Adding in Your Own FiltersIf you've used Spring Security before, you'll know that the framework maintains a chain
of filters in order to apply its services. You may want to add your own filters to the stack at
- particular locations, or use a customized version of an existing filter. How can you do this with
- namespace configuration, since the filter chain is not directly exposed?
+ particular locations or use a Spring Security filter for which there isn't currently a namespace
+ configuration option (CAS, for example). Or you might want to use a customized version of a
+ standard namespace filter, such as the AuthenticationProcessingFilter which is created by the
+ <form-login> element, taking advantage of some of the extra configuration options which are
+ available by using defining the bean directly. How can you do this with namespace configuration,
+ since the filter chain is not directly exposed?
The order of the filters is always strictly enforced when using the namespace. Each Spring Security
- filter implements the Spring Ordered interface and the filters are sorted
- during initialization. The standard filters each have an alias in the namespace:
-
+ filter implements the Spring Ordered interface and the filters created by the namespace
+ are sorted during initialization. The standard Spring Security filters each have an alias in the namespace. The filters, aliases
+ and namespace elements/attributes which create the filters are shown in .
+
@@ -470,8 +539,39 @@
to be inserted before or after another filter in the stack. The names "FIRST" and "LAST" can be used to indicate
that you want your filter to appear before or after the entire stack, respectively.
+
+ Avoiding filter position conflicts
+
+ If you are inserting a custom filter which may occupy the same position as one of the standard filters created by the namespace
+ then it's important that you don't include the namespace versions by mistake. Avoid using the
+ auto-config attribute and remove any elements which create filters whose functionality you want to replace.
+
+
+ Note that you can't replace filters which are created by the use of the <http>
+ element itself - HttpSessionContextIntegrationFilter, ExceptionTranslationFilter or
+ FilterSecurityInterceptor.
+
+
+
+ If you're replacing a namespace filter which requires an authentication entry point (i.e. where the authentication process is triggered by
+ an attempt by an unauthenticated user to access to a secured resource), you will need to add a custom entry point bean too.
+
+
+ Setting a Custom AuthenticationEntryPoint
+
+ If you aren't using form login, OpenID or basic authentication through the namespace, you may
+ want to define an authentication filter and entry point using a traditional bean syntax and link them
+ into the namespace, as we've just seen. The corresponding AuthenticationEntryPoint can be set using the
+ entry-point-ref attribute on the <http> element.
+
+
+ The CAS sample application is a good example of the use of custom beans with the namespace, including this syntax. If you aren't
+ familiar with authentication entry points, they are discussed in the technical
+ overview chapter.
+
+
-
+
Session Fixation Attack Protection
@@ -492,22 +592,6 @@
-
- Setting a Custom AuthenticationEntryPoint
-
- If you aren't using form login, OpenID or basic authentication through the namespace, you may
- want to define an authentication filter and entry point using a traditional bean syntax and link them
- into the namespace. You can add the filter as explained in . The
- corresponding AuthenticationEntryPoint can be set using the entry-point-ref
- attribute on the <http> element.
-
-
- The CAS sample is a good example of the use of custom beans with the namespace, including this syntax. If you aren't
- familiar with authentication entry points, they are discussed in the technical
- overview chapter.
-
-
-
@@ -641,9 +725,9 @@
use this name elsewhere in your application context.
-
-
-
+
+
+
...