+

Search Tips   |   Advanced Search

Propagating security tokens


In this example, security tokens are propagated using Web services security, the security infrastructure of the WAS, and Java EE security.

There is an important distinction between V5.x and V6 and later applications. The information in this article supports V5.x applications only that are used with WAS Version 6.0.x and later. The information does not apply to Version 6.0.x and later applications.

 

An example scenario

In this example, Client 1 invokes Web services 1. Then Web services 1 calls the EJB file 2. The EJB file 2 calls Web services 3 and Web services 3 calls Web services 4. Figure 1. Propagating security tokens

The previous figure shows security tokens propagated using WS-Security, the security infrastructure of the WAS, and Java EE security. Web services 1 is configured to accept <wsse:UsernameToken> only and use the BasicAuth authentication method. However, Web services 4 is configured to accept either <wsse:UsernameToken> using the BasicAuth authentication method or LTPA as <wsse:BinarySecurityToken>.

The following steps describe the scenario shown in the previous figure:

  1. Client 1 sends a SOAP message to Web services 1 with user1 and password in the <wsse:UsernameToken> element.

  2. The user1 and password values are authenticated by the WS-Security run time and set in the current security context as the Java Authentication and Authorization Service (JAAS) Subject.

  3. Web services 1 invokes EJB file 2 using the RMI/IIOP protocol.

  4. The user1 identity is propagated to the downstream call.

  5. The EJB container of EJB file 2 performs an authorization check against user1.

  6. EJB file 2 calls Web services 3 and Web services 3 is configured to accept LTPA tokens.

  7. The RunAs role of EJB file 2 is set to user2.

  8. The LTPA CallbackHandler implementation extracts the LTPA token from the current JAAS Subject in the security context and Web services security run time inserts the token as <wsse: BinarySecurityToken> in the SOAP header.

  9. The WS-Security run time in Web services 3 calls the JAAS login configuration to validate the LTPA token and set it in the current security context as the JAAS Subject.

  10. Web services 3 is configured to send LTPA security to Web services 4. In this case, assume that the RunAs role is not configured for Web services 3. The LTPA token of user2 is propagated to Web services 4.

  11. Client 2 uses the <wsse:UsernameToken> element to propagate the basic authentication data to Web services 4.

WS-Security complements the WebSphere Application WAS security run time and the Java EE role-based security. This example demonstrates how to propagate security tokens across multiple resources such as Web services and EJB files.



 

Related concepts


WS-Security specification—a chronology
WS-Security and Java EE security relationship
WS-Security model in WAS
Security token
WS-Security constraints

 

Related tasks


Set the client for LTPA token authentication: specifying LTPA token authentication
Set the client for LTPA token authentication: collecting the authentication method information
Set the server to handle LTPA token authentication information
Set the server to validate LTPA token authentication information
Set the client security bindings using an assembly tool
Set the security bindings on a server acting as a client
Set pluggable tokens using an assembly tool
Set pluggable tokens
Secure Web services for V5.x applications based on WS-Security

 

Related


WS-Security support