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 following configuration parameters to specify principal names for the Workstation Handler (WSH), domain gateway (GWTDOMAIN), and server processes running in your Release 7.1 or later BEA Tuxedo application.

Parameter Name	Description	Setting
SEC_PRINCIPAL_NAME in UBBCONFIG (TA_SEC_PRINCIPAL_NAME in TM_MIB)	During application booting, each WSH, domain gateway, and server process in the application calls the authentication plug-in to acquire security credentials for the security principal name specified in SEC_PRINCIPAL_NAME.*	1 - 511 characters. If not specified at any level in the configuration hierarchy, the security principal name defaults to the DOMAINID string specified in the UBBCONFIG file.
CONNECTION_PRINCIPAL_NAME for local domain access point in DMCONFIG (TA_DMCONNPRINCIPALNAME for LACCESSPOINT in DM_MIB)**	During application booting, each domain gateway process in the application calls the authentication plug-in a second time to acquire security credentials for the connection principal name specified in CONNECTION_PRINCIPAL_NAME.*	1 - 511 characters. If not specified, the connection principal name defaults to the DOMAINID string for the local domain access point specified in the DMCONFIG file.
* The topics that follow explain how the system processes acquire credentials and why they need them. ** The local domain access point is also known as the LDOM (pronounced "el dom") or simply local domain.

SEC_PRINCIPAL_NAME may be specified any of the following four levels in the configuration hierarchy:

• RESOURCES section in UBBCONFIG or T_DOMAIN class in TM_MIB

• MACHINES section in UBBCONFIG or T_MACHINE class in TM_MIB

• GROUPS section in UBBCONFIG or T_GROUP class in TM_MIB

• SERVERS section in UBBCONFIG or T_SERVER class in TM_MIB

A security principal name at a particular configuration level can be overridden at a lower level. For example, suppose you configure terri as the principal name for machine mach1, and john as the principal name for server serv1 running on mach1. The processes on mach1 behave as follows:

• All WSH, domain gateway, and server processes on mach1 except serv1 processes use terri as a principal name.

• All serv1 processes use john as a principal name.

How System Processes Acquire Credentials

During application booting, each WSH, domain gateway, and server process in the application includes its security principal name as an argument when calling the authentication plug-in to (1) acquire security credentials and (2) get authorization and auditing tokens for itself. The following diagram demonstrates the procedure.

Each domain gateway process in the application calls the authentication plug-in a second time to acquire credentials and tokens for its assigned connection principal name.

A WSH needs credentials so that it can authenticate Workstation clients that want to join the application, and to get authorization and auditing tokens for the authenticated Workstation clients. A WSH needs its own authorization and auditing tokens when handling requests from pre-Release 7.1 clients (clients running BEA Tuxedo Release 6.5 or earlier software) so that it can call the authentication plug-in to establish identities for the older clients. This behavior is described in Mandating Interoperability Policy.

A domain gateway needs one set of credentials so that it can authenticate remote domain gateways for the purpose of establishing links between BEA Tuxedo applications, as described in Establishing a Link Between Domains. (No authorization or auditing tokens are assigned to authenticated remote domain gateways.) A domain gateway acquires these credentials for the principal name specified in the CONNECTION_PRINCIPAL_NAME parameter.

A domain gateway needs a second set of credentials so that it can handle requests from pre-Release 7.1 clients, which involves calling the authentication plug-in to establish identities for the older clients. This behavior is described in Mandating Interoperability Policy. It also needs these credentials to establish identities when enforcing the local access control list (ACL) policy, as described in Setting ACL Policy. A domain gateway acquires these credentials for the principal name specified in the SEC_PRINCIPAL_NAME parameter.

A system or application server needs its own authorization and auditing tokens when handling requests from pre-Release 7.1 clients so that it can call the authentication plug-in to establish identities for the older clients. This behavior is described in Mandating Interoperability Policy.

A server also needs its own tokens when performing a server permission upgrade, which occurs when the authorization and auditing tokens of the server are assigned to messages that pass through the server but originate at a client. The service upgrade capability is described in Replacing Client Tokens with Server Tokens.

Note: An application server cannot call the authentication plug-in itself. It is the underlying system code that calls the authentication plug-in for the application server.

The following example pertains to specifying security principal names in the UBBCONFIG file using the SEC_PRINCIPAL_NAME parameter. For an example of specifying connection principal names in the DMCONFIG file using the CONNECTION_PRINCIPAL_NAME parameter, see Example DMCONFIG Entries for Establishing a Link.

*RESOURCES
SEC_PRINCIPAL_NAME        "Tommy"
          .
          .
          .

*SERVERS
"TMQUEUE"              SRVGRP="QUEGROUP"            SRVID=1
      CLOPT="-t -s secsdb:TMQUEUE"
      SEC_PRINCIPAL_NAME="TOUPPER"

• Mandating Interoperability Policy

• Establishing a Link Between Domains

• Setting ACL Policy

• Security Administration Tasks