Configuring Authentication

This topic includes the following sections:

•	Configuring the Authentication Server

•	Defining Authorized Users

•	Defining a Security Level

•	Configuring Application Password Security

•	Configuring Password Authentication

•	Sample UBBCONFIG File for Password Authentication

•	Configuring Certificate Authentication

•	Sample UBBCONFIG File for Certificate Authentication

•	Configuring Access Control

•	Configuring Security to Interoperate with Older WebLogic Enterprise Client Applications

Notes:

The Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported. All Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB text references, associated code samples, should only be used to help implement/run third party Java ORB libraries, and for programmer reference only.

Technical support for third party CORBA Java ORBs should be provided by their respective vendors. Oracle Tuxedo does not provide any technical support or documentation for third party CORBA Java ORBs.

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 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

*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 Oracle Tuxedo 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"

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.

Defining Authorized Users

As part of configuring security for a CORBA application, you need to define the principals and groups of principals who have access to the CORBA application.

Authorized users can be defined in the following ways:

•	When using password authentication, authorized users are defined using a username and an associated password.

•	When using certificate authentication, authorized users are identified by their e-mail address. The e-mail address maps the external identity of a principal represented by a digital certificate to an identity used by a CORBA application.

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

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.

•

-g gid

The 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

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 CORBA application.

•

usrname

A string of printable characters that specifies the new login name of the user. The name may not contain a colon (:). pound sign (#), or a newline (\n). The user name must be unique within the list of existing users for the CORBA application

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

Usrname    Cltname    Password Entry    Uid    GID
milozzi   “bar”               2        100    0
smart     “ “                 1        1      0
pat       “tpsysadmin”        3        0      8192
butler     “tpsysadmin”        3        N/A     8192

 

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:

•

tpusrdel

•

tpusrmod

•

tpgrpdel

•

tpgrpmod

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:

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.

3.	To convert the /etc/group file into the format needed by the Oracle Tuxedo system, enter the following command:

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 CORBA 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.

 

Table 7‑1 Values for the SECURITY Parameter 

Value	Description
NONE	Indicates that no password or access checking is performed in the CORBA 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 Oracle Tuxedo 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 Oracle Tuxedo 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 CORBA 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 CORBA 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 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:

1.	Ensure that you are working on the application MASTER machine and that the application is inactive.

2.	Set the SECURITY parameter in the RESOURCES section of the UBBCONFIG file to APP_PW.

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.	The system prompts you for a password. The password you enter may be up to 30 characters long. It becomes the password for the application and remains in effect until you change it by using the passwd parameter of the tmadmin command.

5.	Distribute the application password to authorized users of the application through an offline means such as telephone or letter.

Configuring Password Authentication

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.

To enable password authentication, complete the following steps:

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:

*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.

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.	The system prompts you for a password. The password you enter may be up to 30 characters long. It becomes the password for the application and remains in effect until you change it by using the passwd parameter of the tmadmin command.

6.	Distribute the application password to authorized users of the application through an offline means such as telephone or letter.

Sample UBBCONFIG File for Password Authentication

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.

Listing 7‑3 Sample UBBCONFIG File for Password Authentication

*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"

 

Configuring Certificate Authentication

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.

To enable certificate authentication, complete the following steps:

1.	Install the license for the SSL protocol.

2.	Set up an LDAP-enabled directory service.

3.	Obtain a certificate and private key for the IIOP Listener/Handler from a certificate authority.

4.	Obtain a certificate and private key for the CORBA application from a certificate authority.

5.	Store the private keys for the CORBA application in the Home directory of the user or in the following directories:

Windows 2003

%TUXDIR%\udataobj\security\keys

UNIX

$TUXDIR/udataobj/security/keys

6.	Publish the certificates for the IIOP Listener/Handler, the CORBA application, and the certificate authority in the LDAP-enabled directory service.

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:

*RESOURCES
SECURITY   USER_AUTH

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.	Optionally, modify the LDAP search file filter to reflect the hierarchy in place in your enterprise. For more information, see “Editing the LDAP Search Filter File” on page 4‑4.

To enable certificate authentication, complete one of the following:

•	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.

Sample UBBCONFIG File for Certificate Authentication

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.

Listing 7‑4 Sample UBBCONFIG File for Certificate Authentication

*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"

 

Configuring Access Control

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.

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:

•	System administration is simplified. It is easier to give a group of people access to a new object than it is to give individual users access to the object.

•

Performance is improved. Because access permission needs to be checked for each invocation of an entity, permission should be resolved quickly. Because there are fewer groups than users, it is quicker to search through a list of privileged groups than it is to search through a list of privileged users.

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:

•	tpusr contains a list of users

•	tpgrp contains a list of groups

•	tpacl contains a list of ACLs

Configuring Optional ACL Security

The difference between ACL and MANDATORY_ACL is the following.

•	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.

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:

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:

*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 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.	The system prompts you for a password. The password you enter may be up to 30 characters long. It becomes the password for the application and remains in effect until you change it by using the passwd command of tmadmin.

5.	Distribute the application password to authorized users of the application through an offline means such as telephone or letter.

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 CORBA application.

To configure mandatory ACL security, perform the following steps:

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:

*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.

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.	The system prompts you for a password. The password you enter may be up to 30 characters long. It becomes the password for the application and remains in effect until you change it by using the passwd command of tmadmin.

5.	Distribute the application password to authorized users of the application through an offline means such as telephone or letter.

Setting ACL Policy Between CORBA Applications

As the administrator, you use the following configuration parameters to set and control the access control list (ACL) policy between CORBA applications that reside in different Oracle Tuxedo 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.

•

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.

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 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"

 

Configuring Security to Interoperate with Older WebLogic Enterprise Client Applications

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.

Listing 7‑6 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++ 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.