The following sections provide information on how to configure secure communication between servers during a transaction:
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, performance or compatibility.
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.
Please note the following 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 JDBC data source, 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.Use the following table to determine when to use Cross Domain Security or Security Interoperability Mode:
Table 7-1 Selecting a Channel Configuration
| Channel Configuration | Advantage | Disadvantage |
|---|---|---|
|
Cross Domain Security |
|
|
|
Security Interoperability Mode |
|
|
The following sections provide information on how to configure secure communication channels between servers:
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:
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 setSecurity Interoperability Mode to performance for intra-domain communication.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:
WhenSecurity Interoperability Mode is set to performance, you are not required to set domain trust between the domains.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 12c (12.2.1)
”Configure a Credential Mapping for Cross-Domain Security” in Administering Security for Oracle WebLogic Server 12c (12.2.1)
Adding Domains to the Exclude List Based on Transaction Participation
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 12c (12.2.1).
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.
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.
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 12c (12.2.1) 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.
For transactions that have server participants in both remote and local domains, you should configure both Cross Domain Security and Security Interoperability Mode.
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.Consider the following example:
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
Assume further that the global transaction has participants ServerA1, ServerA2, ServerB1, ServerB3.
Set the security for Domain A as follows:
Cross Domain Security: enabled.
Security Interoperability Mode: performance.
No Global Trust
Set the security for Domain B as follows:
Cross Domain Security: enabled.
Security Interoperability Mode: performance.
No Global Trust
Table 7-4 shows how the resulting transactions are performed.
Table 7-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 |