|
|
|
|
|
|
Configuring Authentication
This topic includes the following sections:
Configuring the Authentication Server
Note: You only need to configure the authentication server, if you have specified a value of USER_AUTH or higher for the SECURITY parameter and are using the default authentication plug-in..
Authentication requires that an authentication server be configured for the purpose of authenticating users by checking their individual passwords against a file of legal users. The WebLogic Enterprise system uses a default authentication server called AUTHSRV to perform authentication. 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.
For a WebLogic Enterprise application to authenticate users, the value of the AUTHSVC parameter in the RESOURCES section of the UBBCONFIG file needs to specify the name of the process to be used as the authentication server for the WebLogic Enterprise application. The service must be called AUTHSVC. If the AUTHSVC parameter is specified in the RESOURCES section of the UBBCONFIG file, the SECURITY parameter must also be specified with a value of at least USER_AUTH. If the value is not specified, an error will occur when the system executes the tmloadcf command. If the -m option is configured on the ISL process in the UBBCONFIG file, the AUTHSVC must be defined in the UBBCONFIG file before the ISL process.
In addition, you need to define AUTHSVR in the SERVERS section of the UBBCONFIG file. The SERVERS section contains information about the server processes to be booted in the WebLogic Enterprise application. 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. Listing 7-1 contains the portion of the UBBCONFIG file that defines the authentication server.
Listing 7-1 Parameters for the Authentication Server
*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, the WebLogic Enterprise 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"
Defining Authorized Users
As part of configuring security for a WebLogic Enterprise application, you need to define the principals and groups of principals who have access to the WebLogic Enterprise application.
Authorized users can be defined in the following ways:
You use the tpusradd command to create files containing lists of authorized principals. The tpusradd command adds a new principal entry to the WebLogic Enterprise security data files. This information is used by the authentication server to authenticate principals. The file that contains the principals is called tpusr.
The file is a colon-delimited, flat ASCII file, readable only by the system administrator of the WebLogic Enterprise application. The system file entries have a limit of 512 characters per line. The file is kept in the application directory, specified by the environment variable $APPDIR. The environment variable $APPDIR must be set to the pathname of the WebLogic Enterprise application.
The tpusradd file should be owned by the administrator account. BEA recommends that the file be protected so that only the owner has read and write privileges for the file and all other users have only read privileges for the file.
The tpusradd command has the following options:
-u uid
The user identification number. The UID must be a positive decimal integer below 128K. The UID must be unique within the list of existing identifiers for the application. The UID defaults to the next available (unique) identifier greater than 0.
-c client_name
A string of printable characters that specifies the name of the principal. The name may not contain a colon (:). pound sign (#), or a newline (n). The principal name must be unique within the list of existing principals for the WebLogic Enterprise application. The name of the principal can be either the name of a WebLogic Enterprise client application or a WebLogic Enterprise EJB.
Listing 7-2 includes a sample tpusradd file.
Listing 7-2 Sample tpusradd File
Cltname Uid
milozzi 122
smart 555
patt 1234
butler 15555
Note: Use the tpgrpadd command to add groups of principals to the WebLogic Enterprise security data files.
In addition to the tpusradd and tpgrpadd commands, the WebLogic Enterprise product provides the following commands to modify the tpusr and tpgrp files:
For a complete description of the commands, see the Commands, System Processes, and MIB Reference in the WebLogic Enterprise online documentation.
You may already have files containing lists of users and groups on your host system. You can use them as the user and group files for your WebLogic Enterprise application, but only after converting them to the format required by the WebLogic Enterprise system. To convert your files, run the tpaclcvt command, as shown in the following sample procedure. The sample procedure is written for a UNIX host machine.
tpaclcvt -u /etc/password
This command creates the tpusr file and stores the converted data in it. If the tpusr file already exists, tpaclcvt adds the converted data to the file, but it does not add duplicate user information to the file.
Note: For systems on which a shadow password file is used, you are prompted to enter a password for each user in the file.
tpaclcvt -g /etc/group
This command creates the tpgrp file and stores the converted data in it. If the tpgrp file already exists, tpaclcvt adds the converted data to the file, but it does not add duplicate group information to the file.
Defining a Security Level
As part of defining security for a WebLogic Enterprise application, you need to define the SECURITY parameter in the RESOURCES section of the UBBCONFIG file. The SECURITY parameter has the following format:
*RESOURCES
SECURITY {NONE|APP_PW|USER_AUTH|ACL|MANDATORY_ACL}
Table 7-1 describes the values for the SECURITY parameter.
|
Value |
Description |
|---|---|
|
NONE |
Indicates that no password or access checking is performed in the WebLogic Enterprise application. Tobj::PrincipalAuthenticator::get_auth_type() returns a value of TOBJ_NOAUTH. |
|
APP_PW |
Indicates that client applications are required to supply an application password to access the WebLogic Enterprise domain. The tmloadcf command prompts for an application password. Tobj::PrincipalAuthenticator::get_auth_type()returns a value of TOBJ_SYSAUTH. |
|
USER_AUTH |
Indicates that client applications and the IIOP Listener/Handler are required to authenticate themselves to the WebLogic Enterprise domain using a password. The value USER_AUTH is similar to APP_PW but, in addition, indicates that user authentication will be done during client initialization. The tmloadcf command prompts for an application password. Tobj::PrincipalAuthenticator::get_auth_type() returns a value of TOBJ_APPAUTH. No access control checking is performed at this security level. |
|
ACL |
Indicates that authentication is used in the WebLogic Enterprise application and access control checks are performed on interfaces, services, queue names, and event names. If an associated ACL is not found for a name, it is assumed that permission is granted. The tmloadcf command prompts for an application password. Tobj::PrincipalAuthenticator::get_auth_type returns a value of TOBJ_APPAUTH. |
|
MANDATORY_ACL |
Indicates that authentication is used in the WebLogic Enterprise application and access control checks are performed on interfaces, services, queue names, and event names. The value MANDATORY_ACL is similar to ACL, but permission is denied if an associated ACL is not found for the name.The tmloadcf command prompts for an application password. Tobj::PrincipalAuthenticator::get_auth_type returns a value of TOBJ_APPAUTH. |
Note: If the IIOP Listener/Handler is configured for using certificate-based authentication, the value of the SECURITY parameter must be USER_AUTH or greater.
Configuring Application Password Security
To configure application password security, complete the following steps:
Configuring Username/Password Authentication
Username/Password authentication requires that in addition to the application password, each client application must provide a valid username and user-specific data, such as a password, to interact with the WebLogic Enterprise application. The password must match the password associated with the username stored in the tpusr file. The checking of user passwords against the username/password combination in the tpusr file is carried out by the authentication service AUTHSVC, which is provided by the authentication server AUTHSVR.
To enable Username/Password authentication, complete the following steps:
*RESOURCES
SECURITY USER_AUTH
AUTHSVC AUTHSVC
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
CLOPT="-A" causes the tmboot command to pass only the default command-line options (invoked by "-A") to AUTHSVR when the tmboot command starts the application.
Sample UBBCONFIG File for Username/Password Authentication
Listing 7-4 includes a UBBCONFIG file for an application which uses Username/Password authentication. The key sections of the UBBCONFIG file are noted in bold face text.
Listing 7-3 Sample UBBCONFIG File for Username/Password Authentication
*RESOURCES
IPCKEY 55432
DOMAINID securapp
MASTER SITE1
MODEL SHM
LDBAL N
SECURITY USER_AUTH
AUTHSVR "AUTHSVC"
*MACHINES
"ICEAXE"
LMID = SITE1
APPDIR = "D:\M3\samples\corba\SECURAPP"
TUXCONFIG = "D:\M3\samples\corba\SECURAPP\results\tuxconfig"
TUXDIR = "D:\WLE5"
MAXWSCLIENTS = 10
*GROUPS
SYS_GRP
LMID = SITE1
GRPNO = 1
APP_GRP
LMID = SITE1
GRPNO = 2
*SERVERS
DEFAULT:
RESTART = Y
MAXGEN = 5
AUTHSVR
SRVGRP = SYS_GRP
SRVID = 1
RESTART = Y
GRACE = 60
MAXGEN = 2
TMSYSEVT
SRVGRP = SYS_GRP
SRVID = 1
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 2
CLOPT = "-A -- -N -M"
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 3
CLOPT = "-A -- -N"
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 4
CLOPT = "-A -- -F"
simple_server
SRVGRP = APP_GRP
SRVID = 1
RESTART = N
ISL
SRVGRP = SYS_GRP
SRVID = 5
CLOPT = "-A -- -n //PCWIZ::2500"
SEC_PRINCIPAL_NAME="IIOPListener"
SEC_PRINCIPAL_PASSVAR="ISH_PASS"
Configuring Certificate-based Authentication
Certificate-based authentication uses the SSL protocol so you need to install the WebLogic Enterprise Security Pack and configure the SSL protocol before you can use certificate-based authentication. Information about installing the WebLogic Enterprise Security Pack can be found in the BEA WebLogic Enterprise Installation Guide. For information about configuring the SSL protocol, see "Configuring the SSL Protocol" on page 6-1.
You also need an LDAP-enabled directory and certificate authority in place before using certificate-based authentication in a WebLogic Enterprise application. You can choose any LDAP-enabled directory service. You can also choose the certificate authority from which to obtain certificates and private keys used in a WebLogic Enterprise application. For more information, see "Managing Public Key Security" on page 4-1.
To enable certificate-based authentication, complete the following steps:
Windows NT
%TUXDIR%\udataobj\security\keys
UNIX
$TUXDIR/udataobj/security/keys
*RESOURCES
SECURITY USER_AUTH
To enable certificate-based authentication, complete one of the following:
Enabling certificate-based authentication requires the WebLogic Enterprise Security Pack to be installed. If the -a option or the -ORBmutualAuth command-line option or system property is executed and a license to enable the use of the SSL protocol does not exist, the IIOP Listener/Handler, CORBA C++ ORB, or CORBA Java ORB will not start.
Sample UBBCONFIG File for Certificate-based Authentication
Listing 7-4 includes a UBBCONFIG file for an application which uses certificate-based authentication. The key sections of the UBBCONFIG file are noted in bold face text.
Listing 7-4 Sample UBBCONFIG File for Certificate-based Authentication
*RESOURCES
IPCKEY 55432
DOMAINID simpapp
MASTER SITE1
MODEL SHM
LDBAL N
SECURITY USER_AUTH
*MACHINES
"ICEAXE"
LMID = SITE1
APPDIR = "D:\M3\samples\corba\SIMPAP~1"
TUXCONFIG = "D:\M3\samples\corba\SIMPAP~1\results\tuxconfig"
TUXDIR = "D:\WLE5"
MAXWSCLIENTS = 10
*GROUPS
SYS_GRP
LMID = SITE1
GRPNO = 1
APP_GRP
LMID = SITE1
GRPNO = 2
*SERVERS
DEFAULT:
RESTART = Y
MAXGEN = 5
TMSYSEVT
SRVGRP = SYS_GRP
SRVID = 1
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 2
CLOPT = "-A -- -N -M"
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 3
CLOPT = "-A -- -N"
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 4
CLOPT = "-A -- -F"
simple_server
SRVGRP = APP_GRP
SRVID = 1
RESTART = N
ISL
SRVGRP = SYS_GRP
SRVID = 5
CLOPT = "-A -- -a -z40 -Z128 -S2458 -n //ICEAXE:2468"
SEC_PRINCIPAL_NAME="IIOPListener"
SEC_PRINCIPAL_LOCATION="IIOPListener.pem"
SEC_PRINCIPAL_PASSVAR="ISH_PASS"
Configuring Access Control
Note: Access control only applies to the default authorization implementation. The default authorization provider for CORBA does not enforce access control checks. In addition, the setting of the SECURITY parameter in the UBBCONFIG file does not control or enforce access control used by third-party authorization implementation.
There are two levels of access control 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.
By using an access control list, a system administrator can organize users into groups and associate the groups with objects that the member users have permission to access. Access control is done at the group level for the following reasons:
When using the default authorization provider, the access control checking feature is based on the following files that are created and maintained by the system administrator:
Configuring Optional ACL Security
The difference between ACL and MANDATORY_ACL is the following.
When using multiple authorization implementations, all the implementations are placed under a single master authorization implementation. Each subordinate authorization implementation votes PERMIT, DENY, or ABSTAIN on the client request. The ABSTAIN return value is necessary for authorization implementation developers to gracefully handle unexpected situations that are not understood (such as new operation names that might be added in the future).
The rules for result determination are as follows:
Optional ACL Security requires that each client provide an application password, a username, and user-specific data, such as a password, to join the application.
To configure optional ACL security, complete the following steps:
*RESOURCES
SECURITY ACL
AUTHSVC ..AUTHSVC
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
CLOPT="-A" causes the tmboot command to pass only the default command-line options (invoked by "-A") to AUTHSVR when the tmboot command starts the application. By default, AUTHSVR uses the user information in the tpusr file to authenticate clients that want to interact with the WebLogic Enterprise application.
Configuring Mandatory ACL Security
Mandatory ACL security level requires that each client provide an application password, a username, and user-specific data, such as a password, to interact with the WebLogic Enterprise application.
To configure mandatory ACL security, perform the following steps:
*RESOURCES
SECURITY MANDATORY_ACL
AUTHSVC ..AUTHSVC
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
CLOPT="-A" causes the tmboot command to pass only the default command-line options (invoked by "-A") to AUTHSVR when the tmboot command starts the application. By default, AUTHSVR uses the client user information in the tpusr file named to authenticate clients that want to join the application. The tpusr file resides in the directory referenced by the first pathname defined in the application's APPDIR variable.
Setting ACL Policy between WebLogic Enterprise Applications
As the administrator, you use the following configuration parameters to set and control the access control list (ACL) policy between WebLogic Enterprise applications that reside in different WebLogic Enterprise domains.
.
|
Parameter Name |
Description |
Setting |
|---|---|---|
|
ACL_POLICY in DMCONFIG (TA_DMACLPOLICY in DM_MIB) |
May appear in the DM_REMOTE_DOMAINS section of the DMCONFIG file for each remote domain access point. Its value for a particular remote domain access point determines whether or not the local domain gateway modifies the identity of service requests received from the remote domain.* |
LOCAL or GLOBAL. Default is LOCAL. LOCAL means modify the identity of service requests, and GLOBAL means pass service requests with no change. DOMAINID string for the remote domain access point. |
|
* A remote domain access point is also known as an RDOM (pronounced "are dom") or simply remote domain. |
||
The following bullets explain how the ACL_POLICY configuration affects the operation of local domain gateway (GWTDOMAIN) processes.
In this configuration, each application has an ACL database containing entries only for users in its own domain.
Impersonating the Remote Domain Gateway
If the domain gateway receives a client request from a remote domain for which the ACL_POLICY parameter is set (or defaulted) to LOCAL in the local DMCONFIG file, the domain gateway removes any tokens from the request and creates an application key containing the DOMAINID of the remote domain access point.
Example DMCONFIG Entries for ACL Policy
In the following example, the connection through the remote domain access point b01 is configured for global ACL in the local DMCONFIG file, meaning that the domain gateway process for domain access point c01 passes client requests from and to domain access point b01 without change.
*DM_LOCAL_DOMAINS
# <LDOM name> <Gateway Group name> <domain type> <domain id>
# [<connection principal name>] [<security>]...
c01 GWGRP=bankg1
TYPE=TDOMAIN
DOMAINID="BA.CENTRAL01"
CONN_PRINCIPAL_NAME="BA.CENTRAL01"
SECURITY=DM_PW
.
.
.
*DM_REMOTE_DOMAINS
# <RDOM name> <domain type> <domain id> [<ACL policy>]
# [<connection principal name>] [<local principal name>]...
b01 TYPE=TDOMAIN
DOMAINID="BA.BANK01"
ACL_POLICY=GLOBAL
CONN_PRINCIPAL_NAME="BA.BANK01"
Configuring Security to Interoperate with Older WebLogic Enterprise Client Applications
It may be necessary for CORBA and EJB server applications in a WebLogic Enterprise domain to securely interoperate with client applications that were built with the security features available in the 4.2 and 5.0 releases of the WebLogic Enterprise product. To allow CORBA or EJB server applications to interoperate with older, secure client applications, you need to either set the CLOPT -t option in the UBBCONFIG file or specify the -ORBinterOp command-line option or system property on the CORBA object request broker (ORB).
By setting the CLOPT -t option or specifying the -ORBinterOP command-line option or system property, you are lowing the effective level of security for a CORBA or EJB server. Therefore, the use of compatibility mode should be carefully considered before enabling the mode in a server application.
You need to set the CLOPT -t option on any server applications that will interoperate with the older client application. The CLOPT -t option is specified in the *SERVERS section of the UBBCONFIG file.
Listing 7-5 Example UBBCONFIG File Entries for Interoperability
*SERVERS
SecureSrv SRVGRP=group_name SRVID=server_number
CLOPT=A -t..
If you are using a remote CORBA C++ or CORBA Java ORB, specify the -ORBinterOp command-line option or system property on the ORB to allow the ORB to interoperate with client application using the security features in the 4.2 or 5.0 releases of the WebLogic Enterprise product.
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|