Skip navigation.

Using Security in CORBA Applications

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents Index View as PDF   Get Adobe Reader

Managing Public Key Security

This topic includes the following sections:

Perform the tasks in this topic only if you are using the SSL protocol, or certificate authentication in your CORBA application.

Note: The BEA Tuxedo CORBA Java client and BEA Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported in Tuxedo 9.0.

All BEA Tuxedo CORBA Java client and BEA Tuxedo CORBA Java client ORB text references, associated code samples, etc. should only be used:

Technical support for third party CORBA Java ORBs should be provided by their respective vendors. BEA Tuxedo does not provide any technical support or documentation for third party CORBA Java ORBs.


Requirements for Using Public Key Security

To use the SSL protocol and public key security to protect communication between principals and the BEA Tuxedo domain, you need to install a special license. For information about installing the license, see Installing the BEA Tuxedo System.

You also need to choose a Lightweight Directory Access Protocol server and a certificate authority (either commercial or private) setup for your organization before implementing Public Key Security.


Who Needs Digital Certificates and Private/Private Key Pairs?

To use the SSL protocol in the CORBA security environment, you need a private key and a digitally-signed certificate containing the matching public key. How many digital certificates and private keys you need depends on how you plan to use the SSL protocol.

Any digital certificate that is obtained and used must be issued from a trusted certificate authority defined in the trusted CA file. For more information, see Defining the Trusted Certificate Authorities.


Requesting a Digital Certificate

To acquire a digital certificate, you need to submit your request for a digital certificate in a particular format called a certificate signature request (CSR). How you create a CSR depends on the certificate authority you use. Certificate authorities typically provide a means to generate a public key, private key, and a CSR which contains your public key. To create a CSR follow the steps outlined by your chosen certificate authority.

When you complete the steps to create a CSR, you receive the following files from the certificate authority:




The private key file.


The CSR file which you submit to the certificate authority. It contains the same data as the .dem file but the file is encoded in ASCII so that you can copy it into e-mail or paste it into a Web form.


To purchase a digital certificate from a certificate authority, you submit the CSR to the certificate authority according to the enrollment procedure of the certificate authority. Some commercial certificate authorities allow you to purchase digital certificates through the Web.


Publishing Certificates in the LDAP Directory Service

The use of a global directory service is the most popular way to store digital certificates. A directory service simplifies the management of information that needs to be globally available to an ever-growing number of users. An LDAP server provides access to a variety of directory services.

The CORBA security environment in the BEA Tuxedo product, when configured to use the SSL protocol, can retrieve digital certificates for principals and certificate authorities from an LDAP directory service, such as Netscape Directory Service or Microsoft Active Directory. Before you can use the SSL protocol or certificate authentication, you need to install an LDAP directory service and configure it for your organization. BEA Systems does not provide nor recommend any specific LDAP directory service. However, the LDAP directory service you choose should support the X.500 scheme definition and the LDAP version 2 or 3 protocol.

LDAP directory services define a hierarchy of object classes. While there are a number of different object classes, there is a small set associated with digital certificates. Figure 4-1 illustrates the object classes typically associated with digital certificates.

Figure 4-1 LDAP Directory Structure for Digital Certificates

LDAP Directory Structure for Digital Certificates



Once you receive your digital certificates from the certificate authority, store them in the LDAP directory service as follows:

If your LDAP scheme requires the use of different classes, you will need to modify the LDAP search file as described in Editing the LDAP Search Filter File.

The BEA Tuxedo product requires that the digital certificates be stored in the directory service in Privacy Enhanced Mail (PEM) format.

Refer to Installing the BEA Tuxedo System for information about integrating an LDAP directory service into the CORBA security environment.


Editing the LDAP Search Filter File

When configuring a CORBA application to use the SSL protocol or certificate authentication, you may need to customize the LDAP search filter file to limit the scope of the search of the directory service or specify the object classes that will be used to hold the digital certificates. Customizing the LDAP search filter file can result in significant performance gains. The BEA Tuxedo product ships with the following LDAP search filters:

If the directory service scheme for your organization is defined to store digital certificates in object classes other than certificationAuthority and strongAuthenticationUser, the LDAP search filter file must be modified to specify those object classes.

You can specify a location of the LDAP search filter file during the installation of the BEA Tuxedo product. For more information, see Installing the BEA Tuxedo System.

The LDAP search filter file should be owned by the administrator account. BEA recommends that the file be protected so that only the owner has read and write privileges for the file and all other users have only read privileges for the file.

To limit the search of the directory service for digital certificates for principals and certificate authorities, you need to modify the filter stanzas identified by the following tags in the LDAP search filter file:

These tags identify the stanzas in the LDAP search filter file that contains the filter expression that will be used when looking up information in the directory service. These BEA-specific tags allow the stanzas of an LDAP search filter file to be stored in a common LDAP search filter file with stanzas used by other LDAP-enabled applications that might be found in your organization.

The following is an example of the stanzas of an LDAP search filter file used by the BEA Tuxedo product for the SSL protocol and certificate authentication:

".*" " " "(|(objectClass=strongAuthenticationUser) (mail=%v))"
"e-mail address"
"(|(objectClass=strongAuthenticationUser) (mail=%v))"
"start of e-mail address"
".*" " " "(&(objectClass=certificationAuthority)
(cn=%v)" "exact match cn"
(sn=%v))" "exact match sn"

See the documentation for your LDAP-enabled directory service for additional information about LDAP search file filters.


Storing the Private Keys in a Common Location

When a principal generates a CSR, they typically get a file with a private key. Principals need this private key file to verify their identity in the authentication process. Assign the private key file protections so that only the owner of the private key file has read privileges and all other users have no privileges to access the file. Private key files must be stored as PEM-encoded PKCS #8 protected format.

The BEA Tuxedo system uses the e-mail address of the principal to construct a name for the private key file as follows:

  1. The @ character in the name is replaced by an underscore (_) character.
  2. All characters after the dot (.) character are deleted.
  3. A .PEM file extension is appended to the file.

For example, if the name of the principal is the resulting private key file is milozzi_bigcompany.pem. This naming convention allows an enterprise to have multiple principals that share a common username but are in different e-mail domains.

The BEA Tuxedo software looks in the following directories for private key files:

Window 2000




The BEA Tuxedo software also looks in the following directory for private key files:


The $TUXDIR/udataobj/security/keys directory should be protected so that only the owner has read privileges for the directory and all other users do not have privileges to access the directory.

Listing 4-1 provides an example of a private key file.

Listing 4-1 Example of Private Key File



Defining the Trusted Certificate Authorities

When establishing an SSL connection, the CORBA processes (client applications and the IIOP Listener/Handler) check the identity of the certificate authority and certificates from the peer's digital certificate chain against a list of trusted certificate authorities to ensure the certificate authority is trusted by the organization. This check is similar to the check done in Web browsers. If the comparison fails, the initiator of the SSL connection refuses to authenticate the target and drops the SSL connection. It is typically the job of the system administrator to define a list of trusted certificate authorities.

Retrieve from the LDAP directory service the digital certificates for the certificate authorities that are to be trusted. Cut and paste the PEM formatted digital certificates into a file named trust_ca.cer which is stored in $TUXDIR/udataobj/security/certs. The trust_ca.cer can be edited with any text editor.

The trust_ca.cer file should be owned by the administrator account. BEA recommends that the file be protected so that only the owner has read and write privileges for the file and all other users have only read privileges for the file.

Listing 4-2 provides an example of a Trusted Certificate Authority file.

Listing 4-2 Example of Trusted Certificate Authority File



Creating a Peer Rules File

When communicating across network links, it is important to validate the peer to which you are connected is the intended or authorized peer. Without this check, it is possible to make a secure connection, exchange secure messages, and receive a valid chain of digital certificates but still be vulnerable to a Man-in-the-Middle attack. You perform peer validation by verifying a set of specified information contained in the peer digital certificate against a list of information that specifies the rules for validating peer trust. The system administrator maintains the Peer Rules file.

The Peer Rules are maintained in an ASCII file named peer_val.rul. Store the peer_val.rul file in the following location in the BEA Tuxedo directory structure:


Listing 4-3 provides an example of a Peer Rules file.

Listing 4-3 Example of Peer Rules File

# This file contains the list of rules for validating if
# a peer is authorized as the target of a secure connection
O=Ace Industry
O="Acme Systems, Inc."; OU=Central Engineering;L=Herkimer;S=NY
O="Ball, Corp.", C=US
o=Ace Industry, ou=QA,

Each rule in the Peer Rules file is comprised of a set of elements that are identified by a key. The BEA Tuxedo product recognizes the key names listed in Table 4-1.

Table 4-1 Supported Keys for Peer Rules File 




















Each key is followed by an optional white space, the character =, an optional white space, and finally the value to be compared. The key is not case sensitive. A rule is not a match unless the subject's distinguished name contains each of the specified elements in the rule and the values of those elements match the values specified in the rule, including case and punctuation.

Each line in the Peer Rules file contains a single rule that is used to determine if a secure connection is to be established. Rules cannot span lines; the entire rule must appear on a single line. Each element in the rule can be separated by either a comma (,) or semicolon (;) character.

Lines beginning with the pound character (#) are comments. Comments cannot appear on the same line as the name of an organization.

A value must be enclosed in single quotation marks if one of the following cases is true:

By default, the BEA Tuxedo product verifies peer information against the Peer Rules file. If you do not want to perform this check, create an empty Peer Rules file.


Skip navigation bar  Back to Top Previous Next