Identity Delegation and Impersonation

In this scenario, a web service provider requests services from other web service providers.

Two web service providers called Service1 and Service2 provide some fine-grained service. Both Service1 and Service2 require authentication and trust WS-Trust STS. A web service client tries to access Service1 and requests for the service. To fulfill the request, Service1 needs to access the service of Service2. Service1 can request a token from WS-Trust STS to access Service2. This exchange of information happens through security tokens embedded in SOAP messages. This chaining of service request can be any number of nodes based on the implementation.

Requests for tokens can be made in two ways:

  • By using the ActAs element (Identity Delegation): The ActAs element is used for delegated requests. Delegated scenarios require composite delegation, where the final recipient of the issued token can see the entire delegation chain. ActAs is commonly used in multi-tiered systems to authenticate and pass information about identities between the tiers without having to pass this information at the application or business logic layer.

  • By using the OnBehalfOf element (Impersonation): The OnBehalfOf element is used for proxy requests. OnBehalfOf is used when the identity of only the original client is important. The final recipient of the issued token can only see claims about the original client. The information about intermediaries is not preserved.

The following diagram illustrates the workflow:

The following workflow explains the ActAs scenario:

  1. The web service client sends a RST to WS-Trust STS for its authentication.

  2. WS-Trust STS returns a SAML token to the client in the RSTR. Let us refer to this SAML token as token1. The subject of this SAML token is client.

  3. The client forwards the token1 with its SOAP request to Service1.

  4. Then Service1 sends a RST to WS-Trust STS again authenticating itself to the STS. This time the RST contains the token1 inside the ActAs element.

  5. WS-Trust STS issues a SAML token (referred to as token2). The subject of this token is Service1. It contains an attribute called ActAs with the value of client.

  6. Service1 sends token2 to Service2. By processing token2, Service2 understands that the original requester is client and Service1 is acting as the original requester.

  7. Service2 sends the response to Service1.

  8. Service1 forwards the response to the client.

The following workflow explains the OnBehalfOf scenario:

  1. The web service client sends a RST to WS-Trust STS for its authentication.

  2. WS-Trust STS returns a SAML token to the client in the RSTR. Let us refer to this SAML token as token1. The subject of this SAML token is client.

  3. The client forwards the token1 with its SOAP request to Service1.

  4. Then Service1 sends a RST to WS-Trust STS again authenticating itself to the STS. This time the RST contains the token1 inside the OnBehalfOf element.

  5. WS-Trust STS issues a SAML token (referred to as token2). The subject of this token is client.

  6. Service1 sends token2 to Service2. Service2 understands that the original requester is client but cannot see the details of Service1.

  7. Service2 sends the response to Service1.

  8. Service1 forwards the response to the client.

IMPORTANT:By default, Access Manager supports the SOAP 1.2 binding. If you want to use SOAP 1.1 instead, perform the following steps on all instances of Identity Server:

  1. Open the sun-jaxws.xml file.

    For information about how to open and modify a file, see Modifying Configurations.

  2. Remove all instances of bindings from endpoints and save changes. A binding is represented by the following line in this file:

    binding="http://java.sun.com/xml/ns/jaxws/2003/05/soap/bindings/HTTP/"