Using Security in ATMI Applications
|
 |
 |
|
 |
 |
The following sections explain how to set security policies for a BEA Tuxedo ATMI application:
Administering security for an ATMI application involves setting and enforcing security policies for the components of the application, including its clients, server machines, and gateway links. The application administrator sets the security policies for the ATMI application, and the BEA Tuxedo system upon which the ATMI application is built enforces those policies.
The BEA Tuxedo system offers the following ATMI security capabilities:
All but one of the security capabilities can be configured by the application administrator. The exception is auditing, which cannot be configured, as shown in the following figure.
Figure 2-1 Administering ATMI Security
Security administration consists of the following tasks:
The application administrator needs to know about the BEA Tuxedo registry if the ATMI application is to be configured with one or more custom security capabilities. On the other hand, if the ATMI application is to be configured only with default security, the BEA Tuxedo registry does not need to be changed.
The BEA Tuxedo registry is a disk-based repository for storing information related to plug-in modules. Initially, this registry holds registration information about the default security plug-ins.
Most BEA middleware products use a common transaction processing (TP) infrastructure that consists of a set of core services, such as security. The TP infrastructure is available to ATMI applications through well defined interfaces. These interfaces allow application administrators to change the default behavior of the TP infrastructure by loading and linking their own service code modules, referred to as plug-in modules or simply plug-ins.
The first step in loading a plug-in is to register the plug-in with the host operating system. Registering a plug-in adds an entry for the plug-in to the BEA Tuxedo registry, which is a set of binary files that stores information about active plug-ins. There is one registry per BEA Tuxedo installation.
$TUXDIR/udataobj directory.%TUXDIR%\udataobj directory.Every Workstation client and server machine in an ATMI application must use the same set of plug-in modules.
The administrator of an ATMI application in which custom plug-ins will be used is responsible for registering those plug-ins and performing other registry related tasks. An administer can register plug-ins in the BEA Tuxedo registry only from the local machine. That is, an administrator cannot register plug-ins while logged on to the host machine from a remote location.
Three commands are available for administering plug-ins:
epifreg—for registering a plug-inepifunreg—for unregistering a plug-inepifregedt—for editing registry informationInstructions for using these commands are available in Developing Security Services for ATMI and CORBA Environments. (This document contains the specifications for the security plug-in interface, and describes the plug-in framework feature that makes the dynamic loading and linking of security plug-in modules possible.) Also, when installing custom plug-ins, the supplying third-party security vendor should provide instructions for using these commands to set up the BEA Tuxedo registry to access the custom plug-ins.
For more information about security plug-ins, including installation and configuration procedures, see your BEA account executive.
An application administrator configures security for the ATMI application on the MASTER machine when the application is inactive. The underlying BEA Tuxedo system propagates the configuration information to the other machines in the ATMI application when the application is booted.
As the administrator, you can configure security for your ATMI application by:
UBBCONFIG)TM_MIB, orThe set of security parameters involved depends upon the security capability (authentication, authorization, link-level encryption, or public key) and whether you are using the default or custom security software.
You can edit the UBBCONFIG configuration file to set security policies for an ATMI application. The UBBCONFIG configuration file may have any filename, as long as the content of the file conforms to the format described on the UBBCONFIG(5) reference page in the BEA Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference.
For more details about UBBCONFIG and its binary equivalent, TUXCONFIG, see About the Configuration File on page 2-1 and Creating the Configuration File on page 3-1 in Setting Up a BEA Tuxedo Application.
The TM_MIB defines a set of classes through which the fundamental aspects of an ATMI application may be configured and managed. Separate classes are designated for machines, servers, networks, and so on. You should use the reference page TM_MIB(5) in combination with the generic Management Information Base (MIB) reference page MIB(5) to format administrative requests and interpret administrative replies. The MIB reference pages are defined in the BEA Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference.
Other component MIBs, including the ACL_MIB, DM_MIB, and WS_MIB, also play a role in managing security for an ATMI application. The reference page ACL_MIB(5) defines the ACL_MIB, the reference page DM_MIB(5) defines the DM_MIB, and the reference page WS_MIB(5) defines the WS_MIB.
For more information about BEA Tuxedo MIBs, start with MIB(5) in the BEA Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference. Also, see Introducing BEA Tuxedo ATMI.
You can also use the BEA Administration Console to change security policies for an ATMI application. The BEA Administration Console is a Web-based tool used to configure, monitor, and dynamically re-configure an application.
For details about the BEA Administration Console, see Introducing BEA Tuxedo ATMI.
The application administrator defines certain environment variables for an ATMI application as part of configuring the application. The values defined for the variables are absolute pathnames that reference BEA Tuxedo executables and data libraries.
Being able to find such files is essential to the job of administering an ATMI application. For example, all commands needed to manage application security are located in $TUXDIR/bin on a UNIX host machine, and in %TUXDIR%\bin on a Windows 2003 host machine.
For details on setting up the administration environment, see Administering a BEA Tuxedo Application at Run Time.
In addition to the security features in the ATMI environment of the BEA Tuxedo product, the application administrator needs to take full advantage of the security features of the host operating system to control access to files, directories, and system resources.
Most ATMI applications are managed by an application administrator who configures and boots the application, monitors the running application, and makes changes to it dynamically, as necessary. Because the ATMI application is started and run by the administrator, server programs are run with the administrator's permissions and are therefore considered secure or "trusted." This working method is supported by the login mechanism and the read and write permissions on the files, directories, and system resources provided by the underlying operating system.
Clients, on the other hand, are not started by the administrator. Instead, they are run directly by users with their own permissions. As a result, clients are not trusted.
In addition, users running native clients (that is, clients running on the same machine on which the server is running) have access to the configuration file and interprocess communication (IPC) mechanisms such as the bulletin board (in shared memory). Users running native clients always have such access, even when additional ATMI security is configured.
As the administrator, you can improve operating system security by observing the following general rules:
setuid utility).
Authentication allows communicating processes to prove their identities. It is the foundation for most other security capabilities.
Except for the configuration instructions identified in this topic, the procedures for administering authentication depend upon the underlying authentication system of the application. For procedures to administer a custom authentication system, see the documentation for that system. For procedures to administer the default authentication system, see Administering Default Authentication and Authorization.
The following figure demonstrates the use of the delegated trust authentication model by applications running BEA Tuxedo release 7.1 or later software. Workstation handlers (WSHs) and domain gateways (GWTDOMAINs) are known as trusted system gateway processes in the delegated trust authentication model, which is described in Understanding Delegated Trust Authentication.
Figure 2-2 Mutual Authentication in the Delegated Trust Authentication Model
Note: Mutual authentication is not used for a native client, which authenticates with itself.
The following topics provide the instructions needed to set up the configuration shown in the preceding figure. All of the topics involve authentication and the authentication plug-in.
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 ATMI application built with release 7.1 or later of the BEA Tuxedo software.
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_MIBMACHINES section in UBBCONFIG or T_MACHINE class in TM_MIBGROUPS section in UBBCONFIG or T_GROUP class in TM_MIBSERVERS section in UBBCONFIG or T_SERVER class in TM_MIBA 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:
mach1 except serv1 processes use terri as a principal name.serv1 processes use john as a principal name.During application booting, each WSH, domain gateway, and server process in the ATMI 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 figure demonstrates the procedure.
Figure 2-3 Acquiring Credentials and Tokens During Application Booting
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 ATMI 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.
*RESOURCESSEC_PRINCIPAL_NAME "Tommy".
.
.
*SERVERS
"TMQUEUE" SRVGRP="QUEGROUP" SRVID=1
CLOPT="-t -s secsdb:TMQUEUE"
SEC_PRINCIPAL_NAME="TOUPPER"
As the administrator, you use the CLOPT -t option in the UBBCONFIG file to allow WSH, domain gateway (GWTDOMAIN), and server processes in your ATMI application to interoperate with machines running BEA Tuxedo pre-release 7.1 (6.5 or earlier) software. In addition, you use the WSINTOPPRE71 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.
Figure 2-4 WSH Operating with Older Workstation Client
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.
Figure 2-5 Older WSH Operating with Workstation Client
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 WSINTOPPRE71 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.
Figure 2-6 Server Interoperating with Older ATMI Application
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 ATMI application and the older ATMI application.
Figure 2-7 Server Interoperating with Older BEA Tuxedo Systems
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 figure demonstrates the procedure.
Figure 2-8 Obtaining Authorization and Auditing Tokens 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 ATMI 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 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 ACCESSPOINTID 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.
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..."
When a domain gateway (GWTDOMAIN) attempts to establish a network link with another domain gateway, the following major events occur.
min-max values to be used to set up LLE on the link between the gateways. LLE is described in Link-Level Encryption.As the administrator, you use the following configuration parameter to establish a link between domain gateways running BEA Tuxedo release 7.1 or later software.
|
CONNECTION_PRINCIPAL_NAME in |
When this parameter appears in the For default authentication plug-ins, if a value is assigned to |
1-511 characters. If not specified, the principal name defaults to the |
|
When this parameter appears in the For default authentication plug-ins, if a value is assigned to |
1-511 characters. If not specified, the principal name defaults to the |
|
|
|
||
The following figure demonstrates how a link is established between domains using default authentication plug-ins.
Figure 2-9 Establishing a Link Between Domains Using Default Authentication
Note: The "Credentials" shown in the preceding figure were acquired by each domain gateway process at application booting using the CONNECTION_PRINCIPAL_NAME identity configured for the local domain access point.
In the preceding figure, notice that the information exchanged between the initiator and target domain gateways involves the CONNECTION_PRINCIPAL_NAME strings configured for the domain gateways, as specified in the BDMCONFIG files. Each authentication plug-in uses the password assigned to the remote domain access point (as defined in the DM_PASSWORDS section of the BDMCONFIG file) to encrypt the string before transmitting it over the network, and uses the password assigned to the local domain access point (as defined in the DM_PASSWORDS section of the BDMCONFIG file) to decrypt the received string. The encryption algorithm used is 56-bit DES, where DES is an acronym for the Data Encryption Standard.
For the encryption/decryption operation to succeed, the assigned password for the remote domain access point in the local BDMCONFIG file must be the same as the assigned password for the local domain access point in the remote BDMCONFIG file. (Similarly, if the domain security level is set to APP_PW, the application passwords in the respective TUXCONFIG files must be identical for the encryption/decryption operation to succeed.) For the authentication process to succeed, the received string must match the CONNECTION_PRINCIPAL_NAME string configured for the sender.
When the domain gateways pass the security checks, the link is established, and the gateways can forward service requests and receive replies over the established link.
In the following example, the configurations shown in the local DMCONFIG file are used when establishing a connection through the local domain access point c01 and the remote domain access point b01.
*DM_LOCAL# <local domain access point name> <gateway group name> <domain type>
# <domain id> [<connection principal name>] [<security>]...
c01 GWGRP=bankg1
TYPE=TDOMAIN
ACCESSPOINTID="BA.CENTRAL01"
CONNECTION_PRINCIPAL_NAME="BA.CENTRAL01"
SECURITY=DM_PW
.
.
.
*DM_REMOTE# <remote domain access point name> <domain type> <domain id>
# [<connection principal name>]...
b01 TYPE=TDOMAIN
ACCESSPOINTID="BA.BANK01"
CONNECTION_PRINCIPAL_NAME="BA.BANK01"
As the administrator, you use the following configuration parameters to set and control the access control list (ACL) policy between ATMI 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.
Figure 2-10 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 ATMI 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 ATMI applications running BEA Tuxedo pre-release 7.1 software except that the system uses the ACCESSPOINTID identity configured for the remote domain access point. Essentially, the local ACL policy is hardcoded in BEA Tuxedo release 6.5 or earlier software.
Figure 2-11 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 ATMI application has an ACL database containing entries for users in its own domain as well as users in the remote domain.
Figure 2-12 Establishing a One-way Local and One-way Global ACL Policy
In the preceding figure, the domain gateway (GWTDOMAIN) in ATMI application 1 modifies inbound client requests so that they take on the LOCAL_PRINCIPAL_NAME identity configured for the remote domain access point for ATMI 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 ATMI application 2 passes inbound and outbound client requests without change.
In this configuration, ATMI 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. ATMI application 2 has an ACL database containing entries for users in its own domain as well as users in ATMI application 1.
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.
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# <local domain access point name> <gateway group name>
# <domain type> <domain id> [<connection principal name>]
# [<security>]...
c01 GWGRP=bankg1
TYPE=TDOMAIN
ACCESSPOINTID="BA.CENTRAL01"
CONNECTION_PRINCIPAL_NAME="BA.CENTRAL01"
SECURITY=DM_PW
.
.
.
*DM_REMOTE# <remote domain access name> <domain type> <domain id>
# [<ACL policy>] [<connection principal name>]
# [<local principal name>]...
b01 TYPE=TDOMAIN
ACCESSPOINTID="BA.BANK01"
ACL_POLICY=GLOBAL
CONNECTION_PRINCIPAL_NAME="BA.BANK01"
LOCAL_PRINCIPAL_NAME="BA.BANK01.BOB"
As the administrator, you use the following configuration parameter to set and control the credential policy between ATMI applications running BEA Tuxedo release 8.0 or later software.
Authorization enforces limitations on user access to resources or facilities within an ATMI application in accordance with application-specific rules. Only when users are authenticated to join an ATMI application does authorization go into effect.
The procedures for administering authorization depend upon the underlying authorization system of the ATMI application. For procedures to administer a custom authorization system, see the documentation for that system. For procedures to administer the default authorization system, see Administering Default Authentication and Authorization.
Link-level encryption establishes data privacy for messages moving over the network links that connect the machines in an ATMI application. There are three levels of link-level encryption (LLE) security: 0-bit (no encryption), 56-bit (International), and 128-bit (United States and Canada). The International LLE version allows 0-bit and 56-bit encryption. The United States and Canada LLE version allows 0, 56, and 128-bit encryption.
LLE applies to the following types of ATMI links:
tmboot) to tlistenBefore you can configure LLE for your ATMI application, you need to be familiar with the LLE notation: (min, max). The defaults for these parameters are:
min: 0max: Number of bits that indicates the highest level of encryption possible for the installed LLE versionFor example, the default min and max values for the United States and Canada LLE version are (0, 128). If you want to change the defaults, you can do so by assigning new values to min and max in the UBBCONFIG file for your application.
For more information, see How LLE Works and Encryption Key Size Negotiation.
You can verify the LLE version installed on a machine by running the tmadmin command in verbose mode.
tmadmin -v
Key lines from the local BEA Tuxedo lic.txt file will appear on your computer screen, similar to the sample display shown below. The sample entry STRENGTH=128 indicates a United States and Canada LLE version.
[BEA Tuxedo] VERSION=9.1
[LINK ENCRYPTION] VERSION=9.1
STRENGTH=128
.
.
.
All BEA Tuxedo licenses are in the $TUXDIR/udataobj/lic.txt file on a UNIX host machine, or in the %TUXDIR%\udataobj\lic.txt file on a Windows 2003 host machine.
If Workstation clients are included in an application, the administrator must configure one or more workstation listeners (WSLs) to listen for connection requests from Workstation clients. Each WSL uses one or more associated workstation handlers (WSHs) to handle the Workstation client workload. Each WSH can manage multiple Workstation clients by multiplexing all requests and replies with a particular Workstation client over a single connection.
As the administrator, you enable Workstation client access to the ATMI application by specifying a WSL server in the SERVERS section of the application's UBBCONFIG file. You need to specify the -z and -Z command-line options for the WSL server if you want to override the defaults for the LLE min and max parameters. (See Understanding min and max Values for details.) Of course, link-level encryption is possible only if LLE is installed on both the local machine and the Workstation client.
Note: At the Workstation client end of a network connection, you use environment variables TMMINENCRYPTBITS and TMMAXENCRYPTBITS to override the defaults for the LLE min and max parameters.
To configure LLE on Workstation client links, follow these steps.
MASTER machine and that the application is inactive.*SERVERS
WSL SRVGRP="group_name" SRVID=server_number...
CLOPT="-A -- -zmin-Zmax..."
tmloadcf command parses UBBCONFIG and loads the binary TUXCONFIG file to the location referenced by the TUXCONFIG variable.In the preceding example, when tmboot(1) starts the ATMI application, it passes the "-A -- -z min -Z max" command-line options to the WSL server. When establishing a network link between a Workstation client and the WSH, the Workstation client and WSL negotiate the key size until they agree on the largest key size supported by both.
See WSL(5), WS_MIB(5), and UBBCONFIG(5) in the BEA Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference for additional information.
The BEA Tuxedo system architecture optimizes network communications by establishing a multiplexed channel among the machines in a multiple-machine application. BEA Tuxedo messages flow in both directions over this channel, and the message traffic is managed by a specialized ATMI server known as a Bridge server.
As the administrator, you place an entry in the NETWORK section of the UBBCONFIG file for each machine in an ATMI application on which a Bridge server resides. You need to specify the MINENCRYPTBITS and MAXENCRYPTBITS optional run-time parameters for the Bridge server if you want to override the defaults for the LLE min and max parameters. (See Understanding min and max Values for details.) Of course, Bridge-to-Bridge link-level encryption is possible only if LLE is installed on the machines where the Bridge servers reside.
To configure LLE on Bridge links, follow these steps.
MASTER machine and that the application is inactive.*NETWORK
LMID NADDR="bridge_network_address" BRIDGE="bridge_device"
NLSADDR="listen_network_address"
MINENCRYPTBITS=min
MAXENCRYPTBITS=max
LMID is the logical machine where the Bridge server resides; it has direct access to the network device specified in the BRIDGE parameter.
tmloadcf command parses UBBCONFIG and loads the binary TUXCONFIG file to the location referenced by the TUXCONFIG variable.In the preceding example, when tmboot(1) starts the ATMI application, the Bridge server reads the TUXCONFIG file to access various parameters, including MINENCRYPTBITS and MAXENCRYPTBITS. When establishing a network link with a remote Bridge server, the local and remote Bridge servers negotiate the key size until they agree on the largest key size supported by both.
See TM_MIB(5) and UBBCONFIG(5) in the BEA Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference for additional information.
tlisten(1) is a network-independent listener process that provides connections between nodes of a multiple-machine application, on which administrative utilities such as tmboot(1) can run. The application administrator installs tlisten on all machines defined in the NETWORK section of the UBBCONFIG file.
To configure LLE on tlisten links, follow the steps given in the previous topic, How to Configure LLE on Bridge Links. If you so desire, you can start a separate instance of tlisten on the local machine by entering a command such as:
tlisten -lnlsaddr[-zmin-Zmax]
The nlsaddr value must be the same as that specified for the NLSADDR parameter for this machine in the NETWORK section of the UBBCONFIG file. See tlisten(1) in the BEA Tuxedo Command Reference, and TM_MIB(5) and UBBCONFIG(5) in the BEA Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference for additional information.
A domain gateway is a GWTDOMAIN process that relays service requests and service replies between two or more ATMI applications. It provides interoperability through a specially designed transaction processing (TP) protocol that flows over network transport protocols such as TCP/IP.
A domain gateway belongs to a domain gateway group, for which a Domains configuration file is required. A domain gateway group represents a local domain access point that communicates with one or more remote domain access points. Like the application configuration files, UBBCONFIG and TUXCONFIG, a Domains configuration file is created in text format and then converted to binary format. The text and binary files are referred to as DMCONFIG and BDMCONFIG, respectively. The DMCONFIG and BDMCONFIG files, and the environment variables associated with them, are described on reference page DMCONFIG(5) in BEA Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference.
As the administrator, you must place an entry in the DM_TDOMAIN section of the DMCONFIG file for each:
You need to specify the MINENCRYPTBITS and MAXENCRYPTBITS optional run-time parameters for each domain access point and TDomain session for which you want to override the defaults for the LLE min and max parameters. (See Understanding min and max Values for details.) Of course, domain-to-domain link-level encryption is possible only if LLE is installed on the machines where the domains reside.
To configure LLE on domain gateway links, follow these steps.
MASTER machine and that the ATMI application is inactive.*DM_TDOMAIN# Local network addressesLDOMNWADDR="local_domain_network_address"
NWDEVICE="local_domain_device"
MINENCRYPTBITS=minMAXENCRYPTBITS=max.
.
.
# Remote network addressesRDOMNWADDR="remote_domain_network_address"
NWDEVICE="remote_domain_device"
MINENCRYPTBITS=minMAXENCRYPTBITS=max.
.
.
# TDomain network addressesRDOMNWADDR="remote_domain_network_address"
NWDEVICE="remote_domain_device"CONNECTION_POLICY=ON_STARTLACCESSPOINT="local_domain_access_point_identifier"FAILOVERSEQ=100MINENCRYPTBITS=minMAXENCRYPTBITS=max
LDOMis replaced with a local domain access point identifier, andRDOMis replaced with a remote domain access point identifier.
dmloadcf command parses DMCONFIG and loads the binary BDMCONFIG file to the location referenced by the BDMCONFIG variable.In the preceding example, when tmboot(1) starts the ATMI application, each domain gateway reads the BDMCONFIG file to access various parameters, including MINENCRYPTBITS and MAXENCRYPTBITS, and propagates those parameters to its local and remote domains. When the local domain is establishing a network link with a remote domain, the two domains negotiate the key size until they agree on the largest key size supported by both.
See DMCONFIG(5) in BEA Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference for additional information. Also, see Setting Up Security in a Domains Configuration on page 2-41" in Using the BEA Tuxedo Domains Component.
The most effective way to make a distributed ATMI application secure is to combine link-level encryption with public key encryption. Public key encryption is the framework on which public key security is built.
Public key security allows you to incorporate message-based digital signatures and message-based encryption into your ATMI applications. Together, these capabilities provide data integrity and privacy, which are especially important when an ATMI application interacts with other ATMI applications or Workstation clients from outside the company.
Application administrators and developers need to choose a Certification Authority to provide public-private key pairs and the digital certificates associated with them. Then they must decide how to assign the key pairs to the ATMI application. There are many options for assigning key pairs. An administrator can assign one or more of the following:
Application administrators and developers are responsible for choosing a method of assigning key pairs and assigning them. Once key pairs are assigned, however, no more administrative work is required; the plug-ins for public key security distribute and manage the keys.
As the administrator, you use the following configuration parameters to set the digital signature policy for your ATMI application.
SIGNATURE_AHEAD is specified at the domain-wide level of the configuration hierarchy, meaning that the value you assign to it applies to all processes running in the ATMI application. Domain-wide parameters are set in the RESOURCES section in the UBBCONFIG file, and the T_DOMAIN class in the TM_MIB.
The SIGNATURE_AHEAD parameter establishes the maximum permissible time difference between (1) the timestamp attached to the incoming message buffer and (2) the current time shown on the verifying system's local clock. The minimum value is 1 second; the maximum, 2147483647 seconds. The default is 3600 seconds (one hour).
If the attached timestamp shows a time too far into the future, the signature is considered invalid. This parameter is useful for rejecting signatures that are postdated, while allowing a certain amount of leeway for unsynchronized local clocks.
*RESOURCESSIGNATURE_AHEAD2400
SIGNATURE_BEHIND is specified at the domain-wide level of the configuration hierarchy, meaning that the value you assign to it applies to all processes running in the ATMI application. Domain-wide parameters are set in the RESOURCES section in the UBBCONFIG file, and the T_DOMAIN class in the TM_MIB.
The SIGNATURE_BEHIND parameter establishes the maximum permissible time difference between (1) the current time shown on the verifying system's local clock and (2) the timestamp attached to the incoming message buffer. The minimum value is 1 second; the maximum, 2147483647 seconds. The default is 604800 seconds (one week).
If the attached timestamp shows a time too far into the past, the signature is considered invalid. This parameter is useful for resisting replay attacks, in which a valid signed buffer is injected into the system a second time. However, in a system with asynchronous communication—for example, in a system in which disk-based queues are used—buffers signed a long time ago may still be considered valid. So, in a system with asynchronous communication, you may want to increase the SIGNATURE_BEHIND setting.
*RESOURCESSIGNATURE_BEHIND300000
SIGNATURE_REQUIRED may be specified any of the following four levels in the configuration hierarchy:
RESOURCES section in UBBCONFIG or T_DOMAIN class in TM_MIBMACHINES section in UBBCONFIG or T_MACHINE class in TM_MIBGROUPS section in UBBCONFIG or T_GROUP class in TM_MIBSERVICES section in UBBCONFIG or T_SERVICE class in TM_MIBSetting SIGNATURE_REQUIRED to Y (yes) at a particular level means that signatures are required for all processes running at that level or below. For example, setting SIGNATURE_REQUIRED to Y for a machine named mach1 means that all processes running on mach1 will accept only incoming messages that are digitally signed.
RESOURCES section or T_DOMAIN class), this parameter covers all application services advertised within the domain, including those advertised by gateway processes. The default is N.MACHINES section or T_MACHINE class), this parameter covers all application services advertised on a particular machine, including those advertised by gateway processes. The default is N.GROUPS section or T_GROUP class), this parameter covers all application services advertised by a particular group, including those advertised by gateway processes. The default is N.SERVICES section T_SERVICE class), this parameter covers all instances of a particular service advertised within the domain, including those advertised by gateway processes. The default is N.You may specify both SIGNATURE_REQUIRED=Y and ENCRYPTION_REQUIRED=Y together at the domain-wide level, machine level, group level, or service level. See Enforcing the Encryption Policy for Incoming Messages for a description of ENCRYPTION_REQUIRED.
The enforcement policy for SIGNATURE_REQUIRED applies only to application services, application events, and application enqueue requests. It does not apply to system-generated service invocations and system event postings.
To configure SIGNATURE_REQUIRED for a machine named mach1, follow these steps.
MASTER machine and that the ATMI application is inactive.*MACHINES
mach1 LMID="machine_logical_name"
TUXCONFIG="absolute_path_name_to_tuxconfig_file"
TUXDIR="absolute_path_name_to_BEA_Tuxedo_directory"
APPDIR="absolute_path_name_to_application_directory"
SIGNATURE_REQUIRED=Y
tmloadcf command parses UBBCONFIG and loads the binary TUXCONFIG file to the location referenced by the TUXCONFIG variable.In the preceding example, when tmboot(1) starts the ATMI application, it passes the SIGNATURE_REQUIRED=Y parameter to the machine named mach1. At that point, all application services advertised by mach1, including those advertised by gateway processes, are allowed to accept only messages that include valid digital signatures. If a process controlled by mach1 receives a message that does not include a valid digital signature, the system takes the following actions:
WARN)Note: A NULL (empty) buffer cannot be digitally signed, meaning that the system rejects any NULL buffer received by a process requiring digital signatures, in the manner stated in the preceding bullet list.
When digital signatures are attached to a posted message buffer, these signatures are preserved and forwarded along with the message buffer to subscribers for the relevant event.
If the TMUSREVT(5) system server is running in a domain, machine, or server group that requires digital signatures, it rejects any incoming posting without a TPSIGN_OK composite signature status—see Understanding the Composite Signature Status.
Possible subscription notification actions that the TMUSREVT server might take include invoking a service or enqueuing a message. If the target service or queue requires a valid digital signature, but one is not attached to the posted message, the subscription notification action fails.
System events (events that are posted by the system itself and processed by the TMSYSEVT server) may be digitally signed. The administrative policies regarding digital signature do not apply to the TMSYSEVT(5) server.
When digital signatures are attached to a queued buffer, the signatures are preserved in the queue and forwarded to the dequeuing process. Also, if a message is processed by TMQFORWARD(5) to invoke a service, signatures are preserved.
If the TMQUEUE(5) system server is running in a domain, machine, or server group that requires digital signatures, it rejects any incoming enqueue request without a TPSIGN_OK composite signature status—see Understanding the Composite Signature Status. In addition, the TMQUEUE server requires a digital signature if such a policy is in effect for the service name associated with the queue space.
If the workstation handler (WSH) is running in a domain, machine, or server group that requires digital signatures, it rejects any incoming message buffer containing application data without a TPSIGN_OK composite signature status—see Understanding the Composite Signature Status.
As the administrator, you use the following configuration parameter to set the encryption policy for your ATMI application.