Generic security token login modules
The generic security token login modules are JAAS login modules. These login modules issue, validate, and exchange security tokens using an external Security Token Service (STS).
Overview
The Web Services Security token generation and consuming processes invoke these login modules. The Web Services Security component provides default login modules for common tokens such as the following examples:
- Username tokens
- X.509 tokens
- Kerberos tokens
- LTPA tokens
- SAML tokens
- Security context tokens
For more information on the token implementations, see the default implementations of the Web Services Security service provider programming interfaces documentation.
If we are using the IBM Tivoli Federated Identity Manager as an external Security Token Service, we should use Versions 6.2.0.9, 6.2.1.2, 6.2.2 or later to prevent LTPA token exchange failures.
The following illustration shows the flow of information through the generic security token login module process.
- The caller's identity is inherited by the runtime environment of the web services client.
- The generic security token login module for the token generator sends a token request to a WS-Trust service using a WS-Trust client using either an issue or validate request.
- The returned or validated token is set in the security header of the SOAP message as an authentication token. For more information, see the documentation about the generic security token login modules for the token generator.
- The PassTicket is sent as part of the SOAP message to the service provider.
- The generic security token login module for the token consumer sends the received token in the security header of the SOAP message within a WS-Trust Validate request to a designated WS-Trust service.
- The request might result in a new token or in a notification that the sent token has been validated successfully.
- As required, the new or originally validated token is used as the caller token for authorization purposes. For more information, see the documentation about the generic security token login modules for the token consumer.
A PassTicket is a dynamically generated, one-time use, substitute password. Use the PassTicket to authenticate to a service rather than sending the actual password.
Usage scenarios
The generic security token login module might be very useful if token exchange, identity mapping, or authorization to invoke a target web service are required. The following list explains some useful usage scenarios for a generic security token login module:
- Token exchange with an intermediate server
- The required outgoing security token and the incoming security token are different types.
- Token exchange on the requesting side
- An identity mapping for the requestor is required before invoking a downstream service.
- Token exchange on the receiving side
- The invoking identity mapping is required after the token is validated.
- Authorization to invoke target service
- The login module sends the incoming security token and its target service endpoint address to the WS-Trust service. The WS-Trust service completes the web service-level authorization. The WS-Trust service verifies whether the target web service invocation is authorized for the principal contained within the authentication token.
Limitations
The following limitations exist for the generic login modules:
- Use the token, which is processed by the generic security token login module, for authentication only. We cannot use the token as a protection token to digitally sign and encrypt message parts.
- If the service provider receives an exchanged token, the token must be supported by the default login modules for the application server Web Service Security system. See documentation about the generic security token login module for the token consumer.
- If the service provider receives a token that is validated and not exchanged, the received token must be supported by the default login modules for the application server Web Service Security system.
- When we use a security token from the RunAs Subject to validate or exchange for an outbound security token, the security token within the RunAs Subject must be uniquely identified by a token ValueType value. If multiple tokens in the RunAs Subject have the same ValueType value, the login module does not use WS-Trust Validate to exchange a token with the RunAs Subject. Instead, the login modules use WS-Trust Issue to request a token based on the configuration of the policy set for the trust client.
Related: