1. Using Security in ATMI Application
  2. Implementing Single Point Security Administration

4 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:

Note:

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

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

Parent topic: Implementing Single Point Security Administration

4.1.1 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:

See Also:

Parent topic: What Single Point Security Administration Means

4.2 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.
  • 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.

Parent topic: Implementing Single Point Security Administration

4.2.1 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”

Parent topic: Setting up LAUTHSVR as the Authentication Server

4.2.2 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 the following table.

Parent topic: Setting up LAUTHSVR as the Authentication Server

4.2.2.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.
4.2.2.2 LAUTHSVR Configuration File Keywords

The following table 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 my realm is the name of the security realm and my domain is the name of the WebLogic Server domain.
UID string The user id 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.
4.2.2.3 Example LAUTHSVR Configuration File

The following listing describes an example of a LAUTHSVR configuration file.

Listing 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:

It is recommended that the system administrator secures this file with the correct access permissions, as the PASSWORD for the LDAP administrator is in clear text.

4.2.3 Example UBBCONFIG Using LAUTHSVR

The following listing describes an example UBBCONFIG file with SECURITY set to ACL and LAUTHSVR defined.

Listing 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

Parent topic: Setting up LAUTHSVR as the Authentication Server

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

Parent topic: Setting up LAUTHSVR as the Authentication Server

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

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

Parent topic: Setting up LAUTHSVR as the Authentication Server

4.2.5.1 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

Note:

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

4.2.6 Using tpmigldap to Migrate User Information to WebLogic Server

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

Parent topic: Setting up LAUTHSVR as the Authentication Server

4.2.6.1 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
    causes “userpassword” to be assigned to every user in the tpusr file. After the migration, all users can use “userpassword” as their password in order to join the Tuxedo application.
4.2.6.2 tpmigldap Command Line Options

The following table describes 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_GID 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:

Parent topic: Using tpmigldap to Migrate User Information to WebLogic Server

4.2.7 Adding New Tuxedo User Information

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

Parent topic: Setting up LAUTHSVR as the Authentication Server

4.2.7.1 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
4.2.7.2 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 Consol

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

    Figure 4-1 WebLogic Administration Console Select Users


    WebLogic Administration Console Select Users Diagram

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

    Figure 4-2 WebLogic Administration Console Create Users


    WebLogic Administration Console Create Users Diagram

    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.

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

Parent topic: Implementing Single Point Security Administration

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

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

Parent topic: Setting up GAUTHSVR as the Authentication Server

4.3.2 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. The following table lists keywords and value pairs contained in the GAUTHSVR configuration file.

Parent topic: Setting up GAUTHSVR as the Authentication Server

4.3.2.1 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 must 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).
4.3.2.2 GAUTHSVR Configuration File Keywords

GAUTHSVR keywords are divided into three groups: basic, advanced, and LDAP schema. The following tables describe 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. A0 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.
4.3.2.3 Example GAUTHSVR Configuration File

The following Listing 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:

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

WARNING:

It is recommended that the system administrator secures this file with the correct access permissions, as the PASSWORD for the LDAP administrator is in clear text.

4.3.3 Example UBBCONFIG Using GAUTHSVR

The following listing describes an example UBBCONFIG file with SECURITY set to ACL and GAUTHSVR defined.

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

Parent topic: Setting up GAUTHSVR as the Authentication Server

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

Parent topic: Setting up GAUTHSVR as the Authentication Server

4.3.4.1 Using tpmigldif Command Line Options

The following table 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 thetpusr file.
-g full path name tpgrp The full directory path for thetpgrp file.
4.3.4.2 tpusr and tpgrp File Format

The following listing shows a tpusr file with five fields separated by a colon: 

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

Listing Example tpusr File

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

The listing shows a tpgrp file with three fields separated by a colon: 

name::group id:

Listing Example tpgrp File

group1::601:
         group2::602:
4.3.4.2.1 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 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:
4.3.4.3 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.

The following listing 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 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>

The following listing shows the LDIF output from the tpusr-template.

Listing 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

4.3.5 Supported LDAP Server Template Example

Tuxedo provides an example template for supported LDAP servers. The following table lists the files: 1.

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 Directory 2 tpgauth-ad tpusr-template-ad tpgrp-template-ad
IPlanet tpgauth-iplanet tpusr-template-iplanet tpgrp-template-iplanet
z/OS LDAP, with RACF backend 3 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 require to be completed for activating z/OS RACF account after migration:
  1. reset the password by z/OS administrator
  2. logon with the account to change its password

Parent topic: Setting up GAUTHSVR as the Authentication Server

4.4 Setting up OAUTHSVR as the Authentication Server

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 authenticates and authorizes 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-classname="OAUTHSVR"/> must be specified in the SERVERS section.

Parent topic: Implementing Single Point Security Administration

4.4.1 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 the following table.

Parent topic: Setting up OAUTHSVR as the Authentication Server

4.4.1.1 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.
4.4.1.2 OAUTHSVR Configuration File Keywords

The following table 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".
4.4.1.3 OAM Access Client Configuration (OAM_CONFIG_DIR)

OAM Access Client configuration information is required by OAM.

For more information, see OAM documents https://docs.oracle.com/cd/E52734_01/oam/AIDEV/as_api.htm#AIDEV151

4.4.1.3.1 Limitations

OAUTHSVR does not support OAM 10g agent; 11g or above WebGate agent is required. An example 11gR1PS2 OAM configuration directory is shown in the following listing .

Listing 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 the following listing (the communication transportation security mode between the Agent and OAM server is Simple or Cert).

Listing 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.
4.4.1.4 Examples
4.4.1.4.1 1. Example OAUTHSVR Configuration File

The following listing describes an example of a OAUTHSVR configuration file.

Listing 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

Parent topic: Examples

4.4.1.4.2 2. Example UBBCONFIG Using OAUTHSVR

The following listing describes an example UBBCONFIG file with SECURITY set to ACL and OAUTHSVR defined.

Listing 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

Parent topic: Examples

4.4.1.4.3 3. Example tjsoam.xml Java Server Configuration File

The following listing describes an example Java Server configuration file using OAUTHSVR.

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

Parent topic: Examples

4.4.2 /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) must be used to ensure that 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 you do not meet these prerequisites and SECURITY in UBBCONFIG is set to ACL or MANDATORY_ACL, authorization fails.

Parent topic: Setting up OAUTHSVR as the Authentication Server

4.4.3 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 is passed in following service call, OAUTHSVR uses 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.

Parent topic: Setting up OAUTHSVR as the Authentication Server

4.4.4 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).

Parent topic: Setting up OAUTHSVR as the Authentication Server

4.4.5 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:

Parent topic: Setting up OAUTHSVR as the Authentication Server