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 by 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 by 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.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
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.
After you implement this interface, place it in
the profile_root/classes directory. For more information on classes, see Criando um Subdiretório de Classes em seu Perfil para Classes Customizadas.
Tip: All
of the token types that are 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 for security attribute propagation. After the object
is instantiated in the login module, you can add the object to the
Subject during the commit() method.
If you want to add information
to the Subject to get propagated, see Propagating a custom Java serializable object for security attribute propagation. 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 for JAAS.