13.6. Advanced Usages of STS in Security

The following sections discuss some features for advanced usages of STS in securing Web services with:

13.6.1. Token Caching and Sharing

It is a common requirement from many users and customers of Metro to let the client have more control of the use of issued token from an STS. One particular requirement is that to share issued tokens among multiple services.

Here is a description of how this is supported in Metro:

  1. The services to be accessed with the same token must share the same certificate.
  2. Only issued tokens from the same STS are shared.
  3. Caching and sharing issued tokens can be enabled for each service instance by configuration
To enable this for a service proxy, you need to add attribute shareToken="true" in the wsit-client.xml or the file referenced by it for the proxy:


To illustate the usage, you may find a stand alone sample here. This sample contains 4 parts for client, STS, Service, and Service1. Each service is configured to use the STS issued token to access. On the client side, the client instances for Service and Service1 are configured to be in the circle to share the issued tokens from the STS. The client calls Service first, then Servcie1. You will see that the client goes to the STS to get the token to access Service, and then to call Service1 without going to the STS but use the token obtained in calling Service.

Here is a description on how to managing the lifetime and renewing of the issued tokens:

  1. The client can request for the life time of an issued token through configuration with a subelement LifeTime of PreConfiguredSTS:

                           <t:PreConfiguredSTS xmlns:t="http://schemas.sun.com/ws/2006/05/trust/client"
    or programmatically with STSIssuedTokenConfiguration:

                            config.getOtherOptions().put(STSIssuedTokenConfiguration.LIFE_TIME, Integer.valueOf(3600));
    The value is used to construct the Lifetime element in the RST to the STS:

                                  <wsu:Created xmlns:wsu="...">2007-10-31T18:39:23.548Z</wsu:Created>
                                  <wsu:Expires xmlns:wsu="...">2007-11-01T02:39:23.548Z</wsu:Expires>
  2. By default, an exception is thrown if the token cached to be used on the client side is expired.
  3. One can enable to automatically request for a new token for an expired token by configuration with attribute renewExpiredToken in PreConfiguredSTS:

                                <t:PreConfiguredSTS xmlns:t="http://schemas.sun.com/ws/2006/05/trust/client"
    or programmatically with STSIssuedTokenConfiguration:

                                config.getOtherOptions().put(STSIssuedTokenConfiguration.RENEW_EXPIRED_TOKEN, "true");

13.6.2. ActAs and Identity Delegation

We provide support for ActAs introduced in WS-Truts 1.4 in Metro 2.0

ActAs and Identity Delegation
Screen shot of ActAs
This feature is better illustrated by the sample here.
  1. The Client send a request to the STS. The request message carries the username/password of the user and is secured with the STS certificate.
  2. The STS issues an SAML assertion containing the username (e.g. Alice) as subject id and role attribute (see src\common\SampleSTSAttributeProvider). Then it send a response message with the issued token to the Client.
  3. The client send a request to the Service. The message carries the SAML assertion from the previous step for authentication and secured with the Service certificate.
  4. The Service send a request to the STS. The message contains the username/password (bob/bob) of the Service, the SAML assertion received from the user in the previous step in an ActAs element in the body (RST), and is secure with the STS certificate (see src\fs\ simple\server\FSImpl.java. The ActAs token is injected into the request using the STSIssuedTokenFeture). It means to ask for an issued token with it the Service can access the Service 1, acting as the user.
  5. The STS issues an (act as) SAML assertion which contains the Service id (bob) in the Subject, and attribute ActAs with the user name (e.g. Alice), and role attribute for the user (see src\common\SampleSTSAttributeProvider). It then send a response message with the issued token to the Service.
  6. The Service sand a request to the Service 1. The message carries the act as SAML from the previous step and is secured with the Service 1 certificate. The Service 1 check the act as SAML assertion (see src\common\SampleSamlValidator.java) and understands it is the Service who made the request act as the user.
  7. The Service 1 send a response to the Service.
  8. The Service sends a response to the Client.

Common issues and solutions:

  1. When a custom SAML assertion validator is used, the SAML assertion is not available in the Subject.

    In this case, you need to use the extended version com.sun.xml.wss.impl.callback.SamlValidator and to add explicitly the DOM based saml assertion to the public credentials of the Subject in your implementation of the method

                       validate(XMLStreamReader assertion,
                            Map runtimeProps, Subject clientSubject) and validate(Element assertion, Map runtimeProps, Subject clientSubject;
    in the interface.
  2. ActAs is not called in your custom STSAttributeProvider:

    You need to use the WSTrustContractImpl for your STS as specified in the STSConfiguration in the sts wsdl:

                 <tc:STSConfiguration xmlns:tc="http://schemas.sun.com/ws/2006/05/trust/server"
                          sencryptIssuedKey="true" encryptIssuedToken="false">
    If you use Netbenas to create STS, IssueSAMLTokenContractImpl is set by default. You need to change it to WSTrustContractImpl for "ActAs" support.

Terms of Use; Privacy Policy; Copyright ©2013-2014 (revision 20131025.e7cbc9d)
Please Confirm