As a kid, i loved to play with Lego bricks, especially to build freaky spacecrafts.

At that time it was easy to let my phantasy go (where noone has gone before) and build completely new models simply by composing some standard bricks. Those bricks weren’t too specialized, meaning that there weren’t too many constraints on how to combine them. On the other side you always had to compose a new spacecraft from the very ground up as there weren’t some more higher organized units like engines or control cabins.

Nowadays, you’ll find such units. There are engines, control cabins or a whole commando bridge, Wings, Field Generators and so on – a whole set of higher organized units whithin a single domain. On the other side, you can’t combine every unit with an arbitrary other unit within that domain since there are some ‘constraints’  that will prohibit some unsound combinations.

Now you may ask how that cute childhood story relates to Scala?
You may have seen already some similarities to the field of software development where you also want to compose some higher organized building blocks within a certain domain, enforcing that they are only combined in a proper way. It turns out, that Scala’s concept of traits provide some mechanisms of ‘mixin’ them together while enforcing the compliance of some constraints. This may sound too abstract at that point, but hold on – we’ll build some spacecrafts in the above mentioned way and things will get clearer.

Look, it’s a spacecraft

Let’s start with a hull for our spacecraft. To keep things simple and to focus on the core idea of constrained
composition, the spacecraft’s hull will only provide one abstract method engange to start the craft:

abstract class Spacecraft{

    def engage
}

As you can see, method engage and therefore the whole class is abstract, so you can’t instantiate a pure hull
of a spacecaft. So whenever we want to build a full fledged craft, we may have to ‘add’ (or mix in) a component
that knows how to engage that craft.

Captains place

Typically, a spacecraft possess a kind of ‘control center’ which is normally well suited for initiating the
start of a craft, hence should provide an implementation for method engage. There may be different kinds of
control centers that could be used for building your own, customized spacecraft – e.g. a whole commando bridge for
those big deep space crafts or a small control cabin for those little crafts mainly maneuvering near the orbit.

 trait CommandoBridge{

def engage { for( _ <- 1 to 3 ){ speedUp } }

    def speedUp
}

Now we see what it means to engage (a Spacecraft) if composing a commando Bridge to the hull. We simply speed up that craft 3 times.
But hold on – although we know what it means to engage that craft, speeding up that craft is not in the responsibility of the commando bridge, since speedUp is left abstract (speeding down is omitted since it follows the same mechanism – you get the idea).

Re-calibrating all Dilithium crystals

So the spacecraft seems to be incomplete without a unit to speed it up – let’s call such a unit ‘engine’.  Again, there may be different kinds of engines we could select from to assemble our craft.
Let’s say there is a Pulse-Engine that directly supports the command of speeding up:

trait PulseEngine{

    val maxPulse: Int

    var currentPulse = 0;

    def speedUp { if( currentPulse < maxPulse ) currentPulse += 1  }
}

As you can see, a PulseEngine is able to speed up until a maximum pulse rate. In order to ‘produce’ different pulse engines (supporting different maximum pulse rates for different types of crafts), the field is again left abstract.
Now we could create our first spacecraft, using a commando bridge and a pulse engine (let’s say that’s all you need for building a full fledged spacecraft).

class StarCruiser extends Spacecraft with CommandoBridge with PulseEngine{

    val maxPulse = 200
}

As you can see, we’ve created a new (Sub-)Type of a spacecraft and mixed in both Traits, obtaining a commando bridge (that knows how to engage the whole craft) and an engine (that knows how to get the craft into speed when engaging the craft).
The only thing left is to define the maximum pulse rate our StarCruiser is able to achieve.

Wiring

In the above case, all units fitted together smoothly. For example, a pulse engine provided exactly the ‘interface’ (speedUp) that was needed by a commando bridge, so you could compose both without additional work. Let’s take a look at another control center, that we could apply to our craft, that may offer an incompatible ‘interface’ :

trait ControlCabin{

    def engage = increaseSpeed

    def increaseSpeed
}

This time we need to do some additional wiring, if we want to compose a new type of craft using a control cabin and a pulse engine, since both units don’t fit together directly (the dependency needed by ControlCabin (increaseSpeed) isn’t directly fulfilled by PulseEngine)

class Shuttle extends Spacecraft with ControlCabin with PulseEngine{

    val maxPulse = 10

    def increaseSpeed = speedUp
}

As you can see, we have to wire together the control cabin with the pulse engine in order to let them cooperate.
In the same way, we could think of another kind of engine which offers a completely different ‘interface’:

trait WarpEngine extends Engine{

    val maxWarp: Int

    var currentWarp = 0;

    def toWarp( x: Int ) { if( x < maxWarp ) currentWarp = x }
}

Again, we need to wire together the concrete control center with the WarpEngine, depending on their incompatible ‘interfaces’.

Let’s compose a craft, using a commando bridge and a warp engine.
Firstly, we are forced to define a maximum warp level, since it’s an abstract field of WarpEngine. Secondly we have to wire together the commando bridge with the warp engine, that is to ‘route’ the commando bridge’s method speedUp to the warp engines ‘interface’ toWarp with an appropriate implementation:

class Explorer extends Spacecraft with CommandoBridge with WarpEngine{

    val maxWarp = 10

    def speedUp = toWarp( currentWarp + 1 )
}

Alternatively, we could also use a simple control cabin for another type of spacecraft. Again we have to link the contol cabins commands (increaseSpeed) to the warp engines ‘interface’:

object Defiant extends Spacecraft with ControlCabin with WarpEngine{

    val maxWarp = 20 // claimed by WarpEngine

    def increaseSpeed = toWarp( 10 ) // claimed by ControlCabin
}

Restricted Access

Until now, we only applied a control center or engines to spacecrafts. But nothing would restrict us to use those units in other domains so far. Say we want to build a certain airplane and apply a warp engine.

class Jet extends Airplane with WarpEngine{

    val maxWarp = 5
}

It’s propably not the best idea to equip a Jet with a warp engine, since this seems to be a bit oversized for an airplane. We need a way to restrict the usage of warp engines – they should be only applied to spacecrafts. Fortunately we can express this kind of constraint, using Scala’s self type annotation. Included within a trait, it’s like saying ‘this trait is only allowed to be mixed into a type of x‘ (in our case ‘Spacecraft‘):

trait WarpEngine extends Engine{

    this: Spacecraft =>
    ...
}

As you can see, we used the WarpEngines self type to restrict its appliance only to spacecrafts. In all other cases, Scala’s compiler will complain about an unsound mixin.

What makes a spacecraft a spacecaft ?

With selftypes, we now have an instrument to restrict the usage of a trait to be mixed in only to a certain Type.
On the other side, we aren’t forced to use a control center or an engine at all if creating a new spacecraft, since we could provide an implementation of the spacecrafts abstract methods directly within a subtype. That may be fine in some cases, but what if we want to state that a spacecraft has to be composed of at least a certain type of control center and a certain type of engine? Again, we can use the service of the self type annotation, this time applied to our abstract class spacecraft, stating that a spacecraft should at least be compound of a control center and an engine:

abstract class Spacecraft{

    this: ControlCenter with Engine =>
    ...
}

The only thing left is to provide an appropriate type ControlCenter resp. Engine and the correct classification of those concrete units (e.g. ‘CommandoBridge is a ControlCenter‘)

 trait ControlCenter

 trait CommandoBridge extends ControlCenter{ ... }

 trait ControlCabin extends ControlCenter{ ... }

 trait Engine

 trait PulseEngine extends Engine{ ... }

 trait WarpEngine extends Engine{ ... }

Summary

Abstract methods and self type annotations are two powerful tools which help to guide or constrain the composition of traits.
You may use abstract methods and abstract fields to enforce a kind of ‘wiring’ between multiple units or at least to force the definition of some concrete information.
You may use a self type annotation to restrict the appliance of a trait, so that it can only be mixed in to a certain type (or subtypes). On the other side, you’re able to enforce that a certain trait (or subtype) have to be mixed in to a certain type, again by using a self type annotation.
In all cases, the ‘composer’ of those units will be guided by the compiler – you can’t forget to give a definition for an abstract method or arrange an unsound composition, since all those ‘constraints’ are based on Scala’s statically typed Type system.

I published the slides from my Scala Talk which i did yesterday evening at XPUG Rhein/Main:  ‘Scala – a Scalable Language‘

Content:

• Motivation
• Scala & OO
• Type System
• Scala & Functional Programming (Function values, Closures, Currying, …)
• Characteristics (Expressiveness, Conciseness, Extensibillity, Scalabillity, …)
• Features (Composition, Pattern Matching, Modules, Monads)

Enjoy

Some voices say that Scala’s type system is rich but complex.
Traits are part of Scala’s type system, but their application isn’t that mysterious nor is it incomprehensible.
This post will give some introduction to one of their main operational areas – Traits used as Mixins, a well known concept which is already provided by some dynamic languages like Ruby.

Mixins

As their name reveals, Traits are usually used to represent a distinct feature or aspect that is normally orthogonal to the responsibility of a concrete type or at least of a certain instance. Therefore, the functionality of a Trait may be required by completely different types that have nothing in common or aren’t even members of the same type hierarchy.

Let’s say you want to model the ability to sing as such an orthogonal feature: it could be applied to Birds, Persons (well, not all) or even to Radios (c’mon, with just a little bit of imagination).

In Java, you could come up with an Interface in order to express this ‘trait’:

public interface Singer{
public void sing();
}

Now every type which is also a singer may implement this interface and give an appropriate implementation:

public class Bird implements Singer{
...
public void sing(){ ... }
}

...

public class Cicada extends Singer{
...
public void sing(){...}
}

Now all of them (and their subclasses) can be treated as Singers even – as said – a Cicada is not a Bird nor a Radio.
If some of them (or all) should sing the same way, you could use ‘copy n paste’ or place a default implementation and use composition. But nevertheless, you have to provide a definition of sing() in every of that classes – if only because to delegate to that implementation.
No matter which option you choose, the proportion of boilerplate code isn’t just small (Inheritance may be no option at all, because there may be no common parent class. Particularly, placing sing() into a too general supertype would mean that ALL subtypes would be singers).

Mixin’ traits ’statically’

Scala provides an elegant way to define what it means to sing (at least a default implementation) and reuse it quite idependently by separating that feature as a trait and using that trait as a mixin.
That said, you can (but don’t have to) provide a definition for some or all methods of that trait and mix that trait into every type you want to:

 trait Singer{
   def sing { println( "singing ..." ) }
 }

 ...

 class Bird extends Singer

As you can see, the class definition of class Bird has mixed trait Singer into it’s own definition using keyword ‘extends‘.
Now Bird has mixed in all methods (and all other members of the trait) into its own definition as if class Bird would have defined method sing() on its own – no boilerplate delegation code necessary.
Of course you now can ask every instance of a Bird to sing.

A last word on keyword ‘extends‘: you also (or normally) use it to let a class inherit from a superclass. In case of a trait you only use it if you don’t inherit from a superclass and then only for mixin in the first trait. All following traits (should you want to mix in more than one trait) are mixed in using keyword ‘with‘:

class Insect
class Cicada extends Insect with Singer

class Bird extends Singer with Flyer    // given Flyer as another trait
 

Mixin’ traits ‘dynamically’

In case of class Person, we face another special problem: We only want some instances of Person to be singers. We can’t implement interface Singer on class Person since this would turn every instance of Person into a singer.

Fortunately, Scala allows to mix in a trait ‘dynamically’ when creating a new instance of a class. In that case, only that special instance will be a singer and provide the methods of that trait:

class Person{

def tell { println( "here's a little story ..." ) }
}

val singingPerson = new Person with Singer
person.sing

As you can see, we’ve created a new instance of type Person, saying that this instance is also a Singer by using keyword ‘with‘.
Actually, we’ll receive an instance of a new anonymous class that is a Person as well as a Singer.

 println( "class of singing person: " + singingPerson.getClass )  // -> com.mgi.traits.TraitsAsMixins$$anon$2
 println( "class of singing person is a Person? " + singingPerson.isInstanceOf[Person] )  // -> true
 println( "class of singing person is a Singer? " + singingPerson.isInstanceOf[Singer] )  // -> true

Unlike in Java you could call any method on that instance without any typecast (at least within the scope where you’ve created that singing Person), no matter if the method was originally defined within Person or Singer.
Of course you may encounter some problems when sending that ’special’ singing instance to a method that expects a parameter of type Person. Within that methods scope, a Person (in general) isn’t a singer, therefore calling sing() would cause an error since method sing() is no regular member of class Person.

Is it a Bird? Is it a Singer ? …

In that case, Pattern Matching may come to the rescue. Since you could also try to match against an arbitrary type, we could also try to match a Person against trait Singer. Let’s say we want to cast some Persons for a Show. If that Person is a singer, she should sing, otherwise tell a story …

 def cast( p: Person ) {

p match {
case s: Singer => s.sing
case _ => p.tell
}
 }

Conclusion

Scala’s traits are an elegant way to separate concerns. Every feature may be separated within an own trait and can than be mixed into every type or instance that should posses that trait. This first introduction only gave some superficial examples, motivating why and how to use traits as Mixins.
The next ones will deal with some more interesting questions like how to claim that a trait may only be mixed into types (or in conjunction with some other traits) that offer some needed characteristics or how to leverage Mixins in order to inject some Dependencies into the class the trait is gonna be mixed in.

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).

With that at hand, we’re now in a position to implement the WebService Client, which should sign any outgoing message, adhering to the given Security Constraints of our WebService.
We’ll again leverage Spring-WS’ potential and use org.springframework.ws.client.core.support.WebServiceGatewaySupport for implementing our Gateway class, which will encapsulate the whole procedure of Message Signing and Message Sending.

public class WebServiceGateway  extends WebServiceGatewaySupport{
  ...
  public void callService( Resource payload ){...}
}

Using WebServiceGatewaySupport gives us the chance to provide some of the crucial information (like the
WebServices’ location) via Springs’ application context:

...
<bean id="wsGateway" class="ffb.fsm.ws.gateway.WebServiceGateway">
<property name="defaultUri"
      value="http://www.myWebserviceProviderUrl.de/ws/auction"/>
<property name="messageFactory" ref="soap11MessageFactory"/>
<property name="defaultRequest"
      value="classpath:com/mgi/ws/resource/placeBidRequest.xml"/>
  ...
</bean>
...
<bean id="soap11MessageFactory"
      class="org.springframework.ws.soap.saaj.SaajSoapMessageFactory">
<property name="messageFactory">
    <bean class="com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl" />
  </property>
</bean>
...

As you can see, we provide the WebServices’ Location in form of property defaultUri (so we don’t have to pass the URI within every single request). Further, we’re explicitly using SOAP 1.1 as the ‘communication protocoll’ for the information structure and statically refer to a resource that will hold the payload of the Request Message.
Please note, that i’m not going into any further details on how to implement a ’standard’ WebService Client via Spring-WS, since there are some good resources on that topic out there – instead we want to focus mainly on Message Signing.

A simple Message Signer

Signing of the ‘original’ (unsigned) Message is best encapsulated within a class of its own – let’s call it MessageSigner. Although Message Signing can be done more or less completely by configuration, i’m going to implement the process of Message Signing here for the sake of clarity.
Our MessageSigner will deliver an org.springframework.ws.client.core.WebServiceMessageCallback which in turn is responsible for securing the outgoing message. This WebServiceMessageCallback will be used by our WebServiceGateway to ‘intercept’ the Message Sending Process and manipulate the outgoing request message right before its final delivery (as we’ll see later).

Like on the server side – we’ll also rely on XWSS when it comes to securing the outgoing message, thus our MessageSigner will behave according to some given XWSS Security Constraints. This time we have to provide those Security Constraints on client side, forcing the MessageSigner to sign the outgoing Message. Therefore, we’ll use an instance of com.sun.xml.wss.XWSSProcessor which gets fed with the Policy File (which will hold the Configuration to sign the outgoing message) and the related Keystore, holding the Key-Pair used for message Signing.

import java.io.IOException;
import java.io.InputStream;
import javax.xml.soap.SOAPMessage;
import org.springframework.core.io.Resource;
import org.springframework.ws.WebServiceMessage;
import org.springframework.ws.client.core.WebServiceMessageCallback;
import org.springframework.ws.soap.saaj.SaajSoapMessage;
import org.springframework.ws.soap.security.xwss.callback.KeyStoreCallbackHandler;
import com.sun.xml.wss.ProcessingContext;
import com.sun.xml.wss.XWSSProcessor;
import com.sun.xml.wss.XWSSProcessorFactory;

public class XwssMessageSigner {

  private final XWSSProcessor processor;

  public XwssMessageSecurer( Resource policyFile, KeyStoreCallbackHandler keystoreHandler ) throws Exception {

    InputStream in = policyFile.getInputStream();
    XWSSProcessorFactory factory = XWSSProcessorFactory.newInstance();
    processor = factory.createProcessorForSecurityConfiguration( in, keystoreHandler );
    in.close();
  }

  public WebServiceMessageCallback getCallback() {

    return       
      new WebServiceMessageCallback() {
        public void doWithMessage( WebServiceMessage message ) throws IOException {

          SaajSoapMessage origSaajMessage = (SaajSoapMessage) message;
          SOAPMessage origSoapMessage = origSaajMessage.getSaajMessage();

         ProcessingContext context = new ProcessingContext();

          try {
            context.setSOAPMessage( origSoapMessage );
            SOAPMessage securedSoapMessage = processor.secureOutboundMessage( context );
            origSaajMessage.setSaajMessage( securedSoapMessage );
          }
          catch (Exception exc) {
            exc.printStackTrace();
            throw new IOException( exc.getMessage() );
          }
        }
      };
   }
}

As you can see, our Signer relies on a policy File (containing the Security Constraints) and a KeyStoreCallbackHandler, which is responsible for handling the key /certificate requests. Both Dependencies will be injected into XwssMessageSigner via constructor injection (as we’ll see later).

Inside the WebServiceMessageCallback, we’ll receive the original message in a state just before sending it to the receiver. The message already conists of the whole Soap structure (Payload Body and Envelope), so that we can refer to all parts of it. After retrieving the original Soap Message (extracted from Spring-WS’ SaajSoapMessage wrapper), XWSSProcessor is going to secure it according to the given Security Constraints. The outgoing message is than replaced by our newly secured Soap Message.

Security Policies

In order to get our MessageSigner to really sign the Message, we have to come up with an accordant policy File. Like we did on the server side, we also have to configure it for Message Signing. Note, that we could have placed every possible type of Security Configuration within the Policy file and our MessageSigner would behave accordant to that policy (under that point of view, ‘MessageSecurer’ would be a better, more general name for our MessageSigner).

<xwss:SecurityConfiguration dumpMessages="true"
  xmlns:xwss="http://java.sun.com/xml/ns/xwss/config">
    <xwss:Sign id="signature">
      <xwss:X509Token certificateAlias="wstestclient"/>
    </xwss:Sign>
</xwss:SecurityConfiguration>

As you can see, we force Message Signing by placing xwss:Sign within theSecurity Configuration, further arranging, that the Signing should be based on X509 Certificates. Note, that we also define the alias Name of the Key-Pair which should be used for building the digital Signature (when refering to the Keystore, which we’ve assigned to our instance of XWSSProcessor).

Configuration

Now we’re able to configure our MessageSigner also within the application context, supplying the conning Security Constraints and the underlying Keystore (via the before mentioned KeyStoreCallbackHandler) which holds our Key-Pair for Message Signing:

<bean id="xwssMessageSigner" class="com.mgi.xwss.XwssMessageSigner">
  <constructor-arg value="classpath:com/mgi/xwss/securityPolicy.xml"/>
  <constructor-arg>
    <bean class="org.springframework.ws.soap.security.xwss.callback.KeyStoreCallbackHandler">
<property name="keyStore" ref="clientKeystore" />
<property name="defaultAlias" value="wstestclient"/>
<property name="privateKeyPassword" value="keyPairPasswd"/>
    </bean>
  </constructor-arg>        
</bean>

<bean id="clientKeystore" class="org.springframework.ws.soap.security.support.KeyStoreFactoryBean">
<property name="location" value="classpath:com/mgi/xwss/XWSSClientKeystore.jks"/>
<property name="password" value="keystorePasswd"/>
</bean>

With our MessageSigner ready to go, we’ll extend the configuration of WebServiceGateway. It will now accept the MessageSigner as an additional Dependency:

<bean id="wsGateway" class="ffb.fsm.ws.gateway.WebServiceGateway">
  ...
<property name="xwssMessageSigner" ref="xwssMessageSigner"/>
</bean

Delegation

With the MessageSigner injected, WebServiceGateway will now delegate the Signing of outgoing messages to that MessageSigner simply by requesting an instance of the provided WebServiceMessageCallback and let him do its job (of course we could have requested an instance of WebServiceMessageCallback only once and reuse that instance for every Request):

public class WebServiceGateway  extends WebServiceGatewaySupport{
  ...
  private XwssMessageSigner xwssMessageSigner = null;
  ...
  public void setXwssMessageSigner( XwssMessageSigner signer ){
    this.xwssMessageSigner = signer;
  }

  public void callService() throws IOException{
    callService( defaultRequest );
  }

  public void callService( Resource request ) throws IOException{

    Source requestSource = new ResourceSource( request );

    try{

      getWebServiceTemplate()
        .sendSourceAndReceive(
          requestSource,
          xwssMessageSecurer.getCallback(),
          new MySourceExtractor() );        
    }
    catch( SoapFaultClientException e ){
      // error handling
    }
  }

  public class MySourceExtractor implements SourceExtractor{
    public Object extractData( Source src ) throws IOException, TransformerException {

    DOMSource dom = (DOMSource) src;
      // process response     
      return ... // processed response;
    }
  }
  ...
}

You see, that there’s nothing magic about it at all. WebServiceGateway gets called in order to send a new request to our WebService (which is configured via the clients’ application context, as we’ve seen before).  In the easiest case, we could simply call callService(), so that the configured default message used, signed and send. Of course, you could also call callService( Resource request ), passing an individual payload that is to be signed and send over the wire.

Summary

Message Signing on the client side is also done by leveraging XWSS in form of an XWSSProcessor which is configured accordingly (using an appropriate Security Policy File). The Signing Process is encapsulated within a class of its own – MessageSigner. The client is able to use MessageSigner in that it request a WebServiceMessageCallback which in fact does the job of securing the outgoing message. In our case, according to the given Security Policies, a Hash is build based on the message payload (also including the Timestamp, which is also regarded by default, if not specified otherwise) which gets encrypted afterwards. Encryption is done by using the private Key of a Key-Pair, whose alias name is also defined within the Policy File – the underlying Keystore is configured via Spring-WS’ application config, which in turn is passed to the responsible XWSSProcessor. The encrypted Hash is in fact the digital Signature which is embedded within the outgoing message. In order to give the receiver a chance to detect some unwanted payload manipulation, it will also build a Hash, also based on the payload and Timestamp. To compare that Hash with the digital Signature which is embedded within the message, the receiver has to decrypt the Signature again. This can only be done with the related Public Key (contained within the clients certificate) which therefore also has to be passed to the receiver. Once you’ve retrieved the certificate (also embedded within the message), you can perform whatever kind of logic you want to do based on the client certificate (as seen in episode two).

That’s it

You’ve seen how to configure Certificate Authentification using Spring-WS on client and server side and hopefully got some introduction to the underlying ideas like Message Signing, Certificate Authorities and Public Key Infrastructure.
Of course, Certificate Authentification might only be a reasonable instrument for some use cases which heavily rely on
some given Security concerns.
As always, you have to be clear about your projects goals, the given Security context your WebService is acting in and the knowledge about the given trade offs (extended configuration vs. increased Security) and consequences when leveraging WS-Security using Certificate Authentification.
Maybe this series could gave some useful information on that topic or at least some helpful suggestions.

Again there were some interesting debates in the near past, which once again discussed the role of the DAO within enterprise applications, especially based on JEE and EJB 3. One main argument for the dissapearance of DAOs is the very unlikely probability to exchange or replace your once chosen persistence technology, so that you may directly rely on EJBs Entity Manager within your Business Services (since it’s in fact very unlikely that your underlying persistence technology will change). This argument is mostly accompanied with the concern, that the introduction of a DAO Layer might increase complexity and introduce some performance penalties, while direct usage of the Entity Manager let collapse two separate Layers into one.

All in all, those statements raise the impression, that DAOs form a kind of Layer in their own right, or represent at least the main part of your data access Layer.

Let me give you some counter arguments (using some input from ‘J2EE Design and Development’ as well as ‘Domain Driven Design’) which will show you that DAOs aren’t so much about Layers but more importantly about Abstraction and domain specific Encapsulation (that said, with the disappearance of the DAO, collapsing two Layers into one as suggested, there is STILL a data access Layer, you only just jumbled business and data access logic).

Abstraction and Separation of concerns

In this post we mainly look at Abstraction as a ‘result of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose‘. In case of reasoning about the existence of DAOs , we’re mainly interested in the second part; using Abstraction as a strategy of simplification, wherein concrete details are left, so that a DAOs Client is able to focus on a DAOs effects (the WHAT) he wants to benefit from, rather than worrying about the details (the HOW).

Within this frame, a DAO is mainly useful for decoupling Business Logic and Data Access Logic. The responsibilities between Business Services and DAOS are cleanly separated, so one can easily distinguish the business Logic (e.g. business workflows and rules) from persistence logic / data access logic (e.g. handling specific persistence issues).
From the clients point of view, a DAO hides all the fiddly details of persistence operations, especially if persistence logic is not representable as a one-step-operation but consists of multi-step-operation logic which the client don’t want to mix up with his own tasks.

To make it clear, we are not talking about applications, where the business logic mainly consists of plain data acces operations and not much else. We rather consider separation of existent business logic and data access logic, so a business service can keep focused on the domain model and its domain centric tasks.

Encapsulation

A DAO encapsulates data specific logic that may not be intermingled with business logic – there might be various reasons which represent valid conditions (not only esoteric facts, as i saw those settings more than once in former projects):

• providing some kind of complex compensation logic (e.g. logic not expressable by simply marking a Roleback)
• providing some domain related data integrity (e.g. difficult to express as direct constraints within your persistence store)
• transparently handling of normalization issues (the underlying database may was designed for another system or serves in roles other than object store)
• compensating the mismatch between data model and domain model (the relational data design may doesn’t reflect the domain model)
• shielding the client from constraints of a specific persistence technology

All those conditions result in operations you don’t want to embedd next to your business logic.
Under this point of view, you can look at a DAO as a special kind of Strategy pattern, where the implementation of different data access strategies are possible and cleanly hidden from their clients, coming with a very valuable consequence: it leaves us Choice!

Where a DAO is data source agnostic (works with any underlying persistence technology), using the Entity Manager directly within your business Service will lock you into one way of accessing (persistent) objects and one particular O/R Mapping solution.

Plain old (Java) Interface

DAOs (better DAO implementations) usually implement one ore more DAO interfaces. One important (secondary) use case which is often neglected, is the fact that those interfaces are under your control (not so with Entity Manager) and therefore provides the potential for a wide variety of additional (crosscutting) concerns:

• gives you the potential for very different implementations of data access strategies and persistence technologies
• allows for interception strategies (e.g. special, fine grained caching strategies which can be decided on a per-DAo level, time measurement, Filtering, …)
• allows for portable design that isolates any non portable features behind interfaces
• provides a common approach to (multiple) (data) resource management, regardless of the data access strategy
• able to provide a consistent exception hierarchy (not bound to a single exception type hierarchy of one specific technology)

That said, you don’t rely on one specific persistence technology (you may want to thinkk about the costs trying to use a single persistence technology in all use cases), you could even mix O/R with plain SQL or other access strategies on a per-method or per-DAO level due to specific application needs (e.g. improve performance by varying query techniques if needed or leveraging vendor specific features).

Intention revealing interface

By being able to express the offered possibilities and effects of (data) object access through an interface, we’re able to protect clients (Business services) from database oriented models, as said before e.g. by providing transformation strategies to the domain model inside the DAO or Repository (i’m not going into details of the difference between a DAO and a Repository here ).
In this case you’re able to easily provide verbs (not only nouns) in an intention revealing way, expressing the ‘actions’ using a domain centric vocabulary (‘remove all yesterday orders of a customer’).
Under this view, a DAO offers a clear, strongly typed API, which communicates the core concepts and operations of a certain domain (e.g. allow for finder methods with domain arguments, removing the need to maintain object query language Strings in business services). By looking at that interface, it’s immediately obvious which (persistent) objects are retrieved (created, deleted) – the interface communicates the core underlying design decisions about object access (while Entity Manager (with its generic API) allows to apply any persistence operation to any object which makes it hard to find out actually available operations for a specific domain)

Interface segregation Principle

Regarding DAO interfaces, you’re able to obey the Interface Segragation Pronciple: within that frame, DAO interfaces belong to the different Business services which describe their needs by providing a specific DAO Interface they’ll use.
A single DAO implementaion then may implement one ore more DAO Interfaces (hidden from the client eyes) where (again) the Entity Manager only provides a generic API: client’s can’t communicate their needs in a domain oriented way (by providing an accordant interface) in that case.
That said, a specific DAO Interface meets the demand of expressing specific (data) object access needs for a Business service (if seen as a ‘component’ which have to express it’s ‘dependencies’)

Conclusion

As seen, a DAO is not just a Layer for the sake of Layering (replacing that Layer if in need). Instead it provides the potential for clearly separating business logic from data access logic – so the value of a DAO is more related to abstract some irrelevant aspects (in the eye of WHAT, while of course relevant in the eye of HOW ) away from its Clients, resulting in a cleaner separation of concerns.

Again, you always have to consider the given forces and constraints when arguing about the usefulness of DAOs in a specific setting: Of course – like most design decisions – it’s a matter of choosing the one or other side of a trade off. So one is right to say it depends on the context whether to use a DAO or directly include data access logic inside a business service – but you have to be clear about the consequences (which should be aligned with the projects goals which in turn should be also clear). And letting the DAO dissapear or collapsing with your business logic comes with the loss of the mentioned possibilities of Abstraction.

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)

In this entry, we will set up the clients security infrastructure in that we create a Key-Pair and let the related Certificate be signed by the WebServices trusted CA. In the next episode, we’re going to build an accordant WebService-Client using Spring-WS’ WebServiceTemplate which will be configured to sign its outgoing messages by using the generated clients’ private Key and the associated signed Certificate.

Client Keystore

First of all, we’ll create a new Keystore along with the client’s private Key (needed for encrypting the messages digital Signature) and the related Certificate (holding the public Key, needed to decrypt the encrypted digital Signature again). Again we’ll use Javas’ Keytool for that purpose, creating the Keystore on an arbitrary location on the clients file system, answering the upcoming questions accordingly.

keytool -genkey -alias wsClient -keyalg RSA -keystore Keystore.jks

Note, that we chose ‘wsClient‘ as the alias name for refering to that Key-Pair any time further.
If you remember the second part of this tutorial, we did some authorization based on the Common Name of the client Certificate. So if you rely on that kind of pattern, be sure to choose an appropriate Common Name when asked about it while generating the Clients’ Key-Pair.

Signing the Clients’ Certificate

The Certificate we’ve created is initially self signed. It needs to be signed by the WebServices’ trusted CA in order to be recognized as an accredited client Certificate. Hence we have to initiate a Certificate Signing Request and ’send’ it to the CA in question:

keytool -certreq -keystore Keystore.jks -alias wsClient -file wsClient.cert.req

We’ve created a new Certificate Signing Request based on the Certificate which belongs to our newly generated Key-Pair (pointing to it by refering to the associated alias name). You’ll find a new file ‘wsClient.cert.req‘ which represents that Sigining Request which you now have to ’send’ to the CA for signing.

Switching back to the server side, we now have to sign the ‘incoming’ Certificate Signing Request (after we made sure that the client behind that request is a trustworthy one). Following up the last episode, we’ll extend the folder structure within our ‘Certificate Factory‘ by creating a folder [CERTFACTORY_HOME]\signing in order to hold
Certificate Signing Requests and the resulting signed client Certificates. After putting the incoming Signing Request into that folder, we can start to sign the embedded client Certificate, again using OpenSSL (being on the command line at [CERTFACTORY_HOME]):

openssl ca -config openssl.cfg -out signing\signedWsClient.pem -infiles signing\wsClient.cert.req

Again, we have to convert the signed Certificate from PEM to DER format in order to be compatible with a Java Keystore:

openssl x509 -outform DER -in signing\signedWsClient.pem -out sigining\signedWsClient.cert

After that, we’ll send the signed client Certificate signedWsClient.cert (along with the CAs Certificate which you’ll still find under [CERTFACTORY_HOME]\ca\cacert.cert back to the Client. Note, that we also need to send the CAs Certificate because a Java Keystore need to establish a valid Certificate Chain when importing (signed) Certificates into a Keystore (and that’s exactly what we’re now going to to).

Importing the signed Client Certificate

Back on the client side, we now have to import the signed Certificate (which we’ve received from the CA) into the Keystore, since there’s still the original self signed one inside. First we have to import the CAs Certificate, statisfying the mentioned need for exhibiting a valid Certificate Chain when importing the signed client Certificate afterwards:

keytool -import -file cacert.cert -alias wsCA -keystore keystore.jks

Now we’re able to import the signed client certificate, which will automatically substitute the original self signed Certificate:

keytool -import -file signedWsClient.cert -alias wsClient -keystore keystore.jks

Note, that it’s essential to import the signed Certificate under the alias name under we’ve generated the clients Key-Pair originally.

Summary

We’ve created a clients’ Keystore which contains a private Key and a related signed Certificate. The Certificate has to be signed by the CA which our WebService trusts in. Having a client Certificate inside a request message which may be signed by another CA would result in the Rejection of that request, since that CAs Certificate don’t reside in the WebServices Truststore (of course you could also import more than one CA Certificate into your Truststore, so that the WebService would accept request messages with embedded Certificates which in turn are signed by different CAs).
For receiving a signed Certificate, we first have to generate and ’send’ a Certificate Signing Request to the CA in question, which in turn have to sign the client’s Certificate and return it along with the CAs Certificate back to the client. The client will then import the CAs Certificate (as the root of the Certificate Chain for the signed client Certificate) and afterwards substitute the original self signed client Certificate with the new signed Certificate.

With that infrastruture at hand, we’re now prepared to implement a WebService-Client which will use the contained private Key in order to encrypt the digital Signature for arbitrary request messages (since your WebService asks for ‘Message Signing‘ according to its configured security policies from episode one) which automatically results in the embedding of the clients (now signed) Certificate within the request messages’ security header (which will be used by the WebService to decrypt the encrypted digital Signature along with some of our desired ’side effects’ of being able to access to the Certificates’ attributes for authorization purposes or restricting access to our WebService to only a group of accredited Clients).

So in the next episode, we’re going to implement that Web-Service Client, also using Spring-WS (namely WebServiceTemplate and WebServiceGatewaySupport), which will sign all outgoing request messages accordingly (configuring the clients’ application context using Message Signing, leveraging the Keystore we’ve build within this episode).

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.

In other words, we trust all Client Certificates which are directly issued by the CA which itself is trusted by
the Service Endpoint (by providing its Certificate in the WebServices Truststore). This ‘Chain of Trust’ is going to be validated for every Client’s Certificate (by trying to build a so called Certificate Chain) whenever a Client is transmitting an appropriate Request Message to our WebService.

Certificate Authority … again

As we’ve already mentioned, the Certificate Authority is an ‘entity’, which issues Certificates for use by other parties. Within this role, it kind of acts like an autonomous, accepted party which all participants rely on. Although there are some commercial CAs (like VeriSign or Thawte Digital Certificates) we are free to come up with an own CA.
Let’s say, we want to create a custom CA, ‘representing’ the Host of our WebService, e.g. a CA which is commonly used by the Company which provides the WebService (so to say a Companies own CA). All potential Clients of that WebService have to ask to be signed by that Companies CA (we’ll get back to that task called ‘Certificate Signing Request’ in a further episode, when switching to the client side) in order to be recognized as an accredited Client who is allowed to access the Companies WebService.

OpenSSL

The following sections will give some step by step instructions on how to build your own CA using OpenSSL and importing the CAs Certificate into Spring-WS’ Truststore afterwards. In this regard, this episode is not too strongly related to Spring-WS but rather serve as a general approach on setting up a CA Key-Pair as a vital part of a custom Security infrastructure (sometimes called PKI – Public Key Infrastructure).

Before we start to create the CAs Key-Pair, we have to install OpenSSL (i will show how to do so for Windows, but the
steps are very similar on a unix based operating system). If not done yet, you first have to download and install OpenSSL (you might get a download of a precompiled win version via this site – you may also have to download the ‘Visual C++ 2008 Redistributables’ fom the same site should you detect and need to fix some problems under Windows …)

Certificate Factory

Next, we’ll build an appropriate folder structure where we’ll initially create and store our CAs private Key and the related Certificate (holding the associated public Key). We’ll extend that structure in some following sessions in order to store some more data like Certificate Signing Requests and the like.

I’ll use [CERTFACTORY_HOME] for an arbitrary folder of your choice as the root folder for our structure to build:

[CERTFACTORY_HOME]\ca
[CERTFACTORY_HOME]\ca\certs
[CERTFACTORY_HOME]\ca\crl
[CERTFACTORY_HOME]\ca\newcerts
[CERTFACTORY_HOME]\ca\private

Groundwork

Next, we have to place some files, which are needed by OpenSSL for properly creating a new CA:

• Create a new (empty) Textfile named index.txt under [CERTFACTORY_HOME]\ca
• Copy file serial from [OpenSSL_HOME]\bin\PEM\demoCA to [CERTFACTORY_HOME]\ca
• Copy OpenSSLs Master-Configuration-File openssl.cfg from [OPENSSL_HOME]\bin directly to [CERTFACTORY_HOME]

OpenSSL Configuration

The file openssl.cfg serves as OpenSSLs Master-Configuration. Here we have to configure OpenSSL in order to create a CA according to our whiches. For this purpose we’ll append a new configuration section that should be used whenever
we want to create a new CA, defining some defaults on where OpenSSL should place the generated Keys, which input data to use and some settings used for building the CAs certificate:

[ WEBSERVICE_CA ]

dir   = ./ca
certs   = $dir/certs
crl_dir   = $dir/crl
database  = $dir/index.txt
new_certs_dir  = $dir/newcerts
certificate  = $dir/cacert.pem
serial   = $dir/serial
crlnumber  = $dir/crlnumber
crl   = $dir/crl.pem
private_key  = $dir/private/cakey.pem
RANDFILE  = $dir/private/.rand
x509_extensions  = usr_cert
default_days  = 365
default_crl_days = 30
default_md  = sha1
preserve  = no
policy   = policy_anything

[ policy_anything ]
countryName  = optional
stateOrProvinceName = optional
localityName  = optional
organizationName = optional
organizationalUnitName = optional
commonName  = supplied
emailAddress  = optional

Note, that we named our new section WEBSERVICE_CA (of course you are free to come up with a name of your own).
The only thing left is to link to our customized configuration section as the configuration to use whenever a new CA should be created via this configuration file. This is done some lines above within section [ ca ], where we now will link to our section as the default configuration:

[ ca ]
default_ca = WEBSERVICE_CA

Look … it’s a … new CA

We’re now ready to create our custom CA. Make sure that [OpenSSL_HOME]\bin is on your path, so that you’re able to
invoke OpenSSL from everywhere from the command line. Now, switch to [CERTFACTORY_HOME]> (where we’ve placed our adapted configuration file) and start to build your own CA by typing the following command:

openssl req -x509 -newkey rsa:1024 -keyout ca\private\cakey.pem -out ca\cacert.pem -config openssl.cfg

You will be asked to give some relevant information related to the new CA (like some organisational data and a pass phrase for restricting access to the CAs Key-Pair – you’re asked for it again, at least when signing some Client Certificates with the CAs private Key at later time). After you’ve answered the questions appropriately, you’ll find the new CAs public Key (embedded within an accordant Certificate) under [CERTFACTORY_HOME]\ca\cacert.pem and the related private Key under [CERTFACTORY_HOME]\ca\private\cakey.pem.

Note, that the created Certificate is supplied in so called PEM-Format – in order to import it into a Java-Keystore, we have to convert it accordingly:

openssl x509 -outform DER -in ca\cacert.pem -out ca\cacert.cert

Now if you take a look at [CERTFACTORY_HOME]\ca, you’ll find the converted Certificate with the specified name cacert.cert.

Storing Trust

Now let’s come up with a new Java-Keystore which will serve as the before mentioned Truststore for Spring-WS (used by our Security Interceptor, or better by the injected KeyStoreHandler). We’ll use Java’s keytool for that purpose, so be sure to have [JAVA_HOME]\bin on your path.
Unfortunately, if using keytool you can’t create a new Keystore without also creating a new Key-Pair initially, which is automatically embedded within the new Keystore. As we don’t need this Key-Pair within our Truststore (we only need the CAs Certificate within), we’ll provide a Dummy which we’ll delete afterwards. It’s a good idea to initially place that Java-Keystore within our folder structure, so we might create another separate folder for storing our Truststore, like [CERTFACTORY_HOME]\truststore. After switching to that new folder, we’re ready to go:

keytool -genkey -alias dummy -keyalg RSA -keystore truststore.jks

Again you have to answer some questions, related to the new Keystore (like the password to securely refer to the Keystores content or getting permission to import some other Certificates), again some organisational data belonging to the initial Key-Pair and an associated individual passwort.
As you may have seen, the initial created Key-Pair is ‘labeled’ by an alias Name (the name to uniquely refer to that Key-Pair within the Keystore) called dummy, which we’ll use immediately to delete the dummy Key-Pair:

keytool -delete -alias dummy -keystore truststore.jks

Now we’re ready to import the (already converted) Certificate of our trusted CA:

keytool -import -file ..\ca\cacert.cert -alias trustedCA -keystore truststore.jks

Know the Score

We’re ready to go with our newly created Trustore (containing the Certificate of our also newly created custom CA) now. The only thing left is to place the Keystore accordingly, so that Spring-WS is able to refer to it at runtime within your deployed environment. If you remember the first episode, we already configured Spring-WS for that purpose:

<bean id="trustStore"
      class="org.springframework.ws.soap.security.support.KeyStoreFactoryBean">
<property name="location" value="/WEB-INF/MyTruststore.jks"/>
<property name="password" value="MyJavaKeyStorePassword"/>
</bean>

As you see, we have to make sure that our Keystore will be deployed under /WEB-INF using the Name MyTruststore.jks (Spring-WS needs to run within a Web-Container, as it’s front controller / message dispatcher is a Servlet). Of course you also have to keep the property password in sync with the password you’ve assigned to the Keystore (while we created it).

Summary

OpenSSL allows for the creation of new Certificate Authorities. We created a custom CA which will serve as the WebServices entity to trust. Now, all Client Certificates, which will arrive within incoming request messages have to be signed by that new CA. We said so by importing the CAs Certificate into a newly created Java-Keystore, which have to be provided as the Truststore, which is refered by Spring-WS’ Security Interceptor (more precisely, the KeyStoreHandler, which gets called by the Security Interceptor).

In the next episode, we’ll switch to the client side and see how to come up with a Client’s private Key and a related Certificate which gets signed by our CA. We’ll then implement a WebService-Client that will sign its request messages
in accordance to our claimed security policies (also using Spring-WS) and call our secured WebService.

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).

So far, the current configuration is causing our Security Interceptor to reject all request messages which doesn’t comply with that security constraints. Further, the transmitted client’s certificate is checked againt the Truststore in that it itself has to be signed (issued) by the CA we trust (by placing the trusted CAs certificate into the configured Truststore).
If an incoming request message meets all those requirements, it passes the Security Interception Process and can be received and consumed by an appropriate Message Endpoint (assumed that there are no other Endpoint Interceptors).

Authorisation

Now let’s suppose, that we need to get access to the client certificate for further processing (e.g. retrieving some of the certificate’s attributes). Let’s say that we need to retrieve the Common Name, which is registered within the client’s certificate for the sake of some custom authorisation: The Common Name should serve as input for deriving a set of rights which are permitted to the client (e.g. by associating the common name or a name pattern to a preconfigured set of rights). Since we are mainly interested on how to retrieve the client certificate, we will not dig into the authorisation process itself in greater detail (as it only serves as a valid example for motivating the retrievement of the client certificate).

Certificate Validation

To get access to the certificate, we have to register class SpringCertificateValidationCallbackHandler as another Callback Handler within our Security Interceptor:

...
<bean id="wsSecurityInterceptor"
      class="org.springframework.ws.soap.security.xwss.XwsSecurityInterceptor">
<property name="policyConfiguration" value="/WEB-INF/securityPolicy.xml"/>
<property name="callbackHandlers">
	<list>
      <ref bean="keyStoreHandler"/>
      <ref bean="certificateValidationHandler" />
    </list>
  </property>
</bean>

<bean id="certificateValidationHandler"
      class="org.springframework.ws.soap.security.xwss.callback.SpringCertificateValidationCallbackHandler">
  ...
</bean>

As you can see, we place the new bean certificateValidationHandler right after the already registered KeyStoreCallbackHandler (which is checking the Signer of the client certificate against the trusted CA in our Truststore). Note, that this order is intented and of relevance – in this case, we will first check the certificate Signer against the CA in our Truststore (by building an accordant Certificate Chain). Only if this check is successful, our certificateValidationHandler will be called afterwards.

AuthenticationManager

SpringCertificateValidationCallbackHandler itself is only a delegator in our case – it will call a given AuthenticationManager if configured properly. For the purpose of retrieving the clients certificate, we’ll inject a custom implementation of AuthenticationManager:

...
<bean id="springCertificateHandler"
      class="org.springframework.ws.soap.security.xwss.callback.SpringCertificateValidationCallbackHandler">
<property name="authenticationManager">
    <bean class="com.mgi.authentication.SimpleAuthenticationManager" />
  </property>
</bean>

A valid AuthenticationManager have to implement a correspondend Interface. In this role, he gets called and passed an instance of type Authentication. In case of certificate Authentication, the provided credentials are of type X509Certificate - this is exactly the type of information we are looking for:

import java.security.cert.X509Certificate;
import org.springframework.security.Authentication;
import org.springframework.security.AuthenticationException;
import org.springframework.security.AuthenticationManager;

public class SimpleAuthenticationManager implements AuthenticationManager {

  public Authentication authenticate( Authentication authentication ) throws AuthenticationException {

    Object credentials = authentication.getCredentials();

    if( X509Certificate.class.isAssignableFrom( credentials.getClass() ) ){

      X509Certificate certificate = (X509Certificate) credentials;

      // do some custom authentication here
      setupRightsBasedOn( certificate );
    }

    authentication.setAuthenticated( true );

    return authentication;
  }
}

As you can see, we cast the given credentials (which could be any kind of information that prove the principal is correct, like a password in some other cases) to an instance of X509Certificate, do some authorization based on the given certificate and finally successfully complete authentication (you could of course come up with your own authentification logic, which might not always authenticate successfully in some cases).

X509Certificate

As we mentioned before, we might determine a set of rights based on the Common Name or any other attribute of the given certificate. In order to do this, we simply rely on the given API of java.security.cert.X509Certificate. Further, we might want to ‘publish’ the resulting set of rights, so that they can be retrieved by subsequent called business logic. One solution might be to instantiate a (maybe custom) SecurityContext (maybe using a ThreadLocal underneath, with all the given advantages and risks) which will accept the determined set of rights and provide them to all subsequent called business logic within the current Thread (since AuthenticationManager offers no way of directly returning a custom set of data):

...
private void setupRightsBasedOn( X509Certificate certificate ){

  X500Principal subjectX500Principal = certificate.getSubjectX500Principal();

  Rights rights = rightsFor( commonNameFrom( subjectX500Principal.getName() ) );

  SecurityContext.initContext( rights );
}

private String commonNameFrom( String subjectName ) {
  return
    StringUtils.extractNesting(
      subjectName, "CN=", ",",
      EXCLUDE_OPEN_BRACE_IN_NESTING,
      EXCLUDE_CLOSING_BRACE_IN_NESTING );
}

I’ve omitted the logic on how to retrieve the accordant set of rights for a given Common Name, since this is highly dependent by the given needs and infrastructure of the appclication. You might want to retrieve a database (since we are using Spring-WS you are free to inject any type of spring bean (e.g. a service or a DAO bean) to your custom implementation of AuthenticationManager - remember that the parent context of Spring-WS’ application context is automatically the given web application context) or calculate the rights by any meaningful logic.
You can clearly see, that we only rely on the given API of X509Certificate. Of course you are free to retrieve an arbitrary attribute from within the certificate.

Summary

Retrieving the client’s certificate is more or less a matter of providing a custom AuthenticationManager which itself gets called by a SpringCertificateValidationCallbackHandler (which is registered as another Callback Handler within our Security Interceptor). For having configured Certificate Authentification by the given Security policies, we’ll receive credentials in form of a X509Certificate. Retrieving some attributes from that certificate now is just a matter of using the provided API of X509Certificate in a suitable way – and that’s it.

In the next episode, we’ll take a closer look on how to set up the servers security infrastructure, including some step by step instructions on how to use OpenSSL and Keytool in order to create a CA Key-pair and importing the related CAs certificate into our Truststore. We’ll then move on to the client side in some further episode and will set up the client’s security infrastructure and of course come up with an implementation of a WebService-Client that will sign its request messages accordingly (also using Spring-WS) and call our secured WebService.