Fix (APAR): WAS_Security_08-15-2003_4.0.6-4.0.5-4.0.4_client_cumulative_Fix Status: Fix Release: 4.0.6,4.0.5,4.0.4 Operating System: All Supersedes Fixes: WAS_Security_09-13-2002_4.0.4-4.0.3_client_cumulative_eFix, WAS_Security_10-07-2002_4.0.4-4.0.3_client_cumulative_eFix, WAS_Security_10-31-2002_4.0.4-4.0.3_client_cumulative_eFix, WAS_Security_11-19-2002_4.0.4-4.0.3-4.0.2_client_cumulative_eFix, WAS_Security_01-06-2003_4.0.5-4.0.4_client_cumulative_eFix, WAS_Security_03-17-2003_4.0.5-4.0.4-4.0.3_client_cumulative_Fix, WAS_Security_05-16-2003_4.0.5-4.0.4_client_cumulative_Fix.jar and WAS_Security_06-17-2003_4.0.6-4.0.5-4.0.4_client_cumulative_Fix as well as any fixes for APARs listed below. CMVC Defect: See APAR list below Byte size of APAR: 1325663 Date: 08/22/2003 Abstract: Security cumulative fix 08/15/2003. Description/symptom of problem: See APAR list below. Directions to apply fix: 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 fix: 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 fix: 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: ------------------------------------------------------------------ The administration server and all application servers and clients which use the Websphere installation directory must be stopped for proper application of this eFix. Included APARS: 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 progra mmatic security. Problem Description: If the anonymous principal is propagated or the user id entity is missing, getCallerPrincipal() returns inconsistan t 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: 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 namegets 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: PQ68882 Version: 400 Abstract: CANNOT HAVE , AND () IN ADMIN CONSOLE USER NAME Error Description: The customer cannot use user names that contain the comma character , and parentheses () in the DN as admin console users. The trace file contains the error message 'Invalid LDAP user'. Local Fix: There is no workaround for users whose DN contains a comma and parentheses characters. Logically Dependent Apars: Users Affected: WebSphere Application Server security users who has used a comma (, ASII 44) or open parenthese (ASII 40) or close parenthese (ASII 41) in a user's security name. Problem Description: If a user name or attributes in a DN (if LDAP is the user regi stry) contain comma or open parenthese or close parenthese, authorization for the DN may fail. Recommendation: Problem Summary: If user name or attribute in DN (if using LDAP registry) contain comma or open parenthese or close parenthese, user name was improperly truncated as security use those characters as delimiter, which results authorization error. If a Custom Registry is in use, this also applies to names returned by the following methods: List getUsers() List getUsers(String pattern) String getUserDisplayName(String userName) String getUniqueUserId(String userName) List getUniqueUserIds(String uniqueGroupId) String getUserSecurityName(String uniqueUserId) Problem Conclusion: Comma's and parenthesis were used internally as delimeters. The use of parenthesis as delimiters has been removed. Commas are now treated properly by escaping them. A fix for this APAR will be contained in any security cumulative eFix dated after the closure date of this APAR. Test Comments: Circumvention: Temporary Fix: A test fix was provided. Comments: APAR: PQ71310 Version: 400 Abstract: getUserPrincipal() getname() returns wrong name rather than logg ed in username accessing from another domain Error Description: Customer logs in to the administration console using the administration username and password The Custom realm is called and accepts the administration username and password. Then logs to the Web Application using a web username and password (username and password are different from administration username and password): The Custom realm is called and accepts the authentication. The Web Application (a servlet) calls getUserPrincipal().getName() from the HttpServletRequest. The Web application receives the administration user identity. Later calls to getUserPrincipal().getName() from the HttpServletRequest return the correct logged user. Local Fix: none Logically Dependent Apars: Users Affected: WebSphere Application Server security users who have deployed servlets and EJBs in different realms. Problem Description: getName() in getUserPrincipal() may not return the right security name during an EJB call. Recommendation: Problem Summary: getName() in getUserPrincipal() may return wrong security name after servlet accesses an EJB in a different security domain. Problem Conclusion: When a servlet accesses EJB in a different realm, security will try to map the invocation credential to the target realm. If the credential mapping fails, the original credential is now returned rather than returning the default credential. Test Comments: Circumvention: Temporary Fix: provided test fix Comments: APAR: PQ75785 Version: 400 Abstract: 4.0.6 Admin Console re-prompting Customer for log-in Error Description: Customer is at 4.0.6 on Solaris. When they start the Admin Local Fix: During the 10 minutes after the pop-up disappears, anyone can Logically Dependent Apars: Users Affected: WebSphere Application Server users who have enabled security and are using the LTPA authentication mechanism. Problem Description: Java clients re-prompt for user ID and password after LTPAToken expired. Recommendation: Problem Summary: Java clients, including the Administration Console, may prompt for user ID and password information again after LTPA Token expired. This should not occur since Java clients use a basic authentication credential which does not expire. Problem Conclusion: The server now deletes the session on credential expiration. The client retries once using the existing basic authentication credential if the session was deleted for an expired credential. This prevents the client from re-prompting unless the user or password is no longer valid in the user registry. Test Comments: Circumvention: Temporary Fix: test fix provided. Comments: