BEA Logo BEA Tuxedo Release 7.1

  Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy

 

   Tuxedo Doc Home   |   Security   |   Topic List   |   Previous   |   Next   |   Contents

   Using BEA Tuxedo Security

Setting ACL Policy

As the administrator, you use the following configuration parameters to set and control the access control list (ACL) policy between applications running BEA Tuxedo Release 7.1 or later software.

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.

LOCAL_PRINCIPAL_NAME in DMCONFIG (TA_DMLOCALPRINCIPALNAME in DM_MIB)

May appear in the DM_REMOTE_DOMAINS section of the DMCONFIG file for each remote domain access point. If the ACL_POLICY parameter is set (or defaulted) to LOCAL for a particular remote domain access point, the local domain gateway modifies the identify of service requests received from the remote domain to the principal name specified in LOCAL_PRINCIPAL_NAME.

1 - 511 characters. If not specified, the principal name defaults to the 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 three figures show how the ACL_POLICY configuration affects the operation of local domain gateway (GWTDOMAIN) processes.

Establishing a Local ACL Policy

In the preceding figure, each domain gateway (GWTDOMAIN) modifies inbound client requests (requests originating from the remote application and received over the network connection) so that they take on the LOCAL_PRINCIPAL_NAME identity configured 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. One such user is the LOCAL_PRINCIPAL_NAME identity configured for the remote domain access point.

Note: The preceding description also applies to applications running BEA Tuxedo pre-Release 7.1 software except that the system uses the DOMAINID identity configured for the remote domain access point. Essentially, the local ACL policy is hardcoded in BEA Tuxedo Release 6.5 or earlier software.

Establishing a Global ACL Policy

In the preceding figure, each domain gateway (GWTDOMAIN) passes inbound and outbound 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.

Establishing a One-Way Local and One-Way Global ACL Policy

In the preceding figure, the domain gateway (GWTDOMAIN) in application 1 modifies inbound client requests so that they take on the LOCAL_PRINCIPAL_NAME identity configured for the remote domain access point for application 2 and thus have the same access permissions as that identity; the domain gateway passes outbound client requests without change. The domain gateway (GWTDOMAIN) in application 2 passes inbound and outbound client requests without change.

In this configuration, application 1 has an ACL database containing entries only for users in its own domain; one such user is the LOCAL_PRINCIPAL_NAME identity configured for the remote domain access point for application 2. Application 2 has an ACL database containing entries for users in its own domain as well as users in application 1.

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 performs the following tasks.

  1. Calls the internal "impersonate user" function to get authorization and auditing tokens for the client based on the LOCAL_PRINCIPAL_NAME identity configured for the remote domain access point

  2. Uses these tokens to overwrite the tokens already attached to the client request

  3. Forwards the request to the destination server

For more detail on the "impersonate user" function, see Establishing an Identity for an Older Client.

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. For global ACL, the LOCAL_PRINCIPAL_NAME entry for domain access point b01 is ignored.

*DM_LOCAL_DOMAINS
# <LDOM name> <Gateway Group name> <domain type> <domain id>
# [<connection principal name>] [<security>]...
c01 GWGRP=bankg1
TYPE=TDOMAIN
DOMAINID="BA.CENTRAL01"
CONNECTION_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
CONNECTION_PRINCIPAL_NAME="BA.BANK01"
LOCAL_PRINCIPAL_NAME="BA.BANK01.BOB"

See Also