Default AuthorizationToken
This article explains how WAS uses the default AuthorizationToken. Consider using the default AuthorizationToken when you are looking for a place to add string attributes that will get propagated downstream. However, make sure that the attributes that you add to the AuthorizationToken are specific to the user associated with the authenticated Subject. If they are not specific to a user, the attributes probably belong in the PropagationToken, which is also propagated with the request. For more information on the PropagationToken, see Default PropagationToken. To add attributes into the AuthorizationToken, plug in a custom login module into the various system login modules that are configured. Any login module configuration that has the com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule implementation configured can receive propagated information and can generate propagation information that can be sent outbound to another server.
If propagated attributes are not presented to the login configuration during an initial login, a default AuthorizationToken is created in the wsMapDefaultInboundLoginModule after the login occurs in the ltpaLoginModule. A reference to the default AuthorizationToken can be obtained from the login() method using the sharedState hashmap. You must plug in the custom login module after the wsMapDefaultInboundLoginModule implementation for WAS to see the default AuthorizationToken..
For more information on the Java Authentication and Authorization Service (JAAS) programming model, see Security: Resources for learning.
Important: Whenever you plug in a custom login module into the WAS login infrastructure, ensure that the code is trusted. When you add the login module into the install_dir/classes directory, it has Java 2 Security AllPermissions. It is recommended that you add your login module and other infrastructure classes into a private directory. However, if you use a private directory, modify the $(WAS_INSTALL_ROOT)/properties/server.policy file so that the private directory, JAR file, or both have the permissions needed to execute the API called from the login module. Because the login module might run after the application code on the call stack, you might consider adding a doPrivileged code block so that you do not need to add additional permissions to your applications.
The following sample code shows you how to obtain a reference to the default AuthorizationToken from the login() method, how to add attributes to the token, and how to read from the existing attributes that are used for authorization.
public customLoginModule()
{
public void initialize(Subject subject, CallbackHandler callbackHandler,
Map sharedState, Map options)
{
// (For more information on initialization, see
// Custom login module development for a system login configuration.)
// Get a reference to the sharedState map that is passed in during initialization.
_sharedState = sharedState;
}
public boolean login() throws LoginException
{
// (For more information on what to during login, see
// Custom login module development for a system login configuration.)
// Look for the default AuthorizationToken in the shared state
defaultAuthzToken = (com.ibm.wsspi.security.token.AuthorizationToken)
sharedState.get
(com.ibm.wsspi.security.auth.callback.Constants.WSAUTHZTOKEN_KEY);
// Might not always have one of these generated. It depends on the login
// configuration setup.
if (defaultAuthzToken != null)
{
try
{
// Add a custom attribute
defaultAuthzToken.addAttribute("key1", "value1");
// Determine all of the attributes and values that exist in the token.
java.util.Enumeration listOfAttributes = defaultAuthorizationToken.
getAttributeNames();
while (listOfAttributes.hasMoreElements())
{
String key = (String) listOfAttributes.nextElement();
String[] values = (String[]) defaultAuthorizationToken.getAttributes (key);
for (int i=0; i<values.length; i++)
{
System.out.println ("Key: " + key + ", Value[" + i + "]: "
+ values[i]);
}
}
// Read the existing uniqueID attribute.
String[] uniqueID = defaultAuthzToken.getAttributes
(com.ibm.wsspi.security.token.AttributeNameConstants.
WSCREDENTIAL_UNIQUEID);
// Getthe uniqueID from the String[]
String unique_id = (uniqueID != null &&
uniqueID[0] != null) ? uniqueID[0] : "";
// Read the existing expiration attribute.
String[] expiration = defaultAuthzToken.getAttributes
(com.ibm.wsspi.security.token.AttributeNameConstants.
WSCREDENTIAL_EXPIRATION);
// An example of getting a long expiration value from the string array.
long expire_time = 0;
if (expiration != null && expiration[0] != null)
expire_time = Long.parseLong(expiration[0]);
// Read the existing display name attribute.
String[] securityName = defaultAuthzToken.getAttributes
(com.ibm.wsspi.security.token.AttributeNameConstants.
WSCREDENTIAL_SECURITYNAME);
// Get the display name from the String[]
String display_name = (securityName != null &&
securityName[0] != null) ? securityName[0] : "";
// Read the existing long securityName attribute.
String[] longSecurityName = defaultAuthzToken.getAttributes
(com.ibm.wsspi.security.token.AttributeNameConstants.
WSCREDENTIAL_LONGSECURITYNAME);
// Get the long security name from the String[]
String long_security_name = (longSecurityName != null &&
longSecurityName[0] != null) ? longSecurityName[0] : "";
// Read the existing group attribute.
String[] groupList = defaultAuthzToken.getAttributes
(com.ibm.wsspi.security.token.AttributeNameConstants.
WSCREDENTIAL_GROUPS);
// Get the groups from the String[]
ArrayList groups = new ArrayList();
if (groupList != null)
{
for (int i=0; i<groupList.length; i++)
{
System.out.println ("group[" + i + "] = " + groupList[i]);
groups.add(groupList[i]);
}
}
}
catch (Exception e)
{
throw new WSLoginFailedException (e.getMessage(), e);
}
}
}
public boolean commit() throws LoginException
{
// (For more information on what to do during commit, see
// Custom login module development for a system login configuration.)
}
private java.util.Map _sharedState = null;
private com.ibm.wsspi.security.token.AuthorizationToken defaultAuthzToken = null;
}
Changing the TokenFactory associated with the default AuthorizationToken
When WebSphere Application Server generates a default AuthorizationToken, the application server utilizes the TokenFactory class that is specified using the com.ibm.wsspi.security.token.authorizationTokenFactory property. To modify this property using the administrative console, complete the following steps:
- Click Security > Global Security.
- Under Additional properties, click Custom properties.
The default TokenFactory that used is called com.ibm.ws.security.ltpa.AuthzPropTokenFactory. This token factory encodes the data, but does not encrypt the data in the AuthorizationToken. Because the AuthorizationToken typically flows over Common Secure Interoperability version 2 (CSIv2) using SSL, there is no need to encrypt the token itself. However, if we need addition security for the AuthorizationToken, one can associate a different TokenFactory implementation with this property to get encryption. For example, if you associate com.ibm.ws.security.ltpa.LTPAToken2Factory with this property, the token uses AES encryption. However, we need to weigh the performance impacts against your security needs. Adding sensitive information to the AuthorizationToken is one reason to change the TokenFactory implementation to something that encrypts rather than just encodes.
If you want to perform your own signing and encryption of the default AuthorizationToken implement the following classes:
- com.ibm.wsspi.security.ltpa.Token
- com.ibm.wsspi.security.ltpa.TokenFactory
Your TokenFactory implementation instantiates and validates your token implementation. Use the LTPA keys that are passed into the initialize method of the TokenFactory or you can use your own keys. If you use your own keys, they must be the same everywhere in order to validate the tokens that are generated using those keys. See the Javadoc, available through a link on the front page of the information center, for more information on implementing your own custom TokenFactory. To associate your TokenFactory with the default AuthorizationToken, using the administrative console, complete the following steps:
- Click Security > Global Security.
- Under Additional properties, click Custom properties.
- Locate the com.ibm.wsspi.security.token.authorizationTokenFactory property and verify that the value of this property matches your custom TokenFactory implementation.
- Verify that your implementation classes are put into the install directory/classes directory so that the WebSphere class loader can load the classes.
See Also
Default PropagationToken
Custom login module development for a system login configuration
Security: Resources for learning