Understanding Security Between the BEA TOP END and BEA Tuxedo Systems

This topic includes the following sections:

• Overview of BEA TOP END Security

• Overview of BEA Tuxedo Security

• How Security Is Handled by the TEDG

• How the TEDG Establishes a Secure Connection to the NI

• How BEA Tuxedo to BEA TOP END Security Works

• How BEA TOP END to BEA Tuxedo Security Works

See Also

• Configuring Security Between BEA TOP END and BEA Tuxedo Systems

 

---

Overview of BEA TOP END Security

Enabling BEA TOP END security means that the BEA TOP END system performs user authentication, user authorization, and node authentication at startup and whenever messages are sent or received. These features cannot be enabled individually. The security realm for a BEA TOP END application is the BEA TOP END system. All nodes in a system must have identical security configurations. When two nodes attempt to connect, the security configuration is checked on both nodes. If security is not configured identically on the two nodes, the connection is refused. When security is enabled, BEA TOP END Node Managers (NM) authenticate each other as part of the connection process.

For the TEDG, BEA TOP END security is enabled by the SECURITY parameter in the DM_LOCAL_DOMAINS section of the DMCONFIG file, and the nm_config file on the BEA TOP END node.

Authentication and Authorization

If BEA TOP END security is enabled, then all clients are authenticated by tp_client_signon(3T) and all subsequent requests for service are checked for authorization. Authentication and authorization work together; they cannot be separated. Authorization is performed on a product and function basis.

Message Protection/Encryption

If BEA TOP END security is enabled, then messages between NIs may be sent in one of the following ways:

• clear text (CLEAR)

• protected by checksum (SAFE)

• encrypted (PRIVATE)

Kerberos 4 is used to protect internode messages. The same message protection level is required for all connections within the BEA TOP END system. However, a separate key is created for each connection as part of the connection process. This feature is supplied by the BEA TOP END system; it cannot be replaced by the customer.

 

---

Overview of BEA Tuxedo Security

A BEA Tuxedo domain may be configured with several levels of security. For details about the various levels of security available for BEA Tuxedo Application-to-Transaction Monitor Interface (ATMI) applications, see UBBCONFIG(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference.

Authentication/Authorization

You can authenticate a client in either of two ways. You can:

• Define an application-wide password (APP_PW)

• Specify individual client authentication (USER_AUTH)

The BEA Tuxedo system provides proprietary authentication and authorization services. Authentication is based on a user ID and password for each user. Authorization is based on Access Control Lists (ACLs), which specify the users entitled to access particular resources (services, queues, and events).When a user requests use of a resource, the system searches for an ACL for that resource. If an ACL is found, the system checks it to determine whether the user is authorized to use the resource. The strongest level of security requires explicit authorization (MANDATORY_ACL) for access to any service, queue, or event.

Optional Encryption

Optional encryption can be configured to protect data between nodes. Unlike BEA TOP END encryption, BEA Tuxedo encryption can be enabled without user authentication and authorization.

Public Key Encryption

There are two types of public key encryption used in BEA Tuxedo ATMI applications: message-based encryption and message-based digital signature. Both build on the technology and key management of public/private key encryption algorithms.

Both message-based encryption and message-based digital signatures for application messages are supported between the BEA Tuxedo application and the TEDG but do not apply to messages between the TEDG and BEA TOP END systems.

System Interoperability

The BEA Tuxedo system allows domains to interoperate through domain gateways. Because domains are configured independently, any two domains do not need to have the same security configurations. Gateways provide configuration options that allow administrators to control the level of interoperability between any two domains.

Interdomain Security

Four levels of security are provided by a domain gateway, as specified in the DMCONFIG file:

• Gateways can be configured to limit the set of local services made available to remote domains

• Access to specific services can be limited to select remote domains

• Gateways can be configured to require authentication when attempts are made to connect to remote domains

• Links between domains may be encrypted

See Also

• "Introducing ATMI Security" on page 1-1 in Using Security in CORBA Applications

 

---

How Security Is Handled by the TEDG

The TEDG handles security in a manner similar to how the BEA Tuxedo TDomain handles security.

• The local BEA Tuxedo domain or BEA TOP END system controls access for local clients. Clients log in once to their respective systems, and are authenticated and authorized according to the local policy.

• The TEDG allows an administrator to control access to BEA TOP END services by BEA Tuxedo clients. Similarly, the administrator can control access to BEA Tuxedo services from the BEA TOP END system.

• Requests passing through the gateway are performed using the credentials of the gateway. This practice eliminates the need to maintain duplicate security databases on both the BEA Tuxedo and BEA TOP END systems.

• Mutual authentication of the BEA TOP END and TEDG nodes and encryption of messages between nodes is optional. These capabilities, based on the BEA TOP END security algorithms, use the BEA TOP END security package.

The following illustration shows how security works between BEA Tuxedo and BEA TOP END systems. For more detailed information, see:

• How BEA Tuxedo to BEA TOP END Security Works

• How BEA TOP END to BEA Tuxedo Security Works

  Figure 3-1 TEDG to BEA TOP END Security

  
   

 

---

How BEA Tuxedo to BEA TOP END Security Works

Clients are authenticated and authorized by the BEA Tuxedo system on the basis of how the local domain is configured in the UBBCONFIG(5) file. If BEA TOP END security is enabled, an additional security check can be done on the BEA TOP END node.

BEA Tuxedo-side Security

Clients are authenticated by the BEA Tuxedo system in the same way as any other BEA Tuxedo client, via user ID and password. Clients are authorized through a standard BEA Tuxedo authorization scheme characterized by the following:

• The TEDG advertises the SERVICE and QSPACE entries listed in the DM_REMOTE_SERVICES section of the DMCONFIG file as services to the local BEA Tuxedo domain. BEA TOP END services not placed in the DMCONFIG file are not accessible by BEA Tuxedo clients.

• Access to services advertised by the TEDG is controlled by the local BEA Tuxedo domain configuration. The level of authorization control is determined by the value of the SECURITY parameter in the UBBCONFIG file for the domain. A value of ACL or MANDATORY_ACL indicates that the BEA Tuxedo system should perform access control checks. A BEA Tuxedo administrator can create ACLs for imported BEA TOP END services.

If the BEA Tuxedo-side security is successful, the TEDG prepares to send the message to the BEA TOP END system. At this point, BEA TOP END security takes over.

BEA TOP END-side Security

If BEA TOP END security is enabled, the TEDG inserts a user ID into all messages passed to the BEA TOP END system. To enqueue requests, the TEDG provides both a user ID and password in each message. The password is protected using the current BEA TOP END algorithm used by RTQ.

The TEDG uses a single set of credentials for all messages passed to the BEA TOP END system:

• The TEDG TOP END user ID (the DOMAINID in the DM_LOCAL_DOMAINS section of the DMCONFIG file)

• A password established through the topendpasswd command in the dmadmin(1) utility

The password is stored in the BDMCONFIG file in an encrypted format. The administrator defines a matching user ID and password in the BEA TOP END security database using the BEA TOP END tpsecure(1T) utility.

If BEA TOP END security is enabled, BEA TOP END message passing requires that messages carry the user ID of the client. Because the user ID is not reauthenticated by the BEA TOP END system, a password is not required; the user ID is provided purely for information. For queuing, the BEA TOP END system requires that both the user ID and password be passed along with the service request. The BEA TOP END system uses these credentials to authenticate the client while processing the queued service request.

The BEA TOP END system does not perform any additional access control checking for message passing requests. However, queued requests are authorized by the BEA TOP END system when they are retrieved by RTQ and the service request is processed. Because all messages from the TEDG are submitted using the TEDG TOP END user ID (that is equal to the local domain DOMAINID), this TEDG user ID must be authorized to perform the requested service. The administrator must create ACLs for the TEDG user ID using the TOP END tpsecure(1T) utility.

See Also

• Configuring Security Between BEA TOP END and BEA Tuxedo Systems

 

---

How BEA TOP END to BEA Tuxedo Security Works

Clients are authenticated and authorized by BEA TOP END, based on the configuration of the BEA TOP END system. If BEA Tuxedo security is enabled, an additional security check can be done on the BEA Tuxedo node.

BEA TOP END-side Security

If BEA TOP END security is enabled, clients are authenticated at signon. The TEDG does not perform client authentication on incoming requests.

The BEA TOP END system performs authorization checks on the client node before a message is sent. If BEA TOP END security is enabled, the client must be granted authorization to access the requested BEA Tuxedo service or queue. The administrator must create ACLs using the BEA TOP END tpsecure(1T) utility for each BEA TOP END user who accesses BEA Tuxedo resources. The BEA TOP END products and functions must match the entries in the DM_LOCAL_SERVICES section of the DMCONFIG file used to map BEA TOP END resources to the BEA Tuxedo system.

BEA Tuxedo-side Security

The TEDG provides the following levels of access control for incoming requests from the BEA TOP END system:

• In the first level of access control, the DM_LOCAL_SERVICES section of the DMCONFIG file lists the BEA Tuxedo SERVICE entries and QSPACE entries that are to be advertised to the BEA TOP END system.

• In the second level of access control, the domain gateway access control feature can be used to limit access to particular services from specific BEA TOP END nodes (or NI connections).

  The administrator can specify an ACL parameter as part of the DM_LOCAL_SERVICES entry for a specific SERVICE or QSPACE entry. The ACL is specified in the DM_ACCESS_CONTROL section of the DMCONFIG file. Each ACL record contains the names of remote domains allowed to access the service. The remote domains are mapped to BEA TOP END NI instances in the DM_REMOTE_DOMAINS section of the configuration file. Using ACL entries is useful for limiting access to advertised services to specific BEA TOP END nodes.

• In the third level of access control, normal BEA Tuxedo authorization may be performed.

  If a request passes TEDG authorization, normal BEA Tuxedo authorization is performed. If ACL or MANDATORY_ACL is specified in the UBBCONFIG(5) file, then the DOMAINID of the remote domain making the request is used as the BEA Tuxedo username. If SECURITY=ACL in the UBBCONFIG and there is an entry in the ACL database for this service, the entry must include the DOMAINID of the RDOM; otherwise, the service or enqueue request fails. If SECURITY=MANDATORY_ACL in the UBBCONFIG, there must be an entry in the ACL database for this service, and the entry must include the DOMAINID of the RDOM; otherwise, the service or enqueue request fails.

See Also

• Understanding Security Between the BEA TOP END and BEA Tuxedo Systems

 

---

How the TEDG Establishes a Secure Connection to the NI

All nodes in a BEA TOP END system must be configured for the same level of message protection. The SECURITY parameter in the DM_LOCAL_DOMAINS section of the DMCONFIG file determines the level of protection configured for the TEDG. Three levels of protection are available: CLEAR, SAFE, and PRIVATE.

• At the lowest level, CLEAR, messages are sent without any protection.

• At the next level, SAFE, a checksum for each message is generated by the Kerberos 4 libraries and is appended to the message.

• At the highest level, PRIVATE, the Kerberos libraries, using the DES algorithm, encrypt each message. An encryption key is automatically established when the TEDG and NI connect.

These SECURITY parameter values correspond to the BEA TOP END Node Manager (NM) configuration parameters [security] and [internode security] as described in nm_config(4T) in BEA TOP END Programmer's Reference Manual.

When started, the TEDG checks the configuration to determine whether security is enabled (that is, to determine whether a value of CLEAR, SAFE, or PRIVATE has been assigned to the SECURITY parameter). If it is enabled, the TEDG needs a Kerberos Ticket Granting Ticket (TGT), just as the BEA TOP END NM does at start of day. To obtain a TGT, the Kerberos database used by the BEA TOP END system must contain an entry (Principal) for the machine on which the TEDG is running. If the TEDG cannot obtain a TGT, the TEDG logs an error and terminates.

The TEDG to NI connection process follows the BEA TOP END sign-on protocol. As part of this protocol, the TEDG and NI exchange security configurations and check to make sure the two configurations match exactly. If the configurations do not match, the TEDG logs an error (see userlog(3c) in BEA Tuxedo ATMI C Function Reference) and refuses the connection. If the configuration matches, the TEDG and the remote BEA TOP END system perform mutual authentication, using the protocol for the BEA TOP END Node Manager. If SECURITY is set to either SAFE or PRIVATE in the DMCONFIG file, the TEDG obtains an encryption key as part of the authentication process.

Encryption of messages between BEA TOP END and BEA Tuxedo systems is based on the BEA TOP END internode message security used between NIs. Internode message security is based, in turn, on the Kerberos 4.9 application libraries.

Note: To use BEA TOP END internode security, you must have the BEA TOP END Security Services Product installed on the same machine as the TEDG.

See Also

• Configuring Security Between BEA TOP END and BEA Tuxedo Systems