PQ66449: AUTH PRINCIPAL NULLS OUT AND CAUSES AUTHORIZATION FAILURE.

 Fixes are available

4.0.6: WebSphere Application Server Version 4.0 Fix Pack 6
Security; V4.0.2-V4.0.7: Cumulative fix for security component



APAR status
Closed as program error.

Error description
Note from Tom D. at the WCC
.
Trace and this note on wasdoc0.
.
- error occurs on thread 5f8245
- prior authentication checks on this thread have succeeded
- the failure occurs at 13:06:58
- sequence of events:
  - EJSSecurityCollaborator.preInvoke
  - received and invoke creds are both non-null
  - SetUnauthenticatedCredIfNeeded returns false, meaning that
the creds are
    authorized
  - SecurityCollaborator.performAuthorization is called
  - since invokedCred is non-null, curReceived will be set to
the value of
    invokedCred
  - ejbCheckAuthorization is called with curReceived
  - WSCheckAccessManager.checkAccess is called.  One of the args
is a new
    WSPrincipal, which is constructed with the receivedCred.
  - in checkAccess, creds is initialized to null.  If the
principal is
    non-null, then getCredentials will be called on the
principal object.
  - isGrantedAnyRole is called with the creds object.  If the
creds object is
    null, or creds.isUnauthenticated is true, then the error
occurs.  Since
    there is one error message for two possible conditions, we
do not know
    which one triggered the error.  creds can be null if:  1)
the principal
    passed to checkAccess is null.  Then creds will not be set.
2) the call
    to getCredentials on the principal passed in returns null.
  - not sure where the code is for isUnauthenticated, so I do
not know what
    conditions would cause this call to return true.
  * but, upon return to checkAccess from isGrantedAnyRole, a
message is
    printed with the value of principal.toString(), which is
UNATHENTICATED.
    So if the principal is UNAUTHENTICATED, then the call to
getCredentials
    will probably produce null.
.
QUESTIONS:
- why does the same thread seem to be able to create ejbs and
have the
  authentication checks succeed, and then later fail on a
subsequent create
  check?
- from looking at two different traces, it does not appear as if
the failure
  only occurs on one ejb.  So that could rule out a
config/deployment issue.
- does an UNAUTHENTICATED invokeCreds object somehow get
associated with the
  call?  invokedCred is set by a call to
current.get_credentials().
.
At this point, I'm thinking that the call to
current.get_credentials() in performAuthorization is perhaps
not returning the proper credentials, and this leads to the
client appearing as unauthenticated.  But I still do not have
enough evidence to back this up.
Local fix
No workaround available.
Problem summary
****************************************************************
* USERS AFFECTED: WebSphere Application Server users with      *
*                 security enabled and LocalOS as user         *
*                 registry.                                    *
****************************************************************
* PROBLEM DESCRIPTION: The authentication principal is lost    *
*                      which causes authorization failure.     *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
Authentication principal becomes unauthenticated when a valid
uid/password is used.

Actual Exception:
=================
securityName: /UNAUTHENTICATED;accessID: UNAUTHENTICATED is not
granted any of the required roles: XXXXX
 9/24/02 9:23:37:698 EDT    261218 SecurityColla D
Authorization failed accessing EJB
com.ibm.ws.security.core.AccessException:
securityName: /UNAUTHENTICATED;accessID: UNAUTHENTICATED is not
granted any of the required roles:
Problem conclusion
LocalOS credentials were not mapped correctly to the OS user
registry when a web request qas received.  LocalOS
credentials are now correctly mapped.
Temporary fix
available
Comments
APAR information
APAR number PQ66449
Reported component name WEBSPHERE AE SO
Reported component ID 5630A2202
Reported release 400
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Submitted date 2002-09-20
Closed date 2002-10-07
Last modified date 2002-10-07

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros
SECURITY          

SRLS

Fix information
Fixed component name WEBSPHERE AE SO
Fixed component ID 5630A2202

Applicable component levels
R400 PSY    UP


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ66449
IBM Group: Software Group
Modified date: Oct 7, 2002