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.
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:
- add a signature tab a
- 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.
