|
|
|
|
|
|
Administering Default Authentication and Authorization
Default authentication and authorization work in the same manner that BEA Tuxedo authentication and authorization have worked since they were first made available with the BEA Tuxedo system.
Default authentication provides three levels of security: no authentication (NONE), application password (APP_PW), and user-level authentication (USER_AUTH). Default authorization provides two levels of security: optional access control list (ACL) and mandatory access control list (MANDATORY_ACL). Only when users are authenticated to join an application does the access control list become active.
Designating a Security Level
As the administrator, you can use one of three ways to designate a security level for an application: by editing the UBBCONFIG configuration file, by changing the TM_MIB, or by using the BEA Administration Console.
Establishing Security by Editing the Configuration File
In your UBBCONFIG file, set the SECURITY parameter to the appropriate value.
SECURITY {NONE | APP_PW | USER_AUTH | ACL | MANDATORY_ACL}The default is NONE. If SECURITY is set to USER_AUTH, ACL, or MANDATORY_ACL, then a system-supplied authentication server named AUTHSVR is invoked to perform per-user authentication.
If you select any value other than NONE, make sure that the value of the APPDIR variable is unique for each BEA Tuxedo application running on the MASTER site. Multiple applications cannot share the same application directory if security features are being used.
Establishing Security by Changing the TM_MIB
To designate a security level through the TM_MIB, you must assign a value to the TA_SECURITY attribute in the T_DOMAIN class. When an application is inactive, the administrator can SET the value of TA_SECURITY to any of the values that are valid in UBBCONFIG. To complete this task, run the administrative interface tpadmcall(3c).
Establishing Security by Using the BEA Administration Console
You can also designate a security level through the BEA Administration Console. The BEA Administration Console is a Web-based tool used to configure, monitor, and dynamically re-configure an application.
Configuring the Authentication Server
The BEA Tuxedo server called AUTHSVR provides a single service, AUTHSVC, which performs authentication. AUTHSVC is advertised by the AUTHSVR server as ..AUTHSVC when the security level is set to ACL or MANDATORY_ACL.
To add AUTHSVC to an application, you need to define AUTHSVC as the authentication service and AUTHSVR as the authentication server in the UBBCONFIG file. For example:
*RESOURCES
SECURITY USER_AUTH
AUTHSVC AUTHSVC
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
If you omit the parameter-value entry AUTHSVC AUTHSVC, the system calls AUTHSVC by default.
As another example:
*RESOURCES
SECURITY ACL
AUTHSVC ..AUTHSVC
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
If you omit the parameter-value entry AUTHSVC ..AUTHSVC, the system calls ..AUTHSVC by default.
AUTHSVR may be replaced with an authentication server that implements logic specific to the application. For example, a company may want to develop a custom authentication server so that it can use the popular Kerberos mechanism for authentication.
To add a custom authentication service to an application, you need to define your authentication service and server in the UBBCONFIG file. For example:
*RESOURCES
SECURITY USER_AUTH
AUTHSVC KERBEROS
.
.
.
*SERVERS
KERBEROSSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
See Also
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|