WS-Security using Cert Authentication with Spring-WS V: How to implement a Message Signing Client

The previous installment set the stage for our WebService Clients’ Security Inftrastucture, that is the Keystore which will provide the Clients private Key in order to build the digital Signature (the encrypted Hash for the messages’ payload) and the related – now signed – Certificate, which will be included within the Request Message (so the receiver – among other things – is able to decrypt the embedded digital Signature in order to compare it with the  Hash rebuilded by himself for the sake of data integrity).

WS-Security using Cert Authentication with Spring-WS IV: How to set up your Clients’ Keystore

So far, our WebService is readily configured for only accepting signed messages, forcing clients to include their Certificate for decrypting the digital Signature again on server side (verifying that the message is originally send from an authorized client). In addition to that, the client’s Certificate has to be signed (issued) itself by a Certificate Authority (CA) which is accepted by the WebService (in that the CAs Certificate is contained within the WebServices Truststore)

WS-Security using Cert Authentication with Spring-WS III: Setting up the Security infrastructure

The Story so far

In the first episodes, we configured Spring-WS for rejecting incoming Messages which were sent from ‘unauthorized’ Clients, including the demand for Clients to be trusted by our WebService Endpoint: We only trust in a Client, if its Certificate is in turn issued by a Signer we trust. In our case, the Clients Certificate have to be issued by a Certificate Authority (CA) we trust. We inform Spring-WS about that trusted CA by importing the CAs Certificate into our Truststore (a common Java Keystore), which is declared as the Truststore to check against within Spring-WS’ application context.

WS-Security using Cert Authentification with Spring-WS II: Accessing the certificate

In the last episode, we’ve introduced the Security Interceptor and its Collaborators (KeyStoreHandler, Truststore, Security Policies) as the main Actors for activating Certificate Authentification along with an appropriate application context for configuring Spring-WS accordingly.
Now every incoming request message have to be signed by the Sender (using its private Key), which also implies that the Sender’s public Key has to be included within the SOAP envelope (in form of an appropriate Certificate which contains the Signers public Key, used to decrypt the clients digital Signature).

How to secure a WebService using Spring-WS and Certificate Authentication

Implementing a plain WebService with Spring-WS is rather easy and straight forward: Following the ‘contract first‘ approach, you mainly have to come up with an xsd schema for defining the types and elements, constituting
the structure of your request and response messages (including the so called wrapper elements which are in compliance with the WS-I Basic Profile and also used to designate the different operations offered by the
WebService). The rest (not REST ;o)) is more or less a matter of configuration.

SOA essentials for Technologists, Developers and the IT-minded – Part I: Motivations for SOA

As the IT world encountered SOA as the new answer to some old problems, not few in the technological sphere thought that it’s rather a temporary marketing hype than a new paradigm. Well, SOA is still here, meanwhile in its second hype cycle and there are still many voices which are afflicted by doubts about the real essentials. Especially from a technological point of view, not few are asking about the true innovations that SOA will bring along, making it distinguishable from other conversant architectural paradigms.