42 Configuring 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. Learn how to set security configuration options that enables cross-domain security in Oracle WebLogic Server.

These sections apply to WebLogic Server deployments using the security features in this release of WebLogic Server.

Note:

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.

Enabling Trust Between WebLogic Server Domains

WebLogic Server supports cross-domain security that establishes trust between two 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.

Previous releases of WebLogic Server supported domain trust, which is now referred to as global trust. 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.

  • Domain B and Domain C will both trust Domain A.

The principal distinction between the two approaches is that cross-domain security enables trust between two domains using specific credentials. By comparison, in global trust, the same credentials are used to communicate among all domains.

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.

Note:

If you enable cross-domain security to communicate between two domains, you should not enable global trust for those domains.

Cross-domain security provides more secure communication between two domains.

The following sections explain how to configure each domain trust type:

Enabling Cross-Domain Security Between WebLogic Server Domains

Note:

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.

Configuration and use of cross-domain security is described in the following sections:

Configuring Cross-Domain Security

You configure cross-domain security between two domains — a domain pair — such that principals in a subject from one WebLogic domain can make calls in another domain. You can enable cross-domain security for multiple domain pairs.

For example, assume you have four domains, Domain1 through Domain4. You can enable cross-domain security on all four domains, and then add users and credential maps (as described in subsequent sections) for the following domain pairs:

  • Domain1 - Domain2

  • Domain1 - Domain3

  • Domain1 - Domain4

  • Domain2 - Domain3

  • Domain2 - Domain4

  • Domain3 - Domain4

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:

  1. In the left pane of the Console, under Domain Structure, select the domain name.
  2. Select Security.
  3. Check Cross Domain Security Enabled.
Excluding Domains From Cross-Domain Security

If you enable cross-domain security for some, but not all, of the domains you administer, you need to add the names of the domains for which cross-domain security is not enabled to the list of excluded domains in the SecurityConfigurationMBean.ExcludedDomainNames attributes.

You must do this in each of the WebLogic domains in which you did enable cross-domain security.

For example, if you have four domains, Domain1 through Domain4 and for some reason you do not enable cross-domain security on Domain4, you need to specify Domain4 for the SecurityConfigurationMBean.ExcludedDomainNames attribute in Domain1, Domain2, and Domain3.

To do this using the WebLogic Server Administration Console:

  1. In the left pane of the Console, under Domain Structure, select the domain name.
  2. Select Security.
  3. 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.
  4. Repeat steps one through three, as appropriate, for each domain.
Configuring Cross-Domain Users

Cross-domain security in WebLogic Server uses a global security role named CrossDomainConnector with resource type remote and a group named CrossDomainConnectors. Invocation requests from remote domains are expected to be from users who are mapped to the CrossDomainConnector role.

By default, the CrossDomainConnectors group has no users as members.

For each domain in which you enable cross-domain security, you need to create a user and add that user to the CrossDomainConnectors group. Typically, such a user is a virtual system user and preferably should have no privileges other than those granted by the CrossDomainConnector security role.

For example, assume that you enabled cross-domain security on Domain1, Domain2, Domain3, and Domain4. In each case, create the user account with a password and assign it to the CrossDomainConnectors group.

  • In Domain1, create a user User1.

  • In Domain2, create User2.

  • In Domain3, create User3.

  • In Domain4, create User4.

To add a user in the WebLogic Server Administration Console:

  1. In the left pane of the Console, under Domain Structure, select Security Realms.
  2. Select the name of the security realm.
  3. Select the Users and Groups page.
  4. Click New.
  5. Enter the name and password for the user. You can accept the Default Authenticator provider.
  6. Click OK.
  7. Select the user you just created from the list of users.
  8. Select the Groups page.
  9. Select CrossDomainConnectors from the available groups list, and move it to the Chosen list.
  10. Click Save.
Configure a Credential Mapping for Cross-Domain Security

Note:

The Credential Mapper identifies domains by their names. Therefore, it is important that the domains involved have unique names.

In the domain pairs for which you enabled cross-domain security, you need to specify a credential to be used by each user on the remote domain to be trusted. Do this by configuring credential mappings for each domain pair 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

For example, to extend the user example from Configuring Cross-Domain Users, you would configure the following domain pairs:

Note:

If you have a several domains to configure, you may find it easier to configure one pair of domains, then configure the next pair, and so forth.

  • Populate the credential map in Domain1 with the remote-domain: Domain2, the remote-user: User2, and the remote_user_pass: password-for-User2.

    Populate the credential map in Domain2 with the remote-domain: Domain1, the remote-user: User1, and the remote_user_pass: password-for-User1.

  • Populate the credential map in Domain1 with the remote-domain: Domain3, the remote-user: User3, and the remote_user_pass: password-for-User3.

    Populate the credential map in Domain3 with the remote-domain: Domain1, the remote-user: User1, and the remote_user_pass: password-for-User1.

  • Populate the credential map in Domain1 with the remote-domain: Domain4, the remote-user: User4, and the remote_user_pass: password-for-User4.

    Populate the credential map in Domain4 with the remote-domain: Domain1, the remote-user: User1, and the remote_user_pass: password-for-User1.

  • Populate the credential map in Domain2 with the remote-domain: Domain3, the remote-user: User3, and the remote_user_pass: password-for-User3.

    Populate the credential map in Domain3 with the remote-domain: Domain2, the remote-user: User2, and the remote_user_pass: password-for-User2.

  • Populate the credential map in Domain2 with the remote-domain: Domain4, the remote-user: User4, and the remote_user_pass: password-for-User4.

    Populate the credential map in Domain4 with the remote-domain: Domain2, the remote-user: User2, and the remote_user_pass: password-for-User2.

  • Populate the credential map in Domain3 with the remote-domain: Domain4, the remote-user: User4, and the remote_user_pass: password-for-User4.

    Populate the credential map in Domain4 with the remote-domain: Domain3, the remote-user: User3, and the remote_user_pass: password-for-User3.

To configure a cross-domain security credential mapping in the WebLogic Server Administration Console, click Security Realms in the left panel.

  1. Click the name of your security realm (default is myrealm).
  2. Select Credential Mappings > Default, and click New.
  3. 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.

  4. Click Next.
  5. 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.

  6. Click Finish.
  7. Repeat steps one through six as needed.

For additional help with this task, see Create a Cross-Domain Security Credential Mapping in the Oracle WebLogic Server Administration Console Online Help.

Enabling Global Trust

Note:

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.

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.

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 Online 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.

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 the config.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 1 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 use the approach described in Enabling Cross-Domain Security Between WebLogic Server Domains.

Using the Java Authorization Contract for Containers

As of version 12.2.1, WebLogic Server supports the Java Authorization Contract for Containers (JACC) Standard, Version 1.5. JACC can replace the EJB and servlet container deployment and authorization provided by WebLogic Server. Configure WebLogic Server to use JACC by using the command-line utility.

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 Developing Applications with the WebLogic Security Service.

You configure WebLogic Server to use JACC by specifying the following properties in the command that starts WebLogic Server:

-Djavax.security.jacc.PolicyConfigurationFactory.provider
-Djavax.security.jacc.policy.provider
-Dweblogic.security.jacc.RoleMapperFactory.provider

For more information about these specifying these properties, see Enabling the WebLogic JACC Provider in Developing Applications with the WebLogic Security Service.

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

Use the SecurityConfigurationMBean.AnonymousAdminLookupEnabled attribute to control whether anonymous, read-only access should be allowed to WebLogic Server MBeans from the MBean API.

The Anonymous Admin Lookup Enabled option in the 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.

Configuring a Domain to Use JAAS Authorization

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.

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:

  1. In the left pane of the Console, under Domain Structure, select the domain name.
  2. Select Configuration > Security and click Advanced.
  3. 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 passing identity to a WebLogic domain, see Developing Standalone Clients for Oracle WebLogic Server.