Fix (APAR): WAS_Security_11-17-2003_5.0.1_cumulative_Fix Status: Fix Release: 5.0.1 Operating System: All Supersedes Fixes: This fix supercedes WAS_Security_04-18-2003_5.0.1_cumulative_Fix. However if WAS_J2C_10-16-2003_5.0.1_cumulative_Fix needs to be installed, WAS_Security_04-18-2003_5.0.1_cumulative_Fix must be applied first, Then this fix and WAS_J2C_10-16-2003_5.0.1_cumulative_Fix and this fix can be installed. CMVC Defect: PQxxxxx Byte size of APAR: 1755077 Date: 2003-11-26 Abstract: WAS_Security_11-17-2003_5.0.1_cumulative_Fix Description/symptom of problem: Apar Number: PQ75639 Customer wishes to use own HttpServletRequestWrapper, but while calling getPrivateAttributes() it generates a null pointer exce Error Description: Own HttpServletRequestWrapper in websphere 5.01 will throw a nullpointer exception while hitting method getPrivateAttributes() which belongs to com.ibm.ws.security.web.WebCollaborator Local Fix: None yet. Users Affected: WebSphere Application server users who have enabled security and use a customized HTTPServletRequestWrapper. Problem Description: NullPointException encountered when accessing protected page if a custom HTTPServletRequestWrapper is in use. Problem Summary: A private HTTPRequest attribute flag is used to detect include and forward requests. This private attribute was not available in the custom HTTPServletRequestWrapper. Problem Conclusion: The flag is now based on a public attribute that is independant of a specific HTTPServletRequestWrapper. ************************************************** Apar Number: PQ75723 Web browser allows multiple LTPAToken cookies to be sent to WSAS causing user not to get past form-based login screen Error Description: Environment: WebSphere Application Server (WSAS) 4.0.x Description: Web browsers are allowing multiple copies of the LTPAToken cookie to be stored in the web browser. When these LTPAToken cookies are sent to WSAS during form-based login, the user is redirected back to the login screen no matter what username and password is used. Users Affected: All WebSphere Application Server users who are accessing different WebSphere servers with Single Sign On configured where one server is in a sub-domain of the other server. (e.g. One server is in b.com and the other is in a.b.com) Problem Description: A user is re-prompted to sign on or receives a blank page immediately after signing on. Problem Summary: A user is re-prompted to sign on or receives a blank page immediately after signing on. The root of the problem is that the browser is sending two LtpaToken cookies. WebSphere only attempts to use the first cookie value. If this is not from the same Single Sign On domain and the LTPA keys have not been shared between the servers involved, the token cannot be decrypted and user authentication fails. Problem Conclusion: All LtpaToken cookie values received are now attempted in user authentication. This is done as one cookie is indistinguishable from another cookie if version 0 cookies are used. Version 1 cookies, which contain domain information and can be distinguished, cannot be used for compatibility reasons as older browsers do not recognize them. There are two outstanding issues which will not be addressed in this release of WebSphere. The first is a potential performance degradation to user authentication. This will only occur if two LtpaToken cookies are present in the request and the first cookie is not the proper cookie. The problem will likely only be noticeable on heavily loaded systems. The second will only occur if the WebSphere servers in question have shared LTPA keys. The potential exists for a different user to be logged onto each server. The server in the sub domain may be selected non deterministically as there is no guarantee which cookie will be first in the request. This could cause subsequent requests to this server to be authenticated/authorized by a different user. Circumvention: Do not set up WebSphere servers with SSO configured with one on a sub-domain of another. Comments: The problem is the browser is not following RFC2109 specification for the handling of cookies. From a WebSphere, perspective the cookies are indistinguishable as the browser does not send any of the cookie attributes that were set by the server on the LtpaToken cookie. The cookie value also does not contain any attributes to distinguish the correct cookie. This value cannot currently be changed due to interoperability issues with other WebSphere servers as well as Domino and WebSeal which may have problems with any new format. Applicable sections of RFC2109: 4.3.2 Rejecting Cookies * The value for the request-host does not domain-match the Domain attribute. * The request-host is a FQDN (not IP address) and has the form HD, where D is the value of the Domain attribute, and H is a string that contains one or more dots. Examples: * A Set-Cookie from request-host y.x.foo.com for Domain=.foo.com would be rejected, because H is y.x and contains a dot. 4.3.4 Sending Cookies to the Origin Server Domain Selection The origin server's fully-qualified host name must domain-match the Domain attribute of the cookie. ************************************************** Apar Number: PQ76369 security not handling wild cards for port numbers Error Description: Customer sees java.lang.numberformat exceptions when enabling security. 7/2/03 15:57:22:561 CDT] 59babf7a WebGroup E SRVE0026E: [Servlet Error]-[*]: java.lang.NumberFormatException: * at java.lang.Integer.parseInt(Integer.java(Compiled Code)) at java.lang.Integer.parseInt(Integer.java:472) at com.ibm.ws.security.web.WebCollaborator.getHTTPSPort(WebCollabor ator.jav a:1103) The failiure reason is security expects that all ports are Local Fix: hile scanning a list of ports to find https port. If the desire d port found before hitting *, no error encountered. however, i f hitting * before reaching the desired port, error occurs. Yo u can open an APAR, so I can modify security codes notto affecte d by * port while reading the list of ports. for exampl e, in virtualhosts.xml, the following line was configured : LOCAL FIX: workaround : remove fol lowing line " : " from virtualhosts.xml Users Affected: WebSphere Application server 5.0 security users. Problem Description: Non-decimal port in resources.xml and virtualhosts.xml cause java.lang.NumberFormatException. Problem Summary: If non-decimal port appears in resources.xml or virtualhosts.xml, java.lang.numberformat exception may occur after security enabled. In system.out, you will see the following similar message: WebGroup E SRVE0026E: [Servlet Error]-[*]: java.lang.NumberFormatException: * at java.lang.Integer.parseInt(Integer.java(Compiled Code)) at java.lang.Integer.parseInt(Integer.java:472) at com.ibm.ws.security.web.WebCollaborator.getHTTPSPort (WebCollaborator.java) a:1103) Problem Conclusion: As security does not expect non-decimal port number, any non-decimal port should be just ignored, and continue to scan decimal port rather than error out. Test Comments: Circumvention: remove any non-decimal port entry from resources.xml and virtualhosts.xml . ************************************************** Apar Number: PQ76432 Synchronization breaks when J2C JAAS authentication alias is add ed. Error Description: Customer description: We are running Websphere 5.0.1 ND on AIX 5.1. All appservers are clustered and global security is turned on. When we add a J2C JAAS authentication alias it breaks synchronization. Adding the alias updates the security.xml file, which is not being automatically synchronized. If we manually copy the security.xml file out to all nodes and then issue a sync command synchronization is restored. Should this be automatically managed by Websphere? Local Fix: Setting LDAP configuration to "ignore case" avoids the problem. Users Affected: WebSphere Application Server users who have enabled security. Problem Description: Authorization may fail while performing configuration synchronization in network deployment enviornment. Problem Summary: Configuration synchronization fails with the following message: "SECJ0321E: Role based authorization is caller in role failed for security name ..". The cause was Basic Authorization credentials were incorrectly used to perform authorization during synchronization. Problem Conclusion: Synchronization will now only use LTPA credentials. ************************************************** Apar Number: PQ76788 Abstract: Java client login popup window is blank or in-active Error Description: To re-produce: 1. Enable the global security and re-start the AppServer. 2. go to \bin and run dunmNameSpace.bat. The cursor is inactive and the entry fields will not accept any text. Local Fix: Press the TAB key and immediatly type in the field. Users Affected: All WebSphere Application Server users running Java clients with security enabled. Problem Description: The login popup window will not accept text. Problem Summary: The login popup window will not accept text when security is enabled for a Java client. This was caused by the field constantly re-displaying. Problem Conclusion: A flag was added in the code to only display the field once. ************************************************** Apar Number: PQ77663 THE WILD CARD CHARACTER * WAS NOT ESCAPED IN PASSWORD CHECKING METHOD. WSAS V5.02 Error Description: user "frederic" exists in ldap registry. When launching the admin console (security ON), the login window pops up, if the user input "frede*" then the password, it should NOT complete the name using the * character as a wildcard completion mecanism, it should only look for the user "frede*" in ldap, which in this case does not exist, so "frede*" should be denied access. ************************************************** Apar Number: PQ77960 JSAS1477W error connecting WSAS v5 on z/OS to WSAS v5 on distrib Error Description: We are attempting to connect a WebSphere Application Server ND server to a WebSphere Application Server (V5) on z/OS using CSIv2 with identity assertion. The connection fails, and in the log we see the following messages: JSAS1477W: SECURITY CLIENT/SERVER CONFIG MISMATCH: The client security configuration (sas.client.props or outbound settings in GUI) does not support the server security configuration for the following reasons: ERROR 1: JSAS0616E: The client configuration specifies the LTPA authentication mechanism, but the server does not support it. minor code: 494210CA completed: No Users Affected: All WebSphere Application Server users who have enabled security and are attempting to interoperate with Z/OS when client identity assertion is enabled and the target server is configured to use the LTPA authentication mechanism. Problem Description: JSAS1477W: SECURITY CLIENT/SERVER CONFIG MISMATCH is received. Problem Summary: When attempting to connect from a WebSphere Application Server to a WebSphere Application Server on z/OS using CSIv2 with identity assertion, the connection fails. WebSphere Application Server (V5) on z/OS does not export an IOR with LTPA as a supported authentication mechanism. Since the configured authentication mechanism on WebSphere Application Server using LTPA, the validation logic rejected the request since z/OS doesn't support LTPA at this time. The following messages occur: JSAS1477W: SECURITY CLIENT/SERVER CONFIG MISMATCH: The client security configuration (sas.client.props or outbound settings in GUI) does not support the server security configuration for the following reasons: ERROR 1: JSAS0616E: The client configuration specifies the LTPA authentication mechanism, but the server does not support it. minor code: 494210CA completed: No Problem Conclusion: Since identity assertion was selected, the client authentication mechanism does not need to be validated. ************************************************** Apar Number: PQ79082 ParserException when a dash is encountered WSAS 5.02 Error Description: Customer running a servlet application, encounters the following Local Fix: none Users Affected: All WebSphere Application Server users configuring JAAS login modules. Problem Description: The JAAS configuration file cannot contain hyphens ("-"). Problem Summary: The JAAS configuration file cannot contain hyphens ("-"). The hyphen was not accounted for in the parsing algorithm. The following exception is encountered: [9/10/03 13:36:11:406 GMT-08:00] 5e177462 Parser E SECJ4048E: ParserException occurred during parsing jaas application configuration. The exception is com.ibm.ws.security.auth.login.Parser$ParserException: line 2: expected 'null', found '-' at com.ibm.ws.security.auth.login.Parser.getString (Parser.java:125) at com.ibm.ws.security.auth.login.Parser. parseAppConfigurationEntry(Parser.java:73) at com.ibm.ws.security.auth.login.Parser.parse (Parser.java:50) at com.ibm.ws.security.auth.login.ConfigFile. buildFileEntry(ConfigFile.java:209) at com.ibm.ws.security.auth.login.ConfigFile. (ConfigFile.java:91) Problem Conclusion: Hyphens are now handled by the parser. Test Comments: Circumvention: Don't use hyphens in JAAS configuration files. ************************************************** Apar Number: PQ79211 IN V5 YOU CANNOT OVERRIDE INITIAL JNDI CONTEXT FACTORY Error Description: In V3.5 and in V4.x, you are permitted to override the Intial JNDI Context Factory. However in V5 this capability seems to be intended based on informtion in the InfoCenter, but the customer cannot override it. It appears that the default context factory com.sun.jndi.ldap.LdapCtxFactory is always used. Users Affected: WebSphere Application Server 5.0 users who want to override JNDI initial context factory for the LDAP user registry. Problem Description: If LDAP is configured as the user registry, the JNDI initial context factory cannot be configured as it could on previous releases. Problem Summary: If LDAP is configured as the user registry, the JNDI initial context factory cannot be configured as it could on previous releases. This forces users to use the default context factory which is com.sun.jndi.ldap.LdapCtxFactory Problem Conclusion: Code was introduced to allow users to choose different JNDI initial context factory. To override default context factory, follow those steps: 1: Disable global security 2: add the following custom property: java.naming.factory.initial=initial_context_class 4: restart server. 5: Enable global security, Important note on support: WebSphere supports the ability to configure a new initial context factory. However, Websphere has only been tested with the default initial context factory. If a new initial context factory is configured, issues related to the initial context factory or the initial contexts supplied by the factory are not supported. If WebSphere functions with the default initial context factory but not a customized one, then this willneed to be resolved in the customized initial context factory code. This is not a changed support policy but needs to be documented since this function was not available previously on this release. ************************************************** Apar Number: PQ79821 The comma used to separate trusted users incorrectly parses DNs Error Description: The | symbol should be used to separate entries on the trusted list of users because the full DN contains commas, which is the current delimiter ************************************************** Apar Number: PQ79836 Abstract: The mapDNToName should only return a DN when user reg is LDAP Error Description: Problem has been resolved in internal defect #179238 This defect is due to the change put into defect 179145. The change was in the mapDNToName method which is typically only called when LDAP is the user registry. However, in CTS, the RI sends an Identity Assertion token with a DN (instead of Certificate) when the RI client authenticates to the RI server. The fix here is to only return a DN in mapDNToName in the case of a user registry type of LDAP, otherwise return the CN of the DN as it used to do. Directions to apply fix: NOTE: YOU MUST FIRST DOWNLOAD THE UPDATE INSTALLER TOOL IN ORDER TO INSTALL A FIX. The Fix Installer can be downloaded from the following link: http://www-3.ibm.com/software/webservers/appserv/support/index.html 1) Create temporary "fix" directory to store the jar file: UNIX: /tmp/WebSphere/fix Windows: c:\temp\WebSphere\fix 2) Copy jar file to the directory 3) Shutdown WebSphere 4) Follow the Fix installation instructions that are packaged with the Fix Installer on how to install the Fix. 5) Restart WebSphere 6) The temp directory may be removed. Directions to remove fix: NOTE: FIXES MUST BE REMOVED IN THE ORDER THEY WERE APPLIED. DO NOT REMOVE A FIX UNLESS ALL FIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED. YOU MAY REAPPLY ANY REMOVED FIX. Example: If your system has fix1, fix2, and fix3 applied in that order and fix2 is to be removed, fix3 must be removed first, fix2 removed, and fix3 re-applied. 1) Shutdown WebSphere 2) Follow the instructions that are packaged with the Fix Installer on how to uninstall the Fix. 3) Restart WebSphere Directions to re-apply fix: 1) Shutdown WebSphere 2) Follow the Fix instructions that are packaged with the Fix Installer on how to uninstall and reinstall the Fix. 3) Restart WebSphere Additional Information: