Security - 2

This the fourth and last entry about certificate login in Wildfly for a jax-ws application. The first pair of posts were dedicated to TLS mutual authentication (the client certificate presented at TLS level was then used to identify the user inside JavaEE). The previous entry introduced WS-Security, the SOAP protocol is extended to use headers that can add different security features. Using WSS the message is signed and the X509 certificate is included in the request message as a binary token. In this last entry my intention was just using that certificate in the header and login the user with it. But I had problems implementing this last step and that was the reason to separate this topic in a new entry. I am going to explain the steps to finally make it work one by one.

By default wildfly has an interceptor that can (out of the box) log a user in with a username/password token. This interceptor class is SubjectCreatingPolicyInterceptor which obtains the token, gets the username and password inside it and validates the pair against the security domain configured in the endpoint. But the entry's goal is different, we are using a certificate token (X509), and there is no interceptor for that by default. Therefore I decided to develop a CertificateBinaryTokenInterceptor.

My class has a method to obtain the certificate from the message. The WSS4J implementation stores all the validations executed over the request in the message itself. The signature verification can be retrieved from those validations and the certificate is just part of the validation results. The method iterates over the list of verifications and gets the one that is a signature, is validated (signature has been checked) and has a certificate attached.

    private X509Certificate getCertificate(SoapMessage message) {
        List handlerResults = (List) message.get(WSHandlerConstants.RECV_RESULTS);
        if (handlerResults != null) {
            for (WSHandlerResult handlerResult : handlerResults) {
                List engResults = handlerResult.getResults();
                if (engResults != null) {
                    for (WSSecurityEngineResult engResult : engResults) {
                        Boolean validated = (Boolean) engResult.get(WSSecurityEngineResult.TAG_VALIDATED_TOKEN);
                        X509Certificate cert = (X509Certificate) engResult.get(WSSecurityEngineResult.TAG_X509_CERTIFICATE);
                        Integer action = (Integer) engResult.get(WSSecurityEngineResult.TAG_ACTION);
                        if (Boolean.TRUE.equals(validated) && cert != null && action != null && WSConstants.SIGN == action) {
                            return cert;
                        }
                    }
                }
            }
        }
        return null;
    }

The main method uses the certificate to log the user as it is done in the default SubjectCreatingPolicyInterceptor.

    @Override
    public void handleMessage(SoapMessage message) throws Fault {
        Endpoint ep = message.getExchange().get(Endpoint.class);
        X509Certificate cert = getCertificate(message);
        SecurityContext context = message.get(SecurityContext.class);
        if (cert == null || context == null || context.getUserPrincipal() == null) {
            // no certificate, do nothing
            super.handleMessage(message);
        } else {
            // certificate found => perform a login with it
            // the principal name is going to be as in the users.jks in lowercase
            Principal principal = new SimplePrincipal(cert.getSubjectX500Principal().getName().toLowerCase());
            Subject subject = new Subject();
            if (ep.getSecurityDomainContext().isValid(principal, cert, subject)) {
                ep.getSecurityDomainContext().pushSubjectContext(subject, principal, cert);
                SecurityContext sc = new DefaultSecurityContext(principal, subject);
                message.put(SecurityContext.class, sc);
            } else {
                throw MESSAGES.authenticationFailed(principal.getName());
            }
        }
    }

Then the interceptor is configured in the Echo service:

@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")
@InInterceptors(interceptors = {
    "es.rickyepoderi.sample.CertificateBinaryTokenInterceptor"
})
public class Echo {

Finally the security context is associated to the application (the same security domain used before) but using the jboss-ejb3.xml. This is now necessary, if the configuration was setup in the web.xml/jboss-web.xml files it would not work, the certificate would be searched at TLS level and now it goes in the WSS SOAP header. The file just assigns the security domain to all EJBs:

<?xml version="1.1" encoding="UTF-8"?>
<jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
               xmlns="http://java.sun.com/xml/ns/javaee"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:s="urn:security:1.1"
               xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"
               version="3.1"
               impl-version="2.0">
    <assembly-descriptor>
        <s:security>
            <ejb-name>*</ejb-name>
            <s:security-domain>certificate-sec-domain</s:security-domain>
        </s:security>
    </assembly-descriptor>
</jboss:ejb-jar>

I was pretty sure about this solution but...

Interceptor for {http://es.rickyepoderi.sample/ws}echo-service has thrown exception, unwinding now: java.lang.IllegalArgumentException: only string password accepted
	at org.jboss.as.webservices.security.ElytronSecurityDomainContextImpl.isValid(ElytronSecurityDomainContextImpl.java:71)
	at es.rickyepoderi.sample.CertificateBinaryTokenInterceptor.handleMessage(CertificateBinaryTokenInterceptor.java:98)
	at es.rickyepoderi.sample.CertificateBinaryTokenInterceptor.handleMessage(CertificateBinaryTokenInterceptor.java:32)
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
        ...

It seems that the current integration between webservices and elytron subsystem just admits password logins. Looking the code this restriction is pretty clear. Elytron admits more types of login but, for the moment, the web-services just let you login using a password.

I know that in the previous security subsystem this type of login is admitted, so I just reconfigure the wildfly server to use a previous security-domain with a certificate login module.

/subsystem=security/security-domain=certificate-domain:add(cache-type=default)
/subsystem=security/security-domain=certificate-domain/authentication=classic:add()
/subsystem=security/security-domain=certificate-domain/authentication=classic/login-module=Certificate:add(code=Certificate, flag=required)
/subsystem=security/security-domain=certificate-domain/authentication=classic/login-module=Certificate:write-attribute(name=module-options, value={password-stacking=useFirstPass, securityDomain=certificate-domain})
/subsystem=security/security-domain=certificate-domain/jsse=classic:add(keystore={url="${jboss.server.config.dir}/users.jks", password=Kiosko_00})

Just the certificate module is used (stacking can be used to add roles from other modules). The user will be logged in without any role to the application.

Then I changed the jboss-ejb3.xml to use the new certificate-domain instead of the previous elytron realm. And it simply works. As I remembered, you can make a login with the certificate just passing its X509 representation as the password object. The login module just picks it up and checks if it is in the users.jks key-store. Here it is the video, as you see the current user is again the subject of the certificate.

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.

In this last entry of the certificate security for jax-ws web services series, the application uses a WS-Security X509 token to execute a login inside an interceptor. The solution is very similar to the one that default wildfly uses for username tokens (the documented SubjectCreatingPolicyInterceptor class) but with a certificate. Nevertheless the new elytron susbsystem cannot be used but previous security domain works without any flaw. I think that elytron is still very new and it needs some improvements in these integration areas (in this case between web services and security). Throughout this series client certificate authentication for SOAP web services has been explained in detail (two types, at TLS level and using WS-Security). I hope that the entries are useful, or at least interesting, for you. The last maven project for the application can be download from here.

Certificate regards!

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.