Business Process Management

After reading the book about Webservice Security like mentioned in my last post, I want to try out my knowledge in practice.
Transport Layer Security is the most basic security mechanism to start with. This should be a no-brainer since it is the task of the application servers to handle this problem.
This means, that the transport channel is encrypted and the identity of the webservice provider server is checked. Standard https also means that the identity of the webservice consumer will not be checked.

In short:

• The application server of the webservice consumer checks the certificate of the application server which hosts the webservice provider
• The application server of the webservice provider does not request a certificate from the webservice conumser's server.

My ingrediants for my test implementation:

• Jetty server, version 7 as application server for the webservice provider
• Tomcat server, version 6 as application server for the webservice consumer
• Self signed certificates. This is sufficiant if your webservice calls stay inside one company network.
• Existing webservice implementations for provider and consumer, implemented with Apache Axis2. Check this post to see the architecture.

1.0 Setup Jetty Application Server (WS Provider) to open an https port

For the webservice provider's server to accept requests via https, I followed the instructions from codehouse. The basic steps are these:

- Generate certificate which contains identity and a public key
- Sign the certificate yourself (The alternative would be a to let it signed by Verisign, GeoTrust, etc. which would cost a lot of money)
- Add the certificate to a keystore. This keystore doesn't exist after a new installation of jetty.

After you have followed these instructions, the jetty server sends a certificate to every requestor which contacts the jetty server on its https port. The certificate has the function of a passport which is signed by an organization who anybody trusts. (If you would have let it be signed by Verisign, GeoTrust, etc.). The webservice consumer's application server has to decide upon this certificate if it trusts this application server . How does  the consumer's application server make this decision?
The answer is simple. If the server has this certificate in it's truststore, then it decides to trust this issuer of the certificate.
This brings us to the next step:

2.0 Setup Tomcat Application Server (WS Consumer) to trust the WS Provider's server

2.1 Get certificate from the WS provider's server

The easiest way to get the certificate the WS provider's server issues, is to call the https port with your webbrowser. Just call the https URL for the wsdl file. You webbrowser will ask you if you want to trust the issuer. This question is again, because your browser doesn't know the organization which signed the certificate. (Because you didn't let it be signed by VeriSign, GeoTrust, etc.) Tell you browser to trust the issuer and it will connect you to the requested URL.
With Firefox, you can click on the identity sign next to the URL.

Then get the certificate by following this path: More Information > View Certificates > Detail > Export. Save it as a .pem file and name if jetty_certificate.pem.

2.2 Add the certificate to tomcat's truststore

Since tomcat doesn't have a truststore by default, create a new truststore file for tomcat and add jetty's certificate:

keytool -import  -alias jettykey -file jetty_certificate.pem -keystore tomcattruststore

2.3 Modify Tomcat Scripts for Tomcat to use the truststore

I modified catalina.sh by adding the information to the Java Options:

CATALINA_OPTS="$CATALINA_OPTS \

-Djavax.net.ssl.trustStore=/opt/tomcat6/tomcattruststore \

-Djavax.net.ssl.trustStorePassword=mypassword"

After this modification, you have to restart tomcat.

3.0 Modify Webservice Consumer Implementation

As you might know, Axis2 generates you a Stub-Class for every Service. This Stub-Class has two constructor's, one is empty and the other one has an argument to hand over the webservice endpoint address.

3.1 Change Webservice endpoint address

Obviously you should never use the empty constructor because an SOAP Endpoint address can always change, for example when the service is deployed on a new server. When I developed the webservice consumer I used simple java properties to store all parameters of the endpoint address in a text file. Check here:

monitor.webservice.endpoint.hostname=localhost

monitor.webservice.endpoint.port=8443

monitor.webservice.endpoint.protocol=https

monitor.webservice.endpoint.path.status=/monitor/services/Status.StatusHttpSoap12Endpoint/
Therefore it is very simple to modify the webservice code to use the new https connection. 
Just edit the port and the protocol parameters and deploy the service again. 

3.2 Modify axis2.xml

Without https and and without any other security, no axis2.xml file was necessary in the webapp project. But for https I had to add axis2.xml to WEB-INF/conf to define the https transport receiver. This xml fragment in axis2.xml made it work:

    <transportReceiver name="https" class="org.apache.axis2.transport.http.AxisServletListener">
        <parameter name="port">8443</parameter>
    </transportReceiver>

That's it. Now the webservice communication is running via https. This was the first and most simple step towards secure webservice communication. The next and more challenging steps will be to implement Client(=consumer) Authentication and Message Layer Security like XML Signature and XML Encryption.