Rebecca Dias is a PM on the Advanced Web Services team. She's shifted her blog to a new location. She has a whole grab bag of WSE goodies posted on her blog from a Web Services conference day.
Tim Ewald provides a useful overview of how WSE fits with ASMX web services, Scott Short has a good PowerPoint on WSE Security - explaining about Security Tokens and WS-SecureConversation.
Best of all though are the two Hands On Labs used at TechEd 2003 and written by Aaron Skonnard. The first describes how to use the SOAP TCP supports, similar to his previous article. The second provides information on how to use WS-Policy to author policy for web services. This is a particularly good document as this feature isn't mentioned in many places (yet).
WS-Policy and WS-SecurityPolicy solve the problem of tying code too closely to the security: controlling access to the code is a separate concern from what the code does. With Policies it is possible to place the security information in a file instead of inside compiled code. So if you decide that a method needs to allow users in the 'Broker' role and not 'Traders' you can make this change in the policyCache.xml file, without having to recompile your code.
It took me a while to understand this. My first attempt at securing web services with WSE was to set the Thread.Principal to a GenericPrincipal object that I created, and then use the [PrincipalPermission(SecurityAction.Demand,Role="Banker")] attribute above my method. However, with policies, I can set this in a policy file, like:
<wsp:Policy wsu:Id="TradersOnly">
<Integrity wsp:Usage="wsp:Required"
xmlns="http://schemas.xmlsoap.org/ws/2002/12/secext">
<TokenInfo>
<SecurityToken>
<TokenType>UsernameToken</TokenType>
<Claims>
<wse:Role value="Traders"
wse:xmlns="http://microsoft.com/wse/2003/06"/>
</Claims>
</SecurityToken>
</TokenInfo>
</Integrity>
</wsp:Policy>
Now all I need to know is how to get this working with a custom SecurityContext token (or how to achieve the same effect with a custom assertion handler). In this case the role information is probably not going to be passed in the SOAP message with the SecurityContext token - it will be cached on the server, so I'm not sure how policy will work in this situation. More study required ...