PM20186: SINGLE SIGN ON MAY FAIL BECAUSE AUTHCACHE REMOVES A CACHE ENTRY WHICH HAS A CUSTOM CACHE KEY

Fixes are available

APAR status

Closed as program error.

Error description

When Trust Association Interceptor (TAI) is enabled, and TAI
adds a custom cache key, Single Sign On to a downstream server
may fail with following error:


[7/29/10 15:43:00:225 EDT] 00000071 ContextManage 3
Exception getting opaque token from originating server.
com.ibm.websphere.security.auth.WSLoginFailedException:
SSO token uniqueID not null, but opaque token not found.  Need
to re-challenge the user to login again.


Note that when this condition happens, there are multiple
clients of which are using the same user id and password to
access the server.

Local fix

Problem summary

****************************************************************
* USERS AFFECTED:  All users of IBM WebSphere Application      *
*                  Server with Trust Association Interceptor   *
*                  enabled                                     *
****************************************************************
* PROBLEM DESCRIPTION: Single Sign On to a downstream server   *
*                      might fail due to missing opaque token. *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
In AuthCache class, there is a code to clean up cache entries
under certain conditions, such as userid/password mismatch.
The issue here is that this removal always happens no matter
how the original cache entries are constructed. Given that,
assuming that there are two clients of which are using the
same user id and password. The server authenticates the first
client, it inserts cache entries with a custom cache key
attached. Then when the second client is being authenticated,
the security code doesn't use the cache entry because the
cache entries, which have the same user id and password have
the custom cache key and it doesn't match. When this condition
happens, the original cache entries are being removed, because
the security code assumes that the reason why the cache entry
isn't hit is that the password has been changed since the last
cache insertion. Then when a servlet which is accessed by the
first client makes a remote EJB call to a downstream server
with Single Sign On token, the downstream server will not be
able to access the orginal authenticated data since the cache
entries are already removed.

Problem conclusion

With this fix, cache entires of which key is a custom cache
key aren't be removed from AuthCache.

The fix for this APAR is currently targeted for inclusion in
fix pack 6.1.0.35 and 7.0.0.15.  Please refer to the
Recommended Updates page for delivery information:
http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980

Temporary fix

Comments

APAR Information

APAR number
PM20186
Reported component name
WEBS APP SERV N
Reported component ID
5724H8800
Reported release
61A
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2010-08-09
Closed date
2010-08-30
Last modified date
2010-08-30

APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:

Fix information

Fixed component name
WEBS APP SERV N
Fixed component ID
5724H8800

Applicable component levels

R61A PSY
UP
R61H PSY
UP
R61I PSY
UP
R61P PSY
UP
R61S PSY
UP
R61W PSY
UP
R61Z PSY
UP
R700 PSY
UP

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"6.1","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
24 October 2021

Tips

PM20186: SINGLE SIGN ON MAY FAIL BECAUSE AUTHCACHE REMOVES A CACHE ENTRY WHICH HAS A CUSTOM CACHE KEY

Fixes are available

Subscribe

APAR status

Closed as program error.

Error description

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

APAR Information

APAR number

Reported component name

Reported component ID

Reported release

Status

PE

HIPER

Special Attention

Submitted date

Closed date

Last modified date

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Fix information

Fixed component name

Fixed component ID

Applicable component levels

R61A PSY

R61H PSY

R61I PSY

R61P PSY

R61S PSY

R61W PSY

R61Z PSY

R700 PSY

Document Information

Share your feedback

Need support?