The administration server and all application servers and clients which use the Websphere installation directory must be stopped for proper application of this eFix. Important note, if any of the efixes which this eFix supersedes has been applied, this eFix may take an exceptionally long time to install (possibly up to 15 minutes or more depending system speed). For PTF 4.0.2 only, PQ56667 must be applied before this fix is applied. Release: WebSphere 4.0.2 Operating System: All Supersedes eFixes: PQ61779, PQ62538, PQ62684, PQ63116, PQ63574, WAS_Security_09-13-2002_4.0.4-4.0.3_AE_cumulative_eFix and WAS_Security_10-07-2002_4.0.4-4.0.3_AE_cumulative_eFix and WAS_Security_10-31-2002_4.0.4-4.0.3_AE_cumulative_eFix as well as any eFixes for APARs listed below. CMVC defect: See APAR list below Byte size of APAR: 1,423,088 Date: 11/24/2002 Description/symptom of problem: See APAR list below. Directions to apply efix: 1) Create temporary "efix" directory to store the jar file: AIX: /tmp/WebSphere/efix Solaris/Linux: /tmp/WebSphere/efix Windows: c:\temp\WebSphere\efix 2) Copy jar file to the directory 3) Shutdown WebSphere 4) Run the jar file with the following command answering questions/prompts as they appear: java -jar 5) Restart WebSphere 6) The temp directory may be removed but the jar file should be saved. Do not remove any files created and stored in the /WebSphere/AppServer/efix/ directories. These files are required if an efix is to be removed. Directions to remove an efix: NOTE: EFIXES MUST BE REMOVED IN THE ORDER THEY WERE APPLIED. DO NOT REMOVE AN EFIX UNLESS ALL EFIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED. YOU MAY REAPPLY ANY REMOVED EFIX. Example: If your system has efix1, efix2, and efix3 applied in that order and efix2 is to be removed, efix3 must be removed first, efix2 removed, and efix3 re-applied. 1) Change directory to the efix location (/WebSphere/AppServer/efix/). 2) Shutdown WebSphere 3) Run the backup jar file with the following command: java -jar 4) Restart WebSphere Directions to re-apply an efix: Follow the instructions for applying an efix. If the backup files still exist (from the previous efix application), you will be prompted to overwrite. Answer "yes" at the overwrite prompts. Additional Information: ------------------------------------------------------------------ Some systems may encounter an error similar to the following while applying this eFix. 2002/10/04 14:09:47 Command= /opt/WebSphere/AppServer/temp/FixSecurityJar.sh /opt/WebSphere/AppServer 2002/10/04 14:09:48 RC=xxx 2002/10/04 14:09:48 Error 112 -- The return code of xxx is not equal to the expected return code of 0. If you have not applied any of the 4 cumulative security efixes listed below on your system, then you can ignore these error messages in the extractor log. They are harmless and should not cause you any problems. PQ61779, PQ62538, PQ62684 or PQ63116 If you have applied any of the above 4 cumulative security efixes on your system and get these errors when applying a later cumulative security efix, then this would be a valid error. There are two resolutions to this error. The first is to remove this eFix and all previous eFixes in the opposite order they were installed until all of the eFixes listed above have been removed. Then all other eFixes including this one can be reapplied. The error above will still occur during installation but it can be ignored. The second is to follow the steps below. For Windows, execute the following: (Note use _AEs_ instead of _AE_ in commands below on AEs systems.) cd \WebSphere\AppServer bin\setupCmdLine.bat %JAVA_HOME%\bin\jar -xvf WAS_Security_10-31-2002_4.0.4-4.0.3-4.0.2_AE_cumulative_eFix.jar temp\FixSecurityJar.jar %JAVA_HOME%\bin\jar -xvf WAS_Security_10-31-2002_4.0.4-4.0.3-4.0.2_AE_cumulative_eFix.jar temp\FixSecurityJar.bat temp\FixSecurityJar.bat %WAS_HOME% For UNIX systems, execute the following: (Note use _AEs_ instead of _AE_ in commands below on AEs systems.) . bin/setupCmdLine.sh $JAVA_HOME/bin/jar -xvf eFix/WAS_Security_10-31-2002_4.0.4-4.0.3-4.0.2_AE_cumulative_eFix.jar temp/FixSecurityJar.jar $JAVA_HOME/bin/jar -xvf eFix/WAS_Security_10-31-2002_4.0.4-4.0.3-4.0.2_AE_cumulative_eFix.jar temp/FixSecurityJar.sh . temp/FixSecurityJar.sh $WAS_HOME The following properties must be set for PQ56218 to be effective: In the admin.config file: com.ibm.CORBA.ListenerPort=2000 com.ibm.CORBA.SSLPort=2001 com.ibm.CORBA.LSDPort=9000 com.ibm.CORBA.LSDSSLPort=9001 In each of the Application servers system properties: com.ibm.CORBA.ListenerPort=3000 com.ibm.CORBA.SSLPort=3001 Note, each port number must be unique and must not be in use by any other service on the system. To enable PQ63020, set the following property in the admin.config. com.ibm.ejs.security.customregistry.useSecurityName=true Included APARS: APAR: PQ59412 Version: 350 Abstract: PERFORMANCE PROB WITH THE SSOAUTHENTICATOR Error Description: Together with Dennis R we (Ranier D.) discovered a performance problem with the SSOAuthenticator running websphere portal on WAS. The specific details of the analysis are outlined in notes between Rainer and Dennis. Local Fix: No local fix is known. Logically Dependent Apars: Users Affected: All WebSphere Application Server users which have enabled security and are using a Custom Login. Problem Description: Performance improvement for SSOAuthenticator.login(). Recommendation: Problem Summary: A significant amount of time of SSOAuthenticator.login() execution is spent in getSecurityServer(). The result from getSecurityServer() method has not been used since v3.0 and is no longer necessary. Problem Conclusion: The call to this method has been removed. Test Comments: Circumvention: none Temporary Fix: none Comments: APAR: PQ63457 Version: 400 Abstract: ALLAUTHENTICATEDUSERS NOT WORKING FOR ROLE MAPPING Error Description: Environment: WebSphere Application Server (WAS) 4.0.x . Description: Mapping an application role to the AllAuthenticatedUsers role available by checkbox in the security center did not function as prescribed...users were denied access to pages after authenticated succeeded. Local Fix: None Logically Dependent Apars: Users Affected: All WebSphere Application Server users who have security enabled and are using WebSphere Studio Application Developer (WSAD) to create and deploy EARs with security role references. Problem Description: Users given access to a resource via the special role "All Authenticated Users" receive authorization failures. Recommendation: Problem Summary: Users given access to a resource via the special role "All Authenticated Users" receive authorization failures. The reason for this was that WAS erroneously creating empty access ID for special authorization subjects "All Authenticated Users" and "Everyone." These special authorization subjects are not supposed to have access IDs which cause the name to be used as the access ID. Problem Conclusion: Code was added at runtime to recreate the access ID as the name if the supplied ID is empty. Test Comments: Circumvention: Edit the EAR with the AAT and remove the reference to "All Authenticated Users" and "Everyone," then save. Edit it again and re-add the references. Temporary Fix: Contained in security cumulative eFix PQ63457 or more recent. Comments: APAR: PQ63243 Version: 400 Abstract: SECJ0055A: AUTHENTICATION FAILED FOR WRONGUSER ON WAS 4.03 WINDOWS 2000 Error Description: Authorization fails when using a Custom Registry if the implementations of getUniqueUserId() and getUserSecurityName() do not return the same string. Local Fix: Logically Dependent Apars: Users Affected: WebSphere Application Server users who have implemented a custom registry. Problem Description: Authorization from ltpa token may fail if user security name is different from user ID in custom registry. Recommendation: Problem Summary: Custom registry allow that a User ID is different the user's security name, and user ID and user name got mixed. Problem Conclusion: Custom registry allow that a User ID is different the user's security name, and access ID during authorization should be based on user ID. Test Comments: Circumvention: Temporary Fix: A test fix was supplied and verified. Comments: APAR: PQ63574 Version: 400 Abstract: INTERMITTENT AUTHORIZATION FAILURES FOR AUTHENTICATED USERS THAT BELONG TO A ROLE Error Description: Intermittent authorization failures occur for authenticated users who are properly configured for a security role. The customer has discovered that the problem may not be intermittent, and may instead occur on the first web application loaded when starting an application server. The problem seems to occur because for the first web app loaded the user registry value is null on the call to addAuthorizationTable(), so fillMissingAccessIds() does not occur. This results in the roles information not being available when performing authorizations for those roles. . This problem may be the same as the one reported in internal defect 139504. Local Fix: The customer has worked around the problem by building a workaround into the WSAccessManager. They inserted a fix into the constructor whose signature is "public WSAccessManager(RegistryImpl registryimpl)". The fix simply inserts a call to fillAccessIds() to force the authorization information to be loaded. Logically Dependent Apars: Users Affected: All WebSphere Application Server users who have enabled security. Problem Description: Intermitant authorization problems due to improper authorization table initialization. Recommendation: Problem Summary: Intermittent authorization problems due to improper authorization table initialization. The tables were not initialized properly due to the improper use of a boolean value which was used to indicate initialization state of the tables. Problem Conclusion: The boolean value was used at times to indicate a single table had been initialized when it should only be used to indicate all tables had been initialized. This was corrected. Test Comments: Circumvention: Temporary Fix: Contained in security cumulative eFix PQ63457 or more recent. Comments: APAR: PQ66162 Version: 400 Abstract: SERVERSIDEAUTHENTICATOR DOESN'T THROW EXCEPTION Error Description: SSOAuthenticator - When used 1. Authenticates userid and password. 2. Throws exception when authentication fails (works correctly) 3. Set HttpRequest and HttpResponse LPTA cookie so that they can be passed by servlet. 4. DOES NOT SET THE CONTEXT for SAS communication for ejb layer. So the ejb thinks the user is UNAUTHENTICATED and fails. . ServerSideAuthenticator - When used 1. Authenticates userid and password. 2. DOES NOT Throws exception when authentication fails. 3. DOES NOT Set HttpRequest and HttpResponse LPTA cookie so that they can be passed by servlet. 4. Set context for for SAS communication for ejb layer. . So, with this being the case, i have to use 2 separate API to authenticate correctly and set the desired information to enable J2EE security framework. Right now I call ServerSideAuthenticator first then SSOAuthenticator. Seems kind of expensive to me and confusing. . Customer requests a fix for ServerSideAuthenticator for WAS 4.03 on AIX. . When ServerSideAuthentication fails to authenticate, it returns a null credential. Not basic credentials. Second, a client may use ServerSideAuthenitcate for authentication purpose only. They may never go to a secure resource (like ejb) after that. Or my ejb may not be secure....I know that the ejb container will through the error because the user is UNAUTHENTICATED. This is not new to us developers, however, WAS is relying on the Ejb Server Container (security mechanism) to throw the error for simple WAS authentication...Not authorization...this is not correct. Local Fix: none Logically Dependent Apars: Users Affected: WebSphere Application Server users who uses ServerSideAuthenticator to perform authentication. Problem Description: ServerSideAuthenticator should throw LoginFailed when login fails. Recommendation: Problem Summary: ServerSideAuthenticator should throw org.omg.SecurityLevel2.LoginFailed exception when the login fails and the force_authn flag is true instead of returing a null credential. Problem Conclusion: ServerSideAuthenticator will now throw org.omg.SecurityLevel2.LoginFailed exception when login fails. Test Comments: Circumvention: Temporary Fix: Available Comments: APAR: PQ67823 Version: 350 Abstract: FIRST ATTRIBUTE IN DN IS NOT SEARCHABLE EVEN IT SHOULD BE ALWAYS SEARCHABLE Error Description: The problem with using bluepages occurs since the first attribute in DN is not searchable even it should be always searchable. What we are proposing to deal with this kind of directory defects is to search DN after RDN query fails. This way, I do not break current working functionalities, and make some improperly structured directory working with some limitations. Local Fix: none Logically Dependent Apars: Users Affected: WebSphere Application Server security users with LDAP as a user registry when the LDAP schema has an attribute which is not searchable in the DN. Problem Description: Security can not query relative DN from LDAP with if any attributes of the DN are not searchable. Recommendation: Properly configure Ldap to make attributes in DN searchable. This is not a WebSphere defect, and we try give customers with improperly configured ldap some leverages. The support of this kind of ldap is limited, and some functionalities such as SSO with non WebSphere application may loss. The long term solution for this kind of problem is to fix the ldap server to make attributes in DN searchable. Problem Summary: If the first attrribute of the DN is not searchable, WebSphere is unable to query relative DN to perform name normalization. This may be caused by multiple reasons. Secureway 3.2.2, 3.1.1 and possibly other versions have a defect which makes this attribute unsearchable. Some OEM LDAP servers may also have this defect. Also, configuration errors can cuase this issue. Some LDAP servers may need to be configured to make specific attributes searchable. Some LDAP servers are configured to require a Bind DN before certain attributes can be searched as well. Problem Conclusion: If Relative DN is non-searchable, WebSphere will query DN itself and use this result. However, if the Relative DN search fails, and the full DN search is used, SSO may not function with WebSeal or Domino. If this problem occurs, the only resolution is to make the Relative DN searchable. Test Comments: Circumvention: Properly configure the ldap server, and make first attribute in DN searchable. Temporary Fix: test internally Comments: APAR: PQ67828 Version: 400 Abstract: FIRST ATTRIBUTE IN DN IS NOT SEARCHABLE EVEN IT SHOULD BE ALWAYS SEARCHABLE Error Description: Local Fix: Logically Dependent Apars: Users Affected: Problem Description: Recommendation: Problem Summary: Problem Conclusion: Test Comments: Circumvention: Temporary Fix: Comments: APAR: PQ68063 Version: 400 Abstract: HANG WHEN CONFIGURING SSL FOR LDAP WITH VERSION 4.0.3 AND OCT. 7 2002 CUMULATIVE SECURITY EFIX APPLIED Error Description: After installing the Oct. 7, 2002 cumulative security efix on a 4.0.3 system, the customer hangs when trying to configure SSL between WebSphere and the LDAP server. If the customer removes the efix, the customer does not hang when configuring SSL for LDAP. There were no error messages in the trace files. This error was reported on a Solaris 8 machine. Local Fix: No local fix is available for this hang error. Logically Dependent Apars: Users Affected: WebSphere Application Server who have enabled security and configured LDAP over SSL. Problem Description: Failure to configure SSL between WebSphere and LDAP. Recommendation: Problem Summary: WebSphere fails to reload the SSL configuration from the repository during security configuration. This prevents the Security Center GUI from accessing LDAP to validate a user during LDAP configuraion which ultimately causes the new configuration to fail on update. Problem Conclusion: The SSL Configuration is now reloaded from the repository if configuration is changed. Test Comments: Circumvention: Enable security without configure LDAP over SSL. Restart server, and configure LDAP over SSL. Temporary Fix: provided testing and tracing module to customer. Comments: APAR: PQ59263 Version: 400 APAR: PQ56706 Version: 350 Abstract: INDEXOUTOFBOUND ERROR REPORTED BY POL DIRECTOR IF PORT # NOT USE Error Description: tion.jav 23:22:32:390 GMT+01:00 fc4d8e12 WebAuthentica < a:46) . at...." .ava.lang.StringIndexOutOfBoundsException: String index out of range: -1 .pisc.uk.ibm.com (IBM-PROXY-WTE-US), HTTP/1.1 Ajay Reddy and Chunlong are aware of this. This defect has been opened to track this problem to be resolved inthe coming releases.init>(IndexOutOfBoundsExcep Local Fix: None Logically Dependent Apars: Users Affected: WebSphere Application Servers users of Security Trust Association Problem Description: Can not authenticate with TA if port is not in via head, or via contains proxy. Recommendation: specify port number in via head, and do not use proxy. Problem Summary: Security trust association assumed that via head contains one host and one port number only. If via head contains proxy, or via head omit port number, TA did not work. This efix will allow via to contain proxy server, or omit port number. Problem Conclusion: This is VIA head format problem, and we are relaxing format requirement to allow proxy or omit port number. Test Comments: Circumvention: Could be resolved by using the format of host + port. Temporary Fix: Not required by customer. Could be resolved by including port in via head, and not using proxy. Comments: APAR: PQ57066 Version: 400 Abstract: CUSTOMREGISTRY IS INITIALIZED MULTIPLE TIMES WHEN STARTING THE APP SERVER. Error Description: Here are the details from the pmr: . Abstract: Custom Registry inappropriately initialized . System Type: Solaris Operating System: SUN Product Group: WAS AE SUN 400 . Environment: I do not believe this is environment specific, but I have tested only on Solaris. Solaris 2.8, WAS 4.0.1, Oracle 8.1.7, iPlanet Security enabled, using Trusted Associations and Custom Registry . Problem: I have written a custom registry for WAS. The registry is working fine, however I have discovered a problem in WAS that may lead to resource leaks: the registry is being initialize d *4 times* in the app server. This is wrong for two reasons: 1) initing it 4 times is just bizarre 2) the custom registry isn't used by the app server . When I start an admin server, the custom registry is initialized exactly once as I would expect. There are no problems. Every single time I start *any* application server I see the r egistry initialized 4 times. I know this for two reasons: . 1) I have tracing in my registries init() method that outputs informatio n every time init is called. 2) the WAS Audit subsystem prints the following audit message every time the registry is initialized (4 times when starting an app server): . SECJ0136A: Custom Registry com.ibm.swservices.websphere.registry.Mul tiLDAPCustomRegistry has been initialized. The "com.ibm.*.MultiLDAPCustomRegistry" stuff is the name of my registry Local Fix: None. Logically Dependent Apars: Users Affected: WebSphere Application Server security users. Problem Description: Security registry properties are initialized multiple times. Recommendation: Problem Summary: security registry properties are initialized multiple times, and they should only be initialized once. The unnecessary initializations are harmless but can lead to confusion on the part of an implementer of a Custom registry. Initialization should only occur once. Problem Conclusion: A redundant registry initialization call was removed. Test Comments: Circumvention: Temporary Fix: send testing efix to customer. Comments: APAR: PQ57307 Version: 400 Abstract: ISUSERINROLE ALWAYS RETURNS FALSE FOR JSP Error Description: Users attempting to use the isUserInRole method of the HTTPServletRequest object to do authentication are unable to do so in JSP code because the return value is always false. Local Fix: NONE Logically Dependent Apars: Users Affected: WebSphere Application Server users with security enabled, calling isUserInRole from a JSP. Problem Description: Calling isUserInRole() within JSP always return false. Recommendation: Apply efix, or use Servlet instead of jsp to call isUserInRole(). Problem Summary: Calling isUserInRole() with jsp always return false. Problem Conclusion: The problem only happen in jsp(not servlet), and has been corrected. Test Comments: Circumvention: Temporary Fix: send testing efix to customer Comments: APAR: PQ57615 Version: 400 Abstract: ADDING USERS TO ROLES THROUGH BROWSER CONSOLE DOESN'T WORK. Error Description: AEs 4.0.1 Win2000 . When trying to associate Roles with Users or Groups throught the AEs/d Administrative console (browser) the update appears successful but actually fails. Not only does it not create the proper accessId for the user but it also removes the ones which existed before. . Customers ibm-application-bnd.xmi has following entry . This should look like: . This results in an "unauthorization exception" when a user tries to access a web resource where they should have Local Fix: Manually add accessId to xmi file. Logically Dependent Apars: Users Affected: WebSphere Application Server users of enabled security in AEs. Problem Description: Security accessID is not being filled in properly by some tools. Recommendation: apply Efix. Problem Summary: Some assemble / deployment tools do not fill security accessID properly(empty string). It should either fill fully qualified ID, or do nothing. Security runtime will fix the problem by treating empty ID as not ID presented. Problem Conclusion: Security runtime will fix the problem by treating empty access ID as not ID presented, thus will invoke registry to refill the access ID. Test Comments: Circumvention: Temporary Fix: send efix to customer Comments: APAR: PQ58475 Version: 400 Abstract: WASREQURL IS BEING CLEARED WHEN FORM LOGIN USER USES INCORRECT USERNAME/PASSWORD WHEN FIRST LOGGING IN Error Description: Environment: WebSphere Application Server (WAS) 4.0.2 AE . Description: When using form based login, if a user logging in through a form uses an incorrect username/password, the WASREQURL is cleared, so that even if they are asked to login again and use a valid username/password, they won't be redirected to the secured resource they are trying to access in the first place. Local Fix: None Logically Dependent Apars: Users Affected: All WebSphere Application Server users of Form Login for user authentication challenge and LTPA (either LDAP or Custom) for a user registry. Problem Description: URL redirect information is cleared on a failed login. Recommendation: Problem Summary: URL redirect information is cleared on a failed login when using Form Login. This behavior is undefined as to whether or not the information should be cleared or not. However, the behavior is inconsistent between Local OS and LTPA based user registries. The result of the redirect information being cleared is two fold. 1. If the user fails authentication, then uses the browser back button to go back to reauthenticate (which is the intuitive method for a user to use), the user can authenticate but will not be redirected to the originally requested URL. 2. If the Web app designer wants to use the relogin page as an authentication page as well, the same restriction applies. Problem Conclusion: Since the behavior is inconsistent between Local OS and LTPA and it is undefined, the LTPA behavior was changed to match the Local OS behavior as it supplies more function to the user. Test Comments: Circumvention: Temporary Fix: PQ58475-test-4.02.jar Comments: APAR: PQ59461 Version: 400 APAR: PQ58739 Version: 350 Abstract: USER AUTHENTICATION CREATES TWO CREDENTIALS INSTEAD OF ONE. Error Description: WebSphere security performs MapCredentials immediately followed by Validate when a user makes the first request. Both of these calls end up authenticating the same user twice. In particular, the call to getGroupsForUser takes several seconds on each of the two occasions. If we could take away one of these (seemingly redundant) calls (the one made during Validate), this would significantly improve performance for the customer. Local Fix: an efix has been created for the problem ltp-cred-cache-354.jar Logically Dependent Apars: Users Affected: WebSphere Application Servers users of LTPA authentication with custom login. Problem Description: Performance improvement for LTPA authentication with custom login or Form login Recommendation: Apply this efix to improve performance for Ltpa authentication. Problem Summary: This is a performance improvement efix. In this efix, we use credential cache technique to reduce the number of LTPA server calls. For custom/Form login with Ltpa authentication, the number of ldap searches are reduced by half. Problem Conclusion: Unnecessary ldap searches may cause performance problem. Test Comments: Circumvention: Temporary Fix: The efix PQ58739-354.jar is placed in wasdoc0\Apars\PQ58739\3.5.x Comments: The efix has been send to client before the APAR was created, so we rename the efix with Apar name. APAR: PQ53753 Version: 350 Abstract: WAS SECURITY MAKING A REDUNDANT AUTHENTICATION CALL (VALIDATE) Error Description: WebSphere security performs MapCredentials immediately followed by Validate when a user makes the first request. Both of these calls end up authenticating the same user twice. In particular, the call to getGroupsForUser takes several seconds on each of the two occasions. If we could take away one of these (seemingly redundant) calls (the one made during Validate), this would significantly improve performance for the customer. Local Fix: None Logically Dependent Apars: Users Affected: Problem Description: Recommendation: Problem Summary: Problem Conclusion: Test Comments: Circumvention: Temporary Fix: Comments: User authentication creates two credentials when ideally only one should be created. This can cause authentication performance issues if LDAP response times are long. The likely causes of the related performance issues are network problems and LDAP tuning problems. Prior to 3.5.5 APARs PQ48364, PQ52698 and PQ53935 are applicable as well. These are all contained in the cumulative fix for PQ53953 for 3.5.3, 3.5.4 and 3.5.5. APAR: PQ59667 Version: 350 APAR: PQ61779 Version: 400 Abstract: AUTHORIZATION FAILS WITH AN EXTERNALLY CREATED LTPA TOKEN. Error Description: uthorization fails with externally created LTPA Tokens if the access ID string does not match exactly with the ID stored in the WAS authorization tables. Local Fix: none Logically Dependent Apars: Users Affected: WebSphere Application Server users using security and Single Sign On. Problem Description: Authorization fails with externally created LTPA Token. Recommendation: Problem Summary: Authorization fails for externally created Ltpa Token due to an extra space between Relative Disinguished Name and the Base Distinguished Name required by WebSphere security. This is a result of WebSphere using exact name matching. Problem Conclusion: The name used for authorizations is now created internally by WebSphere so the format of the name is consistent with the name stored in the authorization table including the space between the Relative Distinguished Name and Base Distinguished Name. Test Comments: Circumvention: Temporary Fix: Comments: Supplied fix to create access ID from internal registry calls instead of the ID from the externally created LTPA token. APAR: PQ59684 Version: 400 Abstract: WITH SECURITY ON, AND PASSING THE SECURITY CHALLENGE, THE RETURN URL IS NOT CORRECT WHEN THE SERVLET IS IN A SUBDIRECTORY Error Description: The customer requests the following URL: http://mburati02:9080/bowstreet5/webengine/factory/admin/Factory Admin After successfully logging in, it incorrectly redirects to the following mangled URL: http://mburati02:9080/bowstreet5/webengine/factory/admin/Factory Admin/factory/admin/FactoryAdmin Local Fix: Make sure that the requested servlet is accessible from the context root of the webapp. Logically Dependent Apars: Users Affected: WebSphere Application Server developers using Form Login based security. Problem Description: Form login redirection fails when security is enabled. Recommendation: Problem Summary: When Form Login based security is enabled, the originally requested url is not properly sent to the client if the form login page is located in a directory different than the originally requested url. Problem Conclusion: Modified the storing of the originally requested url to properly handle whether the redirect should be relative to the context root of the web module or the web server. Test Comments: Circumvention: Temporary Fix: //wasdoc0/apars/pq59684/4.0.2_4.0.3 Comments: APAR: PQ59959 Version: 350 Abstract: LTPATOKEN COOKIE NOT CREATED FOR THE CERTIFICATION AUTHENTICATION CASE Error Description: Customer has a setup with WAS 3.5.3 where they use Trust Association and users come via TA as well as without going through it. Customer notices significant performance degradation in the case when TA is not used. That seems to be because customer uses certificate authentication and we do not cache certificates. Local Fix: none Logically Dependent Apars: Users Affected: WebSphere Application Server security users of client certificate authentication. Problem Description: Ltpa Token cookie not returned for client certificate authentication. Recommendation: This is a performance APAR. If you are using client certificate, and you also enable SSO, apply this eFix for better performance. Problem Summary: While using client certificate authentication, if SSO is enabled, Ltpa cookie is expected (could be verified from browser). However, ltpa cookie was never returned. Whenever a new request is made, the user is reauthenticated via the user's certificate instead of being validated by an Ltpa Token. The former operation requires user registry calls which can be very time consuming where the latter does not. Problem Conclusion: The expected Ltpa cookie is now returned for client certificate authentication. Test Comments: Circumvention: Temporary Fix: PQ59959-356.jar Comments: a testing eFix for 3.5.6 has been send to customer. APAR: PQ60862 Version: 400 Abstract: WAS 4.0.2 EXPECTS CONFIG FILE TO BE SPECIFIED IN TRUSTEDSERVERS. PROPERTIES EVEN IF THE TA INTERCEPTOR DOES NOT HAVE ADD PROPS Error Description: In WAS 4.0.2 It seems like the trust Association properties are stored in WCCM. IN earlier version i.e 3.5.X the trustedservers.properties was stored in a config file. Local Fix: There is no need to store the Trust Association properties in WCCM, so we will continue to read the properies from trustedservers.properties file as we were doing in ASV356 Logically Dependent Apars: Users Affected: All WebSphere Application Server users implementing a Trust Association Interceptor and not subclassing WebSphereBaseTrustAssociationInterceptor and implementing the init() function. Problem Description: WAS4.0.2 expects Config file to be specified in trustedServers.properties even though the TAI does not have any additional properties. Recommendation: Problem Summary: The problem is that only those Trust Association Interceptors that have additional properties need to specify an additional file in trustedservers.properties. In WAS 4.0.2 the Trust Association properties are stored in WCCM. This was done in such a way that it became necessary to specify an additional file even though the TAI did not have any additional properties to specify. In earlier versions i.e 3.5.X all the properties for Trust Association were read from a file. Problem Conclusion: There is no need to store the Trust Association properties in WCCM. The problem has been resolved by reading the Trust Association properties from a file exactly the same mannor as WebSphere 3.5.6. Test Comments: Circumvention: The customer can simply put any file name for config file in trustedservers.properties file. The customer will need to write an init() method that does nothing. The fix for this problem is in CMVC now and is part of ptf 4 on ASV40X. Temporary Fix: ZE FIX ERROR PQ62438 02/06/27 PQ60862_test.ja r Comments: APAR: PQ60895 Version: 400 Abstract: WASSEC - AUTHENTICATION INFORMATION NOT RETURNED TO THE BROWSER IF A PROTECTED URI IS NOT ACCESSED BEFORE J_SECURITY_CHECK POST. Error Description: If authentication information is posted to j_security_check before a protected URI is accessed, the browser does not receive authentication information and therefore subsequent requests of protected resources fail. Failure stack in app svr stdout (excerpt): ExtendedMessage: Servlet Error: : java.lang.NullPointerException at com.ibm.servlet.personalization.sessiontracking.SessionContext.i sProtoco lSwitch(SessionContext.java:1884) at com.ibm.servlet.personalization.sessiontracking.SessionContext.s houldEnc odeURL(SessionContext.java:1834) at com.ibm.servlet.engine.srt.SRTSessionAPISupport.encodeURL(SRTSes sionAPIS upport.java:137) at com.ibm.servlet.engine.srt.SRTServletResponse.encodeURL(SRTServl etRespon se.java:220) at com.ibm.servlet.engine.webapp.HttpServletResponseProxy.encodeURL (HttpSer vletResponseProxy.java:51) at com.ibm.ws.security.web.FormLoginServlet.formLogin(FormLoginServ let.java :388) at com.ibm.ws.security.web.FormLoginServlet.doPost(FormLoginServlet .java:16 0) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.ibm.servlet.engine.webapp.StrictServletInstance.doService(Se rvletMan ager.java:827) Local Fix: none Logically Dependent Apars: Users Affected: All WebSphere Application Server users using Form Login. Problem Description: The browser failed to receive authentication information when the Form Login page was directly accessed. Recommendation: Problem Summary: The browser failed to receive authentication information when the Form Login page was directly accessed instead of being redirected to the page by attempting to access a protected URI. Problem Conclusion: Test Comments: Circumvention: Temporary Fix: Test fix supplied on 5/22/2002. Comments: APAR: PQ61020 Version: 350 Abstract: WAS 3.5.6 TRUST ASSOCIATION DOESN'T ALLOW OTHER TYPES OF AUTHENTICATION TO WORK Error Description: Environment: WebSphere Application Server 3.5.6 . Description: Customer was using WAS 3.5.3, and when trust association is enabled, they are still able to authentication via other methods (basic, certificate, etc.). After upgrading to WAS 3.5.6, enabling trust association caused any authentication to be treated as if it is coming from WebSeal. As a result, authentication done via basic, certificate, etc. fail because they don't contain the header information that the trust association interceptor expects. Local Fix: None. Logically Dependent Apars: Users Affected: WebSphere Application Server users who enable Trust Association with WebSeal. Problem Description: After Trust Association is enabled with WebSeal, authentication fails if the request is not via WebSeal. Recommendation: Problem Summary: After Trust Association is enabled with WebSeal, authentication fails if the request is not from WebSeal. If the request header contains a 'via' tag (even if this tag has no value), authentication functioned as expected. However, if the 'via' tag was missing, then authentication fails. Problem Conclusion: The WebSeal Trust Association interceptor now checks if the 'via' tag value is not present and treats this condition the same as if the 'via' tag was not present in the request header. Test Comments: Circumvention: Temporary Fix: send a testing eFix to customer Comments: APAR: PQ61868 Version: 350 APAR: PQ62519 Version: 400 Abstract: TRUST ASSOCIATION MUCH SLOWER THAN BASIC AUTHENTICATION IN 3.5.6 Error Description: Customer is hitting URI being served and secured by WAS with more than 100 users within a 2 minute period using WebSeal and Trust Association. They get an average response time of about 54 seconds. However, this time is only 10 seconds when using Basic Authentication without Trust Association. . The security traces seem to show that several seconds are spent in the LTPA Token Validation cache for every hit. Local Fix: None Logically Dependent Apars: Users Affected: WebSphere Application Server security users who uses Trust Association as the authentication mechanism. Problem Description: Trust association authentication is much slower than other authentication. Recommendation: Problem Summary: Trust association is much slower due to the same security credential being created twice. Problem Conclusion: The first credential is now cached so the same crdential can be retrieved from cache to improve performance. Test Comments: Circumvention: Temporary Fix: A test fix was supplied. Comments: APAR: PQ61912 Version: 350 APAR: PQ62438 Version: 400 Abstract: UNABLE TO LOGIN TO WEBSPHERE PORTAL SERVER WITH A USER ID BELONGING TO A DBCS IN ACTIVE DIRECTORY. Error Description: Customer running WebSphere Application Server 3.5.4 with Active Directory as LDAP. Logging in to WebSphere Portal Server fails when login ID is a user in a double byte character set (DBCS) Organizational Unit (when OU is in Japanese). Customer is able to login if the user belongs to an OU that is in English or other single byte character set. Local Fix: No known workaround. This is a problem in both WebSphere Security code and Portal Server code. This APAR is for the WebSphere Security portion. Logically Dependent Apars: Users Affected: WebSphere Application Server security users which have used double byte characters in security names. Problem Description: Authorization fails when a login user name contains double byte characters. Recommendation: Problem Summary: If a user tries to login WebSphere with a name containing double byte characters, the user receives authorization failure error messages. Problem Conclusion: The problem is caused by incorrect internal data conversion of double byte characters to byte arrays. Test Comments: Circumvention: Temporary Fix: A test fix was supplied. Comments: APAR: PQ62260 Version: 400 Abstract: OUT OF MEMORY CONDITION WHEN WAS R403 IS UNDER HEAVY LOAD WITH SECURITY ENABLED Error Description: Customer using a CustomRegistry and running a load test with 100 stress clients that do the following: - authenticate using a Trust Association & the custom registry - fetch a single JSP page - pause 10 seconds - leave the site. NO LOGOUT - repeat The clients use userids out of a possible population of about 10,000 userids. Thus, over a reasonable period of time, WAS will see 10,000 unique userids. The admin server, over a long period of time, logs out of memory errors. In this case, it took 4 hours. Local Fix: none. Logically Dependent Apars: Users Affected: All WebSphere Application Server users who have enabled security using LTPA authentication. Problem Description: Slow performance and high CPU usage during security cache cleaning cycles and possible OutOfMemoryExceptions. Recommendation: Problem Summary: Slow performance and high CPU usage during security cache cleaning cycles and possible OutOfMemoryExceptions. These issues are seen on servers with a large number of different users (12000 on the reported system) accessing the system within the security cache timeout period. The performance problem was a result of the cache cleaning algorithm which evaluated each cache entry as to whether or not it needed to remain in the cache. The out of memory condition was a result of the algorithms failure to remove cache entries. Problem Conclusion: The cache cleaning algorithm was changed to evaluate all cache entries inserted into the cache within a similar time period (one half the security cache timeout) at the same time. The new algorithm guarantees that the vast majority of entries will stay in the cache for the minimum of the security cache time out. There is now the potential for a small number of cache entries to be flushed from the cache early or for a cache miss to occur when there should have been a hit. This is negligible in comparison to the amount of time saved in cache cleaning, however. Test Comments: Circumvention: Temporary Fix: Comments: APAR: PQ62459 Version: 400 Abstract: TRUST ASSOCIATION DOESN'T EXECUTE CLEANUP() WHEN IT IS UNLOADED Error Description: Environment: WebSphere Application Server 4.0.2 AE . Description: Customer discovered that when using Trust Association, the cleanup() method call is never called. It is expected to be called when the Trust Association Interceptor is unloaded. Local Fix: A workaround is to implement a finalize() class in the Trust Association Interceptor class. For example: . protected void finalize() { cleanup() } Logically Dependent Apars: Users Affected: WebSphere Application Server security users using Trust Association as an authentication mechanism. Problem Description: The cleanup() method in the trust association interceptor is not invoked. Recommendation: Problem Summary: The cleanup() method in trust association interceptor is not invoked when application server is stopped. Problem Conclusion: Placed cleanup() call for trust association interceptors in in code executed during application server shutdown. Test Comments: Circumvention: Temporary Fix: provided test eFix. Comments: APAR: PQ62577 Version: 400 Abstract: WILD CARD CHARACTERS ARE NOT TREATED PROPERLY. Error Description: Wild card characters are not treated properly in the user name at login time. for example: User ID Adm* Password nataraj can get you into WAS. Can reproduce this on DOMINO LDAP or Secureway directory. Local Fix: none. Logically Dependent Apars: Users Affected: WebSphere Application Server users who use LDAP user registry in authentication. Problem Description: Wild card characters in a user name are not treated properly. Recommendation: Problem Summary: An "*" represent any character in LDAP if not escaped. WebSphere did not escape any "*" in a user's name. It is important to note that unless the user has only one match in the registry when the "*" is treated as a wild card, the user will be refused authentication. The users password must still be correct as well. Problem Conclusion: WebSphere security will escape "*" if user name contains "*" in our Ldap registry implementation, and ldap filter will check a value with the character "*", rather than treat "*" as any character. Test Comments: Circumvention: Temporary Fix: provided testing eFix Comments: APAR: PQ62684 Version: 400 Abstract: CREATE ACCESSID AT RUNTIME IF THEY HAVE NOT BEEN CREATED. Error Description: Customer is adding to Role Group Roles using WSCP, WSCP did not create and AccessID in the process. The results are authorization exceptions when using the group. Local Fix: Manually add Roles to Group Roles through the AAT tool but this is too manual a process due to the large volume of users and nodes etc. Logically Dependent Apars: Users Affected: All WebSphere Application Server users adding groups to Roles via WSCP. Problem Description: Authorization failures for members of groups that were added to a Role via WSCP. Recommendation: Problem Summary: Authorization failures for members of groups that were added to a Role via WSCP. The problem stemmed from the fact that WSCP was not inserting an access ID for the group, which is used internally by WebSphere for authorization, into the Role. Problem Conclusion: The security runtime now creates an access ID if it is missing. Test Comments: Circumvention: Use the AAT or the Administration Console. Temporary Fix: testing eFix was send to customer. Comments: APAR: PQ63020 Version: 400 Abstract: ADD FUNCTIONALITY TO TOGGLE GETREMOTEUSER() TO RETURN ACTUAL USER ID INSTEAD OF THE DISPLAY NAME WHEN USING CUSTOM REGISTRY Error Description: Environment: WebSphere Application Server 4.0.3 AE . Description: Customer is implementing LTPA custom user registry. When they perform getRemoteUser() or getPrincipalName() mathods, they get the display name (as a result of getUserDisplayName() method call) instead of the actual user ID, and there seems to be no alternative to acquire the user ID when the getUserDisplayName() is implemented to return other than the user ID. The developer suggests creating a configuration item to toggle getRemoteUser() to return the user ID instead of the display name. Local Fix: None Logically Dependent Apars: Users Affected: WebSphere Application Server users who use custom registry authentication. Problem Description: Wehn using a custom registry, the API getRemoteUser() returns display name rather than security name. Recommendation: Apply this eFix, or use the display name as the same as the security name. Problem Summary: When using a custom registry implementation, security returned the user's display name for getRemoteUser() and getPrincipalName() instead of the user's security name. Problem Conclusion: If getRemoteUser() and getPrincipalName() are required to return the user's security name, a system property has been added to enable this. com.ibm.ejs.security.customregistry.useSecurityName=true Test Comments: Circumvention: Temporary Fix: test eFix provided. Comments: APAR: PQ68148 Version: 400 APAR: PQ65884 Version: 350 Abstract: REQUESTDISPATCH.FORWARD() TO A PROTECTED SERVLET FAILS Error Description: . Failing on security when doing requestdispatch.forward() to a protected servlet (and now failing) from the "baseLogon" servet that calls SSOAuthenticator. After calling SSOAuthenticator, the request thread should have a security context established and should not fail on the requestdispatch.forward() call. Local Fix: Test efix PMR81595-356-test-0829 fixed the customer's problem. Need official efix. Logically Dependent Apars: Users Affected: All WebSphere Application Server users who have enabled security. Problem Description: Users may not be properly challenged while accessing secured resources. Recommendation: Problem Summary: Authenticated user may get challenged again, or unauthenticated user may not be challenged as authentication was not properly flaged. This scenario is only likely to occur if a servlet forwards or dispatches to another secured servlet. Problem Conclusion: The flag used to determine authentication was not used correctly. The flag has now been removed as it is redundant. Test Comments: Circumvention: Temporary Fix: test eFix has been send to customer Comments: APAR: PQ66136 Version: 400 Abstract: SSO (SINGLE SIGNON) FROM WEBSPHERE APPLICATION SERVER (WAS) TO DOMINO SERVER FAILS WHEN THE USER NAME CONTAINS DBCS Error Description: With user info( such as first name or last name) in DBCS chinese characters, after login to the WPS or WAS successfuly, then when access the domino web server, domino will challege the user with a login page with error msg "Your session with the server has expired or is invalid". But when SSO from one WPS server to the other WPS server or SSO from one WAS server to the other WAS was fine. when the user info totally in english charcters (SBCS), the SSO from WAS or WPS to domino is fine, and so do from domino to WAS/WPS is fine. The problem only happens when user info has chinese field ( uid is in english, but first name or last name is in chinese DBCS chars ). . WAS Change Team (L3) supplied an efix and it fixed the problem. . The root cause for this defect is that WebSphere and Domino calculate digital signature differently if user name contains dbcs. While converting user name to byte array to calculate digital signature,websphere treated every character as single byte character. With this fix, Websphere is now using UTF8 to calculate digital signature. Local Fix: request a copy of the efix from WAS C/T. Logically Dependent Apars: Users Affected: WebSphere Application Server security customers who use double byte characters in user's security name. Problem Description: SSO between WebSphere and non WebSphere products(such as Domino) fails if user security name contains double byte characters. Recommendation: Problem Summary: SSO between websphere and non WebSphere products fails if security name contains double byte character. The root cause is was a difference in algorithms used to create digital signatures. Problem Conclusion: Change WebSphere security to follow UTF8 conversion rule to calculate digital signature. First using UTF8 rule to convert user name to a byte array, then caclulate digital signature from the byte array. Test Comments: Circumvention: Temporary Fix: provide test eFix Comments: APAR: PQ66082 Version: 350 Abstract: SSO FAILS FOR DBCS USERNAME FOR WAS 3.5.6 Error Description: Customer found their WPS/Domino could perform SSO while uid is in English characters, but could not do SSO while uid is in DBCS Chinese. Local Fix: none Logically Dependent Apars: Users Affected: WebSphere Application Server security users whose security name contains double byte characters Problem Description: SSO fails if security name contains double byte characters. Recommendation: Problem Summary: SSO fails for security names containing double byte characters due to incorrect LTPA Token. The first problem is that double byte character was treated as single byte character during encryption and decryption. The second problem is digital signature is incorrectly calculated by assuming all characters are single bytes. So user data and digital signature are incorrectly mapped. Problem Conclusion: Use UTF8 rule while converting user data to byte array, and also using UTF8 to reverse byte array to string. Test Comments: Circumvention: Temporary Fix: send testing eFix Comments: APAR: PQ66190 Version: 400 Abstract: PROPFILEPASSWORDENCODER COMMAND CAUSES PROPERTY FILES' OWNERSHIP AND PERMISSIONS TO CHANGE TO THAT OF THE USER RUNNING THE SCRIPT Error Description: Environment: WebSphere Application Server 4.0.3 AE for Solaris . Description: Running the PropFilePasswordEncoder.sh command causes the user/group ownership and permissions to change to the default settings for the user running the script. Local Fix: Change ownership and permissions back after running the command. Logically Dependent Apars: Users Affected: All WebSphere Application Server users of PropFilePasswordEncoder script Problem Description: PropFilePasswordEncoder command causes property files' ownership to change Recommendation: Problem Summary: After running PropFilePasswordEncoder script, the user and group ownership and the file permissions of those files changed to the default settings for the user running the PropFilePasswordEncoder script. Problem Conclusion: The way of how backup files are generated is modified, so the original property files can keep their original file permissions. Test Comments: Circumvention: Temporary Fix: Available Comments: APAR: PQ66857 Version: 400 Abstract: GETSSOCOOKIEVALUE WHICH WAS (IN WAS 4.0.3 AND 4.0.2) LOCATED IN CLASS SSOAUTHENTICATOR, WAS REMOVED. CUSTOMERS WANT IT BACK. Error Description: Customer was asking the method getSSOCookieValue which was (in WAS 4.0.3 and prior releases) located in class SSOAuthenticator, has "vanished" from WAS 4.0.4. I checked the class shipped with WAS 4.0.4 and there is no getSSOCookieValue method. Did find external documentation for this API. Customers are using it, please add it back in. Local Fix: none. Logically Dependent Apars: Users Affected: All WebSphere Application Server users who have a servlet which invokes SSOAuthenticator.getSSOCookieValue() Problem Description: SSOAuthenticator.getSSOCookieValue() was removed. Recommendation: Problem Summary: SSOAuthenticator.getSSOCookieValue() was removed. This was legacy 3.0.2 code which should not have been in use. This method was never really intended for customer use. However, it is documented externally and was still functional until it was removed. It was removed due to performance issues that initialization related to it causes. Problem Conclusion: SSOAuthenticator.getSSOCookieValue() was re-added and initialization specific to this method was moved to a code path that only impacts users of this method. Test Comments: Circumvention: Temporary Fix: Testfix is available. Comments: APAR: PQ66923 Version: 400 Abstract: USING ONE COMMON PROXY ID FOR ALL SESSIONS CAUSES SESSION TIMEOUT FOR ALL SESSIONS WHEN ONE SESSION LTPATOKEN TIMESOUT. Error Description: Customer's concern are as follows:ls :D: 1597969914 ,.java:1155) .SAS0130E: Client credentials were not valid. Restart thee , Session timeout for one session throws away the LTPAToken and5)n customer is not able to determine which session got timedout.Fir Hence does not know which session to re-authenticate.e cliented. and/or server to ensure that you are using new credentials. espo Once credentials are marked invalid, they cannot become valided. again.02 10:02:24:131 EDT 1736f98c SystemOut U 1>n) .2002-09-23 10:02:24.109 , ServerID: 289231329 ,14 ,tendedServe Local Fix: Changed LTPAToken Timeout to 24 hours so the token expires around midnight. Logically Dependent Apars: Users Affected: WebSphere Application Server users with security enabled. Problem Description: Invalid credentials were not properly removed from the cache. Recommendation: apply the eFix. Problem Summary: Invalid credentials were not removed from the cache. Symptoms include server credentials failing to refresh or users not being able to aceess protected resources. Problem Conclusion: Remove all expired security cache. Test Comments: Circumvention: Temporary Fix: testing eFix is provided. Comments: APAR: PQ66974 Version: 400 Abstract: GETCALLERPRINCIPAL() SHOULD JUST ALWAYS RETURN "UNAUTHENTICATED" Error Description: Customer sent the following: We have a distributed log viewer servlet architecture, which means each AppServer must have a Servlet to read log file and present it to the end user. . So we must know how to invoke this servlet before it is serviceable(choosable from a drop down list). In the servlet init() method, we probe WebSphere servlet engine configuration to obtain HTTP port number for the hosting AppServer. Then the user can pick a LogViewer and invoke it based on this information. . The available LogViewer Tracking EJB has to be invoked from the init() method in this sense, so in the serlvet init() we will perform following execution: . try { /** retrieve the collection of application server adapters, retrieve configuration information from servlet engin */ String adapterName = SystemProperties.get("LOGSERVER_ADAPTER"); LogServerAdapter adapter = . (LogServerAdapter)Class.forName(adapterName).newInstance(); . LogServer myLogServer = adapter.getLocalLogServer(); m_logServerManager = CoreManagerFactory.getLogServerManager(); /** first, see if the log server is already in the database */ Collection logServers = m_logServerManager.getLogServers(); for (Iterator it = logServers.iterator(); it.hasNext(); ) { LogServer logServer = (LogServer)it.next(); if (myLogServer.getHost().equalsIgnoreCase(logServer.getHost()) && myLogServer.getPort() == logServer.getPort()) { m_logServerID = logServer.getID(); break; } } if (m_logServerID == null) { /** did not find my log server in the database, create a new record */ m_logServerID = m_logServerManager.createLogServer(myLogServer); } } catch (Exception e) { m_cat.l7dError(CoreEjbBundleKey.DEFAULT, e); } . And in our LogServerManager EJB, it is plain DB persistence stateless session bean. createLogServer() is just an insert statement, while getLogServerManager() is simple select statement. As we have an abstract OR layer, I just provide the functionality of these methods here. . In our EJB, we have logging system, which will always capture user's caller information at the begining of the method and push it down to the underneath logging system. So whenever there is exception and it needs logging, the logging system can always write down the caller infomation transparently. Logging system is based on Log4j. . createLogServer(Object value) { // this method internally will keep track caller info, it is pushed down to the logging system, which is defined in a parent EJB class methodStart("createLogServer", value); try { // operations; } catch(Exception e) { // whenever we want to log the exception, we retrieve back the caller info directly from logging system // so the api is ignorant of it is inside EJB or Servlet logging(e); } finally { // we will pop up the caller info from the logging system methodFinish(); } } . This model is applied to every single EJB in our system, and it will fail in the methodStart() invokation for requests initiated from init() of a servlet. . private void methodStart(String methodName, Object params) { m_strCurrentMethod = methodName; m_params = params; . if (m_sessionContext != null) NDC.push(m_sessionContext); . Category cat = getCategory(); if (cat != null && cat.isDebugEnabled()) { StringBuffer buf = new StringBuffer(100); buf.append("ENTER: "); buf.append(getMethodNameWithParams()); cat.debug(new String(buf)); } } . In the NDC.push(): public static void push( javax.ejb.EJBContext theContext { push( theContext.getCallerPrincipal() ); } . NDC class is used for: The NDC class implements nested diagnostic contexts as defined by Neil Harrison in the article "Patterns for Loggin Diagnostic Messages" part of the book "Pattern Languages of Program Design 3" edited by Martin et al.

A Nested Diagnostic Context, or NDC in short, is an instrument to distinguish interleaved log output from different sources. . This problem applies to all EJBs that will track caller and being invoked from init() method of servlets. Local Fix: None Logically Dependent Apars: Users Affected: WebSphere Application Server 4.0 security users who use programmatic security. Problem Description: If the anonymous principal is propagated or the user identity is missing, getCallerPrincipal() returns inconsistant results. Recommendation: Problem Summary: getCallerPrincipal() returns different results in different timing if the anonymous principal is propagated or caller identity is missing. EJB 1.2 spec define that getCallerPrincipal() should always return container specific unauthenticated principal. Problem Conclusion: getCallerPrincipal() should return "UNAUTHENTICATED", the WebSphere specific unauthenticated principal, if caller identity is missing or the anonymous principal is propagated. Test Comments: Circumvention: Temporary Fix: send testing eFix to customer. Comments: APAR: PQ67062 Version: 400 Abstract: DO NOT RE-VALIDATE GROUP DN IF DN COMES FROM LDAP Error Description: In Ldap, group memberships for each user are stored and retrieved as valid Distinguish Name in Ldap. After finding user's group memberships, there is no necessary to re-validate each group against Ldap server. By not re-validating each group, there are two benefits, one has performance improvement in particular i.e if a user belongs to too many groups, WAS does not have validate against each group. The other is not to validate groups to which user belongs but not used by WebSphere security. Local Fix: none Logically Dependent Apars: Users Affected: WebSphere Application Server security users using LDAP registry. Problem Description: WebSphere performs unnecessary group Distinguish Name validation. Recommendation: Problem Summary: WebSphere revalidates group DN returned from LDAP. In LDAP, group memberships for each user are strored and retrieved as valid Distinguish Names. After findind a user's group memberships, it is not necessary to re-validate each group against the LDAP server. By not re-validating each group, there are two benefits, one has performance improvement in particular if a user belongs to too many groups, the other is not to validate groups to which user belongs but not used by WebSphere security. Problem Conclusion: Group DNs returned from LDAP are now not validated. Test Comments: Circumvention: Temporary Fix: provide both working-around, and testing eFix to customer. Comments: APAR: PQ67391 Version: 400 Abstract: SECURITY COMPONENT WON'T TAKE FULL LDAP NAME. Error Description: We have developed an application that requires Group/Role Mappings. The Groups are contained in the LDAP directory and are referenced by DN of type: "cn=GroupName, o=infoscore,c=de". We can install the application in the Admin Console GUI and setup the mappings, using the User/Role Mappings dialog. . In our application 3 Roles are defined, which are mapped to the following groups . Role Users/Groups . ISSAdmin cn=AdminISSGroup, o=infoscore,c=de VendorAdmin cn=AdminGroup,ou=IBD, o=infoscore,c=de cn=AdminGroup,ou=ICD, o=infoscore,c=de ISSAdminBatch cn=AdminISSBatchGroup, o=infoscore,c=de . Once the roles have been setup in the AdminConsole, I can then see the mappings in the WSCP as follows: . wscp> SecurityRoleAssignment getGroupRoleMapping /EnterpriseApp:admin/ {ISSAdmin cn=AdminISSGroup, o=infoscore,c=de} {VendorAdmin cn=AdminGroup,ou=IBD, o=infoscore,c=de} {VendorAdmin cn=AdminGroup,ou=ICD, o=infoscore,c=de} {ISSAdminBatch cn=AdminISSBatchGroup, o=infoscore,c=de} . However, when we try to set up the mappings using WSCP, it does not work. Here is an example of how we attempt to set up one of the mappings in WSCP: . wscp> SecurityRoleAssignment addGroupRoleMapping /EnterpriseApp:admin/ -grouproles {ISSAdmin cn=AdminISSGroup, o=infoscore,c=de} WSCP0038E: Invalid attribute format : ISSAdmin cn=AdminISSGroup, o=infoscore,c=de . The installation procedure for our production system requires that we use the WSCP, so that this task can be scripted. Therefore, it is essential that we are able to setup our User/Role mappings in WSCP. . This was the problem as described by customer. . I then suggested customer to issue the command as follows: . wscp> SecurityRoleAssignment addGroupRoleMapping /EnterpriseApp:admin/ -grouproles {ISSAdmin {cn=AdminISSGroup, o=infoscore,c=de}} . and install apar PQ60772, since the apar description seemed to match the issue. . It was after installing this apar that customer got a different error: . From customer: . Installing PQ60772 hasn't solved the problem. I am now getting a different error: . wscp> SecurityRoleAssignment addGroupRoleMapping /EnterpriseApp:admin/ -grouproles {ISSAdmin {cn=AdminISSGroup, o=infoscore,c=de}} java.lang.NullPointerException at com.ibm.xmi.xmi2.impl.XMI2WriterImpl.writeFeatures(XMI2WriterImp l.java:3 07) . With regards to the use of short names, customer must use full names. . From customer: . Unfortunately for us, we must use the full DN. Standard LDAP configuration does not include a short name for groups. In particular, in one of the examples I showed you, the use of short names would not solve the problem. In order to distinguish both of the groups (AdminGroup) in this example we must use the full DN: . {VendorAdmin cn=AdminGroup,ou=IBD, o=infoscore,c=de} {VendorAdmin cn=AdminGroup,ou=ICD, o=infoscore,c=de} Local Fix: Use shortname, but which is unacceptable for this customer. Logically Dependent Apars: Users Affected: WebSphere Application Server security users who use WSCP to assign group DN to roles Problem Description: WSCP fails to assign group DNs to a security role. Recommendation: Problem Summary: WSCP cannot assign groups to security roles if the given group name is DN(distinguished name) instead of single attribute value. Problem Conclusion: Modify Ldap registry implementation in security to accept both DN and short name as groups search pattern. Originally, only short name was acceptable search pattern. Test Comments: Circumvention: use short name. Temporary Fix: provide testing eFix. Waiting for feedback. Comments: APAR: PQ67473 Version: 400 Abstract: % SIGN IN THE USER CREDENTIALS IS CORRUPTED WHEN PASSED THROUGHTHE GETUSERPRINCIPAL CLASS Error Description: custom tion Description Form based security using er uses is a \242 (cent sign). When passed to getUserPrincipal, .ustomer programmatically checks security with user name goes in as usercompany, and comes back from the .etUserPrincipal API. For business reasons, customer uses a method as usercompany. This worked under .egistry to store usernames as weblogic :) and they want it to work the same under websphere. Problem Summary The security check passes OK, but the delim the Local Fix: None Logically Dependent Apars: Users Affected: WebSphere Application Server users with security enabled. Problem Description: Unicode character in the principal name gets changed after login with SSOAuthenticator. Recommendation: Problem Summary: When using unicode characters in the principal name, the principal name gets changed with an extra character in front of the unicode character when getUserPrincipal().getName() is called after login. Problem Conclusion: Inconsistent encoding was used when we convert bytecode to string and back. UTF8 should be used. Test Comments: Circumvention: Temporary Fix: available Comments: APAR: PQ67679 Version: 400 Abstract: WASSEC - ADDS TAI CAPABILITY TO PQ63020 Error Description: Customer installed Websphere PTF4 to WAS 4.03. Found out that function fixed by previous efix PQ63020 was unavailable. The cause of the failure appears to be TAI. Local Fix: none Logically Dependent Apars: Users Affected: WebSphere Application Server security users who use programmatic security with Trust Association and Custom Registry. Problem Description: Wehn using a custom registry with trust association, the API getRemoteUser() returns display name rather than security name. Recommendation: Apply this eFix, or use the display name as the same as the security name. Problem Summary: When using a Custom Registry implementation, security returns the user's display name for getRemoteUser() and getPrincipalName() instead of the user's security name. Problem Conclusion: If getRemoteUser() and getPrincipalName() are required to return the user's security name, a system property has been added to enable this. com.ibm.ejs.security.customregistry.useSecurityName=true Test Comments: Circumvention: make display name the same as security name Temporary Fix: testing eFix provided Comments: APAR: PQ67926 Version: 400 Abstract: CANNOT START THE ADMIN SERVER WITH A USER ASSIGNED TO ADMIN ROLE Error Description: Problem Reported: Cannot start the admin server with a user assigned to Admin Role: . performed the following steps: . 1.uninstalled WAS 2.dropped and recreated the admin database 3.deleted /usr/WebSphere/AppServer 4.installed WAS 4.0 5.installed PTF 2 6.started WAS 7.configured Security to use IBM bluepages as LDAP server . 8.stopped WAS 9.started WAS 10.Added user cdsharp@us.ibm.com to admin role 11.stopped WAS 12.installed PTF 4 13.started WAS 14.Admin. Server failed to start. Generated secuirty related errors in tracefile. 15.edited sas.server.props file. Set com.ibm.CORBA.securityEnabled=false 16.connected to the admin repository database and set securityenabled =0 17.(db2 "update ejsadmin.securitycfg_table set securityenabled =0") restarted WAS 18.Admin. Server started 19.connected to server with admin client and used the security center to remove the cdsharp entry from the admin role. 20.enabled security 21.stopped WAS 22.admin. server started with no errors connected to server with admin. client (received logon prompt) Local Fix: Workaround: . Disable security in DB2 Start adminserver and admin console Remove all users from admin role Re-enable security Shut down and restart WAS Adminserver should come up. Logically Dependent Apars: Users Affected: All WebSphere Application Server users who have enabled security and have invalid users listed in the Administrative Role. Problem Description: If an ID which is not valid in the user registry is referenced in the Administrative Role, the Administration Server will not initialize. Recommendation: Problem Summary: If an ID which is not valid in the user registry is referenced in the Administrative Role, the Administration Server will not initialize. The problem stems from the user registry returning a null instead of returning a valid access ID. Errors similar to the following will be encountered. 11/18/02 15:12:24:621 CST 6097e07e Initializer X SECJ0007E: Error during security initialization. Exception null at location: java.lang.NullPointerException at com.ibm.ejs.models.base.bindings.applicationbnd. impl.SubjectImpl.equals(SubjectImpl.java:30) at com.ibm.etools.emf.ref.impl.OwnedListImpl. indexOf(OwnedListImpl.java(Compiled Code)) at com.ibm.etools.emf.ref.impl.OwnedListImpl. duplicate(OwnedListImpl.java(Compiled Code)) at com.ibm.etools.emf.ref.impl.OwnedListImpl. duplicate(OwnedListImpl.java(Compiled Code)) at com.ibm.etools.emf.ref.impl.OwnedListImpl. add(OwnedListImpl.java:48) at com.ibm.ejs.models.base.bindings.applicationbnd.gen. impl.UserGenImpl$User_List.add(UserGenImpl.java:31) at com.ibm.ejs.security.Initializer. bindServerIdToAdminApp(Initializer.java:503) at com.ibm.ejs.security.Initializer. initialize(Initializer.java:220) at com.ibm.ejs.security.Initializer. serverStarted(Initializer.java:136) at com.ibm.ws.runtime.Server. fireServerStarted(Server.java:2018) at com.ibm.ws.runtime.Server. fireServerStarted(Server.java:2011) at com.ibm.ejs.sm.server.AdminServer. initializeRuntime0(AdminServer.java:1144) at com.ibm.ws.runtime.Server. initializeRuntime(Server.java:884) at com.ibm.ejs.sm.server.AdminServer. main(AdminServer.java:392) at java.lang.reflect.Method.invoke(Native Method) at com.ibm.ws.bootstrap.WSLauncher. main(WSLauncher.java:158) . 11/18/02 15:12:24:711 CST 6097e07e Initializer X SECJ0007E: Error during security initialization. Exception null at location: java.lang.NullPointerException at com.ibm.ejs.models.base.bindings.applicationbnd. impl.SubjectImpl.equals(SubjectImpl.java:30) at com.ibm.etools.emf.ref.impl.OwnedListImpl. indexOf(OwnedListImpl.java(Compiled Code)) at com.ibm.etools.emf.ref.impl.OwnedListImpl. duplicate(OwnedListImpl.java(Compiled Code)) at com.ibm.etools.emf.ref.impl.OwnedListImpl. duplicate(OwnedListImpl.java(Compiled Code)) at com.ibm.etools.emf.ref.impl.OwnedListImpl. add(OwnedListImpl.java:48) at com.ibm.ejs.models.base.bindings.applicationbnd.gen. impl.UserGenImpl$User_List.add(UserGenImpl.java:31) at com.ibm.ejs.security.Initializer. bindServerIdToAdminApp(Initializer.java:503) at com.ibm.ejs.security.Initializer. initialize(Initializer.java:220) at com.ibm.ejs.security.Initializer. serverStarted(Initializer.java:136) at com.ibm.ws.runtime.Server. fireServerStarted(Server.java:2018) at com.ibm.ws.runtime.Server. fireServerStarted(Server.java:2011) at com.ibm.ejs.sm.server.AdminServer. initializeRuntime0(AdminServer.java:1144) at com.ibm.ws.runtime.Server. initializeRuntime(Server.java:884) at com.ibm.ejs.sm.server.AdminServer. main(AdminServer.java:392) at java.lang.reflect.Method.invoke(Native Method) at com.ibm.ws.bootstrap.WSLauncher. main(WSLauncher.java:158) . 11/18/02 15:12:24:751 CST 6097e07e AdminServer X WSVR0009E: Error occurred during startup java.lang.RuntimeException at com.ibm.ejs.security.Initializer. serverStarted(Initializer.java:142) at com.ibm.ws.runtime.Server. fireServerStarted(Server.java:2018) at com.ibm.ws.runtime.Server. fireServerStarted(Server.java:2011) at com.ibm.ejs.sm.server.AdminServer. initializeRuntime0(AdminServer.java:1144) at com.ibm.ws.runtime.Server. initializeRuntime(Server.java:884) at com.ibm.ejs.sm.server.AdminServer. main(AdminServer.java:392) at java.lang.reflect.Method.invoke(Native Method) at com.ibm.ws.bootstrap.WSLauncher. main(WSLauncher.java:158) Problem Conclusion: Null access IDs are now checked and ignored. Test Comments: Circumvention: Temporarily disable security, remove invalid IDs from the Administrative Role then restart then restart. Re-enable security then restart again. Temporary Fix: provided testing eFix to customer. Comments: APAR: PQ56218 Version: 400 Abstract: PMI DOES NOT RECOVER WHEN WEBSPHERE APP SERVER IS RESTARTED WHEN SECURITY ENABLED Error Description: ** Brief Description: Customer has a java PMI client (Performance Monitoring Infrastructure)programming interface provided by IBM. -- It logs into WAS fine the first time but when you stop and restart WAS with security on it does not log back in. Getting error Cannot create PmiService bean obj; nested exception is: java.rmi.RemoteException: CORBA INTERNAL 0 No Local Fix: none Logically Dependent Apars: Users Affected: All WebSphere Application Server users which have enabled security. Problem Description: Java clients fail to log into WebSphere Application Server after the server is restarted with security enabled. Recommendation: Problem Summary: After the Java client logged into the WebSphere Application Server, if the server restarts for any reason, then the Java Client cannot login again with security enabled. The client will get the java.rmi.RemoteException: CORBA INTERNAL 0 Problem Conclusion: When the client receives a request reject message, the client now checks the credential associated with the request. If the credential is a dummy credential, then the client tries to re-establish the secure association with the server again. Test Comments: Circumvention: Temporary Fix: PQ56218_eFix_AEServer.jar Comments: APAR: PQ58764 Version: 400 Abstract: CORBA EXCEPTION ERROR Error Description: The customer stated when java client his the application server he is getting the following error into the client stdout file: CORBA exception errors... failed mutual authentication handshake... session does not exist in the session table. He also noticed jsa150e-unable to find session in the session table errors. Def ect 120428 Local Fix: No fix or workaround available yet. Logically Dependent Apars: Users Affected: All WebSphere Application Server users which have enabled security. Problem Description: CORBA exception errors with failed mutual authentication message Recommendation: Problem Summary: Client gets CORBA exception errors, failed mutual authentication handshake after 45 minutes of attempting to complete the request. The following CORBA exception occurs: "org.omg.CORBA.NO_PERMISSION: Failed mutual authentication handshake. Session does not exist in the session table." Problem Conclusion: The server now passes back the security context along with the exception, so the client can react accordingly. Test Comments: Circumvention: Temporary Fix: PQ58764_401_test.jar Comments: APAR: PQ51887 Version: 350 Abstract: EXPIRED CREDENTIAL ON A SESSION REPEATEDLY GIVES OUT " PRINCIPALAUTHENTICATORIMPL VALIDATE IBM WEBSPHERE" ERROR Error Description: Expired Credentials on a Session repeated gives out the following error message in the tracefile. No visibile effect on funtionality observed. . PrincipalAuthenticatorImpl validate IBM WebSphere Security 0, 0, com.ibm.WebSphereSecurity.ValidationFailedException . Change in the LTPA Credential timeout changes the time it takes for the cred to timeout. Local Fix: fix does not do a relogin but it does remove the security session on the client side for the expired credential so that it could relogin if the userid/password credentials are made available (either via cache or login). Logically Dependent Apars: Users Affected: All WebSphere Application Server 3.5 users of security. Problem Description: Expired credential on session does not get clean up on the client. Recommendation: Problem Summary: When the LTPA token expired on the client session, server throws validation failed exception when client makes a request to the server. However, server does not throw back the failure reason back along with the exception. This causes client to not refresh the LTPA token and fails all of the subsequent requests. Problem Conclusion: Server now throws back the correct exception message and the client will update the session accordingly. Test Comments: Circumvention: Temporary Fix: Available Comments: APAR: PQ55325 Version: 350 Abstract: AUTHORIZATION FAILURES IN WAS 3.5.5 Error Description: After upgrading from WAS 3.5.4 to 3.5.5, randomly some users are able to authenticate to use their application, while others are not. . The app server stderr file shows the following exceptions: "UnauthorizedSessionRequestException: SessionContext: a user authenticated as anonymous has attempted to access a session owned by user:xxx" "RuntimeException: SessionContext: an attempt to access a session while WebSphere Session Manager was turned off was made" . Also, a SAS log file is generated which contains the following info: "1> 2001-11-27 14:14:19.171 , ServerID: 2106094737 , PrincipalAuthenticatorImpl.authenticate : Invalid or null client security name, unable to authenticate. 1> 2001-11-27 15:58:43.296 , ServerID: 2106094737 , CredentialsImpl.run : The expiration time for ltpa credentials is too short relative to the ORB request timeout and/or the security cache timeout; a method request could take longer than the period over which the credentials will remain valid, or the credentials could expire while in the server cache." Local Fix: None. Logically Dependent Apars: Users Affected: All WebSphere Application Server users who have enabled security and are on 3.5.5, 4.02 or a more recent PTF will potentially be affected by this. Problem Description: NegativeArraySizeException in SecurityAttributeList. getAttributeStringArray() which causes an authorization failure. Recommendation: Problem Summary: The exception included below causes an authorization failure. java.lang.NegativeArraySizeException at com.ibm.ISecurityUtilityImpl.SecurityAttributeList. getAttributeStringArray(SecurityAttributeList.java (Compiled Code)) at com.ibm.ejs.security.web.WebCollaborator. getGrantedPermissions(WebCollaborator.java (Compiled Code)) at com.ibm.ejs.security.web.WebCollaborator. checkAuthorization(WebCollaborator.java (Compiled Code)) at com.ibm.ejs.security.web.WebCollaborator. authorize(WebCollaborator.java(Compiled Code)) at com.ibm.ejs.security.web.EJSWebCollaborator. preInvoke(EJSWebCollaborator.java(Compiled Code)) at com.ibm.servlet.engine.webapp. WebAppSecurityCollaborator. preInvoke(WebAppSecurityCollaborator.java (Compiled Code)) at com.ibm.servlet.engine.webapp.WebAppRequestDispatcher. dispatch(WebAppRequestDispatcher.java(Compiled Code)) at com.ibm.servlet.engine.webapp.WebAppRequestDispatcher. forward(WebAppRequestDispatcher.java(Compiled Code)) at com.ibm.servlet.engine.srt.WebAppInvoker. doForward(WebAppInvoker.java(Compiled Code)) at com.ibm.servlet.engine.srt.WebAppInvoker. handleInvocationHook(WebAppInvoker. java(Compiled Code)) at com.ibm.servlet.engine.invocation.CachedInvocation. handleInvocation(CachedInvocation.java(Compiled Code)) at com.ibm.servlet.engine.invocation. CacheableInvocationContext. invoke(CacheableInvocationContext.java(Compiled Code)) at com.ibm.servlet.engine.srp.ServletRequestProcessor. dispatchByURI(ServletRequestProcessor.java (Compiled Code)) at com.ibm.servlet.engine.oselistener. OSEListenerDispatcher.service (OSEListener.java(Compiled Code)) at com.ibm.servlet.engine.oselistener.SQEventListenerImp$ ServiceRunnable.run(SQEventListenerImp.java (Compiled Code)) at com.ibm.servlet.engine.oselistener.SQEventListenerImp. notifySQEvent(SQEventListenerImp.java(Compiled Code)) at com.ibm.servlet.engine.oselistener.serverqueue. SQEventSource.notifyEvent(SQEventSource.java (Compiled Code)) at com.ibm.servlet.engine.oselistener.serverqueue. SQWrapperEventSource$SelectRunnable.notifyService (SQWrapperEventSource.java(Compiled Code)) at com.ibm.servlet.engine.oselistener.serverqueue. SQWrapperEventSource$SelectRunnable.run (SQWrapperEventSource.java:221) at com.ibm.servlet.engine.oselistener.outofproc. OutOfProcThread$CtlRunnable.run (OutOfProcThread.java:248) at java.lang.Thread.run(Thread.java:481) Problem Conclusion: Test Comments: Circumvention: Temporary Fix: Comments: APAR: PQ55948 Version: 350 Abstract: OUTOFMEMORY (MEMORY LEAK) OCCURS WHEN SECURITY IS ENABLED AND APPLICATION SPAWNS A ASYNCHRONOUS THREAD WHICH MAKES AN ORB CALL Error Description: Environment: WebSphere Application Server (WAS) 3.5.3 Advanced Edition . Description: Customer has a servlet which spawns a thread which in turn makes a call to MQSeries. In this scenario, when WAS security is enabled, a memory leak occurs which eventually results in OutOfMemory as objects instantiated by the servlet stay around because security references to the objects don't go away. Local Fix: None Logically Dependent Apars: Users Affected: All WebSphere Application Server users which have deployed servlets which are EJB clients and instantiate new threads and WebSphere security is enabled. Problem Description: Security associates thread specific data with the hashtables which prevent the threads from being garbage collected. Recommendation: Problem Summary: Security associates thread specific data with the hashtables using the thread object as a key. Since there is a reference to the thread object stored in a hashtable, the thread object will not be garbage collected even if it has gone out of context in the servlet. This issue can be exacerbated by subclassing the thread in which the subclassed thread has references to large data objects. Problem Conclusion: Logic was added to the hashtables to periodically remove all references to threads which were no longer executing. The logic is activated if N new threads are added to the hashtable since the last time the removal logic has run. N is a tuneable value which defaults to 100 and is set by the "com.ibm.CORBA.threadStateCleanupDelta" property. Test Comments: Circumvention: Don't instantiate new threads within a servlet or manage a thread pool to limit the number of new threads instantiated. Also, clear all instance data before the thread exits. Temporary Fix: ZE FIX ERROR PQ65082 02/09/10 An efix fix is available for 3.5.3. Comments: APAR: PQ56074 Version: 350 Abstract: AUTHORIZATION FAILED FOR / OCCURS WHEN USING COM.IBM.CORBA.LOCALHOST PARAMETER IN ADMIN.CONFIG Error Description: Environment: WebSphere Application Server (WAS) 3.5.4 . Description: With WAS security enabled, when using the com.ibm.CORBA.LocalHost parameter to embed the hostname into IORs instead of the default IP address of the WAS box, trying to start the admin console results in no login prompt and an "Authorization failed for /" message in the tracefile. Any other admin client like XMLConfig also results in the same behavior. Local Fix: None Logically Dependent Apars: Users Affected: WebSphere Application Server users who set-up com.ibm.CORBA.LocalHost parameter in admin.config. Problem Description: With WAS security enabled, when using the com.ibm.CORBA.LocalHost = xxxx, adminserver and/or adminconsole can not be started properly, and you also see authorization failed for /. Recommendation: Apply efix, or not edit com.ibm.CORBA.LocalHost(using default option). Problem Summary: With WAS security enabled, when using the com.ibm.CORBA.LocalHost parameter, adminserver and/or adminconsole can not be started properly, and you also see Authorization failed for / exceptions. Problem Conclusion: With WAS security enabled, when using the com.ibm.CORBA.LocalHost= hostname, the hostname was used in security tag componnent, but IP address was returned by IOR, and the inconsistancy cause TaggedSecurityComponnent not found, thus communication is unsecured. Test Comments: Circumvention: Temporary Fix: PQ56074-354.jar Comments: APAR: PQ57182 Version: 350 Abstract: UNABLE TO VALIDATE CREDENTIALS FROM LTPA TOKEN. Error Description: Worker#49 curityLevel2.LoginFailed caught. LoginFailed.03 class org.omg.SecurityLevel2.LoginFailed exception was caught: .essage: null org.omg.SecurityLevel2.LoginFailed . .3:39:43.312 com.tivoli.tsm.authentication.LoginHelper 13:39:43.427 com.tivoli.tsm.authentication.DefaultAuthenticator .ogin(login(byte ltpaCookie) Worker#49 LTPASingleSignOn(HttpServletRequest, HttpServletResponse).12.03 Local Fix: Need a efix for WAS 3.5.4. This has been fixed in 4.0.X code base. Logically Dependent Apars: Users Affected: All WebSphere Application Server users of security. Problem Description: Unable to validate credential token for LTPA Recommendation: Problem Summary: Ltpa credential token fails authentication when SSO is configured. Invalid credential exception message would appear. Problem Conclusion: This problem is solved by improving the synchronization of the authentication process. Test Comments: Circumvention: Temporary Fix: PQ57182_354_test.jar Comments: APAR: PQ57814 Version: 400 Abstract: MACHINE WITH WAS SECURITY STOPS RESPONDING AFTER A PERIOD OF TIME. Error Description: Customer reports running into a problem where a machine configured with WAS security stops working eventually after 5-30mins of working okay. . The machine info is, . OS: SUN DB: Oracle WebServer: IPlanet WAS Version: 4.0.2 . Steps to recreate: 1. Enable OS EJB Security 2. Run normal test cases. . MAchine works for about 5-30 mins. Then "dies". The main symptom seems to be that after logging in to the environment, the user can access the secured site for a period of time, then they suddenly can no longer perform operations on the secured pages and may encounter blank sreens. . This is occuring on WebSphere Commerce Server. Local Fix: None. Logically Dependent Apars: Users Affected: All WebSphere Application Server users of security. Problem Description: Machine with WebSphere Application Server security stops responding after a period of time Recommendation: Problem Summary: After the security is enabled, the application works fine only for a certain period of time. Then the application would fail with the exception JSAS0240E: Login failed. Problem Conclusion: This problem is caused by multiple key file handles opened by WebSphere Application Server. The login failed problem is gone after allowing only one key file to be opened at a time. Test Comments: Circumvention: Temporary Fix: PQ57814_eFix_AEServer.jar Comments: APAR: PQ59150 Version: 350 APAR: PQ59447 Version: 400 Abstract: USERS & GROUPS WHOSE NAME/STRING IS MORE THAN 127 BYTES LONG WILL GET "JAVA.LANG.NEGATIVEARRAYSIZEEXCEPTION" EXCEPTIONS Error Description: Users who belong to more than 127 groups or belong to a group whose name is greater then 127 bytes long will fail authorization. A "NegativeArraySizeException" message will be evident in traces and possibly be visable on a web client. Local Fix: none Logically Dependent Apars: Users Affected: All WebSphere Application Server users using security and adding users to groups with names greater than 127 bytes long or adding users to more than 127 groups. All WebSphere Application Server users using security and adding users to groups with names greater than 127 bytes long or adding users to more than 127 groups. Problem Description: Users encounter an authentication failure for Java clients or an Error 500 for web clients. Recommendation: Problem Summary: Users encounter an authentication failure for Java clients or an Error 500 for web clients. The problem is a NegativeArraySizeException occurs in SecurityAttributeList due to the conversion of byte values into integers before bitwsie operations were performed. Negative byte values were sign extended yeilding a negative value for the final integer after bitwise operations completed. Problem Conclusion: Sign extended bits were masked off before the bitwise operation was performed. Test Comments: Circumvention: Limit users to 127 groups and to groups with less then 128 bytes in their name. Temporary Fix: PQ59150-3.5.5-3.5.6.jar Comments: APAR: PQ62632 Version: 350 Abstract: WHEN A HIGH NUMBER OF APPLICATION SERVERS ARE RUNNING (15 OR HIGHER) AND WAS SECURITY ENABLED, THE SECBOOTSTRAP IS CORRUPTED Error Description: Environment: WebSphere Application Server 3.5.5 AE for AIX . Description: When WAS security is enabled and a high number of app servers are running (16 or more), the secbootstrap file gets corrupted after stopping an application server resulting in the following message in the tracefile: . I/O Error while processing the security bootstrap repository. . This problem is less intermittent the more application servers are running. In one case, running 35 application servers caused this problem to occur readily when stopping an app server. Local Fix: None. Logically Dependent Apars: Users Affected: WebSphere Application Server users with security enabled. Problem Description: secbootstrap file gets corrupted while stopping application server. Recommendation: Problem Summary: secbootstrap file gets corrupted while stopping application servers if too many application servers are deployed in a single node. (35 application servers were configured on the reported system). The problem was caused in deregistering ports from secbootstrap. Problem Conclusion: The deregister to secootstrap seems not work properly. Test Comments: Circumvention: Temporary Fix: testing eFix has been send to customer Comments: send a testing eFix to customer. APAR: PQ63062 Version: 400 Abstract: RESTART OF WCS IN WAS 4.0.3 CAUSES "ILLEGAL USE OF 1PC RESOURCE IN TRANSACTION" WHEN SECURITY IS ENABLED Error Description: Environment: WebSphere Application Server 4.0.3 AE WebSphere Commerce Suite . Description: In WAS 4.0.3 AE with security enabled, restarting the WCS app server causes the following message to appear in admin console: . 6/18/02 17:18:35:857 EDT 6d938229 ConnectO W Illegal use of 1PC resource in transaction javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 0 No; nested exception is: org.omg.CORBA.TRANSACTION_ROLLEDBACK: com.ibm.websphere.csi.CSITransactionRolledbackException: at com.ibm.ejs.csi.TranStrategy.commit(TranStrategy.java:194) at com.ibm.ejs.csi.TranStrategy.postInvoke(TranStrategy.java:67) . This problem does not occur in WAS 4.0.2 AE, and it doen't occur when WAS 4.0.3 security is disabled. Local Fix: None. Logically Dependent Apars: Users Affected: All WebSphere Application Server users who have enabled security. Problem Description: "Illegal use of 1PC resource in transaction" errors received during WebSphere Commerce Suite initialization. Recommendation: Problem Summary: "Illegal use of 1PC resource in transaction" errors received during WebSphere Commerce Suite initialization. This issue may be seen on initialization or during runtime of any application server if EJBs which use data sources have been deployed. The problem was caused by new EJB calls which were made, necessarily, in a non-standard manner which implicitly involved the calls in any existing transactions. Problem Conclusion: The problem was resolved by explicitly suspending and resuming any existing transaction. Test Comments: Circumvention: Use a Two Phase Commit driver for the data source. Temporary Fix: A test fix was supplied. Comments: APAR: PQ63116 Version: 400 Abstract: PROBLEM: WHEN THE ADMINISTRATION SERVER IS STOPPED AND RESTARTED, VARIOUS CLIENTS GET AUTHENTICATION ERRORS. Error Description: Problem: When the administration server is stopped and restarted, WebSphere SeriousEvent, PMI, and WSCP clients get Authentication errors. . Information specific to WAS 4.0.2: This was working fine with eFix PQ56218. When later cumulative eFix PQ62538 was applied, this is broken. Local Fix: none. Logically Dependent Apars: Users Affected: WebSphere Application Server users with security enabled Problem Description: When the administration server is stopped and restarted, WebSphere clients get authentication errors. Recommendation: Problem Summary: In the scenario where clients make a persistent connection with the server, clients get Authentication errors when the administration server is restarted without restarting the clients. Following exception will occur: Exception stack trace: javax.naming.NoPermissionException: NO_PERMISSION exception caught. Root exception is org.omg.CORBA.NO_PERMISSION: com.ibm.CORBA.iiop.ExceptionInterceptorsCalled minor code: 0 completed: Maybe Problem Conclusion: Both the client and the server exception handling mechanism is improved to handle the broken connections between the client and the server. Test Comments: Circumvention: Temporary Fix: PQ63116_eFix.jar Comments: APAR: PQ65687 Version: 400 Abstract: SECURITY EXCEPTIONS AFTER SERVER REBOOTS Error Description: We are currently having intermittent problems with the IBM WAS Admin service not starting, especially after server reboots. This generates the following entry in sas_server.log: . 1> 2002-07-24 14:23:16.772 , ServerID: 12221999 , SecurityTaggedComponentAssistorImpl.register , Thread Hash: 673378419 Thread P=596272:O=0:CT,5,main : . JSAS0026E: Exception connecting object to the ORB. Check the sas.server.props file to ensure that the SSL keyStore and trustStore properties are set properly. If the problem persists, contact support for assistance. . We did apply the following fix found from the IBM Websphere support site but the problem still recurs. Solution . Put the following parameters in separate lines in the /bin/admin.config and set them to unique unused ports on the machine and restart WAS: . com.ibm.CORBA.SSLPort= com.ibm.CORBA.LSDSSLPort= . Problem occurs on WAS AE 4.03 and 4.04. Local Fix: no workaround available Logically Dependent Apars: Users Affected: All WebSphere Users that have enabled security and restart their adminstration server while their application servers are up and running. Problem Description: If application server is up and running while the adminstration server is restarted, then application server continues to uses a stale IOR without loading the newly created one. Recommendation: Problem Summary: If the WebSphere Application Servers are up and running while the Admin Server is rebooted; then the Application servers continue to use the stale IOR for the Adminstration Server instead of getting the new IOR for the Adminstration Server. With the stale IOR, the Application Servers get OBJECT_NOT_EXIST exceptions. Problem Conclusion: To resolve this problem, the bootstrap repository is read to load the new IORs for the server that was restarted. The logic is to read the bootstrap repository to get the IORs up to three times and ping the server with the new IOR. After three times, if the server does not respond to the new IOR, then OBJECT_NOT_EXIST exception is thrown. Test Comments: Circumvention: Temporary Fix: Comments: APAR: PQ66004 Version: 400 Abstract: MULTIPLE SECURITY LOG ENTRIES FOR ONE INVALID USERID/PASSWORD. Error Description: Upon entering a wrong password for a given userid, the following log statements are written to appserver-out.log. Apart from the fact, that times the same message seems unnecessary, it should the application's decision whether to write or not to write such message regarding invalid logins. Otherwise, a very simple denial of service attack could logins. Otherwise, a very simple denial of service attack could be convinced with bogus login attempts keeping the machine busy logging these messages. 8/26/02 13:17:39:080 CEST 37b2205d SystemOut U 5> 2002-08-26 13:17:39.08 , ServerID: 375334458 , LoginHelperImpl.request_login_controlled : 8/26/02 13:17:39:090 CEST 37b2205d SystemOut U JSAS0240E: Login failed. Verify the userid/password is correct. Check the properties file to ensure the login source is valid. If this error occurs on the server, check the server properties to ensure the principalName has a valid realm and userid. 8/26/02 13:17:39:110 CEST 37b2205d SystemOut U 6> 2002-08-26 13:17:39.11 , ServerID: 375334458 , CredentialsImpl.get_mapped_credentials : 8/26/02 13:17:39:120 CEST 37b2205d SystemOut U JSAS0240E: Login failed. Verify the userid/password is correct. Check the properties file to ensure the login source is valid. If this error occurs on the server, check the server properties to ensure the principalName has a valid realm and userid. 8/26/02 13:17:39:451 CEST 37b2205d SystemOut U 8> 2002-08-26 13:17:39.451 , ServerID: 375334458 , CredentialsImpl.get_mapped_credentials : 8/26/02 13:17:39:481 CEST 37b2205d SystemOut U JSAS0240E: Login failed. Verify the userid/password is correct. Check the properties file to ensure the login source is valid. If this error occurs on the server, check the server properties to ensure the principalName has a valid realm and userid. Action Planned: Sending to entitlement, then to WAS for customer Local Fix: none Logically Dependent Apars: Users Affected: WebSphere Application Server users who have security enabled. Problem Description: Multiple security log entries for one invalid login. Recommendation: Problem Summary: Upon entering a wrong password for a given userid, the following 3 log statements are written to appserver-out.log. It's unnecessary to have 3 login error messages. 8/26/02 13:17:39:080 CEST 37b2205d SystemOut U 5> 2002-08-26 13:17:39.08 , ServerID: 375334458 , LoginHelperImpl.request_login_controlled : 8/26/02 13:17:39:090 CEST 37b2205d SystemOut U JSAS0240E: Login failed. Verify the userid/password is correct. Check the properties file to ensure the login source is valid. If this error occurs on the server, check the server properties to ensure the principalName has a valid realm and userid. 8/26/02 13:17:39:110 CEST 37b2205d SystemOut U 6> 2002-08-26 13:17:39.11 , ServerID: 375334458 , CredentialsImpl.get_mapped_credentials : 8/26/02 13:17:39:120 CEST 37b2205d SystemOut U JSAS0240E: Login failed. Verify the userid/password is correct. Check the properties file to ensure the login source is valid. If this error occurs on the server, check the server properties to ensure the principalName has a valid realm and userid. 8/26/02 13:17:39:451 CEST 37b2205d SystemOut U 8> 2002-08-26 13:17:39.451 , ServerID: 375334458 , CredentialsImpl.get_mapped_credentials : 8/26/02 13:17:39:481 CEST 37b2205d SystemOut U JSAS0240E: Login failed. Verify the userid/password is correct. Check the properties file to ensure the login source is valid. If this error occurs on the server, check the server properties to ensure the principalName has a valid realm and userid. Problem Conclusion: 2 unnecessary messages are removed. Only one message will be logged. Test Comments: Circumvention: Temporary Fix: PQ66004_eFix_test.jar Comments: APAR: PQ66449 Version: 400 Abstract: AUTH PRINCIPAL NULLS OUT AND CAUSES AUTHORIZATION FAILURE. 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. Logically Dependent Apars: 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: Problem Summary: 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. Test Comments: Circumvention: Temporary Fix: available Comments: APAR: PQ67119 Version: 350 Abstract: WEBPSHERE 356 APPSERVER WILL NOT START WHEN SECURITY IS ENABLED ON AN ADMIN AGENT SERVER. Error Description: Upgraded Two Websphere 3.5.4 nodes to Websphere 3.5.6 with security enabled. One node is using a Websphere admin agent thur a firewall to connect to the main Websphere node running the admin server. Various problems either starting an application server on the node running the admin agent and/or connectin the admin server node from the admin agent node. .Running an adminejstrace, it will show that admin server never completes the method: activeObjectInvocation. This method is called from AdminAgentImpl on the admin agent node to update ActiveSecurityConfig on the admin server node.This will cause a deadlock condition within the security code. Local Fix: pmr05680_test.jar Logically Dependent Apars: Users Affected: WebSphere Application Server users of Administration Agent with security enabled. Problem Description: WebSphere AppServer will not start when security is enabled on an adminstration agent server. Recommendation: Problem Summary: On WebSphere 356, when one node is using administation agent to connect to main WAS node's admin server with both security and auto-start is enabled, the AppServer would failed to start. In the thread dump trace, following thread lock will show. sys_mon_t:0x00239ac0 infl_mon_t: 0x00000000: com.ibm.ISecurityLocalObjectBaseL13Impl.VaultImpl@8E0130/ 8E0138: (Flat locked) owner "Pooled ORB request dispatch WorkerThread" (0xa33b7a0) 1 entry Waiting to be notified: "WebServer-Plugin-Cfg-Thread" (0xac43ca8) sys_mon_t:0x0ab3c658 infl_mon_t: 0x00000000: com.ibm.ISecurityLocalObjectBasicAuthImpl.SecurityContextImpl @9BD940/9BD948: (Flat locked) owner "WebServer-Plugin-Cfg-Thread" (0xac43ca8) 1 entry Waiting to be notified: "Pooled ORB request dispatch WorkerThread" (0xa33b7a0) Problem Conclusion: This is caused by over synchronization in the security component Redundant synchronization code will be removed from security component. Test Comments: Circumvention: Temporary Fix: available Comments: