The system administrator is responsible for setting security policies for the CORBA application. The Oracle Tuxedo product provides a set of configuration parameters and utilities. Using the configuration parameters and utilities, a system administrator can configure the CORBA application to force the principals to be authenticated to access a system on which Oracle Tuxedo software is installed. To enforce the configuration parameters, the system administrator uses the tmloadcf command to update the configuration file for a particular CORBA application.For more information about configuring security for your CORBA application, see “Configuring the SSL Protocol” on page 6‑1 and “Configuring Authentication” on page 7‑1.Figure 12‑1 illustrates the authentication process used in the CORBA security model.All Principal Authenticator objects support the SecurityLevel2::PrincipalAuthenticator interface defined in the CORBAservices Security Service specification. This interface contains two methods that are used to accomplish the authentication of the principal. This is because authentication of principals may require more than one step. The authenticate method allows the caller to authenticate, and optionally select, attributes for the principal of this session.Any invocation that fails because the security infrastructure does not permit the invocation will raise the standard exception CORBA::NO_PERMISSION. A method that fails because the feature requested is not supported by the security infrastructure implementation will raise the CORBA::NO_IMPLEMENT standard exception. Any parameter that has inappropriate values will raise the CORBA::BAD_PARAM standard exception. If a timing-related problem occurs, they raise a CORBA::COMM_FAILURE. The Bootstrap object maps most system exceptions to CORBA::Invalid_Domain.The Principal Authenticator object is a locality-constrained object. Therefore, a Principal Authenticator object may not be used through the DII/DSI facilities of CORBA. Any attempt to pass a reference to this object outside of the current process, or any attempt to externalize it using CORBA::ORB::object_to_string, will result in the raising of the CORBA::MARSHAL exception.The Principal Authenticator object has been enhanced to support certificate authentication. The use of certificate authentication is controlled by specifying the Security::AuthenticationMethod value of Tobj::CertificateBased as a parameter to the PrincipalAuthenticator::authenticate operation. When certificate authentication is used, the implementation of the PrincipalAuthenticator::authenticate operation must retrieve the credentials for the principal by obtaining the private key and digital certificates for the principal and registering them for use with the SSL protocol.The values of the security_name and auth_data parameters of the PrincipalAuthenticator::authenticate operation are used to open the private key for the principal. If the user does not specify the proper values for both of these parameters, the private key cannot be opened and the user fails to be authenticated. As a result of successfully opening the private key, a chain of digital certificates that represent the local identity of the principal is built. Both the private key and the chain of digital certificates must be registered to be used with the SSL protocol.The CORBA environment in the Oracle Tuxedo product extends the Principal Authenticator object to support a security mechanism similar to the security in the ATMI environment in the Oracle Tuxedo product. The enhanced functionality is provided by defining the Tobj::PrincipalAuthenticator interface. This interface contains methods to provide similar capability to that available from the ATMI environment through the tpinit function. The interface Tobj::PrincipalAuthenticator is derived from the CORBA SecurityLevel2::PrincipalAuthenticator interface.An extended Principal Authenticator object that supports the Tobj::PrincipalAuthenticator interface provides the same functionality as if the SecurityLevel2::PrincipalAuthenticator interface were used to perform the authentication of the principal. However, unlike the SecurityLevel2::PrincipalAuthenticator::authenticate method, the logon method defined on the Tobj::PrincipalAuthenticator interface does not return a Credentials object.A Credentials object (as shown in Figure 12‑2) holds the security attributes of a principal. The Credentials object provides methods to obtain and set the security attributes of the principals it represents. These security attributes include its authenticated or unauthenticated identities and privileges. It also contains information for establishing security associations.Figure 12‑2 The Credentials ObjectThe Credentials object is a locality-constrained object; therefore, a Credentials object may not be used through the DII/DSI facilities. Any attempt to pass a reference to this object outside of the current process, or any attempt to externalize it using CORBA::ORB::object_to_string, will result in the raising of the CORBA::MARSHAL exception.The Credentials object has been enhanced to allow application developers to indicate the security attributes for establishing secure connections. These attributes allow developers to indicate whether a secure connection requires integrity, confidentiality, or both. To support this capability, two new attributes were added to the SecurityLevel2::Credentials interface.
• The invocation_options_supported attribute indicates which security options are allowed when establishing a secure connection.
• The invocation_options_required attribute allows the application developer to specify the minimum set of security options that must be used in establishing a secure connection.The SecurityCurrent object (see Figure 12‑3) represents the current execution context at both the principal and target objects. The SecurityCurrent object represents service-specific state information associated with the current execution context. Both client and server applications have SecurityCurrent objects that represent the state associated with the thread of execution and the process in which the thread is executing.Figure 12‑3 The SecurityCurrent Object
• SecurityLevel1::Current, which derives from CORBA::Current
• SecurityLevel2::Current, which derives from the SecurityLevel1::Current interfaceAt any stage, a client application can determine the default credentials for subsequent invocations by calling the Current::get_credentials method and asking for the invocation credentials. These default credentials are used in all invocations that use object references.When the Current::get_attributes method is invoked by a client application, the attributes returned from the Credentials object are those of the principal.The SecurityCurrent object is a locality-constrained object; therefore, a SecurityCurrent object may not be used through the DII/DSI facilities. Any attempt to pass a reference to this object outside of the current process, or any attempt to externalize it using CORBA::ORB::object_to_string, results in a CORBA::MARSHAL exception.