The following sections describe how to set security configuration options for a WebLogic domain:
Important Information Regarding Cross-Domain Security Support
Configuring a Domain to Use JAAS Authorization
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.This section describes important information regarding support for the cross-domain security solution.
As described in Enabling Trust Between WebLogic Server Domains, cross-domain security establishes trust between domains such that principals in a subject from one WebLogic domain can make calls in another domain. WebLogic Server establishes a security role for cross-domain users, and uses the WebLogic Credential Mapping security provider in each domain to store the credentials to be used by the cross-domain users.
In this release of WebLogic Server, subsystems such as JMS, JTA, MDB, and WAN replication implement cross-domain security. These subsystems can authenticate and send the required credentials across domains.
However, the EJB container does not implement the solution for cross-domain security. As a result, the WLS cross-domain security feature does not work in the following situations:
WLI domain
With ALSB, when ALSB is configured to use the SB and DSP transports.
ALDSP domain
For these domain types, the alternative is to use the global trust feature, in which global trust is established between two domains by using the same domain credential in each domain. For information about the global trust approach in WLS, see Enabling Global Trust.
Trust between domains is established so that principals in a Subject from one WebLogic domain can make calls in another domain. In previous releases of WebLogic Server, there was only one type of domain trust which is now referred to as Global Trust. WebLogic Server now supports a type of domain trust that is referred to as Cross Domain Security.
Note:
Please see Important Information Regarding Cross-Domain Security Support before enabling cross domain security.Cross Domain Security establishes trust between two WebLogic domain pairs by using a credential mapper to configure communication between these WebLogic domains. Configuration and use of cross-domain security is described in the following sections:
In addition to the approach that uses a Credential Mapping security provider for cross-domain security, WebLogic Server also enables a different approach, under which global trust is established between two or more domains by using the same domain credential in each domain. If you enable global trust between two or more domains, the trust relationship is transitive and symmetric. In other words, if Domain A trusts Domain B and Domain B trusts Domain C, then Domain A will also trust Domain C and Domain B and Domain C will both trust Domain A. In most cases, the Cross Domain Security approach is preferable to the global trust approach, because its use of a specific user group and role for cross-domain actions allows for finer grained security. For information about the global trust approach in WebLogic Server, see Enabling Global Trust.
To configure cross-domain security in a WebLogic domain, set the SecurityConfigurationMBean.CrossDomainSecurityEnabled attribute to true. To do this in the WebLogic Server Administration Console:
Click the name of the domain in the Domain Configurations section of the Home page.
Select Security > General.
Check Cross Domain Security Enabled.
If you maintain any WebLogic domains that have not enabled cross-domain security, you need to add their domain names to the list of excluded domains, in the SecurityConfigurationMBean.ExcludedDomainNames attributes. To do this in the WebLogic Server Administration Console:
Click the name of the domain in the Domain Configuration section of the Home page.
Select Security > General.
In the Excluded Domain Names field, enter the names of any domains that do not have cross-domain security enabled. Enter the names of these domains separated either by semicolons or line breaks.
Cross-domain security in WebLogic Server uses a global security role named CrossDomainConnector with resource type remote and a group named CrossDomainConnectors, which is assigned the CrossDomainConnector role. Invocation requests from remote domains are expected to be from users with the CrossDomainConnector role. By default, the CrossDomainConnectors group has no users as members. You need to create one or more users and add them to the group CrossDomainConnectors. Typically, such a user will be a virtual system user and preferably should have no privileges other than those granted by the CrossDomainConnector security role.
Note:
The Credential Mapper identifies domains by their names. Therefore, it is important that the domains involved have unique names.In each WebLogic domain, you need to specify a credential to be used by each user on each remote domain that needs to be trusted. Do this by configuring credential mappings for each domain in the connection. Each credential mapping needs to specify:
The resource protocol, which is named cross-domain-protocol
The name of the remote domain that needs to interact with the local domain
The name of the user in the remote domain that will be authorized to interact with the local domain
The password of the user in the remote domain that will be authorized to interact with the local domain
To configure a cross-domain security credential mapping in the WebLogic Server Administration Console, click Security Realms in the left panel.
Click the name of your security realm (default is myrealm).
Select Credential Mappings > Default, and click New.
On the Creating the Remote Resource for the Security Credential Mapping page:
Select Use cross-domain protocol.
In the Remote Domain field, enter the name of the remote domain that needs to interact with the local domain.
Click Next.
On the Create a New Security Credential Map Entry page, enter the following:
Local User: cross-domain
Remote User: User configured in the Remote Domain that is authorized to interact with the Local Domain.
Password: The password for the Remote User.
Click Finish.
See "Create a Cross-Domain Security Credential Mapping" in the Oracle WebLogic Server Administration Console Help.
Caution:
Enabling Global Trust between WebLogic domains has the potential to open the servers up to man-in-the-middle attacks. Great care should be taken when enabling trust in a production environment. Oracle recommends having strong network security such as a dedicated communication channel or protection by a strong firewall.WebLogic Server enables you to establish global trust between two or more domains. You do this by specifying the same Domain Credential for each of the domains. By default, the Domain Credential is randomly generated and therefore, no two domains will have the same Domain Credential. If you want two WebLogic domains to interoperate, you need to replace the generated credential with a credential you select, and set the same credential in each of the domains. For configuration information, see "Enable global trust between domains" in the Oracle WebLogic Server Administration Console Help.
If you enable global trust between two domains, the trust relationship is transitive and symmetric. In other words, if Domain A trusts Domain B and Domain B trusts Domain C, then Domain A will also trust Domain C and Domain B and Domain C will both trust Domain A. In most cases, the credential mapper approach, described in Enabling Cross Domain Security Between WebLogic Server Domains, is preferable to the global trust approach, because it is provides closer control over access.
Global trust between domains is established so that principals in a Subject from one WebLogic domain are accepted as principals in another domain. When this feature is enabled, identity is passed between WebLogic 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). 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 theconfig.xml file is persisted to disk.If you are enabling global 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 global trust between WebLogic 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.
To avoid these issues, Oracle recommends that rather than enabling global trust between two domains, you should instead configure users with the CrossDomainConnector role and use the credential mapping approach described in Enabling Cross Domain Security Between WebLogic Server Domains.
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 Security for Oracle WebLogic Server. 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 Oracle WebLogic Server Administration Console 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 Security for Oracle WebLogic Server.
You can also use the WebLogic Scripting Tool or Java Management Extensions (JMX) APIs to create a new security configuration.
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 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 Security for Oracle WebLogic Server.
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" in Command Reference for Oracle WebLogic Server.
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.
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 in the WebLogic Server Administration Console, select Domain > Security > General, or view the SecurityConfigurationMBean.AnonymousAdminLookupEnabled attribute.
It is important to protect passwords that are used to access resources in a WebLogic domain. In the past, usernames and passwords were stored in clear text in a WebLogic security realm. Now all the passwords in a WebLogic domain are hashed. The SerializedSystemIni.dat file contains the hashes for the passwords. It is associated with a specific WebLogic domain so it cannot be moved from domain to domain.
If the SerializedSystemIni.dat file is destroyed or corrupted, you must reconfigure the WebLogic 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.
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 Oracle WebLogic Server Administration Console 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 Default 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, see "Unlock user accounts" in the Oracle WebLogic Server Administration Console Help. Unlocking a locked user account can be done through either the WebLogic Administration Console or the clearLockout attribute on the UserLockoutManagerRuntimeMBean.
The security configuration in a WebLogic domain can be modified to use JAAS authorization, which interprets Subjects differently from the way in which the WebLogic Security Service does. For example, when a principal requests access to a resource that is protected by the Java policy provider in Oracle Platform Security Services (OPSS), the principal is compared to another principal that is built from a name contained in a policy store. (This comparison occurs when the Principal.equals() method is invoked.) If the appropriate attributes of the two principal objects match, access is granted.
Principal comparison is not used by the WebLogic Security Service to determine access decisions to protected resources. However, when principal comparison is performed in a default WebLogic domain, the comparison of principal names is case sensitive, and only the names of the principals are compared. To use JAAS authorization, the security configuration of a WebLogic domain can be modified to accommodate the following principal comparison behavior:
The comparison of principal names is case insensitive
The GUID and DN data in WebLogic principal objects are included in the comparison
To modify the security configuration of a WebLogic domain so that principal objects can be used with JAAS authorization, the following MBean attributes settings are available:
SecurityConfigurationMBean.PrincipalEqualsCaseInsensitive="true" SecurityConfigurationMBean.PrincipalEqualsCompareDnAndGuid="true"
To set these attributes in the WebLogic Server Administration Console:
In the left pane of the Console, under Domain Structure, select the domain name.
Select Configuration > Security and click Advanced.
Select the check box next to each of the following entries:
Principal Equals Case Insensitive
Principal Equals Compare DN and GUID
Note:
If a domain is configured to use the GUID and DN data in principals, there may be an impact when interoperating with other WebLogic domains, particularly older domains, resulting from changes made to the way identity is passed.For information about principal comparison in the Oracle Platform Security Service, see "Principal Name Comparison Logic" in Oracle Fusion Middleware Security Guide. For information about passing identity to a WebLogic domain, see Programming Stand-alone Clients for Oracle WebLogic Server.