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 this release of WebLogic Server as well as deployments using Compatibility Security.

 

---

Enabling Trust Between WebLogic Domains

Note: Enabling trust between WebLogic Server domains opens the servers up to man-in-the-middle attacks. Great care should be taken when enabling trust in a production environment. BEA recommends having strong network security such as a dedicated communication channel or protection by a strong firewall.

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.

This release of WebLogic Server adds more restrictions to the trust relationship between domains. Now 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 defined. As the Administration Server boots, it notices that the Credential attribute is not defined and generates a random credential. The Administration Server uses that credential to sign principals in subjects created in that domain. The config.xml file which stores the credential is saved after the credential is generated. Managed servers in that domain obtain 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.

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 the WebLogic Server 7.0 domain 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. In the left panel of the console, select the domain name at the top of the tree.

2. Select the Security-->Advanced tab.

3. Uncheck the Enable Generated Credential attribute.

4. Click the Change... link in the Credential attribute.

5. Enter a password for the domain. Choose the password carefully. BEA Systems recommends using a combination of upper and lower case letters and numbers.

6. Confirm the password.

7. Click Apply.

8. Reboot WebLogic Server.

When using inter-domain trust with a WebLogic Server domain that uses custom Principals (meaning a custom Authentication provider is configured in the domain), the domain that is not using custom Principals must have the class for the custom Principal defined in the server's class path in order for authentication to work properly. Otherwise, a java.lang.ClassNotFound is thrown.

For example: two domains (Domain 1 and Domain 2) have established trust (meaning their domain credentials are set to the same value).

• Domain 1 has a custom Authentication provider that creates custom Principals of type myPrincipal.

• mySubject is a Subject authenticated on Domain 1 that contains a Principal of type myPrincipal.

• mySubject is passed from Domain 1 to Domain 2. Subjects are passed between domains in the following circumstances:

  • When one domain makes an RMI call over T3 to another domain.

  • When one domain makes an RMI call over IIOP and CSIv2 cannot be established.

  • A Subject is passed as a argument to a user's method.

  • When using the JMX Message bridge.

• Domain 2 must have myPrincipal defined in the server class path or a java.lang.ClassNotFound will be thrown when Domain 2 tries to deserialize the Subject.

 

---

Configuring Connection Filtering

Connection filters allow you to deny access at the network level. They can be used to protect server resources on individual servers, server clusters, or an entire internal network or Intranet. For example, you can deny any non-SSL connections originating outside of your corporate network. Network connection filters are a type of firewall in that they can be configured to filter on protocols, IP addresses, and DNS node names.

WebLogic Server provides a default connection filter called ConnectionFilterImpl. This connection filter accepts all incoming connections and also provides static factory methods that allow the server to obtain the current connection filter. To configure this connection filter to deny access, simply enter the connection filters rules in the WebLogic Server Administration Console.

You can also use a custom connection filter by implementing the classes in the weblogic.security.net package. For information about writing a connection filter, see Using Network Connection Filters in Programming WebLogic Security. Like the default connection filter, custom connection filters are configured in the WebLogic Server Administration Console.

To configure a connection filter:

1. Expand the Domains node.

2. Select the Security-->Filter tab.

3. Specify the connection filter to be used in the domain.

   • To configure the default connection filter, specify weblogic.security.net.ConnectionFilterImpl in the Connection Filter attribute field.

   • To configure a custom connection filter, specify 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 Using Network Connection Filters.

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. This attribute logs successful connections and connection data in the server. This information can be used to debug problems relating to server connections.

11. Click Apply.