WS-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. WS-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. Web services security has the following built-in token types:
- Username token
- X.509 token
- LTPA token
ConfigureWeb 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.
When you configure a propagation token in a token generator or token consumer, use the following values for the token type Uniform Resource Identifier (URI) and local name:
- 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 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.
There are two common uses for a propagation token:
- 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. We can generate this LTPA token from the RunAs subject that is created by the JAAS login.
For the receiver of the LTPA propagation token to make proper use of the credentials that were sent to it in the propagation token, configure a define a caller part for the token in the WS-Security configuration on the receiver side.
Related concepts
Security attribute propagation
WS-Security provides message integrity, confidentiality, and authentication
Set token generators using JAX-RPC to protect message authenticity at the server or cell level
Set token consumers using JAX-RPC to protect message authenticity at the server or cell level
Set token generators using JAX-RPC to protect message authenticity at the application level
Set token consumers using JAX-RPC to protect message authenticity at the application level
Token generator settings
Token consumer settings