Why do we need to manage state when using a Security Context Token, and what are the implications?

A security context token is a lightweight token that can be established for multiple message exchanges between two endpoints. It only makes sense to establish an SCT if it is anticipated that multiple messages will be exchanged. The specification for this feature can be found here and builds on both ws-security and ws-trust. You’ll notice that the defined payload of the token is very light – in fact, only one element mandatory element is defined, Identifier, for an SCT. While a third party approach to issuing SCT’s is not prohibited, the model that WSE supports out of the box and we anticipate will be predominantly used is based on a conversation between two endpoints. In fact, WSE has a really cool feature, auto issuing (configured with < autoIssueSecurityContextToken>) where the framework picks up an incoming SCT request issued directly to the service endpoint and handles it.

If you’ve seen what various security token looks like, you know that they can be pretty large, and the associated transport and parsing logic can add measurable overhead – for instance, a Kerberos based token can be well over 1K in size. SCT avoids this overhead by relying on the client and service retaining the key information as well as BaseToken used in originally establishing the secure context. An exchange has already occurred to authenticate and establish identity when an SCT is requested that has established the identity and credentials of the client. Once established, the client and service use the identifier in the SCT to pull the key and base token information back out of a cache for validating the message information and establishing the identity.

The implication here of course is that state is saved on both the client and service side that allows the parties to more efficiently manage security. However when your service is deployed to a web farm, this assumption on the server side needs to be addressed. Several ways to deal with this issue are:

1) Pin the client session to a particular server instance hosting the service in the farm. Most load balancers have an ability to route incoming requests to the same server instance based upon some form of session affinity.

2) Support a distributed cache on the server side for sharing the SCT information across the farm.

3) Put the state information for the SCT into the extensibility area of the SCT.

I will examine all three options over the next few blog entries.