For example, creating a new example with the UsernameToken security token, based on the OASIS WS-Security standard, requires some minor adjustments to your web.config settings. Previously, when you configure a custom security token manager to handle <wsse:UsernameToken>, you would add the following <securityTokenManager> element:

Of course the namespace and qualified name of the OASIS WSS UsernameToken profile haven't changed, but the way ASP.NET 2.0 handles application assemblies has, along with the WSE 3.0 configuration schema.

First point: ASP.NET no longer has a single application assembly (DLL) for the application code. You can't count on a specifically named assembly like MyWSE30Service.DLL to be deployed to the \bin directory. In fact several assemblies are generated from the Web site source, and the assembly names are dynamically generated. So, you can't specify the name of the assembly in the type attribute of the <securityTokenManager> element, the custom token manager type is compiled with the ASP.NET application code. In this case the type attribute should only include the fully qualified type name with its full namespace.  And, you'll be glad to know that when you sign the Web site application output assemblies, the setting remains the same.

For types that are compiled into a separate assembly, then referenced, the traditional format for the type attribute would be used. The fuly qualified namespace and assembly name are provided for unsigned assemblies. For signed assemblies provide the full assembly name which includes version, culture, and public key token.

Second point: there is a new namespace attribute, and qname has changed to localname...and they aren't the same thing. Qname refers to a fully qualified XML name which means namespace and local name. Now, the QName property of the SecurityTokenManager at runtime can be generated from the namespace and localname in configuration.

Third point: with WSE 3.0 you can configure more than one token manager for each type of security token manager (binary or XML). THis changes the configuration schema for <securityTokenManager> which now supports the traditional pattern of add, remove, clear - as discussed in the WSE 3.0 specification:

<securityTokenManager>
<add localName namespace type />
<remove localName namespace />
<clear />
</securityTokenManager >

And so now your custom UsernameTokenManager should be configured like this:

Of course, you could just read through the WSE 3.0 documentation to find these things out...but I betcha browsed the Web first, so here ya go...