This topic explains how you might create your own propagation token implementation, which is set on the running thread and propagated downstream.
To implement a custom propagation token, complete the following steps:
After you implement this interface, you can place it in the profile_root/classes directory. The profile_root variable is the directory and name specified for the profilePath parameter at profile creation. For more information on classes, see Creating a classes subdirectory in your profile for custom classes.
All of the token types that are defined by the propagation framework have similar interfaces. The token types are marker interfaces that implement the com.ibm.wsspi.security.token.Token interface. This interface defines most of the methods. If you 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 your token implementations, including the propagation token, might extend the abstract class and then most of the work is complete.
To see an implementation of the propagation token, see Example: com.ibm.wsspi.security.token.PropagationToken implementation.
The code sample in Example: Custom propagation token 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 callback contains propagation data. If the callback does not contain propagation data, initialize a new custom propagation token implementation and set it on the thread. If the callback contains propagation data, look for your specific custom propagation token TokenHolder instance, convert the byte array back into your customer PropagationToken object, and set it back on the thread. The code sample shows both instances.
You can add attributes any time your custom propagation token is added to the thread. If you add attributes between requests and the getUniqueId method changes, the Common Secure Interoperability V2 (CSIv2) client session is invalidated so that it can send the new information downstream. Adding attributes between requests can affect performance. In many cases, you want the downstream requests to receive the new propagation token information.
To add the custom propagation token to the thread, call the WSSecurityPropagationHelper.addPropagationToken token. This call requires the WebSphereRuntimePerMission "setPropagationToken" Java 2 Security permission.
For information on how to add your custom login module to the existing login configurations, see Custom login module development for a system login configuration.