[SWS-549] integrate AbstractWsSecurityInterceptor with EndpointExceptionResolver Created: 10/Aug/09  Updated: 04/May/12  Resolved: 16/Aug/09

Status: Closed
Project: Spring Web Services
Component/s: Security
Affects Version/s: 1.5.7
Fix Version/s: 1.5.8

Type: New Feature Priority: Major
Reporter: Nicholas Blair Assignee: Arjen Poutsma
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 0.05h
Original Estimate: Not Specified

Attachments: Text File interceptor-exceptionResolver.patch.txt    

 Description   

AbstractWsSecurityInterceptor is not currently integrated with Spring Web Services' EndpointExceptionResolver.

If an exception occurs during validation, AbstractWsSecurityInterceptor's own handleValidationException generates a SoapFault on it's own and populates the message with the input parameter ex's getMessage result.

A common cause of this behavior would be integration with a ClientUserDetailsService; in this example the loadUserByUsername method throws a UsernameNotFoundException.

This UsernameNotFoundException gets wrapped by a org.apache.ws.security.WSSecurityException (twice over), which in turn gets caught and turned into a org.springframework.ws.soap.security.wss4j.Wss4jSecurityValidationException, which is caught and passed into the handleValidationException method.

It would be useful to let the developer customize the SoapFault when these validation exceptions occur.
The obvious approach (to me at least ) is to delegate to an EndpointExceptionResolver, particularly since this resolver is already likely being used within the Spring Web Services application.

I have a proposed patch that adds an EndpointExceptionResolver as a private field (with a public setter) and a re-factored handleValidationException method that allows the endpointExceptionResolver to step in if present.

This allows the developer to add their own custom message to the soap fault instead of (the current faultstring when these validation exceptions occur):

The security token could not be authenticated or authorized; nested exception is:
org.apache.ws.security.WSSecurityException: The security token could not be authenticated or authorized; nested exception is org.apache.ws.security.WSSecurityException: The security token could not be authenticated or authorized; nested exception is:
org.apache.ws.security.WSSecurityException: The security token could not be authenticated or authorized



 Comments   
Comment by Nicholas Blair [ 10/Aug/09 ]

Attached proposed patch to integrate EndpointExceptionResolver with AbstractWsSecurityInterceptor.

Comment by Nicholas Blair [ 10/Aug/09 ]

I should mention the patch is based off revision 1433 (trunk retrieved today - Mon Aug 10).

Comment by Arjen Poutsma [ 16/Aug/09 ]

Done. Thanks for the patch!

Comment by Paul Nyheim [ 23/Sep/10 ]

Instead of introducing the EndpointExceptionResolver in this Interceptor, would it not be better to just let the exception flow up to the MessageDispatcher, where the resolvers already are configured (with sensible defaults)

And as this is not documented anywhere unlike the exception resolving in the MessageDispatcher (http://static.springsource.org/spring-ws/sites/1.5/reference/html/server.html#server-endpoint-exception-resolver), it is too easy to miss out on or forget this extra configuration step.

In my opinion this could be done for both the client and endpoint handleRequest/handleResponse methods by just removing the catch clauses.
I would be happy to contribute a patch for this if needed.

Regards,
Paul Nyheim

Comment by Arjen Poutsma [ 04/May/12 ]

Closing old issues

Generated at Tue Dec 12 10:18:48 UTC 2017 using JIRA 6.4.14#64029-sha1:ae256fe0fbb912241490ff1cecfb323ea0905ca5.