Configuring Security for a WebLogic Domain

The following sections describe how to set security attributes on a WebLogic domain:

• Enabling Trust Between WebLogic Domains
• Configuring Connection Filtering

Note: This chapter applies to WebLogic Server deployments using the security features in WebLogic Server 7.0 as well as deployments using Compatibility Security.

 

---

Enabling Trust Between WebLogic Domains

A trust relationship is established when principals in a Subject from one WebLogic Server domain (referred to as the domain) are accepted as principals in the local domain.

In WebLogic Server 6.x, the trust relationship between two WebLogic Server domains was established if the system password was the same in both domains. The user identity was not checked after initial authentication. So you could authenticate to the trusted remote domain as joeuser and then perform operations locally as joeuser even though you had not authenticated to the local domain as joeuser.

WebLogic Server 7.0 adds more restrictions to the trust relationship between domains. In WebLogic Server 7.0, a trust relationship is established when the Credential attribute for one domain matches the Credential attribute for another domain.

By default, when you boot an Administration Server for the first time, the Credential attribute is not set. As the Administration Server boots, it notices that the Credential attribute is not set and generates a random credential. The Administration Server uses that credential to sign Principals in Subjects created in that domain. After some period of time (immediately if the Credential attribute on the embedded LDAP server is not set), the config.xml file is persisted to disk. Managed servers in that domain download the credential from the Administration Server when booting.

WebLogic Server performs a validation (comparing how the Principal was signed with how a local Principal would be signed) whenever the code is asked to create a new Subject.

If a WebLogic Server 7.0 deployment is acting as a client and authenticates to another domain, the Credential attributes of the two domains must match.

Note: Any credentials in clear text are encrypted the next time the config.xml file is persisted to disk.

If you want a WebLogic Server 6.x domain to interoperate with a WebLogic Server 7.0 domain, change the Credential attribute in both domains to the password of the system user in the WebLogic Server 6.x domain.

If you want two 7.0 domains to interoperate, perform the following procedure in both domains.

To establish a trust relationship between WebLogic Server domains:

1. Expand the Domains node.
2. Select the Security-->Advanced tab.
3. Click the Change... link in the Credential attribute.
4. Enter a password for the domain. Choose the password carefully. BEA Systems recommends using a combination of upper and lower case letters and numbers.
5. Confirm the password.
6. Click Apply.
7. Reboot WebLogic Server.

 

---

Configuring Connection Filtering

Create connection filters that allow you to reject or accept client connections based on the client's origin and protocol thus adding an additional level of security. For example, write a connection filter that rejects any non-SSL connections originating outside of your corporate network. After a client connects, and before any work is performed on its behalf, WebLogic Server passes the client's IP number and port, protocol (HTTP, HTTPS, T3, T3S, or IIOP), and WebLogic Server port number to the connection filter. By examining this information, you can choose to allow the connection or throw a Filter Exception to terminate it.

For information about writing a connection filter, see Writing a Network Connection Filter in Programming WebLogic Security.

To configure a connection filter:

1. Expand the Domains node.
2. Select the Security-->Filter tab.
3. Enter the class that implements the network connection filter in the Connection Filter attribute. This class must also be specified in the CLASSPATH for WebLogic Server.
4. Enter the syntax for the connection filter rules. For more information about connection filter rules, see Writing a Network Connection Filter in Programming WebLogic Security.
5. Click Apply.
6. Reboot WebLogic Server.
7. Expand the Domains node.
8. Click the Security tab.
9. Click the Advanced tab.
10. Click the Connection Logger Enabled attribute to enable the logging of accepted messages.
11. Click Apply.

When WebLogic Server acts a client to an untrusted WebLogic Server (for example, a server in a different domain), the remote credentials cannot be used for accessing locally protected resources. When running WebLogic Server 6.x code on WebLogic Server 7.0, this behavior is seen after using a JNDI InitialContext to perform remote operations and then attempting to use the same JNDI InitialContext to perform local operations.

When local and remote operations are required at the same time on the same server, the following options are available:

1. Use to the Java Authentication and Authorization Service (JAAS) Authentication available in WebLogic Server 7.0. In JAAS, remote credentials are supplied via a JAAS LoginModule. Use the following method to access the resulting Subject:

   weblogic.security.Security.runAs(Subject, PrivilegedAction)

   where PrivilegedAction represents the remote operation that is to be performed with the remote credentials.

2. After establishing the JNDI InitialContext, use the following method to obtain the remote credentials as a JAAS Subject:

   weblogic.security.Security.getCurrentSubject()

   After using the remote credentials, close the JNDI InitialContext and use the Subject as described in Option 1.

Note: The JNDI method of pass security credentials in an InitialContext was deprecated in WebLogic Server 6.x.