Web Services Security with Apache Rampart – Part 2 (Message-Level Security)

Apache Rampart is the Axis2 module that provides WS-Security functionality to Axis2 Web services and clients. Rampart currently implements WS-SOAP message security , WS-Security policy , WS-Secure conversation and WS-Trust specifications. In part one of this tutorial [1], we looked at applying transport-level security to a Web service and a client. In this tutorial, we will look at how to apply message-level security to a Web service and a client using Apache Rampart. Nandana Mihindukulasooriya explains..

Introduction

This tutorial is a step by step guide on how to sign a SOAP message with Apache Rampart using policy based configuration. We will also look at how to deploy the Apache Rampart module in Axis2. Although we have already covered deploying Rampart in Axis2, in part one of this tutorial, it is repeated here again for completeness sake only. Those who have already deployed Rampart can skip this section. We will then go and look at how a Axis2 Web service and a client can be secured with Rampart. As Axis2/Rampart has been proven to be highly interoperable, either the Web service or the client can still be written in some other Web service stack (including .NET / C / PHP) other than Axis2/Java.

See Web Services Security with Apache Rampart – Part 1 (Transport Level Security) [2] for part I of this tutorial.

Applies To

<Project/lan>	version
Apache Rampart	1.3
Apache Axis2	1.3

Scenario [2]
Deploying the Rampart Module [2]
- Deploying the module and necessary jars [2]
Securing the service [2]
- Step 1. Writing the web service and the service descriptor [2]
- Step 2. Setting up the key store [2]
- Step 3. Writing the password callback [2]
- Step 4. Constructing the security policy [2]
- Step 5. Providing the Rampart specific configuration details [2]
- Step 6. Engaging Rampart and applying the security policy [2]
- Step 7. Deploy the service [2]
- Policy annotated WSDL [2]
Securing the client [2]
- Step 1. Generating the Stub using WSDL2Java tool [2]
- Step 2. Writting the client [2]
- Step 3. Setting up the key store [2]
- Step 4. Writing the password callback [2]
- Step 5. Engaging Rampart [2]
- Step 6. Setting the Rampart specific configuration details [2]
- Step 7. Calling the Web service [2]
SOAP messages exchanged [2]
- Without security [2]
- With Security [2]
Summary [2]
References [2]
Resources [2]

here [3]. Rampart distribution contains two module files, rampart-1.3 and rahas-1.3.mar . These module files should be copied to the modules directory of the Axis2 engine that can be found in TOMCAT_HOME/webapps/axis2/WEB-INF/modules, where TOMCAT_HOME is the home directory of the Apache Tomcat server in which Axis2 war is deployed. All the dependancy jars needed for Apache Rampart can be found under the libs directory of the Rampart distribution. These need to be copied to the lib directory of the Axis2 engine, which can found in TOMCAT_HOME/webapps/axis2/WEB-INF/lib.

You can check whether Apache Rampart is successfully deployed by logging in to Axis2 as the admin and using the System Components/available modules option in admin Web console . Both "rampart" and "rahas" should be listed under available modules, if you deploying of rampart and rahas modules has been successfull.

Hello world with Apache Axis2 [4]".

<service>
  <module ref="rampart"/>
  <parameter name="ServiceClass" locked="false">tutorial.rampart.service.SecureService</parameter>
  <operation name="add">
    <messageReceiver class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/>
  </operation>
</service>

Setting Up Keystores for a Client and a Service [5]”. The service.jks which we use as the key store of the service, can be downloaded with the source code of this tutorial. You can use the keytool shipped with Java if you want inspect the keystore and see what keys it contains.


$ keytool -list -v -keystore path/to/service.jks -storepass servicePW 
 
Keystore type: jks
Keystore provider: SUN
 
Your keystore contains 2 entries
 
Alias name: service
Creation date: Mar 21, 2008
Entry type: keyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=service, OU=Secuirty Team, O=WSO2, L=colombo, ST=Western, C=LK, EMAILADDRESS=service@wso2.com
Issuer: CN=service, OU=Secuirty Team, O=WSO2, L=colombo, ST=Western, C=LK, EMAILADDRESS=service@wso2.com
Serial number: 47e3b6c0
Valid from: Fri Mar 21 18:53:12 LKT 2008 until: Tue Mar 15 18:53:12 LKT 2033
Certificate fingerprints:
         MD5:  C4:B9:2D:70:22:E9:08:6B:07:3B:2C:1E:5B:87:ED:09
         SHA1: 4F:C9:0C:42:01:B7:BE:AC:0D:4F:AC:00:A2:E7:CC:CA:07:40:8E:BB
 
 
*******************************************
*******************************************
 
 
Alias name: client
Creation date: Mar 21, 2008
Entry type: trustedCertEntry
 
Owner: CN=client, OU=Secuirty Team, O=WSO2, L=colombo, ST=Western, C=LK, EMAILADDRESS=client@wso2.com
Issuer: CN=client, OU=Secuirty Team, O=WSO2, L=colombo, ST=Western, C=LK, EMAILADDRESS=client@wso2.com
Serial number: 47e3b631
Valid from: Fri Mar 21 18:50:49 LKT 2008 until: Tue Mar 15 18:50:49 LKT 2033
Certificate fingerprints:
         MD5:  DE:66:EB:95:18:2E:44:97:05:CE:DF:FC:83:E9:53:C3
         SHA1: CE:E5:F0:BB:2F:46:A9:F0:45:60:4C:16:1B:33:FC:B5:09:0B:8C:13
 
 
*******************************************
*******************************************

As you can see, service.jks contains it’s public-private key and the public key of client as trusted certificates. Service needs it’s private key to sign the messages which is pretty obvious but why does it need the certificate of the client? It is because it needs the client’s public key to verify the signature of the client.

Understanding WS – Security Policy Language [6]”.

here [7].

Web Services Security with Apache Rampart – Part 1 (Transport Level Security) [8]

2. Setting Up Keystores for a Client and a Service [9]

3. Understanding the WS Security Policy Language [10]

Download source code for this tutorial [11]

Author

Nandana Mihindukulasooriya, Software Engineer, WSO2 Inc. nandana AT wso2 DOT com