Spring security with multiple custom filters and roles

Question

I am using Spring security with two filters: - One filter for x.509 authentication for client certificates. All his filter does is extracts the username from certificate into principle. - One filter to do header based authentication. The header should have username and roles. In this filter I check to make sure that there is a principal already present in the security context. If present I make sure that it matches whats in the headers. Then I extract the roles from the header and set the granted authorities. I have a url pattern that I want to be made accessible to roles - 'ROLE_USER'

Now here is the problem. The request only hits the first filter(X.509), the role is missing in this header obviously and access is denied by spring security.

I cannot switch the order of the filters because if I do then X.509 filter provided by spring simply sees that principal is already present and does nothing making it useless.

Is there any way for the role check to be deferred until all filters are processed? Or any other way to achieve what I am trying to do.

Here is my spring security config:

<security:http auto-config="true" entry-point-ref="customEntryPoint">
    <security:intercept-url pattern="/user/**"  access="ROLE_USER"/>
    <security:custom-filter after="EXCEPTION_TRANSLATION_FILTER" ref="x509Filter"  />
    <security:custom-filter after="FILTER_SECURITY_INTERCEPTOR" ref="headerFilter"/>
</security:http>

where the x509Filter is standard spring security filter configured as:

<beans:bean id="x509PrincipalExtractor" class="org.springframework.security.web.authentication.preauth.x509.SubjectDnX509PrincipalExtractor">
    <beans:property name="subjectDnRegex" value="CN=(.*?),"/>
</beans:bean>

I can provide scrubbed up customHeaderFilter if needed but at this point the control never reaches the filter so it is inconsequential as to what happens in it.

Any help/guidance would be greatly appreciated.

Why you do not use [x509](http://static.springsource.org/spring-security/site/docs/3.2.x/reference/springsecurity-single.html#d0e8028) tag for turning on certificate based authentification? — Maksym Demidas, Mar 18 '13 at 16:57
I don't remember exactly but I was having trouble with ordering of the filters and being able to handle exceptions while using the x509 with my custom filter. Same reason that led me to adding the custom 'after' position. Even if I did, would that make a difference though in this situation? — MickJ, Mar 18 '13 at 17:14
I am not sure that this can fix the situation. What looks strange for me are positions for your filters. From the official documentation it looks like right place for preauth filter is PRE_AUTH_FILTER (and X509_FILTER for x509). Have you tried injecting x509 at X509_FILTER position and custom one on PRE_AUTH_FILTER? — Maksym Demidas, Mar 18 '13 at 17:52
Thanks for the pointer. In some ways it was about the filters not being in their usual place. The answer was staring at my face. 'custom-filter after="FILTER_SECURITY_INTERCEPTOR" ref="headerFilter"'. I had asked Spring security to run my filter after filterSecurityInterceptor. FilterSecurityInterceptor is responsible for enforcing interceptions including checking role in the authentication present in security context. just changed 'after' to 'before' and its working. Also in a side note, I was setting authorities to the principal instead of setting to the authentication object itself. Phew! — MickJ, Mar 18 '13 at 19:11

score 1 · Accepted Answer · answered Mar 18 '13 at 19:17

Thanks to the pointer from @Maksym, the problem was resolved by changing 'after' to 'before' in the customHeaderFilter as follows:

<security:custom-filter before="FILTER_SECURITY_INTERCEPTOR" ref="headerFilter"/>

FilterSecurityInterceptor is responsible for handling security of HTTP resources, including applying role checks. In my case X509Filter would fire setting principal but would not set any authorities. This would cause the interceptor to deny access to the resource and the headerFilter would not even come into the picture.

By setting the position of the headerFilter to before the interceptor allowed the principal and authentication object in the security context to be set up correctly with the given authorities, leading to the expected behavior.

Spring security with multiple custom filters and roles

1 Answers1