Implementing Single Point Security Administration

The following sections explain how to implement single point security administration for Tuxedo and WebLogic Server from the Tuxedo point of view:

•	What Single Point Security Administration Means

•	Setting up LAUTHSVR as the Authentication Server

•	Setting up GAUTHSVR as the Authentication Server

•	Setting up OAUTHSVR as the Authentication Server

Note:

Before setting up single point security, be sure you are familiar with the Tuxedo security architecture and requirements. You may also want to coordinate this effort with your WebLogic or LDAP Administrator.

What Single Point Security Administration Means

If you have both Tuxedo and WebLogic Server deployed in your environment, then you have to manage two sets of security information. Single point security administration allows you to leverage the WebLogic Server security to manage your security database by eliminating user and group information from Tuxedo. You can use WebLogic Server as your security database to authenticate Tuxedo users.

Note:

The Tuxedo ACL information will continue to reside in Tuxedo and is not currently integrated with WebLogic Server 7.0.

If you are specifying SECURITY=ACL or SECURITY=MANDATORY_ACL in the RESOURCES section of the UBBCONFIG file, then you must continue to maintain tpgrp and tpacl files in Tuxedo.

The single point security administration feature leverages the enhanced WebLogic Server 7.0 security and the LDAP to allow single point security administration. You can maintain user security information in WebLogic Server embedded LDAP server and use the WebLogic Server Console to administer the security information from a single system. You must modify the UBBCONFIG file to enable single point security.

Single Point Security Administration Tasks

To set up single point security, you must provide the Tuxedo security information to the WebLogic Server-embedded LDAP server. This includes migrating or setting up the Tuxedo user (UID) and group (GID) information in WebLogic Server LDAP server so that authentication can be successful. For Tuxedo UID and GID values to be available to WebLogic Server, you must use the tpmigldap utility, modify the tpusr file manually with a text editor, or enter the user information via the WebLogic Administration Console.

Note:

The WebLogic Administration Console may be the method used when adding one or two users after the security database is set up. For efficiency and time management, you may prefer using the tpmigldap utility or the tpusr file as a general rule.

Single point security administration consists of the following tasks:

•	Setting up LAUTHSVR as the Authentication Server

•	Using tpmigldap to Migrate User Information to WebLogic Server

•	Setting up GAUTHSVR as the Authentication Server

•	Using tpmigldif to Migrate User Information

•	Adding New Tuxedo User Information

See Also

•	Security information for Oracle WebLogic Server

Setting up LAUTHSVR as the Authentication Server

LAUTHSVR is a System /T provided server that offers the authentication service while the user security information is located in WebLogic Server. To enable the single security administration feature, you must configure LAUTHSVR as the authentication server. At runtime, the LAUTHSVR will retrieve the user information from the WebLogic Server-embedded LDAP and authenticate users. If the authentication is successful, an appkey is returned to the user, otherwise, authentication fails.

Note:

Tuxedo 10 and greater allows you to configure WebLogic authentication using a more general authentication server, GAUTHSVR (which can be used along with LAUTHSVR or replace it).

For more GAUTHSVR information, see Setting up GAUTHSVR as the Authentication Server and GAUTHSVR(5), in the Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference.

To define LAUTHSVR as the authentication server, you must define the following parameters in the UBBCONFIG file:

•	SECURITY must be set to USER_AUTH, ACL, or MANDATORY_ACL in the RESOURCES section.

•	LAUTHSVR must be specified in the SERVERS section.

Note:

If LAUTHSVR cannot find a valid configuration file or the file does not exist, it will log an error message in USERLOG and fail to boot. The default LAUTHSVR configuration file is $TUXDIR/udataobj/tpldap and is provided with the product.

LAUTHSVR Command Line Interface

The LAUTHSVR is the LDAP-based authentication server for Tuxedo. It requires a configuration file, that by default is $TUXDIR/udataobj/tpldap. You can create your own LAUTHSVR configuration file or use the default tpldap file that is available with the product.

The command line interface syntax for LAUTHSVR is as follows:

-f full_pathname

Specifies the full pathname of the LAUTHSVR configuration file.

Note:

If -f option is omitted, the default LAUTHSVR configuration file tpldap is used.

The following example instructs LAUTHSVR to use the default configuration file, tpldap, in the $TUXDIR/udataobj directory.

LAUTHSVR SRVGRP=GROUP1 SRVID=2 CLOPT=”-A-”

In the following example, LAUTHSVR uses the myauthsvr.conf configuration file in the /home/tuxedo/bankapp directory.

LAUTHSVR SRVGRP=GROUP1 SRVID=2
CLOPT=”-A-- -f/home/tuxedo/bankapp/myauthsvr.conf”

Setting Up the LAUTHSVR Configuration File

LAUTHSVR supports an input configuration file that contains information such as bind DN and an unencrypted password for bind DN. This configuration file is a plain text file and can be edited using any text editor and must be protected by the system using file permissions. By default the configuration file, named tpldap, is located in $TUXDIR/udataobj directory. You can overwrite this file in the command line for LAUTHSVR. The LAUTHSVR configuration file contains keyword and value pairs as defined in Table 4‑1.

Syntax Requirements for LAUTHSVR Configuration File

Although the default values for the LAUTHSVR configuration file are usually sufficient, a system administrator may choose to configure it with different names. Therefore, you should be aware of the following requirements for the LAUTHSVR configuration file:

•	The LAUTHSVR configuration file is a plain text file.

•	Keyword order does not matter; however, there must be at least one space character between the keyword and its value.

•	Comments begin with the pound symbol (#). Text after the # is ignored.

•	The upper limit of a line is 255 characters. If a line exceeds this upper limit, it will be truncated.

•	The bind DN must have privileges to access the LDAP database (usually this is the LDAP administrator).

Note:

Before an administrator can set up and use the Tuxedo LDAP-based security authentication server, the administrator must change the LDAP administrator password through the WebLogic Administration Console.

LAUTHSVR Configuration File Keywords

Table 4‑1 defines the LAUTHSVR configuration file keywords.

Note:

The only required keyword in the LAUTHSVR configuration file is PASSWORD, which specifies the password for bind DN. All other keywords are optional.

 

Table 4‑1 LAUTHSVR Configuration File Keywords

Keyword	Value Type	Usage
FILE_VERSION	numeric	The configuration file version. This should always be 1. The default is 1.
LDAP_VERSION	numeric	The LDAP protocol version. Valid values are 2 or 3. The default is 3.
BINDDN	string	The DN used to bind to an LDAP server, usually the DN for the LDAP administrator. The default is “cn=admin”.
BASE	string	LDAP search base. The default is “ou=people, ou=myrealm, dc=mydomain”, where myrealm is the name of the security realm and mydomain is the name of the WebLogic Server domain.
UID	string	The userid attribute that is used to logon to WebLogic Server and Tuxedo. The default is uid.
PASSWORD	string	The password for bind DN. This is a required keyword and the password is in clear text format or encrypted format. The tpldapconf command can be used to create the encrypted password.
LDAP_ADDR	string	A comma separated list of WebLogic hostnames and ports. The syntax is [//]hostname[:port][,[//]hostname[:port]...]. The default value for port is 7001. If LDAP_ADDR is not specified, LAUTHSVR assumes localhost:7001 is the location to contact the LDAP server. For more information about specifying multiple network addresses, refer to “Using Multiple Network Addresses for High Availability.”
EXPIRE	numeric	A numeric value that represents the number of seconds the cached entry is available in the local process memory. A value other than zero will enable caching. A value of zero specifies no caching. The default is zero. For more information about enabling caching, refer to “Using Multiple Network Addresses for High Availability.”
SRCH_ORDER	string	Valid values are LDAP or LOCAL, or both separated by a comma. If you specify LOCAL, the search order will use the tpusr file. The default is LDAP. For more information about database search order, refer to “Configuring the Database Search Order.”
LOCAL_FILE	string	The full pathname of the tpusr file to be used if LOCAL search order is enabled. The default value is $APPDIR/tpusr. For more information about database search order, refer to “Configuring the Database Search Order.” Note: If a directory path is specified other than the default $APPDIR/tpusr, the file must be generated using Tuxedo MIB or tpusradd command line utility. Failure to do this may cause authentication failure.
WLS_DOMAIN	string	The WebLogic Server domain name. The default value is mydomain.
WLS_REALM	string	The WebLogic Server security realm name. The default is myrealm.
ADM_GROUP	string	The WebLogic Server administrator group name. The default is Administrators.
OP_GROUP	string	The WebLogic Server operators group name. The default is Operators.
TUX_UID_KW	string	The keyword used in the description to identify the Tuxedo userid. The default is TUXEDO_UID.
TUX_GID_KW	string	The keyword used in the description to identify the Tuxedo group ID. The default is TUXEDO_GID.

Example LAUTHSVR Configuration File

Listing 4‑1 shows an example of a LAUTHSVR configuration file.

Listing 4‑1 Example LAUTHSVR Configuration File

#
# Tuxedo LDAP Authentication Server configuration file.
#
# created: Thu May 26 15:36:59 2002
#
FILE_VERSION         1
LDAP_VERSION         3
BINDDN               cn=Admin
BASE                 ou=people,ou=myrealm,dc=mydomain
UID                  uid
PASSWORD             secret
LDAP_ADDR             //PLUTO:7001,//Saturn:7001
EXPIRE               0
SRCH_ORDER            LDAP
WLS_DOMAIN            mydomain
WLS_REALM             myrealm
ADM_GROUP             Administrators
OP_GROUP             Operators
TUX_UID_KW           TUXEDO_UID
TUX_GID_KW            TUXEDO_GID
# end of file

 

WARNING:

Because the PASSWORD for the LDAP administrator is in clear text, it is recommended that the system administrator guards this file with correct access permission.

Example UBBCONFIG Using LAUTHSVR

Listing 4‑2 shows an example UBBCONFIG file with SECURITY set to ACL and LAUTHSVR defined.

Listing 4‑2 Example UBBCONFIG File Using LAUTHSVR

*RESOURCES

IPCKEY        51002
MASTER        site1
MAXACCESSERS  50
MAXSERVERS    20
MAXSERVICES   20
MODEL        SHM
LDBAL        N
BLOCKTIME     10
SECURITY      ACL
AUTHSVC       "..AUTHSVC"

*MACHINES
DEFAULT:
       APPDIR="/home/tuxedo/application"
       TUXCONFIG="/home/tuxedo/application/TUXCONFIG"
       TUXDIR="/home/tuxedo/tux81"
Server1        LMID=site1
                     MAXWSCLIENTS=20

*GROUPS
GROUP1        LMID=site1 GRPNO=1
GROUP2        LMID=site1 GRPNO=2
GROUP3        LMID=site1 GRPNO=3
GROUP4        LMID=site1 GRPNO=4

*SERVERS
DEFAULT:
       CLOPT="-A" RESTART=N MAXGEN=5
LAUTHSVR       SRVGRP=GROUP1 SRVID=10
CLOPT="-A -- -F /home/tuxedo/application/lauthsvr.conf "
DMADM         SRVGRP=GROUP2 SRVID=20
GWADM         SRVGRP=GROUP3 SRVID=30
GWTDOMAIN      SRVGRP=GROUP3 SRVID=31
Simpserv       SRVGRP=GROUP4 SRVID=40
*SERVICES
TOUPPER

 

Using Multiple Network Addresses for High Availability

It is possible to configure more than one network address for a WebLogic Server domain. This may be a favorable configuration in order to provide high availability for user authentication. The user security information is replicated to all WebLogic Server-embedded LDAP servers in a WebLogic domain. LAUTHSVR can only connect to one server at a time; however, when a network error occurs, LAUTHSVR will try to connect to the next available address.

To configure multiple network addresses for LAUTHSVR, use the LDAP_ADDR keyword in the LAUTHSVR configuration file. The order in which the hostnames are specified is the order in which LAUTHSVR will try to connect. To use caching during authentication, specify the EXPIRE keyword. The value in this keyword will determine the number of seconds the cached entry is available in the local process memory.

Note:

It is not required to have WebLogic Server available when you boot Tuxedo using tmboot; however, without the availability of at least one WebLogic Server, LAUTHSVRs ability to authenticate users is limited.

Without the availability of WebLogic Server, you can boot Tuxedo and authenticate users using SRCH_ORDER LOCAL. In this case, the user authentication is verified against the tpusr file. For more information about search order, refer to Configuring the Database Search Order.

Example LAUTHSVR Configuration of Multiple Network Addresses

The following example specifies multiple network addresses in the LDAP_ADDR keyword.

LDAP_ADDR //Pluto:8000,//Saturn,Jupiter

The previous example specifies three WebLogic Server hostnames. The first server runs on Pluto and uses address 8000. The second server runs on Saturn and uses the default address 7001. The third server runs on Jupiter and also uses the default address 7001.

Configuring the Database Search Order

By default the LAUTHSVR authentication server will search the user information in the WebLogic Server-embedded LDAP server. To enable the use of the tpusr file in the database search, you must specify LOCAL in the SRCH_ORDER keyword. The order that the comma separated values are defined in the SRCH_ORDER keyword will specify the order in which LAUTHSVR searches for user information. LAUTHSVR will search the LDAP server or the tpusr file or both (according to the order of the values specified).

If there are two or more SRCH_ORDER entries specified in the LAUTHSVR configuration file, only the last entry takes effect. In this case a warning message is logged in USERLOG as well. A warning message also results if you specify a value other than LDAP or LOCAL in the SRCH_ORDER keyword. In this case, the invalid entry is discarded and the default value or a previous valid SRCH_ORDER entry is used.

Example LAUTHSVR Configuration for Database Search Order

The following example specifies that LAUTHSVR should search the WebLogic Server-embedded LDAP server first for user information. If the user information is not found in the LDAP server, then LAUTHSVR should look in the tpusr file.

SRCH_ORDER LDAP,LOCAL

The following example specifies that LAUTHSVR should search the tpusr file first for user information. If the user information is not found in the tpusr file, then LAUTHSVR should look in the WebLogic Server-embedded LDAP server for the information.

SRCH_ORDER LOCAL,LDAP

The following example specifies that LAUTHSVR should search the tpusr file only for user information.

SRCH_ORDER LOCAL

See Also

•	LAUTHSVR(5) and GAUTHSVR(5) in the Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference.

Using tpmigldap to Migrate User Information to WebLogic Server

You should use the tpmigldap command utility to migrate Tuxedo user and group information to WebLogic Server.

Assigning New Passwords for the tpusr File

Before migrating the user and group information, the administrator must assign new passwords for each user so the migration can be successful. This step is required because the passwords in the tpusr file are encrypted with one-way encryption; therefore, it is impossible to retrieve the original password from the file.

There are two ways to handle this password situation:

•	Modify the tpusr file.

You can modify the tpusr file using a text editor and change the user password for each user in the file. The password field is the second field in the tpusr file. The field delimiter is a colon (:). Each user takes up a line in the tpusr file.

The following example:

TuxedoUser1:ADdg0w8nfGMag:6001:601:TPCLTNM,*::
TuxedoUser2:0Yq2s6FjbvuU2:6002:601:TPCLTNM,*::

could be modified to:

TuxedoUser1:User1Password:6001:601:TPCLTNM,*::
TuxedoUser2:User2Password:6002:601:TPCLTNM,*::

•	Use the -f option with the tpmigldap utility to define a default password for all users.

If a -f option is used, then the argument that follows will be used as a substitute for the password field in the tpusr file for every user in the file.

The following example command:

tpmigldap -f userpassword -c

will cause “userpassword” to be assigned to every user in the tpusr file. After the migration, all users will have to use “userpassword” as their password in order to join the Tuxedo application.

tpmigldap Command Line Options

Table 4‑2 defines the command line options for the tpmigldap utility. The order of the command line options does not matter.

Note:

The tpmigldap command requires the use of -w or -c so the user or group can be added to the WebLogic Server-embedded LDAP database.

 

Table 4‑2 tpmigldap Command Line Options

Command Line Option	Option Argument	Default Value	Usage
-h	hostname	localhost	Hostname of WebLogic Server.
-p	port	7001	Port number for WebLogic Server Administration Console.
-d	domain	mydomain	WebLogic Server domain name.
-r	realm	myrealm	WebLogic Server security realm name.
-i	TUXEDO_UID keyword string	TUXEDO_UID	The keyword string for Tuxedo UID that the administrator wants to use in the WebLogic Server user “description” attribute.
-e	TUXEDO_GID keyword string	TUXEDO_GID	The keyword string for Tuxedo GID that the administrator wants to use in the WebLogic Server user “description”.
-f	user password	No default.	The default user password for every user in the tpusr file.
-b	binddn	cn=Admin	LDAP connection bind DN.
-w	password	No default.	The password for bind DN.
-c	Not applicable.	No default.	A prompt for entering a password for bind DN.
-u	full path name	$APPDIR/tpusr	The full directory path for the tpusr file.
-g	full path name	$APPDIR/tpgrp	The full directory path for the tpgrp file.

See Also

•	tpmigldap(1) in the Oracle Tuxedo Command Reference.

Adding New Tuxedo User Information

There are two methods for adding new user and group information to the single security LDAP database:

•	Add new information to the tpusr text file and then specify the updated file when using the migration utility tpmigldap. Refer to Adding New User Information in tpusr or tpgrp.

•	Use the WebLogic Administration Console to add user or group information. Refer to Adding New User Information Using the WebLogic Administration Console.

Note:

Using the WebLogic Administration Console may not be efficient for adding large numbers of users to the LDAP database. In the case of adding several users, you may want to use the tpmigldap utility.

Adding New User Information in tpusr or tpgrp

To add new user information to the single point security LDAP database:

1.	Use your existing tpusr file and tpgrp file to add the new user and group information. Be sure to use the same format previously defined in the file. Be sure to use clear text passwords to add to the LDAP database.

2.	Run the tpmigldap utility using the -u option and specify the updated tpusr file and the -g option and specify the updated tpgrp file. For example:

tpmigldap -u $APPDIR/tpusr -g $APPDIR/tpgrp

Adding New User Information Using the WebLogic Administration Console

To add new user information to the single point security LDAP database using the WebLogic Administration Console:

1.	Access the WebLogic Administration Console and select Security →Realms→ myrealm where myrealm represents the LDAP security realm.

2.	Click Configure a new User... and access the General tab.

Enter the user information:

In the Name field specifies the user name.

In the Description field specify the Tuxedo UID and GID values as a string in the following syntax:

<TUXEDO UID KEYWORD>=<decimal value>
<TUXEDO GID KEYWORD>=<decimal value>

where by default, the TUXEDO UID KEYWORD is TUXEDO_UID and TUXEDO GID KEYWORD by default is TUXEDO_GID. For example:

TUXEDO_UID=2504 TUXEDO_GID=601.

In the Password field, specify the password for the user. Then confirm the password by entering the password again in the Confirm Password field.

3.	Click Apply to update the LDAP database with the new user information.

Setting up GAUTHSVR as the Authentication Server

GAUTHSVR is a System /T provided server usage is similar to LAUTHSVR, but with the following differences:

•	GAUTHSVR can access user security information located in a wide variety of LDAP servers (for example, WebLogic, OpenLDAP, Netscape/IPlanet, Microsoft Active Directory, z/OS LDAP, and so on), using LDAP (Lightweight Directory Access Protocol).

Note:

You can also configure WebLogic authentication using LAUTHSVR. GAUTHSVR can be used along with an existing LAUTHSVR or replace it.

For more LAUTHSVR information, see Setting up LAUTHSVR as the Authentication Server and “LAUTHSVR(5),” in the Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference.

•	GAUTHSVR syntax does not support multiple network addresses for high availability. For more information, see Using Multiple Network Addresses for High Availability.

•	GAUTHSVR does not support user security information stored in a local file. For more information, see Configuring the Database Search Order.

To enable the single security administration feature, GAUTHSVR must be configured as the authentication server. GAUTHSVR authenticates user security information against LDAP server. It returns appkey if SECURITY is set to ACL or MANDATORY_ACL when authentication success.

To configure GAUTHSVR as the authentication server, you must define the following parameters in the UBBCONFIG file:

•	SECURITY must be set to USER_AUTH, ACL, or MANDATORY_ACL in the RESOURCES section.

•	GAUTHSVR must be specified in the SERVERS section.

Note:

If GAUTHSVR cannot find a valid configuration file or the file does not exist, it will log an error message in USERLOG and fail to boot. The default GAUTHSVR configuration file is $TUXDIR/udataobj/tpgauth and is provided with the product.

If you use GAUTHSVR with JDK1.6 or later, please specify the following: JAVA_OPTS=-Djavax.xml.stream.XMLInputFactory=com.bea.xml.stream.MXParserFactory in your environment before booting GAUTHSVR.

If you use GAUTHSVR with Java 1.6, please add the 64-bit JRE library path to LIBPATH. The default library is located in /usr/java6_64/jre/lib/ppc64. Run export LIBPATH=/usr/java6_64/jre/lib/ppc64:$LIBPATH to set the correct LIBPATH.

GAUTHSVR Command Line Interface

GAUTHSVR is an LDAP-based authentication server for Tuxedo. It requires a configuration file, that by default is $TUXDIR/udataobj/tpgauth.

The command line interface syntax for GAUTHSVR is as follows:

-f config

Specifies the full pathname of the GAUTHSVR configuration file.

-o gaconfig.xml

Specifies the full pathname of the GAUTHSVR internal configuration file generated from customer configuration file specified by -f option. The default value is $APPDIR/gaconfig.xml.

-k gakey.dat

Specifies the full pathname of the GAUTHSVR internal configuration file generated from the configuration file (specified in the -f option). The default value is $APPDIR/gakey.dat.

-v

Verbose mode. Logs more detailed messages to ULOG.

The following example instructs GAUTHSVR to use the default configuration file, tpgauth, in the $TUXDIR/udataobj/tpgauth directory.

GAUTHSVR SRVGRP=GROUP1 SRVID=2 CLOPT=”-A --”

In the following example, GAUTHSVR use the myauthsvr.conf configuration file in the /home/tuxedo/bankapp directory.

GAUTHSVR SRVGRP=GROUP1 SRVID=2
CLOPT=”-A -- -f/home/tuxedo/bankapp/myauthsvr.conf”

GAUTHSVR updates the generated XML file if tpgauth is newer than the generated XML and key files. Only changed or newly added tpgauth items are updated in the generated XML file.

Note:

If the XML and key file are not present when GAUTHSVR is booted, GAUTHSVR creates them automatically.

Setting Up the GAUTHSVR Configuration File

GAUTHSVR supports an input configuration file that contains information such as bind DN and an unencrypted password for bind DN. This configuration file is a plain text file and can be edited using any text editor and must be protected by the system using file permissions. By default the configuration file, named tpgauth, is located in $TUXDIR/udataobj/tpgauth directory. You can overwrite this file in the command line for GAUTHSVR. Table 4‑3 lists keywords and value pairs contained in the GAUTHSVR configuration file.

Syntax Requirements for GAUTHSVR Configuration File

Although the default values for the GAUTHSVR configuration file are usually sufficient, you can choose to configure it with different names. Therefore, you should be aware of the following requirements for the GAUTHSVR configuration file:

•	The GAUTHSVR configuration file is a plain text file.

•	Keywords are case-sensitive, but their order does not matter. The keyword format is “keyword=value”.

•	Blank lines or lines starting with a # sign are treated as comments, and are ignored.

•	The upper limit of a line is 255 characters. If a line exceeds this upper limit, it is truncated.

•	The Principal must have privileges to access the LDAP database (usually the LDAP administrator).

GAUTHSVR Configuration File Keywords

GAUTHSVR keywords are divided into three groups: basic, advanced, and LDAP schema. Table 4‑3, Table 4‑4, and Table 4‑5 define the GAUTHSVR configuration file keywords accordingly.

 

Table 4‑3 Basic GAUTHSVR Configuration File Keywords 

Configuration Keyword	Value Type	Description
UserCacheExpire	numeric	A numeric value that represents the number of seconds the cached entry is available in the local process memory. A value other than zero will enable caching. A value of zero specifies no caching. The default value is 0.
UserCacheSize	numeric	Maximum number of entries for user cache where one entry is required for each user. A 0 value of zero specifies no limit. The default value is 0 (indicating no limit).
SYSADM	string	The user name for the Tuxedo SYSADM.
SYSOP	string	The user name for the Tuxedo SYSOP.
Host	string	The host name or IP address of the LDAP server. The default value is localhost.
Port	numeric	The port number on which the LDAP server is listening. The default value is 389.
Principal		The Distinguished Name (DN) of the LDAP user that is used to connect to the LDAP server.
Credential		The credential (generally a password) used to authenticate the LDAP user that is defined in the Principal attribute. The credential can be in clear text format or encrypted format. The tpldapconf command can be used to create the encrypted credential.
RetrieveUIDAndGID	boolean	Specifies whether the UID and GID information are retrieved from the LDAP server. It must be set to true when SECURITY is ACL or MANDATORY_ACL. The default value is false.

 

Table 4‑4 Advanced GAUTHSVR Configuration File Keywords 

Configuration Keyword	Value Type	Description
TuxedoUIDKey	string	Used to identify the Tuxedo UID. The default value is TUXEDO_UID.
TuxedoGIDKey	string	Used to identify the Tuxedo GID The default value is TUXEDO_GID.
ConnectTimeout	numeric	The maximum number of seconds to wait for the LDAP connection to be established. If set to 0, there is no maximum time limit. The default value is 0.
ConnectionRetryLimit	numeric	The number of times to attempt to connect to the LDAP server if the initial connection failed. The default value is 1.
ResultsTimeLimit	numeric	The maximum number of milliseconds to wait for results before timing out. If set to 0, there is no maximum time limit. The default value is 0.
SSLEnabled	boolean	Specifies that SSL is used to connect to the LDAP server. The default value is false.
KeepAliveEnabled	boolean	Specifies whether to prevent LDAP connections from timing out or not. The default value is false.
ParallelConnectDelay	numeric	The number of seconds to delay when making concurrent attempts to connect to multiple servers. If set to 0, connection attempts are serialized. An attempt is made to connect to the first server in the list. The next entry in the list is tried only if the attempt to connect to the current host fails. This might cause your application to block for unacceptably long time if a host is down. If set to greater than 0, another connection setup thread is started after this number of delay seconds has passed. The default value is 0.
FollowReferrals	boolean	Specifies whether referrals are automatically followed within the LDAP Directory or not. If set to false, a referral exception is sent when referrals are encountered during LDAP requests. The default value is true.
BindAnonymouslyOnReferrals	boolean	Specifies to anonymously bind when following referrals within the LDAP directory. If set to false, then the current Principal and Credential are used. The default value is false.
UseZOSRACF	boolean	Specifies whether the LDAP server is z/OS RACF LDAP server. The default value is false
ControlFlag	string	Specifies how Tuxedo LDAP Authentication provider fits into the login sequence. The Control Flag determines how the login sequence uses the Authentication provider. A REQUIRED value specifies this LoginModule must succeed. Even if it fails, authentication proceeds down the list of LoginModules for the configured Authentication providers. This setting is the default. A REQUISITE value specifies this LoginModule must succeed. If other Authentication providers are configured and this LoginModule succeeds, authentication proceeds down the list of LoginModules. Otherwise, control is return to the application. A SUFFICIENT value specifies this LoginModule need not succeed. If it does succeed, return control to the application. If it fails and other Authentication providers are configured, authentication proceeds down the LoginModule list. An OPTIONAL value specifies this LoginModule need not succeed. Whether it succeeds or fails, authentication proceeds down the LoginModule list. The default value is REQUIRED.

 

Table 4‑5 LDAP Schema Configuration File Keywords 

Configuration Keyword	Value Type	Description
UserObjectClass	string	The LDAP object class that stores users The default is person.
UserBaseDN	string	The base distinguished name (DN) of the tree in the LDAP directory that contains users. The default value is ou=people, o=example.com
UserFromNameFilter	string	An LDAP search filter for finding a user given the name of the user. The default value is (&(cn=%u)(objectclass=person))
UserSearchScope	string	Specifies how deep in the LDAP directory tree to search for users. Valid values are "subtree, onelevel". The default value is subtree.
UserUIDAttrName	string	The attribute name of an LDAP user object that specifies the UID of the user or the UID and GID of the user in a fixed format. The default value is userid.
UIDAttrValueType	string	Specifies the value type of the uid attribute for the LDAP user object. Legal values include UID, and UIDAndGID. The default value is UID. Note: When SECURITY is ACL or MANDATORY_ACL, it must be set to UIDAndGID.
UserGroupAttrNames	string	The attribute names of an LDAP user object that specify the groups the user belongs to. This attribute can contain three types of values: GID, group CN and group DN. One type of value for each configuration. More names are separated by comma. The default value is usergroups.
GroupAttrValueType	string	Specifies the value type of the group attributes for the LDAP user object. Legal values include "GID, group CN, and group DN". The default value is GID.
GroupBaseDN	string	The base distinguished name (DN) of the tree in the LDAP directory that contains groups. The default value is ou=groups, o=example.com.
GroupFromNameFilter	string	An LDAP search filter for finding a group given the name of the group. The default value is (&(cn=%g)(objectclass=groupofuniquenames)).
StaticGroupObjectClass	string	The name of the LDAP object class that stores static groups The default value is groupofuniquenames.
GroupSearchScope	string	Specifies how deep in the LDAP directory tree to search for groups. Valid values are "subtree, onelevel" The default value is subtree.
GroupGIDAttrName	string	The attribute of a LDAP group object that specifies the GID of the group The default value is groupid.

Example GAUTHSVR Configuration File

Listing 4‑3 shows a GAUTHSVR configuration file for WebLogic Server example. Please refer to this example when configuring other LDAP servers.

Listing 4‑3 Example WebLogic GAUTHSVR Configuration File

#
# Tuxedo LDAP Authentication Server configuration file.
#
# created: Thu May 26 15:36:59 2002
# end of file

# Tuxedo configuration
UserCacheExpire = 600
UserCacheSize = 16384
SYSADM = sysadm
SYSOP = sysop

# LDAP server configuration
Host = server.bea.com
Port = 7001

Principal = cn=Admin
Credential= weblogic

UserObjectClass = person
UserBaseDN = ou=people,ou=myrealm,dc=examples
UserFromNameFilter = (&(uid=%u)(objectclass=person))
UserUIDAttrName = description
UserGroupAttrNames=wlsMemberOf
RetrieveUIDAndGID = true
UIDAttrValueType = UIDAndGID

 

Note:

Make sure UID =* and GID = * in the LDAP description are the same as defined in SECURITY IS ACL.

WARNING:

Because the PASSWORD for the LDAP administrator is in clear text, it is recommended that the system administrator guards this file with correct access permission.

Example UBBCONFIG Using GAUTHSVR

Listing 4‑4 shows an example UBBCONFIG file with SECURITY set to ACL and GAUTHSVR defined.

Listing 4‑4 Example UBBCONFIG File Using GAUTHSVR

# UBBCONFIG

*SERVER

GAUTHSVR SVRGRP="SYSGRP" SVRID=100
              CLOPT="-A -- -f ${APPDIR}/tpgauth"
              ENVFILE="${APPDIR}/tpgauth.env"

 

See Also

•	GAUTHSVR(5) and LAUTHSVR(5) in the Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference

Using tpmigldif to Migrate User Information

You can use the tpmigldif command utility to migrate Tuxedo user and group information to LDAP servers in LDAP Interchange Format (LDIF). In order to use tpmigldif, you must create a migration template.

Using tpmigldif Command Line Options

Table 4‑6 lists the command line options for the tpmigldif utility. The order of the command line options does not matter.

 

Table 4‑6 tpmigldif Command Line Options 

Command Line Option	Option Argument	Default Value	Usage
-t	user|group	user	Specifies migration type.
-f	template filename	tpusr-template (when type is user), or tpgrp-template(when type is group)	Specifies the template file name.
-o	o (output filename)	console/stdout	Specifies the output file name.
-u	full path name	tpusr	The full directory path for the tpusr file.
-g	full path name	tpgrp	The full directory path for the tpgrp file.

tpusr and tpgrp File Format

Listing 4‑5 shows a tpusr file with five fields separated by a colon:

name:password(encrypted):user id:group id:client name::

Listing 4‑5 Example tpusr File

user1:EI4xxxjrCc:16668:601:TPCLTNM,client::
user2:EI4xxxjrCc:16669:602:TPCLTNM,client::

 

Listing 4‑6 shows a tpgrp file with three fields separated by a colon:

name::group id:

Listing 4‑6 Example tpgrp File

group1::601:
group2::602:

 

Assigning New Passwords for the tpusr File (Optional)

Before migrating the user and group information, the administrator could assign new passwords for each user so the generated LDIF output contains correct password for each user. This step is required because the passwords in the tpusr file are encrypted with one-way encryption; therefore, it is impossible to retrieve the original password from the file.

Using a text-editor, there are two methods you can use to modify tpusr file passwords:

•	Modify the tpusr file password field to change the user password for each user in the file. The password field is the second field in the tpusr file. Each user is entered on a separate line in the tpusr file. See listing Listing 4‑5, for original tpusr file example.

user1:pwd1:16668:601:TPCLTNM,client::
user2:pwd2:16669:602:TPCLTNM,client:

•	Add a new password to the last tpusr file field

user1:EI4xxxjrCc:16668:601:TPCLTNM,client::pwd1:
user2:EI4xxxjrCc:16669:602:TPCLTNM,client::pwd2:

Creating a Migration Template

The migration template is a text file used by the tpmigldif command utility to translate the tpusr or tpgrp file into an LDIF output file.

Listing 4‑7 shows a tpusr-template migration file example. <%n> refers to a tpusr file field, where n starts at 1.

Note:

Use <%gn> for group field in tpgrp file for given user.

Listing 4‑7 tpusr-template

dn: CN=<%1>,CN=Users,DC=tuxdev,DC=bea,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: user
cn: <%1>
description: Tuxedo User, TUXEDO_UID=<%3> TUXEDO_GID=<%4>
password: <%7>

 

Listing 4‑8 shows the LDIF output from the tpusr-template.

Listing 4‑8 LDIF Output

dn: CN=user1,CN=Users,DC=tuxdev,DC=bea,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: user
cn: user1
description: Tuxedo User, TUXEDO_UID=16668 TUXEDO_GID=601
password: pwd1

dn: CN=user2,CN=Users,DC=tuxdev,DC=bea,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: user
cn: user2
description: Tuxedo User, TUXEDO_UID=16669 TUXEDO_GID=602
password: pwd2

 

Supported LDAP Server Template Example

Tuxedo provides an example template for supported LDAP servers. The files are listed in Table 4‑7.

 

Table 4‑7 Supported LDAP Server Template Example¹

LDAP Server	GAUTHSVR Configuration	User Migration Template	Group Migration Template
WebLogic Server	tpgauth	tpusr-template	tpgrp-template
Active Directory2	tpgauth-ad	tpusr-template-ad	tpgrp-template-ad
IPlanet	tpgauth-iplanet	tpusr-template-iplanet	tpgrp-template-iplanet
z/OS LDAP, with RACF backend3	tpgauth-racf	tpusr-template-racf	tpgrp-template-racf

---

1

All files are available under $TUXDIR/udataobj.

2

For Active Directory user’s password cannot be added on creation. For help on how to change or reset it, please refer to Microsoft support document, http://support.microsoft.com/kb/269190, http://support.microsoft.com/kb/263991, etc;

3

Two things need to be done to activate z/OS RACF account after migration: i) reset the password by z/OS administrator; and ii) logon with the account to change its password.

Setting up OAUTHSVR as the Authentication Server

•	Setting Up the OAUTHSVR Configuration File

•	/T DOMAIN Support

•	Oracle SALT Support

•	WTC Support

•	Oracle JCA Support

OAUTHSVR is a Tuxedo provided server that offers the authentication and authorization service while the user security information is located in Oracle Access Manager (OAM) Server. To enable the single security administration feature, you must configure OAUTHSVR as the authentication server. At runtime, the OAUTHSVR will authenticate and authorize the user using OAM Server

To define OAUTHSVR as the authentication server, you must define the following parameters in the UBBCONFIG file:

•	SECURITY must be set to USER_AUTH, ACL, or MANDATORY_ACL in the RESOURCES section.

•	A TMJAVASVR with <server-class name="OAUTHSVR"/> must be specified in the SERVERS section.

Setting Up the OAUTHSVR Configuration File

OAUTHSVR supports an input configuration file that contains information such as OAM access client configuration file and the resource type mapping between Tuxedo and OAM. This configuration file is a plain text file and can be edited using any text editor and must be protected by the system using file permissions. By default the configuration file, named tpoam.auth, is located in $TUXDIR/udataobj directory. You can overwrite this file in the command line for OAUTHSVR. The OAUTHSVR configuration file contains keyword and value pairs as defined in Table 4‑8

•	Syntax Requirements for OAUTHSVR Configuration File

•	OAUTHSVR Configuration File Keywords

•	OAM Access Client Configuration (OAM_CONFIG_DIR)

•

Examples

Syntax Requirements for OAUTHSVR Configuration File

•	Although the default values for the OAUTHSVR configuration file are usually sufficient, a system administrator may choose to configure it with different names. Therefore, you should be aware of the following requirements for the OAUTHSVR configuration file:

•	The OAUTHSVR configuration file is a plain text file.

•	Keyword order does not matter; however, there must be at least one space character between the keyword and its value.

•	Comments begin with the pound symbol (#). Text after the # is ignored.

Note:

Before an administrator can set up and use the Tuxedo OAM-based security authentication and authorization server, the administrator must register a OAM access client or use already installed WebGate. For how to register and configure OAM access client, please refer Oracle OAM documents.

OAUTHSVR Configuration File Keywords

Table 4‑8 lists the OAUTHSVR configuration file keywords.

 

Table 4‑8 OAUTHSVR Configuration File Keywords

Keyword	Value Type	Usage
OAM_CONFIG_DIR	string	The directory location where OAM access client configuration file will be searched. The access client configuration can be obtained by registering an access client as an OAM 11g Agent with the OAM 11g server or copied from already installed WebGate.
RESTYPE_MAPPING	string	The resource type mapping between Tuxedo and OAM. Format is "RESTYPE_MAPPING $TUX_RESTYPE $OAM_RESTYPE", multiple resource types can be defined, such as RESTYPE_MAPPING SERVICE TUXEDO_SERVICE RESTYPE_MAPPING QUEUE TUXEDO_QUEUE RESTYPE_MAPPING EVENT TUXEDO_EVENT If the resource type name defined in OAM is same as Tuxedo resource type, no mapping is needed.
TUXEDO_DEF_RESTYPE	string	The Tuxedo default resource type defined in OAM. The default is "TUXEDO_SERVICE".
TUXEDO_DEF_RESOURCE	string	The Tuxedo default resource defined in OAM. OAM always requires a resource to figure out the authentication level and policies to authenticate a user. Administrator need define a default resource. The default is "tuxres".

OAM Access Client Configuration (OAM_CONFIG_DIR)

OAM Access Client configuration information is needed by OAM. Fo more information, see OAM documents https://docs.oracle.com/cd/E52734_01/oam/AIDEV/as_api.htm#AIDEV151.

Limitations

OAUTHSVR does not support OAM 10g agent; 11g or above WebGate agent is required. An example 11gR1PS2 OAM configuration directory is shown in Listing 4‑9 .

Listing 4‑9 Example 11gR1PS2 OAM Configuration Directory

OAM_CONFIG_DIR/

|------config/

|------ cwallet.sso (Get from WebGate)

|------ jps-config.xml (Get from OAM SDK)

|------ ObAccessClient.xml (Get from WebGate)

 

Another example configuration directory for OAM12cR2 is shown in Listing 4‑10 (the communication transportation security mode between the Agent and OAM server is Simple or Cert).

Listing 4‑10 Example 11gR1PS3 OAM Configuration Directory

OAM_CONFIG_DIR/

|------config/

|------ cwallet.sso (Get from WebGate)

|------ jps-config.xml (Get from OAM SDK)

|------ ObAccessClient.xml (Get from WebGate)

|------ oamclient-keystore.jks (Get from WebGate)

|------ oamclient-truststore.jks (Get from WebGate)

|------ password.xml (Get from WebGate)

 

For more information, see OAM documents http://docs.oracle.com/cd/E21764_01/install.1111/e12002/webgate.htm#INOIM75755.

Note:

In OAM server host, under directory <OAM_DOMAIN_HOME>/output/<WebGate_ID> you can find cwallet.sso and ObAccessClient.xml file.

Examples

1. Example OAUTHSVR Configuration File

2. Example UBBCONFIG Using OAUTHSVR

3. Example tjsoam.xml Java Server Configuration File

1. Example OAUTHSVR Configuration File

Table 4‑11 shows an example of a OAUTHSVR configuration file.

Listing 4‑11 Example OAUTHSVR Configuration File

# Tuxedo OAM Authentication Server configuration file.

 

OAM_CONFIG_DIR /usr/tuxedo/accessclient

#RESTYPE_MAPPING SERVICE TUXEDO_SERVICE

#RESTYPE_MAPPING QUEUE TUXEDO_QUEUE

#RESTYPE_MAPPING EVENT TUXEDO_EVENT

TUXEDO_DEF_RESTYPE TUXEDO_SERVICE

TUXEDO_DEF_RESOURCE tuxres

 

# end of file

 

2. Example UBBCONFIG Using OAUTHSVR

Table 4‑12 shows an example UBBCONFIG file with SECURITY set to ACL and OAUTHSVR defined.

Listing 4‑12 Example UBBCONFIG File Using OAUTHSVR

*RESOURCES

 

IPCKEY 51002

MASTER site1

MAXACCESSERS 50

MAXSERVERS 20

MAXSERVICES 20

MODEL SHM

LDBAL N

BLOCKTIME 10

SECURITY ACL

AUTHSVC "..AUTHSVC"

OPTIONS EXT_AA

 

 

*MACHINES

DEFAULT:

APPDIR="/home/tuxedo/application"

TUXCONFIG="/home/tuxedo/application/TUXCONFIG"

TUXDIR="/home/tuxedo/tuxedo12"

Server1 LMID=site1

MAXWSCLIENTS=20

 

*GROUPS

GROUP1 LMID=site1 GRPNO=1

GROUP2 LMID=site1 GRPNO=2

GROUP3 LMID=site1 GRPNO=3

GROUP4 LMID=site1 GRPNO=4

 

*SERVERS

DEFAULT:

CLOPT="-A" RESTART=N MAXGEN=5

TMJAVASVR SRVGRP=GROUP1 SRVID=2 CLOPT="-A -- -c tjsoam.xml"

 

DMADM SRVGRP=GROUP2 SRVID=20

GWADM SRVGRP=GROUP3 SRVID=30

GWTDOMAIN SRVGRP=GROUP3 SRVID=31

Simpserv SRVGRP=GROUP4 SRVID=40

 

*SERVICES

TOUPPER

 

3. Example tjsoam.xml Java Server Configuration File

Table 4‑13shows an example Java Server configuration file using OAUTHSVR.

Listing 4‑13 Example Java Server Configuration File Using OAUTHSVR

<?xml version="1.0" encoding="UTF-8"?>

<TJSconfig version="2.0">

<!-- do not forget modify $TUXDIR $OAMASDK_DIR to absolute path -->

<java-config>

<jvm-options>-Doracle.security.jps.config=/home/tuxedo/application/oamclient/config/jps-config.xml</jvm-options>

<jvm-options>-Doracle.tuxedo.oam.config=tpoam.auth</jvm-options>

</java-config>

 

<classpath-config>

<classpath>/home/tuxedo/udataobj/tuxj/oam/com.oracle.tuxedo.tjoam.jar</classpath>

<classpath>/home/tuxedo/oamsdk/*</classpath>

</classpath-config>

 

<tux-server-config>

<server-class name="OAUTHSVR"/>

</tux-server-config>

 

</TJSconfig>

 

/T DOMAIN Support

ACL_POLICY and CREDENTIAL_POLICY impact credential propagation.

When local domain receives request from remote domain, if ACL_POLICY is set to LOCAL, the local domain removes the OAM session token of any service request received from the remote domain if session token exists. If ACL_POLICY is set to GLOBAL the local domain does not remove the OAM session token received with a remote service request.

When a Tuxedo domain sends request to a remote /T domain, if CREDENTIAL_POLICY is set to LOCAL, then the local domain removes the session token from a local service request destined for the remote domain access point. If CREDENTIAL_POLICY is set to GLOBAL, the local domain does not remove the session token from a local service request destined for this remote domain access point.

From above description we can see to pass OAM session token between Tuxedo /T domains, ACL_POLICY and CREDENTIAL_POLICY should both configured to GLOBAL, and same OAM access client configuration (OAM_CONFIG_DIR parameter in OAUTHSVR configuration file) should be used to ensure the OAM session token is valid in both domains.

To authenticate or authorize user requests, username/password pair or valid session token issued by OAM server must exist. If both username/password pair and valid session token do not exist, it is not possible to impersonate the desired principle; authentication or authorization with OAM server cannot be done.

When domain gateway receives a request, if ACL_POLICY is set to LOCAL, or the request doesn't contain OAM session token (for example, remote domain doesn't use OAM, or CREDENTIAL_POLICY is set to LOCAL, or Tuxedo version of remote domain is not 12.2.2.0.0 or later, or remote domain can't pass OAM session token like WTC), to impersonate the desired principle, the local domain gateway replaces the credential of any service request received from the remote domain with the principle name specified in the LOCAL_PRINCIPAL_NAME parameter (if not specified, the principle name defaults to the ACCESSPOINTID string for the remote domain access point) for this remote domain access point, the password will use "Remote Domain Password", that is the SECURITY parameter in the DM_LOCAL section of the DMCONFIG file must set to DM_PW. User LOCAL_PRINCIPAL_NAME (or ACCESSPOINTID) with same password as "Remote Domain Password" must be defined in OAM. If these prerequisites are not met and SECURITY in UBBCONFIG is set to ACL or MANDATORY_ACL, authorization will fail.

Oracle SALT Support

OAM integration only support SALT inbound request, for HTTP Basic Authentication GWWS will extract username and password and calls Tuxedo AUTHSVC to authenticate the user, OAUTHSVR will communicate with OAM to authenticate, if it is successful then GWWS will retrieve OAM session token, the session token will be passed in following service call, OAUTHSVR will use the session token to authorize.

For WSSE situation, GWWS will use user credential received and authenticate with Tuxedo, before it calls Tuxedo service it will check if auth level is TPAPPAUTH and insert the session token into context and call Tuxedo service.

If it is either X509 authentication or SAML SSO is used then it depends on whether Basic Authentication is attached to the request. If Basic Authentication is not attached to the request, Tuxedo cannot retrieve username and password, authorization will fail.

If user is already authenticated with WebGate and the OAM session token is exist in HTTP header, GWWS will extract the token and use it to authorize.

WebGate is a agent provided for various Web Servers (Oracle HTTP server - OHS, IBM HTTP server -IHS, Apache ...) as part of the OAM product. It's installed on different HTTP server, to use OAM for authentication and authorization, HTTP server and WebGate are necessary. Often the HTTP server works as reverse proxy to backend applications, such as WLS or SALT

Note:

For 11g WebGate, the OAM token cookie (OAMAuthnCookie) is not passed to downstream applications such as SALT, please specify WebGate user-defined parameter filterOAMAuthnCookie to false. For more information, see Registering and Managing OAM 11g Agents.

WTC Support

For WTC inbound service, client is authenticated in Tuxedo domain, the request is passed to WTC. WTC will look up the EJB name and invoke the target EJB using passed principle (ACL_POLICY is global) or domain name (ACL_POLICY is local). No authentication is required, although WLS security module will check the authorization of this principle (security identity). The target EJB will receive the identity only, it will not receive any authentication data. There is no way for WLS to authenticate the identity, the identity is only used in authorization checks. The OAM session token will not pass to WTC.

For WTC outbound service, the authentication only occurs in WLS, the authorization check should also occurs in WLS. When WTC pass the request to Tuxedo domain, user is already authenticated, WTC cannot get the OAM session token from WLS. Tuxedo local domain gateway will use the same approach as /T domain to impersonate desired principle (LOCAL_PRINCIPAL_NAME or ACCESSPOINTID and remote domain password).

Oracle JCA Support

Tuxedo JCA adapter can't and should not be changed for OAM as JCA architecture has its own way of importing the security principal identity, and we should not break the contract and made it not portable between different Java AS. JCA architecture specification has its own way and that is supported by all JCA 1.6 compliant JCA

See Also

•	tpmigldif(1) in the Oracle Tuxedo Command Reference