Configuring Secure Inter-Domain and Intra-Domain Transaction Communication

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.
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 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, as settings are set at the domain level.
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 7-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. If Admin channel is configured and the Security Interoperability Mode is set to `default`, messages are forwarded using kernel identity. If Admin channel is not configured, the `default` Interoperability Mode behaves the same as the `performance` Interoperability Mode, where messages are forwarded using anonymous user.	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 `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.

Cross Domain Security

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:

Enabling Cross Domain Security Between WebLogic Server Domains in Administering Security for Oracle WebLogic Server
Configure a Credential Mapping for Cross-Domain Security in Administering Security for Oracle WebLogic Server
Adding Domains to the Exclude List Based on Transaction Participation

Important Considerations When Configuring Cross Domain Security

When configuring Cross Domain Security, consider the following guidelines:

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

Set cross-domain security in DomainA for DomainB
Set cross-domain security in DomainB for DomainA
Set cross-domain security in DomainA for DomainC
Set cross-domain security in DomainC for DomainA
Set cross-domain security in DomainB for DomainC
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 7-2. A table cell containing Yes indicates that you must configure cross domain security for this domain combination.

Table 7-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 7-3. A table cell containing Yes indicates that you must configure cross domain security for this domain combination.

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

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.