• Security refers to techniques for ensuring that data stored in a computer or passed between computers is not compromised. Most security measures involve passwords and data encryption, where a password is a secret word or phrase that gives a user access to a particular program or system, and data encryption is the translation of data into a form that is unintelligible without a deciphering mechanism.As shown in Figure 1‑1, all but one of the security capabilities available with the ATMI environment of the Oracle Tuxedo product are implemented through a plug-in interface, which allows Oracle Tuxedo customers to independently define and dynamically add their own security plug-ins. A security plug-in is a code module that implements a particular security capability.The Oracle Tuxedo system can enforce security in a number of ways, which includes using the security features of the host operating system to control access to files, directories, and system resources. Table 1‑1 describes the security capabilities available with the ATMI environment of the Oracle Tuxedo product.
Table 1‑1 ATMI Security Capabilities The default authentication plug-in provides security at three levels: no authentication, application password, and user-level authentication. This plug-in works the same way the Oracle Tuxedo implementation of authentication has worked since it was first made available with the Oracle Tuxedo system. The default authorization plug-in provides security at two levels: optional access control lists and mandatory access control lists. This plug-in works the same way the Oracle Tuxedo implementation of authorization has worked since it was first made available with the Oracle Tuxedo system. Uses public key (or asymmetric key) encryption to establish end-to-end digital signing and data privacy between ATMI application clients and servers. Complies with the PKCS-7 standard.
• RSA public key algorithm
• Client programs are run directly by users with the users’ own permissions. In addition, users running native clients (that is, clients running on the same machine on which the server program is running) have access to the UBBCONFIG configuration file and interprocess communication (IPC) mechanisms such as the bulletin board (a reserved piece of shared memory in which parameters governing the ATMI application and statistics about the application are stored).For ATMI applications running on platforms that support greater security, a more secure approach is to limit access to the files and IPC mechanisms to the application administrator and to have “trusted” client programs run with the permissions of the administrator (using the setuid command on a UNIX host machine or the equivalent command on another platform). For the most secure operating system security, allow only Workstation clients to access the application; client programs should not be allowed to run on the same machines on which application server and administrative programs run.
• “About the Configuration File” and “Creating the Configuration File” in Setting Up an Oracle Tuxedo Application
• UBBCONFIG(5) in the Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes ReferenceAuthentication allows communicating processes to mutually prove identification. The authentication plug-in interface in the ATMI environment of the Oracle Tuxedo product can accommodate various security-provider authentication plug-ins using various authentication technologies, including shared-secret password, one-time password, challenge-response, and Kerberos. The interface closely follows the generic security service (GSS) application programming interface (API) where applicable; the GSSAPI is a published standard of the Internet Engineering Task Force. The authentication plug-in interface is designed to make integration of third-party vendor security products with the Oracle Tuxedo system as easy as possible, assuming the security products have been written to the GSSAPI.Direct end-to-end mutual authentication in a distributed enterprise middleware environment such as the Oracle Tuxedo system can be prohibitively expensive, especially when accomplished with security mechanisms optimized for long-duration connections. It is not efficient for clients to establish direct network connections with each server process, nor is it practical to exchange and verify multiple authentication messages as part of processing each service request. Instead, the ATMI applications use a delegated trust authentication model, as shown in Figure 1‑2.Figure 1‑2 ATMI Delegated Trust Authentication ModelA Workstation client authenticates to a trusted system gateway process, the workstation handler (WSH), at initialization time. A native client authenticates within itself, as explained later in this discussion. After a successful authentication, the authentication software assigns a security token to the client. A token is an opaque data structure suitable for transfer between processes. The WSH safely stores the token for the authenticated Workstation client, or the authenticated native client safely stores the token for itself.Figure 1‑3 shows the control flow inside the ATMI environment of the Oracle Tuxedo system while a session is being established between a Workstation client and the WSH. The Workstation client and WSH are attempting to establish a long-term mutually authenticated connection by exchanging messages.Figure 1‑3 Client-WSH AuthenticationThe initiator process (may be thought of as a middleware client process) creates a session context by repeatedly calling the Oracle Tuxedo “initiate security context” function until a return code indicates success or failure. A session context associates identity information with an authenticated user.When a Workstation client calls tpinit(3c) for C or TPINITIALIZE(3cbl) for COBOL to join an ATMI application, the Oracle Tuxedo system begins its response by first calling the internal “acquire credentials” function to obtain a session credential handle, and then calling the internal “initiate security context” function to obtain a session context. Each invocation of the “initiate security context” function takes an input session token (when one is available) and returns an output session token. A session token carries a protocol for verifying a user’s identity. The initiator process passes the output session token to the session’s target process (WSH), where it is exchanged for another input token. The exchange of tokens continues until both processes have completed mutual authentication.After a successful authentication, the trusted gateway calls two Oracle Tuxedo internal functions that retrieve an authorization token and an auditing token for the client, which the gateway stores for safekeeping. Together, these tokens represent the user identity of a security context. The term security token refers collectively to the authorization and auditing tokens.
• Principal name—the name of an authenticated user.
• Application key—a 32-bit value that uniquely identifies the client initiating the request message. See “Application Key” on page 1‑48 for more detail.In addition, when default authentication is used, the auditing token carries the same two pieces of information: principal name and application key.As shown in Figure 1‑4, there are situations where a client service request forwarded by a server takes on the identity of the server. The server replaces the client tokens attached to the request with its own tokens and then forwards the service request to the destination service.Figure 1‑4 Server Permission Upgrade Example
Note: See “Specifying Principal Names” on page 2‑11 for an understanding of how servers acquire their own authorization and auditing tokens and why they need them.The feature demonstrated in the preceding figure is known as server permission upgrade, which operates in the following manner: whenever a server calls a dot service (a system-supplied service having a beginning period in its name—such as .TMIB), the service request takes on the identity of the server and thus acquires the access permissions of the server. A server’s access permissions are those of the application (system) administrator. Thus, certain requests that would be denied if the client called the dot service directly would be allowed if the client sent the requests to a server, and the server forwarded the requests to the dot service. For more information about dot services, see the .TMIB service description on the MIB(5) reference page in the Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference.You can provide authentication for your ATMI application by using the default plug-in or a custom plug-in. You choose a plug-in by configuring the Oracle Tuxedo registry, a tool that controls all security plug-ins.If you want to use the default authentication plug-in, you do not need to configure the registry. If you want to use a custom authentication plug-in, however, you must configure the registry for your plug-in before you can install it. For more detail about the registry, see “Setting the Oracle Tuxedo Registry” on page 2‑4.Authorization allows administrators to control access to ATMI applications. Specifically, an administrator can use authorization to allow or disallow principals (authenticated users) to use resources or facilities in an ATMI application.A fanout is an umbrella plug-in to which individual plug-in implementations are connected. As shown in Figure 1‑5, the authorization plug-in interface is implemented as a fanout.Figure 1‑5 Authorization Plug-in ArchitectureThe purpose of an authorization request is to determine whether a client operation should be allowed or whether the results of an operation should be kept unchanged. Each authorization plug-in returns one of three responses: permit, deny, or abstain. The abstain response gives writers of authorization plug-ins a graceful way to handle situations that are not accommodated by the original plug-in, such as names of operations that are added to the system after the plug-in is installed.The authorization fanout plug-in forms a composite response as described in Table 1‑2. For default authorization, the composite response is determined solely by the default authorization plug-in.
Table 1‑2 Authorization Composite Responses At least one deny All abstain permit
If the SECURITY parameter is not set in the ATMI application’s UBBCONFIG file or is set to any value other than MANDATORY_ACLAs an example of custom authorization, consider a banking application in which a user is identified as a member of the Customer group, and the following conditions are in effect:
• The default authorization plug-in allows any user in the Customer group to withdraw money from a particular account.
• A custom authorization plug-in allows any user in the Customer group to withdraw money from a particular account but only on Monday through Friday between 9:00 A.M. and 5:00 P.M.
• A second custom authorization plug-in allows any user in the Customer group to withdraw money from a particular account but only if the amount being withdrawn is less than $10,000.So, if a user in the Customer group attempts to withdraw $500.00 on Monday at 10 A.M., the operation is allowed. If the same user attempts the same withdrawal on Saturday morning, the operation is not allowed.Authorization decisions are based partly on user identity, which is stored in an authorization token. Because authorization tokens are generated by the authentication security plug-in, providers of authentication and authorization plug-ins need to ensure that these plug-ins work together.An Oracle Tuxedo system process or server (such as /Q server TMQUEUE(5) or EventBroker server TMUSREVT(5)) calls the authorization plug-in when it receives a client request. In response, the authorization plug-in performs a pre-operation check and returns whether the operation should be allowed.The authorization fanout plug-in receives a decision (permit or deny) from the default authorization plug-in and operates on its behalf.
• If the decision is to permit the client operation, the fanout plug-in returns permit to the calling process. The system carries out the client request.
• If the decision is to deny the operation, the fanout plug-in returns deny to the calling process. The system does not carry out the client request.The authorization fanout plug-in makes the ultimate decision by checking the individual responses (permit, deny, abstain) of its subordinate plug-ins.
• If the fanout plug-in allows the client operation, it returns permit to the calling process. The system carries out the client request.
• If the fanout plug-in does not allow the operation, it returns deny to the calling process. The system does not carry out the client request.The authorization fanout plug-in makes the ultimate decision by checking the individual responses (permit, deny, abstain) of its subordinate plug-ins.
• If the fanout plug-in decides that the operation results are acceptable, it returns permit to the calling process. The system accepts the operation results.
• If the fanout plug-in does not allow the operation, it returns deny to the calling process. The system either modifies the operation results or rolls back (reverses) the operation.A post-operation check is useful for label-based security models. For example, suppose that a user is authorized to access CONFIDENTIAL documents but performs an operation that retrieves a TOP SECRET document. (Often, a document’s classification label is not easily determined until after the document has been retrieved.) In this case, the post-operation check is an efficient means to either deny the operation or modify the output data by expunging any restricted information.You can provide authorization for your ATMI application by using the default plug-in or adding one or more custom plug-ins. You choose a plug-in by configuring the Oracle Tuxedo registry, a tool that controls all security plug-ins.If you want to use the default authorization plug-in, you do not need to configure the registry. If you want to add one or more custom authorization plug-ins, however, you must configure the registry for your additional plug-ins before you can install them. For more detail about the registry, see “Setting the Oracle Tuxedo Registry” on page 2‑4.A fanout is an umbrella plug-in to which individual plug-in implementations are connected. As shown in Figure 1‑6, the auditing plug-in interface is implemented as a fanout.Figure 1‑6 Auditing Plug-in ArchitectureThe purpose of an auditing request is to record an event. Each auditing plug-in returns one of two responses: success (the audit succeeded—logged the event) or failure (the audit failed—did not log the event). The auditing fanout plug-in forms a composite response in the following manner: if all responses are success, the composite response is success; otherwise, the composite response is failure.For default auditing, the composite response is determined solely by the default auditing plug-in. For custom auditing, the composite response is determined by the fanout plug-in after collecting the responses of the subordinate plug-ins. For more insight into how fanouts work, see “Authorization Plug-in Architecture” on page 1‑12.Auditing decisions are based partly on user identity, which is stored in an auditing token. Because auditing tokens are generated by the authentication security plug-in, providers of authentication and auditing plug-ins need to ensure that these plug-ins work together.An ATMI system process or server (such as /Q server TMQUEUE(5) or EventBroker server TMUSREVT(5)) calls the auditing plug-in when it receives a client request. Because it is called before an operation begins, the auditing plug-in can audit operation attempts and store data if that data will be needed later for a post-operation audit. In response, the auditing plug-in performs a pre-operation audit and returns whether the audit succeeded.In addition, an ATMI system process or server may call the auditing plug-in when a potential security violation occurs. (Suspicion of a security violation arises when a pre-operation or post-operation authorization check fails, or when an attack on security is detected.) In response, the auditing performs a post-operation audit and returns whether the audit succeeded.The default auditing implementation consists of the Oracle Tuxedo EventBroker component and userlog (ULOG). These utilities report only security violations; they do not report which operations were attempted, which ones failed, and which ones successfully completed.The auditing fanout plug-in receives a decision (success or failure) from the default auditing plug-in and operates on its behalf.
• If the decision is success, the post-operation audit succeeded. The auditing fanout plug-in returns success to the calling process and logs the security violation.
• If the decision is failure, the post-operation audit failed. The auditing fanout returns failure to the calling process.The auditing fanout plug-in makes the ultimate decision by checking the individual responses (success or failure) from its subordinate plug-ins.
• If the composite decision is success, the pre-operation audit succeeded. The auditing fanout plug-in returns success to the calling process and logs the client’s attempt to perform the operation.
• If the composite decision is failure, the pre-operation audit failed. The auditing fanout returns failure to the calling process.The auditing fanout plug-in decides if the post-operation audit succeeded or failed by checking the individual responses (success or failure) from its subordinate plug-ins.
• If the composite decision is success, the post-operation audit succeeded. The auditing fanout plug-in returns success to the calling process and logs the completion status of the operation.
• If the composite decision is failure, the post-operation audit failed. The auditing fanout returns failure to the calling process.You can provide auditing for your ATMI application by using the default plug-in or adding one or more custom plug-ins. You choose a plug-in by configuring the Oracle Tuxedo registry, a tool that controls all security plug-ins.If you want to use the default auditing plug-in, you do not need to configure the registry. If you want to add one or more custom auditing plug-ins, however, you must configure the registry for your additional plug-ins before you can install them. For more detail about the registry, see “Setting the Oracle Tuxedo Registry” on page 2‑4.
•
• An initiator process begins the communication session.
• A target process receives the initial connection.The first configuration parameter is the minimum encryption level that a process will accept. It is expressed as a key length: 0, 56, or 128 bits.The second configuration parameter is the maximum encryption level a process can support. It also is expressed as a key length: 0, 56, or 128 bits.For convenience, the two parameters are denoted as (min, max) in the discussion that follows. For example, the values “(56, 128)” for a process mean that the process accepts at least 56-bit encryption but can support up to 128-bit encryption.
1.
• If the configured min-max values accommodate the default min-max values, then the local software assigns those values as the min-max values for the process.
• If one of the min-max values is not configured, then the default value will be used for the missing value. For instance (0, max-value-configured) or (min-value-configured, 128) will be used.
• If there are no min-max values specified in the configurations for a particular link type, then the local software assigns 0 as the minimum value and assigns the highest bit-encryption rate possible for the default min-max values as the maximum value, that is, (0, 128) for the LLE.After the min-max values are determined for the two processes, the negotiation of key size begins. The negotiation process need not be encrypted or hidden. Once a key size is agreed upon, it remains in effect for the lifetime of the network connection.Table 1‑3 shows which key size, if any, is agreed upon by two processes when all possible combinations of min-max values are negotiated. The header row holds the min-max values for one process; the far left column holds the min-max values for the other.
Table 1‑3 Interprocess Negotiation Results Table 1‑4 shows which key size, if any, is agreed upon by two ATMI applications when one of them is running under release 6.5 and the other under release 7.1 or later. The header row holds the min-max values for the process running under release 7.1 or later; the far left column holds the min-max values for the process running under release 6.5.
Table 1‑5 shows which key size, if any, is agreed upon by two ATMI applications when one of them is running under pre-release 6.5 and the other under release 7.1 or later. The header row holds the min-max values for the process running under release 7.1 or later; the far left column holds the min-max values for the process running under pre-release 6.5.
If your current Oracle Tuxedo installation is configured for (56, 56), (56, 128), or (128, 128), then your system cannot interoperate with a pre-release 6.5 ATMI application that is configured for a maximum LLE level of 40 bits. Attempts to negotiate a common key size fail.The length of time a Workstation client can take for initialization is limited. By default, this interval is 30 seconds in an ATMI application not using LLE, and 60 seconds in an ATMI application using LLE. The 60-second interval includes the time needed to negotiate an encrypted link. This time limit can be changed when LLE is configured by changing the value of the MAXINITTIME parameter for the workstation listener (WSL) server in the UBBCONFIG file, or the value of the TA_MAXINITTIME attribute in the T_WSL class of the WS_MIB(5).
• “Distributing ATMI Applications Across a Network” and “Creating the Configuration File for a Distributed ATMI Application” in Setting Up an Oracle Tuxedo ApplicationLike LLE, the SSL protocol can be used with password authentication to provide confidentiality and integrity to communication between the client application and the Oracle Tuxedo domain. When using the SSL protocol with password authentication, you are prompted for the password of the Listener/Handler (IIOP, Workstation, or JOLT) defined by the SEC_PRINCIPAL_NAME parameter when you enter the tmloadcf command.
• Figure 1‑7 illustrates how the SSL protocol works.
1.
• If the configured min-max values accommodate the default min-max values, then the local software assigns those values as the min-max values for the process.
• If one of the min-max values is not configured, then the default value will be used for the missing value. For instance (0, max-value-configured) or (min-value-configured, 128) will be used.
• If there are no min-max values specified in the configurations for a particular link type, then the local software assigns 0 as the minimum value and assigns 128 as the maximum value.
• For /WS client, the default MAXENCRYPTBITS is 256; it will be adjusted according to the actual link level security configured.After the min-max values are determined for the two processes, the negotiation of key size begins. The negotiation process need not be encrypted or hidden. Once a key size is agreed upon, it remains in effect for the lifetime of the network connection.Table 1‑6 shows which key size, if any, is agreed upon by two processes when all possible combinations of min-max values are negotiated. The header row holds the min-max values for one process; the far left column holds the min-max values for the other.
The length of time a Workstation client can take for initialization is limited. By default, this interval is 60. The 60-second interval includes the time needed to negotiate an encrypted link. This time limit can be changed when WSL is configured by changing the value of the MAXINITTIME parameter for the workstation listener (WSL) server in the UBBCONFIG file, or the value of the TA_MAXINITTIME attribute in the T_WSL class of the WS_MIB(5).A cipher suite is a SSL encryption method that includes the key exchange algorithm, the symmetric encryption algorithm, and the secure hash algorithm used to protect the integrity of the communication. For example, the cipher suite RSA_WITH_RC4_128_MD5 uses RSA for key exchange, RC4 with a 128-bit key for bulk encryption, and MD5 for message digest.
• “Distributing ATMI Applications Across a Network” and “Creating the Configuration File for a Distributed ATMI Application” on page 10‑1 in Setting Up an Oracle Tuxedo ApplicationPKCS-7 is a hybrid cryptosystem architecture. A symmetric key algorithm with a random session key is used to encrypt a message, and a public key algorithm is used to encrypt the random session key. A random number generator creates a new session key for each communication, which makes it difficult for a would-be attacker to reuse previous communications.Public key (or asymmetric key) algorithms such as RSA are implemented through a pair of different but mathematically related keys:Two-key triple-DES is a 128-bit block cipher run in Encrypt-Decrypt-Encrypt (EDE) mode. Two-key triple-DES provides two 56-bit keys (in effect, a 112-bit key) and is not exportable outside the United States.A block cipher is a type of symmetric key algorithm that transforms a fixed-length block of plaintext (unencrypted text) data into a block of ciphertext (encrypted text) data of the same length. This transformation takes place in accordance with the value of a randomly generated session key. The fixed length is called the block size.Figure 1‑8 shows how end-to-end message-based digital signature works.Figure 1‑8 ATMI PKCS-7 End-to-End Digital SigningMessage-based digital signature involves generating a digital signature by computing a message digest on the message, and then encrypting the message digest with the sender’s private key. The recipient verifies the signature by decrypting the encrypted message digest with the signer’s public key, and then comparing the recovered message digest to an independently computed message digest. The signer’s public key either is contained in a digital certificate included in the signer information, or is referenced by an issuer-distinguished name and issuer-specific serial number that uniquely identify the certificate for the public key.Digital certificates are electronic files used to uniquely identify individuals and resources over networks such as the Internet. A digital certificate securely binds the identity of an individual or resource, as verified by a trusted third party known as a Certification Authority, to a particular public key. Because no two public keys are ever identical, a public key can be used to identify its owner.The recipient of an encrypted message can develop trust in the CA’s private key recursively, if the recipient has a certificate containing the CA’s public key signed by a superior CA whom the recipient already trusts. In this sense, a certificate is a stepping stone in digital trust. Ultimately, it is necessary to trust only the public keys of a small number of top-level CAs. Through a chain of certificates, trust in a large number of users’ signatures can be established.
• Figure 1‑9 shows the PKI process flow.Figure 1‑9 PKI Process FlowFigure 1‑10 shows how end-to-end message-based encryption works.Figure 1‑10 ATMI PKCS-7 End-to-End EncryptionThe certificate lookup interface allows public key software to retrieve X.509v3 certificates for a given principal. Principals are authenticated users. The certificate database may be stored using any appropriate tool, such as Lightweight Directory Access Protocol (LDAP), Microsoft Active Directory, Netware Directory Service (NDS), or local files.The certificate validation interface allows public key software to validate an X.509v3 certificate in accordance with specific business logic. This interface is implemented as a fanout, which allows Oracle Tuxedo customers to use their own business rules to determine the validity of a certificate.You can provide public key security for your ATMI application by using custom plug-ins. You choose a plug-in by configuring the Oracle Tuxedo registry, a tool that controls all security plug-ins.If you want to use custom public key plug-ins, you must configure the registry for your public key plug-ins before you can install them. For more detail about the registry, see “Setting the Oracle Tuxedo Registry” on page 2‑4.
•
•
•
• At the lowest level, no authentication is provided. At the highest level, an access control checking feature determines which users can execute a service, post an event, or enqueue (or dequeue) a message on an application queue. The security levels are briefly described in Table 1‑9.
Note: The term client is synonymous with client process, meaning a specific instance of a client program in execution. An ATMI client program can exist in active memory in any number of individual instances.An application administrator can designate a security level by setting the SECURITY parameter in the UBBCONFIG configuration file to the appropriate value.
The default is NONE. If SECURITY is set to USER_AUTH, ACL, or MANDATORY_ACL, then the application administrator must configure a system-supplied authentication server named AUTHSVR. AUTHSVR performs per-user authentication.An application developer can replace AUTHSVR with an authentication server that has logic specific to the ATMI application. For example, a company may want to develop a custom authentication server so that it can use the popular Kerberos mechanism for authentication.Upon joining an ATMI application, a client process has two names: a combined user-client name and a unique client identifier known as an application key.
• The user-client name consists of a username and a client name and is used for security, administration, and communications.Two client names are reserved for special semantics: tpsysadm and tpsysop. tpsysadm is treated as the application administrator, and tpsysop is treated as the application operator.When an authenticated client joins an ATMI application, it passes a username and client name to tpinit(3c) in a TPINIT buffer if the application is written in C, or to TPINITIALIZE(3cbl) in a TPINFDEF-REC record if the application is written in COBOL. The username and client name, as well as other security-related fields in the TPINIT buffer/ TPINFDEF-REC record, are described in Table 1‑10.
A user name consisting of a string of up to 30 characters. Required for security level USER_AUTH, ACL, or MANDATORY_ACL. The username represents the caller. A client name consisting of a string of up to 30 characters. Required for security level USER_AUTH, ACL, or MANDATORY_ACL. The client name represents the client program. Application password. Required for security level APP_PW, USER_AUTH, ACL, or MANDATORY_ACL. tpinit() or TPINITIALIZE() validates this password by comparing it to the configured application password stored in the TUXCONFIG file.* User-specific data.** Required for security level USER_AUTH, ACL, or MANDATORY_ACL. tpinit() or TPINITIALIZE() forwards the user-specific data to the authentication server for validation. The authentication server is AUTHSVR. * The binary equivalent of the UBBCONFIG file.** Usually a user password.For an authenticated security level (USER_AUTH, ACL, or MANDATORY_ACL), the username, client name, and user-specific data are transferred to AUTHSVR without interpretation by the Oracle Tuxedo system. The only manipulation of this information is its encryption when transmitted over the network from a Workstation client.The assigned application key is the client’s security credential. The client provides its application key with every service invocation as part of the TPSVCINFO structure in the appkey field. (See tpservice(3c) in the Oracle Tuxedo ATMI C Function Reference for more information about TPSVCINFO.)Table 1‑11 shows how the application key is set for various security levels and clients. All application key assignments are hardcoded except the last item in the table.
Table 1‑11 Application Key Assignments NONE or APP_PW Messages from native ATMI clients that call tpinit()/ TPINITIALIZE() with a client name of tpsysadm and are run by the administrator Messages from native ATMI clients that call tpinit()/ TPINITIALIZE() with a client name of tpsysop and are run by the administrator Messages from native ATMI clients that call tpinit()/ TPINITIALIZE() with a client name of tpsysadm and are run by the administrator and bypass authentication Messages from authenticated ATMI clients that call tpinit()/ TPINITIALIZE() with a client name of tpsysadm Messages from authenticated ATMI clients that call tpinit()/ TPINITIALIZE() with a client name of tpsysop Messages from authenticated ATMI clients that call tpinit()/ TPINITIALIZE() with a client name other than tpsysadm or tpsysop Application key = user identifier (UID) in the lower 17 bits and group identifier (GID) in the next higher 14 bits; remaining upper bit is 0. AUTHSVR returns this application key valueIn addition, any message that originates from tpsvrinit(3c) or tpsvrdone(3c) in a C program (TPSVRINIT(3cbl) or TPSVRDONE(3cbl) in COBOL) is assigned the application key of the administrator: 0x80000000. The application key of the client is assigned to messages that pass through a server but originate at a client; an exception to this rule is described in “Replacing Client Tokens with Server Tokens” on page 1‑10.The user, group, and ACL files are located in the application_root directory, where application _root is the first pathname defined for the APPDIR variable. Figure 1‑11 identifies these files and specifies the administrative commands available for controlling each list.Figure 1‑11 Default User, Group, and ACL Files
Note: For an ATMI application running on the Compaq VMS operating system, the names of the user, group, and ACL files have .dat extensions: tpusr.dat, tpgrp.dat, and tpacl.dat.The files are colon-delimited, flat text files that can be read and written only by the application administrator—the owner of the TUXCONFIG file referenced by the TUXCONFIG variable. The format of the files is irrelevant, since the files are fully administered with a set of dedicated commands. Only the application administer is allowed to use these commands.An application administer can use the tpaclcvt(1) command to convert security data files to the format needed by the ACL checking feature. For example, on a UNIX host machine, an administrator can use tpaclcvt to convert the /etc/password file and store the converted version in the tpusr file. The same administrator can use tpaclcvt to convert the /etc/group file and store the converted version in the tpgrp file.The AUTHSVR server uses the user information stored in the tpusr file to authenticate users who want to join the ATMI application.The ACL and MANDATORY_ACL security levels constitute the default authorization implementation for the ATMI environment in the Oracle Tuxedo product.When the security level is ACL, if there is no entry in the tpacl file associated with the target application entity, the client is permitted to access the entity. This security level enables an administrator to configure access for only those resources that need more security. That is, there is no need to add entries to the tpacl file for services, events, or application queues that are open to everyone.When the security level is MANDATORY_ACL, if there is no entry in the tpacl file associated with the target application entity, the client is not permitted to access the entity. For this reason, this level is called mandatory. There must be an entry in the tpacl file for each and every application entity that the client needs to access.For both the ACL and MANDATORY_ACL security levels, if an entry for an application entity exists in the tpacl file and the client attempts to access that entity, the user associated with that client must be a member of a group that is allowed to access that entity; otherwise, permission is denied.For some ATMI applications, it may be necessary to use both system-level and application-level authorization. An entry in the tpacl file can be used to control which users can access a service, and application logic can control data-dependent access, for example, which users can handle transactions for more than a million dollars.Note that there is no ACL permission checking for administrative services, events, and application queues with names that begin with a dot (.). For example, any client can subscribe to administrative events such as .SysMachineBroadcast, .SysNetworkConfig, and .SysServerCleaning. In addition, there is no ACL permission checking for the application administrator, application operator, or processes or service requests running with the privileges of the application administrator or operator.
• “About the Configuration File” and “Creating the Configuration File” in Setting Up an Oracle Tuxedo Application
• UBBCONFIG(5) in the Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference
• AUTHSVR(5) in the Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes ReferenceInteroperability, as defined in this discussion, is the ability of the current release of Oracle Tuxedo software to communicate over a network with a previous release of Oracle Tuxedo software. Specifically, inter-domain interoperability and intra-domain interoperability have the following meanings:Involves one ATMI application running Oracle Tuxedo release 7.1 or later software, and another ATMI application running Oracle Tuxedo pre-release 7.1 software. See the diagram “Inter-Domain Interoperability” on page 1‑54 for clarification.Involves one machine in a multiple-machine ATMI application running Oracle Tuxedo release 7.1 or later software, and another machine in the same application running Oracle Tuxedo pre-release 7.1 software. See the figure “Intra-Domain Interoperability” on page 1‑55 for clarification.Figure 1‑12 Inter-Domain InteroperabilityFigure 1‑13 Intra-Domain InteroperabilityInteroperating with Oracle Tuxedo pre-release 7.1 software is allowed or disallowed at the authentication security level. Authentication, as implemented by Oracle Tuxedo release 7.1 or later software, allows communicating processes to mutually prove their identities.By default, interoperability with a machine running Oracle Tuxedo pre-release 7.1 software is not allowed. To change the default, an application administrator can use the CLOPT -t option to allow workstation handlers (WSHs), domain gateways (GWTDOMAINs), and servers in the release 7.1 or later ATMI application to interoperate with Oracle Tuxedo pre-release 7.1 software. “Mandating Interoperability Policy” on page 2‑15 provides instructions for using the CLOPT -t option as well as the security ramifications for authentication and authorization when using CLOPT -t.LLE interoperability with Oracle Tuxedo pre-release 7.1 software is described in “Backward Compatibility of LLE” on page 1‑24.
Note: The only exception to the SSL encryption interoperabiliy rules is that the CORBA related SSL capabilities described in “Using Security in CORBA Applications” can be used when interoperating with Tuxedo 8.0 and above, and when interoperating with the former WLE product.The following interoperability rules for public key security shown in Table 1‑12 apply to a machine running release 7.1 or later Oracle Tuxedo software that is configured to interoperate with a machine running Oracle Tuxedo pre-release 7.1 software. To clarify the rules, each rule has an accompanying example scenario involving a Workstation client running Oracle Tuxedo pre-release 7.1 software.
Encrypted outgoing message buffers destined for a machine running Oracle Tuxedo pre-release 7.1 software are not transmitted to the machine. Incoming message buffers from a machine running an Oracle Tuxedo pre-release 7.1 software are not accepted if routed to a process requiring encryption. See “Setting Encryption Policy” on page 2‑53 for a description of the ENCRYPTION_REQUIRED configuration parameter. For outgoing message buffers destined for the machine running Oracle Tuxedo pre-release 7.1 software, any digital signatures are verified and then removed before the message buffers are transmitted to the older machine. It is assumed that the outgoing message buffer is digitally signed but not encrypted. If the outgoing message buffer is digitally signed and encrypted, the message is not decrypted, the digital signatures are not verified, and the message is not transmitted to the older machine. Incoming message buffers from a machine running Oracle Tuxedo pre-release 7.1 software are not accepted if routed to a process requiring digital signatures. See “Setting Digital Signature Policy” on page 2‑49 for a description of the SIGNATURE_REQUIRED configuration parameter.For inter-domain interoperability, release 7.1 or later domain gateway (GWTDOMAIN) processes enforce the interoperability rules for public key security.For intra-domain interoperability, release 7.1 or later native clients, workstation handlers (WSHs), or server processes communicating with the local bridge process enforce the interoperability rules for public key security, as shown in Figure 1‑14. A bridge process operates only as a conduit; it does not decrypt message buffer content or verify digital signatures.It is possible to have default authentication and custom authorization, or custom authentication and default authorization, as long as the application developer is aware of the following restriction: the authorization security token must carry at a minimum (1) an authenticated username, or principal name, and (2) an application key value as defined in “Application Key” on page 1‑48.Authorization decisions are based partly on user identity, which is stored in an authorization token. Because authorization tokens are generated by the authentication security plug-in, providers of authentication and authorization plug-ins need to ensure that these plug-ins work together. (See “Authentication” on page 1‑7 and “Authorization” on page 1‑12 for more detail.)It is possible to have default authentication and custom auditing, or custom authentication and default auditing, as long as the application developer is aware of the following restriction: the auditing security token must carry at a minimum (1) an authenticated username, or principal name, and (2) an application key value as defined in “Application Key” on page 1‑48.Auditing decisions are based partly on user identity, which is stored in an auditing token. Because auditing tokens are generated by the authentication security plug-in, providers of authentication and auditing plug-ins need to ensure that these plug-ins work together. (See “Authentication” on page 1‑7 and “Auditing” on page 1‑18 for more detail.)Public key security is compatible with all features and processes supported by Oracle Tuxedo release 7.1 or later software except the compression feature. Encrypted message buffers cannot be compressed using the compression feature. But, because the public key software compresses the message content just before it encrypts the message buffer, any size savings are still achieved.
•
•
• Domain gateways (GWTDOMAINs)If a decryption key is not available, the routing operation fails. The system generates an ERROR userlog(3c) message to report the failure.If a decryption key is available, the process makes a routing decision based on a decrypted copy of the encrypted message buffer. The chain of events is as follows:
2. The process reads the resulting plaintext (unencrypted text) message content to make the routing decision.Public-private keys are represented and manipulated via handles. A handle has data associated with it that is used by the public key application programming interface (API) to locate or access the item named by the handle. A process opens a key handle for digital signature generation, message encryption, or message decryption.A key’s internal data structures are thread safe. As such, a key may be accessed concurrently by multiple threads.In general, a TMUSREVT(5) system server handles encrypted message buffers without decrypting them, that is, both digital signatures and encryption envelopes remain intact as messages flow through the Oracle Tuxedo EventBroker component. However, the following cases require that the EventBroker component decrypt posted message buffers:
• To perform subscription notification actions that require access to message content: userlog(3c) processing or system command execution.If the EventBroker does not have access to a suitable decryption key, the subscription’s notification action fails, and the system generates an ERROR userlog(3c) message to report the failure.If the EventBroker does not have access to a suitable decryption key, the subscription’s notification action fails, and the system generates an ERROR userlog() message to report the failure.
• If the EventBroker does not have access to a suitable decryption key, the tppost(3c) operation fails, and the system generates an ERROR userlog() message to report the failure.
• If the EventBroker does not have access to a suitable decryption key, the tppost(3c) operation fails, and the system generates an ERROR userlog() message to report the failure.In general, a TMQUEUE(5) or TMQFORWARD(5) system server handles encrypted message buffers without decrypting them, that is, both signatures and encryption envelopes remain intact as messages flow through the Oracle Tuxedo /Q component. However, the following cases require that the /Q component decrypt enqueued message buffers:
• To perform TMQFORWARD operations that, based on system configurations, need to access message content for data-dependent routing.If TMQFORWARD does not have access to a suitable decryption key, the forward operation fails. The system returns the message to the queue and generates an ERROR userlog(3c) message to report the failure.After a number of periodic retry attempts, TMQFORWARD might place the unreadable message on an error queue.
• If the /Q component does not have access to a suitable decryption key, the tpenqueue(3c) operation fails, and the system generates an ERROR userlog() message to report the failure.
• If the /Q component does not have access to a suitable decryption key, the tpenqueue(3c) operation fails, and the system generates an ERROR userlog() message to report the failure.A non-transactional tpdequeue(3c) operation has the side effect of destroying an encrypted queued message if the invoking process does not hold a valid decryption key.If a message with an invalid signature is placed in a queue (or if the message is corrupted or tampered with while on the queue), any attempt to dequeue it fails. A non-transactional tpdequeue() operation has the side effect of destroying such a message. A transactional tpdequeue() operation causes transaction rollback, and all future transactional attempts to dequeue the message will continue to fail.Domain gateway (GWTDOMAIN) processes connecting two ATMI applications running Oracle Tuxedo release 7.1 or later software preserve digital signatures and encryption envelopes. In addition, the domain gateway processes verify digital signatures and enforce administrative system policies regarding digital signatures and encryption.Figure 1‑15 is an aid to understanding how domain gateway processes interact with local and remote ATMI applications. The table following the figure describes how release 7.1 or later domain gateway processes handle digitally signed and encrypted message buffers.Figure 1‑15 Communication Between ATMI Applications
If the data-dependent routing feature applies and the domain gateway process does not have a suitable decryption key, the gateway process rejects the message. (See “Compatibility/Interaction with Data-dependent Routing” on page 1‑60 for clarification.) If the domain gateway process is running within a domain, machine, or group requiring encryption, the gateway process rejects the message. If a service advertised by the domain gateway requires encryption, the gateway process rejects the message. (See “Setting Encryption Policy” on page 2‑53 for clarification.)If the domain gateway does not require encryption, the gateway process accepts and forwards the message. If the domain gateway process is running within a domain, machine, or group requiring digital signatures, the gateway process rejects the message. If a service advertised by the domain gateway requires digital signatures, the gateway process rejects the message. (See “Setting Digital Signature Policy” on page 2‑49 for clarification.)If the domain gateway does not require digital signatures, the gateway process accepts and forwards the message. If the data-dependent routing feature applies and the domain gateway process does not have a suitable decryption key, the gateway process rejects the message. (See “Compatibility/Interaction with Data-dependent Routing” on page 1‑60 for clarification.)If the encrypted message is destined for a process running Oracle Tuxedo pre-release 7.1 (6.5 or earlier) software, the domain gateway process rejects the message. (See “Interoperating with Pre-Release 7.1 Software” on page 1‑55 and “Interoperability for Public Key Security” on page 1‑56 for clarification.) If the domain gateway process is running within a domain, machine, or group requiring encryption, the gateway process rejects the message. If a service advertised by the domain gateway requires encryption, the gateway process rejects the message. (See “Setting Encryption Policy” on page 2‑53 for clarification.)If the domain gateway does not require encryption, the gateway process accepts the message and forwards it over the network. If the message is destined for a process running Oracle Tuxedo pre-release 7.1 software and assuming interoperability with Oracle Tuxedo pre-release 7.1 software is allowed, the domain gateway process verifies and then removes the digital signature before forwarding the message over the network. (See “Interoperating with Pre-Release 7.1 Software” on page 1‑55 and “Interoperability for Public Key Security” on page 1‑56 for clarification.) If the domain gateway process is running within a domain, machine, or group requiring digital signatures, the gateway process rejects the message. If a service advertised by the domain gateway requires digital signatures, the gateway process rejects the message. (See “Setting Digital Signature Policy” on page 2‑49 for clarification.)If the domain gateway does not require digital signatures, the gateway process accepts the message and forwards it over the network.A domain gateway (GWTDOMAIN) process connecting a release 7.1 or later ATMI application to another vendor’s gateway process operates on outbound message buffers as follows:With more distributed multi-domain Tuxedo applications extending their reach to public networks and less secure environments, the Tuxedo domain gateway is required to better defend against potential threats. These environments may contain insecure networks and untrusted participants, who can initiate or propagate malicious attacks such as Denial-of-Service (DoS) attacks as shown in Figure 1‑16.Figure 1‑16 Denial-of-Service (DoS) AttacksBy limiting the number of connections, GWTDOMAIN can avoid this problem. For more GWTDOMAIN information, see GWTDOMAIN(5).The Limited/Restricted Connection Numbers feature requires modification of the *SERVERS section in the UBBCONFIG file.The CLOPT used to specify the parameter for GWTDOMAIN is "-x" using the following syntax: -x limit[:{[duration][:period]}]. A colon ( : ) is used to separate each option.
Note: The number of current active connections includes both active incoming connections and active outgoing connections. The number of closed connections in a previous period includes both closed incoming connections and closed outgoing connections. However, when GWTDOMAIN is suspended, none of the closed connections are counted.
• The maximum number of connections. The minimum limit value is 0, and the maximum value is 2,147,483,647.When the limit is reached (or exceeded) and there is an incoming request, GWTDOMAIN is suspended for the given duration. At the same time, the current incoming request which triggers the suspending is not accepted. Polling is resumed after duration has elapsed.Setting the limit to 0 prohibits the domain gateway from accepting any incoming connection requests. In other words, this is an "OUTGOING_ONLY" connection policy.
• The duration in seconds to suspend polling for incoming connection when limit is reached. The default value is (SCANUNIT * SANITYSCAN) seconds. The minimum duration value is 5, and the maximum value is 65,535.
• The time interval (in seconds) proceeding GWTDOMAIN check point to count the closed connections in the past. When not specified, the default value is the same as duration. The minimum period value is 0, and the maximum value is 65,535.If period is specified as 0, the number of closed connections in a prior period will always be 0, limit only counts active connections.Listing 1‑1 shows an example where the GWTDOMAIN limit is set to 512 concurrent socket connections. When the 512 limit is reached and there is an incoming request, GWTDOMAIN will stop polling and accepting new incoming connection requests for a duration of 300 seconds (or, 5 minutes). Since period is specified as 0, only the active connections are counted.Listing 1‑1 UBBCONFIG File Example 1Listing 1‑2 shows an example where the GWTDOMAIN limit is set to 200 concurrent socket connections. When the 200 limit is reached, (for example:and since the duration value is not specified, GWTDOMAIN will stop polling and accepting new incoming connection requests for the duration default value SCANUNIT * SANITYSCAN seconds.Listing 1‑2 UBBCONFIG File Example 2
• If limit is specified as 0, when GWTDOMAIN starts up:It is not necessary to turn on the SECURITY feature to enable MAC; however, it is recommended since SECURITY can be used to defend against the “man-in-the-middle” attack.There are two options that you configure the MAC feature. You can use DMCONFIG file configuration, or MIB configuration.
Table 1‑14 DMCONFIG File Keywords Listing 1‑3 shows an example DMCONFIG configuration.Listing 1‑3 DMCONFIG File ConfigurationTwo new attributes are added to support MIB interface in the T_DM_TDOMAIN class definition attribute table: TA_DMMAC and TA_DMMACLEVEL.
Listing 1‑4 and Listing 16 show examples of how to retrieve and update MAC attributes using ud32 respectively.Listing 1‑4 Sample Retrieve MAC Attribute ScriptListing 16 Sample Update MAC Attribute ScriptTable 1‑17 shows two domains: DOM1 and DOM2. When DOM1 (initiator) establishes a session with DOM2 (acceptor), the MAC negotiation result is (1) MAC = ON; and (2) MACLEVEL = 2.Table 1‑17 MAC Negotiation ExampleTable 1‑18 and Table 1‑19 provide more MAC and MACLEVEL details respectively.When MAC is turned on, the MACLEVEL in use is set to the higher number, or max (m1,m2) for safety purpose. It must be supported by both endpoints (that is, not greater than min (Max1,Max2)). In short, the negotiated MACLEVEL must satisfy following relationship:
max(m1, m2)<=negotiated MACLEVEL<=min(Max1, Max2), otherwise the connection is closed with one ERROR message logged in USERLOG.Table 1‑18 MAC Negotiation Results (parameter: MAC)Table 1‑19 MAC NegotiationResults (parameter: MACLEVEL)
Note: