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.

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

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.

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”

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.

• Syntax Requirements for LAUTHSVR Configuration File
  
• LAUTHSVR Configuration File Keywords
  
• Example LAUTHSVR Configuration File
  

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

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.

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
  

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
  

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

• Assigning New Passwords for the tpusr File
  
• tpmigldap Command Line Options
  

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.
• 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
  
• Adding New User Information Using the WebLogic Administration Console
  

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

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.

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.

• Syntax Requirements for GAUTHSVR Configuration File
  
• GAUTHSVR Configuration File Keywords
  
• Example GAUTHSVR Configuration File
  

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"

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
  
• tpusr and tpgrp File Format
  
• Creating a Migration Template
  

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

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

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.

• Syntax Requirements for OAUTHSVR Configuration File
• OAUTHSVR Configuration File Keywords
• OAM Access Client Configuration (OAM_CONFIG_DIR)
• Examples

• Syntax Requirements for OAUTHSVR Configuration File
  
• OAUTHSVR Configuration File Keywords
  
• OAM Access Client Configuration (OAM_CONFIG_DIR)
  
• Examples
  

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.

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.

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

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