Overview of the CORBA Security Features

This topic includes the following sections:

•	The CORBA Security Features

•	The CORBA Security Environment

•	Oracle Tuxedo Security SPIs

Notes:

The Oracle Tuxedo product includes environments that allow you to build both Application-to-Transaction Monitor Interfaces (ATMI) and CORBA applications. This topic explains how to implement security in a CORBA application. For information about implementing security in an ATMI application, see Using Security in ATMI Applications.

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.

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.

The CORBA Security Features

Security refers to techniques for ensuring that data stored in a computer or passed between computers is not compromised. Most security measures involve proof material and data encryption, where the proof material 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 cannot be interpreted.

Distributed applications such as those used for electronic commerce (e-commerce) offer many access points for malicious people to intercept data, disrupt operations, or generate fraudulent input; the more distributed a business becomes, the more vulnerable it is to attack. Thus, the distributed computing software, or middleware, upon which such applications are built must provide security.

The CORBA security features of the Oracle Tuxedo product lets you establish secure connections between client and server applications. It has the following features:

•	Authentication of CORBA C++ applications to the Oracle Tuxedo domain. Authentication can be accomplished using a standard username/password combination or the identity inside of the X.509 digital certificate provided to the server applications.

•

Data integrity and confidentiality through Link-Level Encryption (LLE) or the Secure Sockets Layer (SSL) protocol. CORBA C++ applications can establish SSL sessions with an Oracle Tuxedo domain. Oracle Tuxedo client applications can use LLE or SSL to protect network traffic between bridges and domains.

•	Security Service Provider Interfaces (SPIs) that can be used to integrate security mechanisms that provide authentication, authorization, auditing, and public key security features. Security vendors can use the SPIs to integrate third-party security offerings into the CORBA environment.

•	A Public Key Infrastructure (PKI) that uses the SSL protocol and X.509 digital certificates to provide data privacy for messages sent over network links. In addition, a set of PKI SPIs are provided.

To access the full security features of the CORBA environment, you need to install a license that enable the use of the SSL protocol, LLE, and PKI. For information about installing the license for the security features, see the Installing the Oracle Tuxedo System.

Note:

Using Security in CORBA Applications describes the security features of the CORBA environment in the Oracle Tuxedo product. For a complete description of using the security features in the ATMI environment in the Oracle Tuxedo product, see Using Security in ATMI Applications.

Table 1‑1 summarizes the features in the CORBA security features in the Oracle Tuxedo product.

.

Table 1‑1 CORBA Security Features 

Security Features	Description	Service Provider Interface (SPI)	Default Implementation
Authentication	Proves the stated identity of users or system processes; safely remembers and transports identity information; and makes identity information available when needed.	Implemented as a single interface	Provides security at three levels: no authentication, application password, and certificate authentication.
Authorization	Controls access to resources based on identity or other information.	Implemented as a single interface	N/A
Auditing	Safely collects, stores, and distributes information about operating requests and their outcomes.	Implemented as a single interface	Default auditing security is implemented via the features of the user log (ULOG).
Link-Level Encryption	Uses symmetric key encryption to establish data privacy for messages moving over the network links that connect the machines in a CORBA application.	N/A	RC4 symmetric key encryption.
The Secure Sockets Layer (SSL) protocol	Uses asymmetric encryption to establish data privacy for messages moving over network links between Oracle Tuxedo domains.	N/A	The SSL version 3.0 protocol.
Public key security	Uses public key (or asymmetric key) encryption to establish data privacy for messages moving over the network links between remote client applications and the IIOP Listener/Handler. Complies with SSL version 3.0 allowing mutual authentication based on X.509 digital certificates.	Implemented as the following interfaces: • Public key initialization • Key management • Certificate lookup • Certificate parsing • Certificate validation • Proof material mapping	Default public key security supports the following algorithms: • RSA for key exchange. • AES or DES and its variants RC2 and RC4 for bulk encryption. • MD5 and SHA for message digests.

The CORBA Security Environment

Direct end-to-end mutual authentication in a distributed enterprise middleware environment such as the Oracle Tuxedo CORBA environment can be prohibitively expensive, especially when accomplished through security mechanisms optimized for long duration connections. It is not efficient for principals to establish direct network connections with each server application, nor is it practical to exchange and verify multiple authentication messages as part of processing each service request. Instead, CORBA applications in an Oracle Tuxedo product implements a delegated trust authentication model as shown in Figure 1‑1.

Figure 1‑1 Delegated Trust Model

In a delegated trust model, principals (generally users of client applications) authenticate to a trusted system gateway process. In the case of the CORBA applications, the trusted system gateway process is the IIOP Listener/Handler. As part of successful authentication, security tokens are assigned to the initiating principal. A security token is an opaque data structure suitable for transfer between processes.

When a request from an authenticated principal reaches the IIOP Listener/Handler, the IIOP Listener/Handler attaches the principal’s security tokens to the request and delivers the request to the target server application for authorization and auditing purposes.

In a delegated trust authentication model, the IIOP Listener/Handler trusts that the authentication software in the Oracle Tuxedo domain will verify the identity of the principal and generates the appropriate security tokens. Server applications, in turn, trust that the IIOP Listener/Handler will attach the correct security tokens. Server applications also trust that any other server applications involved in the process of a request from a principal will safely deliver the security tokens.

A session is established between the initiating client application and the IIOP Listener/Handler in the following way:

1.	When a client application wants to access an object within an Oracle Tuxedo domain, the client application uses either a username and password or a X.509 digital certificate to authenticate over the connection with the IIOP Listener/Handler.

2.	A security association called a security context is established between a principal and the IIOP Listener/Handler. This security context is used to control access to objects in the Oracle Tuxedo domain.

The IIOP Listener/Handler retrieves the authorization and auditing tokens from the security context. Together, the authorization and auditing tokens represent the principal’s identity associated with the security context.

3.	Once the authentication process is complete, the principal invokes an object in the Oracle Tuxedo domain. The request is packaged into an IIOP request and forwarded to the IIOP Listener/Handler. The IIOP Listener/Handler associates the request with the previously established security context.

4.	The IIOP Listener/Handler receives the request from the initiating principal.

The protection of messages between the client application and the IIOP Listener/Handler is dependent on the security technology used in the CORBA application. The default behavior of the Oracle Tuxedo product is to encrypt the authentication information but not to protect the message sent between the client application and the Oracle Tuxedo domain. The message is sent in clear text. The SSL protocol can be used to protect the message. If the SSL protocol is configured to protect messages for integrity and confidentiality, the request is digitally signed and sealed (encrypted) before it is sent to the IIOP Listener/Handler.

5.	The IIOP Listener/Handler forwards the request along with the authorization and auditing tokens of the initiating principal to the appropriate server application.

6.

When the request is received by the server application, the Oracle Tuxedo system interrogates the forwarded tokens of the requesting principal to determine if the request should be processed or denied. The CORBA security features will, based on the decision of the authorization implementation, deny the processing of any request on an object for which the requesting principal has no permission to access.

Oracle Tuxedo Security SPIs

As shown in Figure 1‑2, the authentication, authorization, auditing, and public key security features available with the Oracle Tuxedo product are implemented through a plug-in interface, which allows security plug-ins to be integrated into the CORBA environment. A security plug-in is a code module that implements a particular security feature.

Figure 1‑2 Architecture for the Oracle Tuxedo Security Service Provider Interfaces

 

The Oracle Tuxedo product provides interfaces for the types of security plug-ins listed in Table 1‑2.

 

Table 1‑2 The Oracle Tuxedo Security Plug-Ins 

Plug-In	Description
Authentication	Allows communicating processes to mutually prove identification.
Authorization	Allows system administrators to control access to CORBA applications. Specifically, an administrator can use authorization to allow or disallow principals to use resources or services provided by a CORBA application.
Auditing	Provides a means to collect, store, and distribute information about operating requests and their outcomes. Audit-trail records may be used to determine which principals performed, or attempted to perform, actions that violated the configured security policies of a CORBA application. They may also be used to determine which operations were attempted, which ones failed, and which ones successfully completed.
Public key initialization	Allows public key software to open public and private keys. For example, gateway processes may need to have access to a specific private key in order to decrypt messages before routing them.
Key management	Allows public key software to manage and use public and private keys. Note that message digests and session keys are encrypted and decrypted using this interface, but no bulk data encryption is performed using public key cryptography. Bulk data encryption is performed using symmetric key cryptography.
Certificate lookup	Allows public key software to retrieve X.509v3 digital certificates for a given principal. Digital certificates may be stored using any appropriate certificate repository, such as Lightweight Directory Access Protocol (LDAP).
Certificate parsing	Allows public key software to associate a simple principal name with an X.509v3 digital certificate. The parser analyzes a digital certificate to generate a principal name to be associated with the digital certificate.
Certificate validation	Allows public key software to validate an X.509v3 digital certificate in accordance with specific business logic.
Proof material mapping	Allows public key software to access the proof materials needed to open keys, provide authorization tokens, and provide auditing tokens.

The specifications for the SPIs are currently only available to third-party security vendors who have entered into a special agreement with Oracle Systems, Inc. Customers who want to customize a security feature must contact one of these vendors or Oracle Professional Services. For example, an Oracle customer who wants a custom implementation of public key security must contact a third-party vendor who can provide the appropriate security plug-in or Oracle Professional Services.

For more information about security plug-ins, including installation and configuration procedures, see your Oracle account executive.