Sdílet prostřednictvím

Federation and Bearer Tokens

  • Článek

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.

Comments

  • Anonymous
    June 10, 2008
    weblogic already support this feature