Write a custom implementation of the PropagationToken interface.
Many different methods are available for implementing the PropagationToken
interface. However, make sure that the methods that are required by the PropagationToken
interface and the token interface are fully implemented.
After
you implement this interface, you can place it in the app_server_root/classes directory.
Alternatively, you can place the class in any private directory. However,
make sure that the WebSphere Application Server class loader can locate the
class and that it is granted the appropriate permissions. You can add the
Java archive (JAR) file or directory that contains this class into the server.policy file
so that it has the required permissions for the server code.
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.
Tip: 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.
Add and receive the custom propagation token during WebSphere Application
Server logins. 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 need to plug in a custom login module, which is discussed
in Propagating a custom Java serializable object.
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 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 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
token. This call requires the WebSphereRuntimePerMission "setPropagationToken"
Java 2 Security permission.