PQ71399: RETRY FLAG IN SECURITY.XML AND SAS PROPERTIES DOES NOT TAKE EFFECT.

 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
Problem:
-------
.
The issue is related to authenticationRetryEnabled and
authenticationRetryCount settings in security.xml file and
sas.client.props file. Customer found that the client was
authenticated twice from the server side when he provided the
wrong password, even if he disabled
the authenticationRetryEnabled flag.
.
Environment:
-----------
.
Win 2K
WebSphere Application Server 5.0 Base
.
Detailed description and workaround from customer:
-------------------------------------------------
.
It 'seems' that when I do a bad userid and password,
authentication happens MULTIPLE times, even though I have set
the retry flags to 0 (in sas.client.props and the security.xml
file on the server side).
.
I first noticed this when I tried a bad password on my own
account; we've a security rule set up in our RACF system that 3
bad password attempts will lock out your account.  I locked it
out once, and then looked thru the logs.
.
I then turned off the retry flags, and still see multiple
authentication attempts.  And, the client side trace can be
checked against the server side traces and you can see these
multiple tries.
.
I think the problem is in two classes:
com.ibm.IsecurityUtilityImpl. CommonSecurityServer and
com.ibm.WebSphereSecurityImpl.SecurityServerImpl
.
Here's the problem:
1) In CommonSecurityServer, the last authenticate method will
call initSecurityServer the first time.  This ends up creating
com.ibm.WebSphereSecurityImpl.SecurityServerImpl by
Class.forName.  The constructor for this class (thru a method
called getSecurityServer) does an InitialContext, and then a
lookup for "SecurityServer".  Both of these cause
authentications with the customregistry.  So, here are two of
the four authentication attempts.
This constructor does NOT throw an exception, so the object
seems to be constructed.  Back in CommonSecurityServer,
securityServer is NOT null.  Here's a screen shot thru WSAD -
the class is being created, where I would imagine that's not
what is expected.
.
2) After this, since the securityServer is not null, the
authenticate method continues on.  The method
simple_authenticate in SecurityServerImpl is called; it in turn
calls getSecurityServer again, which causes the other 2
authentications.
.
From there, I looked into the method getSecurityServer() in
com.ibm.WebSphereSecurityImpl.SecurityServerImpl.  This is where
it does the initialcontext, and then a "securityserver" lookup,
which causes the two exceptions.
.
There are several catch blocks in this code - the catch blocks
do some debug traces, but that's about it.  In each of them, I
threw the exception along, to let the call know about them.
.
In this case, the caller class is
com.ibm.IsecurityUtilityImpl.CommonSecurityServer and the method
is initSecurityServer, which again is creating
SecurityServerImpl with a class.forname().  Now, the exception
will get back to this class, and the attempt to create the
securityServer member will fail, and it will be null.
.
In the authenticate method (which called initSecurityServer), I
would see that securityServer is null, and create an
AuthorizationResult and return.
.
Possible Solution:
-----------------
.
I've got this working now, at least for this problem.
.
1) Changes to com.ibm.IsecurityUtilityImpl.CommonSecurityServer
- added String member variable named mike
- in initSecurityServer(), in the catch block, set mike to
((NoPermissionException)e).getRootCause().getMessage();
- in authenticate, set the auth fail reason to mike, instead of
logmsg.
- I marked the code changes with the comment //mike
.
2) Changes to com.ibm.WebSphereSecurityImpl.SecurityServerImpl
- again, commented additions with //mike
- in getSecurityServer(), on the various catches, throw the
exception so that CommonSecurityServer can deal with it, rather
than doing nothing with it
.
3) changes to
com.ibm.ISecurityLocalObjectBaseL13Impl.LoginHelperImpl
- when creating a LoginFailed exception to throw to the client
application, create it as
new LoginFailed (null, authResult.get_auth_fail_message());
- I only changed some specific code for what I'm seeing in
request_login_controlled - the final method.
- Again, commented as //mike
.
So, with these changes, I still see that I'm authenticating
twice on the server side, but I haven't jarred up the above
changes and stopped and restarted Websphere.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: All WebSphere Application Server users       *
*                 using Java clients with security enabled     *
*                 and disabling authentication retries.        *
****************************************************************
* PROBLEM DESCRIPTION: Authentication retry logic cannot be    *
*                      disabled.                               *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
Authentication retry logic cannot be disabled.  In addition,
any attempt at authentication after a failed attempt results
in a NO_PERMISSION exception.
Problem conclusion
This problem was resolved by adding additional retry logic in
the CredentialManager.  This was resolved in internal defect
155026.
Temporary fix
WAS_Security_02-24-2003_5.0.0_cumulative_fix.jar
Comments
APAR information
APAR number PQ71399
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-02-25
Closed date 2003-03-13
Last modified date 2003-04-30

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 #: PQ71399
IBM Group: Software Group
Modified date: Apr 30, 2003