• For convenience, the two parameters are denoted as (min, max). 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.Figure 3‑1 illustrates these steps.Figure 3‑1 How LLE Works
1. Each process identifies its own min-max values.When either of the two processes starts up, the Oracle Tuxedo system (1) checks the bit-encryption capability of the installed LLE version by checking the LLE licensing information in the lic.txt file and (2) checks the LLE min-max values for the particular link type as specified in the two configuration files. The Oracle Tuxedo system then proceeds as follows:
• If the configured min-max values accommodate the installed LLE version, then the local software assigns those values as the min-max values for the process.
• If the configured min-max values do not accommodate the installed LLE version, for example, if the Export LLE version is installed but the configured min-max values are (0, 128), then the local software issues a run-time error; link-level encryption is not possible at this point.
• 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 installed LLE versions as the maximum value, that is, (0, 128) for the Domestic LLE version.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 3‑1 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 3‑1 Interprocess Negotiation Results The length of time a Workstation client can take for initialization is limited. By default, this interval is 30 seconds in an application not using LLE, and 60 seconds in an 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).To use LLE in a CORBA application, you need to install a license that enables the use of LLE. For information about installing the license, see Installing the Oracle Tuxedo System.The implementation of LLE is an administrative task. The system administrators for each CORBA application set min-max values in the UBBCONFIG file that control encryption strength. When the two CORBA applications establish communication, they negotiate what level of encryption to use to exchange messages. Once an encryption level is negotiated, it remains in effect for the lifetime of the network connection.When using Password authentication, you have the option of using the Tobj::PrincipalAuthenticator::logon() or the SecurityLevel2::PrincipalAuthenticator::authenticate() methods in your client application.If you use password authentication, the SSL protocol can be used to provide confidentiality and integrity to communication between applications. For more information, see “The SSL Protocol” on page 3‑9.
• Through the CORBA Interoperable Naming Service (INS) Bootstrapping mechanism. Use this mechanism if you are using a client ORB from another vendor. For more information about using CORBA INS, see the CORBA Programming Reference in the Oracle Tuxedo online documentation
• The initiating application creates the security context using a PrincipalAuthenticator object. The request for authentication is sent to the IIOP Listener/Handler. The proof material in the authentication request is securely relayed to the authentication server, which verifies the supplied information.
• If the verification succeeds, the Oracle Tuxedo system constructs a Credentials object that is used by all future invocations. The Credentials object for the user is associated with the Current object that represents the security context.Figure 3‑2 illustrates these steps.Figure 3‑2 How Password Authentication WorksDefining password authentication for a CORBA application includes administration and programming steps. Table 3‑2 and Table 3‑3 list the administration and programming steps for password authentication. For a detailed description of the administration steps for password authentication, see “Configuring Authentication” on page 7‑1. For a complete description of the programming steps, see “Writing a CORBA Application That Implements Security” on page 10‑1.
If you defined the SECURITY parameter as USER_AUTH, ACL, or MANDATORY_ACL, configure the authentication server (AUTHSRV) in the UBBCONFIG file. Use the tpusradd and tpgrpadd commands to define lists of authorized users and groups including the IIOP Listener/Handler. Use the tmloadcf command to load the UBBCONFIG file. When the UBBCONFIG file is loaded, the system administrator is prompted for a password. The password entered at this time becomes the password for the CORBA application.
Write application code that uses the Tobj::PrincipalAuthenticator::logon() or SecurityLevel2::PrincipalAuthenticator::authenticate() operation to establish a security context with the Oracle Tuxedo domain. Write application code that prompts the user for the password defined when the UBBCONFIG file is loaded.Like 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 IIOP Listener/Handler defined by the SEC_PRINCIPAL_NAME parameter when you enter the tmloadcf command.Figure 3‑3 illustrates how the SSL protocol works.To use the SSL protocol in a CORBA application, you need to install a license that enables the use of the SSL protocol and PKI. For information about installing the license for the security features, see Installing the Oracle Tuxedo System.Using the SSL protocol in a CORBA application is primarily an administration process. Table 3‑4 lists the administration steps required to set up the infrastructure required to use the SSL protocol and configure the IIOP Listener/Handler for the SSL protocol. For a detailed description of the administration steps, see “Managing Public Key Security” on page 4‑1 and “Configuring the SSL Protocol” on page 6‑1.Once the administration steps are complete, you can use either password authentication or certificate authentication in your CORBA application. For more information, see “Writing a CORBA Application That Implements Security” on page 10‑1.
Note:
Define the SEC_PRINCIPAL_NAME, SEC_PRINCIPAL_LOCATION, and SEC_PRINCIPAL_PASSVAR parameters for the ISL server process in the UBBCONFIG file. Define a port for secure communication on the IIOP Listener/Handler using the -S option of the ISL command. Create a Trusted Certificate Authority file (trust_ca.cer) that defines the certificate authorities trusted by the IIOP Listener/Handler. Optionally, create a Peer Rules file (peer_val.rul) for the IIOP Listener/Handler. If you use the SSL protocol with password authentication, you need to set the SECURITY parameter in the UBBCONFIG file to desired level of authentication and if appropriate, configure the Authentication Server (AUTHSRV). For information about the administration steps for password authentication, see “Password Authentication” on page 3‑5.Figure 3‑4 illustrates the configuration of a CORBA application that uses the SSL protocol.Figure 3‑5 provides a conceptual overview of the certificate authentication.Figure 3‑5 Certificate Authentication
Note: In versions of Tuxedo prior to Tuxedo 12.1.1 a value of 0 was also allowed, which disabled Basic Constraints enforcement entirely. This option was provided for compatibility with older certificates back when Basic Constraints were still a fairly recent feature in the X.509 standard. Since this is no longer the case, the TUX_SSL_ENFORCECONSTRAINTS=0 value is no longer supported in Tuxedo 12.1.1 and later releases.
• Through the CORBA INS Bootstrapping mechanism. Use this mechanism if you are using a client ORB from another vendor. For more information about using CORBA INS, see CORBA Programming Reference in the Oracle Tuxedo online documentation.
2. The initiating application instantiates the Bootstrap object with a URL in the form of corbaloc://host:port or corbalocs://host:port and controls the requirement for protection by setting attributes on the SecurityLevel2::Credentials object returned as a result of the SecurityLevel2::PrincipalAuthenticator::authenticate operation.
Note: You can also use the SecurityLevel2::Current::authenticate() method to secure the bootstrapping process and specify that certificate authentication is to be used.The security context is established as result of a SecurityLevel2::PrincipalAuthenticator::authenticate() method.
4. If the verification succeeds, the Oracle Tuxedo system constructs a Credentials object. The Credentials object for the principal represents the security context for the current thread of execution.Figure 3‑6 How Certificate Authentication WorksTo use certificate authentication in a CORBA application, you need to install a license that enables the use of the SSL protocol and PKI. For information about installing the license, see Installing the Oracle Tuxedo System.Using certificate authentication in a CORBA application includes administration and programming steps. Table 3‑5 and Table 3‑6 list the administration and programming steps for certificate authentication. For a detailed description of the administration steps, see “Managing Public Key Security” on page 4‑1 and “Configuring the SSL Protocol” on page 6‑1.
Define the SEC_PRINCIPAL_NAME, SEC_PRINCIPAL_LOCATION, and SEC_PRINCIPAL_PASSVAR for the ISL server process in the UBBCONFIG file. Use the tpusradd and tpgrpadd commands to define the authorized Users and Groups of your CORBA application. Define a port for SSL communication on the IIOP Listener/Handler using the -S option of the ISL command. Enable certificate authentication in the IIOP Listener/Handler using the -a option of the ISL command. Create a Trusted Certificate Authority file (trust_ca.cer) that defines the certificate authorities trusted by the IIOP Listener/Handler. Create a Trusted Certificate Authority file (trust_ca.cer) that defines the certificate authorities trusted by the CORBA client application. Use the tmloadcf command to load the UBBCONFIG file. You will be prompted for the password of the IIOP Listener/Handler defined in the SEC_PRINCIPAL_NAME parameter. Optionally, create a Peer Rules file (peer_val.rul) for both the CORBA client application and the IIOP Listener/Handler. Figure 3‑7 illustrates the configuration of a CORBA application that uses certificate authentication.Table 3‑6 lists the programming steps for using certificate authentication in a CORBA application. For more information, see “Writing a CORBA Application That Implements Security” on page 10‑1.
Write application code that uses the corbaloc or corbalocs URL address formats of the Bootstrap object. Note that the CommonName in the Distinguished Name of the certificate of the IIOP Listener/Handler must match exactly the host name provided in the URL address format. For more information on the URL address formats, see “Using the Bootstrapping Mechanism” on page 10‑1. Write application code that uses the authenticate() method of the SecurityLevel2::PrincipalAuthenticator interface to perform authentication. Specify Tobj::CertificateBased for the method argument and the pass phrase for the private key as the auth_data argument for Security::Opaque.The Oracle Tuxedo product allows the integration of authentication plug-ins into a CORBA application. The Oracle Tuxedo product can accommodate authentication plug-ins using various authentication technologies, including shared-secret password, one-time password, challenge-response, and Kerberos. The authentication interface is based on the generic security service (GSS) application programming interface (API) where applicable and assumes authentication plug-ins have been written to the GSSAPI.If you chose to use an authentication plug-in, you must configure the authentication plug-in in the registry of the Oracle Tuxedo system. For more detail about the registry, see “Configuring Security Plug-ins” on page 8‑1.If you chose to use an authorization plug-in, you must configure the authorization plug-in the registry of the Oracle Tuxedo system. For more detail about the registry, see “Configuring Security Plug-ins” on page 8‑1.The current implementation of the auditing feature supports the recording of logon failures, impersonation failures, and disallowed operations into the ULOG file. In the case of disallowed operations, the value of the parameters to the operation are not provided because there is no way to know the order and data types of the parameter for an arbitrary operation. Audit entries for logon and impersonation include the identity of the principal attempting to be authenticated. For information about setting up the ULOG file, see Setting Up an Oracle Tuxedo Application.Auditing decisions are based partly on user identity, which is stored in an auditing token. Because auditing tokens are generated by the authentication plug-in, providers of authentication and auditing plug-ins need to ensure that these plug-ins work together.The purpose of an auditing request is to record an event. Each auditing plug-in returns one of two responses: success (the audit succeeded and the event was logged) or failure (the audit failed and the event was not logged the event). An auditing plug-in is called once before the operation is performed and once after the operation completes.When using multiple auditing plug-ins, all the plug-ins are placed under a single master auditing plug-in. Each subordinate authorization plug-in returns SUCCESS or FAILURE. If any plug-in fails the operation, the auditing master plug-in determines the outcome to be FAILURE. Other error returns are also considered FAILURE. Otherwise, SUCCESS is the outcome.In addition, an Oracle Tuxedo system process may call an auditing plug-in when a potential security violation occurs. (Suspicion of a security violation arises when a preoperation or postoperation authorization check fails or when an attack on security is detected.) In response, the auditing plug-in performs a postoperation audit and returns whether the audit succeeded.If you chose to use an auditing plug-in other than the default auditing plug-in, you must configure the auditing plug-in the registry of the Oracle Tuxedo system. For more detail about the registry, see “Configuring Security Plug-ins” on page 8‑1.The Oracle Tuxedo product provides a PKI environment which includes the SSL protocol and the infrastructure needed to use digital certificates in a CORBA application. However, you can use the PKI interfaces to integrate a PKI plug-in that supplies custom message-based digital signature and message-based encryption to your CORBA applications. Table 3‑7 describes the PKI interfaces.
Table 3‑7 PKI Interfaces If you chose to use a PKI plug-in, you must configure the PKI plug-in in the registry of the Oracle Tuxedo system. For more detail about the registry, see “Configuring Security Plug-ins” on page 8‑1.To use the SSL protocol in a CORBA application, set up the infrastructure to use digital certificates, change the command-line options on the ISL server process to use the SSL protocol, and configure a port for secure communications on the IIOP Listener/Handler. If your existing CORBA application uses password authentication, you can use that code with the SSL protocol. If your CORBA C++ client application does not already catch the InvalidDomain exception when resolving initial references to the Bootstrap object and performing authentication, write code to handle this exception. For more information, see “PKI Plug-ins” on page 3‑22.