![]() |
![]() |
|
|
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.
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.
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
![]() |
![]() |
![]() |
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|