|
|
|
|
@ -1,97 +1,32 @@
@@ -1,97 +1,32 @@
|
|
|
|
|
<chapter xmlns="http://docbook.org/ns/docbook" version="5.0" xml:id="supporting-infrastructure" xmlns:xlink="http://www.w3.org/1999/xlink"> |
|
|
|
|
<chapter xmlns="http://docbook.org/ns/docbook" version="5.0" xml:id="web-infrastructure" xmlns:xlink="http://www.w3.org/1999/xlink"> |
|
|
|
|
|
|
|
|
|
<info><title>Supporting Infrastructure</title></info> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para>This chapter introduces some of the supplementary and supporting |
|
|
|
|
infrastructure used by Spring Security. If a capability is not directly |
|
|
|
|
related to security, yet included in the Spring Security project, we |
|
|
|
|
will discuss it in this chapter.</para> |
|
|
|
|
|
|
|
|
|
<section xml:id="localization"> |
|
|
|
|
<title>Localization</title> |
|
|
|
|
<para>Spring Security supports localization of exception messages that |
|
|
|
|
end users are likely to see. If your application is designed for |
|
|
|
|
English users, you don't need to do anything as by default all |
|
|
|
|
Security Security messages are in English. If you need to support |
|
|
|
|
other locales, everything you need to know is contained in this |
|
|
|
|
section.</para> |
|
|
|
|
|
|
|
|
|
<para>All exception messages can be localized, including messages |
|
|
|
|
related to authentication failures and access being denied |
|
|
|
|
(authorization failures). Exceptions and logging that is focused on |
|
|
|
|
developers or system deployers (including incorrect attributes, |
|
|
|
|
interface contract violations, using incorrect constructors, startup |
|
|
|
|
time validation, debug-level logging) etc are not localized and |
|
|
|
|
instead are hard-coded in English within Spring Security's |
|
|
|
|
code.</para> |
|
|
|
|
|
|
|
|
|
<para>Shipping in the <literal>spring-security-core-xx.jar</literal> you |
|
|
|
|
will find an <literal>org.springframework.security</literal> package |
|
|
|
|
that in turn contains a <literal>messages.properties</literal> file. |
|
|
|
|
This should be referred to by your |
|
|
|
|
<literal>ApplicationContext</literal>, as Spring Security classes |
|
|
|
|
implement Spring's <literal>MessageSourceAware</literal> interface and |
|
|
|
|
expect the message resolver to be dependency injected at application |
|
|
|
|
context startup time. Usually all you need to do is register a bean |
|
|
|
|
inside your application context to refer to the messages. An example |
|
|
|
|
is shown below:</para> |
|
|
|
|
|
|
|
|
|
<para><programlisting><![CDATA[ |
|
|
|
|
<bean id="messageSource" |
|
|
|
|
class="org.springframework.context.support.ReloadableResourceBundleMessageSource"> |
|
|
|
|
<property name="basename" value="org/springframework/security/messages"/> |
|
|
|
|
</bean> |
|
|
|
|
]]></programlisting></para> |
|
|
|
|
|
|
|
|
|
<para>The <literal>messages.properties</literal> is named in |
|
|
|
|
accordance with standard resource bundles and represents the default |
|
|
|
|
language supported by Spring Security messages. This default file is |
|
|
|
|
in English. If you do not register a message source, Spring Security |
|
|
|
|
will still work correctly and fallback to hard-coded English versions |
|
|
|
|
of the messages.</para> |
|
|
|
|
|
|
|
|
|
<para>If you wish to customize the |
|
|
|
|
<literal>messages.properties</literal> file, or support other |
|
|
|
|
languages, you should copy the file, rename it accordingly, and |
|
|
|
|
register it inside the above bean definition. There are not a large |
|
|
|
|
number of message keys inside this file, so localization should not be |
|
|
|
|
considered a major initiative. If you do perform localization of this |
|
|
|
|
file, please consider sharing your work with the community by logging |
|
|
|
|
a JIRA task and attaching your appropriately-named localized version |
|
|
|
|
of <literal>messages.properties</literal>.</para> |
|
|
|
|
|
|
|
|
|
<para>Rounding out the discussion on localization is the Spring |
|
|
|
|
<literal>ThreadLocal</literal> known as |
|
|
|
|
<literal>org.springframework.context.i18n.LocaleContextHolder</literal>. |
|
|
|
|
You should set the <literal>LocaleContextHolder</literal> to represent |
|
|
|
|
the preferred <literal>Locale</literal> of each user. Spring Security |
|
|
|
|
will attempt to locate a message from the message source using the |
|
|
|
|
<literal>Locale</literal> obtained from this |
|
|
|
|
<literal>ThreadLocal</literal>. Please refer to Spring documentation |
|
|
|
|
for further details on using <literal>LocaleContextHolder</literal> |
|
|
|
|
and the helper classes that can automatically set it for you (eg |
|
|
|
|
<literal>AcceptHeaderLocaleResolver</literal>, |
|
|
|
|
<literal>CookieLocaleResolver</literal>, |
|
|
|
|
<literal>FixedLocaleResolver</literal>, |
|
|
|
|
<literal>SessionLocaleResolver</literal> etc)</para> |
|
|
|
|
</section> |
|
|
|
|
<info><title>Web Security Infrastructure</title></info> |
|
|
|
|
|
|
|
|
|
<section xml:id="filters"> |
|
|
|
|
<info><title>Filters</title></info> |
|
|
|
|
<title>Spring Security Filters</title> |
|
|
|
|
|
|
|
|
|
<para>Spring Security uses many filters, as referred to throughout the |
|
|
|
|
remainder of this reference guide. If you are using <link xlink:href="#ns-config">namespace configuration</link>, |
|
|
|
|
then the you don't usually have to declare the filter beans explicitly. There may be times when you want full control |
|
|
|
|
over the security filter chain, either because you are using features which aren't supported in the namespace, or you |
|
|
|
|
are using your own customized versions of classes.</para> |
|
|
|
|
<para>In this case, you have a choice in how these filters are added to your web application, in that you can use either |
|
|
|
|
Spring's <literal>DelegatingFilterProxy</literal> or |
|
|
|
|
<classname>FilterChainProxy</classname>. We'll look at both below.</para> |
|
|
|
|
|
|
|
|
|
<para>When using <literal>DelegatingFilterProxy</literal>, you will see |
|
|
|
|
something like this in the web.xml file: |
|
|
|
|
|
|
|
|
|
<para>Spring Security's web application features are implemented using standard servlet filters. It doesn't use |
|
|
|
|
servlets or any other servlet-based frameworks (such as Spring MVC) internally. So it has no strong links to any |
|
|
|
|
particular web technology - it deals in <classname>HttpServletRequest</classname>s and <classname>HttpServletResponse</classname>s |
|
|
|
|
and doesn't care whether the requests come from a browser, a web service client, an <classname>HttpInvoker</classname> or an AJAX application. |
|
|
|
|
</para> |
|
|
|
|
<para> |
|
|
|
|
Spring Security maintains a filter chain internally where each of the filters has a particular responsibility and filters are added or removed |
|
|
|
|
depending on which services are required. The ordering of the filters is important as there are dependencies between them. |
|
|
|
|
If you have been using <link xlink:href="#ns-config">namespace configuration</link>, then the filters are automatically configured for you |
|
|
|
|
and you don't have to define any Spring beans explicitly but here may be times when you want full control over the security filter chain, |
|
|
|
|
either because you are using features which aren't supported in the namespace, or you are using your own customized versions of classes.</para> |
|
|
|
|
|
|
|
|
|
<section xml:id="delegating-filter-proxy"> |
|
|
|
|
<title><classname>DelegatingFilterProxy</classname></title> |
|
|
|
|
<para> |
|
|
|
|
When using servlet filters, you obviously need to declare them in your <filename>web.xml</filename>, or they will be ignored |
|
|
|
|
by the servlet container. In Spring Security, the filter classes are also Spring beans defined in the application context and thus able |
|
|
|
|
to take advantage of Spring's rich dependency-injection facilities and lifecycle interfaces. Spring's <classname>DelegatingFilterProxy</classname> |
|
|
|
|
provides the link between <filename>web.xml</filename> and the application context. |
|
|
|
|
</para> |
|
|
|
|
<para>When using <classname>DelegatingFilterProxy</classname>, you will see something like this in the <filename>web.xml</filename> file: |
|
|
|
|
|
|
|
|
|
<programlisting><![CDATA[ |
|
|
|
|
<filter> |
|
|
|
|
<filter-name>myFilter</filter-name> |
|
|
|
|
@ -103,132 +38,111 @@
@@ -103,132 +38,111 @@
|
|
|
|
|
<url-pattern>/*</url-pattern> |
|
|
|
|
</filter-mapping>]]> |
|
|
|
|
</programlisting> |
|
|
|
|
|
|
|
|
|
Notice that the filter is actually a <literal>DelegatingFilterProxy</literal>, |
|
|
|
|
and not the filter that will actually implement the logic of the filter. What |
|
|
|
|
<literal>DelegatingFilterProxy</literal> does is delegate the |
|
|
|
|
<literal>Filter</literal>'s methods through to a bean which is |
|
|
|
|
obtained from the Spring application context. This enables the bean to |
|
|
|
|
benefit from the Spring web application context lifecycle support and |
|
|
|
|
configuration flexibility. The bean must implement |
|
|
|
|
<literal>javax.servlet.Filter</literal> and it must have the same name as that in |
|
|
|
|
the <literal>filter-name</literal> element.</para> |
|
|
|
|
|
|
|
|
|
<para>There is a lifecycle issue to consider when hosting |
|
|
|
|
<literal>Filter</literal>s in an IoC container instead of a servlet |
|
|
|
|
container. Specifically, which container should be responsible for |
|
|
|
|
calling the <literal>Filter</literal>'s "startup" and "shutdown" |
|
|
|
|
methods? It is noted that the order of initialization and destruction |
|
|
|
|
of a <literal>Filter</literal> can vary by servlet container, and this |
|
|
|
|
can cause problems if one <literal>Filter</literal> depends on |
|
|
|
|
configuration settings established by an earlier initialized |
|
|
|
|
<literal>Filter</literal>. The Spring IoC container on the other hand |
|
|
|
|
has more comprehensive lifecycle/IoC interfaces (such as |
|
|
|
|
<literal>InitializingBean</literal>, |
|
|
|
|
<literal>DisposableBean</literal>, <literal>BeanNameAware</literal>, |
|
|
|
|
<literal>ApplicationContextAware</literal> and many others) as well as |
|
|
|
|
a well-understood interface contract, predictable method invocation |
|
|
|
|
ordering, autowiring support, and even options to avoid implementing |
|
|
|
|
Spring interfaces (eg the <literal>destroy-method</literal> attribute |
|
|
|
|
in Spring XML). For this reason we recommend the use of Spring |
|
|
|
|
lifecycle services instead of servlet container lifecycle services |
|
|
|
|
wherever possible. Read the Javadoc for <classname>DelegatingFilterProxy</classname> |
|
|
|
|
for more information</para> |
|
|
|
|
|
|
|
|
|
<para>Rather than using <literal>DelegatingFilterProxy</literal>, we |
|
|
|
|
strongly recommend that you use <classname>FilterChainProxy</classname> instead. |
|
|
|
|
Whilst <literal>DelegatingFilterProxy</literal> is a very useful class, |
|
|
|
|
the problem is that the number of lines of code required for |
|
|
|
|
<literal><filter></literal> and |
|
|
|
|
<literal><filter-mapping></literal> entries in |
|
|
|
|
<literal>web.xml</literal> explodes when using more than a few |
|
|
|
|
filters. To overcome this issue, Spring Security provides a |
|
|
|
|
<classname>FilterChainProxy</classname> class. It is wired using a |
|
|
|
|
<literal>DelegatingFilterProxy</literal> (just like in the example above), |
|
|
|
|
but the target class is |
|
|
|
|
<literal>org.springframework.security.web.FilterChainProxy</literal>. |
|
|
|
|
The filter chain is then declared in the application context, using |
|
|
|
|
code such as this:</para> |
|
|
|
|
|
|
|
|
|
<para><programlisting><![CDATA[ |
|
|
|
|
Notice that the filter is actually a <literal>DelegatingFilterProxy</literal>, |
|
|
|
|
and not the class that will actually implement the logic of the filter. What |
|
|
|
|
<classname>DelegatingFilterProxy</classname> does is delegate the |
|
|
|
|
<interfacename>Filter</interfacename>'s methods through to a bean which is |
|
|
|
|
obtained from the Spring application context. This enables the bean to |
|
|
|
|
benefit from the Spring web application context lifecycle support and |
|
|
|
|
configuration flexibility. The bean must implement |
|
|
|
|
<interfacename>javax.servlet.Filter</interfacename> and it must have the same name as that in |
|
|
|
|
the <literal>filter-name</literal> element. Read the Javadoc for <classname>DelegatingFilterProxy</classname> |
|
|
|
|
for more information</para> |
|
|
|
|
</section> |
|
|
|
|
<section xml:id="filter-chain-proxy"> |
|
|
|
|
<title><classname>FilterChainProxy</classname></title> |
|
|
|
|
<para> |
|
|
|
|
It should now be clear that you can declare each Spring Security filter bean that you require in your application context file and add a corresponding |
|
|
|
|
<classname>DelegatingFilterProxy</classname> entry to <filename>web.xml</filename> for each filter, making sure that they are ordered correctly. |
|
|
|
|
This is a cumbersome approach and clutters up the <filename>web.xml</filename> file quickly if we have a lot of filters. We would prefer to just add |
|
|
|
|
a single entry to <filename>web.xml</filename> and deal entirely with the application context file for managing our web security beans. |
|
|
|
|
This is where Spring Secuiryt's <classname>FilterChainProxy</classname> comes in. It is wired using a <literal>DelegatingFilterProxy</literal> |
|
|
|
|
(just like in the example above), but the target class is <classname>org.springframework.security.web.FilterChainProxy</classname>. |
|
|
|
|
The filter chain is then declared in the application context. Here's an example: |
|
|
|
|
<programlisting language="xml"><![CDATA[ |
|
|
|
|
<bean id="filterChainProxy" class="org.springframework.security.web.FilterChainProxy"> |
|
|
|
|
<sec:filter-chain-map path-type="ant"> |
|
|
|
|
<sec:filter-chain pattern="/webServices/**" filters=" |
|
|
|
|
httpSessionContextIntegrationFilterWithASCFalse, |
|
|
|
|
securityContextPersistenceFilterWithASCFalse, |
|
|
|
|
basicProcessingFilter, |
|
|
|
|
exceptionTranslationFilter, |
|
|
|
|
filterSecurityInterceptor" /> |
|
|
|
|
<sec:filter-chain pattern="/**" filters=" |
|
|
|
|
httpSessionContextIntegrationFilterWithASCTrue, |
|
|
|
|
securityContextPersistenceFilterWithASCTrue, |
|
|
|
|
authenticationProcessingFilter, |
|
|
|
|
exceptionTranslationFilter, |
|
|
|
|
filterSecurityInterceptor" /> |
|
|
|
|
</sec:filter-chain-map> |
|
|
|
|
</bean> |
|
|
|
|
]]> |
|
|
|
|
</programlisting></para> |
|
|
|
|
|
|
|
|
|
<para>You may notice similarities with the way |
|
|
|
|
<classname>FilterSecurityInterceptor</classname> is declared. Both regular |
|
|
|
|
expressions and Ant Paths are supported, and the most specific URIs |
|
|
|
|
appear first. At runtime the <classname>FilterChainProxy</classname> will |
|
|
|
|
locate the first URI pattern that matches the current web request and the list |
|
|
|
|
of filter beans specified by the <literal>filters</literal> attribute |
|
|
|
|
will be applied to that request. The filters will be invoked in the order |
|
|
|
|
they are defined, so you have complete control over the filter chain |
|
|
|
|
which is applied to a particular URL.</para> |
|
|
|
|
|
|
|
|
|
<para>You may have noticed we have declared two |
|
|
|
|
<classname>HttpSessionContextIntegrationFilter</classname>s in the filter |
|
|
|
|
chain (<literal>ASC</literal> is short for |
|
|
|
|
<literal>allowSessionCreation</literal>, a property of |
|
|
|
|
<classname>HttpSessionContextIntegrationFilter</classname>). As web |
|
|
|
|
services will never present a <literal>jsessionid</literal> on future |
|
|
|
|
requests, creating <literal>HttpSession</literal>s for such user |
|
|
|
|
agents would be wasteful. If you had a high-volume application which |
|
|
|
|
required maximum scalability, we recommend you use the approach shown |
|
|
|
|
above. For smaller applications, using a single |
|
|
|
|
<classname>HttpSessionContextIntegrationFilter</classname> (with its |
|
|
|
|
default <literal>allowSessionCreation</literal> as |
|
|
|
|
<literal>true</literal>) would likely be sufficient.</para> |
|
|
|
|
|
|
|
|
|
<para>In relation to lifecycle issues, the |
|
|
|
|
<classname>FilterChainProxy</classname> will always delegate |
|
|
|
|
<literal>init(FilterConfig)</literal> and <literal>destroy()</literal> |
|
|
|
|
methods through to the underlaying <literal>Filter</literal>s if such |
|
|
|
|
methods are called against <classname>FilterChainProxy</classname> itself. |
|
|
|
|
In this case, <classname>FilterChainProxy</classname> guarantees to only |
|
|
|
|
initialize and destroy each <literal>Filter</literal> once, |
|
|
|
|
irrespective of how many times it is declared by the |
|
|
|
|
<interfacename>FilterInvocationDefinitionSource</interfacename>. You control the |
|
|
|
|
overall choice as to whether these methods are called or not via the |
|
|
|
|
<literal>targetFilterLifecycle</literal> initialization parameter of the |
|
|
|
|
<literal>DelegatingFilterProxy</literal> that proxies |
|
|
|
|
<literal>DelegatingFilterProxy</literal>. As discussed above, by default |
|
|
|
|
any servlet container lifecycle invocations are not delegated through |
|
|
|
|
to <literal>DelegatingFilterProxy</literal>.</para> |
|
|
|
|
|
|
|
|
|
<para>You can use the attribute <literal>filters = "none"</literal> |
|
|
|
|
in the same way that you do when using <link xlink:href="#namespace-auto-config">namespace configuration</link> |
|
|
|
|
to build the <classname>FilterChainProxy</classname>. This will omit the |
|
|
|
|
request pattern from the security filter chain entirely. |
|
|
|
|
Note that anything matching this path will then have |
|
|
|
|
no authentication or authorization services applied and will be freely |
|
|
|
|
accessible.</para> |
|
|
|
|
|
|
|
|
|
<para>The order that filters are defined in <literal>web.xml</literal> |
|
|
|
|
</programlisting> |
|
|
|
|
The namespace element <literal>filter-chain-map</literal> is used to set up the security filter chain(s) which are required |
|
|
|
|
within the application. It maps a particular URL pattern to a chain of filters built up from the bean names |
|
|
|
|
specified in the <literal>filters</literal> element. Both regular |
|
|
|
|
expressions and Ant Paths are supported, and the most specific URIs |
|
|
|
|
appear first. At runtime the <classname>FilterChainProxy</classname> will |
|
|
|
|
locate the first URI pattern that matches the current web request and the list |
|
|
|
|
of filter beans specified by the <literal>filters</literal> attribute |
|
|
|
|
will be applied to that request. The filters will be invoked in the order |
|
|
|
|
they are defined, so you have complete control over the filter chain |
|
|
|
|
which is applied to a particular URL.</para> |
|
|
|
|
|
|
|
|
|
<para>You may have noticed we have declared two |
|
|
|
|
<classname>SecurityContextPersistenceFilter</classname>s in the filter |
|
|
|
|
chain (<literal>ASC</literal> is short for |
|
|
|
|
<literal>allowSessionCreation</literal>, a property of |
|
|
|
|
<classname>SecurityContextPersistenceFilter</classname>). As web |
|
|
|
|
services will never present a <literal>jsessionid</literal> on future |
|
|
|
|
requests, creating <literal>HttpSession</literal>s for such user |
|
|
|
|
agents would be wasteful. If you had a high-volume application which |
|
|
|
|
required maximum scalability, we recommend you use the approach shown |
|
|
|
|
above. For smaller applications, using a single |
|
|
|
|
<classname>SecurityContextPersistenceFilter</classname> (with its |
|
|
|
|
default <literal>allowSessionCreation</literal> as |
|
|
|
|
<literal>true</literal>) would likely be sufficient.</para> |
|
|
|
|
|
|
|
|
|
<para>In relation to lifecycle issues, the |
|
|
|
|
<classname>FilterChainProxy</classname> will always delegate |
|
|
|
|
<methodname>init(FilterConfig)</methodname> and <methodname>destroy()</methodname> |
|
|
|
|
methods through to the underlaying <interfacename>Filter</interfacename>s if such |
|
|
|
|
methods are called against <classname>FilterChainProxy</classname> itself. |
|
|
|
|
In this case, <classname>FilterChainProxy</classname> guarantees to only |
|
|
|
|
initialize and destroy each <literal>Filter</literal> bean once, |
|
|
|
|
no matter how many times it is declared in the filter chain(s). You control the |
|
|
|
|
overall choice as to whether these methods are called or not via the |
|
|
|
|
<literal>targetFilterLifecycle</literal> initialization parameter of |
|
|
|
|
<literal>DelegatingFilterProxy</literal>. By default this property |
|
|
|
|
is <literal>false</literal> and servlet container lifecycle invocations are not delegated through |
|
|
|
|
<literal>DelegatingFilterProxy</literal>.</para> |
|
|
|
|
<para> |
|
|
|
|
When we looked at how to set up web security using <link xlink:href="#namespace-auto-config">namespace configuration</link>, |
|
|
|
|
we used a <literal>DelegatingFilterProxy</literal> with the name <quote>springSecurityFilterChain</quote>. You should now be able to |
|
|
|
|
see that this is the name of the <classname>FilterChainProxy</classname> which is created by the namespace. |
|
|
|
|
</para> |
|
|
|
|
<section> |
|
|
|
|
<title>Bypassing the Filter Chain</title> |
|
|
|
|
<para> |
|
|
|
|
As with the namespace, you can use the attribute <literal>filters = "none"</literal> as an alternative to supplying a filter bean list. |
|
|
|
|
This will omit the request pattern from the security filter chain entirely. Note that anything matching this path will then have |
|
|
|
|
no authentication or authorization services applied and will be freely accessible. |
|
|
|
|
</para> |
|
|
|
|
</section> |
|
|
|
|
</section> |
|
|
|
|
|
|
|
|
|
<section> |
|
|
|
|
<title>Filter Ordering</title> |
|
|
|
|
<para>The order that filters are defined in the chain |
|
|
|
|
is very important. Irrespective of which filters you are actually |
|
|
|
|
using, the order of the <literal><filter-mapping></literal>s |
|
|
|
|
should be as follows:</para> |
|
|
|
|
using, the order should be as follows: |
|
|
|
|
|
|
|
|
|
<orderedlist inheritnum="ignore" continuation="restarts"> |
|
|
|
|
<listitem> |
|
|
|
|
<para><literal>ChannelProcessingFilter</literal>, because it might |
|
|
|
|
<para><classname>ChannelProcessingFilter</classname>, because it might |
|
|
|
|
need to redirect to a different protocol</para> |
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
<para><literal>ConcurrentSessionFilter</literal>, because it |
|
|
|
|
<para><classname>ConcurrentSessionFilter</classname>, because it |
|
|
|
|
doesn't use any <classname>SecurityContextHolder</classname> |
|
|
|
|
functionality but needs to update the |
|
|
|
|
<interfacename>SessionRegistry</interfacename> to reflect ongoing requests |
|
|
|
|
@ -236,7 +150,7 @@
@@ -236,7 +150,7 @@
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
<para><classname>HttpSessionContextIntegrationFilter</classname>, so a |
|
|
|
|
<para><classname>SecurityContextPersistenceFilter</classname>, so a |
|
|
|
|
<interfacename>SecurityContext</interfacename> can be setup in the |
|
|
|
|
<classname>SecurityContextHolder</classname> at the beginning of a web |
|
|
|
|
request, and any changes to the <interfacename>SecurityContext</interfacename> |
|
|
|
|
@ -246,10 +160,9 @@
@@ -246,10 +160,9 @@
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
<para>Authentication processing mechanisms - |
|
|
|
|
<literal>UsernamePasswordAuthenticationProcessingFilter</literal>, |
|
|
|
|
<literal>CasProcessingFilter</literal>, |
|
|
|
|
<literal>BasicProcessingFilter, HttpRequestIntegrationFilter, |
|
|
|
|
JbossIntegrationFilter</literal> etc - so that the |
|
|
|
|
<classname>UsernamePasswordAuthenticationProcessingFilter</classname>, |
|
|
|
|
<classname>CasProcessingFilter</classname>, |
|
|
|
|
<classname>BasicProcessingFilter</classname> etc - so that the |
|
|
|
|
<classname>SecurityContextHolder</classname> can be modified to |
|
|
|
|
contain a valid <interfacename>Authentication</interfacename> request |
|
|
|
|
token</para> |
|
|
|
|
@ -274,7 +187,7 @@
@@ -274,7 +187,7 @@
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
<para><literal>AnonymousProcessingFilter</literal>, so that if no |
|
|
|
|
<para><classname>AnonymousProcessingFilter</classname>, so that if no |
|
|
|
|
earlier authentication processing mechanism updated the |
|
|
|
|
<classname>SecurityContextHolder</classname>, an anonymous |
|
|
|
|
<interfacename>Authentication</interfacename> object will be put there</para> |
|
|
|
|
@ -292,21 +205,20 @@
@@ -292,21 +205,20 @@
|
|
|
|
|
URIs</para> |
|
|
|
|
</listitem> |
|
|
|
|
</orderedlist> |
|
|
|
|
|
|
|
|
|
<para>All of the above filters use |
|
|
|
|
<literal>DelegatingFilterProxy</literal> or |
|
|
|
|
<classname>FilterChainProxy</classname>. It is recommended that a single |
|
|
|
|
<literal>DelegatingFilterProxy</literal> proxy through to a single |
|
|
|
|
<classname>FilterChainProxy</classname> for each application, with that |
|
|
|
|
<classname>FilterChainProxy</classname> defining all of Spring Security |
|
|
|
|
filters.</para> |
|
|
|
|
|
|
|
|
|
<para>If you're using SiteMesh, ensure Spring Security filters execute |
|
|
|
|
before the SiteMesh filters are called. This enables the |
|
|
|
|
<classname>SecurityContextHolder</classname> to be populated in time for |
|
|
|
|
use by SiteMesh decorators</para> |
|
|
|
|
</para> |
|
|
|
|
</section> |
|
|
|
|
|
|
|
|
|
<section> |
|
|
|
|
<title>Use with other Filter-Based Frameworks</title> |
|
|
|
|
<para>If you're using SiteMesh, ensure Spring Security filters execute |
|
|
|
|
before the SiteMesh filters are called. This enables the |
|
|
|
|
<classname>SecurityContextHolder</classname> to be populated in time for |
|
|
|
|
use by SiteMesh decorators.</para> |
|
|
|
|
|
|
|
|
|
</section> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</section> |
|
|
|
|
<section xml:id="taglib"> |
|
|
|
|
<info><title>Tag Libraries</title></info> |
|
|
|
|
|
|
|
|
|
|
Luke Taylor
17 years ago