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.

Refining Uncle Bob’s Clean Code

I’ve just finished reading ‘Uncle Bob’s’ new book ‘Clean Code‘. I fully agree with most of the statements and it was a pleasure to read, especially because Uncle Bob and his co-authors have a talent for putting some of the most relevant values and principles of software development into so simple words (i wished they have crossed my mind within more than one discussion in the past).

Initializer Build idiom – facts and fallacies

Nowadays, most Java developers are quite familiar with the so called Initializer Build idiom. It’s meanwhile a well known idiom for building hierarchical structures, especially when creating formations which follow the composite pattern.

In short, you mostly want to avoid building those structures in a verbose way by instantiating each element separately and assembling the elements afterwards (that is defining the parent – child relationships), but combine both (instantiation and assembling) within one step in a more concise way.

I applied the idiom the other day, only to detect some fallacies (i was falling for) that will come with that idiom, if you don’t attend to the given specialities. The following sections will give a brief overview of the specific facts that will come with that idiom along with some of the more severe fallacies you have to be aware of.