When I discussed dynamic API endpoint resolution in my previous post, I mentioned that some services might require security headers. This makes creating a generic service a tad bit more complicated but there are ways around it. In this post I’ll talk about how to add a Web Service Security (WSSE) header, a custom (vendor specific) header or both to an outgoing web service request.
Once again, I’ll approach it from the angle of a “can’t be bothered” developer who doesn’t want to open up a new development track just because one service provider decided to define their own header.
Adding Headers to Outbound SOAP Requests
Just to jog your memory, our final SOAP outbound gateway looked something like this:
|
1 |
<!--—Outbound Gateway ----> |
This caters for a simple implementation though: one which doesn’t require any headers at all. However, adding headers isn’t that difficult either. You just need to throw an interceptor into the mix like so:
|
1 |
Let’s look at the implementation of the headers more closely, starting with WSSE headers.
Adding WSSE Headers
Spring Integration makes it extremely easy to add WSSE headers to outgoing SOAP requests with their Wss4jSecurityInterceptor. The simplest implementation is to define the bean in the Spring context (it doesn’t necessarily have to be in the same file as the SOAP outbound flow) and set the necessary properties. A simple example requiring only a username and password is:
|
1 |
(See this excellent post by Mark Serrano if you want a more in – depth description of the Wss4jSecurityInterceptor).
Forgetting about dynamic endpoints for the moment, this is really all you need. Your credentials could be entered directly in the bean definition (not advised) or placed in a properties file (still not advised…plain text!). In which case, your outbound gateway would look like so:
|
1 |
However, we have chosen a bolder endeavour, “all for one and one for all”! So things get a bit more complicated here.
The first change I want to make is to add an ID to let us know which set of credentials we need to fetch. We’ll call this property “security_id” and pass it to the flow as an HTTP header as shown in the previous post:
|
1 |
Or, if you prefer, as a request parameter
|
1 |
Now, this is where I used a bit of a workaround. The SOAP message is sent to the interceptor wrapped in a message context object. This object has a properties map but I couldn’t for the life of me figure out how to set properties before writing this post. In case you’ve already figured out how to set them, I’ll show you how to use that method instead (although if you can figure out how to set it you probably don’t need my help on the easier part :P). In my case, I appended the identifier to my SOAP action like so:
|
1 |
Now we know which credentials to load, let’s dive into the interceptor!
Custom WSSE Interceptor
Seeing how much effort the Spring team put into creating their Wss4jSecurityInterceptor (and how lazy I am of course), I couldn’t possibly bring myself to shun their work and create my own from scratch. So, as the object oriented programmer I am, I inherited ;). My class is shown below:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
@Component(value="wss4jDynamicInterceptor") public class Wss4jDynamicClientInterceptor extends Wss4jSecurityInterceptor { @Override protected RequestData initializeRequestData(MessageContext messageContext) { //if you were able to set the messageContext property, you just retrieve the security_id like so: String securityId = messageContext.getProperty("security_id"); //if not, you’ll have to hack away at the SOAP action like I did! SoapMessage message = (SoapMessage)messageContext.getRequest(); String action = message.getSoapAction(); //Remember I used “!” as a separator String[] actionParts = action.split("!"); //If no id was set, then we’re wasting our time. Revert to Spring’s implementation if(actionParts.length < 2) return super.initializeRequestData(messageContext); SomeSecurityObject security = someSecurityService.getById(securityId); if(security == null)//Another waste of time return super.initializeRequestData(messageContext); //Now we have the security details. Let’s set them this.setSecurementActions(security.getActions); this.setSecurementUsername(security.getUsername); this.setSecurementPassword(security.getPassword); //Override any other property you want and let Spring do the rest return super.initializeRequestData(messageContext); } } |
The key here is just to make sure the necessary properties are set BEFORE calling Wss4jSecurityInterceptor’s initializeRequestData method. That way, you can inject your credentials (and decrypt them if they were stored encrypted in a database for example) and then let Spring handle the work of actually creating the header.
So that’s it for adding a WSSE header…but how about a custom one?
Adding a Custom SOAP Header
The process here is generally the same as above. Make sure you pass any data you would need in order to determine which exact header you need to generate. Then set the interceptor to your custom header generator class:
|
1 |
And create your CustomHeaderInjector class (this class will implement the org.springframework.ws.client.support.interceptor.ClientInterceptor interface but the only method you’ll really need to implement is handleRequest):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
@Component(value="customHeaderInjector") public class CustomHeaderInjecttor implements ClientInterceptor { @Override public boolean handleRequest(MessageContext messageContext) throws WebServiceClientException { SoapMessage message = (SoapMessage)messageContext.getRequest(); //Retrieve the header identifier from messageContext property or SOAP action as shown in the previous section String header_id; //Load the header XML from a file or database. You can also use a templating engine such as Velocity to construct the header based on other parameters String customHeaderXML = someService.getHeaderXML(); //Retrieve the current header from the message SoapHeader header = message.getSoapHeader(); StringSource headerSource = new StringSource(customHeaderXML); //Get an instance of javax.xml.transform.Transformer Transformer transformer = TransformerFactory.newInstance().newTransformer(); //Use the transformer to merge your custom header into the SOAP header transformer.transform(headerSource, header.getResult()); return true; } //Just return default values for the remaining methods @Override public boolean handleResponse(MessageContext messageContext) throws WebServiceClientException { // TODO Auto-generated method stub return false; } @Override public boolean handleFault(MessageContext messageContext) throws WebServiceClientException { // TODO Auto-generated method stub return false; } @Override public void afterCompletion(MessageContext messageContext, Exception ex) throws WebServiceClientException { // TODO Auto-generated method stub } } |
And that’s it for adding a custom header!
Two Headers Are Better Than One?
The final scenario I want to discuss is where the client requires BOTH their own custom header as well as a WSSE header. Don’t snort at me now, this is an actual use case I ran into! Thankfully, there’s a simple way of achieving this. Remember the “interceptor” attribute of the outbound gateway that took a bean reference? Well, you can use the “interceptors” attribute instead and pass it a list. Here’s how it’ll look:
|
1 |
… … … |
Note that (in my implementation at least) the order of the interceptors is preserved. This is important to me because I’m not sure whether or not my custom header interceptor would overwrite the WSSE header if it was executed after. Spring’s WSS4J interceptor however maintains my custom header while adding its own so everything is just peachy!
Summary
That’s all for today. I discussed how to add WSSE headers with dynamic credential injection and custom SOAP headers to outbound SOAP requests. We also looked at a combination of both. Hopefully I’m not the only one crazy enough to do this and this post will actually be of help to someone else. Either way, I’m out!