Interoperating with a C++ common object request broker architecture client

 

You can achieve interoperability of SAS between the C++ CORBA client and WebSphere Application Server using CSIv2 authentication protocol over Remote Method Invocation over the Internet Inter-ORB Protocol (RMI-IIOP). The CSIv2 security service protocol has authentication, attribute and transport layers. Among the three layers, transport authentication is conceptually simple, however, cryptographically based transport authentication is the strongest. WAS Enterprise has implemented the transport authentication layer, so that C++ secure CORBA clients can use it effectively in making CORBA clients and protected enterprise bean resources work together.

Security authentication from non-Java based C++ client to enterprise beans. WAS supports security in the CORBA C++ client to access protected enterprise beans. If configured, C++ CORBA clients can access protected enterprise bean methods using client certificate to achieve mutual authentication on WAS Enterprise applications.

To support the C++ CORBA client in accessing protected enterprise beans:

C++ security setting Description
client_protocol_password Specifies the password for the user ID.
client_protocol_user Specifies the user ID to be authenticated at the target server.
security_sslKeyring Name of the RACF keyring the client will use. The keyring must be defined under the user ID that is issuing the command to run the client.

To support the C++ CORBA client in accessing protected enterprise beans...

  1. Obtain a valid certificate to represent the client and export its public key to the target enterprise bean server.

    A valid certificate is needed to represent the C++ client. Request a certificate from the certificate authority (CA) or create a self-signed certificate for testing purposes.

    Use the Key Management Utility from the GSKit to extract the public key from the personal certificate and save it in the .arm format. For details, see the related information about how to extract the personal certificate of the public key.

  2. Prepare a truststore file for WAS.

    Add the extracted client public key in the .arm file from the client to the server key truststore file. The server can now authenticate the client.

    This is done by invoking the Key Management Utility through ikeyman.bat or ikeyman.sh from WAS installation.For details, see the article on Adding truststore files.

  3. Configure WAS to support SSL as the authentication mechanism.

    1. Start the administrative console.

    2. Locate the appserver that has the target enterprise bean deployed and configure it to use SSL client certificate authentication.

      If it is a base installation, go to Security > Authentication Protocol > CSIv2 Inbound Authentication then select Supported for Basic Authentication and Client Certificate Authentication and leave the rest as defaults. Go to the CSIv2 Inbound Transport and make sure SSL-Supported is selected.

      If it is a Network Deployment setting, go to Server > Application Server > server_name_where_EJB_resides > Server Security > CSI Authentication Inbound. Then select Supported for Basic Authentication and Client Certificate Authentication. Leave the rest as defaults. Go to CSI Transport > Inbound to make sure SSL-Supported is selected.

      For details, see the security articles Configuring CSIv2 inbound authentication and Configuring CSIv2 inbound transport.

    3. Restart the appserver.

      The WebSphere Application Server is ready to take a C++ CORBA security client and a mutually authenticated server and client by using SSL in the transport layer.

  4. Configure the C++ CORBA client to use a certificate in performing the mutual authentication.

    Client users are accustomed to using property files in their applications because they are helpful in specifying configuration settings. The following list presents important C++ security settings...

    C++ security setting Description
    com.ibm.CORBA.bootstrapHostName=ricebella.amsterdam.setgetweb.com Specifies the target host name.
    com.ibm.CORBA.securityEnabled=yes Enables security.
    com.ibm.CSI.performTLClientAuthenticationSupported=yes Ensures client is supporting mutual authentication by certificate
    com.ibm.CSI.performTransportAssocSSLTLSSupported=yes Ensures SSL is used, not TCP/IP
    com.ibm.ssl.keyFile=C:/ricebella/etc/DummyKeyRingFile.KDB Specifies which key database file to use.
    com.ibm.ssl.keyPassword=WebAS Specifies the password for opening the key database file. WAS supports a utility called PasswordEncode4cpp to encode the plain password.
    com.ibm.CORBA.translationEnabled=1 Enables the valueType conversion.

    To use the property files in running a C++ client, an environment variable WASPROPS, is used to indicate where a property file or a list of property files exist.

    For the complete set of C++ client properties, see the sample property file scclient.props, which is shipped with the product located in the $$WAS_HOME\etc directory.

 

See Also

Extracting public certificates for truststore files
Configuring CSIv2 inbound authentication
Configuring inbound transports

 

Interoperability with C++ CORBA client support and limitations

 

In addition to the WebSphere base installation, you can choose from two types of C++ CORBA client support:

  1. IBM WAS Enterprise v5
  2. IBM WAS Client v5

If you plan to develop or rebuild your own C++ client applications, then the Enterprise version is required. It installs tools, libraries, and include files for the build environment in selecting C++ CORBA client SDK. Otherwise, a client installation suffices to run your C++ client applications with security. In Version 5, WAS supports the C++ CORBA client on the Windows 2000, Windows NT, Linux, and AIX operating systems and the Solaris operating environment.

SSL Version 2 (SSLV2) cipher suites are not supported. In Version 5, only the most commonly used ciphers among JSSE and Global Security Kit (GSkit) are supported.

Since the WebSphere Enterprise CORBA C++ Client has only implemented security on the transport layer, other authentication mechanisms such as user ID and password (Basic Authentication) are not supported.