For more information on server-side and client-side authentication, see “Authenticating clients with usernames and passwords”.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. The KeyStore in VisiSecure for C++ refers to a directory structure similar to a trustpointRepository, which contains the certificate chain.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, see “VisiSecure for C++ APIs” and “Security SPI for C++”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”” 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.If you do not want to use KeyStores directly, you can import certificates and private keys using the CertificateFactoryAPI. This class also supports the pkcs12 file format.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.There are several properties that can be used to ensure connection Quality of Protection. The VisiBroker ORB security properties for C++ 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.Setting up of trust can be done through property vbroker.security.trustpointRepository=Directory:<path to directory>, where the directory contains the trusted certificates.Other trust policies are set in the QoP configurations. See “Step Two: Setting properties and Quality of Protection (QoP)”.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 getCallerSubject 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.It is important to note that the 'manager.type' and the 'listener.type' must be initialized to the values indicated above whereas the 'dispatcher.type' can be any of the allowable types. The default value is ThreadPool. (For more information, see ”Managing Threads and Connections” in the VisiBroker for C++ Developer's Guide.)VisiBroker provides APIs to inspect and set SSL-related information. The SecureContext API is used to 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.