[SWS-193] XwsSecurityInterceptor : funtionality for skipping the validate of a SOAP message when there are no WSSE headers in SOAP envelope. Created: 12/Sep/07  Updated: 04/May/12  Resolved: 29/Apr/10

Status: Closed
Project: Spring Web Services
Component/s: Security
Affects Version/s: 1.0
Fix Version/s: 2.0 M2

Type: New Feature Priority: Minor
Reporter: Albert van 't Hart Assignee: Tareq Abedrabbo
Resolution: Complete Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


Is it possible to skip the validateMessage(SoapMessage soapMessage) when a SOAP message has no WSSE headers?
I'm building a web service which have to support multiple authentication mechanisms, such as X509 client certificates, BASIC authentication.
All mechanisms are implemented using Acegi Security.

As workaround i have built an endpoint interceptor that will look for a WSSE security header in the SOAP envelope and decides to continue or stops processing.

Comment by Arjen Poutsma [ 12/Sep/07 ]

You can achieve this by creating two separate endpoint mappings: one with the XwsSecurityInterceptor which require WS-Security, and one without it. The airline sample does this. The trick is to have some differentiator between the WS-Security endpoints and the BASIC auth endpoints. Perhaps a different URL?

Skipping the WS-Security headers when they are not present basically makes the headers optional, and that could result in a security leak.

Comment by Albert van 't Hart [ 12/Sep/07 ]

The airline sample uses different endpoint mapping (marshalling endpoint, payload endpoint and annotation endpoint).
I have one endpoint; PayloadRootAnnotationMethodEndpointMapping using JAXB2 Marshalling.

By configuring two different URLs, results in two MessageDispatchers servlets for each instance a configuration file.

There by we now have created a fallback mechanism on one URL, because we have a lot of different clients (users).
Some users wants to do SOAP authentication (WS-Security) and other users can only do BASIC authentication.

We use the MethodSecurityInterceptor from Acegi to handle the authentication and authorization.
So when there is no (authenticated) authentication object in the security context, this results in an AuthenticationException wich maps to a SOAP fault. When configuring the application in this way there can not be a security leak (i think).

I do not want to change the default behaviour of the XwsSecurityInterceptor, but is it possible to configure the interceptor to skip the validating?
The AcegiPlainTextPasswordValidationCallbackHandler can also be configured to ignore authentication failures, this is also a possible security leak then?

Well let me know what you think?

Comment by Thomas Champagne [ 14/Apr/10 ]


I have a similar problem and I don't understant why this feature has not been implemented for 2 years.

For me, I would like to implement an endpoint with an optional authentication.
When there isn't an authentication, the endpoint answers public data of an object.
But When there is an authentication, the endpoint answers public data with private data of an object.

For example : With a method getBooks that return a list of books. When there is an authentification, the method indicates whether the user is a fan of the book.
With no authentication the response is :

    <title>The Tragedy of Hamlet</title>
    <title>Little Red Riding Hood</title>

With authentification, the response is :

    <title>The Tragedy of Hamlet</title>
    <title>Little Red Riding Hood</title>

Tell me if you are agree with this idea.

Comment by Tareq Abedrabbo [ 28/Apr/10 ]

I've just added a skipValidationIfNoHeaderPresent property to AbstractWsSecurityInterceptor, which defaults to false, but when set to true skips validation if no WS-Security header is present.

Comment by Thomas Champagne [ 29/Apr/10 ]

I tested your code and it's nice for me.
Thanks for your fix.

Comment by Tareq Abedrabbo [ 29/Apr/10 ]

Thank you for the feedback.

Comment by Arjen Poutsma [ 04/May/12 ]

Closing old issues

Generated at Sat Nov 17 07:14:01 UTC 2018 using JIRA 7.9.2#79002-sha1:3bb15b68ecd99a30eb364c4c1a393359bcad6278.