How to test secure web services with soapUI - part #2

In  a previous article I described how to specify signature and encryption for outgoing Secured Web Services request.

1. SAML

In this second article I will talk about SAML and incoming Secure Web Service responses.

If you are using SAML 1.X then you just need to add a SAML 1.X assertion in the corresponding window.
You may have to add a timestamp as follow:

In this example, we specify 10,000 milliseconds (10 seconds) for the life time of the Timestamp:

SAML 1.X assertions are copied and pasted in the SAML tab:

Of course, if you combine signature and encryption with SAML 1.X. You can those to the configuration tabs as well.

For SAML 2.0, the only option you have for this version of soapUI is to add it manually to the WSSE section of your SOAP request:

2. Incoming Secure Web Service 
Responses


Setting up incoming secure Web services responses encrypted and/or signed is easier than for outgoing request:

1) Make sure that you have Keystores / Certificates tab set - You probably have done that earlier as described in part #1 of this article.
You verify the signature with public key contained in the server's sender certificate/store and your private key to decrypt what the other server sends you.

2) Create an incoming WSS configuration (e.g. my_config_from_server_A) that will decrypt the incoming SOAP requests coming from server A:

You specify that you want to use your keystore to decrypt the message and the server's certificate/store to verify the signature of server A
(theses should appear in the drop box for each field):

3) Last, you want to specify that you are using the incoming configuration for each request:

Enjoy!

How to test secure web services with soapUI - part #1

Recently I have been involved in a SOA project which goal is to orchestrate  IHE integration profiles SOAP web services (XCPD & XCA) using an enterprise service bus (ESB).

The security characteristics of these web services include digital certificates for transport level security two-way transport layer security (TLS),  message level security (encryption and digital signature) as well as single sign-on (SSO) based authentication using SAML 2.0 assertions.

One of the challenges was to find a tool we could use to create test harness for these web services, but also to simulate and mock some of these same services during development and testing.

For this I used soapUI. Overall it was not too complicated, except the support for SAML 2.0 since the current version of soapUI (4.0) only supports SAML 1.1 out-of-the-box.

Initially security features on the XCPD web service were  turned off so we could test the basic SOAP web service functionalities. For this a new soapUI project was created by introspecting the XCPD service Web Services Description Language (WSDL) file:

To make the initial project simple, no test suite has been created and the initial operation has been re-labelled "RespondingGateway_XCPD" and its sample request has been modified to query a specific test patient (Joan Hunter) and renamed XCPD_PATIENT_JOAN_HUNTER:

The test is done by submitting the request to the XCPD end-point:

This returns in the response window the XCPD response.

In the next steps, we will setup all the security features for querying our XCPD service :

• digital certificates for transport level security two-way transport layer security (TLS)
• message level security (encryption and digital signature) as well as single sign-on (SSO) based authentication using SAML 2.0 assertions.

The SAML 2.0 assertion will be described in the part two of this post.

1. TLS setup

First we need to indicate that we are using SSL on top of HTTP for the transport layer. For this we need to setup the client keystore via file/preference/SSL settings (from the machine where soapUI will run):

2. Message level security

Probably the first thing you want is to specify your keystores and certificates if you decide to have mutal secure communication. You will use your private key from your key store (my_key_store.jks) to sign messages you send and decrypt the payloads you receive, and you will use specific server public key/certificate (a_another_server_keystore.jks) to encrypt the SOAP messages you send and verify signatures you receive. The server with whom you have secure mutual communication will do the reverse.

The soapUI message level security configuration for SOAP (WS-security) can be setup by selecting our soapUI project XCPD_Tests, right-click and select Show Project View and then add using the sign + in the out-going WS-Security configuration :

 
























You then specify your configurations (e.g. my_config_to_server_A) for outgoing messages and similarly to ingoing messages.

Here how you would define a configuration in the Outgoing WS-security Configurations tab:

1. add a signature tab a
2. add an encryption tab (is you also use SAML 1.1 you would also add a SAML tab and a timestamp tab before adding the signature and the encryption).

2a. Signature

In the Signature tab, you specify:

• the keystore that contain the private key to sign the messages you are going to send (usually your private key - expect if you want to mock another server)
  
• the alias for the key to use for signature
• the certificate password
• the key identifier type (none, binary security token, X509 certificate or subject key identifier)
• the signature algorithm (e.g SHA256)
• the signature canonicalization
• the number of certificates used to sign
• the parts you want to sign (e.g. the content of the body of namespace http://www.w3.org/2003/05/soap-envelope)
  

2b. Encryption


In the Encryption tab, you specify:

• the public key of the server you are sending your SOAP messages to
• the alias for the key to use for encryption
• the certificate password
• the key identifier type (none, binary security token, Issuer Name and Serial, X509 certificate, subject key identifier, Embedded KeyInfo, Embedded SecurityToken Reference, Thumbprint SHA1 Identifier)
• an embedded key name (if any)
• an embedded key password (if any)
• a symmetric encoding algorithm
• a key encryption algorithm 
• the encryption canonicalization
• the number of certificates used to sign
• the parts you want to encrypt (e.g. the content of the body of namespace http://www.w3.org/2003/05/soap-envelope)

And finally, last but not least, you need to specify for the request which outgoing security configuration you want to choose. In our case we have defined only one configuration: my_config_to_server_A at the project level. To select the configuration, click on the Auth Tab at the bottom of the request window, select in the drop-down Outgoing WSS field your configuration. Create and configuring incoming Secure Web Services will be very similar.

You are now ready to test your SOAP Web Service with soapUI!

In  part #2 we will look how SAML can be added to the mix.

Open APIs: State of the Market, May 2010

Today, I was looking at the presentation from John Musser related to Open APIs (see below). Even though these statistics comes mainly from mashup and consumer applications, I was surprised by the fact that REST APIs are gaining market shares over SOAP APIs so rapidly.

In B2B and in the enterprise world in general SOAP is often the top choice. The advantages for SOAP often mentioned are:

• Type checking (via the WSDL files)
• Availability of development tools

On the other hand, REST offers the following:

• Lightweight and easy to build
• Human Readable Results
• Extensibility
• Scalability

In Health Care, SOAP is still widespread and prevalent. However there are some interesting projects such as NHIN Direct Health Information Exchange where the relevance of REST vs other API protocols are discussed.

It will be interesting to see what will be the outcome of such discussions.

Open APIs: State of the Market, May 2010

View more presentations from jmusser.

SOA and Health Care Meaningful Use requirements of the Recovery Act

The Interim Final Rule of the Health Information Technology for Economic and Clinical Health (HITECH) Act was passed by Congress in February of 2009.  Under this act, eligible providers will be given financial rewards if they demonstrate "meaningful use" of "certified" Electronic Health Record (EHR) technologies.

Therefore there is a big incentive for health care vendors to offer solutions that meet the criteria described in the law.  More precisely, the associated regulation provided by the Department of Health and Human Services describes the set of standards,  implementation, specifications and certification for Electronic Health Record (EHR) technology.

As a Software Architect, I was curious to see whether Service Oriented Architecture (SOA) or Web Services in general were mentioned in these documents.

The definition of an EHR Module includes an open list of services such as electronic health information exchange, clinical decision support, public health and health authorities information queries, quality measure reporting etc.

In the transport standards section, both SOAP and RESTful Web services protocols are described. However Service Oriented Architecture (SOA) is never explicitly described or cited. No reference how these services might be discovered and orchestrated in a "meaningful way". I would assume that the reason is that the law makers and regulators wanted to be as vague as possible on the underlying technologies for an EHR and its components.

The technical aspect of "meaningful use" is specified more precisely when associated with interoperability, functionality, utility, data confidentiality and integrity of the data, security of the health information system in general.

These characteristics are not necessarily specific to SOA, but to any good health care software and solution design.

Still, the following paragraph seems to describe a solution that could be best implemented using a Service Oriented Architecture: "As another example, a subscription to an application service provider (ASP) for electronic prescribing could be an EHR Module"  where software is offered as a service (SaaS).  This looks more like the description of an emerging SOA rather than a full grid enabled SOA.

It will be up to the solutions providers to come up with relevant products and tools to maximize the return on investment (ROI) of the tax payer's money and the professionals and organizations eligible for ARRA/HITECH.

SOA will definitively be part of the mix since it gives the ability create, offer and maintain large numbers of complex EHR Software solutions (SaaS) that have a high level of modularization and interoperability.
 

Further developments toward a complete SOA stack such as offering a Platform as a Service (PaaS) and even the underlying Infrastructure as a Service (IaaS) in the cloud will face more resistance in a domain known for a lot of legacy systems and concerns about privacy and security.

The Object Management Group (OMG) is organizing a conference this summer on the topic of  "SOA in Healthcare: Improving Health through Technology: The role of SOA on the path to meaningful use". It will be interesting to see what healthcare providers, payers, public health organizations and solution providers from both the public and private sector will have to say on this topic.