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.

Pragmatic Caching – a simple Cache Configuration Model for Spring

Caching is a widely used instrument when it comes to performance tuning a given application (of course not until you’ve measured the real bottlenecks). For example, you may want to cache objects that are expensive to fetch (i.e. an object graph from database) or to calculate. Whereas most of us have used a kind of Map to ‘cache’ some data on ad hoc basis in the past, there are a couple of mature caching solutions at the market in the meantime that offer sophisticated features for caching, which goes beyond simply holding objects in memory (e.g. Thread pool controls, Element grouping, Remote server chaining (or clustering), failover, …) Deciding to use such a cache solution always comes with the question of the resulting complexity impact when applying ‘cache logic’ to your application.