[SWS-991] MessageSender incompatibility in SSL Mutual Auth and Basic Auth scenario Created: 28/Jul/17 Updated: 01/Nov/17
|Project:||Spring Web Services|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
Java 8 (OS irrelevant)
We are integrating with a client that provides WSDL for their services. Their setup involves:
Using WS to generate and create client, we configure the WebServiceTemplate with the relevant jaxb2 marshaller/unmarshaller and proceed to configure message senders.
Two senders were configured:
It seems that using the webServiceTemplate.setMessageSenders() call to set the array of message senders, the combination of the two produces weird results:
We believe that these two message senders are incompatible. Whichever goes last overrides (or uses different URL factories or something) and makes the first configuration to disappear. This is not evident in documentation anywhere and for our case it took us more than 2 days debugging with the client (initially thinking it was an SSL configuration issue on their side) to understand that this was an incompatibility.
In our scenario of SSL Mutual Auth and Basic Auth, we proceeded to add a custom override of the prepareConnection() call of the HttpsUrlConnectionMessageSender as below:
By doing that, we used only the SSL configuration MessageSender which successfully passed the client Mutual Authentication and also configured the header for the Basic Authentication.
PS: Flagging as major due to lack of documentation and complexity of the debugging involved.
|Comment by Greg Turnquist [ 01/Nov/17 ]|
You aren't really supposed to configure two MessageSenders targeting one message. The purpose is to have different MessageSenders for different message types. Hence the supports() call. In other words, they don't act like layered filters, one feeding the next. Instead, a given MessageSender attempts to create a connection and then send the message.
The two strategies, perhaps as you've read in the reference docs, for sending messages over HTTP use either build in Java HttpUrlConnection or the more sophisticated one, using Apache HttpClient. For complex stuff, which your use case clearly is in, hints at using Apache HttpClient. This is where you get to configure everything in the HttpClient and then inject it into HttpComponentsMessageSender via constructor injection (preferred) or setter injection.
To use HttpClient, there are gobs of StackOverflow articles showing many permutations of configuration. The trick is the fact that mutual TLS is a relatively obscure configuration, so I understand how difficult it can be to find such an article and then mix it with BASIC authorization headers.
Given the fact that you found a suitable workaround by merely extending HttpsUrlConnectionMessageSender and tweaking the HttpURLConnection object by adding a single header, I'm inclined to agree that this was the best solution for your use case. Who wants to perform complex configurations against Apache HttpClient if this works?
What I am trying to investigate is whether this warrants augmenting Spring WS code, or if documenting this in the reference documents is really the best approach?
So documenting the ability to extend and modify may be of the most benefit to all users vs. something actually added to the framework's code base.
|Comment by Thanos Angelatos [ 01/Nov/17 ]|
thanks for taking the time to prepare such a thorough analysis. I will agree that this may be an "obscure" configuration that was probably not very requested in the past, but in recent times we've been faced with such configurations more than once in the last 2-3 months. Nevertheless, I would like to focus to your last sentence - and documentation is always the first place we go when we have such doubts. So +1 there.
On the other hand, I find really confusing your 1st sentence - If I'm not supposed to configure two message senders, why there is a webServiceTemplate.setMessageSenders(...) API call? What is it for? It directly implies a chain of MessageSenders - which was then quite an obvious path leading down the rabbit hole for us.
Maybe a rethinking of the API is necessary. Or much more documentation, or both...
|Comment by Greg Turnquist [ 01/Nov/17 ]|
The concept of setMessageSenders() is to support either a different sender for each type, or a different sender per transport. Imagine an array of senders, one for HTTP, one for JMS, one for email. (SOAP has this nice transport neutrality people often overlook).
The concept is also, one message sender for Order objects, a different message sender for ExpiredUser-based messages.
I can see how that API is confusing since it's not the same as an array of nested filters.