HOME | SITE MAP | SEARCH | CONTACT | GLOSSARY | PDF FILES | WHAT'S NEW
Administration | TABLE OF CONTENTS | PREVIOUS TOPIC | NEXT TOPIC | INDEX
|
|
|
BEA WebLogic Enterprise 4.2 Developer Center |
|
HOME | SITE MAP | SEARCH | CONTACT | GLOSSARY | PDF FILES | WHAT'S NEW |
||
|
Administration | TABLE OF CONTENTS | PREVIOUS TOPIC | NEXT TOPIC | INDEX |
||
This chapter discusses the levels of security that are available to WLE and 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:
This section covers the levels of security provided by the WLE system or the BEA TUXEDO system. Application designers need to decide the appropriate level for their applications.
Security Strategy
NONE" (configuration is discussed below). This implies that there are no additional mechanisms (for example, WLE or BEA TUXEDO system password) beyond what the platform provides.
Most WLE and 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 WLE or 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 WLE or 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.
The WLE or 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.
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, WLE or 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.
Note: For BEA TUXEDO systems, 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_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.
Note: This feature is not supported on WLE systems.
USER_AUTH.
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_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.
Note:
The WLE CORBA API does not support access control lists (ACLs). The WLE system ignores the SECURITY MANDATORY_ACL parameter in an application's UBBCONFIG configuration file on machines using the WLE CORBA API. You can use the SECURITY MANDATORY_ACL parameter on machines with WLE installed if the applications use only the ATMI API. Also, specifying the SECURITY ACL parameter does not cause access control checks to be performed on WLE servers that were built using the CORBA API.
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.
UBBCONFIG file in a text editor.
SECURITY parameter as follows.
SECURITY=METHOD where the value of METHOD is one of the following:
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 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.
Application password-level security requires all users to enter the same password to be allowed access to the application.
It is implemented as follows:
passwd field of the TPINIT buffer before tpinit(3c) is called to join the application.
At runtime, all clients need to provide this password to access the application.
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 WLE or BEA TUXEDO system, Implementing Security via an Authentication Server
AUTHSVR, provides two levels of security checks:
tpinit(3c) function is called to join the application, the user's ID, client name, and user name are verified with a password.
The WLE or 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.
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"
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:
usrname-a character string that represents the name of a user.
client_name or cltname-a character string that represents the name of a client.
group_name or grpname-a character string that represents the name of a group.
Two files are used for user and group administration:
$APPDIR/tpusr
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 The commands Following is the syntax of the commands.
Section (1) of the BEA TUXEDO Reference Manual also includes the commands The commands Following is the syntax of the commands.
Note:
The WLE CORBA API does not support access control lists (ACLs). The WLE system ignores the
Access control lists (ACLs) enhance the security features of BEA TUXEDO systems. 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:
$APPDIR. The format of the files is irrelevant, since they are fully administered with shell-level 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.
tpusradd [-u UID] [-g GID] [-c client_name] usrnametpusrdel [-c client_name] usrnametpusrmod [-u UID] [-g GID] [-c client_name] [-l new_login] [-n\ new_client_name] [-p] usrnametpaddusr(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
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 WLE or BEA TUXEDO system application that will be modified. In addition, only the application owner, as specified in $TUXCONFIG, is allowed to use these commands.
tpgrpadd [-g GID] grpnametpgrpdel grpnametpgrpmod [-g GID] [-n new_grpname] grpnameImplementing Security via Access Control Lists (BEA TUXEDO System)
SECURITY MANDATORY_ACL parameter in an application's UBBCONFIG configuration file on machines using the WLE CORBA API.
SECURITY MANDATORY_ACL parameter on machines with WLE installed if the applications only use the ATMI API. Also, specifying the SECURITY ACL parameter does not cause access control checks to be performed on WLE servers that were built using the CORBA API.
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.
Access control lists have the following limitations:
Limitations of ACLs
$APPDIR/tpusr.
ACLs are stored in the file Administering ACLs
$APPDIR/tpacl, an ASCII file that is readable and writable only by the application administrator. The file is administered with the following commands:
tpacladd
tpacladd [-g GID | group_name] [,GID | group_name...] entity_nameentity_name is the name of the service, event, or /Q queue for which to create an ACL.
tpacldel
tpacldel entity_nameentity_name is the name of the ACL entry that is to be deleted.
tpaclmod
The tpaclmod [-g GID | group_name][,GID | group_name...] entity_name-g option allows the specification of a group or list of groups that can access the feature provided by entity_name.
