IBM - PK00852: SSO tokens with custom cacheKey from TAI are not handled
correctly: "When using the security attribute propagation token framework or the
cacheKey property within a Hashtable login to affect the custom cache key of a
Subject, an SSO token containing this custom cache key will result in a cache
miss at a backup server. This will cause either a DynaCache hit (if configured)
or an MBean retrieval to get the Subject contents. In cases where the
originating server is down, the LTPA token will be used to login, but it's
unlikely the custom attributes will be preserved in that situation. To
accommodate the behavior of a new challenge whenever these custom attributes
cannot be retrieved, any SSO token containing the custom cache key that cannot
retrieve the originating attributes will, by default, result in a new
authentication challenge. However, there will be a property that can be used to
change to the old login using the token behavior."
Wednesday, January 04, 2006
Missing PDPrincipal with TAI+
We configured websphere trust association with Tivoli Access Manager. It works fine when we tested it with individual logins. But when we tried to load test the authentication and authorization using TAM and TAM's Authorization API , the PDPrincipal of the subject was lost in a significant number of cases. When we contacted IBM about this, they suggested that we apply PK00852 to websphere, which is available from websphere cumulative fix pack 188.8.131.52. Although the fix does not directly address the problem at hand, we could load test TAM authentication and authorization with Azn API successfully. Probably TAI+ creates a custom cache key and modifies the subject with information that cannot be retrieved from the user registry alone. For more on custom JAAS subjects and cache keys in websphere, refer to this article in the WebSphere technical Journal. This is what IBM has to say about the APAR fix mentioned above.