This task explains how you might create your own AuthorizationToken
implementation, which is set in the login Subject and propagated downstream.
About this task
The default AuthorizationToken usually is sufficient for propagating
attributes that are user-specific. Consider writing your own implementation
if you want to accomplish one of the following tasks:
- Isolate your attributes within your own implementation.
- Serialize the information using custom serialization. You 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() application
programming interface (API).
To implement a custom authorization token, you must complete the following
steps:
- Write a custom implementation of the AuthorizationToken interface.
There are many different methods for implementing the AuthorizationToken
interface. However, make sure that the methods required by the AuthorizationToken
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 necessary permissions that are needed by the server code.
Tip: 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 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 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
- 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, you must
plug in a custom login module, which is discussed in Propagating a custom Java serializable object. After the object is instantiated
in the login module, you can add the object to the Subject during the commit()
method.
If you only want to add information to the Subject to get propagated,
see Propagating a custom Java serializable object.
If you want 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 your 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 your custom AuthorizationToken object, and set
it back into the Subject. The code sample shows both instances.
You
can make your AuthorizationToken read-only in the commit phase of the login
module. If you do not make the token read-only, then attributes can be added
within your applications.
- Add your 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 your 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 your custom login module to the existing login
configurations, see Developing custom login modules for a system login configuration.