|bea.com | products | dev2dev | support | askBEA|
|e-docs > WebLogic Server > Managing WebLogic Security > Configuring Security for a WebLogic Domain|
Managing WebLogic Security
Configuring Security for a WebLogic Domain
The following sections describe how to set security attributes on a WebLogic domain:
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:
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:
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:
where PrivilegedAction represents the remote operation that is to be performed with the remote credentials.
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.