Skip navigation.

File Formats, Data Descriptions, MIBs, and System Processes Reference

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

 


SECURITY USER_AUTH

If SECURITY is set to USER_AUTH, per-user authentication is enforced. The name of the authentication service can be configured for the application using the AUTHSVC parameter in the RESOURCES section of the UBBCONFIG file. For example, the following AUTHSVC parameter setting specifies the authentication service (AUTHSVC) advertised by AUTHSVR when SECURITY is set to USER_AUTH.

*RESOURCES
SECURITY   USER_AUTH
AUTHSVC    AUTHSVC

If the AUTHSVC parameter is not specified, the authentication service defaults to AUTHSVC.

By default, the file tpusr in the directory referenced by the first pathname defined in the application's APPDIR variable is searched for password information; /etc/passwd is used if this file does not exist (although this file cannot be used correctly on systems that have a shadow password file). The file can be overridden by specifying the filename using a "-f filename" option in the server command-line options (for example, CLOPT="-A -- -f /usr/tuxedo/users"). Note that automatic propagation of the user file from the master machine to other machines in the configuration is done only if $APPDIR/tpusr is used.

The user file is searched for a matching username and client name. There are four types of entries in the user file. They are listed below in order of matching precedence when validating a user against the file.

  1. Exact username/exact clientname
  2. Wildcard username (*)/exact clientname
  3. Exact username/wildcard clientname (*)
  4. Wildcard username (*)/wildcard clientname (*)

An authentication request is authenticated against only the first matching password file entry. These semantics allow for a single user to have multiple entries (usually with different client names) and the username may be a wildcard. These semantics are allowed if the user file is maintained using tpaddusr(), tpdelusr(), and tpmodusr(). Note that use of these semantics is not compatible with the semantics for ACL and MANDATORY_ACL and will make migration to these security levels difficult. To get the restricted semantics for compatibility with ACL security, use the tpusradd(), tpusrdel(), and tpusrmod() programs to maintain the user file.

Note: To use tpusradd(), tpusrdel(), and tpusrmod(), SECURITY for the target application must be set to USER_AUTH, ACL, or MANDATORY_ACL. Otherwise, the system returns an error when you attempt to use these programs.

The reserved client name values tpsysadm (system administrator) and tpsysop (system operator) are treated specially by AUTHSVR(5) when processing authentication requests. These values are not allowed to match wildcard client names in the user file.

The application key that is returned by the AUTHSVR is the user identifier. This application key is passed to every service in the appkey element of the TPSVCINFO structure.

Note that a standard AUTHSVR is shipped as part of the system in ${TUXDIR}/bin/AUTHSVR and has the semantics as described above. Sample source code is provided in ${TUXDIR}/lib/AUTHSVR.c. The AUTHSVR can be replaced by an application authentication server that validates users and user data (which may not be a password) in an application-dependent fashion (for example, using Kerberos). If you plan to replace AUTHSVR, take special note of the warning later in this reference page. It is also up to the application to determine what value is returned from the authentication service to be used for the application key (which is passed to each service).

The application keys that correspond to tpsysadm and tpsysop are 0x80000000 and 0xC0000000, respectively.

 

Skip navigation bar  Back to Top Previous Next