This topic includes the following sections:
|Notes:||The Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported. All Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB text references, associated code samples, should only be used to help implement/run third party Java ORB libraries, and for programmer reference only.|
|Note:||Technical support for third party CORBA Java ORBs should be provided by their respective vendors. Oracle Tuxedo does not provide any technical support or documentation for third party CORBA Java ORBs.|
For the C++ and Automation method descriptions for the CORBA Security APIs, see the following topics:
The security model in the CORBA environment of the Oracle Tuxedo product defines only a framework for security. The Oracle Tuxedo product provides the flexibility to support different security mechanisms and policies that can be used to achieve the appropriate level of functionality and assurance for a particular CORBA application.
The security model in the CORBA environment defines:
The security model in the CORBA environment is a combination of the security model defined in the CORBAservices Security Service specification and the value-added extensions that provide a focused, simplified form of the security model found in the ATMI environment of the Oracle Tuxedo product.
The following sections describe the general characteristics of the CORBA security model.
Authentication of principals (for example, an individual user, a client application, a server application, a joint client/server application, or an IIOP Listener/Handler) provides security officers with the ability to ensure that only registered principals have access to the objects in the system. An authenticated principal is used as the primary mechanism to control access to objects. The act of authenticating principals allows the security mechanisms to:
The CORBA security model provides a simple framework through which a security officer can limit access to the Oracle Tuxedo domain to authorized users only. Limiting access to objects allows security officers to prohibit access to objects by unauthorized principals. The access control framework consists of two parts:
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, seeand .
The CORBA security model is based on the process of authenticating principals to the Oracle Tuxedo domain. The objects in the CORBA security environment are used to authenticate a principal. The principal provides identity and authentication data, such as a password, to the client application. The client application uses the Principal Authenticator object to make the calls necessary to authenticate the principal. The credentials for the authenticated principal are associated with the security system’s implementation of the SecurityCurrent object and are represented by a Credentials object.
Figure 12-1 illustrates the authentication process used in the CORBA security model.
The following sections describe the objects in the CORBA security model.
The Principal Authenticator object is used by a principal that requires authentication but has not been authenticated prior to calling the object system. The act of authenticating a principal results in the creation of a Credentials object that is made available as the default credentials for the application.
The Principal Authenticator object is a singleton object; there is only a single instance allowed in a process address space. The Principal Authenticator object is also stateless. A Credentials object is not associated with the Principal Authenticator object that created it.
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
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
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
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
The extended Principal Authenticator object adheres to all the same rules as the Principal Authenticator object defined in the CORBAservices Security Service specification.
The implementation of the extended Principal Authenticator object requires users to supply a username, client name, and additional authentication data (for example, passwords) used for authentication. Because the information needs to be transmitted over the network to the IIOP Listener/Handler, it is protected to ensure confidentiality. The protection must include encryption of any information provided by the user.
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.
Credentials objects are created as the result of:
Multiple references to a Credentials object are supported. A Credentials object is stateful. It maintains state on behalf of the principal for which it was created. This state includes any information necessary to determine the identity and privileges of the principal it represents. Credentials objects are not associated with the Principal Authenticator object that created it, but must contain some indication of the authentication authority that certified the principal’s identity.
The 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
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
invocation_options_supportedattribute indicates which security options are allowed when establishing a secure connection.
invocation_options_requiredattribute 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.
The SecurityCurrent object is a singleton object; there is only a single instance allowed in a process address space. Multiple references to the SecurityCurrent object are supported.
The CORBAservices Security Service specification defines two interfaces for the SecurityCurrent object associated with security:
Both interfaces give access to security information associated with the execution context.
At 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.
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