Establishing a Secure Conversation with Security Context Tokens

When a security token service is configured to issue security context tokens, a SOAP message sender can use the security token to sign and/or encrypt a series of SOAP messages, known as a conversation, between a SOAP message sender and the target Web service. As long as the requested security token, which is a SecurityContextToken security token, has not expired, the SOAP message sender can use the same security token to sign and/or encrypt the SOAP messages sent to the target Web service.

The following illustration shows a SOAP message sending a Request Security Token (RST) to request a security token from a security token. The security token can then be used to sign and encrypt a series of SOAP messages between a SOAP message sender and a target Web service.

When a request is deemed valid by a security token service, the RSTR contains either an entropy value or the proof token. An entropy value, which is similar to a symmetric session key value in that it is a randomly generated value of some sufficiently long length, is returned in the RSTR if the RST contained an entropy value. This returned entropy value and the entropy value sent in the RST are passed to the PSHA-1 algorithm to generate a symmetric key. The security token service and the sender generate and cache a security token using this computed symmetric key.

Constructing a security token from the two entropy values is handled by the security token service client classes (SecurityContextTokenServiceClient and SecurityTokenServiceClient). So, when you build your application, it takes a similar number of lines of code to request a security token using entropy values, as it does to request a security token from a security token service that simply returns a security token. The benefit of using entropy values is that both the SOAP message sender and security token service contribute to the strength of the symmetric key. When policy is used to request a security context token, WSE uses 128-bit entropy values by default. When using a proof token instead of entropy, user code should ensure that the RSTR was signed with the expected issuer token.

The security token service and security context token support found in WSE support the WS-Trust and WS-SecureConversation specifications, respectively.

In This Section

• How to: Create a Custom Policy Assertion That Supports Secure Conversations
  Details how to communicate with a SecurityContextTokenService security token service security token service to obtain a SecurityContextToken security token.