Before you begin
Prior to completing this task, verify that security propagation is enabled in the administrative console.Why and when to perform this task
With security attribute propagation enabled, you can propagate data either horizontally with single signon (SSO) enabled or downstream using Common Secure Interoperability Version 2 (CSIv2). When a login occurs, either through an application login configuration or a system login configuration, a custom login module can be plugged in to add Java serializable objects into the Subject during login. This document describes how to add an object into the Subject from a login module and describes other infrastructure considerations to make sure that the Java object gets propagated.Steps for this task
public customLoginModule()
{
public void initialize(Subject subject, CallbackHandler callbackHandler,
Map sharedState, Map options)
{
// (For more information on what to do during initialization, see
// Custom login module development for a system login configuration.)
}
public boolean login() throws LoginException
{
// (For more information on what to do during login phase, see
// Custom login module development for a system login configuration.)
// Construct callback for the WSTokenHolderCallback so that you
// can determine if
// your custom object has propagated
Callback callbacks[] = new Callback[1];
callbacks[0] = new WSTokenHolderCallback("Authz Token List: ");
try
{
_callbackHandler.handle(callbacks);
}
catch (Exception e)
{
throw new LoginException (e.getLocalizedMessage());
}
// Checks to see if any information is propagated into this login
List authzTokenList = ((WSTokenHolderCallback) callbacks[1]).
getTokenHolderList();
if (authzTokenList != null)
{
for (int i = 0; i< authzTokenList.size(); i++)
{
TokenHolder tokenHolder = (TokenHolder)authzTokenList.get(i);
// Look for your custom object. Make sure you use
// "startsWith"because there is some data appended
// to the end of the name indicating in which Subject
// Set it belongs. Example from getName():
// "com.acme.CustomObject (1)". The class name is
// generated at the sending side by calling the
// object.getClass().getName() method. If this object
// is deserialized by WebSphere Application Server,
// then return it and you do not need to add it here.
// Otherwise, you can add it below.
// Note: If your class appears in this list and does
// not use custom serialization (for example, an
// implementation of the Token interface described in
// the Propagation Token Framework), then WebSphere
// Application Server automatically deserializes the
// Java object for you. You might just return here if
// it is found in the list.
if (tokenHolder.getName().startsWith("com.acme.CustomObject"))
return true;
}
}
// If you get to this point, then your custom object has not propagated
myCustomObject = new com.acme.CustomObject();
myCustomObject.put("mykey", "mydata");
}
public boolean commit() throws LoginException
{
// (For more information on what to do during the commit phase, see
// Custom login module development for a system login configuration.)
try
{
// Assigns a reference to a final variable so it can be used in
// the doPrivileged block
final com.acme.CustomObject myCustomObjectFinal = myCustomObject;
// Prevents your applications from needing a JAAS getPrivateCredential
// permission.
java.security.AccessController.doPrivileged(new java.security.
PrivilegedExceptionAction()
{
public Object run() throws java.lang.Exception
{
// Try not to add a null object to the Subject or an object
// that already exists.
if (myCustomObjectFinal != null && !subject.getPrivateCredentials().
contains(myCustomObjectFinal))
{
// This call requires a special Java 2 Security permission,
// see the JAAS Javadoc.
subject.getPrivateCredentials().add(myCustomObjectFinal);
}
return null;
}
});
}
catch (java.security.PrivilegedActionException e)
{
// Wraps the exception in a WSLoginFailedException
java.lang.Throwable myException = e.getException();
throw new WSLoginFailedException (myException.getMessage(), myException);
}
}
// Defines your login module variables
com.acme.CustomObject myCustomObject = null;
}
If you are careful adding custom objects and follow all the steps to make sure that WebSphere Application Server can serialize and deserialize the object at each hop, then it is sufficient to use custom Java objects only.
Although you can add custom objects to the propagation exclude list, you must be aware of a side effect. WebSphere Application Server stores the opaque token, or the serialized Subject contents, in a local cache for the life of the single signon (SSO) token. The life of the SSO token, which has a default of two hours, is configured in the SSO properties on the administrative console. The information that is added to the opaque token includes only the objects not in the exclude list.
If your authentication cache does not match your SSO token timeout, you might get a Subject on the local server that is regenerated from the opaque token but does not contain the objects on the exclude list. The authentication cache, which has a default of ten minutes, is configured on the Global Security panel on the administrative console. It is recommended that you make your authentication cache timeout value equal to the SSO token timeout so that the Subject contents are consistent locally.
Result
As a result of this task, custom Java serializable objects are propagated horizontally or downstream. For more information on the differences between horizontal and downstream propagation, see Security attribute propagation.Related concepts
Security attribute propagation
Related tasks
Enabling security attribute propagation
Administering security
Related reference
Security: Resources for learning
Custom login module development for a system login configuration
Default authorization token
Default propagation token