This chapter covers the configuration and use of security in
BEA TUXEDO applications.
BEA TUXEDO System/T provides several levels of security.
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, not that there is no security, but that there are no additional mechanisms (for example, BEA TUXEDO System password) beyond what the platform provides.
The BEA TUXEDO System has the notion of an application 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. Note that this implies that server programs are "trusted" since they run with the administrator's permissions. This is supported using the underlying operating system login mechanism and read/write permissions on files, directories, and system resources.
Client programs are run directly by the users with their own permissions. However, they normally have access to the administrative configuration file and the interprocess communication mechanisms, such as the Bulletin Board in shared memory, as part of normal processing. This is true whether or not additional BEA TUXEDO System security is configured. For some applications running on platforms supporting such, a more secure approach is to have the files and IPC mechanisms accessible only to the application administrator and to have "trusted" client programs run with the permissions of the administrator (using a "setuid" mechanism). Combining this with BEA TUXEDO security will allow the application to "know" who the user is that 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 machines where application server and administrative programs run.
BEA TUXEDO 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 like someone accessing an unattended terminal. Or it can protect the boundaries of the administrative domain from inter-domain or workstation client access over the network by unauthorized users.
This security level requires that every client provide an application password as part of joining the application. The security level is configured to "APP_PW". The administrator must provide an application password when this level is configured and this password can also be changed administratively. It is the responsibility of the administrator to inform users of the application what the password is.
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 terminal. The password is placed in clear text in the TPINIT buffer and evaluated when the client calls tpinit() to join the application.
See
"Writing Client Programs" in theBEA TUXEDO Programmer's Guide for examples of code for handling a password.
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 set 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 passed over the network from workstation clients. The default authentication service, "AUTHSVC", is provided by a BEA TUXEDO System-supplied server, AUTHSVR. The operation of AUTHSVR is described in
"Writing Service Routines" in theBEA TUXEDO Programmer's Guide. This server can be replaced with an application authentication server with logic specific to the application. (For example, it might access the widely-used Kerberos mechanism for authentication.) With this level of security, authentication but not authorization is provided. That is, the user is checked when joining the application but then is free to execute any services, post events, and access application queues. It is possible for the servers to do application-specific authorization within the logic of the service routines, but there are no hooks for authorization checking for access to events or application queues. The alternative is to use the built-in access control checking.
With the use of access control lists (ACLs), the user is not only authenticated when joining the application, but permissions are automatically checked when accessing application entities such as services. ACL security also includes the user-authentication security equivalent to "USER_AUTH".
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 name, the assumption is that permission is granted. This is why this level is considered "optional" ACLs. It allows the administrator to configure access for those resources that need more security, but ACLs need not be configured for services, queues, or events that are accessible to everyone.
Some applications may find it necessary to use both system level and application authorization. An ACL can be used to control who can get to a service, and application logic can control data-dependent access (for example, who can handle transactions for more than a million dollars).
Note that administrative services, queues, and events beginning with a period (.) do no ACL checking. For example, anyone can subscribe to administrative events.
The second ACL security level is "MANDATORY_ACL". This level is similar to "ACL", but an access control list must be configured for every object for which users are to have access. If "MANDATORY_ACL" is specified and there is no ACL for the name, permission is denied.
Users of the BEA TUXEDO Security Add-On Package (Domestic or International) can establish data privacy for messages moving over the network links that connect machines of BEA TUXEDO applications (or domains). A somewhat more detailed description of this feature can be found in the final section of this chapter.
Configuration of the SECURITY level must be done when an
application is inactive and must be done on the MASTER
site so that the system can propagate the information to other
sites as they are booted. There are three ways to set the
security level (and optionally the AUTHSVC for the application
authentication server when the security level is
"USER_AUTH", "ACL", or
"MANDATORY_ACL"). Note that in addition to setting
SECURITY, the APPDIR must be unique for each application if
security is set to any value but NONE (that is, applications
cannot share APPDIR if security features are being used).
Edit the *RESOURCES section of the ASCII configuration file for the application.
SECURITY {"NONE" | "APP_PW" | "USER_AUTH" | "ACL" | "MANDATORY_ACL" }
After the configuration file is edited, tmloadcf
must be executed. The program will prompt for an application
password if SECURITY is set to a level other than
"NONE". The application password can be changed using
the
The T_DOMAIN class of TM_MIB(5) has an attribute called TA_SECURITY.
When an application is inactive, the administrator can SET
the value of TA_SECURITY to any of the values that are
valid in ubbconfig (assuming the T_DOMAIN object has
already been defined). This can be done using the administrative
interface tpadmcall(3c).
The GUI can be used to change the security level by choosing
one of the options corresponding to the security levels listed
above. See the BEA
TUXEDO Administrator's Guide to the Web-based GUI for
more information.
There are two things that need to be done for clients that are
running in an application with SECURITY set. These are getting
the security data needed for the specific user, and passing this
information to the BEA TUXEDO System when joining the
application.
The function tpchkauth(3c) is provided so a check on the level of security can be done before calling tpinit(). This is necessary so that the program can prompt for an application password and possibly user authentication data needed for the tpinit() call. tpchkauth() is called without arguments and returns one of the following values.
In an application configured with SECURITY, it is necessary to pass the security information to the BEA TUXEDO System via a TPINIT buffer. The TPINIT buffer is a special typed buffer used by a client program to pass client identification and authentication information to the system as the client attempts to join the application. It is defined in the atmi.h header file and contains the following fields:
char usrname[MAXTIDENT+2]; char cltname[MAXTIDENT+2]; char passwd[MAXTIDENT+2]; char grpname[MAXTIDENT+2]; long flags; long datalen; long data;
usrname, cltname, and grpname are all NULL-terminated strings of up to MAXTIDENT characters. MAXTIDENT is defined as 30. usrname is a name representing the caller; you might elect to use the operating system user name. cltname is a client name whose semantics are application defined. You might use this field to indicate the role of the user when executing the client program. It is also used for selection of specific clients when sending broadcast messages. grpname allows a client to be associated with a resource manager group that is defined in the configuration; its use is not related to security.
The usrname and cltname fields are
associated with the client process when tpinit() is
called and are used for authentication, broadcast notification,
and the retrieval of administrative statistics.
passwd is a NULL-terminated string of up to 8
characters. It is an application password in unencrypted format
that is used by tpinit() for validation against the
configured application password.
User-specific data is passed by using the datalen and data fields when security is set to "USER_AUTH", "ACL", or "MANDATORY_ACL". datalen is the length of the user-specific data that follows. The buffer type switch entry for the TPINIT typed buffer sets datalen based on the total size passed in for the typed buffer (the application data size is the total size less the size of the TPINIT structure itself plus the size of the data placeholder as defined in the structure). There is a macro, TPINITNEED, provided in atmi.h that calculates the size needed when you call it with the number of bytes of application data you expect to pass.
data is a placeholder for variable length data that
is forwarded to an authentication service. data is
always the last element of the structure. See
An application key is associated with each client program when it joins the application. You can think of this 32-bit value as the security credential for the client - it identifies the client for security purposes. This value cannot be reset by the client (other than by terminating its association and joining the application as a different user), and cannot be forged. The value is provided to every service invocation as part of the TPSVCINFO structure in the appkey field (see tpservice(3c)).
The following list indicates how the application key will be set for various security levels and clients.
No additional administration is needed for the "NONE" and "APP_PW" security levels. For "USER_AUTH" security,however, a password file must be created and maintained. The file can be created and maintained using the tpaddusr(1), tpdelusr(1), and tpmodusr(1) commands. Each of these commands takes the name of a file in which the user information is stored and updated. Similarly, AUTHSVR takes the name of a file from which to read the user information for authentication. The file is created automatically by the software, so its format is not documented. There is no MIB for this file: it is not available via the administrative interface or the GUI.
The semantics of the "USER_AUTH" security level allows for some flexibility not allowed for "ACL" or "MANDATORY_ACL". While these semantics may be useful for your application, you should understand that making use of them will make it difficult to migrate to the use of ACLs later on if you choose to do so. "USER_AUTH" allows the following.
If your application doesn't need duplicate or wild-card user
names, it is recommended that the commands tpusradd(1), tpusrdel(1), and
tpusrmod(1)
or the MIB (via the Admin API or the GUI) be used to create and
maintain the user file. These are described below in relation to
access control list administration. For ease of migration, it is
also recommended that only the low-order 17 bits of the
application key be used for application authorization checking
(with the exception of checking for the administrator and
operator keys).
Beyond per-user authentication, the ACL security level allows an administrator to associate users with groups and relate the groups to objects they are permitted to access. By logging in and joining an application, a client is given an application key. The application key contains information that identifies the client as a valid user and valid group member. The BEA TUXEDO system administrator and processes or service requests running with the privileges of the system administrator are not subject to ACL permission checking.
The ACL feature also allows the administrator to associate service names, event names, and /Q application queue names with the specific groups. An example of how this capability might be used is a banking application where an employee user is identified as being in the group Teller. A customer of the bank who uses the bank's ATM system might be identified as being in the group Customer. Now, clearly, in any reasonable banking application tellers and customers would need to be able to use many of the same services; deposit, withdraw, check_balance, and transfer, for example, but customers would only be authorized to make such transactions in accounts of their own; tellers need to be able to act on behalf of any customer and also need to do other tasks such as look at a customer's record to ascertain whether it is okay to cash a check for the purported customer and to do some cash-drawer balancing procedures after the bank has closed for the day. This sort of problem can be handled by having an ACL group for customers and another ACL group for tellers; depending on how the services are coded, some services might be available to both groups.
In all of the procedures, there are alternatives for accomplishing the same result. Feel free to improvise.
Note that administrative services, queues, and events
beginning with ``.'' do no ACL checking. For example, anyone can
subscribe to administrative events.
The tpaclcvt(1) utility can be used to convert security data files to the format needed by the Access Control List feature. Here are the prerequisites.
Once those conditions are met the command is
tpaclcvt [-u userfile} [-g groupfile]
Both the -u and the -g options are shown in the syntax as optional (surrounded by square brackets), but if the command is run with neither option specified, the net result is that nothing is done. In other words, there are no default file names for either the user file or the group file. This command is commonly used to convert either the user file currently being used for "USER_AUTH" security or /etc/password (note that for systems with a shadow password file, a password must be entered for each user). By using tpaclcvt instead of simply copying the file to the fixed file name, the file can be validated looking for inconsistencies or violations of the restrictions mentioned earlier.
tpaclcvt can also be used to convert the /etc/group
file to the format used by the ACL feature.
This procedure has the following prerequisites:
There are several approaches to add a user.
The tpusradd(1) command is a command used to add the name of a user or domain to the application's user file. The command syntax is as follows:
tpusradd [-u uid] [-g gid] [-c client_name] usrname
usrname is the only required argument. It is a string that specifies the user name of the user. The user name must be unique within the list.
uid is a decimal number representing the user identifier associated with usrname. uid must be unique within the list of identifiers for the application. If not specified on the command line, the value defaults to the next available number in the list.
The gid must be either a decimal number or character string representing the group identifier of an existing group. If no value is specified on the command line, group membership defaults to "other," which may limit the number of objects available to this user.
The client_name argument is a character string that associates a client name with the user. A common use of this argument is to identify the role of the user; for example, "teller" might be a client name used in a banking application. If not specified, the default is the wildcard character (*), which matches any client name. Per user authentication in AUTHSVC is based on a user-name/client-name match and is thus made easier through a wildcard value.
The administrator is prompted for an initial password for the user.
Two other commands, tpusrdel(1) and tpusrmod(1),
allow the administrator to delete and change user entries. tpusrmod
can also be used to change a user's password.
The administrator can accomplish the same operations through
the /AdminAPI feature by changing the values of the attributes of
Class T_ACLPRINCIPAL in the ACL_MIB(5). This would probably be the
preferred way of adding several users at a time, since tpusradd(1) adds
only one at a time. Of course, the easiest way to access the MIB
is via the graphical user interface.
This procedure has the following prerequisites:
There are several approaches to add a group.
The tpgrpadd(1) command is a command used to add the name (and optionally the identifier) of a group to the application's group file. The command syntax is as follows:
tpgrpadd [-g gid] grpname
grpname is the only required argument. It is a string that specifies the name of the group.
gid is a decimal number representing the group identifier associated with grpname. If not specified on the command line, the value defaults to the next available number in the list. Identifier 0 is reserved as the identifier for group "other."
Two other commands, tpgrpdel(1) and tpgrpmod(1),
allow the administrator to delete and change group file entries.
The administrator can accomplish the same operations through
the /AdminAPI feature by changing the values of the attributes of
Class T_ACLGROUP in the ACL_MIB(5). This would probably be the
preferred way of adding several groups at a time, since tpgrpadd(1) adds
only one at a time. Of course, the easiest way to access the MIB
is via the graphical user interface.
This procedure has the following prerequisites:
There are several approaches to add an ACL.
The tpacladd(1) command is a command used to grant access permission to one or more groups of users for a service, queue, or posting an event. The command syntax is as follows:
tpacladd [-g gid[,gid. . .]] [-t type] name
gid, . . . is a list of one or more numeric identifiers or character-string names (they can be mixed) of groups configured for the application. If no gid argument is provided, the entry is added with no associated groups.
type specifies the object type. It can be one of the following four literals.
If type is not specified, the default is SERVICE.
name is a unique character string that specifies the name of the object.
tpacladd is the command through which the administrator can map groups to object names. This is the heart of the Access Control List feature.
There are two related commands, tpacldel(1) and tpaclmod(1), that are used to delete or modify an Access Control List entry. One caution should be mentioned in connection with tpaclmod. If tpaclmod is executed with no gid argument, it has the effect of unmapping all the groups authorized to access the named object.
Note that administrative services, queues, and events
beginning with a period (.) do no ACL checking.
The administrator can accomplish the same operations through
the /AdminAPI feature by changing the values of the attributes of
Class T_ACLPERM in the ACL_MIB(5). Of course, the easiest way to
access the MIB is via the graphical user interface.
The basic idea behind Access Control List security is that the administrator must maintain files that:
There are generally three means of accomplishing ACL administration:
As noted earlier, for data security Link-Level Encryption (LLE) is available in two add-on packages, the BEA TUXEDO Security Add-on Package, Domestic or International version. The difference between the two versions consists solely in the number of bits of the 128-bit encryption key that can be used; the U.S. version can use up to 128 bits, the International version can use no more than 40.
The packages allow encryption of data flowing over BEA TUXEDO network links. The objective is to ensure data privacy, so a network-based eavesdropper cannot learn the content of BEA TUXEDO messages or application-generated messages.
The feature applies to the following types of BEA TUXEDO links:
Link-level encryption control parameters and underlying communication protocols are different for various link types, but there are some common themes:
LLE is point-to-point, which means that your data may be
encrypted/decrypted many times as it flows over network links.
The first step in negotiating the key size is for the two processes to agree on the largest common key size supported by both. This negotiation itself need not be encrypted or hidden.
Once encryption is negotiated, it remains in effect for the lifetime of the network connection.
A pre-processing step temporarily reduces the maximum key size parameter configured to agree with the installed software's capabilities. This must be done at link negotiation time, because at configuration time it may not be possible to verify a particular machine's installed encryption package. For example, the administrator may configure (0, 128) encryption for an unbooted machine that only has a 40-bit encryption add-on package installed. When the machine actually negotiates a key size, it should represent itself as (0, 40). In some cases this may cause a run-time error; for example (128, 128) is not possible with a 40-bit encryption package.
The following table shows the outcome for all possible combinations of min/max parameters.
| Inter-Process Negotiation Results | (0,0) | (0,40) | (0,128) | (40,40) | (40,128) | (128,128) |
| (0,0) | 0 | 0 | 0 | ERROR | ERROR | ERROR |
| (0,40) | 0 | 40 | 40 | 40 | 40 | ERROR |
| (0,128) | 0 | 40 | 128 | 40 | 128 | 128 |
| (40,40) | ERROR | 40 | 40 | 40 | 40 | ERROR |
| (40,128) | ERROR | 40 | 128 | 40 | 128 | 128 |
| (128,128) | ERROR | ERROR | 128 | ERROR | 128 | 128 |
There is a limit on the length of time a /Workstation client
can take for initialization. By default this interval is 30
seconds in a non-security application and 60 seconds in a
security application. The 60 seconds includes the time needed to
negotiate an encrypted link. This time limit can be changed when
LLE is configured by changing the value of the TA_MAXINITTIME
in class T_WSL. See WS_MIB(5).
The BEA TUXEDO Security Add-On Package, as noted before, is sold as two separate products. The International package is enabled for 40-bit encryption; the U.S. package is enabled for both 40-bit and 128-bit encryption.
Each package is shipped on a CD-ROM containing the appropriate library for each supported BEA TUXEDO platform.
Also on the CD-ROM is an installation program that installs the product in a platform-specific manner. Compatability between the add-on package and the underlying BEA TUXEDO System software is imperative; the installation program checks this.