Release Notes
Service Packs are cumulative; Service Pack 4 contains all the fixes made in earlier Service Packs released for WebLogic Server 8.1.
The following sections describe problems that were resolved in WebLogic Server 8.1 Service Pack 4:
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-70.00.jsp. |
|
Updates to the weblogic-application.xml file were not getting loading upon redeployment. Now, the JDBCModule considers changes to the JDBC connection pool definition in the weblogic-application.xml file upon deployment. |
|
The weblogic.j2eeclient.Main did not work in webstart. The client jar file is an argument loaded by the webstart client and made available in the classpath. But the file was not available in the current directory resulting in an error. A system property (weblogic.j2ee.client.isWebStart) was added to WebLogic Server to load the client jar file from the system classpath. weblogic.j2eeclient.Main now works in webstart. |
|
When the classloader-structure feature was used in weblogic-application.xml, the ClasspathServlet was unable to serve the files requested in a form such as: http://host:port/bea_wls_internal/classes/appName@compName/mydir/Foo.class The ClasspathServlet code has been modified to address this specific requirement. |
The CredentialMapper had insufficient privileges to modify the user credential mappings in all cases. WebLogic Server now has sufficient privileges to modify the user credential mappings in all cases. |
|
The ParsePolicies class was not parsing some special permissions properly. |
|
WebLogic log was ignoring the Principals that extend WLSUser. Therefore, sometimes the wrong Principal was being displayed in the user field. Now, WebLogic log displays the custom Principals that extend WLSUser. |
|
WebLogic Server was not checking for group circularity in weblogic.security.providers.authentication.LDAPAtnLoginModuleImpl. As a result, so many LDAPConnections were being created when the backend LDAP group had itself as a member that the server would crash. Now, WebLogic Server has a flag called IgnoreDuplicateMembership. When checked, this flag warns if a group is being added that has already been added to the list of groups a user belongs to. In this case, WebLogic Server will then ignore the duplicate group. By default, the flag is unchecked. Although this flag works in production mode, it is recommended that it only be used in development mode due to its affect on performance in production mode. |
|
Memory Leaks were detected when using DirContext.close with the embedded LDAP server. |
|
When the flag -Dweblogic.security.URLResourceCaseMapping=off was used during startup, a warning message was displayed even though the server started correctly. |
|
WebLogic Server only supported the use of the weblogic.system.BootIdentity file with the SHUTDOWN and FORCESHUTDOWN operations of the weblogic. admin utility. The weblogic.admin utility has been enhanced to support the use of the weblogic.system.BootIdentity file with all its operations. |
|
The Certicom implementation of the SSL protocol in WebLogic Server uses a class that is synchronized by the JDK. This synchronization caused the SSL session threads to hang. The SSL implementation now uses a class that is synchronized outside of the JDK. This change resolved the SSL session thread problem. |
|
If two trusted CA certificates had the same Subject name, WebLogic SSL implementation was only using the first trusted CA certificate. This often resulted in an SSL client failing the peer certificate validation check. This problem has been resolved. Now if there are two trusted CA certificates with the same Subject name, the SSL implementation finds the appropriate trusted CA certificate for the peer certificate presented. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-72.00.jsp. |
|
The muxable socket for the embedded LDAP server was not correctly calculating the message length. The result was the data in the embedded LDAP was not replicated in a cluster of managed servers. WebLogic Server now calculates the available bytes and the LDAP messages correctly. |
|
When a context was opened during a jms call, the subject was pushed onto a stack of subjects. If the context was not closed, the subject was not removed, leaving an extra subject on the stack. When the application continued to process and at some point accessed a protected resource, the extra subject was taken from the stack as the current subject. In some cases, it did not have the required privileges, so access to the resource was denied. Closing the context removed the subject from the stack, restoring the correct subject to the top of the stack. |
|
When proxying a connection, the proxy hostname was being validated during hostname verification rather than the target system hostname, causing a validation error. |
|
When a client program was trying to establish a mutually-authenticated SSL connection to WebLogic Server, it was able to establish the connection and perform its task only once. Subsequent attempts to establish a connection were failing. |
|
When using the embedded LDAP server, membership information from both the LDAP etc/group and etc/passwd directories was not processed when group membership was determined. WebLogic Server now combines and retrieves the membership information specified in the etc/group and etc/passwd directories. |
|
When the areWebAppFilesCaseInsensitive() method was added to the Security Service Manager, the calculation of the case-setting changed for client processes. As a result, the configuration and listing of security roles and security policies for a URL resource was failing. |
|
Performance of outbound SSL connections was slowed compared to JSSE because WebLogic Server created a new SSLSocketFactory for each outbound request. WebLogic Server now caches the SSLSocketFactory when there is no certificate for the request. |
|
WebLogic Server was ignoring the weblogic.management.username command-line property. The only way to get the username was to look in the boot.properties file or to prompt the user. Code was added to so that WebLogic Server can obtain the username by using the weblogic.management.username command-line property when no boot.propertiesfile is available. WebLogic Server uses the following process to obtain the username: |
|
Certificate verification was failing because the SubjectAlternativeName extension to the x509 certificate was marked as critical. WebLogic Server now allows x509 certificates with this extension marked as critical to be verified during the SSL handshake. |
|
When the Web Application was restricted with (/*) in the web.xml file there was no constraint on access to the root directory (/). For example, if the application was foo and policy was defined for (/*) in the web.xml file, the result was that /foo was not protected. Now, WebLogic Server constrains access to the root directory (/) when the webapp is restricted with (/*) in the web.xml file. |
|
When Web browsers sent plain text through the secure port, SSL misunderstood the message header and waited for more data before finishing the message. This delay caused problems with the SSL handshake. The server was using 100%of its CPU usage trying to complete the SSL handshake. This problem was caused by an arithmetic error on the number of bytes read. This arithmetic problem has been solved. Clients that send plaintext messages to the secure port now receive errors earlier and the server will not hang because of 100% CPU utilization. |
|
When a server joined a cluster, it obtained information from other servers in the cluster for purposes of synchronization. It the cluster was configured to use only SSL ports and required client certificates to establish the SSL connection, the synchronization was failing. The problem occurred because the new server (the SSL client) was not presenting a certificate to the other servers in the cluster. |
|
When using the T3 or IIOP protocol, WebLogic Server was not propagating the Security context (javax.security.auth.Subject) between WebLogic Server instances. The WebLogic Credential Mapping provider is now called for each outbound CSIv2 session that is established from a server. The Credential Mapping provider uses the inbound CSIv2 principal instead of the AuthenticatedSubject principal to propagate the security context. Note the WebLogic Credential Mapping provider does not have access to the credentials for the inbound principal. If the credentials are required, a custom Authentication provider needs to be written to add them to the Subject so that the WebLogic Credential Mapping provider can access them. |
|
The implementation of LDAP server in WebLogic Server had connection handlers each of which ran in its own threads. However, the implementation was not starting and stopping the threads properly therefore thread memory was not being recovered. The implementation was changed so that the connection handlers no longer run as threads. This change allows normal memory recovery to take place. |
|
Connections to external LDAP servers were sometimes dropped if a load balancer or firewall was configured between WebLogic Server and the external LDAP Server. WebLogic Server now automatically refreshes the connections if they are dropped and user requests complete if the connection is dropped during the request. |
|
When an LDAP connection was dropped by the LDAP server, WebLogic obtained a new connection. However, the stale connection was not getting cleared. The stale LDAP references are now cleared correctly when using the Compatibility realm. |
|
The Certicom code was handling UTF8 incorrectly. It was treating the bytes of a String as individual characters causing a NullPointerException when Scandinavian characters are used. |
|
Two aspects of SubjectUtils.isUserInGroup were problematic.
All Principals are now gotten from the Subject and are iterated through once looking for the specified WLSGroup. A second method has been added with an AuthenticatedSubject as the first parameter. Both public isUserInGroup () methods were changed to call an internal isUserInGroup ()method that works with a set of Principals rather than any Subject. This method eliminates the need for conversion from a Subject to an AuthenticatedSubject. |
|
The persisted authenticated Subject was reusable in a second session because the validation process did not detect the configuration change. This problem was resolved by providing new functionality that re-authenticates an authenticated Subject presented during a request after a specified length of time. |
|
When Certificate Authentication was configured, Authorization was occurring even for unprotected resources. As a result, access for anonymous users was being denied. Now, when Certificate Authentication is configured, Authorization no longer occurs for unprotected resources. |
|
The weblogic.security.X500Name class now implements the Serializable method. |
|
When querying the JDBCConnection MBean from a ServletContextListener and then deploying the associated EAR from the Administration Console, a NoAccessRuntime exception was thrown even though the application was successfully deployed. |
|
WebLogic Server was not honoring an authenticated Subject when a WebLogic Server security realm interoperated with a Compatibility security realm. By default, WebLogic Server does not honor authenticated Subjects coming over the wire. The WLS User Principal Allowed attribute has been added to the WebLogic Server Administration Console. When the attribute is enabled in the WebLogic Authentication provider, WebLogic Server honors authenticated Subjects coming in over the wire. |
|
When WebLogic Server 6.1 and WebLogic Server 8.1 interoperated, an Authenticated User sent to a 8.1 server instance was not honored properly. As a result a java.rmi.AccessException was thrown. The Authenticated User was changed to an Authenticated Subject. Now, WebLogic Server 6.1 can interoperate with WebLogic Server 8.1 without a java.rmi.AccessException being thrown. |
|
The weblogic.servlet.security.CertificateServlet interface is deprecated in this release. Therefore, the Certificate Request Generator is also deprecated. Use the keytool utility from Sun Microsystems in place of the Certificate Request Generator servlet. |
|
The getLatestFailure() method no longer throws a NoSuchElementException. |