[Top] [Previous Page] [Next Page] [Bottom]


Chapter 11. Securing Applications

This chapter discusses the levels of security that are available to BEA TUXEDO system applications, and describes how to implement the level of security your designers decide best serves the requirements of your application.

The following topics are presented:

Security Strategy

This section covers the levels of security provided by the BEA TUXEDO system. Application designers need to decide the appropriate level for their applications.

Operating System
For platforms that have underlying security mechanisms, this is the first line of defense. The security level is configured to "NONE" (configuration is discussed below). This implies that there are no additional mechanisms (for example, a BEA TUXEDO system password) beyond what the platform provides.

Most BEA TUXEDO applications are managed by a system administrator who configures the application, starts up the application (servers run with the permissions of this administrator), and monitors the running application, making dynamic changes as necessary. This arrangement implies that server programs are "trusted," since they run with the administrator's permissions. This working method is supported by the login mechanism and read/write permissions on files, directories, and system resources provided by the underlying operating system.

Client programs are run directly by users with their own permissions. Normally, however, users have access to the administrative configuration file and interprocess communication mechanisms, such as the Bulletin Board (in shared memory), as part of normal processing. This is true regardless of whether additional BEA TUXEDO system security is configured.

For some applications running on platforms that support greater security, a more secure approach is to limit access to the files and IPC mechanisms to the application administrator and to have "trusted" client programs run with the permissions of the administrator (using a setuid mechanism). Combining these practices with BEA TUXEDO system security allows the application to "know" who is making the request.

For the most secure environment, only workstation clients should be allowed to access the application; client programs should not be allowed to run on the same machines on which application server and administrative programs run.

BEA TUXEDO system security mechanisms can be used in addition to operating system security to prevent unauthorized access. The additional security can be used to avoid simple violations, such as someone accessing an unattended terminal. In addition, it can protect the boundaries of the administrative domain from interdomain or workstation client access over the network by unauthorized users.

Application Password
This security level requires that every client provide an application password as one step in the process of joining the application. The security level is configured to APP_PW. The administrator must provide an application password when this level is configured. (The password can be changed by the administrator.) It is the responsibility of the administrator to inform authorized users of the application about the password.

If this level of security is used, BEA TUXEDO system-supplied client programs, ud(1) for example, prompt for the application password. Application-written client programs must include code to obtain the password from a user. The password should not be echoed to the user's screen. The password is placed in clear text in the TPINIT buffer and is evaluated when the client calls tpinit() to join the application.

See "Writing Client Programs" in the BEA TUXEDO Programmer's Guide for examples of code for handling a password.

User Authentication
The third level of BEA TUXEDO system security is based on authenticating each individual user in addition to providing the application password. The security level is configured to USER_AUTH.

This level involves passing user-specific data to an authentication service. Often, the data is a per-user password. This data is automatically encrypted when it is sent over the network from workstation clients. The default authentication service, AUTHSVC, is provided by a BEA TUXEDO system-supplied server, AUTHSVR. The operation of an authentication service is described in "Writing Service Routines" in the BEA TUXEDO Programmer's Guide. This server can be replaced with an application authentication server that has logic specific to the application. (For example, it might access the widely used Kerberos mechanism for authentication.)

With this level of security, authentication is provided, but access control is not provided. That is, the user is checked when joining the application, but then is free to execute any services, to post events, and to access application queues. It is possible for servers to do application-specific authorization within the logic of the service routines, but there are no hooks for authorization that check for access to events or application queues. The alternative is to use the built-in access control checking.

Access Control
With the use of access control lists (ACLs), not only is a user authenticated when joining the application, but in addition, permissions are checked automatically when attempts are made to access application entities (such as services). ACL security also includes the user-authentication security equivalent to USER_AUTH.
Optional Access Control Lists
There are two levels of ACL checking. The first ACL security level is simply called ACL. If ACL is configured, the access control lists are checked whenever a user attempts to access a service name, queue name, or event name within the application. If there is no ACL associated with the user's name, the assumption is that permission is granted. For this reason, this level is considered "optional." It allows the administrator to configure access for only those resources that need more security; ACLs need not be configured for services, queues, or events that are open to everyone.

For some applications, it may be necessary to use both system-level and application authorization. An ACL can be used to control who can request a service, and application logic can control data-dependent access (for example, who can handle transactions for more than one million dollars).

Note that ACL checking is not done for administrative services, queues, and events with names that begin with a dot (.). For example, anyone can subscribe to administrative events such as, .SysMachineBroadcast, .SysNetworkConfig, .SysServerCleaning.

Mandatory Access Control Lists
The second ACL security level is MANDATORY_ACL. This level is similar to ACL, but an access control list must be configured for every entity (such as a service, queue, or event) that users can access. If MANDATORY_ACL is specified and there is no ACL for a particular entity, permission for that entity is denied.
Link-Level Encryption
Users of the BEA TUXEDO Security Add-On Package (US/Canada or International) can establish data privacy for messages moving over the network links that connect the machines in a BEA TUXEDO application. For a detailed description of this feature, see Chapter 6, "Building Networked Applications."

Configuring the RESOURCES SECURITY Parameter

You can designate a security scheme by setting the value of one parameter in the RESOURCES section of the configuration file: SECURITY. (The parameter AUTHSVC also comes into play if SECURITY is set to USER_AUTH, ACL or MANDATORY_ACL.)

To set the SECURITY parameter, perform the following steps.

  1. Open the UBBCONFIG file in a text editor.
  2. Set the SECURITY parameter as follows.

    SECURITY=METHOD where the value of METHOD is one of the following:

    The default is NONE.

The value APP_PW indicates that application password security will be enforced (that is, clients will be required to provide the application password during initialization). Setting APP_PW causes tmloadcf to prompt for an application password.

The value USER_AUTH is similar to APP_PW but, in addition, indicates that per-user authentication will be done during client initialization.

The value ACL is similar to USER_AUTH but, in addition, indicates that access control checks will be done on service names, queue names, and event names. If an associated ACL is not found for a name, it is assumed that permission is granted.

The value MANDATORY_ACL is similar to ACL, but permission is denied if an associated ACL is not found for the name.

Implementing Operating System Security

Implementing operating system security is one of the easier tasks you will have as an administrator. It consists entirely of not implementing any higher level of security.

In the RESOURCES section, set SECURITY to NONE. If you leave SECURITY blank, NONE is the default.

Operating system security depends on the underlying password and the read/write permission structure of the operating system. You need to make sure that your users are able to connect to the application and have access to application files and programs. Consult the administrator's guide for your operating system to learn how to do this.

Implementing Application Password-level Security

Application password-level security requires all users to enter the same password to be allowed access to the application.

It is implemented as follows:

At runtime, all clients need to provide this password to access the application.

Implementing Security via an Authentication Server

User authentication-level security requires a server that can authenticate users by checking individual passwords against a file of legal users.

The authentication server shipped with the BEA TUXEDO system, AUTHSVR, provides two levels of security checks:

The Authentication Server

BEA TUXEDO system user authentication is provided by AUTHSVR(5).

AUTHSVR provides per-user authentication. When a client process calls tpinit(3c) to join the application, AUTHSVR validates the user name, client name, and password. If tpinit fails for security reasons, a security violation is logged both in the userlog, and as a system event. On success, AUTHSVR provides the client with an application key that cannot be forged. The client presents the application key in the appkey field of the TPSVCINFO structure on each service invocation.( See "Writing Client Programs" in the BEA TUXEDO Programmer's Guide.)

Currently, authentication is not provided by a standard authentication mechanism, such as Kerberos, DCE, or public key encryption. When enhancements are provided to use such mechanisms, authentication is based on the user name. The client name is used for application logic only (for example, filtering of broadcast messages). If you are planning to use an alternate authentication scheme, we recommend that you do not associate client names with users. In this case, administrators should use only wildcard values for the client name in the user file; they should not use wildcard values for the user name.

Configuring the Authentication Server

To add AUTHSVR to an application, you must define AUTHSVR as a server in the TUXCONFIG file. To do so, add the following lines to the UBBCONFIG file. 

RESOURCES
SECURITY   "USER_AUTH"
AUTHSVC    "AUTHSVC"
 
SERVERS
AUTHSVR SRVGRP="groupname" SRVID=1 RESTART=Y GRACE=0 MAXGEN=2 CLOPT="-A"

Adding, Modifying, and Deleting User Accounts

The shell-level commands tpusradd(1) and tpgrpadd(1) allow you to create files containing lists of authorized users and groups. The tpusrdel(1), tpusrmod(1), tpgrpdel(1), and tpgrpmod(1) commands enable you to maintain your user and group files. The following parameters are used in one or more of these six commands:

Two files are used for user and group administration:

The files are colon-delimited, flat ASCII files, readable only by the application's administrator.

The files are kept in the application directory, specified by the environment variable $APPDIR. The format of the files is irrelevant, since they are fully administered with shell-level commands.

The commands tpusradd(1), tpusrdel(1), and tpusrmod(1) are available for modifying the files tpusr and tpgrp. For all of these commands, the environment variable $APPDIR must be set to the path name of the BEA TUXEDO system application that will be modified. In addition, only the application owner, as specified in $TUXCONFIG, is allowed to use these commands.

Following is the syntax of the commands. 

tpusradd [-u UID] [-g GID] [-c client_name] usrname
 
tpusrdel [-c client_name] usrname
 
tpusrmod [-u UID] [-g GID] [-c client_name] [-l new_login] [-n\ new_client_name] [-p] usrname

Section (1) of the BEA TUXEDO Reference Manual also includes the commands tpaddusr(1), tpdelusr(1), and tpmodusr(1), which are functionally similar to the three commands described here. tpaddusr(1), tpdelusr(1), and tpmodusr(1) are provided for compatibility with releases prior to Release 6.0; if you are running Release 6.0 or later, we recommend you use the commands described in this section.

Adding, Modifying, and Deleting Groups

The commands tpgrpadd(1), tpgrpdel(1), and tpgrpmod(1) enable you to modify the files tpusr and tpgrp. For all of these commands, the environment variable $APPDIR must be set to the path name of the BEA TUXEDO system application that will be modified. In addition, only the application owner, as specified in $TUXCONFIG, is allowed to use these commands.

Following is the syntax of the commands. 

tpgrpadd [-g GID] grpname
tpgrpdel grpname
tpgrpmod [-g GID] [-n new_grpname] grpname

Implementing Security via Access Control Lists

Access control lists (ACLs) enhance the security features of the BEA TUXEDO system. ACLs provide group-based access control to application entities (services, events, and /Q queues). By looking at the client's application key, these entities can identify the group to which the user belongs; by looking at the ACL, the entity can determine whether the client's group has access permission.

Access control is done at the group level for the following reasons:

If user-level ACLs are needed, they may be implemented by creating a group for each user, and then setting up the group to have the desired permissions for its single member.

Limitations of ACLs

Access control lists have the following limitations:

Administering ACLs

ACLs are stored in the file $APPDIR/tpacl, an ASCII file that is readable and writable only by the application administrator. The file is administered with the following commands:


[Top] [Previous Page] [Next Page] [Bottom]