3 Oracle WebLogic Tuxedo Connector Administration
This chapter includes the following sections:
For more information on the Oracle WebLogic Server management, including the Oracle WebLogic Tuxedo Connector, see the MBean Reference for Oracle WebLogic Server.
Configuring the Connections Between Access Points
Several options can specify the conditions under which an access point tries to establish a connection with a remote access point. Specify these conditions using the ConnectionPolicy
attribute on the Connections page of the local Tuxedo access points and remote Tuxedo access points configurations of your WTC server. You can select any of the following connection policies:
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 access point.
The WTC local access point has three connection policies: ON_DEMAND
, INCOMING_ONLY
, and ON_STARTUP
. The default is ON_DEMAND
.
The WTC remote access point has four connection policies: ON_DEMAND
, INCOMING_ONLY
, ON_STARTUP
, and LOCAL
. The default is LOCAL
. When you specify LOCAL
for the remote access point connection policy setting, the local access point connection policy is used. The remote access point connection policy takes precedence over the local access point connection policy.
The local access point connection policy works as a backup for remote access point connection. At the WTC startup, WTC processes through all the remote access point definitions and decides the actual connection policy similar to the following table.
Table 3-1 Access Point Connection Policy Settings
If the Local Access Point Setting is... | And the Remote Access Point Setting is | Then the Actual Connection Policy Is... |
---|---|---|
ON_DEMAND |
ON_DEMAND |
ON_DEMAND |
ON_DEMAND |
ON_STARTUP |
ON_STARTUP |
ON_DEMAND |
INCOMING_ONLY |
INCOMING_ONLY |
ON_DEMAND |
LOCAL |
ON_DEMAND |
ON_STARTUP |
ON_DEMAND |
ON_DEMAND |
ON_STARTUP |
ON_STARTUP |
ON_STARTUP |
ON_STARTUP |
INCOMING_ONLY |
INCOMING_ONLY |
ON_STARTUP |
LOCAL |
ON_STARTUP |
INCOMING_ONLY |
ON_DEMAND |
ON_DEMAND |
INCOMING_ONLY |
ON_STARTUP |
ON_STARTUP |
INCOMING_ONLY |
INCOMING_ONLY |
INCOMING_ONLY |
INCOMING_ONLY |
LOCAL |
INCOMING_ONLY |
The following information clarifies the interaction between the connection policy for the local access point, the connection policy for the remote access point, and the settings of these parameters at the remote domain.
Table 3-2 Interaction of Local and Remote Access Point Connection Policies
If the Local System's Effective Connection Policy Is... | And the Remote System's Effective Connection Policy Is... | Then the Settings of the Parameters at the Remote Domain Are... |
---|---|---|
ON_DEMAND |
ON_DEMAND |
ON_DEMAND from either |
ON_DEMAND |
ON_STARTUP |
ON_STARTUP when both are up |
ON_DEMAND |
INCOMING_ONLY |
ON_DEMAND from local |
ON_STARTUP |
ON_DEMAND |
ON_STARTUP when both are up |
ON_STARTUP |
ON_STARTUP |
ON_STARTUP when both are up |
ON_STARTUP |
INCOMING_ONLY |
ON_STARTUP when both are up |
INCOMING_ONLY |
ON_DEMAND |
ON_DEMAND from remote |
INCOMING_ONLY |
ON_STARTUP |
ON_STARTUP when both are up |
INCOMING_ONLY |
INCOMING_ONLY |
manual connect only when both are up |
How to Request a Connection at Boot Time (On Startup)
A policy of On Startup
means that an access point attempts to establish a connection with its remote 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 ConnectionPolicy
attribute on the Connections page of your local Tuxedo access point 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 access point 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
You indicate the number of times an access point tries to establish connections to remote 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 access point automatically. -
If you set
MaxRetries
to a number, the access point 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.
Use this only when ConnectionPolicy
is set to On Startup
. For other connection policies, retry processing is disabled.
Table 3-3 Example Settings of MaxRetries and RetryInterval Parameters
If you set... | Then... |
---|---|
|
The access point makes 3 attempts to establish a connection, at 30 seconds intervals, before quitting. |
|
The access point attempts to establish a connection at initialization time but does not retry if the first attempt fails. |
|
The access point attempts to establish a connection every 30 seconds until a connection is established. |
How to Request Connections for Client Demands (On Demand)
A connection policy of 0n Demand
means that a connection is attempted only when requested by either a client request to a remote service or an administrative start connection command.
Note:
If the ConnectionPolicy
is not specified for the local access point, the Oracle WebLogic Tuxedo
Connector uses a ConnectionPolicy
of 0n Demand
.
Accepting Incoming Connections (Incoming Only)
A connection policy of Incoming Only
means that an access point does not establish a connection to remote access points upon starting. The access point is available for incoming connection requests from remote access points.
How to use LOCAL Connection Policy
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 access point ConnectionPolicy
is not defined, the system uses the setting specified by the associated local access point.
Note:
A ConnectionPolicy
of LOCAL
is not valid for local access points.
Configuring Failover and Failback
Oracle WebLogic Tuxedo
Connector provides a failover mechanism that transfers requests to alternate remote access points when a failure is detected with a primary remote access point. It also provides failback to the primary remote access point when that access point is restored. This level of failover/failback depends on connection status. The access point must be configured with a connection policy of On Startup
or Incoming Only
to enable failover/failback.
Note:
In the Tuxedo T/ Domain, there is a limit of two backup remote access points. The Oracle WebLogic Tuxedo Connector has no limit to the number of backup access points allowed to be configured for a service.
Prerequisite to Using Failover and Failback
To use failover/failback, you must specify ON_STARTUP
or INCOMING_ONLY
as the value of the Connection Policy
parameter.
A connection policy of 0n Demand
is unsuitable for failback as it operates on the assumption that the remote access point 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 access points that you have specified with the Tuxedo RDOM
parameter.
Note:
A remote access point is available
if a network connection to it exists; a remote access point is unavailable
if a network connection to it does not exist.
How to Configure Failover
To support failover, you must specify the remote access points responsible for executing a particular service. You must specify the following in your WTC server:
-
Create remote Tuxedo access points configurations for each remote access point.
-
Create imported services configurations that specify the service provided by each remote access point.
Suppose a service, TOUPPER, is available from two remote access points: TDOM1
and TDOM3
. Your WTC server would include two remote Tuxedo access point configurations and two imported services configurations in your WTC server. The WTC server defined in the config.xml
file would contain the following:
<wtc-server> <name>WTCsimpapp</name> <wtc-local-tux-dom> <access-point>TDOM2</access-point> <access-point-id>TDOM2</access-point-id> <connection-policy>ON_DEMAND</connection-policy> <interoperate>no</interoperate> <nw-addr>//123.123.123.123:5678</nw-addr> <name>myLoclTuxDom</name> <security>NONE</security> </wtc-local-tux-dom> <wtc-remote-tux-dom> <access-point>TDOM1</access-point> <access-point-id>TDOM1</access-point-id> <local-access-point>TDOM2</local-access-point> <nw-addr>//123.123.123.123:1234</nw-addr> <name>myRTuxDom</name> </wtc-remote-tux-dom> <wtc-remote-tux-dom> <access-point>TDOM3</access-point> <access-point-id>TDOM3</access-point-id> <local-access-point>TDOM2</local-access-point> <nw-addr>//234.234.234.234:5555</nw-addr> <name>2ndRemoteTuxDom</name> </wtc-remote-tux-dom> <wtc-export> <ejb-name>tuxedo.services.TOLOWERHome</ejb-name> <local-access-point>TDOM2</local-access-point> <name>myExportedResources</name> <resource-name>TOLOWER</resource-name> </wtc-export> <wtc-import> <name>imp0</name> <resource-name>TOUPPER</resource-name> <local-access-point>TDOM2</local-access-point> <remote-access-point-list>TDOM1,TDOM3</remote-access-point-list> <remote-name>TOUPPER</remote-name> </wtc-import> <wtc-import> <name>imp1</name> <resource-name>TOUPPER</resource-name> <local-access-point>TDOM2</local-access-point> <name>2ndImportedResources</name> <remote-access-point-list>TDOM3,TDOM1</remote-access-point-list> <remote-name>TOUPPER</remote-name> </wtc-import> </wtc-server>
How to Configure Link-level Failover
To support link-level failover, you must specify the correct failover sequence information in the comma separated syntax <nw-addr>
XML tag in the WTCRemoteTuxDomMBean
and WTCLocalTuxDomMBean
definitions. The order of the network addresses determines the order of preference for failover.
Note:
The value of the XML tag is checked for correct syntax. If the syntax is not correct, the InvalidAttributeException
is thrown.
The semantic of the link-level failover is late binding, which means the existence and availability is not checked when the MBean is created. This is to allow users to add the machine to DNS after the WTC configuration is created, but before the TDomain session connection is created.
The correct syntax in config.xml
will be as follow using comma separated syntax for the <nw-addr>
XML tag.
<nw-addr>//host1:4001</nw-addr> --> only one host, no link-level failover <nw-addr>//host1:4001,//host2:4001</nw-addr> --> can failover to host2 <nw-addr>//host1:4001,//host2:4001,//host3:4001</nw-addr> --> can failover from host 1 to host2, and if host2 still not available then failover to host3
Sample Link-level Failover Configuration
The following example configures a WTC local access point named WDOM
, and one TDomain session with name TDOM
. This TDomain session also defines a remote access point named DOM1
. The TDomain session in this case is a session between WDOM
and TDOM
. The local access point will try to listen on end point "//pluto:4100"
first; if fails to create a listening endpoint, the session attempts to create a listening endpoint on "//saturn:4101"
. If WTC migrated from pluto
to saturn
, then the remote access point DOM1
is able to contact WDOM
using "//saturn:4101"
.
If the remote access point DOM1
migrates from host mercury to host mars, the WDOM
can contact DOM1
at "//mars:4001"
.
The order of network address specified in the list provides order preference. For WDOM
, "//pluto:4100"
is the first choice for creating a listening endpoint and "//saturn:4101"
is the second choice. For remote access point DOM1
, "//mercury:4001"
is the first choice to create a connection from WDOM
to DOM1
and "//mars:4001"
is the second choice.
Example 3-1 Link-level Failover Configuration
<wtc-server> <name>myWTCserver</name> .... <wtc-local-tux-dom> <name>WDOM</name> <access-point>WDOM</access-point> <access-point-id>WDOM</access-point-id> <nw-addr>//pluto:4100,//saturn:4101</nw-addr> </wtc-local-tux-dom> <wtc-remote-tux-dom> <name>TDOM</name> <access-point>DOM1</access-point> <access-point-id>DOM1</access-point-id> <local-access-point>WDOM</local-access-point> <nw-addr>//mercury:4001,//mars:4001</nw-addr> </wtc-remote-tux-dom> ..... </wtc-server>
Configuring for TypedMBString Support
To configure WTC to support MBSTRING buffers, you must specify the encoding you want to use in the RemoteMBEncoding
attribute of the WTCResources
definition. This attribute is optional and if it is not specified or is invalid, Java's default encoding is used.
TypedMBString
uses the conversion function java.lang.String
class for converting between Unicode and an external encoding. TypedMBString
uses a map file to map the encoding names between Java and GNU iconv, which is used by the C language API of MBSTRING. The map file is mbencmap
, which is a text-based file in $WL_HOME
/server/lib
directory as a default. The map file creates a HashMap with each "user_name java_name
" pair. You can customize the map file.
An encoding map file contains one or more lines with the following syntax.
<user_name> <java_name1>[,<java_name2>,[java_name3,...]]
By specifying multiple java_names
in a line, multiple Java encoding names are mapped to a single user_name
. The user_name
always maps to the first java_name
in the line.
Authentication of Remote Access Points
Domain gateways can be made to authenticate incoming connections requested by remote access points and outgoing connections requested by local access points. Application administrators can define when security should be enforced for incoming connections from remote access points. You can specify the level of security used by a particular local access point by setting the Security
attribute on the Security page of the local Tuxedo access point configuration of your WTC server. There are three levels of password security:
-
NONE
—incoming connections from remote access points are not authenticated. -
Application Password
— incoming connections from remote access points are authenticated using the application password defined in the resource configuration of your WTC server. You use theweblogic.wtc.gwt.genpasswd
utility to create encrypted application passwords. -
Domain Password
—this feature enforces security between two or more access points. Connections between the local and remote access points are authenticated using password pairs defined in the password configuration of your WTC server. You use theweblogic.wtc.gwt.genpasswd
utility to create encrypted local and remote passwords.
The Security
attribute on the Security page of the local Tuxedo access point of your WTC server must match the SECURITY
attribute 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 access point and the remote access point.
-
If the security type of the local Tuxedo access point in your WTC server does not match the security type of the *DM_LOCAL_DOMAINS or if the passwords do not match, the connection fails.
Configuring a Password Configuration
The /Domain architecture with SECURITY=DM_PW
requires a password for each connection principal. Each TDomain session between two TDomain gateways has two distinctive connection principals associated with it; by default, they are represented by Domain IDs. The default Session Authentication with DM_PW
requires both sides configure two secrets for both connection principals so they can authenticate each other. The following example provides configurations for both WTC and Tuxedo.
-
WTC is configured with:
-
local access point
WDOM1
with DOMAIN IDWDOM1
-
remote access point
TDOM1
with DOMAIN IDTDOM1
-
security set to
DM_PW
-
-
Tuxedo is configured with
-
its own local access point
TDOM1
with DOMAIN IDTDOM1
-
remote access point
WDOM1
with DOMAIN IDWDOM1
-
security is set to
DM_PW
-
Then WTC needs to configure a password pair for TDOMAIN session (WDOM1, TDOM1
). For example, the password pair is represent as (pWDOM1, pTDOM1
) for the TDomain Session (WDOM1, TDOM1
). Then Tuxedo TDOMAIN needs to configure a password pair for TDOMAIN session (TDOM1, WDOM1
). The password pair should be (pTDOM1, pWDOM1
) in this case.
Using AES Encrypted Passwords
This release of WebLogic Server provides the ability to optionally support 256-bit AES encryption of passwords by setting the -Daes
flag in the weblogic.wtc.gwt.genpasswd
utility (see Generating Encrypted Passwords). This is equivalent to setting the GWT_SNP_MINCRYPT
environment variable to AES
for a GWTDOMAIN process in Tuxedo.
Note:
For AES support in Tuxedo 10 for GWTDOMAIN, passwords in the tpusr
file remain encrypted using their original encryption method. tpusr
files are normally generated in a Tuxedo native domain and then copied to a location where WTC (via the WLS domain) can access it.
Generating Encrypted Passwords
To generate encrypted passwords:
-
Use
weblogic.wtc.gwt.genpasswd
to generate encrypted passwords for Local Password, Remote Password, and App Password attributes. The utility uses a key to encrypt a password that is copied into the password or resources configuration of your WTC werver. -
The password configuration of your WTC server does not store clear text passwords.
-
The key value is a WebLogic Server property.
-Dweblogic.wtc.PasswordKey=mykey
PasswordKey
is the attribute used to assign the keymykey
is the key value-
The
PasswordKey
attribute can only be assigned for one key value. This key value is used for all Oracle WebLogic Tuxedo Connector passwords generated (local, remote, and application passwords) 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 [-Daes] Key <LocalPassword|RemotePassword|AppPassword> <local|remote|application>
Call the utility with a key value, password to encrypt, and the type of password. To generate 256-bit AES encoded password and password IV, include the -Daes
flag.
Example:
$ java weblogic.wtc.gwt.genpasswd Key1 LocalPassword1 local
The utility will respond with the encoded password and password IV. Cut and paste the results into the appropriate fields in the password configuration of your WTC server.
Local Password : my_password Local Password IV: my_passwordIV
where
-
Cut and paste the string of characters represented by
my_password
into the Password field. -
Cut and paste the string of characters represented by
my_passwordIV
Examples
This section provides examples of each of the password element types.
Local Passwords
The following example uses key1
to encrypt LocalPassword1
as the password of the local access point.
$ java weblogic.wtc.gwt.genpasswd key1 LocalPassword1 local Local Password : FMTCg5Vi1mTGFds1U4GKIQQj7s2uTlg/ldBfy6Kb+yY= Local Password IV : NAGikshMiTE=
Your Password attributes are:
Local Password: FMTCg5Vi1mTGFds1U4GKIQQj7s2uTlg/ldBfy6Kb+yY= Local Password IV: NAGikshMiTE=
The following example uses AES encryption to encode LocalPassword1
as the password of the local access point.
$ java weblogic.wtc.gwt.genpasswd -Daes LocalPassword1 local Local Password : 71Im/Y4VcuhInuN1My5wWRjIneu+KPR0aN1WBliwIq4= Local Password IV: a9qAjBpYExA=
Your Password attributes are:
Local Password: 71Im/Y4VcuhInuN1My5wWRjIneu+KPR0aN1WBliwIq4= Local Password IV: a9qAjBpYExA=
Remote Passwords
The following example uses mykey
to encrypt RemotePassword1
as the password for the remote access point.
$ java weblogic.wtc.gwt.genpasswd mykey RemotePassword1 remote Remote Password : A/DgdJYOJunFUFJa62YmPgsHan8pC02zPT0T7EigaVg= Remote Password IV : ohYHxzhYHP0=
Your Password attributes are:
Remote Password: A/DgdJYOJunFUFJa62YmPgsHan8pC02zPT0T7EigaVg= Remote Password IV: ohYHxzhYHP0=
App Passwords
The following example uses mykey
to encrypt test123
as the application password.
$ java weblogic.wtc.gwt.genpasswd mykey test123 application App Password : uou2MALQEZgNqt8abNKiC9ADN5gHDLviqO+Xt/VjakE= App Password IV : eQuKjOaPfCw=
Your Resources attributes are:
Application Password: uou2MALQEZgNqt8abNKiC9ADN5gHDLviqO+Xt/VjakE= Application Password IV: eQuKjOaPfCw=
User Authentication
Access Control Lists (ACLs) limit the access to local services within a local access point by restricting the remote Tuxedo access point that can execute these services. Inbound policy from a remote Tuxedo access point is specified using the AclPolicy
attribute. Outbound policy towards a remote Tuxedo domain is specified using the CredentialPolicy
attribute. 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 Oracle WebLogic Tuxedo
Connector ACL Policy is set to Local
, access to local services does not depend on the remote user credentials. The Tuxedo remote access point ID is authenticated as a local WebLogic Server user. To allow Oracle WebLogic Tuxedo
Connector to authenticate a DOMAINID
as a local user, use the WebLogic Server Administration Console to complete the following steps:
-
From the WebLogic Server Administration Console, select Security Realms.
-
Select your default security Realm.
-
On the Realms settings page, select Users and Groups>Users.
The Users table displays. The User table lists the names of all users defined in the Authentication provider.
-
Click New to configure a new User. The Create a New User page displays.
-
In the Create a New User page, do the following:
-
Add the Tuxedo
DOMAINID
in the Name field. -
Enter and validate a password.
-
Click OK. The user name is now in the User table.
-
ACL Policy is GLOBAL
If the Oracle WebLogic Tuxedo
Connector ACL Policy is GLOBAL
, access to local services depends on the remote user credentials.
Remote Access Point Credential Policy is GLOBAL
If a remote domain is running with the CredentialPolicy
set to GLOBAL
, the request has the credentials of the remote user, thus the ability to access the local service depends on this credential.
When CredentialPolicy
is set to GLOBAL
for WTC, then WLS user credential is propagated from WTC to the remote Tuxedo domain. If a remote Tuxedo domain is also configured with ACL_POLICY
set to GLOBAL
, then it will accept the WLS user credential and use it to access Tuxedo services. If a remote Tuxedo domain is configured with ACL_POLICY
to LOCAL
, then it will discard the received WLS user credential and use WTC DOMAINID
to access Tuxedo services.
Remote Access Point Credential Policy is LOCAL
When CredentialPolicy
is set to LOCAL
for WTC, then WLS user credential is not propagated to a remote Tuxedo domain. The remote Tuxedo access point sets the identity of a service request received from the WTC domain to be the principal name specified in the local principal name for the remote Tuxedo domain.
How to Configure Oracle WebLogic Tuxedo Connector to Provide Security between Oracle Tuxedo and Oracle WebLogic Server
The following sections provide information on how to configure WebLogic Tuxedo provide user security information to Tuxedo:
TpUsrFile Plug-in
The TpUsrFile plug-in provides traditional Tuxedo TpUserFile functionality for users who do not need single point security administration or custom security authentication. Use the following steps to configure Oracle WebLogic Tuxedo Connector to provide security between Tuxedo and WebLogic Server applications using the TpUsrFile plug-in AppKey Generator:
Configuring the Local Tuxedo Access Point for the TpUsrFile Plug-in
Set the security
attribute on the Security page of the local Tuxedo access point of your WTC server to match the SECURITY parameter of the *DM_LOCAL_DOMAINS section of the Tuxedo domain configuration file.
Configure the Remote Tuxedo Access Point for the TpUsrFile Plug-in
Configure the Security page of the remote Tuxedo access point of your WTC server to establish an inbound and outbound Access Control List (ACL) policy.
Perform the following steps to prepare the WebLogic Server environment:
Using the Resources TpUsrFile attribute
The location of the TpUsrFile can be specified from your remote Tuxedo access point configurations or from your resources configuration. You may find it convenient assign the value of the TpUsrFile attribute globally at the WTC server level, rather than by assigning it individually on all of your remote Tuxedo access point configurations. Use the following guidelines to help you determine where to best configure the TpUsrFile attribute:
-
All TpUsrFile attribute values are ignored if the TpUsrFile Plug-in is not selected as the AppKey Generator, regardless of location.
-
If the resources configuration does not have TpUsrFile attribute values, the TpUsrFile attribute value must be specified in the remote Tuxedo access point configurations. The cached user record information is ignored.
-
If the resources and remote Tuxedo access point configurations contain TpUsrFile attribute values, the attribute values in the remote Tuxedo access points are used. The cached user record information is ignored.
-
If the remote Tuxedo access point configurations do not have TpUsrFile attribute values, the TpUsrFile attribute value must be specified in the resources configuration. The cached user record is used, which improves system performance. However, this restricts the user to have the same identity in all remote Tuxedo access points.
LDAP Plug-in
The LDAP plug-in provides single point security administration that allows you to maintain user security information in a WebLogic Server embedded LDAP server and use the WebLogic Server Administration Console to administer the security information from a single system. Requires Tuxedo 8.1 and higher.Use the following steps to configure Oracle WebLogic Tuxedo Connector to provide security between Tuxedo and WebLogic Server applications using the LDAP Plug-in AppKey Generator:
Implementing Single Point Security Administration
Detailed information on how to implement single point security administration, see Implementing Single Point Security Administration. See Understanding Security for Oracle WebLogic Server.
Configure the Local Tuxedo Access Point for the LDAP Plug-in
Set the security
attribute on the Security page of the local Tuxedo access point of your WTC server to match the SECURITY parameter of the *DM_LOCAL_DOMAINS section of the Tuxedo domain configuration file.
Configure the Remote Tuxedo Access Point for the LDAP Plug-in
Configure the Security page of the remote Tuxedo access point of your WTC server to establish an inbound and outbound Access Control List (ACL) policy.
Perform the following steps to prepare the WebLogic Server environment:
- Set the AclPolicy attribute to
GLOBAL
. - Set the CredentialPolicy attribute to
GLOBAL
. - Set the Allow Anonymous attribute for your environment. If you select to allow anonymous users to access Tuxedo, you must set the value of the Default AppKey to be used by anonymous users. See Anonymous Users.
- Select
LDAP
from the AppKey Generator dropdown box. - If necessary, set the value of the Tuxedo UID Keyword attribute and Tuxedo GID attribute. Default values are provided. These keywords for the Tuxedo user ID (UID) is used to extract the Tuxedo UID and GID in the user record of the embedded LDAP database.
Custom Plug-in
The Custom plug-in provides the ability for you to create customized security authentication. Use the following steps to configure Oracle WebLogic Tuxedo Connector to provide security between Tuxedo and WebLogic Server applications using the Custom Plug-in AppKey Generator:
-
Configure the Local Tuxedo Access Point for the Custom Plug-in
-
Configure the Remote Tuxedo Access Point for the Custom Plug-in
See How to Create a Custom AppKey Plug-in in Developing Oracle WebLogic Tuxedo Connector Applications for Oracle WebLogic Server.
Configure the Local Tuxedo Access Point for the Custom Plug-in
Set the security
attribute on the Security page of the local Tuxedo access point of your WTC server to match the SECURITY parameter of the *DM_LOCAL_DOMAINS section of the Tuxedo domain configuration file.
Configure the Remote Tuxedo Access Point for the Custom Plug-in
Configure the Security page of the remote Tuxedo access point of your WTC server to establish an inbound and outbound Access Control List (ACL) policy.
Perform the following steps to prepare the WebLogic Server environment:
- Set the AclPolicy attribute to
GLOBAL
. - Set the CredentialPolicy attribute to
GLOBAL
. - Set the Allow Anonymous attribute for your environment. If you select to allow anonymous users to access Tuxedo, you must set the value of the Default AppKey to be used by anonymous users. See Anonymous Users.
- Select
Custom
from the AppKey Generator dropdown box. - Set the value of the Custom AppKey Class attribute to the full pathname to your Custom AppKey generator class. This class is loaded when the WTC server is started.
- Set the value of the Custom AppKey Param attribute to the optional parameters that you may require to use your Custom AppKey class when it is initialized when the WTC server starts.
Anonymous Users
The Allow Anonymous attribute on the Security page of a remote Tuxedo access point specifies whether the anonymous user is allowed to access Tuxedo. If the anonymous user is allowed to access Tuxedo, the value of the Default AppKey attribute is used for TpUsrFile and LDAP AppKey plug-ins. The TpUsrFile and LDAP plug-ins do not allow users that are not defined in user database to access Tuxedo unless the Allow Anonymous attribute is enabled. Interaction with the Custom AppKey plug-in depends on the design of the Custom AppKey generator.
The default value of the Default AppKey is -1. If you wish to use this value, you must make sure that your Tuxedo environment has a user assigned to that key value. You should avoid assigning the Default AppKey value to 0. In some systems, this specifies the user as root.
Anonymous Users and CORBA Services
It is important to understand the differences between how ATMI services and CORBA services authenticate an anonymous user. ATMI services rely on the Default AppKey value sent with the message. Corba services use the default WebLogic Server anonymous user name <anonymous> to identify the user credential defined in the Tuxedo tpusr file. CORBA users must configure the anonymous user using one of the following methods to become an authenticated user:
-
Add <anonymous> to the Tuxedo tpusr file.
-
Define anonymous as a user in the WebLogic Authentication provider. You do this by setting the following argument when starting a WebLogic Server instance:
-Dweblogic.security.anonymousUserName=anonymous
Link-Level Encryption
You can use encryption 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
attributes on the Security page in the local Tuxedo access points and remote Tuxedo access points configurations of your WTC server.
Secure Socket Level Encryption
This release of WebLogic Server supports Secure Socket Level (SSL) encryption for securing communications between domains, including use of trusted certificates and private keys. You configure this security mechanism by setting attributes in the SSL Configuration, KeyStore Configuration, and the MINENCRYPTBITS
and MAXENCRYPTBITS
attributes on the Security page in the local Tuxedo access points and remote Tuxedo access points configurations of your WTC server. See the following topics in Oracle WebLogic Server Administration Console Online Help:
-
For this release, WTC does not support SSL renegotiation. Any TUXEDO remote access points that communicate with WTC should disable renegotiation feature. By default, the
GWTDOMAIN
disables the SSL renegotiation.