PQ70395: WAS 5.0 JAAS WSLoginModule not use token authentication data.

 Fixes are available

5.0.1: WebSphere Application Server Version 5.0 Fix Pack 1 (Version 5.0.1)
Cumulative Security Interim fix for V5.0
5.0.1: WebSphere Application Server Enterprise Edition Version 5.0 Fix Pack 1



APAR status
Closed as program error.

Error description
When login with a valid token (LTPA in 5.0), the token
validation fails with the following message:
[11/25/02 15:47:35:625 CST] 4fe2b3fa WSLoginHelper E SECJ4008E:
Missing some of the authentication data
[11/25/02 15:47:35:816 CST] 4fe2b3fa WSLoginHelper E SECJ4001E:
Login failed for  secnt6.austin.ibm.com:389/<null>
org.omg.SecurityLevel2.LoginFailed
Environnment:
   WebSphere Application Server 5.0 AE
   LTPA authentication Mechanism
Description:
Customer has a simple servlet that is mapped to any URL
starting with "/servlet/" . URLs starting with
"/servlet/protected/*" are protected and the login method is
set to Basic. The security is enabled and authentication
mechanism is set to use LTPA with user registry being LDAP.
The servlet performs a login on every request. The user id and
password are hardcoded in the code (for simplicity). However,
if the request is for "/servlet/protected/*" , then it looks
for an LTPA cookie. If that is found on the request,
another login is performed, in order to get the dn of the
user. This last step is where I hit some problems.
Here is the source of the servlet and of a helper class, that
does the login.
(See wasdoc0:\\PMR\00026663649\export_1125a.jar
(See wasdoc0:\\PMR\00026663649\SecurityTestApplication.ear)
(See wasdoc0:\\PMR\00026663649\traceForRequestWithLTPAToke.log)
...
Customerstated that the classes caused the problem are:
WSLoginModuleImpl and WSCallbackHandlerImpl
Test procedures:
- Install SecurityTestApplication.ear.
- From a browser enter request is http:<host>/sta/servlet/aaa ,
the servlet will do a login with the hardcoded credentials.
- From a vrowser enter request for /sta/servlet/protected/aaa;
this is a protected URL and WAS will enforce basic
authentication, when sucessful, the servlet will again do a
login with hardcoded credentials.
- From a browser enter /sta/servlet/secure/aaa ; the servlet
will again do a login with hardcoded credentials but also, in
this case, the servlet will look for LTPA cookie, which should
have been generated by the previous request. When LTPA is found,
another login will be attempted with this LTPA token. And this
is the failing part.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: All WebSphere Application Server users       *
*                 creating JAAS login modules and using the    *
*                 LTPA authentication mechanism.               *
****************************************************************
* PROBLEM DESCRIPTION: WSLoginModuleImpl.login() fails when    *
*                      using LTPA.                             *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
WSLoginModuleImpl.login() fails when using LTPA.  The error
messages received are similar to the following:
[11/25/02 15:47:35:625 CST] 4fe2b3fa WSLoginHelper E SECJ4008E:
    Missing some of the authentication data
[11/25/02 15:47:35:816 CST] 4fe2b3fa WSLoginHelper E SECJ4001E:
    Login failed for someserver.some.domain.com:389/<null>
    org.omg.SecurityLevel2.LoginFailed
The failure was due to the logic failing to use the LTPA token
to validate the login.  Instead, an attempt to use the user ID
and password was done.  However, the user ID and password was
no longer available.
Problem conclusion
This is resolved in internal defect 154797.  The LTPA token is
now used for validating the login.
Temporary fix
WAS_Security_02-24-2003_5.0.0_cumulative_fix.jar
Comments
APAR information
APAR number PQ70395
Reported component name WAS BASE 5.0
Reported component ID 5630A3600
Reported release 00W
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Special Attention NoSpecatt
Submitted date 2003-01-29
Closed date 2003-03-13
Last modified date 2004-06-07

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros
Security          

Publications Referenced

Fix information

Applicable component levels
R003 PSY    UP
R00A PSY    UP
R00H PSY    UP
R00I PSY    UP
R00S PSY    UP
R00W PSY    UP


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s):
Software version: 00W
Software edition:
Reference #: PQ70395
IBM Group: Software Group
Modified date: Jun 7, 2004