Web Services Security token propagation
Web Services Security has the ability to send security tokens in the security header of a SOAP message. These security tokens can be used to sign, verify, encrypt or decrypt message parts. Security tokens can also be sent as stand-alone security tokens and set as the caller on the request consumer. Web Services Security token propagation is used to send these stand-alone security tokens in a wsse:BinarySecurityToken element within the security header of the SOAP message.
- Username token
- X.509 token
- Lightweight Third-Party Authentication (LTPA) token
You can configure Web Services Security to use custom security tokens. Web Services Security uses the same propagation token format as the Security attribute propagation feature. Web Services Security can propagate all of the built-in security token types and can propagate custom token types as long as they are serializable by the security attribute propagation feature.
- Token type URI: http://www.ibm.com/websphere/appserver/tokentype
- Token type local name: LTPA_PROPAGATION
When a propagation token is generated, Web Services Security gathers all of the serializable security tokens in the RunAs subject for the current thread and serialize the security tokens within a wsse:BinarySecurityToken token. To have a RunAs subject and the credentials that are necessary on the current thread, a JAAS login must occur on the current thread before a propagation token can be created.
Under ordinary circumstances, for a service provider, the Java Authentication and Authorization Service (JAAS) login is achieved by including a defined caller part for the inbound token in the WS-Security configuration. For a web services client, the JAAS login is achieved by configuring HTTP basic authentication.
- A client from within a secured service propagates the serializable security tokens and credentials from the current RunAs subject to a downstream server.
- A server-based client that is secured in the web container with
HTTP basic authentication can use a propagation token.
For a server-based client, the overhead for propagation tokens is not necessary as only the identity is required and not the full set of credentials. However, if the client application makes modifications to the subject after it is invoked by the web container, it might be appropriate to use a propagation token. If only an identity token is required, an ordinary LTPA token might be appropriate. You can generate this LTPA token from the RunAs subject that is created by the JAAS login.