Delegating secure tokens from one relying party to another

Question

I have a WCF service that is a relying party for a custom STS, built using WIF. My STS issues holder-of-key tokens to my client application. I have created a new 'backend' WCF service, that I need to call from the existing 'frontend' service. How can I use the incoming secure token in the frontend service to call the backend service, without retrieving a new one from the STS?

So far, in my frontend service, I have no problem accessing the incoming SamlSecurityToken using a custom Saml11SecurityTokenHandler.

After that, I tried two different ways to attach the out of band token to a service call on my target backend service:

1. Create a custom IssuedSecurityTokenProvider
2. Use ChannelFactoryOperations.CreateChannelWithIssuedToken

However, both of these attempts result in errors. From what I can tell, it seems to be the same dead end, - they do not accept the signed SamlSecurityToken. It seems that even though both of these methods accept the base SecurityToken class, they both only work if given a GenericXmlSecurityToken instance, instead of a SamlSecurityToken.

Update: Here is a code sample and the exception details for bullet #1

Update 2: After doing some more research, the closest thing I can find was an article about using Identity Delegation for WIF/ADFS which basically just uses ActAs tokens, in which the front end service would issue a request to the STS using the token it recieved from the client application. This would require an update to our custom STS, which we're hoping not to do at this time. I'm starting to wonder if the approach that I've illustrated in my diagram is even valid for WIF or WS-Trust?

Answer 1

As it turns out, the the concept of reusing an issued token by a front-end service to call a back-end service IS valid within the confines of WS-Trust protocol. However, for the vast majority of scenarios, it should not be considered a good practice. This is due to security and extensibility concerns. Security-wise, doing so would force both relying parties to use the same token encryption algorithms/keys, and also reduces your ability to authenticate the SAML token's audience restriction. This is exactly why WS-Trust was updated to support Identity Delegation with both ONBEHALFOF and ACTAS tokens. Utilizing either of these will help deal with this exact scenario in a more secure and robust way. It appears that the design of WIF's API follows this line of thinking, which explains why there is no direct API to be found for a front end service to reuse an incoming signed holder-of-key token to call a back-end service.

In conclusion, I have two answers to this question:

A. If you are the owner of your own custom-built STS, you can achieve this scenario outside of the default WIF/WCF pipeline, by following these steps:

1. In the client requestor application, manually retrieve the token from the STS using either WSTrustChannel or an IssuedSecurityTokenProvider. Notice that the token type will be GenericXmlSecurityToken, or some derivation of that.
2. Send the token, out-of-band, to the front end service. By out-of-band, I mean send it as an extra contract field, in a message header, or any other way.
3. Within the front end service, you can easily use the out-of-band token to call the back-end service by using ChannelFactory.CreateChannelWithIssuedToken() or by creating a custom IssuedSecurityTokenProvider. This is not possible when using an incoming bootstrap token, because WIF will always create a bootstrap token as a specific type, such as SamlSecurityToken. Both ChannelFactory and the IssueSecurityTokenProvider will only work with the GenericXmlSecurityToken!

B. Whether you have an out-of-box STS or a custom one, as long as it supports ActAs or OnBehalfOf, you can use proper Identity Delegation.

My conclusions are largely based on the following sources. I hope this ends up helping someone else with similar requirements.

http://www.cloudidentity.com/blog/2008/09/07/delegation-or-traversing-multilayer-architectures/ (Amazing explanation of ACTAS/ONBEHALFOF vs token reuse)

http://msdn.microsoft.com/en-us/library/ee748487.aspx (scroll down to find a comparison of ACTAS and BEHALFOF)

http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html (wstrust protocol, of course)