[SWS-708] PayloadValidatingInterceptor errors not clearing SecurityContextHolder Created: 09/May/11  Updated: 04/May/12  Resolved: 18/May/11

Status: Closed
Project: Spring Web Services
Component/s: Security
Affects Version/s: 2.0 GA
Fix Version/s: 1.5.10, 2.0.2

Type: Bug Priority: Major
Reporter: Harshi Assignee: Arjen Poutsma
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File MyXwsSecurityInterceptor.java    
Reference URL: http://forum.springsource.org/showthread.php?108650-PayloadValidatingInterceptor-error-not-clearing-SecurityContextHolder&p=360306

 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>



 Comments   
Comment by Arjen Poutsma [ 10/May/11 ]

Added formatting

Comment by Arjen Poutsma [ 10/May/11 ]

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.

Comment by Arjen Poutsma [ 10/May/11 ]

Resolving as Cannot Reproduce for now.

Comment by Harshi [ 13/May/11 ]

Hi Arjen,
Please find the attached MyXwsSecurity Interceptor.

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

Thanks
Harshi

Comment by Harshi [ 13/May/11 ]

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

Comment by Arjen Poutsma [ 18/May/11 ]

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).

Comment by Arjen Poutsma [ 18/May/11 ]

Reopening

Comment by Arjen Poutsma [ 18/May/11 ]

Fixed in trunk.

Comment by Arjen Poutsma [ 18/May/11 ]

Fixed in 1.5 branch.

Comment by Arjen Poutsma [ 04/May/12 ]

Closing old issues

Generated at Mon Dec 11 18:57:29 UTC 2017 using JIRA 6.4.14#64029-sha1:ae256fe0fbb912241490ff1cecfb323ea0905ca5.