Configuring inbound CSIv2 transport layer

You can configure a Liberty server to claim support for client certificate authentication for inbound CSIv2 requests.

1. Add the appSecurity-2.0 and ejbRemote-3.2 features in the server.xml file.

   
       <featureManager>
           <feature>appSecurity-2.0</feature>
           <feature>ejbRemote-3.2</feature>
       </featureManager>

   The following example is the default configuration without having to specify it in the server.xml file.

   
       <orb id="defaultOrb">
           <serverPolicy.csiv2>
               <layers>
                   <attributeLayer identityAssertionEnabled="false"/>
                   <authenticationLayer mechanisms="LTPA,GSSUP" establishTrustInClient="Required"/>
                   <transportLayer/>
               </layers>
           </serverPolicy.csiv2>
           <clientPolicy.csiv2>
               <layers>
                   <attributeLayer identityAssertionEnabled="false"/>
                   <authenticationLayer mechanisms="LTPA,GSSUP" establishTrustInClient="Supported"/>
                   <transportLayer/>
               </layers>
           </clientPolicy.csiv2>
       </orb>
   

2. Configure SSL support as described in the Enabling SSL communication in Liberty page.
3. Configure the SSL element to use clientAuthentication or clientAuthenticationSupported.
   For example,

   
       <ssl id="defaultSSLConfig" keyStoreRef="defaultKeyStore" 
            trustStoreRef="defaultTrustStore" clientAuthentication="true" />
   

   or

   
       <ssl id="defaultSSLConfig" keyStoreRef="defaultKeyStore" 
            trustStoreRef="defaultTrustStore" clientAuthenticationSupported="true" />
   

   • If you specify clientAuthentication="true", then the server requests that a client sends a certificate. However, if the client does not have a certificate or if the certificate is not trusted by the server, then the handshake does not succeed.
   • If you specify clientAuthenticationSupported="true", then the server requests that a client sends a certificate. However, if the client does not have a certificate or if the certificate is not trusted by the server, then the handshake might still succeed.
   • If you do not specify either clientAuthentication or clientAuthenticationSupported, or if you specify clientAuthentication="false" or clientAuthenticationSupported="false", then the server does not request the client to send a certificate during the handshake.
4. Optional: If you need to change the default inbound transport layer configuration, then add an <orb> element in the server.xml file as follows or add the transportLayer element to an existing one. Replace the sample values in the example with your values.

   
           <orb id="defaultOrb">
               <serverPolicy.csiv2>
                   <layers>
                       <transportLayer sslRef="defaultSSLConfig"/>
                   </layers>
               </serverPolicy.csiv2>
           </orb>
   

   Note: The ID value defaultOrb in the <orb> element is predefined and cannot be modified.
5. Make sure the server trusts any client certificates that are used.
6. Make sure any client certificates that are used for client authentication are mapped to a user identity in your registry.
   • For the basic registry, the user identity is the common name (CN) from the distinguished name (DN) of the certificate.
   • For a Lightweight Directory Access Protocol (LDAP) registry, the DN from the client certificate must be in the LDAP registry.

   Omitting a layer uses the default values for that layer. For more information about attributeLayer and authenticationLayer elements, see Configuring inbound CSIv2 attribute layer and Configuring inbound CSIv2 authentication layer.