Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
PayloadValidatingInterceptor errors not clearing SecurityContextHolder [SWS-708] #802
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
Backported to: 1.5.10
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):
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.
If you want I can create a simple ws for this. when I Debug the code it didn't come to HadnldeFault method.
Arjen Poutsma commented
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).