To secure FilterInvocation
s, developers need
to add a FilterSecurityInterceptor
to their filter chain.
A typical configuration example is provided below:
In the application context you will need to configure three beans:
<bean id="exceptionTranslationFilter" class="org.springframework.security.ui.ExceptionTranslationFilter"> <property name="authenticationEntryPoint" ref="authenticationEntryPoint"/> </bean> <bean id="authenticationEntryPoint" class="org.springframework.security.ui.webapp.AuthenticationProcessingFilterEntryPoint"> <property name="loginFormUrl" value="/acegilogin.jsp"/> <property name="forceHttps" value="false"/> </bean> <bean id="filterSecurityInterceptor" class="org.springframework.security.intercept.web.FilterSecurityInterceptor"> <property name="authenticationManager" ref="authenticationManager"/> <property name="accessDecisionManager" ref="accessDecisionManager"/> <property name="objectDefinitionSource"> <security:filter-invocation-definition-source> <security:intercept-url pattern="/secure/super/**" access="ROLE_WE_DONT_HAVE"/> <security:intercept-url pattern="/secure/**" access="ROLE_SUPERVISOR,ROLE_TELLER"/> </security:filter-invocation-definition-source> </property> </bean>
The ExceptionTranslationFilter
provides
the bridge between Java exceptions and HTTP responses. It is solely
concerned with maintaining the user interface. This filter does not do
any actual security enforcement. If an
AuthenticationException
is detected,
the filter will call the AuthenticationEntryPoint to commence the
authentication process (e.g. a user login).
The AuthenticationEntryPoint
will be called
if the user requests a secure HTTP resource but they are not
authenticated. The class handles presenting the appropriate response
to the user so that authentication can begin. Three concrete
implementations are provided with Spring Security:
AuthenticationProcessingFilterEntryPoint
for
commencing a form-based authentication,
BasicProcessingFilterEntryPoint
for commencing a
HTTP Basic authentication process, and
CasProcessingFilterEntryPoint
for commencing a
JA-SIG Central Authentication Service (CAS) login. The
AuthenticationProcessingFilterEntryPoint
and
CasProcessingFilterEntryPoint
have optional
properties related to forcing the use of HTTPS, so please refer to the
JavaDocs if you require this.
FilterSecurityInterceptor
is responsible for
handling the security of HTTP resources. Like any other security
interceptor, it requires a reference to an
AuthenticationManager
and an
AccessDecisionManager
, which are both discussed in
separate sections below. The
FilterSecurityInterceptor
is also configured with
configuration attributes that apply to different HTTP URL requests. A
full discussion of configuration attributes is provided in the High
Level Design section of this document.
The FilterSecurityInterceptor
can be
configured with configuration attributes in two ways. The first,
which is shown above, is using the <filter-invocation-definition-source>
namespace element. This is similar to the <filter-chain-map>
used to configure a FilterChainProxy
but the <intercept-url>
child elements only use the pattern
and access
attributes.
The second is by writing your own
ObjectDefinitionSource
, although this is beyond the
scope of this document. Irrespective of the approach used, the
ObjectDefinitionSource
is responsible for returning
a ConfigAttributeDefinition
object that contains
all of the configuration attributes associated with a single secure
HTTP URL.
It should be noted that the
FilterSecurityInterceptor.setObjectDefinitionSource()
method actually expects an instance of
FilterInvocationDefinitionSource
. This is a marker
interface which subclasses ObjectDefinitionSource
.
It simply denotes the ObjectDefinitionSource
understands FilterInvocation
s. In the interests of
simplicity we'll continue to refer to the
FilterInvocationDefinitionSource
as an
ObjectDefinitionSource
, as the distinction is of
little relevance to most users of the
FilterSecurityInterceptor
.
When using the namespace option to configure the interceptor,
commas are used to delimit the different configuration
attributes that apply to each HTTP URL. Each configuration attribute
is assigned into its own SecurityConfig
object. The
SecurityConfig
object is discussed in the High
Level Design section. The ObjectDefinitionSource
created by the property editor,
FilterInvocationDefinitionSource
, matches
configuration attributes against FilterInvocations
based on expression evaluation of the request URL. Two standard
expression syntaxes are supported. The default is to treat all
expressions as Apache Ant paths and regular expressions are also supported
for ore complex cases. The path-type
attribute is used
to specify the type of pattern being used. It is not possible to
mix expression syntaxes within the same definition. For example, the
previous configuration using regular expressions instead of Ant paths would be
written as follows:
<bean id="filterInvocationInterceptor" class="org.springframework.security.intercept.web.FilterSecurityInterceptor"> <property name="authenticationManager" ref="authenticationManager"/> <property name="accessDecisionManager" ref="accessDecisionManager"/> <property name="runAsManager" ref="runAsManager"/> <property name="objectDefinitionSource"> <security:filter-invocation-definition-source path-type="regex"> <security:intercept-url pattern="\A/secure/super/.*\Z" access="ROLE_WE_DONT_HAVE"/> <security:intercept-url pattern="\A/secure/.*\" access="ROLE_SUPERVISOR,ROLE_TELLER"/> </security:filter-invocation-definition-source> </property> </bean>
Irrespective of the type of expression syntax used, expressions
are always evaluated in the order they are defined. Thus it is
important that more specific expressions are defined higher in the
list than less specific expressions. This is reflected in our example
above, where the more specific /secure/super/
pattern appears higher than the less specific
/secure/
pattern. If they were reversed, the
/secure/
pattern would always match and the
/secure/super/
pattern would never be
evaluated.
As with other security interceptors, the
validateConfigAttributes
property is observed. When
set to true
(the default), at startup time the
FilterSecurityInterceptor
will evaluate if the
provided configuration attributes are valid. It does this by checking
each configuration attribute can be processed by either the
AccessDecisionManager
or the
RunAsManager
. If neither of these can process a
given configuration attribute, an exception is thrown.