Security - 2

This is the third entry in the series about certificate login for SOAP web-services in wildfly. In the first post all the certificate setup was configured, the wildfly configuration used the new subsystem elytron to add mutual TLS authentication. In the next entry javaee security was integrated and the certificate was used to log the user in using the standard CLIENT-CERT method. In today's entry, instead of TLS, we are going to use the WS-Security extensions for SOAP. I have divided the subject in another two entries, same idea than in the previous two, this one is the setup for WS-Security and the next one will add the JavaEE integration.

The WS-Security or WSS is an extension to SOAP to apply different security measures to the communication (always using SOAP headers inside the message). Non-repudiation is one of the features that can be accomplished with it and, obviously, it consists in a certificate signature. My idea was singing the message and using that signature (the certificate in it) to log the user into the application. It is important to understand that this technique is completely different to the one used in the previous entries. Now the certificate is not going to be requested at TLS level (indeed that part of the configuration is going to be removed), the communication is going to be https (secure) but the client certificate is not going to be presented (no client or mutual authentication is used at this level). The SOAP message itself is going to be signed (using WS-Security extensions) and the certificate in the signature is the one used to log the user in (although the JavaEE integration will be shown in the next entry). Please, take this into account, this entry is completely different to the previous two in the series. Wildfly uses Apache WSS4J for WS-Security implementation, and it is not part of the JavaEE standard, so today's application is going to use a lot of classes from the CXF/WSS4J/Wildfly implementation (the solution is only designed for this app container).

1. First the configuration for compulsory client authentication was removed. Now the client is not going to send any certificate at this level.

   
   /subsystem=elytron/server-ssl-context=localhost-context:write-attribute(name=need-client-auth, value=false)
   

2. There is a lot of documentation in the wildfly site but, in general, the process to setup WS-Security is quite complicated. The Echo endpoint needs to be annotated with two special tags to establish WS-Security. Besides the web method is again annotated as @PermitAll to permit the execution for anonymous (not logged) users.

   
   @Stateless
   @WebService(name = "echo",
           targetNamespace = "http://es.rickyepoderi.sample/ws",
           serviceName = "echo-service")
   @Policy(placement = Policy.Placement.BINDING, uri = "WssX509V3Token10.xml")
   @DeclareRoles("Users")
   @SOAPBinding(style = SOAPBinding.Style.RPC)
   @EndpointConfig(configFile = "WEB-INF/jaxws-endpoint-config.xml", configName = "Custom WS-Security Endpoint")
   public class Echo {
       @Resource SessionContext ctx;
   
       @WebMethod
       @PermitAll
       public String echo(String input) {
           return ctx.getCallerPrincipal() + " -> " +  input;
       }
   }
   

3. The @Policy annotation is used to specify we want a special WSS policy for the binding. The WssX509V3Token10.xml file includes the following:

   
   <?xml version="1.0" encoding="UTF-8" ?>
   <wsp:Policy wsu:Id="SecurityPolicy" 
               xmlns:wsp="http://www.w3.org/ns/ws-policy"
               xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
               xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
     <wsp:ExactlyOne>
       <wsp:All>
         <sp:AsymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
           <wsp:Policy>
             <sp:InitiatorToken>
               <wsp:Policy>
                 <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
                   <wsp:Policy>
                     <sp:WssX509V1Token11/>
                   </wsp:Policy>
                   </sp:X509Token>
               </wsp:Policy>
             </sp:InitiatorToken>
             <sp:RecipientToken>
               <wsp:Policy>
                 <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never">
                   <wsp:Policy>
                     <sp:WssX509V1Token11/>
                   </wsp:Policy>
                 </sp:X509Token>
               </wsp:Policy>
             </sp:RecipientToken>
             <sp:AlgorithmSuite>
               <wsp:Policy>
                 <sp:Basic256Sha256Rsa15/>
               </wsp:Policy>
             </sp:AlgorithmSuite>
             <sp:Layout>
               <wsp:Policy>
                 <sp:Lax/>
               </wsp:Policy>
             </sp:Layout>
             <sp:IncludeTimestamp/>
             <sp:ProtectTokens />
             <sp:OnlySignEntireHeadersAndBody/>
           </wsp:Policy>
         </sp:AsymmetricBinding>
         <sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
           <sp:Body/>
         </sp:SignedParts>
         <sp:Wss10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
           <wsp:Policy>
             <sp:MustSupportRefIssuerSerial/>
           </wsp:Policy>
         </sp:Wss10>
       </wsp:All>
     </wsp:ExactlyOne>
   </wsp:Policy>
   

   The configuration says that the body of the message is going to be signed using SHA256 and an asymmetric RSA key. The certificate should also be added as a binary token (WssX509V1Token11). Only signature is used cos the communication is already encrypted using https at TLS level. Using this extra policy the final WSDL generated by the server adds all this WSS configuration and the client knows that extra security data should be sent. I know that understanding this WSS configuration is very complicated, but I found some good examples at OASIS site.

4. Then the @EndpointConfig is used to configure the Apache CXF/WSS4J implementation. The file jaxws-endpoint-config.xml contains the following:

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" 
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xmlns:javaee="http://java.sun.com/xml/ns/javaee" 
              xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
  <endpoint-config>
    <config-name>Custom WS-Security Endpoint</config-name>
    <property>
      <property-name>ws-security.signature.properties</property-name>
      <property-value>server.properties</property-value>
    </property>
    <property>
      <property-name>ws-security.signature.username</property-name>
      <property-value>server</property-value>
    </property>
    <property>
      <property-name>ws-security.callback-handler</property-name>
      <property-value>es.rickyepoderi.sample.KeystorePasswordCallback</property-value>
    </property>
    <property>
      <property-name>ws-security.enableRevocation</property-name>
      <property-value>true</property-value>
    </property>
    <property>
      <property-name>ws-security.subject.cert.constraints</property-name>
      <property-value>.*O=demo.kvm.*</property-value>
    </property>
  </endpoint-config>
</jaxws-config>

The properties file is used to configure the key-store used by the server to verify request signatures and sign responses. The callback is used to obtain the password for the key (my callback always return the same password, it's the same for all the stores). The revocation was enabled to discover that client2 certificate is not valid. And a subject expression is added (the subject of the certificate should match this expression) just to avoid an annoying warning message.

4. The server.properties has the real information for the key-store and CRL file (all the files are packaged with the application):

   
   org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
   org.apache.wss4j.crypto.merlin.x509crl.file=my.crl
   org.apache.ws.security.crypto.merlin.keystore.type=jks
   org.apache.ws.security.crypto.merlin.keystore.password=Kiosko_00
   org.apache.ws.security.crypto.merlin.keystore.alias=server
   org.apache.ws.security.crypto.merlin.keystore.file=server.jks
   

   The server.jks contains the private key for the server (the same certificate used in previous entries entries to configure the https port) and the trusted CA for the clients.

   
   keytool -list -keystore ./src/main/resources/server.jks 
   
   Keystore type: JKS
   Keystore provider: SUN
   
   Your keystore contains 2 entries
   
   ca, Dec 18, 2017, trustedCertEntry, 
   Certificate fingerprint (SHA1): A1:A4:8B:7B:85:1B:EB:48:85:56:50:A8:34:74:41:74:2B:4E:B6:69
   server, Nov 29, 2017, PrivateKeyEntry, 
   Certificate fingerprint (SHA1): 66:AE:A8:33:BC:4F:23:79:02:E6:E3:47:97:C8:B7:AA:40:75:BA:C5
   

   In general all the WSS4J properties and policy configuration can be assigned using the previous files.

5. Now we need to prepare the client, more or less the same configuration given to the server is needed for the client. But here the configuration is setup as CXF properties in the BindingProvider.

   
       URL url = new URL("https://localhost:8443/wildfly-x509/echo-service/echo?wsdl");
       EchoService service = new EchoService(url);
       Echo echo = service.getEchoPort();
       // Properties for WS-Security configuration
       ((BindingProvider)echo).getRequestContext().put(SecurityConstants.CALLBACK_HANDLER, new KeystorePasswordCallback());
       ((BindingProvider)echo).getRequestContext().put(SecurityConstants.SIGNATURE_PROPERTIES, Thread.currentThread().getContextClassLoader().getResource("client1.properties"));
       ((BindingProvider)echo).getRequestContext().put(SecurityConstants.SIGNATURE_USERNAME, "client1");
       // get the client and assign a specific SSLContext configuration
       Client client = ClientProxy.getClient(echo);
       HTTPConduit http = (HTTPConduit) client.getConduit();
       TLSClientParameters parameters = new TLSClientParameters();
       parameters.setSSLSocketFactory(createSSLContext(args[0]).getSocketFactory());
       http.setTlsClientParameters(parameters);
       System.err.println(echo.echo(args[1]));
   

   If you see the same properties are specified (the properties file, the username and the password callback for the key).

   The file client1.properties contains the store used by the client:

   
   org.apache.wss4j.crypto.provider=org.apache.wss4j.common.crypto.Merlin
   org.apache.wss4j.crypto.merlin.keystore.type=jks
   org.apache.wss4j.crypto.merlin.keystore.password=Kiosko_00
   org.apache.wss4j.crypto.merlin.keystore.alias=client1
   org.apache.wss4j.crypto.merlin.keystore.file=client1.jks
   

   The store is just the valid client1 certificate and key, the trusted CA and the server certificate (in this case the server cert needs to be added for the client to trust in the server response):

   
   keytool -list -keystore ./src/main/resources/client1.jks
   
   Keystore type: JKS
   Keystore provider: SUN
   
   Your keystore contains 3 entries
   
   ca, Dec 18, 2017, trustedCertEntry, 
   Certificate fingerprint (SHA1): A1:A4:8B:7B:85:1B:EB:48:85:56:50:A8:34:74:41:74:2B:4E:B6:69
   client1, Dec 18, 2017, PrivateKeyEntry, 
   Certificate fingerprint (SHA1): 2D:2D:11:BF:DB:6E:EB:2D:10:9D:09:BE:96:7C:B9:3D:AF:8B:A7:89
   server, Dec 18, 2017, trustedCertEntry, 
   Certificate fingerprint (SHA1): 66:AE:A8:33:BC:4F:23:79:02:E6:E3:47:97:C8:B7:AA:40:75:BA:C5
   

   The same configuration is done for client2. The client is also modified to receive client1 or client2 parameter and use one or the other configuration to sign the message.

6. At this point everything is ready. If authentication is disabled in web.xml (no JavaEE integration) the @PermitAll annotation lets us execute the method as anonymous. I also added the system property -Dorg.apache.cxf.logging.enabled=true in the server to dump the SOAP messages interchanged. So the video now is more or less the same. First the client2 is used to sign the message and it is not valid because of the revocation. Then the maven project is executed with the client1 configuration. When executed the server receives the client1 certificate and signature, validates it and finally executes the method. The response is also signed and validated by the client. As there is no JavaEE integration, anonymous user is presented again. But the important thing is that all the WSS headers are in place, they are printed in the server.

7. Let's examine the messages. This is the request sent by the client when using client1:

   
   <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
     <soap:Header>
       <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soap:mustUnderstand="1">
         <wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="X509-f40f60f5-64b4-4135-b7e0-fd8348d00c3a">...X509...Client1...certtificate...</wsse:BinarySecurityToken>
         <wsu:Timestamp wsu:Id="TS-02fe948b-e2ac-477f-ada4-abaac47fc4f1">
           <wsu:Created>2017-12-23T14:02:05.321Z</wsu:Created>
           <wsu:Expires>2017-12-23T14:07:05.321Z</wsu:Expires>
         </wsu:Timestamp>
         <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="SIG-3a786e4f-80bb-4283-a834-40de53b4da54">
           <ds:SignedInfo>
             <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
               <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="soap"/>
             </ds:CanonicalizationMethod>
             <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
             <ds:Reference URI="#TS-02fe948b-e2ac-477f-ada4-abaac47fc4f1">
               <ds:Transforms>
                 <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                   <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse soap"/>
                 </ds:Transform>
               </ds:Transforms>
               <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
               <ds:DigestValue>GUQXfHsUaDwGCEEerkqLWmIqmYdEdn52kK5eRCVd2Hg=</ds:DigestValue>
             </ds:Reference>
             <ds:Reference URI="#_e8f02c45-106a-4c8e-b0ad-4252be04b7ef">
               <ds:Transforms>
                 <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
               </ds:Transforms>
               <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
               <ds:DigestValue>TeGgjqgupN/UMYOybuACCUeN2P20z120wDhTO0rb9no=</ds:DigestValue>
             </ds:Reference>
               <ds:Reference URI="#X509-f40f60f5-64b4-4135-b7e0-fd8348d00c3a">
               <ds:Transforms>
                 <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                   <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="soap"/>
                 </ds:Transform>
               </ds:Transforms>
               <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
               <ds:DigestValue>dajItom81ecXPgC9DRVRPRmr/ZPtgtri85sK18ckSQc=</ds:DigestValue>
             </ds:Reference>
           </ds:SignedInfo>
           <ds:SignatureValue>...SIGNATURE...</ds:SignatureValue>
           <ds:KeyInfo Id="KI-31f93730-0d96-4309-bed9-ac1440f120af">
             <wsse:SecurityTokenReference xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="STR-f55c14ba-58c1-4831-b393-bf7609769fc9">
               <wsse:Reference URI="#X509-f40f60f5-64b4-4135-b7e0-fd8348d00c3a" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
             </wsse:SecurityTokenReference>
           </ds:KeyInfo>
         </ds:Signature>
       </wsse:Security>
     </soap:Header>
     <soap:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="_e8f02c45-106a-4c8e-b0ad-4252be04b7ef">
       <ns1:echo xmlns:ns1="http://es.rickyepoderi.sample/ws">
         <arg0>something....</arg0>
       </ns1:echo>
     </soap:Body>
   </soap:Envelope>
   

   As you see, the X509 certificate is sent as a BinarySecurityToken and the signature is also present. The key information for the signature references the previous X509 certificate.

8. The server responds with the following message:

   
   <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
     <soap:Header>
       <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soap:mustUnderstand="1">
         <wsu:Timestamp wsu:Id="TS-3c6018cd-cef4-4832-81f3-ec6fe8f482f8">
           <wsu:Created>2017-12-23T14:02:06.182Z</wsu:Created>
           <wsu:Expires>2017-12-23T14:07:06.182Z</wsu:Expires>
         </wsu:Timestamp>
         <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="SIG-469137e4-901f-4037-9206-6263ac026ad8">
           <ds:SignedInfo>
             <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
               <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="soap"/>
             </ds:CanonicalizationMethod>
             <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
             <ds:Reference URI="#TS-3c6018cd-cef4-4832-81f3-ec6fe8f482f8">
               <ds:Transforms>
                 <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                   <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse soap"/>
                 </ds:Transform>
               </ds:Transforms>
               <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
               <ds:DigestValue>jo6cDr9a+XZiQ8miJ6E09n0Qovt40lxYhemHhL1juqk=</ds:DigestValue>
             </ds:Reference>
             <ds:Reference URI="#_1b05d41b-5b7e-4d75-97c2-0d3c300c0e22">
               <ds:Transforms>
                 <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
               </ds:Transforms>
               <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
               <ds:DigestValue>Z14Q80/j3gR31KiNMINj9ylZ0ywf/INOm62iO4k4Axc=</ds:DigestValue>
             </ds:Reference>
           </ds:SignedInfo>
           <ds:SignatureValue>...SIGNATURE...</ds:SignatureValue>
           <ds:KeyInfo Id="KI-d23763d6-3dd6-4338-b639-de8fbab2d824">
             <wsse:SecurityTokenReference xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="STR-36fb975b-769d-477d-96f8-43c8ce0d84fb">
               <ds:X509Data>
                 <ds:X509IssuerSerial>
                   <ds:X509IssuerName>CN=ca.demo.kvm,O=demo.kvm,C=ES</ds:X509IssuerName>
                   <ds:X509SerialNumber>6</ds:X509SerialNumber>
                 </ds:X509IssuerSerial>
               </ds:X509Data>
             </wsse:SecurityTokenReference>
          </ds:KeyInfo>
         </ds:Signature>
        </wsse:Security>
     </soap:Header>
     <soap:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="_1b05d41b-5b7e-4d75-97c2-0d3c300c0e22">
       <ns1:echoResponse xmlns:ns1="http://es.rickyepoderi.sample/ws">
         <return>anonymous -> something....</return>
       </ns1:echoResponse>
     </soap:Body>
   </soap:Envelope>
   

   Another signature is included but, in the response, the server does not add the certificate just the info to retrieve the certificate from the client key-store. That is why the server certificate (public part) needs to be included in the client key-store.

And that is all for now. In the current entry the WS-Security is configured to be used in our previous web-services application. Now the client, instead of using the certificate at TLS level, uses WSS headers to include a signature of the body message in a header. The configuration is a bit complicated but the main idea is that now the SOAP message is signed by the client, and that signature is validated by the server with the Apache WSS4J/CXF implementation used by wildfly. Then the response is also signed by the server and validated by the client. The missing piece is the JavaEE integration. I was going to include everything in this same entry, but the integration is giving a lot of problems to me, so I decided to explain it better in another entry and do not complicate this one even more. The project application used today can be downloaded from here.

Regards!

This entry is the second part of the certificate security in wildfly series. The previous post was about setting a TLS mutual authentication in a jax-ws application, but without any javaee integration. The client had to send the certificate (and revoked certificates were not admitted at TLS level) but inside the java application no principal was assigned. This continuation entry is going to add this integration. In wildfly it is mainly a matter of configuration.

The new elytron subsystem is very convoluted and you need a lot of steps to add a standard CLIENT-CERT login. The following points were needed in my case:

1. The certificate login continues to be based in a certificate store. I am not very happy with this feature, I think that any certificate that is valid (dates, revocation and so on) should be directly passed. But default implementation also checks that the certificate is in a user key-store. So another users.jks was created with the client certificates:

   
   keytool -import -keystore users.jks -file /etc/pki/client1.pem -alias "CN=SampleClient1,O=demo.kvm,C=ES"
   keytool -import -keystore users.jks -file /etc/pki/client2.pem -alias "CN=SampleClient2,O=demo.kvm,C=ES"
   

   And finally the new store is added to the configuration:

   
   /subsystem=elytron/key-store=users:add(type=jks, relative-to=jboss.server.config.dir, path=users.jks, credential-reference={clear-text=Kiosko_00})
   

   Please note that the certificate alias should be the user name. (The full subject is used. As I comment in a later step, the CN decoder is not working for me, maybe with a working decoder the alias should be different. I do not really know.)

2. With the users key-store a certificate realm is created:

   
   /subsystem=elytron/key-store-realm=users-realm:add(key-store=users)
   

3. I wanted to use a CN decoder (the logged username would be the common-name part of the subject) but it does not work. The openssl defaulted to UTF-8 strings and the default decoder just manages IA5 and Printable strings (I do not know why). So the decoder does not work with my certificates.

   
   /subsystem=elytron/x500-attribute-principal-decoder=cn-decoder:add(oid="2.5.4.3", maximum-segments=1)
   

4. Finally a role decoder is used to auto-assign a Users role to the certificate.

   
   /subsystem=elytron/constant-role-mapper=users-roles:add(roles=[Users])
   

5. With all the previous parts the security domain is created:

   
   /subsystem=elytron/security-domain=certificate-domain:add(principal-decoder=cn-decoder, role-mapper=users-roles, realms=[{realm=users-realm}], default-realm=users-realm, permission-mapper=default-permission-mapper)
   

6. Now the security domain should be assigned to the web subsystem (undertow) using an authentication factory:

   
   /subsystem=elytron/http-authentication-factory=certificate-auth-fact:add(http-server-mechanism-factory=global, security-domain=certificate-domain, mechanism-configurations=[{mechanism-name=CLIENT_CERT,mechanism-realm-configurations=[{realm-name=certificate-sec-domain}]}])
   /subsystem=undertow/application-security-domain=certificate-sec-domain:add(http-authentication-factory=certificate-auth-fact)
   

7. And finally because the WS endpoint is an EJB the security domain is also assigned to the ejb3 subsystem (indeed this part is not needed):

   
   /subsystem=ejb3/application-security-domain=certificate-sec-domain:add(security-domain=certificate-domain)
   

Now the server is ready for certificate login. The elytron subsystem can be configured to have a second method (BASIC for example) but more steps are needed. You can also configure an aggregate realm to assign roles using a second provider for roles (the key-store realm would validate the principal and a second one, ldap for example, would add the roles, instead of my fixed Users role used in this entry). But, as I said before, the configuration is very convoluted in my opinion. Besides I do not see any direct translation for the typical stacking of login modules of the previous and deprecated security system.

Finally the sample application should be modified to include the new certificate configuration. So the web.xml is modified to request CLIENT-CERT. (As the endpoint is an EJB the same solution can also be achieved using the jboss-ejb3.xml.)

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>Protect all application</web-resource-name>
            <url-pattern>/*</url-pattern>
        </web-resource-collection>
        <user-data-constraint>
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
        <auth-constraint>
            <role-name>Users</role-name>
        </auth-constraint>
    </security-constraint>
    <login-config>
        <auth-method>CLIENT-CERT</auth-method>
        <realm-name>certificate-sec-domain</realm-name>
    </login-config>
    <security-role>
        <description>Role required to log in to the Application</description>
        <role-name>Users</role-name>
    </security-role>
    <session-config>
        <session-timeout>30</session-timeout>
    </session-config>
</web-app>

And the jboss-web.xml is used to mark the certificate-sec-domain as the application security domain to use.

<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
   <security-domain>certificate-sec-domain</security-domain>
</jboss-web>

The WS endpoint is slightly modified to only let its use to the Users role. The RolesAllowed annotation is added.

@Stateless
@WebService(name = "echo", 
        targetNamespace = "http://es.rickyepoderi.sample/ws", 
        serviceName = "echo-service")
@DeclareRoles("Users")
@SOAPBinding(style = SOAPBinding.Style.RPC)
public class Echo {

    @Resource SessionContext ctx;

    @WebMethod
    @RolesAllowed("Users")
    public String echo(String input) {
        return ctx.getCallerPrincipal() + " -> " +  input;
    }
}

And here it is the video. It is just the execution of the same WS client presented before using the valid client1.p12 key-store. The new thing is that now the endpoint returns the subject of the certificate as the logged user. Therefore, everything is working.

Your browser doesn't support the video tag. See this entry for more information about how to see the videos in this blog. You can download the file instead.

This second entry in the series integrates the previous solution into the javaee security framework. The certificate is validated using the key-store realm which checks that the certificate is inside the configured store. All the previous work is still in place (TLS mutual authentication ensures the certificate is valid and not revoked) but then the realm authenticates the user into the application. This way the WS endpoint can be configured with security and the caller is assigned properly. The new version of the application can be downloaded from here.

Long time ago I posted some entries about how to integrate client certificate authentication using glassfish. I am going to start another series about doing the same but in wildfly. In the new entries the protected resource is going to be a web service (jax-ws/SOAP is used), so it is very similar but a bit different (if everything goes as expected the last entry is going to be completely new). As in the previous time the first post is not very interesting because it is just the setup of the server and the presentation of the little WS application.

Again some certificates are needed in order to test the application. The same steps were performed (I am not going to repeat them, you can see the exact openssl commands in the previous entry) and at the end the following files are obtained:

• The custom CA certificate that is imported in a custom cacerts file that will be used to validate the server and clients certificates.

• The server certificate that is generated in a server.jks to be used by the wildfly server.

• Two client1.p12 and client2.p12 files that contain a client certificate each. The latter is revoked.

• A my.crl file which is the revocation list (it should contain the client2 certificate in it).

The just released wildfly 11 is going to be used in the entry. I need to learn more about the elytron subsystem so this is a good opportunity to start with it. Once the container is unzipped and started (using standalone mode and default standalone.xml configuration file), the following CLI commands were executed to create all the needed configuration.

1. Using the cacerts and server.jks files two stores are added to elytron:

   
   /subsystem=elytron/key-store=localhost:add(type=jks, relative-to=jboss.server.config.dir, path=server.jks, credential-reference={clear-text=Kiosko_00})
   /subsystem=elytron/key-store=ca:add(type=jks, relative-to=jboss.server.config.dir, path=cacerts, credential-reference={clear-text=changeit})
   

2. With the previous stores a key manager and a trust manager are created. In the trust manager the CRL is also added to take the revoked certificates into account. The wildfly server does not support OCSP checking for the moment, for that reason OCSP is not mentioned in the entry.

   
   /subsystem=elytron/key-manager=localhost-manager:add(key-store=localhost, alias-filter=server, credential-reference={clear-text=Kiosko_00})
   /subsystem=elytron/trust-manager=ca-manager:add(key-store=ca, certificate-revocation-list={relative-to=jboss.server.config.dir, path=my.crl})
   

3. Finally the SSL context is created for the https port (only TLSv1.2 is configured and client certificate is needed).

   
   /subsystem=elytron/server-ssl-context=localhost-context:add(key-manager=localhost-manager, protocols=["TLSv1.2"], trust-manager=ca-manager, need-client-auth=true)
   

4. Finally the previous context is assigned to the https port (the old security realm should be removed first):

   
   batch
   /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
   /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context, value=localhost-context)
   run-batch
   

5. Just reload and the new configuration for the secure port will available.

   
   reload
   

At this point the server is listening in the default wildfly port 8443 and client authentication is compulsory.

Moving to the application side, the WS endpoint is extremely easy, it's just a echo service that return the logged user and the same text that is passed to it.

@Stateless
@WebService(name = "echo", 
        targetNamespace = "http://es.rickyepoderi.sample/ws", 
        serviceName = "echo-service")
@SOAPBinding(style = SOAPBinding.Style.RPC)
public class Echo {

    @Resource SessionContext ctx;

    @WebMethod
    public String echo(String input) {
        return ctx.getCallerPrincipal() + " -> " +  input;
    }
}

To make compulsory the https access at application level two more things are needed. In the web.xml a security constraint is added to restrict the access to confidential data (this makes wildfly redirect all the http traffic to the https port).

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>Protect all application</web-resource-name>
            <url-pattern>/*</url-pattern>
        </web-resource-collection>
        <user-data-constraint>
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>
    <session-config>
        <session-timeout>30</session-timeout>
    </session-config>
<web-app>

And a jboss-webservices.xml is also added to force the scheme to be https (the generated WSDL will use https for generating the port location).

<?xml version="1.1" encoding="UTF-8"?>
<webservices version="1.2"
  xmlns="http://www.jboss.com/xml/ns/javaee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee">
  <property>
    <name>wsdl.soapAddress.rewrite.wsdl-uri-scheme</name>
    <value>https</value>
  </property>
</webservices>

Finally the client is developed and this step also has some tricks. Doing the previous steps the WSDL itself is protected behind the https (mutual auth) restriction. It means that any connection that reaches the server must present a valid certificate in order to get through. And using jax-ws there are two problems: configuration for SSL is not standardized by the API and the initial connection (the one that is done to download the WSDL) cannot be customized. Therefore we have two options, using global SSL configuration for the client (for example passing the following options to the java client -Djavax.net.ssl.trustStore=cacerts -Djavax.net.ssl.keyStore=client1.p12 -Djavax.net.ssl.keyStorePassword=Kiosko_00 -Djavax.net.ssl.keyStoreType=PKCS12), which is not perfect because your client can be another application container with several apps with different needs, or developing some specific code for the implementation you are using.

        URL url = new URL("https://localhost:8443/wildfly-x509/echo-service/echo?wsdl");
        EchoService service = new EchoService(url);
        Echo echo = service.getEchoPort();
        // get the client and assign a specific SSLContext configuration
        Client client = ClientProxy.getClient(echo);
        HTTPConduit http = (HTTPConduit) client.getConduit();
        TLSClientParameters parameters = new TLSClientParameters();
        parameters.setSSLSocketFactory(createSSLContext(args[0]).getSocketFactory());
        http.setTlsClientParameters(parameters);
        System.err.println(echo.echo(args[1]));

If you see once the echo port is created, a specific CXF/Apache lines assign your specific SSLContext (with your key and trust stores). Those lines are different for the Sun/Oracle metro implementation (code is also very easy but different). Having a standard property in the BindingProvider to assign a custom SSLSocketFactory would be a very nice extension for the standard. But the second problem still stands, the SSLSocketFactory is assigned once the port is created but, to reach this point, a first connection has already been established to read the WSDL (this part is done in the new EchoService(url) line). There is no way to set a SSLSocketFactory specifically to this request (only global solutions work, but they affect another applications in the same JVM as it was previously commented). You can avoid this issue just specifying a local WSDL file instead the final URL, but I prefer to use a jax-ws catalog, it caches the WSDL and avoids the first contact to the endpoint. Besides this point is standard, you just need to create a jax-ws-catalog.xml in the META-INF folder of the WAR bundle. In my case:

<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="system">
  <system systemId="https://localhost:8443/wildfly-x509/echo-service/echo?wsdl" uri="wsdl/echo.wsdl"/>
</catalog>

The catalog marks that the WSDL for that location can be locally read from the wsdl/echo.wsdl file. This way when the service is created no initial connection is made (the local file is read instead of the network URL). With both ideas (catalog and specific CXF SSL configuration) the WS client can now access the endpoint using TLS mutual authentication.

Here it is the final video. First firefox browser (both client certificates were imported previously) is managed to access the service's WSDL. If client2 is used an error is presented but using client1 the definition is shown. That means everything is working as expected. Then maven is used to execute the web service client. The first execution uses client2.p12 as the trust store which does not work (it is revoked). But then the argument is changed to read the client1.p12 and it works. Please note that the user that is returned by the server is anonymous.

Your browser doesn't support the video tag. See this entry for more information about how to see the videos in this blog. You can download the file instead.

Let's do a little summary of the idea presented in today's entry. The wildfly container was configured to require client certificate in the https port. Besides it was configured to read a CRL file at startup (the client2 certificate is revoked, present in the CRL and not admitted). The jax-ws application is configured as confidential so any access to the application is restricted to the https port (wildfly redirects any plain access to the encrypted port). This setup makes compulsory to configure the WS client to use a client certificate. This configuration is not standard and a catalog is used to avoid the initial download of the WSDL. I want to emphasize that there is no real authentication in the entry, it is just a TLS level mutual authentication, but no user is really passed to the echo WS. That is why the user is anonymous in the call. JavaEE authentication will be the topic of the next entry in the series. The sample WS maven project used in the entry can be download from here.

Best regards!