Securing WebLogic Server

Configuring Security for a WebLogic Domain

The following sections describe how to set security configuration options for a WebLogic domain:

Note: These sections apply 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 Server 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.

Trust between domains is established so that principals in a Subject from one WebLogic Server domain are accepted as principals in another domain. When this feature is enabled, identity is passed between WebLogic Server domains over an RMI connection without requiring authentication in the second domain (for example: log in to Domain 1 as Joe, make an RMI call to Domain 2 and Joe is still authenticated). When inter-domain trust is enabled, transactions can commit across domains. A trust relationship is established when the Domain Credential for one domain matches the Domain Credential for another domain.

The domain credential is randomly created the first time a WebLogic Server domain is started. This process ensures that by default no two WebLogic Server domains have the same credential. To enable trust between two WebLogic Server domains, you must explicitly specify the same value for the credential in both WebLogic Server domains. In the Administration Console, use the configuration options on the Security: Advanced page under the Domains node to set domain credentials.

By default, when you boot an Administration Server for the first time, the Domain Credential is not defined. As the Administration Server boots, it notices that the Domain Credential is not defined and generates a random credential. To enable trust between two WebLogic Server domains, for each domain, prevent the generation of a random credential by:

Unchecking Enable Generated Credential.

Enter a credential in the Credential and Confirm Credential fields, using the same credential for each domain.

WebLogic Server signs Principals with the Domain Credential as Principals are created. When a Subject is received from a remote source, its Principals are validated (the signature is recreated and if it matches, the remote domain has the same Domain Credential). If validation fails, an error is generated. If validation succeeds, the Principals are trusted as if they were created locally.

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 another WebLogic Server domain, change Domain Credential in the WebLogic Server domain to the password of the system user in the WebLogic Server 6.x domain.

If you are enabling trust between domains in a Managed Server environment, you must stop the Administration Server and all the Managed Servers in both domains and then restart them. If this step is not performed, servers that were not rebooted will not trust the servers that were rebooted.

Keep the following points in mind when enabling trust between WebLogic Server domains:

Because a domain will trust remote Principals without requiring authentication, it is possible to have authenticated users in a domain that are not defined in the domain's authentication database. This situation can cause authorization problems.
Any authenticated user in a domain can access any other domain that has trust enabled with the original domain without re-authenticating. There is no auditing of this login and group membership is not validated. Therefore, if Joe is a member of the Administrators group in the original domain where he authenticated, he is automatically a member of the Administrators group for all trusted domains to which he makes RMI calls.
If Domain 2 trusts both Domain 1 and Domain 3, Domain 1 and Domain 3 now implicitly trust each other. Therefore, members of the Administrators Group in Domain 1 are members of the Administrators group in Domain 3. This may not be a desired trust relationship.
If you extended the WLSUser and WLSGroup Principal classes, the custom Principal classes must be installed in the server's classpath in all domains that share trust.

See Enable trust between domains in the Administration Console online help.

Note: You can also use the WebLogic Scripting tool or Java Management Extensions (JMX) APIs to modify your security configuration.

Using Connection Filters

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.

Connection filters are particularly useful when using the Administration port. Depending on your network firewall configuration, you may be able to use a connection filter to further restrict administration access. A typical use might be to restrict access to the Administration port to only the servers and machines in the domain. An attacker who gets access to a machine inside the firewall, still cannot perform administration operations unless the attacker is on one of the permitted machines.

WebLogic Server provides a default connection filter called weblogic.security.net.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 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 Administration Console.

To configure a connection filter:

Enable the logging of accepted messages. This Connection Logger Enabled option logs successful connections and connection data in the server. This information can be used to debug problems relating to server connections.

Choose which connection filter is to be used in the domain.

To configure the default connection filter, specify weblogic.security.net.ConnectionFilterImpl in Connection Filter.
To configure a custom connection filter, specify the class that implements the network connection filter in Connection Filter. This class must also be specified in the CLASSPATH for WebLogic Server.

Enter the syntax for the connection filter rules.

For more information:

See Configure connection filtering in the Administration Console online help.
For information about connection filter rules and writing a custom connection filter, see Using Network Connection Filters and Developing Custom Connection Filters in Programming WebLogic Security.
You can also use the WebLogic Scripting Tool or Java Management Extensions (JMX) APIs to create a new security configuration.

Using the Java Authorization Contract for Containers

The Java Authorization Contract for Containers (JACC) Standard can replace the EJB and Servlet container deployment and authorization provided by WebLogic Server. When you configure a WebLogic Server domain to use JACC, EJB and servlet authorization decisions are made by the classes in the JACC framework. All other authorization decisions within WebLogic Server are still determined by the WebLogic Security Framework. For information about the WebLogic JACC provider, see Using the Java Authorization Contract for Containers in Programming WebLogic Security.

You configure WebLogic Server to use JACC with a command line start option. For more information, see the description of the -Djava.security.manager option in the weblogic.Server Command-Line Reference.

Note that an Administration Server and all Managed Servers in a domain need to have the same JACC configuration. If you change the JACC setting on the Administration Server, you should shut down the Managed Server and reboot them with the same settings as the Administration Server to avoid creating a security vulnerability. Otherwise, it may appear that EJBs and servlets in your domain are protected by WebLogic Security Framework roles and policies, when in fact the Managed Servers are still operating under JACC.

Viewing MBean Attributes

The Anonymous Admin Lookup Enabled option specifies whether anonymous, read-only access to WebLogic Server MBeans should be allowed from the MBean API. With this anonymous access, you can see the value of any MBean attribute that is not explicitly marked as protected by the Weblogic Server MBean authorization process. This option is enabled by default to assure backward compatibility. For greater security, you should disable this anonymous access.

To verify the setting of the Anonymous Admin Lookup Enabled option through the WebLogic Administration Console, see the Domain: Security: General page in the Administration Console or the SecurityConfigurationMBean.AnonymousAdminLookupEnabled attribute.

How Passwords Are Protected in WebLogic Server

It is important to protect passwords that are used to access resources in a WebLogic Server domain. In the past, usernames and passwords were stored in clear text in a WebLogic security realm. Now all the passwords in a WebLogic Server domain are hashed. The SerializedSystemIni.dat file contains the hashes for the passwords. It is associated with a specific WebLogic Server domain so it cannot be moved from domain to domain.

If the SerializedSystemIni.dat file is destroyed or corrupted, you must reconfigure the WebLogic Server domain. Therefore, you should take the following precautions:

Make a backup copy of the SerializedSystemIni.dat file and put it in a safe location.
Set permissions on the SerializedSystemIni.dat file such that the system administrator of a WebLogic Server deployment has write and read privileges and no other users have any privileges.

Protecting User Accounts

WebLogic Server defines a set of configuration options to protect user accounts from intruders. In the default security configuration, these options are set for maximum protection. You can use the Administration Console to modify these options on the Configuration: User Lockout page.

As a system administrator, you have the option of turning off all the configuration options, increasing the number of login attempts before a user account is locked, increasing the time period in which invalid login attempts are made before locking the user account, and changing the amount of time a user account is locked. Remember that changing the configuration options lessens security and leaves user accounts vulnerable to security attacks. See Set user lockout attributes in the console online help.

Notes: The User Lockout options apply to the default security realm and all its security providers. The User Lockout options do not work with custom security providers in a security realm other than the default security realm. To use the User Lockout options with custom security providers, configure the custom security providers in the default security realm. Include the customer providers in the authentication process after the WebLogic Authentication provider and the WebLogic Identity Assertion provider. This ordering may cause a small performance hit.

If you are using an Authentication provider that has its own mechanism for protecting user accounts, disable Lockout Enabled.

If a user account becomes locked and you delete the user account and add another user account with the same name and password, the User Lockout configuration options will not be reset.

For information about unlocking a locked user account on the Administration Server, see Unlock a user account in the Administration Console online help. Unlocking a locked user account on a Managed Server cannot be done through the WebLogic Administration Console. The unlock information is propagated through a multicast message which is only configured in a cluster environment. Use the following command instead:

java weblogic.Admin -url url -username adminuser 
-password passwordforadminuser -type weblogic.mangement.security.authentication.UserLockoutManager -method clearLockout lockedusername

You can also wait the time specified in the Lockout Duration attribute: the user account will be unlocked after the specified time.