Spring Web Services
  1. Spring Web Services
  2. SWS-708

PayloadValidatingInterceptor errors not clearing SecurityContextHolder

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major 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 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 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 added a comment -

        Reopening

        Show
        Arjen Poutsma added a comment - Reopening
        Hide
        Arjen Poutsma added a comment -

        Fixed in trunk.

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

        Fixed in 1.5 branch.

        Show
        Arjen Poutsma added a comment - Fixed in 1.5 branch.
        Hide
        Arjen Poutsma added a comment -

        Closing old issues

        Show
        Arjen Poutsma added a comment - Closing old issues

          People

          • Assignee:
            Arjen Poutsma
            Reporter:
            Harshi
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: