WS-Trust and WS-SecureConversation were updated today. WSE 2.0 implements these specifications, not the older versions, so they are required reading if you working with the related features in WSE 2.0.
One of the most notable changes to WS-SecureConversation from a WSE perspective is the removal of the KeysXml element in a SecurityContextToken. As a result of this change, WSE 2.0 no longer supports 3-party Secure Conversation out-of-the-box - there is no interoperable mechanism for carrying the required key material. Instead, custom additions are required to the built-in SCT to make this work.
Following the Security Review for WSE 2.0 we have added a new feature that makes all services, both ASMX and SoapService, capable of using Secure Conversation automatically.
In the configuration file, you enable automatic Secure Conversation. Thereafter, all services in your application respond to a request to issue a SecurityContextToken (SCT), including ASMX-based services. This behaviour is enabled directly in SoapService and the WebServicesExtension classes and uses the SecurityContextTokenService class to handle the RST / RSTR messages. With additional configuration, or method overrides for SoapServices, you can utilize your own token issuer instead of the built-in one.
Also as a result of the security review, the default behaviour of the SecurityTokenService class is very strict: it requires signed and encrypted requests and signs and encrypts responses. The SecurityTokenServiceClient also has stricter rules to ensure that the tokens used across RST and RSTR match and thus provides a further element of mutual authentication. Both the client and service classes were also modified to provide a consistent framework of protected, virtual methods for verifying and processing requests and securing the responses.
Steven asked in a comment:
"...we want to create a WSE2 conversation that starts by a clients sending a request to the server passing a UsernameToken. Upon this first request, the server will extract the usrnam/passwd and authenticate against an Oracle data provider. (Yes, we're using app-level user and role management.) If authenticated, the server will generate a SecurityContextToken to pass back to the client. Subsequent messages will contain the context token, recognized by the server, so the server won't have to re-authenticate against Oracle.
Of course, this implies TTLs, nonce, sequence values, etc. But the important thing is that the server may not be using ASP Sessions, so we need to embed the Username in the SecurityContextToken so the server can recall a user context for each message.
Is this possible with WSE2?"
As ever, I have to caveat my answer based on current builds of WSE 2.0, not the Tech Preview. The above scenario is (we hope) reasonably simple to implement and only requires extension for a few scenarios. I demonstrated some of the techniques required based on the Tech Preview release in a previous entry.
WSE 2.0 allows a client to issue a RequestSecurityToken (RST) message to a token issuer for a SecurityContextToken (SCT). For the WSE 2.0 final release, UsernameTokens will be supported as the base token for RST messages. An issuer processing this message can validate the UsernameToken and then issue an appropriate SCT to the requestor in a RequestSecurityTokenResponse (RSTR) message. The SecurityContextTokenService is the base class in WSE for this service. You may either host this standalone at it's own endpoint or subclass it and add your own service methods to it. The SecurityTokenServiceClient class provides an interface for sending the RST message and receiving the resultant token via the RSTR message from the issuer. The client can then use the SCT to communicate with the target service.
Generally, the only customisation required for this step is for handling passwords for UsernameTokens if you are not using Windows based authentication. This involves subclassing the UsernameToken security token manager and implementing the methods that allow WSE to verify the password in the token and thence generate keys to validate signatures. This is demonstrated in the samples for the product.
As part of its processing for the RST message, the SecurityContextTokenService will remember the issued token and the base token associated with it, in this case, the UsernameToken. These are cached in memory. This cache is in a CLR AppDomain, it is not associated with the ASP.NET session but it's lifetime is dependent on the lifetime of the hosting process. When an SCT arrives from a client at the target service it typically contains only an Identifier. The SecurityContextTokenManager uses this Identifier value to search the cache of issued tokens and effectively replace the token in the message with the one from the cache. Of course, the token from cache carries with it key material for verifying signatures and a reference to the original base token - the UsernameToken. At this point, the target service can find the UsernameToken and then set identity or audit information appropriately.
Of course, if the target service is not hosted in the same AppDomain as the token issuing service, then it will not have access to the memory cache of issued tokens. As a result, it will not be able to verify incoming messages. To handle this situation, you can configure a
One item is left undone in the above: the default SCT does not carry identity with it and therefore the target service cannot determine the user. The only way to solve this is to extend the SCT implementation in WSE and add more data to the issued SCT token. If you choose to do this, you should ensure that the SCT's issued are signed by the issuer - WSE has a config option that triggers the built-in issuers to generate an Enveloped XML Signature over issued tokens. Doing this allows anyone processing the token to validate that it has not been modified since it was issued.
Similar to the scenario above is hosting on a web farm where multiple physical machines are acting as a single node. Once again, the memory caches of the issuers and target services may not be the same; you can deal with this using the same techniques outlined above.
Finally, we are looking at a mechanism for users to override SecurityTokenManagers and replace the token caching mechanism, for example with a database cache instead of a memory cache. This allows the issued SCT along with its base token to be shared across all machines in a farm. Keith has prototyped this approach and we are refining it for the final release.
Hopefully, this will get you started on the right track.