Identity Delegation in WS Trust 1.4

With the introduction of “ActAs” element, WS Trust 1.4 specification facilitates identity delegation. The best way to understand the usage of this element is through a practical scenario. Following use case demonstrates an application of “ActAs”.

There are two services called service 1 and service 2. Service 2 contains the actual business logic and Alice(service consumer) is interested about it. There is a Security Token Service(STS) which is trusted by both services.

1. Alice sends a RST to the STS authenticating herself to the STS. This is a normal RST.
2. STS returns a SAML Token to Alice in the RSTR. The subject of this SAML token is “Alice”. Let’s refer to this SAML token as token1.
3. Alice forwards the token1 with its soap request to service 1. Up to this message transfer, this is same as a usual trust brokering scenario.
4. Then service1 sends a RST to STS again authenticating itself to the STS. But this time the RST contains the token1 inside the “ActAs” element. (This ActAs element is introduced in the WS Trust 1.4.)
5. Now the STS issues a SAML token(referred to as token2). The subject of this token is “service1”. But it contains an attribute called “ActAs” with the value of “Alice”.
6. Then the service1 sends the token2 to “Service2”. Now the service2 understands that the original requester is “Alice” and “Service1” is acting as the original requester by processing the token2.
7. Then Service1 sends the response to Service2.
8. Finally, Service1 forwards the response to Alice.

Apache Rampart will be supporting WS-Trust 1.4 specification soon. So stay tuned..