PayloadValidatingInterceptor errors not clearing SecurityContextHolder [SWS-708]

[gregturn]

Harshi opened SWS-708 and commented

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>

---

Affects: 2.0 GA

Reference URL: http://forum.springsource.org/showthread.php?108650-PayloadValidatingInterceptor-error-not-clearing-SecurityContextHolder&p=360306

Attachments:

• MyXwsSecurityInterceptor.java (3.80 kB)

Referenced from: commits 078c390, 95ac668

Backported to: 1.5.10

[gregturn]

Arjen Poutsma commented

Added formatting

[gregturn]

Arjen Poutsma commented

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.

[gregturn]

Arjen Poutsma commented

Resolving as Cannot Reproduce for now.

[gregturn]

Harshi commented

Hi Arjen,
Please find the attached MyXwsSecurity Interceptor.

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

Thanks
Harshi

[gregturn]

Harshi commented

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

[gregturn]

Arjen Poutsma commented

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

[gregturn]

Arjen Poutsma commented

Reopening

[gregturn]

Arjen Poutsma commented

Fixed in trunk.

[gregturn]

Arjen Poutsma commented

Fixed in 1.5 branch.

[gregturn]

Arjen Poutsma commented

Closing old issues