Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	e-docs   |   Search   |   Contact   |   WebLogic Tuxedo Connector Documentation
WebLogic Tuxedo Connector Administration Guide:   Previous topic   |   Next topic   |   Contents

Configuring BDMCONFIG

The BDMCONFIG section of the WebLogic Tuxedo Connector XML configuration file describes how to establish connectivity and provide security between domains in the WebLogic Tuxedo Connector and Tuxedo environments. The XML configuration file is composed of configuration parameters that are analogous to the interoperability attributes required for the communication between Tuxedo domains.

The WebLogic Tuxedo Connector is started as part of the WebLogic Server application environment. Any configuration condition that prevents the WebLogic Tuxedo Connector from starting results in an error being logged to the WebLogic Server error log.

The following sections provide configuration information about BDMCONFIG:

• Establishing Connectivity

• Dynamic Status

• Configuring Failover and Failback

• Establishing Security

  Note: For more detailed reference information on the WebLogic Tuxedo Connector XML configuration file, elements and attributes, and the wtc_config.dtd, see The wtc_config.dtd.

Establishing Connectivity

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 parameter in the T_DM_LOCAL_TDOMAIN and T_DM_REMOTE_TDOMAIN sections of BDMCONFIG.

• Valid values for local domains are: ON_DEMAND, ON_STARTUP, or INCOMING_ONLY.

• Valid values for remote domains are: ON_DEMAND, ON_STARTUP, INCOMING_ONLY, or LOCAL.

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

RetryInterval

The RetryInterval parameter enables failed attempts at connections to remote domains to be retried automatically if the connection policy is ON_STARTUP. 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.

• Minimum value: 0

• Maximum value: 2147483647

• Default setting: 60

MaxRetries

The MaxRetries number indicates the number of times that a domain gateway tries to establish connections to remote domain access points before quitting. Use only when ConnectionPolicy is set to ON_STARTUP.

• Minimum value: 0

• Maximum value: 2147483647

• Default value: 2147483647

Use the maximum value to retry processing until a connection is established. Use the minimum value to disable the automatic retry mechanism.

Connecting on Request (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. The default setting for ConnectionPolicy is ON_DEMAND.

Accepting Incoming Connections (INCOMING_ONLY)

A connection policy of INCOMING_ONLY means that a domain gateway does not attempt an initial connection to remote domain access points at startup. The domain gateway is available for incoming connections from remote domain access points and remote services are advertised when the domain gateway for this local domain access point receives an incoming connection. Connection retry processing is not allowed when the connection policy is INCOMING_ONLY.

LOCAL

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 (specified by the LocalAccessPoint).

Dynamic Status

Dynamic Status is a feature of the gateway process (GWTDOMAIN) to determine 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 each connection policy 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 Failover and Failback

The WebLogic Tuxedo Connector supports domain level failover and failback

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

Domain Failover and Failback

Domain failover provides an alternate access to domain services when a failure is detected on a primary remote domain. Failback is provided if a connection to the primary domain is restored when the domain becomes available.

• Configure domains with a ConnectionPolicy of ON_STARTUP or INCOMING_ONLY to enable failover/failback on the WebLogic Tuxedo Connector.

• A connection policy of ON_DEMAND assumes the domain is always available

Establishing Security

The WebLogic Tuxedo Connector supports authentication of clients, servers, and administrative programs.

• Clients present passwords and are authenticated before joining applications

• Servers are authenticated to be running as the user identified by the application administrator

• Access Control Lists (ACLs) are available to control access to services

Domains Passwords

The Security parameter in the local domain specifies the level of security allowed by a particular local domain. There are three basic security levels:

• NONE: Incoming connections from a remote domain are not authenticated. This is the default value.

• APP_PW: Incoming connections from remote domains are authenticated using the application password defined in the T_DM_PASSWORD element.

• DM_PW: Domain password security is enforced when a connection is established from a remote domain. Domain passwords must be defined in the T_DM_PASSWORD element.

Generating Encrypted Passwords

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 WebLogic Tuxedo Connector XML configuration file. The result is a valid WebLogic Tuxedo Connector XML element.

Note: Use of encryption requires appropriate user licenses. For more information, see Licensing.

• The XML configuration file does not store clear text passwords.

• The key must included in the argument field of the StartUp class to provide the WebLogic Tuxedo Connector access to the key on startup.

  • Use the PasswordKey parameter to assign the key.

  • The PasswordKey argument can only be assigned one key value.

  • If there are no T_DM_PASSWORD entries in the XML configuration file, the PasswordKey argument is ignored.

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>

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>

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>

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>

Access Control Lists

Access Control Lists (ACLs) limit the access to local services within a local domain by restricting the remote domains that can execute these services. Inbound policy from a remote domain is specified using the AclPolicy element. Outbound policy towards a remote 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 this parameter are:

• LOCAL: The domain gateway's security token is passed.

• GLOBAL: The user's security token is passed.

Security Requirements for servers

• If the RemoteAccessPoint is running with an AclPolicy of LOCAL, then any requests from that RemoteAccessPoint must have the credentials of the WebLogic Tuxedo Connector instantiation.

• If the RemoteAccessPoint is running with an AclPolicy of GLOBAL, then any requests from that RemoteAccessPoint must have the user identity from the token received on the request.

Security Requirements for clients

• If a remote domain is running with the CredentialPolicy set to LOCAL then the request to Tuxedo has the credentials of the remote domain gateway.

• If a remote domain is running with the CredentialPolicy set to GLOBAL then the WebLogic Tuxedo Connector constructs tokens based on the identity of the caller.

Establishing an ACL Policy

Use the following steps to establish an ACL policy:

1. Add Users to TpUserFile

2. Modify EJBs for ACL

3. Modify Tuxedo Environment for ACL

4. Modify WebLogic Tuxedo Connector Environment for ACL

   Note: Tuxedo 6.5 does not have the required security infrastructure to support security mapping.

Add Users to TpUserFile

Add users to the TpUsrFile using the WebLogic Server Console.

Modify EJBs for ACL

Add the security-role and security-role-assignment elements to each EJB used in the application.

After you have added the users and modified the EJBs, only WebLogic Server defined users have permission to access the EJBs.

Modify Tuxedo Environment for ACL

Perform the following steps for inbound and outbound requests to prepare the Tuxedo environment:

1. Add the group using tpgrpadd.

2. Add users using tpusradd.

3. Add the service to be protected by TUXEDO ACL using tpacladd.

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

   Note: If ACL_POLICY="LOCAL", you must configure the remote DOMAINID as a user using tpusradd.

Modify WebLogic Tuxedo Connector Environment for ACL

Perform the following steps to prepare the WebLogic Server environment:

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

2. Add a TpUserFile element to the T_DM_REMOTE_TDOMAIN section of the XML configuration file.

   Example: <TpUsrFile>full path name to tpusr</TpUsrFile>.

3. Add a CredentialPolicy element to the T_DM_REMOTE_TDOMAIN section of the XML configuration file.

   Example: <CredentialPolicy>GLOBAL</CredentialPolicy>

   Note: If the CredentialPolicy value is set to LOCAL, the user information is stripped off.

Example ACL Policy

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 security-role-assignment elements for the Tuxedo TOUPPER service.

   Note: The | at beginning of the line indicates the changes added to support the security implementation.

<?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>

1. Modify the Weblogic-ejb-jar.xml to add the security-role and security-role-assignment elements for the Tuxedo TOUPPER service.

   Note: The | at beginning of the line indicates the changes added to support the security inplementation.

<?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>

1. Modify the ejb-jar.xml to add the security-role and security-role-assignment elements for the Tolower service.

   Note: The | at beginning of the line indicates the changes added to support the security inplementation.

<?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>

1. Modify the Weblogic-ejb-jar.xml to add the security-role and security-role-assignment elements for the Tolower service.

   Note: The | at beginning of the line indicates the changes added to support the security inplementation.

<?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>

1. 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".

2. 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".

     Note: If ACL_POLICY="LOCAL", you must configure the remote DOMAINID as a user using tpusradd.

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

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

   • Add a TpUserFile element to the T_DM_REMOTE_TDOMAIN section of the XML configuration file.

     Example: <TpUsrFile>full path name to tpusr</TpUsrFile>.

   • Add a CredentialPolicy element to the T_DM_REMOTE_TDOMAIN section of the XML configuration file. Set the value to GLOBAL.

     Example: <CredentialPolicy>GLOBAL</CredentialPolicy>