diff --git a/docs/manual/src/docbook/appendix-namespace.xml b/docs/manual/src/docbook/appendix-namespace.xml
index 3e25b52655..f7959533e6 100644
--- a/docs/manual/src/docbook/appendix-namespace.xml
+++ b/docs/manual/src/docbook/appendix-namespace.xml
@@ -15,30 +15,29 @@
explaining their purpose. The namespace is written in RELAX NG Compact format and later converted into
an XSD schema. If you are familiar with this format, you may wish to examine the schema file directly.
Web Application Security - the <http> Element
- If you use an <http> element within your application, a
- FilterChainProxy bean named "springSecurityFilterChain" is
- created and the configuration within the element is used to build a filter chain within
- FilterChainProxy. As of Spring Security 3.1, additional
- http elements can be used to add extra filter chains
+ The <http> element encapsulates the security configuration
+ for the web layer of your application. It creates a
+ FilterChainProxy bean named "springSecurityFilterChain" which
+ maintains the stack of security filters which make up the web security configuration See the introductory chapter for how to set
up the mapping from your web.xml
- . Some core filters are always created in a filter chain and others will be
- added to the stack depending on the attributes and child elements which are present. The
- positions of the standard filters are fixed (see the
- filter order table in the namespace introduction), removing a common source of
- errors with previous versions of the framework when users had to configure the filter
- chain explicitly in theFilterChainProxy bean. You can, of course,
- still do this if you need full control of the configuration.
+ . Some core filters are always created and others will be added to the stack
+ depending on the attributes child elements which are present. The positions of the
+ standard filters are fixed (see the filter order
+ table in the namespace introduction), removing a common source of errors with
+ previous versions of the framework when users had to configure the filter chain
+ explicitly in theFilterChainProxy bean. You can, of course, still
+ do this if you need full control of the configuration. All filters which require a reference to the
AuthenticationManager will be automatically injected with
the internal instance created by the namespace configuration (see the introductory chapter for more on the
AuthenticationManager).
- Each <http> namespace block always creates an
+ The <http> namespace block always creates an
SecurityContextPersistenceFilter, an
ExceptionTranslationFilter and a
FilterSecurityInterceptor. These are fixed and cannot be replaced
@@ -47,50 +46,25 @@
<http> Attributes The attributes on the <http> element control some of the
properties on the core filters.
-
- pattern
- Defining a pattern for the http element controls the
- requests which will be filtered through the list of filters which it defines.
- The interpretation is dependent on the configured request-matcher. If no pattern is defined,
- all requests will be matched, so the most specific patterns should be declared
- first.
-
-
- security
- A request pattern can be mapped to an empty filter chain, by setting this
- attribute to none. No security will be applied and none of
- Spring Security's features will be available.
- servlet-api-provision Provides versions of HttpServletRequest security methods
such as isUserInRole() and getPrincipal()
which are implemented by adding a
SecurityContextHolderAwareRequestFilter bean to the
- stack. Defaults to "true".
-
-
- jaas-api-provision
- If available, runs the request as the Subject acquired from
- the JaasAuthenticationToken which is implemented by
- adding a JaasApiIntegrationFilter bean to the stack.
- Defaults to "false".
+ stack. Defaults to "true".
- request-matcher
- Defines the RequestMatcher strategy used in
- the FilterChainProxy and the beans created by the
- intercept-url to match incoming requests. Options are
- currently ant, regex and
- ciRegex, for ant, regular-expression and case-insensitive
- regular-expression repsectively. A separate instance is created for each
- intercept-url element using its pattern
- and method attributes (see below). Ant paths are matched
- using an AntPathRequestMatcher and regular expressions
- are matched using a RegexRequestMatcher. See the Javadoc
- for these classes for more details on exactly how the matching is preformed. Ant
- paths are the default strategy.
+ path-type
+ Controls whether URL patterns are interpreted as ant paths (the default) or
+ regular expressions. In practice this sets a particular
+ UrlMatcher instance on the
+ FilterChainProxy.
+
+
+ lowercase-comparisons
+ Whether test URLs should be converted to lower case prior to comparing with
+ defined path patterns. If unspecified, defaults to "true" realm
@@ -106,12 +80,6 @@
AuthenticationEntryPoint bean which will start
the authentication process.
-
- security-context-repository-ref
- Allows injection of a custom
- SecurityContextRepository into the
- SecurityContextPersistenceFilter.
- access-decision-manager-ref Optional attribute specifying the ID of the
@@ -131,13 +99,13 @@
Corresponds to the observeOncePerRequest property of
FilterSecurityInterceptor. Defaults to "true".
-
+ create-session Controls the eagerness with which an HTTP session is created. If not set,
defaults to "ifRequired". Other options are "always" and "never". The setting of
this attribute affect the allowSessionCreation and
forceEagerSessionCreation properties of
- HttpSessionContextIntegrationFilter.
+ SecurityContextPersistenceFilter.
allowSessionCreation will always be true unless this
attribute is set to "never". forceEagerSessionCreation is
"false" unless it is set to "always". So the default configuration allows
@@ -145,7 +113,7 @@
control is enabled, when forceEagerSessionCreation will be
set to true, regardless of what the setting is here. Using "never" would then
cause an exception during the initialization of
- HttpSessionContextIntegrationFilter.
+ SecurityContextPersistenceFilter.
use-expressions
@@ -174,17 +142,19 @@
This element is used to define the set of URL patterns that the application is
interested in and to configure how they should be handled. It is used to construct
the FilterInvocationSecurityMetadataSource used by
- the FilterSecurityInterceptor. It is also responsible for
- configuring a ChannelAuthenticationFilter if particular URLs
- need to be accessed by HTTPS, for example. When matching the specified patterns
- against an incoming request, the matching is done in the order in which the elements
- are declared. So the most specific matches patterns should come first and the most
+ the FilterSecurityInterceptor and to exclude particular
+ patterns from the filter chain entirely (by setting the attribute
+ filters="none"). It is also responsible for configuring a
+ ChannelAuthenticationFilter if particular URLs need to be
+ accessed by HTTPS, for example. When matching the specified patterns against an
+ incoming request, the matching is done in the order in which the elements are
+ declared. So the most specific matches patterns should come first and the most
general should come last.pattern The pattern which defines the URL path. The content will depend on the
- request-matcher attribute from the containing http element,
- so will default to ant path syntax.
+ path-type attribute from the containing http element, so will
+ default to ant path syntax.
method
@@ -242,7 +212,7 @@
filter stack and an LoginUrlAuthenticationEntryPoint to the
application context to provide authentication on demand. This will always take
precedence over other namespace-created entry points. If no attributes are supplied,
- a login page will be generated automatically at the URL "/spring_security_login"
+ a login page will be generated automatically at the URL "/spring-security-login" This feature is really just provided for convenience and is not intended for
production (where a view technology will have been chosen and can be used to
render a customized login page). The class
@@ -255,7 +225,7 @@
The URL that should be used to render the login page. Maps to the
loginFormUrl property of the
LoginUrlAuthenticationEntryPoint. Defaults to
- "/spring_security_login".
+ "/spring-security-login". login-processing-url
@@ -293,11 +263,9 @@
authentication-success-handler-refThis can be used as an alternative to default-target-url
and always-use-default-target, giving you full control over
- the navigation flow after a successful authentication. The value should be the
+ the navigation flow after a successful authentication. The value should be he
name of an AuthenticationSuccessHandler bean in
- the application context. By default, an imlementation of
- SavedRequestAwareAuthenticationSuccessHandler is used and
- injected with the default-target-url.
+ the application context.
authentication-failure-handler-ref
@@ -329,13 +297,18 @@
will be used and configured with a
JdbcTokenRepositoryImpl instance.
+
+ token-repository-ref
+ Configures a PersistentTokenBasedRememberMeServices
+ but allows the use of a custom
+ PersistentTokenRepository bean.
+ services-ref Allows complete control of the
RememberMeServices implementation that will be
- used by the filter. The value should be the id of a bean in the application
- context which implements this interface. Should also implement
- LogoutHandler if a logout filter is in use.
+ used by the filter. The value should be the Id of a bean in the application
+ context which implements this interface.
token-repository-ref
@@ -367,7 +340,7 @@
UserDetailsService, so there has to be one
defined in the application context. If there is only one, it will be selected
and used automatically by the namespace configuration. If there are multiple
- instances, you can specify a bean id explicitly using this attribute.
+ instances, you can specify a bean Id explicitly using this attribute.
@@ -470,17 +443,8 @@
OpenIDAuthenticationFilter and
OpenIDAuthenticationProvider will be registered. The latter
requires a reference to a UserDetailsService. Again,
- this can be specified by id, using the user-service-ref
+ this can be specified by Id, using the user-service-ref
attribute, or will be located automatically in the application context.
-
- The <attribute-exchange> Element
- The attribute-exchange element defines the list of
- attributes which should be requested from the identity provider. More than one
- can be used, in which case each must have an identifier-match
- attribute, containing a regular expression which is matched against the supplied
- OpenID identifer. This allows different attribute lists to be fetched from
- different providers (Google, Yahoo etc).
- The <logout> Element
@@ -496,22 +460,11 @@
The destination URL which the user will be taken to after logging out.
Defaults to "/".
-
- The success-handler-ref attribute
- May be used to supply an instance of LogoutSuccessHandler
- which will be invoked to control the navigation after logging out.
-
- The invalidate-session attribute Maps to the invalidateHttpSession of the
SecurityContextLogoutHandler. Defaults to "true", so the
- session will be invalidated on logout.
-
-
- The delete-cookies attribute
- A comma-separated list of the names of cookies which should be deleted when the user logs out.
-
+ session will be invalidated on logout.
@@ -627,13 +580,6 @@
you do this if you are using a custom implementation and want to use these
annotations.
-
- The mode Attribute
- This attribute can be set to aspectj to specify that AspectJ
- should be used instead of the default Spring AOP. Secured methods must be woven
- with the AnnotationSecurityAspect from the
- spring-security-aspects module.
- Securing Methods using <protect-pointcut> Rather than defining security attributes on an individual method or class