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”.
You can use the same APIs discussed in “Username/password authentication, using APIs” on page 96 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.
You can use the same APIs discussed in “Username/password authentication, using APIs” on page 96 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.
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.
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.
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.
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.
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.
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.
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.
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.