Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	http://www.oracle.com/technology/documentation/index.html   |   Site Map   |   Search   |   PDF Files   |   Contact   |   Glossary
Tuxedo Doc Home   |   Security   |   Topic List   |   Previous   |   Next   |   Contents

   Using BEA Tuxedo Security

As the administrator, you use the CLOPT -t option in the UBBCONFIG file to allow WSH, domain gateway (GWTDOMAIN), and server processes in your application to interoperate with machines running BEA Tuxedo pre-Release 7.1 (6.5 or earlier) software. In addition, you use the WSALLOWPRE71 environment variable to allow Workstation clients to interoperate with machines running BEA Tuxedo pre-Release 7.1 software. The following four figures show what interoperability means for these processes.

In the preceding figure, the WSH authenticates with the Workstation client using an older (pre-Release 7.1) authentication protocol, calls the internal "impersonate user" function to get authorization and auditing tokens for the client, and attaches the tokens to the client request. If the CLOPT -t option is not specified for the Workstation Listener (WSL) that controls the WSH, no communication is possible between the newer WSH and the older Workstation client.

Note: The "impersonate user" function involves calling the authentication plug-in to establish an identity for the older client. See Establishing an Identity for an Older Client for details.

In the preceding figure, the WSH authenticates with the Workstation client using an older (pre-Release 7.1) authentication protocol; the client request does not receive authorization and auditing tokens. If the WSALLOWPRE71 environment variable is not set at the Workstation client or is set to N, no communication is possible between the older WSH and the newer Workstation client.

In the preceding figure, the local domain gateway (GWTDOMAIN) in application 1 authenticates with the remote domain gateway in application 2 using an older (pre-Release 7.1) authentication protocol. Upon receiving a request from a remote client, the local domain gateway calls the internal "impersonate user" function to get authorization and auditing tokens for the remote client and then attaches the tokens to the client request. For any outbound client request (client request originating in application 1 and destined for application 2), the local domain gateway strips the tokens from the request before sending the request along with the client's application key to the older application. (See Application Key for a description of the application key.)

If the CLOPT -t option is not specified for the domain gateway, no communication is possible between the newer application and the older application.

In the preceding figure, the destination server on machine 1 calls the internal "impersonate user" function to get authorization and auditing tokens for the remote client on machine 2, attaches the tokens to the client request, and then performs the request assuming the client passes any authorization checks. If the CLOPT -t option is not specified for the server, no communication is possible between the newer server and the older client.

Note: Also, in the preceding figure, if the WSH on machine 1 receives a client request destined for a server on machine 2, the WSH strips the tokens from the request before sending the request along with the client's application key to the older system. Similarly, if the native client on machine 1 sends a request to a server on machine 2, the native client strips the tokens from the request before sending the request along with the client's application key to the older system. See Application Key for a description of the application key.

For a WSH, domain gateway (GWTDOMAIN), or server process to establish an identity for an older client, the process calls the internal "impersonate user" function to obtain authorization and auditing tokens for the older client. The following diagram demonstrates the procedure.

How the WSH Establishes an Identity for an Older Client

When the CLOPT -t option is specified, the WSH establishes an identity for an older client using the usrname field of the TPINIT buffer for C, or the USRNAME field of the TPINFDEF-REC record for COBOL. (The WSH receives a TPINIT buffer/ TPINFDEF-REC record from a client when the client attempts to join the application, as described in Joining the Application.) The WSH includes the user name as the principal name when calling the "impersonate user" function.

For default authentication plug-ins, the "impersonate user" function finds the user name and its associated application key (user identifier, group identifier combination) in the local tpusr file, and then includes the user name and application key in both the authorization and auditing tokens created for the older client. The tpusr file is briefly described in Setting Up the User and Group Files.

When the CLOPT -t option is specified, the domain gateway establishes an identity for an older client using the LOCAL_PRINCIPAL_NAME string configured for the remote domain access point. (The domain gateway searches the DM_REMOTE_DOMAINS section of the local BDMCONFIG file-the binary equivalent of the DMCONFIG(5) file-to find the LOCAL_PRINCIPAL_NAME string for the remote domain access point. If not specified, the identity defaults to the DOMAINID string for the remote domain access point.) The domain gateway uses the LOCAL_PRINCIPAL_NAME string as the principal name when calling the "impersonate user" function.

For default authentication plug-ins, the "impersonate user" function finds the LOCAL_PRINCIPAL_NAME string and its associated application key in the local tpusr file, and then includes that string (identity) and application key in both the authorization and auditing tokens created for the older client.

When the CLOPT -t option is specified, the server establishes an identity for an older client using the client's assigned application key. (The client request received by the server contains the client's assigned application key.) The server finds the application key and its associated name in the local tpusr file, and then includes the name as the principal name when calling the "impersonate user" function.

For default authentication plug-ins, the "impersonate user" function finds the name and its associated application key in the local tpusr file, and then includes the name and application key in both the authorization and auditing tokens created for the older client.

The following table summarizes the functionality of WSH, domain gateway, and server processes when interoperability is and is not allowed using the CLOPT -t option.

Functionality of WSH, Domain Gateway, and Server Processes When Interoperability Is and Is Not Allowed

Process	Interoperability Allowed (CLOPT -t)	Interoperability Not Allowed
Workstation Handler (WSH)	If the WSH receives a request from a pre-Release 7.1 Workstation client to join the application, the WSH authenticates the client using a pre-Release 7.1 authentication protocol and calls the "impersonate user" function to get authorization and auditing tokens for the client based on the user name given in the request. When the WSH receives a service request from the authenticated Workstation client, it attaches the tokens to the client request and forwards the request to the destination server.	If the WSH receives a request from a pre-Release 7.1 Workstation client to join the application, the WSH rejects the request. No communication is possible between the newer WSH and the older Workstation client.
Domain gateway (GWTDOMAIN)	When the domain gateway sets up a connection to a pre-Release 7.1 remote domain gateway, it authenticates the remote domain gateway using a pre-Release 7.1 authentication protocol and then sets up the network connection. When the domain gateway receives a client request from the older domain, the domain gateway calls the "impersonate user" function to get authorization and auditing tokens for the client based on the LOCAL_PRINCIPAL_NAME (defaults to DOMAINID) identity configured for the remote domain access point, attaches the tokens to the client request, and then forwards the request to the destination server. The client has the same access permissions as the LOCAL_PRINCIPAL_NAME identity. For any outbound client request, the domain gateway strips the tokens from the request before sending the request along with the client's application key to the older domain.	The domain gateway does not set up a connection to a pre-Release 7.1 remote domain gateway. No communication is possible between the newer and older domains.
System or application server	If the server receives a request from a remote client running BEA Tuxedo pre-Release 7.1 software, the server calls the "impersonate user" function to get authorization and auditing tokens for the client based on the client's assigned application key, and then performs the client request assuming the client passes any authorization checks.	If the server receives a request from a remote client running BEA Tuxedo pre-Release 7.1 software, the server rejects the client request. No communication is possible between the newer server and the older client.

In the following example, all WSHs controlled by the Workstation Listener (WSL) are configured for interoperability.

*SERVERS
WSL       SRVGRP="group_name" SRVID=server_number ...
              CLOPT="-A -t ..."

• Specifying Principal Names

• Establishing a Link Between Domains

• Setting ACL Policy

• Security Administration Tasks

• Security Interoperability

• Setting Up Security in Domains and Configuring the Connections Between Your Domains in Using the BEA Tuxedo Domains Component