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 Oracle Tuxedo 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 CORBA 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 CORBA 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 CORBA 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*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"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:*SERVERS
KERBEROSSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"Once you configure the default authentication server, the identity of the IIOP Listener/Handler (as specified in the SEC_PRINCIPAL_NAME parameter in the UBBCONFIG file) must be specified in the tpusr file. In addition, all the users of the CORBA application must be specified in the tpusr file. For more information, see “Defining Authorized Users” on page 7‑3.You use the tpusradd command to create files containing lists of authorized principals. The tpusradd command adds a new principal entry to the Oracle Tuxedo 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 CORBA 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 CORBA application.The tpusradd file should be owned by the administrator account. Oracle 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
• -g gidThe group identification number. The GID can be an integer identifier or character-string name. This option defines the new user’s group membership. It defaults to the other group (identifier 0).
• -c client_name
• If you are using the default authentication server, the identity of the IIOP Listener/Handler (as specified in the SEC_PRINCIPAL_NAME parameter in the UBBCONFIG file) must be specified in the tpusr file. In addition, all the users of the CORBA application must be specified in the tpusr file.If you are using a custom authentication service, define the IIOP Listener/Handler and the users of the CORBA application in the user registry of the custom authentication service. In addition, no file called tpusr should appear in $APPDIR. If a file by that name exists, a CORBA/NO_PERMISSION exception will be raised.Listing 7‑2 includes a sample tpusr file.Listing 7‑2 Sample tpusr File
Note: Use the tpgrpadd command to add groups of principals to the Oracle Tuxedo security data files.In addition to the tpusradd and tpgrpadd commands, the Oracle Tuxedo product provides the following commands to modify the tpusr and tpgrp files:
•
•
•
• For a complete description of the commands, see the Oracle Tuxedo Command Reference in the Oracle Tuxedo 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 CORBA application, but only after converting them to the format required by the Oracle Tuxedo 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.
1. Ensure that you are working on the application MASTER machine and that the application is inactive.
2. To convert the /etc/password file into the format needed by the Oracle Tuxedo system, enter the following command: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.
3. To convert the /etc/group file into the format needed by the Oracle Tuxedo system, enter the following command: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.As part of defining security for a CORBA application, you need to define the SECURITY parameter in the RESOURCES section of the UBBCONFIG file. The SECURITY parameter has the following format:Table 7‑1 describes the values for the SECURITY parameter.
Note: If the IIOP Listener/Handler is configured for using certificate authentication, the value of the SECURITY parameter must be USER_AUTH or greater.
1. Ensure that you are working on the application MASTER machine and that the application is inactive.
2.
3. Load the configuration by running the tmloadcf command. The tmloadcf command parses UBBCONFIG and loads the binary TUXCONFIG file to the location referenced by the TUXCONFIG variable.
4. 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 CORBA 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.
1. Define users and their associated passwords in the tpusr file. For more information about the tpusr file, see “Defining Authorized Users” on page 7‑3.
2. Ensure that you are working on the application MASTER machine and that the application is inactive.
3. Open UBBCONFIG with a text editor and add the following lines to the RESOURCES and SERVERS sections:*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.
4. Load the configuration by running the tmloadcf command. The tmloadcf command parses UBBCONFIG and loads the binary TUXCONFIG file to the location referenced by the TUXCONFIG variable.
5. Listing 7‑3 includes a UBBCONFIG file for an application which uses password authentication. The key sections of the UBBCONFIG file are noted in boldface text.*RESOURCES
IPCKEY 55432
DOMAINID securapp
MASTER SITE1
MODEL SHM
LDBAL N
SECURITY USER_AUTH
AUTHSVR “AUTHSVC”
*MACHINES
"ICEAXE"
LMID = SITE1
APPDIR = "D:\TUXDIR\samples\corba\SECURAPP"
TUXCONFIG = "D:\TUXDIR\samples\corba\SECURAPP\results
\tuxconfig"
TUXDIR = "D:\Tux8"
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"Certificate authentication uses the SSL protocol so you need to install the license for the SSL protocol and configure the SSL protocol before you can use certificate authentication. Information about installing the license for the SSL protocol can be found in Installing the Oracle Tuxedo System. 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 authentication in a CORBA 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 CORBA application. For more information, see “Managing Public Key Security” on page 4‑1.
5. Store the private keys for the CORBA application in the Home directory of the user or in the following directories:
7. Define the SEC_PRINCIPAL, SEC_PRINCIPAL_LOCATION, and SEC_PRINCIPAL_PASSVAR for the ISL server process in the UBBCONFIG file. For more information, see “Defining Security Parameters for the IIOP Listener/Handler” on page 6‑6.
8. Use the tpusradd command to define the authorized users of your CORBA application and IIOP Listener/Handler. Use the e-mail addresss of the user in the tpusr file. For more information about the tpusr file, see “Defining Authorized Users” on page 7‑3. Use the phase phrase you defined in SEC_PRINCIPAL_PASSVAR as the password for the IIOP Listener/Handler.
9. Define a port on the IIOP Listener/Handler for secure communications using the -S option of the ISL command. For more information, see “Defining a Port for SSL Network Connections” on page 6‑2.
10. Enable certificate authentication in the IIOP Listener/Handler using the -a option of the ISL command.
11. Create a Trusted Certificate Authority file (trust_ca.cer) that defines the certificate authorities trusted by the CORBA application. For more information, see “Defining the Trusted Certificate Authorities” on page 4‑7.
12. Open UBBCONFIG with a text editor and add the following lines to the RESOURCES and SERVERS sections:
13. Load the configuration by running the tmloadcf command. The tmloadcf command parses UBBCONFIG and loads the binary TUXCONFIG file to the location referenced by the TUXCONFIG variable.
14. Optionally, create a Peer Rules file (peer_val.rul) for both the CORBA application and the IIOP Listener/Handler. For more information, see “Creating a Peer Rules File” on page 4‑8.
15.
• Use the -a option of the ISL command to specify that certificate authentication must be used by applications connecting to the IIOP Listener/Handler.
• Use the -ORBmutualAuth command-line option on the ORB to specify that certificate authentication must be used by applications connecting to the CORBA C++ ORB.Enabling certificate authentication requires the license for the SSL protocol to be installed. If the -a option or the -ORBmutualAuth command-line option is executed and a license to enable the use of the SSL protocol does not exist, the IIOP Listener/Handler or CORBA C++ ORB will not start.Listing 7‑4 includes a UBBCONFIG file for a CORBA application which uses certificate authentication. The key sections of the UBBCONFIG file are noted in boldface text.*RESOURCES
IPCKEY 55432
DOMAINID simpapp
MASTER SITE1
MODEL SHM
LDBAL N
SECURITY USER_AUTH
AUTHSVR “AUTHSVC”
*MACHINES
"ICEAXE"
LMID = SITE1
APPDIR = "D:\TUXDIR\samples\corba\SIMPAP~1"
TUXCONFIG = "D:\TUXDIR\samples\corba\SIMPAP~1
\results\tuxconfig"
TUXDIR = "D:\TUX8"
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 -- -a -z40 -Z128 -S2458 -n //ICEAXE:2468"
SEC_PRINCIPAL_NAME="IIOPListener"
SEC_PRINCIPAL_LOCATION="IIOPListener.pem"
SEC_PRINCIPAL_PASSVAR="ISH_PASS"
Note: Access control only applies to the default authorization implementation. The default authorization provider for the CORBA security environment 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.
• tpusr contains a list of users
• tpgrp contains a list of groups
• tpacl contains a list of ACLs
• In ACL mode, a service request will be allowed if there is not a specific ACL.
• In MANDATORY_ACL mode, the service request is denied if there is not a specific ACL.
1. Ensure that you are working on the application MASTER machine and that the application is inactive.
2. Open UBBCONFIG with a text editor and add the following lines to the RESOURCES and SERVERS sections:*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 CORBA application.
3. Load the configuration by running the tmloadcf command. The tmloadcf command parses UBBCONFIG and loads the binary TUXCONFIG file to the location referenced by the TUXCONFIG variable.
4.
1. Ensure that you are working on the application MASTER machine and that the application is inactive.
2. Open UBBCONFIG with a text editor and add the following lines to the RESOURCES and SERVERS sections:*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.
3. Load the configuration by running the tmloadcf command. The tmloadcf command parses UBBCONFIG and loads the binary TUXCONFIG file to the location referenced by the TUXCONFIG variable.
4.
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 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.
• When using a local ACL policy, each domain gateway (GWTDOMAIN) modifies inbound CORBA client requests (requests originating from the remote application and received over the network connection) so that they take on the DOMAINID for the remote domain access point and thus have the same access permissions as that identity. Each domain gateway passes outbound client requests without change.In this configuration, each application has an ACL database containing entries only for users in its own domain.
• When using a global ACL policy, each domain gateway (GWTDOMAIN) passes inbound and outbound CORBA client requests without change. In this configuration, each application has an ACL database containing entries for users in its own domain as well as users in the remote domain.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.In Listing 7‑5, 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.Listing 7‑5 Sample DMCONFIG File for ACL Policy*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"It may be necessary for CORBA erver applications in an Oracle Tuxedo 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 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 on the CORBA object request broker (ORB).By setting the CLOPT -t option or specifying the -ORBinterOP command-line option, you are lowering the effective level of security for a CORBA 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 Listing 7‑6.If you are using a remote CORBA C++ ORB, specify the -ORBinterOp command-line option 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.