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

PayloadValidatingInterceptor errors not clearing SecurityContextHolder

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.0 GA
    • Fix Version/s: 1.5.10, 2.0.2
    • Component/s: Security
    • Labels:
      None

      Description

      I have Validtion Interecptor first and SecurityInterceptor Later in the sequence.

      When response has validation errors some how SecurityConextHolder has old previous authenticated user Information.

      When there are NO response validation errors SecurityContextHolder is clean.

      I am guessing that when PayloadValidatingInterceptor has errors which is causing not to clean up thread local ?

      Once the request is complete all thread context should be nulled out and give back to pool. It does that there are no reponse validation errors but doesn't do that when there are response validation errors. I tried to debug the code , all the way to MessageDispatcherServlet but didn't find any clue.

      Here is my configuration

      <sws:interceptors>
       
       
              <bean id="wsSecurityInterceptor" class="com.mycompancy.MyXwsSecurityInterceptor">
                  
                  <property name="secureResponse" value="false"/>
                  <property name="policyConfiguration"
                            value="/WEB-INF/spring/securityPolicy.xml"/>
                  <property name="callbackHandlers">
                      <list>
                          <bean class="com.mycompancy.security.MySpringDigestPasswordValidationCallbackHandler">
                              <property name="userDetailsService" ref="securityService"/>
                              <property name="userCache" ref="userCache"/>
                          </bean>
                      </list>
                  </property>
              </bean>
       
       
              <bean class="com.mycompancy.util.MyLoggingInterceptor"/>
              <bean class="org.springframework.ws.soap.server.endpoint.interceptor.PayloadValidatingInterceptor"
                    p:validateRequest="true" p:validateResponse="true">
                  <property name="schemas">
                      <list>
                          <value>/WEB-INF/schema/customer.xsd</value>
                          <value>/WEB-INF/schema/users.xsd</value>
                          <value>/WEB-INF/schema/userDetails.xsd</value>
                      </list>
                  </property>
              </bean>
          </sws:interceptors>

        Activity

        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Added formatting

        Show
        arjen.poutsma Arjen Poutsma added a comment - Added formatting
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Note that the interceptor configuration you pasted is different than the one described: in the description you write that the validating interceptor comes before the security interceptor, while in the config they are in opposite order. I assume that the config is correct.

        Besides this minor issue, I can't seem to reproduce this with the standard org.springframework.ws.soap.security.xwss.XwsSecurityInterceptor. This is what should happen (and what does happen with the standard interceptors):

        1. New request comes in
        2. Security interceptor sets up a security context based on the credentials in the request
        3. Logging interceptor logs the request
        4. Validating interceptor tries to validate the request, and finds it invalid. This result in a SOAP fault as a response.
        5. Logging interceptor does not log the response, as it's a fault (see org.springframework.ws.server.endpoint.AbstractLoggingInterceptor#handleFault)
        6. Security interceptor cleans up the security context, by calling cleanup. See org.springframework.ws.soap.security.AbstractWsSecurityInterceptor#handleFault(MessageContext messageContext, Object endpoint)

        As I can't reproduce this with the standard interceptors, my guess is that you are overriding handleFault() in your MyXwsSecurityInterceptor, and do not call cleanUp() in that method. If you attach the MyXwsSecurityInterceptor code, I can verify this.

        Show
        arjen.poutsma Arjen Poutsma added a comment - Note that the interceptor configuration you pasted is different than the one described: in the description you write that the validating interceptor comes before the security interceptor, while in the config they are in opposite order. I assume that the config is correct. Besides this minor issue, I can't seem to reproduce this with the standard org.springframework.ws.soap.security.xwss.XwsSecurityInterceptor. This is what should happen (and what does happen with the standard interceptors): New request comes in Security interceptor sets up a security context based on the credentials in the request Logging interceptor logs the request Validating interceptor tries to validate the request, and finds it invalid. This result in a SOAP fault as a response. Logging interceptor does not log the response, as it's a fault (see org.springframework.ws.server.endpoint.AbstractLoggingInterceptor#handleFault) Security interceptor cleans up the security context, by calling cleanup. See org.springframework.ws.soap.security.AbstractWsSecurityInterceptor#handleFault(MessageContext messageContext, Object endpoint) As I can't reproduce this with the standard interceptors, my guess is that you are overriding handleFault() in your MyXwsSecurityInterceptor, and do not call cleanUp() in that method. If you attach the MyXwsSecurityInterceptor code, I can verify this.
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Resolving as Cannot Reproduce for now.

        Show
        arjen.poutsma Arjen Poutsma added a comment - Resolving as Cannot Reproduce for now.
        Hide
        harshi Harshi added a comment -

        Hi Arjen,
        Please find the attached MyXwsSecurity Interceptor.

        Also , the issue is with when response has validation errors not request.

        Thanks
        Harshi

        Show
        harshi Harshi added a comment - Hi Arjen, Please find the attached MyXwsSecurity Interceptor. Also , the issue is with when response has validation errors not request. Thanks Harshi
        Hide
        harshi Harshi added a comment -

        Hi Arjen,
        I have attached MyXwsSecurityInterceptor . The issue is with when response has validation errors not request.

        If you want I can create a simple ws for this. when I Debug the code it didn't come to HadnldeFault method.

        Thannks
        Harshi

        Show
        harshi Harshi added a comment - Hi Arjen, I have attached MyXwsSecurityInterceptor . The issue is with when response has validation errors not request. If you want I can create a simple ws for this. when I Debug the code it didn't come to HadnldeFault method. Thannks Harshi
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Hi Harshi,

        Thanks for posting the additional information. You have indeed spotted a potential security issue in Spring Web Services. That said, it is quite easy to work around, by swapping the security and validation interceptor, so that the validation interceptor is the first one in the sequence. This obviously won't work when you need encryption of the payload, as the schema probably does not conform to the encrypted data. Alternatively, you can disable response validation entirely. Or you could override the PayloadValidatingInterceptor to make sure it doesn't return false for handleResponseValidationErrors(). All of these suggestions will work around the issue at hand.

        We will fix this issue in the next minor release, but I do think it's a corner case. After all, this issue only occurs when the response payload does not validate against you own schema, and generally I believe that sending an invalid response is a bug that should be fixed. After all, if you don't conform to your own schema, you can't really expect your clients to do so either. As such, the response validation is mostly meant to be used during the development stages of your project, making sure that all your response messages are valid. When going into production, I generally recommend to disable response validation, as it slows things down considerably (i.e. schema validation is slow).

        Show
        arjen.poutsma Arjen Poutsma added a comment - Hi Harshi, Thanks for posting the additional information. You have indeed spotted a potential security issue in Spring Web Services. That said, it is quite easy to work around, by swapping the security and validation interceptor, so that the validation interceptor is the first one in the sequence. This obviously won't work when you need encryption of the payload, as the schema probably does not conform to the encrypted data. Alternatively, you can disable response validation entirely. Or you could override the PayloadValidatingInterceptor to make sure it doesn't return false for handleResponseValidationErrors(). All of these suggestions will work around the issue at hand. We will fix this issue in the next minor release, but I do think it's a corner case. After all, this issue only occurs when the response payload does not validate against you own schema, and generally I believe that sending an invalid response is a bug that should be fixed. After all, if you don't conform to your own schema, you can't really expect your clients to do so either. As such, the response validation is mostly meant to be used during the development stages of your project, making sure that all your response messages are valid. When going into production, I generally recommend to disable response validation, as it slows things down considerably (i.e. schema validation is slow).
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Reopening

        Show
        arjen.poutsma Arjen Poutsma added a comment - Reopening
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Fixed in trunk.

        Show
        arjen.poutsma Arjen Poutsma added a comment - Fixed in trunk.
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Fixed in 1.5 branch.

        Show
        arjen.poutsma Arjen Poutsma added a comment - Fixed in 1.5 branch.
        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:
            harshi Harshi
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: