WebLogic Tuxedo Connector Administration

Note: For more detailed reference information on the WebLogic Tuxedo Connector MBean attributes, see WebLogic Tuxedo Connector MBean Attributes.

The following sections describe how to establish connectivity and provide security between domains in the WebLogic Server and Tuxedo environments. The WebLogic Tuxedo Connector MBeans attributes are analogous to the interoperability attributes required for the communication between Tuxedo domains.

The following sections provide WebLogic Tuxedo Connector configuration information:

• Configuring the Connections Between Domains

• How ConnectionPolicy Affects Dynamic Status

• Configuring Domains-level Failover and Failback

• Authentication of Remote Domains

• User Authentication

• How to Configure WebLogic Tuxedo Connector to Provide Security between Tuxedo and WebLogic Server

• Example ACL Policy for Simpapp and Simpserv Examples

• Link-Level Encryption

 

---

Configuring the Connections Between Domains

Note: For more information on Dynamic Status, see How ConnectionPolicy Affects Dynamic Status.

Several options can specify the conditions under which a local domain gateway tries to establish a connection with a remote domain. Specify these conditions using the ConnectionPolicy attribute in the WTCLocalTuxDom MBean and WTCRemoteTuxDom MBean. You can select any of the following connection policies:

• How to Request a Connection at Boot Time (ON_STARTUP)

• How to Request Connections for Client Demands (ON_DEMAND)

• Accepting Incoming Connections (INCOMING_ONLY)

• How to use LOCAL Connection Policy

For connection policies of ON_STARTUP and INCOMING_ONLY, Dynamic Status is invoked. Dynamic Status checks and reports on the status of imported services associated with each remote domain.

How to Request a Connection at Boot Time (ON_STARTUP)

A policy of ON_STARTUP means that a domain gateway attempts to establish a connection with its remote domain access points at gateway server initialization time. The connection policy retries failed connections at regular intervals determined by the RetryInterval parameter and the MaxRetries parameter. To request a connection at boot time, set the WTCLocalTuxDom MBean connection policy to ON_STARTUP.

How to Configure RetryInterval

You can control the frequency of automatic connection attempts by specifying the interval (in seconds) during which the gateway should wait before trying to establish a connection again. The minimum value is 0; the default value is 60, and maximum value is 2147483647.

How to Configure MaxRetries

Note: Use only when ConnectionPolicy is set to ON_STARTUP. For other connection policies, retry processing is disabled.

You indicate the number of times a domain gateway tries to establish connections to remote domain access points before quitting by assigning a value to the MaxRetries parameter: the minimum value is 0; the default and maximum value is 2147483647.

• If you set MaxRetries to 0, automatic connection retry processing is turned off. The server does not attempt to connect to the remote gateway automatically.

• If you set MaxRetries to a number, the gateway tries to establish a connection the specified number of times before quitting.

• If you set MaxRetries to 2147483647, retry processing is repeated indefinitely or until a connection is established.

  Table 3-1 Example Settings of MaxRetries and RetryInterval Parameters

  If you set ...	Then ...
  ConnectionPolicy: ON_STARTUP RetryInterval: 30 MaxRetries: 3	The gateway makes 3 attempts to establish a connection, at 30 seconds intervals, before quitting.
  ConnectionPolicy: ON_STARTUP MaxRetries: 0	The gateway attempts to establish a connection at initialization time but does not retry if the first attempt fails.
  ConnectionPolicy: ON_STARTUP RetryInterval: 30	The gateway attempts to establish a connection every 30 seconds until a connection is established.

  
   

How to Request Connections for Client Demands (ON_DEMAND)

Note: If the ConnectionPolicy is not specified, the WebLogic Tuxedo Connector uses a ConnectionPolicy of ON_DEMAND.

A connection policy of ON_DEMAND means that a connection is attempted only when requested by either a client request to a remote service or an administrative connect command.

Accepting Incoming Connections (INCOMING_ONLY)

A connection policy of INCOMING_ONLY means that a domain gateway does not establish a connection to remote domains upon starting. The domain gateway is available for incoming connections from remote domain access points and remote services are advertised when the domain gateway receives an incoming connection.

How to use LOCAL Connection Policy

Note: A ConnectionPolicy of LOCAL is not valid for local domains.

A connection policy of LOCAL indicates that a remote domain connection policy is explicitly defaulted to the local domain ConnectionPolicy attribute value. If the remote domain ConnectionPolicy is not defined, the system uses the setting specified by the associated local domain using the LocalAccessPoint.

 

---

How ConnectionPolicy Affects Dynamic Status

Dynamic Status determines the availability of remote services. The connection policy used in the WebLogic Tuxedo Connector configuration file determines whether the Dynamic Status feature is available for a service. The following table describes how ConnectionPolicy affects Dynamic Status capability.

ON_STARTUP	Dynamic Status is on. Services imported from a remote domain are advertised while a connection to that remote domain exists.
ON_DEMAND	Dynamic Status is off. Services imported from remote domains are always advertised.
INCOMING_ONLY	Dynamic Status is on. Remote services are initially suspended. The domain gateway is available for incoming connections from remote domains. Remote services are advertised when the local domain gateway receives an incoming connection.

 

 

---

Configuring Domains-level Failover and Failback

Note: In the Tuxedo T/ Domain, there is a limit of 2 backup remote domains. The WebLogic Tuxedo Connector has no limit to the number of backup domains allowed to be configured for a service.

WebLogic Tuxedo Connector provides a domains-level failover mechanism that transfers requests to alternate remote domains when a failure is detected with a primary remote domain. It also provides failback to the primary remote domain when that domain is restored.

This level of failover/failback depends on Dynamic Status. The domain must be configured with a CONNECTION_POLICY of ON_STARTUP or INCOMING_ONLY to enable Domains-level failover/failback.

Domains-level failover/failback defines a remote domain as available when a network connection to the remote domain exists, and unavailable when a network connection to the remote domain does not exist.

Prerequisite to Using Domains-level Failover and Failback

To use Domains-level failback, you must specify ON_STARTUP or INCOMING_ONLY as the value of the CONNECTION_POLICY parameter.

A connection policy of ON_DEMAND is unsuitable for Domains-level failback as it operates on the assumption that the remote domain is always available. If you do not specify ON_STARTUP or INCOMING_ONLY as your connection policy, your servers cannot fail over to the alternate remote domains that you have specified with the Tuxedo RDOM parameter.

Note: A remote domain is available if a network connection to it exists; a remote domain is unavailable if a network connection to it does not exist.

How to Configure Domains to Support Failover

To support failover, you must specify the remote domains responsible for executing a particular service. You must specify the following in your WTCServer MBean:

• Create a WTCRemoteTuxDom MBean for each remote domain.

• Create a WTCImport MBean that specifies the service provided by each remote domain.

Suppose a service, TOUPPER, is available from two remote domains: TDOM1 and TDOM3. Your WTCServer Mbean would include two WTCRemoteTuxDom MBeans and two WTCImport MBeans. The WTCServer Mbean in your config.xml file would contain the following:

<WTCServer Name="WTCsimpapp" 
     <WTCExport EJBName="tuxedo.services.TOLOWERHome"
           LocalAccessPoint="TDOM2" Name="myExportedResources"           ResourceName="TOLOWER"/>
     <WTCImport LocalAccessPoint="TDOM2" Name="myImportedResources"
          RemoteAccessPointList="TDOM1" ResourceName="TOUPPER"/>
     <WTCImport LocalAccessPoint="TDOM2" Name="2ndImportedResources"
          RemoteAccessPointList="TDOM3" ResourceName="TOUPPER"/>
     <WTCLocalTuxDom AccessPoint="TDOM2" AccessPointId="TDOM2"
          ConnectionPolicy="ON_DEMAND" Interoperate="no"
          NWAddr="//123.123.123.123:5678" Name="myLoclTuxDom" Security="NONE"/>
     <WTCRemoteTuxDom AccessPoint="TDOM1" AccessPointId="TDOM1"
           LocalAccessPoint="TDOM2" NWAddr="//123.123.123.123:1234"           Name="myRTuxDom"/>
     <WTCRemoteTuxDom AccessPoint="TDOM3" AccessPointId="TDOM3"
           LocalAccessPoint="TDOM2" NWAddr="//234.234.234.234:5555"           Name="2ndRemoteTuxDom"/>
</WTCServer>

How to Configure Domains to Support Failback

Failback occurs when a network connection to the primary remote domain is reestablished for any of the following reasons:

• Automatic retries (ON_STARTUP only)

• Incoming connections

 

---

Authentication of Remote Domains

Note: Tuxedo 6.5 users should set the Interoperate parameter to Yes.

Domain gateways can be made to authenticate incoming connections requested by remote domains and outgoing connections requested by local domains. Application administrators can define when security should be enforced for incoming connections from remote domains. You can specify the level of security used by a particular local domain by setting the SECURITY parameter in the WTCLocalTuxDom MBean of your WTCServer Mbean. There are three levels of password security:

• No Security (using the NONE option)—incoming connections from remote domains are not authenticated.

• Application Password (using the APP_PW option)— incoming connections from remote domains are authenticated using the application password defined in the WTCPassword MBean of your WTCServer Mbean. You use the weblogic.wtc.gwt.genpasswd utility to create encrypted application passwords.

• Remote Domains Password (using the DM_PW option)—this feature enforces security between two or more domains. Connections between the local and remote domains are authenticated using password pairs defined in the WTCPassword MBean of your WTCServer Mbean. You use the weblogic.wtc.gwt.genpasswd utility to create encrypted local and remote passwords.

The SECURITY parameter in the WTCLocalTuxDom MBean of your WTCServer Mbean must match the SECURITY parameter of the *DM_LOCAL_DOMAINS section of the Tuxedo domain configuration file.

• If authentication is required, it is done every time a connection is established between the local domain and a remote domain.

• If the security type of the WTCLocalTuxDom MBean does not match the security type of the *DM_LOCAL_DOMAINS or if the passwords do not match, the connection fails.

Configuring a WTCPassword MBean

Note: For more information on how to assign a PasswordKey, see How to Set WebLogic Tuxedo Connector Properties.

Use weblogic.wtc.gwt.genpasswd to generate encrypted passwords for LocalPassword, RemotePassword, and AppPassword elements. The utility uses a key to encrypt a password that is copied into the WTCPassword MBean of your WTCServer Mbean.

• The WTCPassword MBean does not store clear text passwords.

• The key value is a WebLogic Server property.

  • PasswordKey is the attribute used to assign the key.

      -Dweblogic.wtc.PasswordKey=mykey

where: mykey is the key value

• The PasswordKey attribute can only be assigned one key value. This key value is used for all Weblogic Tuxedo Connector passwords generated (local, remote, and application) for use with a specific WebLogic Server.

Usage

Call the utility without any arguments to display the command line options.

Example:

$ java weblogic.wtc.gwt.genpasswd

Usage: genpasswd Key <LocalPassword|RemotePassword|AppPassword> <local|remote|application>

The utility will respond with an XML element containing the encoded password and password IV. Cut and paste the results into the appropriate fields in your WTCServer MBean.

<LocalPassword IV="my_passwordIV">my_password</LocalPassword>

where

• Cut and paste the string of characters represented by my_passwordIV into the PasswordIV field. Do not include the quotation marks.

• Cut and paste the string of characters represented by my_password into the Password field. Do not include > or <.

Examples

This section provides examples of each of the password element types.

LocalPasswords

The following example uses key1 to encrypt "LocalPassword1" as the password of the local domain.

$ java weblogic.wtc.gwt.genpasswd Key1 LocalPassword1 local

<LocalPassword IV="I#^Da0efo1">!djK*87$klbJJ</LocalPassword>

Your Password MBean attributes are:

Local Password IV: I#^Da0efo1

Local Password: !djK*87$klbJJ

RemotePasswords

The following example uses mykey to encrypt "RemotePassword1" as the password for the remote domain.

$ java weblogic.wtc.gwt.genpasswd mykey RemotePassword1 remote

<RemotePassword IV="Rq$45%%kK">McFrd3#f41Kl</RemotePassword>

Your Password MBean attributes are:

Remote Password IV: Rq$45%%kK

Remote Password: McFrd3#f41Kl

AppPasswords

The following example uses key1 to encrypt "test123" as the application password.

$ weblogic.wtc.gwt.genpasswd mykey test123 application 

<AppPassword IV="gx8aSkAgLFg=">c98Y/P94HY3rCAVmkF=</AppPassword>

Your Resources MBean attributes are:

Application Password IV: gx8aSkAgLFg=

Application Password: c98Y/P94HY3rCAVmkF=

 

---

User Authentication

Access Control Lists (ACLs) limit the access to local services within a Local WLS Domain by restricting the remote Tuxedo domains that can execute these services. Inbound policy from a remote Tuxedo domain is specified using the AclPolicy element. Outbound policy towards a remote Tuxedo domain is specified using the CredentialPolicy element. This allows WebLogic Server and Tuxedo applications to share the same set of users and the users are able to propagate their credentials from one system to the other.

The valid values for AclPolicy and CredentialPolicy are:

• LOCAL

• GLOBAL

ACL Policy is LOCAL

If the WebLogic Tuxedo Connector ACL Policy is set to Local, access to local services does not depend on the CredentialPolicy. The Tuxedo remote domain DOMAINID is authenticated as a local WebLogic Server user. To allow WebLogic Tuxedo Connector to authenticate a DOMAINID as a local user, use the WebLogic Server Console to complete the following steps:

1. Click on the Security node.

2. Click on Realms.

3. Select your default security Realm.

4. Click on Users.

5. Click the Configure a new User text link.

6. Click DefaultAuthenticator

7. In the General tab, do the following:

   1. Add the Tuxedo DOMAINID in the Name field.

   2. Enter and validate a password.

   3. Click apply.

ACL Policy is GLobal

If the WebLogic Tuxedo Connector ACL Policy is GLOBAL, access to local services depends on the CredentialPolicy.

Credential Policy is Global

If a remote domain is running with the CredentialPolicy set to GLOBAL, the request has the credentials of the caller.

CredentialPolicy is Local

If a remote domain is running with the CredentialPolicy set to LOCAL, the result depends on the user configuration that initiated the call.

User Authenticaion for Tuxedo 6.5

Tuxedo 6.5 users should set the Interoperate parameter to Yes. The AclPolicy and CredentialPolicy elements are ignored and the Tuxedo remote domain DOMAINID is authenticated as a local WebLogic Server user. If you require User Security features and use the WebLogic Tuxedo Connector, you will need to upgrade to Tuxedo 7.1 or higher.

 

---

How to Configure WebLogic Tuxedo Connector to Provide Security between Tuxedo and WebLogic Server

Use the following steps to configure WebLogic Tuxedo Connector to provide security between Tuxedo and WebLogic Server applications:

• Configure a WTCLocalTuxDom MBean

• Configure a WTCRemoteTuxDom MBean

Configure a WTCLocalTuxDom MBean

Set the SECURITY parameter in the WTCLocalTuxDom MBean of your WTCServer MBean to match the SECURITY parameter of the *DM_LOCAL_DOMAINS section of the Tuxedo domain configuration file.

Example WTCLocalTuxDom MBean Configuration

     <WTCLocalTuxDom AccessPoint="TDOM2" AccessPointId="TDOM2"
         ConnectionPolicy="ON_DEMAND" Interoperate="no"
          NWAddr="//123.123.123.123:5678" Name="myLoclTuxDom"           Security="DM_PW"/>

Example Tuxedo *DM_LOCAL_DOMAINS Configuration

.
.
.
*DM_LOCAL_DOMAINS
     domain1      DOMAINID = "domain1"
     GWGRP = "GWGRP"
     CONNECTION_POLICY=ON_DEMAND
     DMTLOGDEV = "/nfs/home1/dkumar/lcsol5/tmp.100/DMTLOG"
     DMTLOGNAME = "DMTLG1"
     SECURITY=DM_PW
     BLOCKTIME=10
.
.
.

Configure a WTCRemoteTuxDom MBean

Configure the WTCRemoteTuxDom MBean to establish an inbound and outbound Access Control List (ACL) policy.

Perform the following steps to prepare the WebLogic Server environment:

1. Set the AclPolicy attribute of the WTCRemoteTuxDom MBean of your WTCServer MBean to GLOBAL.

2. Set the CredentialPolicy attribute of the WTCRemoteTuxDom MBean of your WTCServer MBean to GLOBAL.

3. If the CredentialPolicy is set to GLOBAL, you must have a copy of the Tuxedo tpusr file in your WebLogic Server environment. Use the following steps to add a TpUserFile to your environment:

   1. Copy the tpusr file from TUXEDO to the WebLogic Server application environment or generate your own tpusr file.

   2. Set the WTCRemoteTuxDom MBean TpUserFile attribute of your WTCServer MBean to the fully qualified path and name of the tpusr file.

Note: For more information on how to create a Tuxedo tpusr file, see How to Enable User-Level Authentication.

Example WTCRemoteTuxDom MBean

<WTCRemoteTuxDom AccessPoint="TDOM3" AccessPointId="TDOM3"
     AclPolicy="GLOBAL" CredentialPolicy="GLOBAL"
     LocalAccessPoint="TDOM2" NWAddr="//234.234.234.234:5555"
     Name="WTCRemoteTuxDom-1012347174947"      TpUsrFile="C:\runs\tmp.100\config\wldom1\tpusr"/>

Example Tuxedo *DM_LOCAL_DOMAINS Configuration

.
.
.
*DM_REMOTE_DOMAINS
     wldom1 DOMAINID = "wldom1"
     ACCESSPOINTID="wldom1"
     ACL_POLICY="GLOBAL"
     CREDENTIAL_POLICY="GLOBAL"
.
.
.

 

---

Example ACL Policy for Simpapp and Simpserv Examples

This section provides an example of how to set up ACL control using the simpapp and simpserv examples.

• Only John and Bob have access to Toupper.

• Only Dan and John to access Tolower.

• Toupper is used for accessing remote the Tuxedo service TOUPPER.

• Tolower provides the actual service for remote Tuxedo user.

Use the following steps to establish ACL control:

1. Add user John, Bob, and Dan to WebLogic Security using the WebLogic Server Console.

2. Modify the ejb-jar.xml to add the security-role and method_permission elements for the Tuxedo TOUPPER service. The bolded statements indicate the changes added to support the security implementation.

Listing 3-1 TOUPPER ejb-jar.xml Security Example Code

<?xml version="1.0"?>
<!--
Copyright (c) 2000 BEA Systems, Inc. All rights reserved

THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF BEA Systems, Inc. The 
copyright notice above does not evidence any actual or intended publication 
of such source code.

-->

<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans
2.0//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_2_0.dtd'>

<ejb-jar>
     <enterprise-beans>
          <session>
               <ejb-name>Toupper</ejb-name>
     <home>weblogic.wtc.examples.simpapp.ToupperHome</home>
     <remote>weblogic.wtc.examples.simpapp.Toupper</remote>                                                       <ejb-class>weblogic.wtc.examples.simpapp.ToupperBean</ejb-class>
               <session-type>Stateful</session-type>
               <transaction-type>Container</transaction-type>
          </session>
     </enterprise-beans>
     <assembly-descriptor>
          <security-role>
               <role-name>dom2</role-name>
          </security-role>
          <method-permission>
               <role-name>dom2</role-name>
               <method>
                     <ejb-name>Toupper</ejb-name>
                     <method-name>Toupper</method-name>
               </method>
          </method-permission>
          <container-transaction>
               <method>
                    <ejb-name>Toupper</ejb-name>
                    <method-intf>Remote</method-intf>
                    <method-name>*</method-name>
               </method>
               <trans-attribute>Supports</trans-attribute>
           </container-transaction>
     </assembly-descriptor>
</ejb-jar>

3. Modify the Weblogic-ejb-jar.xml to add the security-role-assignment element for the Tuxedo TOUPPER service. The bolded statements indicate the changes added to support the security implementation.

Listing 3-2 TOUPPER Weblogic-ejb-jar.xml Security Example Code

<?xml version="1.0"?>
<!--

Copyright (c) 2000 BEA Systems, Inc. All rights reserved

THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF BEA Systems, Inc.
The copyright notice above does not evidence any actual or intended 
publication of such source code.

-->

<!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 6.0.0
EJB//EN' 'http://www.bea.com/servers/wls600/dtd/weblogic-ejb-jar.dtd'>

<weblogic-ejb-jar>
     <weblogic-enterprise-bean>
          <ejb-name>Toupper</ejb-name>
          <stateful-session-descriptor>
               <stateful-session-cache>
          <max-beans-in-cache>100</max-beans-in-cache>
               </stateful-session-cache>
          </stateful-session-descriptor>
          <jndi-name>tuxedo.services.ToupperHome</jndi-name>
     </weblogic-enterprise-bean>
     <security-role-assignment>
          <role-name>dom2</role-name>
          <principal-name>john</principal-name>
          <principal-name>bob</principal-name>
     </security-role-assignment>
</weblogic-ejb-jar>

4. Modify the ejb-jar.xml to add the security-role and method-permission elements for the Tolower service. The bolded statements indicate the changes added to support the security implementation.

Listing 3-3 Tolower ejb-jar.xml Security Example Code

<?xml version="1.0"?>
<!--

Copyright (c) 2000 BEA Systems, Inc. All rights reserved 
THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF BEA Systems, Inc. 
The copyright notice above does not evidence any actual or intended 
publication of such source code.

-->
<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans
2.0//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_2_0.dtd'>

<ejb-jar>
     <enterprise-beans>
          <session>
               <ejb-name>Tolower</ejb-name>
            <home>weblogic.wtc.jatmi.TuxedoServiceHome</home>
             <remote>weblogic.wtc.jatmi.TuxedoService</remote>                                                    <ejb-class>weblogic.wtc.examples.simpserv.TolowerBean</ejb-class>
            <session-type>Stateless</session-type>
            <transaction-type>Container</transaction-type>
          </session>
     </enterprise-beans>

     <assembly-descriptor>
          <security-role>
               <role-name>rdom2</role-name>
          </security-role>
          <method-permission>
               <role-name>rdom2</role-name>
               <method>
                    <ejb-name>Tolower</ejb-name>
                    <method-name>service</method-name>
               </method>
          </method-permission>
          <container-transaction>
               <method> 
                    <ejb-name>Tolower</ejb-name>
                    <method-intf>Remote</method-intf>
                    <method-name>*</method-name>
               </method>
               <trans-attribute>Supports</trans-attribute>
          </container-transaction>
     </assembly-descriptor>
</ejb-jar>

5. Modify the Weblogic-ejb-jar.xml to add the security-role-assignment element for the Tolower service.The bolded statements indicate the changes added to support the security implementation.

Listing 3-4 Tolower Weblogic-ejb-jar.xml Security Example Code

<?xml version="1.0"?>
<!--

Copyright (c) 2000 BEA Systems, Inc. All rights reserved

THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF BEA Systems, Inc. 
The copyright notice above does not evidence any actual or intended 
publication of such source code.

-->

<!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 6.0.0
EJB//EN' 'http://www.bea.com/servers/wls600/dtd/weblogic-ejb-jar.dtd'>

<weblogic-ejb-jar>
     <weblogic-enterprise-bean>
          <ejb-name>Tolower</ejb-name>
     <stateless-session-descriptor>
          <pool>
               <max-beans-in-free-pool>100</max-beans-in-free-pool>
          </pool>
     </stateless-session-descriptor>
     <jndi-name>tuxedo.services.TOLOWERHome</jndi-name>
     </weblogic-enterprise-bean>
     <security-role-assignment>
          <role-name>rdom2</role-name>
          <principal-name>john</principal-name>
          <principal-name>dan</principal-name>
     </security-role-assignment>
</weblogic-ejb-jar>

6. Perform the following steps to prepare the Tuxedo environment for outbound requests:

• If needed, add the group using tpgrpadd.

• If needed, add John, Bob, and Dan as users using tpusradd.

• Add TOUPPER service to be protected by TUXEDO ACL using tpacladd.

• Set the BDMCONFIG for the remote domain (the WebLogic Server domain) with the ACL_POLICY="GLOBAL".

7. Perform the following steps to prepare the Tuxedo environment for inbound requests:

• If needed, add the group using tpgrpadd.

• If needed, add John, Bob, and Dan as users using tpusradd.

• Add TOUPPER service to be protected by TUXEDO ACL using tpacladd.

• Set the BDMCONFIG for the remote domain (the WebLogic Server domain) with the ACL_POLICY="GLOBAL". If ACL_POLICY="LOCAL", configure the remote DOMAINID or the AccessPointID as a user using tpusradd.

8. Perform the following steps to prepare the WebLogic Server environment:

• Copy the tpusr file from TUXEDO or generate your own tpusr file.

• Set the WTCRemoteTuxDom MBean TpUserFile attribute of your WTCServer MBean to the fully qualified path and name of the tpusr file.

9. Set the WTCRemoteTuxDom MBean CredentialPolicy attribute of your WTCServer MBean to GLOBAL.

 

---

Link-Level Encryption

You can use encryption across domains to ensure data privacy. In this way, a network-based eavesdropper cannot learn the content of messages or application-generated messages flowing from one domain gateway to another. You configure this security mechanism by setting the MINENCRYPTBITS and MAXENCRYPTBITS parameters of the WTCLocalTuxDom and the WTCRemoteTuxDom MBeans of your WTCServer MBean.

Note: Encryption requires appropriate licensing. For more information on license requirements, see Licensing