PQ71399: RETRY FLAG IN SECURITY.XML AND SAS PROPERTIES DOES NOT TAKE EFFECT. | |||||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||||
![]() 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.jarComments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
Publications Referenced
|
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
(C) Copyright IBM Corporation 2000, 2008. All Rights Reserved.