Security Guide : Creating Secure CORBA Applications Using Java

Creating Secure CORBA Applications Using Java
This section describes the use of VisiSecure to make secure connections for CORBA applications using Java.
Steps to secure clients and servers
Listed below are the common steps required for developing a secure client or secure server. For CORBA users the properties are all stored in files that are located through config files. Wherever appropriate the usage models for clients and servers are separately discussed. All properties can be set in the VisiBroker Management Console by right-clicking the node of interest in the Navigation Pane and selecting “Edit Properties.”
Note
These steps are similar for both Java and C++ applications.
Step One: Providing an identity
An identity can be a username/password/realm triad, or certificates can be used. These can be collected through JAAS modules or through APIs.
Clients
For clients using usernames and passwords, there can be constraints about what the client knows about the server's realms. Clients may have intimate knowledge of the server's supported realms or none at all at the time of identity inquiry. Note also that clients authenticate at the server end.
Servers
For servers using username and password identities, authentication is performed locally since the realms are always known.
There can be constraints on certificate identities as well, depending on whether they are stored in a KeyStore or whether they are specified through APIs.
Keeping these constraints in mind, the VisiSecure Server supports the following usage models, any of which could be used to provide an identity to the server or client:
Username/password authentication, using JAAS
modules, for known realms
If the realm to which the client wishes to authenticate is known, the client-side JAAS configuration would take the following form:
vbroker.security.login=true
vbroker.security.login.realms=<known-realm>
Username/password authentication, using APIs
The following code sample demonstrates the use of the login APIs. This case uses a wallet. For a full description of the four login modes supported, go to the VisiSecure for Java API and SPI sections.
public static void main(String[] args) {
//initialize the ORB
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);
com.borland.security.Context ctx = (com.borland.security.Context)
orb.resolve_initial_references("VBSecurityContext");
if(ctx != null) {
com.borland.securty.IdentityWallet wallet =
new com.borland.security.IdentityWallet(<username>,
<password>.toCharArray(), <realm>);
ctx.login(wallet);
}
}
Certificate-based authentication, using KeyStores via property settings
By setting the property vbroker.security.login.realms=Certificate#ALL, the client will be prompted for keystore location and access information. For valid values, see “Certificate mechanism”.
Certificate-based authentication, using KeyStores via APIs
You can use the same APIs discussed in “Username/password authentication, using APIs” to login using certificates through KeyStores. The realm name in the IdentityWallet should be CERTIFICATE#ALL, the username corresponds to an alias name in the default KeyStore that refers to a Key entry, and the password refers to the Private Key password (also the KeyStore password) corresponding to the same Key entry.
Certificate-based authentication, using APIs
If you do not want to use KeyStores directly, you can specify certificates and private keys using the CertificateWalletAPI. This class also supports the pkcs12 file format.
X509Certificate[] certChain = ...list-of-X509-certificates...
PrivateKey privKey = private-key
com.borland.security.CertificateWallet wallet =
new com.borland.security.CertificateWallet(alias,
certChain, privKey, "password".toCharArray());
The first argument in the new Certificate wallet is an alias to the entry in the KeyStore, if any. If you are not using keystores, set this argument to null.
pkcs12-based authentication, using KeyStores
You can use the same APIs discussed in “Username/password authentication, using APIs” to login using pkcs12 KeyStores. The realm name in the IdentityWallet should be CERTIFICATE#ALL, the username corresponds to an alias name in the default KeyStore that refers to a Key entry, and the password refers to the password needed to unlock the pkcs12 file. The property javax.net.ssl.KeyStore specifies the location of the pkcs12 file.
pkcs12-based authentication, using APIs
See “Certificate-based authentication, using APIs”.
Step Two: Setting properties and Quality of Protection (QoP)
There are several properties that can be used to ensure connection Quality of Protection. The VisiBroker ORB security properties for Java can be used to fine-tune connection quality. For example, you can set the cipherList property for SSL connections to set cryptography strength.
QoP policies can be set using the ServerQoPConfig and the ClientQoPConfig APIs for servers and clients, respectively. These APIs allow you set target trust (whether or not targets must authenticate), the transport policy (whether or not to use SSL or another secure transport mechanism specified separately), and, for servers, an AccessPolicyManager that can access the RoleDB to set access policies for POA objects. For QoP API information, go to the VisiSecure for Java API and SPI book.
Step Three: Setting up Trust
Use the API setTrustManager for the proper security context to provide an X509TrustManager interface implementation. If you have certificates that need to be trusted, place them in a KeyStore and use javax.net.ssl.trustStore property to set it. A default X509TrustManager provided by the security service will be used if one is not provided.
Other trust policies are set in the QoP configurations. See “Step Two: Setting properties and Quality of Protection (QoP)”.
Step Four: Setting up the Pseudo-Random Number Generator
Setting up the PRNG is required if you intend to use SSL communication.
1
Construct a SecureRandom object and seed it.
2
Set this object as your PRNG by using the com.borland.security.Context interface, setSecureRandom method.
For detailed information on the com.borland.security.Context interface, see the VisiSecure for Java API and SPI.
Step Five: If necessary, set up identity assertion
When a client invokes a method in a mid-tier server which, in the context of this request, invokes an end-tier server, then the identity of the client is internally asserted by the mid-tier server by default. Therefore, if getCallerPrincipal is called on the end-tier server, it will return the Client's principal. Here the client's identity is asserted by the mid-tier server. The identity can be a username or certificate. The client's private credentials such as private keys or passwords are not propagated on assertion. This implies that such an identity cannot be authenticated at the end-tier.
If the user would like to override the default identity assertion, there are APIs available to assert a given Principal. These APIs can be called only on mid-tier servers in the context of an invocation and with special permissions. For more information, see the VisiSecure for Java API and SPI.
Examining SSL related information
VisiSecure provides APIs to inspect and set SSL-related information. The SecureContext API is used to specify a Trust Manager, PRNG, inspect the SSL cipher suites, and enable select ciphers.
Clients
To examine peer certificates, use getPeerSession() to return an SSLSession object associated with the target. You can then use standard JSSE APIs to obtain the information therein.
Servers
To examine peer certificates on the server side, you set up the SSL connection with com.borland.security.Context and use the APIs with com.borland.security.Current to examine the SSLSession object associated with the thread.
SSL Example
The Bank SSL example included in the visibroker\examples directory contains a simple Bank interface to open a bank account and to query the balance. It illustrates basic communication using the ORB and SSL with VisiBroker for C++ and Java. In addition, this example demonstrates a modular approach to security by moving the code required to setup an SSL connection into initializers and properties.
From this example, you will learn how to:
Install a certificate in the trustpoint repository using the API or the property vbroker.security.trustpointsRepository
To run the example:
1
2
make -f Makefile_java on UNIX, or
nmake /f Makefile_java on Windows
This will run the Bank.idl through the idl2java compiler. It will also build SecureServer.class, SecureClient.class and other class files.
3
The old method of inserting a certificate chain by using API setPKprincipal using (byte [][]derCertChain, byte[] privateKey, String passPhrase)) and resolving initial reference of "SecurityCurrent" on the ORB, still exists for backward compatibility. In this case, the requirement is the setPKPrincipal() API should be called prior to calling resolve_initial_references() API.
4
prompt> vbj -DORBpropStorage=java_server.properties SecureServer
(start vbj -DORBpropStorage=java_server.properties SecureServer on Windows)
5
prompt> SecureServer -DORBpropStorage=cpp_server.properties \ -Dvbroker.orb.dynamicLibs="path to the dynamic library"/Init.so &
(start SecureServer ...args... on Windows)
6
prompt>vbj -DORBpropStorage=java_client.properties SecureClient
7
prompt>SecureClient -DORBpropStorage=cpp_client.properties
8
byte [][] certChain = {
user_cert_1.getBytes (),
user_cert_2.getBytes (),
user_cert_3.getBytes (),
user_cert_4.getBytes (),
ca_cert.getBytes ()
};
9
com.borland.security.provider.CertificateWallet wallet =
new com.borland.security.provider.CertificateWallet (null, certChain,
encryptedPrivateKey.getBytes (), "Delt@$$$".toCharArray());