diff --git a/docs/manual/src/docbook/authorization-common.xml b/docs/manual/src/docbook/authorization-common.xml
index db6f10c622..63c99473b7 100644
--- a/docs/manual/src/docbook/authorization-common.xml
+++ b/docs/manual/src/docbook/authorization-common.xml
@@ -149,8 +149,8 @@ boolean supports(Class clazz);
prefix ROLE_. It will vote to grant access if there is a
GrantedAuthority which returns a
String representation (via the getAuthority()
- method) exactly equal to one or more ConfigAttributes starting with
- ROLE_. If there is no exact match of any
+ method) exactly equal to one or more ConfigAttributes starting with the
+ prefix ROLE_. If there is no exact match of any
ConfigAttribute starting with ROLE_, the
RoleVoter will vote to deny access. If no
ConfigAttribute begins with ROLE_, the voter will
@@ -200,11 +200,15 @@ boolean supports(Class clazz);
that integrate with its ACL capabilities.
illustrates Spring Security's
AfterInvocationManager and its concrete implementations.
+
+
+
Like many other parts of Spring Security, AfterInvocationManager has a
single concrete implementation, AfterInvocationProviderManager, which polls
a list of AfterInvocationProviders. Each
diff --git a/docs/manual/src/docbook/namespace-config.xml b/docs/manual/src/docbook/namespace-config.xml
index fbba3ba380..21ded8dc85 100644
--- a/docs/manual/src/docbook/namespace-config.xml
+++ b/docs/manual/src/docbook/namespace-config.xml
@@ -21,13 +21,13 @@
]]> This is much simpler than wiring up the equivalent Apache Directory Server
beans. The most common alternative configuration requirements are supported by attributes on
the ldap-server element and the user is isolated from worrying about which
- beans they need to create and what the bean property names are. You can find
- out more about the use of the ldap-server element in the chapter on
- LDAP.. Use of a good XML editor while
- editing the application context file should provide information on the attributes and elements
- that are available. We would recommend that you try out the SpringSource Tool Suite as it
- has special features for working with standard Spring namespaces.
+ beans they need to create and what the bean property names are.
+ You can find out more about the use of the ldap-server element in
+ the chapter on LDAP.
+ . Use of a good XML editor while editing the application context file should
+ provide information on the attributes and elements that are available. We would recommend that
+ you try out the SpringSource Tool
+ Suite as it has special features for working with standard Spring namespaces.
To start using the security namespace in your application context, all you need to do is
add the schema declaration to your application context file:
The namespace is designed to capture the most common uses of the framework and provide
a simplified and concise syntax for enabling them within an application. The design is based
around the large-scale dependencies within the framework, and can be divided up into the
- following areas:
+ following areas:
+
+ Web/HTTP Security - the most complex part. Sets up the filters
and related service beans used to apply the framework authentication mechanisms, to
- secure URLs, render login and error pages and much
- more.
+ secure URLs, render login and error pages and much more.
+
+
+ Business Object (Method) Security - options for securing the
- service layer.
+ service layer.
+
+
+ AuthenticationManager - handles authentication requests from
- other parts of the framework.
+ other parts of the framework.
+
+
+ AccessDecisionManager - provides access decisions for web and
method security. A default one will be registered, but you can also choose to use a
- custom one, declared using normal Spring bean
- syntax.
+ custom one, declared using normal Spring bean syntax.
+
+
+ AuthenticationProviders - mechanisms against which the
authentication manager authenticates users. The namespace provides supports for
several standard options and also a means of adding custom beans declared using a
- traditional syntax.
+ traditional syntax.
+
+
+ UserDetailsService - closely related to authentication providers,
- but often also required by other beans.
+ but often also required by other beans.
+ We'll see how to configure these in the following sections.
@@ -131,13 +147,16 @@
ant path style syntax. The access attribute defines the access
requirements for requests matching the given pattern. With the default configuration, this
is typically a comma-separated list of roles, one of which a user must have to be allowed to
- make the request. Access-control in Spring Security is not limited to the use of simple
- roles, however, and we'll see later how the interpretation can varyThe
- interpretation of the comma-separated values in the access attribute
- depends on the implementation of the ROLE_ is a marker which indicates that a simple
+ comparison with the user's authorities should be made. In other words, a normal role-based
+ check should be used. Access-control in Spring Security is not limited to the use of simple
+ roles (hence the use of the prefix to differentiate between different types of security
+ attributes). We'll see later how the interpretation can vary
+ The interpretation of the comma-separated values in the access
+ attribute depends on the implementation of the AccessDecisionManager which is used. In Spring Security 3.0, the attribute can
- also be populated with an EL
- expression..
+ also be populated with an EL expression.
+ .
You can use multiple <intercept-url> elements to define
different access requirements for different sets of URLs, but they will be evaluated in
@@ -201,14 +220,15 @@
]]> These other elements are responsible for setting up form-login, basic
- authentication and logout handling services respectively In versions prior
- to 3.0, this list also included remember-me functionality. This could cause some
- confusing errors with some configurations and was removed in 3.0. In 3.0, the addition
- of an AnonymousAuthenticationFilter is part of the default
- <http> configuration, so the <anonymous
- /> element is added regardless of whether auto-config
- is enabled. . They each have attributes which can be used to alter
- their behaviour.
+ authentication and logout handling services respectively
+ In versions prior to 3.0, this list also included remember-me functionality. This
+ could cause some confusing errors with some configurations and was removed in 3.0. In
+ 3.0, the addition of an AnonymousAuthenticationFilter is part
+ of the default <http> configuration, so the
+ <anonymous /> element is added regardless of whether
+ auto-config is enabled.
+ . They each have attributes which can be used to alter their behaviour.
+
Form and Basic Login Options
@@ -229,15 +249,16 @@
Note that you can still use auto-config. The
form-login element just overrides the default settings. Also note
that we've added an extra intercept-url element to say that any
- requests for the login page should be available to anonymous users See the
- chapter on anonymous authentication and also the
- AuthenticatedVoter class for
- more details on how the value IS_AUTHENTICATED_ANONYMOUSLY is
- processed.. Otherwise the request would be matched by the pattern
- /** and it wouldn't be possible to access the login page itself! This
- is a common configuration error and will result in an infinite loop in the application.
- Spring Security will emit a warning in the log if your login page appears to be secured.
- It is also possible to have all requests matching a particular pattern bypass the security
+ requests for the login page should be available to anonymous users
+ See the chapter on anonymous authentication
+ and also the AuthenticatedVoter
+ class for more details on how the value
+ IS_AUTHENTICATED_ANONYMOUSLY is processed.
+ . Otherwise the request would be matched by the pattern /**
+ and it wouldn't be possible to access the login page itself! This is a common
+ configuration error and will result in an infinite loop in the application. Spring
+ Security will emit a warning in the log if your login page appears to be secured. It is
+ also possible to have all requests matching a particular pattern bypass the security
filter chain completely:
@@ -458,14 +479,20 @@
logs in. If you don't require this protection, or it conflicts with some other
requirement, you can control the behaviour using the
session-fixation-protection attribute on
- <session-management>, which has three options
- migrateSession - creates a new
- session and copies the existing session attributes to the new session. This is the
- default.none - Don't do
- anything. The original session will be
- retained.newSession - Create
- a new "clean" session, without copying the existing session
- data.
+ <session-management>, which has three options
+
+ migrateSession - creates a new session and copies the
+ existing session attributes to the new session. This is the default.
+
+
+ none - Don't do anything. The original session will be
+ retained.
+
+
+ newSession - Create a new "clean" session, without copying
+ the existing session data.
+
+
@@ -478,15 +505,18 @@
]]> You should then register yourself with an OpenID provider (such as
myopenid.com), and add the user information to your in-memory
- <user-service>:
+ <user-service> :
]]> You should be able to login using the myopenid.com site to
authenticate. It is also possible to select a specific
UserDetailsService bean for use OpenID by setting the
user-service-ref attribute on the openid-login
element. See the previous section on authentication
- providers for more information.
+ providers for more information. Note that we have omitted the password attribute
+ from the above user configuration, since this set of user data is only being used to load
+ the authorities for the user. A random password will be generate internally, preventing you
+ from accidentally using this user data as an authentication source elsewhere in your
+ configuration.
Adding in Your Own Filters
@@ -502,48 +532,112 @@
The order of the filters is always strictly enforced when using the namespace. When the
application context is being created, the filter beans are sorted by the namespace handling
code and the standard Spring Security filters each have an alias in the namespace and a
- well-known position.In previous versions, the sorting took place after the
- filter instances had been created, during post-processing of the application context. In
- version 3.0+ the sorting is now done at the bean metadata level, before the classes have
- been instantiated. This has implications for how you add your own filters to the stack
- as the entire filter list must be known during the parsing of the
- <http> element, so the syntax has changed slightly in
- 3.0.The filters, aliases and namespace elements/attributes which create
- the filters are shown in . The filters are listed in the order
- in which they occur in the filter chain.
- You can add your own filter to the stack, using the custom-filter element
- and one of these names to specify the position your filter should appear at:
+ In previous versions, the sorting took place after the filter instances had been
+ created, during post-processing of the application context. In version 3.0+ the sorting
+ is now done at the bean metadata level, before the classes have been instantiated. This
+ has implications for how you add your own filters to the stack as the entire filter list
+ must be known during the parsing of the <http> element, so the
+ syntax has changed slightly in 3.0.
+ The filters, aliases and namespace elements/attributes which create the filters are
+ shown in . The filters are listed in the order in which they
+ occur in the filter chain.
You can add your own filter to the stack, using the
+ custom-filter element and one of these names to specify the position
+ your filter should appear at:
diff --git a/docs/manual/src/docbook/technical-overview.xml b/docs/manual/src/docbook/technical-overview.xml
index 86c448a913..6d3e13d698 100644
--- a/docs/manual/src/docbook/technical-overview.xml
+++ b/docs/manual/src/docbook/technical-overview.xml
@@ -547,7 +547,12 @@ Successfully authenticated. Security context contains: \
anyone who has a GrantedAuthority matching either of these
two attributes will be allowed access. Strictly speaking though, they are just attributes
and the interpretation is dependent on the
- AccessDecisionManager implementation.
+ AccessDecisionManager implementation. The use of the
+ prefix ROLE_ is a marker to indicate that these attributes are roles
+ and should be consumed by Spring Security's RoleVoter. This is only
+ relevant when a voter-based AccessDecisionManager is in
+ use. We'll see how the AccessDecisionManager is
+ implemented in the authorization chapter.
RunAsManager