Get the latest version of .Net Framework 3.0 at

http://www.microsoft.com/downloads/details.aspx?FamilyId=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=en

Share Tag It! read more...

The latest WS-Trust spec (yet to be ratified by OASIS) introduces a concept called Bearer Tokens. This basically is a keyless token that a client requests from an STS (Security Token Service). The only purpose this token serves is to provide more information about the client to the service while the client already has a way to secure its conversation with the service. (Read my other post on Federation for more details on how client uses that key obtained from a STS token.)

This introduces some qurikiness. The obtained issued token can now be added only as a supporting token. In case of transport secured messages this can just be a signed supporting tokens. In messages level security scenarios, this token should be added as a signed encrypted supporting token. Note, the client doesn't have a key so there is no need for the client to prove to the service that it did obtain the token for the STS and it does know some secret information of the token. So just adding the token as signed token in message level security will expose the token for a third party, who can just snoop the token and replay it to the service as if it is the client.

Bearer tokens issued by a STS should be some how verifiale by the service. For this purpose the Bearer token should be signed by the STS. A SAML 1.1, SAML 2.0 or a custom token fits well for this purpose. WCF will require a wsu:Id to be on the issued token to be able to sign it (In message level security case). A SAML 1.1 does not have a wsu:Id on it and its attribute list is not extendable by the schema and hence it is not possible to use SAML 1.1 as bearer tokens in WCF with message level security. The only choices are SAML 2.0 or a custom token that contains a wsu:Id on it.

The cool feature of Bearer tokens in my opinion is that it enables the client to get multiple such tokens from different STS and present all of it to the service. The service might need information from multiple sources to allow or deny permissions for a client and instead of doing multiple round trips the client can present all information to the service at once.

WCF v1 does not support this token type and we might be adding support for this in the future. The idea behind this post is to explain the issues involved in using such tokens and how it plays with message level and transport level security.

Share Tag It! read more...

There are four different security header layout that can be specified. The values are defined in WS-SecurityPolicy. They are,

• Strict - All security tokens are defined in the security header before its first use. The primary signature should be specified before any endorsing signatures.
• Lax - All elements inside the security header can appear in any order.
• LaxWithTimestampFirst - Timestamp element should be the first element that appears inside the security header. All other elements can appear in any order.
• LaxWithTimestampLast - Timestamp element should be the last element inside the security header.

WCF provides a way to specify the security header layout using a switch on the security binding element called securityHeaderLayout.

Strict is the default mode in WCF. Lax mode can be slower in rejecting invalid messages as most of the validations are done after the security header is consumed. LaxWithTimestampLast serves the least purpose among the different header layouts but is defined for Interop reasons.

So what should you use? Lax is predominantly used when incoming message can be generated by different stacks. If all your messages are from WCF then using the default of Strict gives the maximum benefit.

Share Tag It! read more...