spring security filter chain

摘要: spring security拦截链,

##13.the security Filter chain

spring security的web机制是基于标准的servlet拦截器的.它没有使用servlet或其他基于servlet的框架,因此它同web技术没有太强的关联.他处理httpServletRequest和response时,不会关心这些请求是来自浏览器,还是其他web服务客户端,一个HttpInvoker or ajax应用.

spring安全保持一个互相关联的拦截链.每个拦截链都有特定的职责并根据服务的需求来决定他们是否被添加.他们之间排序也很重要.有时你需要自定义这些类的版本.

##13.1 DelegatingFilterProxy

当你使用servlet拦截器,你需要在你的web.xml里声明他们.否则就会被servlet容器忽略.

如下使用DelegatingFilterProxy,web.xml如下:

<filter>
<filter-name>myFilter</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>

<filter-mapping>
<filter-name>myFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

这个拦截器是一个DelegatingFilterProxy,而不是实际上实现的拦截器.delegatingFilterProxy代理从spring应用上下文中获取的bean的拦截器方法.

###13.2 FilterChainProxy

spring security的web架构只应该用来代理FilterChainProxy的实例.理论上你可以在web.xml里注册各种filters,但这样会使是xml文件散乱.

<bean id="filterChainProxy" class="org.springframework.security.web.FilterChainProxy">
<constructor-arg>
<list>
<sec:filter-chain pattern="/restful/**" filters="
securityContextPersistenceFilterWithASCFalse,
basicAuthenticationFilter,
exceptionTranslationFilter,
filterSecurityInterceptor" />
<sec:filter-chain pattern="/**" filters="
securityContextPersistenceFilterWithASCTrue,
formLoginFilter,
exceptionTranslationFilter,
filterSecurityInterceptor" />
</list>
</constructor-arg>
</bean>

上例中根据url来区分.
你可以使用属性filters="none"来支持.这样会排除filter之外.如果你想使用securityContextHolder,那必须经过拦截链.

###13.3 拦截器顺序
顺序应该如下:

ChannelProcessingFilter,它可能会重定向到不同的协议.

SecurityContextPersistentceFilter,所以securityContextHolder安装SecurityContext,任何的一个改变都会到httpSession里.

ConcurrentSessionFilter 因为可以使用SecurityContextHolder的功能,所以可以使用SessionRegistry来反应来自主体的请求.

Authentication processing mechanisms 认证处理机制,UsernamePasswordAuthenticationFilter,CasAuthenticationFilter,BasicAuthenticationFilter等.所以springContextHolder会发生改变

SecurityContextHolderAwareRequestFilter.用来向你的servlet容器里安装HttpServletRequestWrapper组件

JaasApiIntegrationFilter,如果SecurityContextHolder里有JaasAuthenticationToken,那么就可以通过拦截器

RememberMeAuthenticationFilter.如果没有更早的安全认证机制来更新SecurityContextHolder,且请求中的代表的cookie能使remember-me发生作用,那么一个适当的Authentication对象就会装进去.

AnonymousAuthenticationFilter.如果之前的处理机制没有更新SecurityContextHolder,就会设置一个匿名的Authentication对象.

ExceptionTranslationFilter,捕获异常,可以返回http错误响应,或合适AuthenticationEntryPoint.

FilterSecurityInterceptor,用来保护web URIs,当访问受限会抛出异常

##13.4 Request Matching and httpFirewall

spring security有几个区域来决定那个请求应该被处理.当FilterChainProxy决定那个请求可以通过,FilterSecurityInterceptor决定那个安全限制适用于一个规则.

servlet规则定义了几种能被getter方法访问的httpServletRequest属性,如contextPath,servletPath,pathInfo,queryString.contextPath可以被忽略.但不幸的是,servletPath,pathInfo的值没有被准确定义.例如,每个url的部分可能包含属性值.但是该规则没有说明是否要包含在servletPath和pathInfo值中,还有不同servlet容器的区别.如果一个容器没有从url值中剥离这些参数很危险,攻击者可能把它们添加到请求url中,引起模板匹配的成功或失败.其他的变种在url请求中也是可能的.例如,他应该包含路径转化序列(如/../)或混合路径转化序列(//),那么这会引起正则表达式失败.有些容器会在servlet匹配之前将他们正常化,而有些则不会.为了保护这些问题,FilterChainProxy会使用HttpFirewall的策略来检测组装这些请求.不正常的请求默认会被拒绝.servletPath和pathInfo是由容器来解码的,所以你的应用不应该有任何有效的路径包含分号,如果有,则会被删除.

默认使用ant风格路径,这个是最好的选择.这个策略是通过AntpathRequestMatcher类实现的,它大小写敏感,匹配了servletPath和pathInfo,且忽略了queryString.

如果你需要更强力的匹配策略,那你可以使用正则表达式.这个策略是RegexRequestMatcher实现的,查看javadoc以了解更多.

实际上我们还在服务层使用访问控制,不完全依赖web层的安全防护.url的变化很难统计这些应用支持的url的数量,已经这些请求该如何被操作.你应该通过简单的例子来测试这些路径.一般情况下是默认拒绝的方式.

Security定义的安全很稳健,难以绕过.所以你应该更好的利用spring security的方法.

HttpFirewall通过拒绝新行字符来拒绝http响应.

###13.5 使用其他基于拦截器的框架

要讲spring security的拦截器放在其他拦截器之前./

###13.6 高级命名空间配置

<!-- Stateless RESTful service using Basic authentication -->
<http pattern="/restful/**" create-session="stateless">
<intercept-url pattern='/**' access="hasRole('REMOTE')" />
<http-basic />
</http>

<!-- Empty filter chain for the login page -->
<http pattern="/login.htm*" security="none"/>

<!-- Additional filter chain for normal users, matching all other requests -->
<http>
<intercept-url pattern='/**' access="hasRole('USER')" />
<form-login login-page='/login.htm' default-target-url="/home.htm"/>
<logout />
</http>