Implement a custom authorization token for security attribute propagation

This task explains how you might create our own AuthorizationToken implementation, which is set in the login Subject and propagated downstream.

The default AuthorizationToken usually is sufficient for propagating attributes that are user-specific. Consider writing our own implementation to accomplish one of the following tasks:

• Isolate the attributes within our own implementation.

• Serialize the information by using custom serialization. We must deserialize the bytes at the target and add that information back on the thread. This task also might include encryption and decryption.

• Affect the overall uniqueness of the Subject using the getUniqueID() (API).

To implement a custom authorization token, you must complete the following steps:

1. Write a custom implementation of the AuthorizationToken interface. There are many different methods for implementing the AuthorizationToken interface. However, verify the methods required by the AuthorizationToken interface and the token interface are fully implemented.

   (dist)(zos) After you implement this interface, we can place it in the app_server_root/classes directory. Alternatively, we can place the class in any private directory. However, verify the WAS class loader can locate the class and that it is granted the appropriate permissions. We can add the JAR file or directory containing this class into the server.policy file so that it has the necessary permissions that are needed by the server code.

   (iseries) After you implement this interface, place it in the profile_root/classes directory. For more information on classes, see Create a classes subdirectory in the profile for custom classes.

   All of the token types defined by the propagation framework have similar interfaces. Basically, the token types are marker interfaces that implement the com.ibm.wsspi.security.token.Token interface. This interface defines most of the methods. If we plan to implement more than one token type, consider creating an abstract class that implements the com.ibm.wsspi.security.token.Token interface. All of the token implementations, including the AuthorizationToken, might extend the abstract class and then most of the work is completed.

   To see an implementation of AuthorizationToken, see Example: com.ibm.wsspi.security.token.AuthorizationToken implementation

2. Add and receive the custom AuthorizationToken during WebSphere Application Server logins. This task is typically accomplished by adding a custom login module to the various application and system login configurations. However, in order to deserialize the information, plug in a custom login module, which is discussed in Propagating a custom Java serializable object for security attribute propagation. After the object is instantiated in the login module, we can add the object to the Subject during the commit() method.

   To add information to the Subject to get propagated, see Propagating a custom Java serializable object for security attribute propagation. To ensure that the information is propagated, want to do you own custom serialization, or want to specify the uniqueness for Subject caching purposes, then consider writing our own AuthorizationToken implementation.

   The code sample in Example: custom AuthorizationToken login module shows how to determine if the login is an initial login or a propagation login. The difference between these login types is whether the WSTokenHolderCallback contains propagation data. If the callback does not contain propagation data, initialize a new custom AuthorizationToken implementation and set it into the Subject. If the callback contains propagation data, look for your specific custom AuthorizationToken TokenHolder instance, convert the byte[] back into the custom AuthorizationToken object, and set it back into the Subject. The code sample shows both instances.

   We can make the AuthorizationToken read-only in the commit phase of the login module. If we do not make the token read-only, then attributes can be added within the applications.

3. Add the custom login module to WebSphere Application Server system login configurations that already contain the com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule for receiving serialized versions of the custom authorization token.

   Because this login module relies on information in the sharedState added by the com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule, add this login module after com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule. For information on how to add the custom login module to the existing login configurations, see Developing custom login modules for a system login configuration for JAAS.

Results

After completing these steps, we have implemented a custom AuthorizationToken.

Subtopics

• Example: com.ibm.wsspi.security.token.AuthorizationToken implementation
  Use this file to see an example of a AuthorizationToken implementation. The following sample code does not extend an abstract class, but rather implements the com.ibm.wsspi.security.token.AuthorizationToken interface directly. We can implement the interface directly, but it might cause you to write duplicate code. However, you might choose to implement the interface directly if there are considerable differences between how you handle the various token implementations.

• Example: custom AuthorizationToken login module
  This file shows how to determine if the login is an initial login or a propagation login.

Related concepts

Security attribute propagation

Related tasks

Implement tokens for security attribute propagation

Propagating security attributes among application servers

Develop custom login modules for a system login configuration for JAAS