13.5. Handling Token and Key Requirements at Run Time

In the general model for using STS issued tokens to securing Web services, a service side IssuedToken policy assertion is used to specify the STS information (STS endpoint, STS MEX endpoint, etc) and the token requirements (token type, key type, claims, etc). Alternatively, a client side PreConfiguredSTS assertion can be used to specify the local STS. Only one STS can be specified in PreconfiguredSTS. In this way, the process to go to STS to obtain the issued toke and subsequently use it with the messages to the service was handled by Metro transparently to the users.

Now with Metro 2.0, one may also inject STS information and issued token requirements programmatically at run time on the client side. This This gives the users more control of the its identity and security information to be used to access a service, hence open up for building more interesting and important applications with Metro.

General steps for managing run time configuration:

  1. Use existing STSIssuedTokenConfiguration for run-time configuration, e.g.
     DefaultSTSIssuedTokenConfiguration config = new DefaultSTSIssuedTokenConfiguration();
                    Claims claims = ...
  2. Use Web Service Feature to inject STSIssuedTokenConfiguration into the system:
    STSIssuedTokenFeature feature = new STSIssuedTokenFeature(config);
  3. STSIssuedTokenFeature is used when creating port from the Service:
    CalculatorWS port = service.getCalculatorWSPort(new WebServiceFeature[]{feature});
  4. The entries in IssuedToken policy assertion in services WSDL is available through
    This allows the users to select STS at run time according to the service requirements.

While it is more or less straight forward with TokenType, KeyType, etc., it requires extra effort for managing Claims requirement at run time:

  1. Claims are defined as an extensible element in the WS-SecurityPolicy spec:

                     <wst:Claims Dialect="http://schemas.xmlsoap.org/ws/2005/05/identity"
  2. It is up to the applications and profiles of WS-Trust to define the content of the Claims. So you need to implement com.sun.xml.ws.api.security.trust.Claims to manage claims in your environment. Here is a sample for managing claim types of the following form:

                    <wst:Claims Dialect="http://schemas.xmlsoap.org/ws/2005/05/identity"
  3. Make run time requirement for claim types on the client side:

                    DefaultSTSIssuedTokenConfiguration config = new DefaultSTSIssuedTokenConfiguration();
                    STSIssuedTokenFeature feature = new STSIssuedTokenFeature(config);
                    org.me.calculator.client.CalculatorWS port = service.getCalculatorWSPort(new WebServiceFeature[]{feature});

                    int i = Integer.parseInt(request.getParameter("value1"));
                    int j = Integer.parseInt(request.getParameter("value2"));

                    MyClaims claims = new MyClaims();
                    int result = port.add(i, j);


In general, you may need to supply your own STSIssuedTokenConfiguration in following cases:

  1. The client has to go through multiple STS in a trust chain across security domains to access the service.
  2. The client needs to select the STS and/or to provide token and key parameters to the STS at run time, according to which service it tries to access and the requirement from the service.

To create a custom configuration class which extends STSIssuedTokenConfiguration:

  1. You may get the targeted service endpoint at run time through
  2. Similarly, you may get an instance of STSIssuedTokenConfiguration, which captures entries from the IssuedToken policy assertion for the targeted service, through
  3. The entries in the IssuedToken policy and in the client side PreConfiguredSTS take high priorities which cannot be override at run time.
  4. Different run time entries should be supplied for different services.

Terms of Use; Privacy Policy; Copyright ©2013-2017 (revision 20160708.bf2ac18)
Please Confirm