8 Configuring Secure Inter-Domain and Intra-Domain Transaction Communication

Learn about secure inter-domain and intra-domain communication and how to configure these secure communication between servers during a transaction.

What is Secure Inter-Domain and Intra-Domain Transaction Communication?

In a transaction communication if the participating servers are within the same domain it is an intra-domain communication. When the servers participating in transactions are not in the same domain then it is an inter-domain communication.

For a transaction manager to manage distributed transactions, the transaction manager must be able to communicate with all participating servers and resources to prepare and then commit or rollback the transactions. How a communication channel is configured depends on whether the transaction route is:

  • Intra-domain—The transaction communication is between servers participating in transactions within the same domain. You must correctly configure compatible communication channels between servers participating in transactions within the same domain using Security Interoperability Mode. See Security Interoperability Mode.

    Set participating servers to either default or performance.

  • Inter-domain—The transaction communication is between servers participating in transactions that are not in the same domain. You must correctly configure compatible communication channels using either Cross Domain Security or Security Interoperability Mode for all participating domains in global transactions.

Communication channels must be secure to prevent a malicious third-party from using man-in-the-middle attacks to affect transaction outcomes and potentially gaining administrative control over one or more domains.

Requirements for Transaction Communication

There are certain requirements when configuring communication channels for your transaction environment.

  • The domains and all participating resources must have unique names. That is, you cannot have a server or a domain with the same name as an object in another domain or the domain itself.

  • Keep all the domains used by your process symmetric with respect to Cross Domain Security configuration and Security Interoperability Mode. Because both settings are set at the domain level, it is possible for a domain to be in a mixed mode, meaning the domain has both Cross Domain Security and Security Interoperability Mode set.

  • Configure one-way SSL to provide additional communication security to protect the transaction from a man-in-the-middle attack.

  • Only one data source with both of the following attribute conditions participate in a global transaction, regardless of the domain in which the data source is configured:

    • Logging Last Resource or Emulate two-phase Commit is selected.

    • The data source uses a non-XA driver to create database connections.

    Note:

    If more than one LLR or JTS resource participate in a global transaction, naming conflicts will cause the global transaction to fail.

How to Determine the Communication to Use for Inter-Domain Transactions

Use the following table to determine the usage of Cross Domain Security or Security Interoperability Mode:

Table 8-1 Selecting a Channel Configuration

Channel Configuration Advantage Disadvantage

Cross Domain Security

  • Specific users are configured to establish communication between a domain pair.

  • With SSL, prevents man-in-the-middle attacks.

  • More complex configuration.

  • Any change to the transaction flow, such as changing participants, participant roles (coordinator versus resource or subcoordinator), adding or removing a domain, or changing the transaction route, requires a configuration change.

Security Interoperability Mode

  • Very easy to configure.

  • No need to understand the transaction flow when configuring Security Interoperability Mode.

  • When in default mode, using the Admin channel prevents man-in-the-middle attacks.

  • All domains that have servers that participate in the global transaction have the same domain trust. This is not as secure as in Cross Domain Security where the trust is established only between a domain pair.

  • When set to compatibility, inter-domain trust grants administrator privileges across domains. That is, with trust established between domains, an Administrator in Domain A has administrator privileges in Domain B.

  • When set to performance, you are not required to set domain trust between the domains.

  • In some configurations, there is a narrow possibility of man-in-the-middle attacks.

Configuring Secure Channel Communication

Learn how to configure secure communication channels between servers.

Security Interoperability Mode

Security Interoperability Mode enables you to configure compatible communication channels between servers in global transactions with participants in the same domain (intra-domain) or in different domains (inter-domain). Trust is established between all the domains that participate in a transaction by setting the security credential of all domains to the same value so that principals in a Subject from one WebLogic Server instance are accepted as principals in another instance. Some settings of Security Interoperability Mode rely on domain trust and are less secure.

Use the following steps to configure Security Interoperability Mode:

  1. Configuring Security Interoperability Mode

  2. Establish Domain Trust

Note:

The compatibility setting for JTA Security Interoperability Mode is deprecated in this release of WebLogic Server and will be removed in a future release.

Configuring Security Interoperability Mode

Every participating server must set the Security Interoperability Mode parameter to the same value:

Valid values are:

  • default—The transaction coordinator makes calls using the kernel identity over an Admin channel if it is enabled. If the Admin channel is not configured, the Security Interoperability Mode behavior is the same as using performance.

  • performance—The transaction coordinator always makes calls using anonymous. This implies a security risk when communicating with servers that are in a remote domain because a malicious third party could then try to affect the outcome of transactions using a man-in-the-middle attack.

  • compatibility—The transaction coordinator makes calls as the kernel identity over a non-secure channel. This mode is required when interacting with WebLogic Servers servers that do not support Security Interoperability Mode. This is a high security risk because a successful man-in-the-middle attack would allow the attacker to gain administrative control over both domains. This setting should only be used when strong network security is in place.

To configure Security Interoperability Mode for participating servers, see “Configure security interoperability mode" in the Oracle WebLogic Server Administration Console Online Help.

Note:

Using the Admin channel for intra-domain transaction communication does not provide additional security. Oracle recommends that you set Security Interoperability Mode to performance for intra-domain communication.

Establish Domain Trust

For some settings of Security Interoperability Mode , you need to configure domain trust.

Establish domain trust by setting a security credential for all domains to the same value in all participating domains. See “Enable trust between domains" in Oracle WebLogic Server Administration Console Online Help.

When establishing domain trust, all domains use the same credentials. If one domain in your environment can no longer be trusted, you are required to reconfigure domain trust in all of the remaining domains.

Note:

When Security Interoperability Mode is set to performance, you are not required to set domain trust between the domains.

Cross Domain Security

Cross Domain Security uses a credential mapper to enable you to configure compatible communication channels between remote servers in global transactions. For every domain pair that participates in a transaction, a credential mapper is configured. Every domain pair has a different set of credentials which belong to the CrossDomainConnector security role.

Although it requires a more complex configuration, Cross Domain Security enables you to tailor trust between individual domains. As described in Cross Domain Security Between WebLogic Server Domains, subsystems such as JMS, JTA, MDB, and WAN replication implement cross-domain security. (The EJB container does not implement the solution for cross-domain security.)

See:

Important Considerations When Configuring Cross Domain Security

When configuring Cross Domain Security, consider the following guidelines:

Note:

When you enable Cross Domain Security for inter-domain communication, and you also have WebLogic servers participating in the transaction that are in the same domain (intra-domain communication), Oracle recommends you set Security Interoperability Mode to performance for transaction communication.

  • Domain trust is not required for Cross Domain Security.

  • For every domain pair that participates in a transaction, a credential mapper must be correctly configured having a set of credentials which belong to the CrossDomainConnector security role. If the credential mapping is not correct, transactions across the participating domains fail. See Configure a Credential Mapping for Cross-Domain Security in Administering Security for Oracle WebLogic Server.

  • To interoperate with WebLogic domains that either do not support Cross Domain Security or have Cross Domain Security disabled, you must add these domains to the Excluded Domain Names list of every participating WebLogic Server domain that has Cross Domain Security enabled. If the configuration of the Excluded Domain Names list and the CrossDomainSecurityEnabled flag is not consistent in all participating domains, branches of the transaction fail.

  • If Cross Domain Security Enabled flag is disabled or the domain is in the Excluded Domain Names list, then Security Interoperability Mode is used to establish communication channels for participating domains.

  • If Cross Domain Security Enabled flag is enabled and the transaction has participating servers that are remote and local, Cross Domain security will be used for RMI communication with the remote servers but Security Interoperability Mode will be used for RMI communication with server participants that are in the local domain.

  • When enabling or disabling the Cross Domain Security Enabled flag, there may be a period of time where transactions or other remote calls can fail. For transactions, if the commit request fails, the commit is retried after the configuration change is complete. If a transaction RMI call fails during any other request, then the transaction times out and the transaction is rolled back. The rollback is retried until AbandonTimeoutSeconds.

Cross Domain Security is Not Transitive

Servers participating in a transaction set cross-domain credential mapping with each other.

Unlike domain-trust, the cross domain security configuration is not transitive; that is, because A trusts B and B trusts C, it is not therefore also true that A trusts C.

Consider the follow scenario:

  • DomainA has Server1 (coordinator)

  • DomainB has Server2 (sub-coordinator)

  • DomainC has Server3 and Server4 (Server3 is a sub-coordinator)

  • DomainD has Server5 (does not participate in the transaction)

To set the cross-domain credential mapping in this scenario, do the following:

  1. Set cross-domain security in DomainA for DomainB

  2. Set cross-domain security in DomainB for DomainA

  3. Set cross-domain security in DomainA for DomainC

  4. Set cross-domain security in DomainC for DomainA

  5. Set cross-domain security in DomainB for DomainC

  6. Set cross-domain security in DomainC for DomainB

Because DomainD does not participate in the transaction, using cross-domain credential mapping is not required. However, see Adding Domains to the Exclude List Based on Transaction Participation for further clarification.

To present this information in another way, consider Table 8-2. A table cell containing Yes indicates that you must configure cross domain security for this domain combination.

Table 8-2 Setting Cross Domain Security with Three Participating Domains

DomainA DomainB DomainC DomainD

DomainA

NA

Yes

Yes

No

DomainB

Yes

NA

Yes

No

DomainC

Yes

Yes

NA

No

DomainD

No

No

No

NA

If you were then to add DomainD and leave a DomainE out of the cross-domain security configuration, the cross-domain credential map would be as shown in Table 8-3. A table cell containing Yes indicates that you must configure cross domain security for this domain combination.

Table 8-3 Setting Cross Domain Security with Five Participating Domains

DomainA DomainB DomainC DomainD DomainE

DomainA

NA

Yes

Yes

Yes

No

DomainB

Yes

NA

Yes

Yes

No

DomainC

Yes

Yes

NA

Yes

No

DomainD

Yes

Yes

Yes

NA

No

DomainE

No

No

No

No

NA

Adding Domains to the Exclude List Based on Transaction Participation

The exclude list provides a mechanism for a server in a domain with Cross Domain Security configured to participate in a transaction with a server in another domain that does not support or have Cross Domain Security enabled.

If any server in a domain in which cross domain security is not configured participates in a transaction with any server in a domain in which cross domain security is configured, add that domain to the exclude list of the domain that has cross domain security configured. Security Interoperability Mode is used to establish communication channels for participating domains as described in Important Considerations When Configuring Cross Domain Security.

You do not need to add the domain to the exclude list of all domains that have cross domain security configured; the domain must explicitly participate in a transaction with the domain in question for this requirement to take effect.

Note:

You may find it more convenient to add the names of all domains for which cross-domain security is not enabled to the list of excluded domains. If you exclude only those domains that do not participate in transactions, the exclusions may be sufficient only in the case of transactions. As described in ”Excluding Domains From Cross-Domain Security”, in Administering Security for Oracle WebLogic Server the more common use case is to exclude all domains for which cross-domain security is not enabled.

Consider the following scenario:

  • Transaction #1:

    • DomainA has Server1 (coordinator)

    • DomainB has Server2 (sub-coordinator)

    • DomainC has Server3 and Server4 (Server3 is a sub-coordinator)

    • DomainD has Server5 (does not participate in the transaction, cross-domain security not configured)

  • Transaction #2:

    • DomainB has Server6 (coordinator)

    • DomainD has Server5 (sub-coordinator, cross-domain security not configured)

In this case DomainD has to be in the exclusion list of DomainB because of Transaction #2.

You do not need to include it in the exclusion list of DomainA or DomainC because DomainD does not participate in any transactions with servers in these two domains.

Configuring a Combination of Cross Domain Security and Security Interoperability Mode

For transactions that have server participants in both remote and local domains, you should configure both Cross Domain Security and Security Interoperability Mode.

Note:

The compatibility setting for JTA Security Interoperability Mode is deprecated in this release of WebLogic Server and will be removed in a future release.

Consider the following example:

  1. Assume that you have two domains, Domain A and Domain B, with servers as follows:

    • Domain A: ServerA1, ServerA2, ServerA3

    • Domain B: ServerB1, ServerB2, ServerB3

  2. Assume further that the global transaction has participants ServerA1, ServerA2, ServerB1, ServerB3.

  3. Set the security for Domain A as follows:

    • Cross Domain Security: enabled.

    • Security Interoperability Mode: performance.

    • No Global Trust

  4. Set the security for Domain B as follows:

    • Cross Domain Security: enabled.

    • Security Interoperability Mode: performance.

    • No Global Trust

Table 8-4 shows how the resulting transactions are performed.

Table 8-4 Transactions with Remote and Local Servers

ServerB1 ServerB3 ServerA1 ServerA2

ServerA1

Cross Domain Security

Cross Domain Security

NA

Security Interoperability Mode

ServerA2

Cross Domain Security

Cross Domain Security

Security Interoperability Mode

NA

ServerB1

NA

Security Interoperability Mode

Cross Domain Security

Cross Domain Security

ServerB3

Security Interoperability Mode

NA

Cross Domain Security

Cross Domain Security

Note:

For inter-domain communication, Cross Domain Security always has precedence over Security Interoperability Mode when both are configured. If Security Interoperability Mode is set such that the admin channel is used for transaction communication, Cross Domain Security is used for inter-domain communication.