Monday, November 1, 2010

Encrypt the response with a certificate taken from the request

Sometimes it is not possible to share public keys among all clients but still necessary to provide some level of message security. In this case it's possible to validate an incoming request and use a certificate from the request to encrypt a response. I'll show how to create the proxy workflow for the SOA Expressway providing such functionality.

First of all we'll start a backend web-service which will do a real work. I usually use jax-ws to create simple web-services. The code for simple web-service is listed below.
package example;
import javax.jws.*;
import javax.jws.soap.*;
import javax.xml.ws.*;

@WebService(targetNamespace="http://hello/")
public class Hello {
@WebMethod
public String hello(String name) {
return "hello " + name;
}
public static void main(String args[]) {
Endpoint.publish("http://0.0.0.0:"
+ args[0]+"/hello",new Hello());
System.out.println("Web Service listening on "
+ args[0]);
}
}


We will compile this file with an apt tool and run it with command
$ java example/Hello 9876
Web Service listening on 9876


Service is started and accepting requests on address http://localhost:9876/hello

Now we are ready to create the SOA Expressway application to offload security operations for our HelloWorld web-service.

Create a new Intel SOA Expressway Project in the Services Designer.


Create a new Synchronous SOA Expressway Workflow in this project.


Select the Invoke operation on a right palette and drop it between the Receive and the Reply. This operation will call the backend web-service.


Click on the "Invoke" operation and select the "Use Existing WSDL" checkbox to make this "Invoke" WSDL-oriented activity.
Import the backed web-service WSDL with the "Import WSDL..." button and import WSDL of the jax-ws backend web service.


Bind the "Invoke" activity to the "hello" operation.


We've done with the operation "Invoke" and now we need to setup the "Receive" operation to receive requests for the backend server.
Click on the "Receive" operation select "Use existing WSDL" and select the "hello" operation.


To setup the dataflow click on the "Invoke" activity and select for the "1. parameters" dropdown value "$Receive.parameters" to pass a data from the "Receive" activity into the "Invoke" activity then click on the "Reply" activity and select the value "$Invoke.parameters" for the "1. parameters" dropdown to send a server's response back to the client.

The simple proxy application is ready and we can go on with security features.
We'll need two security policies, first for a request verification and second for a response encryption.

Create a new WS-Security Policy with the name "verify" and an operation type "Verify".


On the Settings tab of the verification.wsSecurity policy select accepted methods. Set the "Save resolved key information" checkbox, this key will be later used for the response encryption. Select "X509 Certificate Source: incoming message".


Create a new WS-Security policy with the name "encrypt" and an operation type "Encrypt". On "Settings" tab select suitable algorithms and "X509 certificate Source: Verify operation" to use the certificate from the request for the encryption.


Policies are ready now and we need to bind them to "Receive" and "Reply" activities respectively.
Click on the "Receive" activity, then select "WS-Security" tab and add the verify.wsSecurity policy to the list.


Click on the "Reply" activity, select the "WS-Security" tab, add the encrypt.wsSecurity policy to the list and select "Receive > verify.wsSecirity" as "Encryption key: X509 certificate" value.


Our workflow is complete now, we can export it and deploy it into the SOA Expressway server. Once workflow is deployed and started it will be able to both verify requests and encrypt responses.

3 comments:

  1. Great post. I hope you can write more good stuff like this article.

    Managed It Services RI

    ReplyDelete