Fix (APAR):  PK13926

Status:  Fix

Release:  6.0.2.5,6.0.2.4,6.0.2.3

Operating System:  AIX,Linux,Solaris,Windows

Supersedes Fixes:  

CMVC Defect:  PK13926

Byte size of APAR:  62418

Date: 2006-01-17

Abstract:  When using custom JAAS module with LTPA token authentication, the system forces the user to reauthenticate if the server that performed the authentication goes down.

Description/symptom of problem:  
 
PK13926 resolves the following problem:

ERROR DESCRIPTION:                                              
WebSphere provides failover support for JAASObjects. Once a user
gets authenticated, the security token is stored inside the     
DynaCache object which is then replicated to the other servers. 
If the next request goes to a different server, the security    
token should get fetched from the dynacache object. The local   
lookup was failing and the security service was doing           
a remote lookup for the Distmap Object. As long as the original 
authenticating server was up the Distmap object was             
found.However, if it is brought down  authentication fails      
completely and user is made to relogin.                         

LOCAL FIX:                                                      
N/A                                                             

PROBLEM SUMMARY

USERS AFFECTED:
All WebSphere Application Server users
who have enabled security and are
utilizing Security and uses custom JAAS
module with LTPA token authentication.

PROBLEM DESCRIPTION:
When using custom JAAS module with
LTPA token authentication, the system
forces the user to reauthenticate if
the server that performed the
authentication goes down.

RECOMMENDATION:
None



When using custom JAAS module with LTPA token authentication,
the system forces the user to reauthenticate if the server
that performed  the authentication goes down. If any other
server goes down, the system fails over correctly.
Security Cache does not failover correctly.

PROBLEM CONCLUSION:                                             
The opaqueToken is the one that contains the entire caller      
Subject, which was not found in the distributed cache.          
As can be seen from the trace, the opaqueToken was not found    
in the distributed, shared cache which is the problem. The      
sso_token was found in the local cache, but that is irrelevant. 
                                                                
Fixed the code and the fix for this APAR is currently targeted  
for inclusion in  fixpack 6.0.2.7. Please refer to the          
Recommended  Updates page for delivery dates:                   
http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP& 
uid=swg27004980                                                 


Directions to apply fix:  
NOTE: Choose the:
1) Release the fix applies to
2) The Editions that apply
3) Delete the Editions & Methods that do not apply and this Note

Fix applies to Editions:
Release 6.0
__ Application Server (Express or BASE)
__ Network Deployment (ND)
__ WebSphere Business Integration Server Foundation (WBISF)
__ Edge Components
__ Developer
__ Extended Deployment (XD)

Install Fix to:
Method:
__ Application Server Nodes
__ Deployment Manager Nodes
__ Both

NOTE:
The user must:
* Have Administrative rights in Windows, or be the Actual Root User in a UNIX environments.
* Logged in with the same authority level when unpacking a fix, fix pack or refresh pack.
* Be at V6.0.2.2 or newer of the Update Installer. This can be checked by reviewing the level of the Update Installer in file <was_root>/updateinstaller/version.txt.

The Update Installer can be downloaded from the following link:
http://www.ibm.com/support/docview.wss?rs=180&uid=swg21205991

For detailed instructions to Extract the Update Installer see the following Technote:
http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg21205400

1) Copy PKxxxxx.pak file directly to the maintenance directory

2) Shutdown WebSphere
Manually execute setupCmdLine.bat in Windows or . ./setupCmdLine.sh in Unix from the WebSphere instance that maintenance is being applied to.

3) Launch Update Installer

4) Enter the installation location of the WebSphere product you want to update.

5) Select the "Install maintenance package" operation.

6) Enter the file name of the maintenance package to install (PKxxxxx.pak file which was copied in the maintenance directory).

7) Install the maintenance package.

8) Restart WebSphere

Directions to remove fix:  
NOTE:
* The user must have Administrative rights in Windows, or be the Actual Root User in a UNIX environments.
* FIXES MUST BE REMOVED IN THE ORDER THEY WERE APPLIED
* DO NOT REMOVE A FIX UNLESS ALL FIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED
* YOU MAY REAPPLY ANY REMOVED FIX

Example: If your system has fix1, fix2, and fix3 applied in that order and fix2 is to be removed, fix3 must be removed first, fix2 removed, and fix3 re-applied.

1) Shutdown WebSphere
Manually execute setupCmdLine.bat in Windows or . ./setupCmdLine.sh in Unix from the WebSphere instance that uninstall is being run against.

2) Start Update Installer

3) Enter the installation location of the WebSphere product you want to remove the fix.

4) Select  "Uninstall maintenance package" operation.

5) Enter the file name of the maintenance package to uninstall (PKxxxxx.pak).

6) UnInstall maintenance package.

7) Restart WebSphere

Directions to re-apply fix:  
1) Shutdown WebSphere.

2) Follow the Fix instructions to apply the fix.

3) Restart WebSphere.



Additional Information: