9.3 Scenarios

This section describes the basic scenarios supported by WS-Trust STS.

9.3.1 Scenario 1: Web Service Client Communicating with Token Protected Web Service Provider

In this scenario, a Web service client situated outside the enterprise tries to access a Web service provider hosted inside the enterprise.

This process consists of requesting a token by means of the request‐response message pairs of a Request Security Token (RST) and a Request Security Token Response (RSTR). The tokens are included in SOAP messages.

The following diagram illustrates this scenario:

  1. A Web service client, which is outside the enterprise, sends its credentials to WS-Trust STS and request for the security token through RST.

  2. WS-Trust STS verifies the client’s credentials and then issues a security token (SAML token) through RSTR.

    The Web service client caches the security token and then uses it in multiple requests to the Web service provider.

  3. The Web service client presents the token to the Web service provider.

  4. The Web service provider validates the token and sends the response to the Web service client.

9.3.2 Scenario 2: Web Single Sign-On and STS

In this scenario, a Web service client that resides as part of a Web application within an enterprise tries to access services from other Web service providers of the same enterprise. A user named Alice accesses to the Web application through a browser and needs single sign-on access to other applications.

  1. A Web application sends a single sign-on authentication request to WS-Trust STS on behalf of Alice.

    The Web application is residing within the enterprise.

  2. The Web application passes the credentials corresponding to the single sign-on session to the Web service client.

  3. The Web service client requests for security token by using the passed on credentials.

  4. WS-Trust STS verifies the credentials. After checking the credentials, it verifies if the Web service provider for which the token has been requested for is a trusted service provider. Then it issues a security token consumable by the service provider.

  5. The Web service client residing within the Web application presents the token to the Web service provider. The Web service client caches the security token and then uses it in multiple requests to the Web service provider.

  6. The Web service provider validates the token and sends the response to the Web service client residing within the Web application.

The tokens are included in SOAP messages.

9.3.3 Scenario 3: Identity Delegation and Impersonation

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

The following use-case explains this scenario:

There are two Web service providers called Service1 and Service2 providing 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:Starting from Access Manager 4.0 SP1 release, the default binding supported is SOAP 1.2. If you want to use SOAP 1.1 instead, perform the following steps on all instances of the Identity Server:

  1. Traverse to the /opt/novell/nam/idp/webapps/nidp/WEB-INF folder and edit the sun-jaxws.xml file.

  2. Remove all instances of bindings from the endpoints in the sun-jaxws.xml file and save the 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/"

  3. Restart the Identity Server using the /etc/init.d/novell-idp restart command.

9.3.4 Renewing a Token

The renew token operation helps in renewing a token issued by WS-Trust Security Token Service(STS). Only a token that is issued by an Identity Server that is part of the same cluster can be renewed. Tokens issued by a different Identity Server in a different cluster or by a third-party STS cannot be renewed.

Each token generated by the STS is valid for the duration specified using the Token Lifetime setting. A token can be renewed only before lapse of the expiry period. For example: if the Token Lifetime has been specified as 180 seconds, token renew operation will succeed only till the 179th second.

Workflow:

  1. The Web service client sends a RST to WS-Trust STS for its authentication and WS-Trust STS returns a SAML token to the client in the RSTR

  2. Web Service Provider uses the SAML token from STS and requests access to resources hosted on the Web Service provider.

  3. The Web Service Provider validates the SAML token and provides access to the resources.

  4. When the token is nearing expiry, the Web service client sends a RST to WS-Trust STS to renew the token previously issued. The STS renews the validity of the token and sends a renewed token to the Web Service client for any further requests.

  5. Web Service client uses the renewed SAML token from STS and requests access to resources hosted on the Web Service provider.

9.3.5 Authentication Using SAML Tokens

WS-Trust STS now accepts SAML tokens issued by a third-party STS for authentication. The tokens can be in SAML 1.1 or SAML 2.0. This is an improvement over the existing feature where only username tokens were accepted for authentication.

Workflow:

  1. The Web service client sends a RST to third-party STS. The third-party STS returns a SAML token to the client in the RSTR.

  2. The Web Service client uses SAML token issued by the third-party STS and requests WS-Trust STS to grant access to resources hosted on the Web Service Provider.

  3. WS-Trust STS authenticates the client using the third-party SAML token and issues a new SAML token.

  4. The Web Service client uses this new SAML token to get access to resources hosted on the Web Service Provider.

  5. The Web Service Provider validates the SAML token with WS-Trust STS.

  6. The Web Service client can access the resources on the Web Service Provider if the SAML token is valid.