Default Authentication and Authorization

The default authentication and authorization plug-ins provided by the ATMI environment of the BEA Tuxedo product work in the same manner that implementations of authentication and authorization have worked since they were first made available with the BEA Tuxedo system.

An application administrator can use the default authentication and authorization plug-ins to configure an ATMI application with one of five levels of security. The five levels are:

At the lowest level, no authentication is provided. At the highest level, an access control checking feature determines which users can execute a service, post an event, or enqueue (or dequeue) a message on an application queue. The security levels are briefly described in the following table.

Security Levels for Default Authentication and Authorization

Security Level	Description
No authentication	Clients do not have to be verified before joining the ATMI application. When joining an ATMI application at this security level, a user has access to all application resources.
Application password	The application administrator defines a single password for the entire ATMI application, and clients must provide the password to join the application. When successfully joining an ATMI application at this security level, a user has access to all application resources.
User-level authentication	In addition to the application password, each client must provide a valid username and user-specific data, such as a password, to join the ATMI application. When successfully joining an ATMI application at this security level, a user has access to all application resources.
Optional ACL security	Clients must provide the application password, a username, and user-specific data such as a password. For a user who successfully joins an ATMI application at this security level, access to application resources is restricted in the following way. The ACL database contains a list of application resources and, for each resource, a list of users with permission to use it. A user who is not included in the list for a particular resource is not allowed to access that resource, regardless of whether optional ACL or mandatory ACL security is being used. If there is no entry in the ACL database for a resource and the security level for the ATMI application is set to optional ACL security, all users are permitted to access the resource.
Mandatory ACL security	Clients must provide the application password, a username, and user-specific data such as a password. For a user who successfully joins an ATMI application at this security level, access to application resources is restricted in the following way. The ACL database contains a list of application resources and, for each resource, a list of users with permission to use it. A user who is not included in the list for a particular resource is not allowed to access that resource, regardless of whether optional ACL or mandatory ACL security is being used. If there is no entry in the ACL database for a resource and the security level for the ATMI application is set to mandatory ACL security, users are not permitted to access the resource.

Note: The term client is synonymous with client process, meaning a specific instance of a client program in execution. An ATMI client program can exist in active memory in any number of individual instances.

An application administrator can designate a security level by setting the SECURITY parameter in the UBBCONFIG configuration file to the appropriate value.

For This Security Level	Set SECURITY Parameter to . . .
No authentication	NONE
Application password security	APP_PW
User-level authentication	USER_AUTH
Optional ACL security	ACL
Mandatory ACL security	MANDATORY_ACL

The default is NONE. If SECURITY is set to USER_AUTH, ACL, or MANDATORY_ACL, then the application administrator must configure a system-supplied authentication server named AUTHSVR. AUTHSVR performs per-user authentication.

An application developer can replace AUTHSVR with an authentication server that has logic specific to the ATMI application. For example, a company may want to develop a custom authentication server so that it can use the popular Kerberos mechanism for authentication.

Client Naming

Upon joining an ATMI application, a client process has two names: a combined user-client name and a unique client identifier known as an application key.

Two client names are reserved for special semantics: tpsysadm and tpsysop. tpsysadm is treated as the application administrator, and tpsysop is treated as the application operator.

User-Client Names

For an authenticated security level (USER_AUTH, ACL, or MANDATORY_ACL), the username, client name, and user-specific data are transferred to AUTHSVR without interpretation by the BEA Tuxedo system. The only manipulation of this information is its encryption when transmitted over the network from a Workstation client.

Application Key

Every time a client joins an ATMI application, it is assigned a 32-bit application key by the BEA Tuxedo system. The client cannot reset the key other than by terminating its association and joining the ATMI application as a different user.

The following table shows how the application key is set for various security levels and clients. All application key assignments are hardcoded except the last item in the table.

Application Key Assignments

At This Security Level	Messages of This Type	Are Assigned the Following Application Key
Any security level	Messages from native ATMI clients that must be run by the administrator (like tmadmin(1))	0x80000000 (Application key of the administrator)
NONE or APP_PW	Messages from native ATMI clients that call tpinit()/ TPINITIALIZE() with a client name of tpsysadm and are run by the administrator	0x80000000 (Application key of the administrator)
	Messages from native ATMI clients that call tpinit()/ TPINITIALIZE() with a client name of tpsysop and are run by the administrator	0xC0000000 (Application key of the operator)
	Messages from any ATMI client other than tpsysadm or tpsysop	-1
USER_AUTH, ACL, or MANDATORY_ACL	Messages from native ATMI clients that call tpinit()/ TPINITIALIZE() with a client name of tpsysadm and are run by the administrator and bypass authentication	0x80000000 (Application key of the administrator)
	Messages from authenticated ATMI clients that call tpinit()/ TPINITIALIZE() with a client name of tpsysadm	0x80000000 (Application key of the administrator)
	Messages from authenticated ATMI clients that call tpinit()/ TPINITIALIZE() with a client name of tpsysop	0xC0000000 (Application key of the operator)
	Messages from authenticated ATMI clients that call tpinit()/ TPINITIALIZE() with a client name other than tpsysadm or tpsysop	Application key = user identifier (UID) in the lower 17 bits and group identifier (GID) in the next higher 14 bits; remaining upper bit is 0. AUTHSVR returns this application key value

A user identifier (UID) is an integer, between 0 and 128K, that is used by the application to refer to a particular user. A group identifier (GID) is an integer, between 0 and 16K, that is used by the application to refer to an application group.

User, Group, and ACL Files

To use access control, an application administrator must maintain lists of (1) users, (2) groups, and (3) and mappings of groups to application entities (such as services, events, and application queues). The third type of list, a mapping of groups to application entities, is known as the access control list (ACL).

When a client tries to access an application resource, such as a service, the system checks the client's application key and thus identifies the group to which the user belongs. Next, the system checks the ACL for the target resource and determines whether the client's group has access permission. The application administrator, application operator, and processes or service requests running with the privileges of the application administrator or operator are not subject to ACL permission checking.

The user, group, and ACL files are located in the application_root directory, where application _root is the first pathname defined for the APPDIR variable. The following figure identifies these files and specifies the administrative commands available for controlling each list.

Default User, Group, and ACL Files

The files are colon-delimited, flat text files that can be read and written only by the application administrator—the owner of the TUXCONFIG file referenced by the TUXCONFIG variable. The format of the files is irrelevant, since the files are fully administered with a set of dedicated commands. Only the application administer is allowed to use these commands.

The AUTHSVR server uses the user information stored in the tpusr file to authenticate users who want to join the ATMI application.

Optional and Mandatory ACLs

The ACL and MANDATORY_ACL security levels constitute the default authorization implementation for the ATMI environment in the BEA Tuxedo product.

When the security level is ACL, if there is no entry in the tpacl file associated with the target application entity, the client is permitted to access the entity. This security level enables an administrator to configure access for only those resources that need more security. That is, there is no need to add entries to the tpacl file for services, events, or application queues that are open to everyone.

When the security level is MANDATORY_ACL, if there is no entry in the tpacl file associated with the target application entity, the client is not permitted to access the entity. For this reason, this level is called mandatory. There must be an entry in the tpacl file for each and every application entity that the client needs to access.

For both the ACL and MANDATORY_ACL security levels, if an entry for an application entity exists in the tpacl file and the client attempts to access that entity, the user associated with that client must be a member of a group that is allowed to access that entity; otherwise, permission is denied.

For some ATMI applications, it may be necessary to use both system-level and application-level authorization. An entry in the tpacl file can be used to control which users can access a service, and application logic can control data-dependent access, for example, which users can handle transactions for more than a million dollars.

Note that there is no ACL permission checking for administrative services, events, and application queues with names that begin with a dot (.). For example, any client can subscribe to administrative events such as .SysMachineBroadcast, .SysNetworkConfig, and .SysServerCleaning. In addition, there is no ACL permission checking for the application administrator, application operator, or processes or service requests running with the privileges of the application administrator or operator.

See Also