This task is typically accomplished by adding a custom login
module to the various application and system login configurations.
You also can add the implementation from an application. However,
to deserialize the information, you must plug in a custom login module,
which is discussed in
Propagating a custom Java serializable object for security attribute propagation.
The WSSecurityPropagationHelper class has APIs that are used to set
a propagation token on the thread and to retrieve the token from the
thread to make updates.
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 custom 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 Version 2 (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 method.
This call requires the WebSphereRuntimePerMission "setPropagationToken" Java 2 Security permission.