Uploaded image for project: 'Spring Web Services'
  1. Spring Web Services
  2. SWS-549

integrate AbstractWsSecurityInterceptor with EndpointExceptionResolver

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.7
    • Fix Version/s: 1.5.8
    • Component/s: Security
    • Labels:
      None

      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

        Activity

        Hide
        nblair Nicholas Blair added a comment -

        Attached proposed patch to integrate EndpointExceptionResolver with AbstractWsSecurityInterceptor.

        Show
        nblair Nicholas Blair added a comment - Attached proposed patch to integrate EndpointExceptionResolver with AbstractWsSecurityInterceptor.
        Hide
        nblair Nicholas Blair added a comment -

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

        Show
        nblair Nicholas Blair added a comment - I should mention the patch is based off revision 1433 (trunk retrieved today - Mon Aug 10).
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Done. Thanks for the patch!

        Show
        arjen.poutsma Arjen Poutsma added a comment - Done. Thanks for the patch!
        Hide
        hurragutt Paul Nyheim added a comment -

        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

        Show
        hurragutt Paul Nyheim added a comment - 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
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Closing old issues

        Show
        arjen.poutsma Arjen Poutsma added a comment - Closing old issues

          People

          • Assignee:
            arjen.poutsma Arjen Poutsma
            Reporter:
            nblair Nicholas Blair
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0d
              0d
              Logged:
              Time Spent - 0.05h
              0.05h