Cwikius-Spring
/
spring-security
mirror of https://github.com/spring-projects/spring-security.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

SEC-1343: ref manual typos

This commit is contained in:
Luke Taylor 2009-12-28 13:59:21 +00:00
parent 7e817b9640
commit 744ed95b51
13 changed files with 182 additions and 312 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/manual/src/docbook/anon-auth-provider.xml
View File

@ -78,7 +78,7 @@
it is possible for an authenticating client to construct the
<interfacename>Authentication</interfacename> object (such as with RMI
invocations), then a malicious client could submit an
<classname>AnonyousAuthenticationToken</classname> which it had created
<classname>AnonymousAuthenticationToken</classname> which it had created
itself (with chosen username and authority list). If the <literal>key</literal>
is guessable or can be found out, then the token would be accepted by the
anonymous provider. This isn't a problem with normal usage but if you are using
@ -132,7 +132,7 @@
the use of the <classname>AuthenticatedVoter</classname> which we will see in the <link
xlink:href="#authz-authenticated-voter">authorization chapter</link>. It uses an
<interfacename>AuthenticationTrustResolver</interfacename> to process this
particular configuration attribute and grant access to aonymous users. The
particular configuration attribute and grant access to anonymous users. The
<classname>AuthenticatedVoter</classname> approach is more powerful, since it allows
you to differentiate between anonymous, remember-me and fully-authenticated users. If
you don't need this functionality though, then you can stick with

2
docs/manual/src/docbook/appendix-namespace.xml
View File

@ -453,7 +453,7 @@
<section>
<title>The <literal>&lt;authentication-manager&gt;</literal> Element</title>
<para> Every Spring Security application which uses the namespace must have include this
element somewhere. It is resposible for registering the
element somewhere. It is responsible for registering the
<interfacename>AuthenticationManager</interfacename> which provides authentication
services to the application. It also allows you to define an alias name for the internal
instance for use in your own configuration. Its use is described in the <link

6
docs/manual/src/docbook/core-services.xml
View File

@ -77,8 +77,8 @@
<section xml:id="core-services-dao-provider">
<title><literal>DaoAuthenticationProvider</literal></title>
<para>The simplest <interfacename>AuthenticationProvider</interfacename> implemented by
Spring Security is <literal>DaoAuthenticationProvider</literal>, which is is also
one of the earliest supported by the framework. It leverages a
Spring Security is <literal>DaoAuthenticationProvider</literal>, which is also one
of the earliest supported by the framework. It leverages a
<interfacename>UserDetailsService</interfacename> (as a DAO) in order to lookup
the username, password and <interfacename>GrantedAuthority</interfacename>s. It
authenticates the user simply by comparing the password submitted in a
@ -206,7 +206,7 @@
<title>Password Encoding</title>
<para>Spring Security's <interfacename>PasswordEncoder</interfacename> interface is used to
support the use of passwords which are encoded in some way in persistent storage. This
will normally mean that the passwords are <quote>hashed</quote> using a digest alogirthm
will normally mean that the passwords are <quote>hashed</quote> using a digest algorithm
such as MD5 or SHA.</para>
<section>
<title>What is a hash?</title>

34
docs/manual/src/docbook/el-access.xml
View File

@ -15,7 +15,7 @@
Security uses specific classes for web and method security as the root object, in order
to provide built-in expressions and access to values such as the current
principal.</para>
<section xml:id="el-common-built-in">
<section xml:id="el-common-built-in">
<title>Common Built-In Expressions</title>
<para>The base class for expression root objects is
<classname>SecurityExpressionRoot</classname>. This provides some common
@ -79,8 +79,8 @@
</row>
<row>
<entry><literal>isFullyAuthenticated()</literal></entry>
<entry>Returns <literal>true</literal> if the user is not an anonyous or
a remember-me user</entry>
<entry>Returns <literal>true</literal> if the user is not an anonymous
or a remember-me user</entry>
</row>
</tbody>
</tgroup>
@ -121,7 +121,7 @@
<para>Method security is a bit more complicated than a simple allow or deny rule. Spring
Security 3.0 introduced some new annotations in order to allow comprehensive support for
the use of expressions.</para>
<section xml:id="el-pre-post-annotations">
<section xml:id="el-pre-post-annotations">
<title><literal>@Pre</literal> and <literal>@Post</literal> Annotations</title>
<para>There are four annotations which support expression attributes to allow pre and
post-invocation authorization checks and also to support filtering of submitted
@ -147,13 +147,13 @@
we're actually using a method argument as part of the expression to decide
whether the current user has the <quote>admin</quote>permission for the given
contact. The built-in <literal>hasPermission()</literal> expression is linked
into the Spring Security ACL module through the application context, as we'll
<link xlink:href="#el-permission-evaluator">see
below</link>. You can access any of the method arguments by name as expression variables, provided
your code has debug information compiled in. Any Spring-EL functionality is
available within the expression, so you can also access properties on the
arguments. For example, if you wanted a particular method to only allow access
to a user whose username matched that of the contact, you could write</para>
into the Spring Security ACL module through the application context, as we'll
<link xlink:href="#el-permission-evaluator">see below</link>. You can access
any of the method arguments by name as expression variables, provided your code
has debug information compiled in. Any Spring-EL functionality is available
within the expression, so you can also access properties on the arguments. For
example, if you wanted a particular method to only allow access to a user whose
username matched that of the contact, you could write</para>
<programlisting> @PreAuthorize("#contact.name == principal.name)")
public void doSomething(Contact contact);</programlisting>
<para>Here we are accessing another built–in expression, which is the
@ -196,7 +196,7 @@
we have already seen in use above. The <literal>filterTarget</literal> and
<literal>returnValue</literal> values are simple enough, but the use of the
<literal>hasPermission()</literal> expression warrants a closer look.</para>
<section xml:id="el-permission-evaluator">
<section xml:id="el-permission-evaluator">
<title>The <interfacename>PermissionEvaluator</interfacename> interface</title>
<para><literal>hasPermission()</literal> expressions are delegated to an instance of
<interfacename>PermissionEvaluator</interfacename>. It is intended to bridge
@ -220,18 +220,16 @@
long as it is consistent with how the permissions are loaded.</para>
<para>To use <literal>hasPermission()</literal> expressions, you have to explicitly
configure a <interfacename>PermissionEvaluator</interfacename> in your
application context. This would look something like
this:<programlisting language="xml"> <![CDATA[ <security:global-method-security pre-post-annotations="enabled">
application context. This would look something like this:<programlisting language="xml"> <![CDATA[ <security:global-method-security pre-post-annotations="enabled">
<security:expression-handler ref="expressionHandler"/>
</security:global-method-security>
<bean id="expressionHandler"
class="org.springframework.security.access.expression.method.DefaultMethodSecurityExpressionHandler">
<property name="permissionEvaluator" ref="myPermissionEvaluator"/>
</bean>]]></programlisting>Where
<literal>myPermissionEvaluator</literal> is the bean which implements
<interfacename>PermissionEvaluator</interfacename>. Usually this will be the
implementation from the ACL module which is called
</bean>]]></programlisting>Where <literal>myPermissionEvaluator</literal> is the bean which
implements <interfacename>PermissionEvaluator</interfacename>. Usually this will
be the implementation from the ACL module which is called
<classname>AclPermissionEvaluator</classname>. See the
<quote>Contacts</quote> sample application configuration for more
details.</para>

8
docs/manual/src/docbook/introduction.xml
View File

@ -21,10 +21,10 @@
customisable security features.</para>
<para>As you probably know two major areas of application security are
<quote>authentication</quote> and <quote>authorization</quote> (or
<quote>access-control</quote>). These are the the two main areas that Spring
Security targets. <quote>Authentication</quote> is the process of establishing a
principal is who they claim to be (a <quote>principal</quote> generally means a user,
device or some other system which can perform an action in your application).
<quote>access-control</quote>). These are the two main areas that Spring Security
targets. <quote>Authentication</quote> is the process of establishing a principal is who
they claim to be (a <quote>principal</quote> generally means a user, device or some
other system which can perform an action in your application).
<quote>Authorization</quote> refers to the process of deciding whether a principal
is allowed to perform an action within your application. To arrive at the point where an
authorization decision is needed, the identity of the principal has already been

2
docs/manual/src/docbook/jaas-auth-provider.xml
View File

@ -80,7 +80,7 @@ JAASTest {
internal mechanics.</para>
<para>For those needing full control over the callback behavior,
internally <literal>JaasAutheticationProvider</literal> wraps these
internally <literal>JaasAuthenticationProvider</literal> wraps these
<literal>JaasAuthenticationCallbackHandler</literal>s with an
<literal>InternalCallbackHandler</literal>. The
<literal>InternalCallbackHandler</literal> is the class that

4
docs/manual/src/docbook/ldap-auth-provider.xml
View File

@ -254,7 +254,7 @@
<info>
<title>LDAP Search Objects</title>
</info>
<para>Often more a more complicated strategy than simple DN-matching is required to
<para>Often a more complicated strategy than simple DN-matching is required to
locate a user entry in the directory. This can be encapsulated in an
<interfacename>LdapUserSearch</interfacename> instance which can be supplied to
the authenticator implementations, for example, to allow them to locate a user. The
@ -372,7 +372,7 @@ public interface UserDetailsContextMapper {
parameter is the name used to authenticate and the final parameter is the collection
of authorities loaded for the user. </para>
<para> The way the context data is loaded varies slightly depending on the type of
authentication you are using. With the <classname>BindAuthenticatior</classname>,
authentication you are using. With the <classname>BindAuthenticator</classname>,
the context returned from the bind operation will be used to read the attributes,
otherwise the data will be read using the standard context obtained from the
configured <interfacename>ContextSource</interfacename> (when a search is configured

276
docs/manual/src/docbook/namespace-config.xml
View File

@ -21,13 +21,13 @@
]]></programlisting> 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 <literal>ldap-server</literal> element and the user is isolated from worrying about which
beans they need to create and what the bean property names are. <footnote>
<para>You can find out more about the use of the <literal>ldap-server</literal> element in
the chapter on <link xlink:href="#ldap">LDAP</link>.</para>
</footnote>. 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 <link xlink:href="http://www.springsource.com/products/sts">SpringSource Tool
Suite</link> as it has special features for working with standard Spring namespaces. </para>
beans they need to create and what the bean property names are. <footnote><para>You can find
out more about the use of the <literal>ldap-server</literal> element in the chapter on
<link xlink:href="#ldap">LDAP</link>.</para></footnote>. 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 <link
xlink:href="http://www.springsource.com/products/sts">SpringSource Tool Suite</link> as it
has special features for working with standard Spring namespaces. </para>
<para> 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: <programlisting language="xml">
<![CDATA[
@ -61,41 +61,25 @@
<para> 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: <itemizedlist>
<listitem>
<para>
following areas: <itemizedlist><listitem><para>
<emphasis>Web/HTTP Security</emphasis> - 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.</para>
</listitem>
<listitem>
<para>
secure URLs, render login and error pages and much
more.</para></listitem><listitem><para>
<emphasis>Business Object (Method) Security</emphasis> - options for securing the
service layer.</para>
</listitem>
<listitem>
<para>
service layer.</para></listitem><listitem><para>
<emphasis>AuthenticationManager</emphasis> - handles authentication requests from
other parts of the framework.</para>
</listitem>
<listitem>
<para>
other parts of the framework.</para></listitem><listitem><para>
<emphasis>AccessDecisionManager</emphasis> - 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.</para>
</listitem>
<listitem>
<para>
custom one, declared using normal Spring bean
syntax.</para></listitem><listitem><para>
<emphasis>AuthenticationProvider</emphasis>s - 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. </para>
</listitem>
<listitem>
<para>
traditional syntax. </para></listitem><listitem><para>
<emphasis>UserDetailsService</emphasis> - closely related to authentication providers,
but often also required by other beans.</para>
</listitem>
but often also required by other beans.</para></listitem>
<!-- todo: diagram and link to other sections which describe the interfaces -->
</itemizedlist></para>
<para>We'll see how to configure these in the following sections.</para>
@ -151,12 +135,12 @@
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<footnote>
<para>The interpretation of the comma-separated values in the <literal>access</literal>
attribute depends on the implementation of the <link xlink:href="#ns-access-manager"
attributes). We'll see later how the interpretation can vary<footnote><para>The
interpretation of the comma-separated values in the <literal>access</literal> attribute
depends on the implementation of the <link xlink:href="#ns-access-manager"
>AccessDecisionManager</link> which is used. In Spring Security 3.0, the attribute can
also be populated with an <link xlink:href="#el-access">EL expression</link>.</para>
</footnote>.</para>
also be populated with an <link xlink:href="#el-access">EL
expression</link>.</para></footnote>.</para>
<note>
<para>You can use multiple <literal>&lt;intercept-url&gt;</literal> elements to define
different access requirements for different sets of URLs, but they will be evaluated in
@ -220,15 +204,14 @@
<logout />
</http>
]]></programlisting> These other elements are responsible for setting up form-login, basic
authentication and logout handling services respectively <footnote>
<para>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 <classname>AnonymousAuthenticationFilter</classname> is part
of the default <literal>&lt;http></literal> configuration, so the
<literal>&lt;anonymous /></literal> element is added regardless of whether
<literal>auto-config</literal> is enabled.</para>
</footnote> . They each have attributes which can be used to alter their behaviour.
</para>
authentication and logout handling services respectively <footnote><para>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 <classname>AnonymousAuthenticationFilter</classname> is part of the default
<literal>&lt;http></literal> configuration, so the <literal>&lt;anonymous
/></literal> element is added regardless of whether <literal>auto-config</literal>
is enabled.</para></footnote> . They each have attributes which can be used to alter
their behaviour. </para>
</section>
<section xml:id="ns-form-and-basic">
<title>Form and Basic Login Options</title>
@ -249,16 +232,15 @@
</programlisting> Note that you can still use <literal>auto-config</literal>. The
<literal>form-login</literal> element just overrides the default settings. Also note
that we've added an extra <literal>intercept-url</literal> element to say that any
requests for the login page should be available to anonymous users <footnote>
<para>See the chapter on <link xlink:href="#anonymous">anonymous authentication</link>
and also the <link xlink:href="#authz-authenticated-voter">AuthenticatedVoter</link>
class for more details on how the value
<literal>IS_AUTHENTICATED_ANONYMOUSLY</literal> is processed.</para>
</footnote>. Otherwise the request would be matched by the pattern <literal>/**</literal>
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 <footnote><para>See the
chapter on <link xlink:href="#anonymous">anonymous authentication</link> and also the
<link xlink:href="#authz-authenticated-voter">AuthenticatedVoter</link> class for
more details on how the value <literal>IS_AUTHENTICATED_ANONYMOUSLY</literal> is
processed.</para></footnote>. Otherwise the request would be matched by the pattern
<literal>/**</literal> 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: <programlisting language="xml"><![CDATA[
<http auto-config='true'>
<intercept-url pattern="/css/**" filters="none"/>
@ -479,20 +461,14 @@
logs in. If you don't require this protection, or it conflicts with some other
requirement, you can control the behaviour using the
<literal>session-fixation-protection</literal> attribute on
<literal>&lt;session-management&gt;</literal>, which has three options <itemizedlist>
<listitem>
<para><literal>migrateSession</literal> - creates a new session and copies the
existing session attributes to the new session. This is the default.</para>
</listitem>
<listitem>
<para><literal>none</literal> - Don't do anything. The original session will be
retained.</para>
</listitem>
<listitem>
<para><literal>newSession</literal> - Create a new "clean" session, without copying
the existing session data.</para>
</listitem>
</itemizedlist></para>
<literal>&lt;session-management&gt;</literal>, which has three options
<itemizedlist><listitem><para><literal>migrateSession</literal> - creates a new
session and copies the existing session attributes to the new session. This is the
default.</para></listitem><listitem><para><literal>none</literal> - Don't do
anything. The original session will be
retained.</para></listitem><listitem><para><literal>newSession</literal> - Create
a new "clean" session, without copying the existing session
data.</para></listitem></itemizedlist></para>
</section>
</section>
<section xml:id="ns-openid">
@ -558,112 +534,48 @@ List&lt;OpenIDAttribute> attributes = token.getAttributes();</programlisting>The
<para>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.<note>
<para>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 <literal>&lt;http></literal> element, so the
syntax has changed slightly in 3.0.</para>
</note>The filters, aliases and namespace elements/attributes which create the filters are
shown in <xref linkend="filter-stack"/>. The filters are listed in the order in which they
occur in the filter chain. <table xml:id="filter-stack">
<title>Standard Filter Aliases and Ordering</title>
<tgroup cols="3" align="left">
<thead>
<row>
<entry align="center">Alias</entry>
<entry align="center">Filter Class</entry>
<entry align="center">Namespace Element or Attribute</entry>
</row>
</thead>
<tbody>
<row>
<entry> CHANNEL_FILTER</entry>
<entry><literal>ChannelProcessingFilter</literal></entry>
<entry><literal>http/intercept-url@requires-channel</literal></entry>
</row>
<row>
<entry> CONCURRENT_SESSION_FILTER</entry>
<entry><literal>ConcurrentSessionFilter</literal>
</entry>
<entry><literal>session-management/concurrency-control</literal></entry>
</row>
<row>
<entry> SECURITY_CONTEXT_FILTER</entry>
<entry><classname>SecurityContextPersistenceFilter</classname></entry>
<entry><literal>http</literal></entry>
</row>
<row>
<entry> LOGOUT_FILTER </entry>
<entry><literal>LogoutFilter</literal></entry>
<entry><literal>http/logout</literal></entry>
</row>
<row>
<entry> X509_FILTER </entry>
<entry><literal>X509AuthenticationFilter</literal></entry>
<entry><literal>http/x509</literal></entry>
</row>
<row>
<entry> PRE_AUTH_FILTER </entry>
<entry><literal>AstractPreAuthenticatedProcessingFilter</literal> Subclasses</entry>
<entry>N/A</entry>
</row>
<row>
<entry> CAS_FILTER </entry>
<entry><literal>CasAuthenticationFilter</literal></entry>
<entry>N/A</entry>
</row>
<row>
<entry> FORM_LOGIN_FILTER </entry>
<entry><literal>UsernamePasswordAuthenticationFilter</literal></entry>
<entry><literal>http/form-login</literal></entry>
</row>
<row>
<entry> BASIC_AUTH_FILTER </entry>
<entry><literal>BasicAuthenticationFilter</literal></entry>
<entry><literal>http/http-basic</literal></entry>
</row>
<row>
<entry> SERVLET_API_SUPPORT_FILTER</entry>
<entry><literal>SecurityContextHolderAwareFilter</literal></entry>
<entry><literal>http/@servlet-api-provision</literal></entry>
</row>
<row>
<entry> REMEMBER_ME_FILTER </entry>
<entry><classname>RememberMeAuthenticationFilter</classname></entry>
<entry><literal>http/remember-me</literal></entry>
</row>
<row>
<entry> ANONYMOUS_FILTER </entry>
<entry><literal>AnonymousAuthenticationFilter</literal></entry>
<entry><literal>http/anonymous</literal></entry>
</row>
<row>
<entry> SESSION_MANAGEMENT_FILTER</entry>
<entry><literal>SessionManagementFilter</literal></entry>
<entry><literal>session-management</literal></entry>
</row>
<row>
<entry>EXCEPTION_TRANSLATION_FILTER </entry>
<entry><classname>ExceptionTranslationFilter</classname></entry>
<entry><literal>http</literal></entry>
</row>
<row>
<entry> FILTER_SECURITY_INTERCEPTOR </entry>
<entry><classname>FilterSecurityInterceptor</classname></entry>
<entry><literal>http</literal></entry>
</row>
<row>
<entry> SWITCH_USER_FILTER </entry>
<entry><literal>SwitchUserFilter</literal></entry>
<entry>N/A</entry>
</row>
</tbody>
</tgroup>
</table> You can add your own filter to the stack, using the
<literal>custom-filter</literal> element and one of these names to specify the position
your filter should appear at: <programlisting language="xml"><![CDATA[
well-known position.<note><para>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
<literal>&lt;http></literal> element, so the syntax has changed slightly in
3.0.</para></note>The filters, aliases and namespace elements/attributes which create
the filters are shown in <xref linkend="filter-stack"/>. The filters are listed in the order
in which they occur in the filter chain. <table xml:id="filter-stack"><title>Standard Filter
Aliases and Ordering</title><tgroup cols="3" align="left"><thead><row><entry
align="center">Alias</entry><entry align="center">Filter Class</entry><entry
align="center">Namespace Element or
Attribute</entry></row></thead><tbody><row><entry>
CHANNEL_FILTER</entry><entry><literal>ChannelProcessingFilter</literal></entry><entry><literal>http/intercept-url@requires-channel</literal></entry></row><row><entry>
CONCURRENT_SESSION_FILTER</entry><entry><literal>ConcurrentSessionFilter</literal>
</entry><entry><literal>session-management/concurrency-control</literal></entry></row><row><entry>
SECURITY_CONTEXT_FILTER</entry><entry><classname>SecurityContextPersistenceFilter</classname></entry><entry><literal>http</literal></entry></row><row><entry>
LOGOUT_FILTER
</entry><entry><literal>LogoutFilter</literal></entry><entry><literal>http/logout</literal></entry></row><row><entry>
X509_FILTER
</entry><entry><literal>X509AuthenticationFilter</literal></entry><entry><literal>http/x509</literal></entry></row><row><entry>
PRE_AUTH_FILTER
</entry><entry><literal>AstractPreAuthenticatedProcessingFilter</literal>
Subclasses</entry><entry>N/A</entry></row><row><entry> CAS_FILTER
</entry><entry><literal>CasAuthenticationFilter</literal></entry><entry>N/A</entry></row><row><entry>
FORM_LOGIN_FILTER
</entry><entry><literal>UsernamePasswordAuthenticationFilter</literal></entry><entry><literal>http/form-login</literal></entry></row><row><entry>
BASIC_AUTH_FILTER
</entry><entry><literal>BasicAuthenticationFilter</literal></entry><entry><literal>http/http-basic</literal></entry></row><row><entry>
SERVLET_API_SUPPORT_FILTER</entry><entry><literal>SecurityContextHolderAwareFilter</literal></entry><entry><literal>http/@servlet-api-provision</literal></entry></row><row><entry>
REMEMBER_ME_FILTER
</entry><entry><classname>RememberMeAuthenticationFilter</classname></entry><entry><literal>http/remember-me</literal></entry></row><row><entry>
ANONYMOUS_FILTER
</entry><entry><literal>AnonymousAuthenticationFilter</literal></entry><entry><literal>http/anonymous</literal></entry></row><row><entry>
SESSION_MANAGEMENT_FILTER</entry><entry><literal>SessionManagementFilter</literal></entry><entry><literal>session-management</literal></entry></row><row><entry>EXCEPTION_TRANSLATION_FILTER
</entry><entry><classname>ExceptionTranslationFilter</classname></entry><entry><literal>http</literal></entry></row><row><entry>
FILTER_SECURITY_INTERCEPTOR
</entry><entry><classname>FilterSecurityInterceptor</classname></entry><entry><literal>http</literal></entry></row><row><entry>
SWITCH_USER_FILTER
</entry><entry><literal>SwitchUserFilter</literal></entry><entry>N/A</entry></row></tbody></tgroup></table>
You can add your own filter to the stack, using the <literal>custom-filter</literal> element
and one of these names to specify the position your filter should appear at: <programlisting language="xml"><![CDATA[
<http>
<custom-filter position="FORM_LOGIN_FILTER" ref="myFilter" />
</http>
@ -815,12 +727,12 @@ List&lt;OpenIDAttribute> attributes = token.getAttributes();</programlisting>The
<para> The main interface which provides authentication services in Spring Security is the
<interfacename>AuthenticationManager</interfacename>. This is usually an instance of Spring
Security's <classname>ProviderManager</classname> class, which you may already be familiar
with if you've used the framework before. If not, it will be covered later, in <link
xlink:href="#tech-intro-authentication"/>. The bean instance is registered using the
<literal>authentication-manager</literal> namespace element. You can't use a custom
<classname>AuthenticationManager</classname> if you are using either HTTP or method security
through the namespace, but this should not be a problem as you have full control over the
<classname>AuthenticationProvider</classname>s that are used.</para>
with if you've used the framework before. If not, it will be covered later, in the <link
xlink:href="#tech-intro-authentication">technical overview chapter</link>. The bean instance
is registered using the <literal>authentication-manager</literal> namespace element. You can't
use a custom <classname>AuthenticationManager</classname> if you are using either HTTP or
method security through the namespace, but this should not be a problem as you have full
control over the <classname>AuthenticationProvider</classname>s that are used.</para>
<para> You may want to register additional <classname>AuthenticationProvider</classname> beans
with the <classname>ProviderManager</classname> and you can do this using the
<literal>&lt;authentication-provider&gt;</literal> element with the <literal>ref</literal>

8
docs/manual/src/docbook/preauth.xml
View File

@ -26,7 +26,7 @@
in a structured fashion, without having to write everything from scratch. You don't need to
know about these classes if you want to use something like <link xlink:href="#x509">X.509
authentication</link>, as it already has a namespace configuration option which is simpler
to use and get started with. If you need to use explicit bean confiuration or are planning on
to use and get started with. If you need to use explicit bean configuration or are planning on
writing your own implementation then an understanding of how the provided implementations work
will be useful. You will find classes under the
<package>org.springframework.security.web.authentication.preauth</package>. We just provide
@ -122,7 +122,7 @@
<section>
<title>Request-Header Authentication (Siteminder)</title>
<para> An external authentication system may supply information to the application by setting
specific headers on the HTTP request. A well known example of this is is Siteminder, which
specific headers on the HTTP request. A well known example of this is Siteminder, which
passes the username in a header called <literal>SM_USER</literal>. This mechanism is
supported by the class <classname>RequestHeaderAuthenticationFilter</classname> which simply
extracts the username from the header. It defaults to using the name
@ -132,7 +132,7 @@
checks at all and it is <emphasis>extremely</emphasis> important that the external system
is configured properly and protects all access to the application. If an attacker is able
to forge the headers in their original request without this being detected then they could
potentially choose any userame they wished. </para>
potentially choose any username they wished. </para>
</tip>
<section>
<title>Siteminder Example Configuration</title>
@ -177,7 +177,7 @@ class="org.springframework.security.web.authentication.preauth.PreAuthenticatedA
<title>J2EE Container Authentication</title>
<para> The class <classname>J2eePreAuthenticatedProcessingFilter</classname> will extract the
username from the <literal>userPrincipal</literal> property of the
<interfacename>HttpServletRequest</interfacename>. use of this filter would usually be
<interfacename>HttpServletRequest</interfacename>. Use of this filter would usually be
combined with the use of J2EE roles as described above in <xref
linkend="j2ee-preauth-details"/>. </para>
<para> There is a sample application in the codebase which uses this approach, so get hold of

29
docs/manual/src/docbook/remember-me-authentication.xml
View File

@ -64,12 +64,11 @@
<para>This approach is based on the article <link
xlink:href="http://jaspan.com/improved_persistent_login_cookie_best_practice"
>http://jaspan.com/improved_persistent_login_cookie_best_practice</link> with some
minor modifications <footnote>
<para>Essentially, the username is not included in the cookie, to prevent exposing a
valid login name unecessarily. There is a discussion on this in the comments
section of this article.</para>
</footnote>. To use the this approach with namespace configuration, you would supply a
datasource reference: <programlisting><![CDATA[
minor modifications <footnote><para>Essentially, the username is not included in the
cookie, to prevent exposing a valid login name unecessarily. There is a
discussion on this in the comments section of this article.</para></footnote>.
To use the this approach with namespace configuration, you would supply a datasource
reference: <programlisting><![CDATA[
<http>
...
<remember-me data-source-ref="someDataSource"/>
@ -110,7 +109,7 @@
authentication-related events, and delegates to the implementation whenever a candidate
web request might contain a cookie and wish to be remembered. This design allows any
number of remember-me implementation strategies. We've seen above that Spring Security
provides two implementations. We'll look at thes in turn.</para>
provides two implementations. We'll look at these in turn.</para>
<section>
<title>TokenBasedRememberMeServices</title>
<para> This implementation supports the simpler approach described in <xref
@ -162,16 +161,12 @@
<para> This class can be used in the same way as
<classname>TokenBasedRememberMeServices</classname>, but it additionally needs
to be configured with a <interfacename>PersistentTokenRepository</interfacename> to
store the tokens. There are two standard implementations. <itemizedlist>
<listitem>
<para><classname>InMemoryTokenRepositoryImpl</classname> which is intended
for testing only.</para>
</listitem>
<listitem>
<para><classname>JdbcTokenRepositoryImpl</classname> which stores the tokens
in a database. </para>
</listitem>
</itemizedlist> The database schema is described above in <xref
store the tokens. There are two standard implementations.
<itemizedlist><listitem><para><classname>InMemoryTokenRepositoryImpl</classname>
which is intended for testing
only.</para></listitem><listitem><para><classname>JdbcTokenRepositoryImpl</classname>
which stores the tokens in a database. </para></listitem></itemizedlist>
The database schema is described above in <xref
linkend="remember-me-persistent-token"/>. </para>
</section>
</section>

2
docs/manual/src/docbook/secured-objects.xml
View File

@ -24,7 +24,7 @@
<literal>&lt;intercept-methods&gt;</literal> or <literal>&lt;protect-point&gt;</literal>
elements. Other implementations will be used to handle annotation-based configuration. </para>
<section>
<title>Explicit MethodSecurityIterceptor Configuration</title>
<title>Explicit MethodSecurityInterceptor Configuration</title>
<para> You can of course configure a <classname>MethodSecurityIterceptor</classname> directly
in your application context for use with one of Spring AOP's proxying mechanisms: <programlisting><![CDATA[
<bean id="bankManagerSecurity"

2
docs/manual/src/docbook/session-mgmt.xml
View File

@ -13,7 +13,7 @@
<title>SessionManagementFilter</title>
<para>The <classname>SessionManagementFilter</classname> checks the contents of the
<interfacename>SecurityContextRepository</interfacename> against the current contents of the
<classname>SecurityContextHolder</classname> to deterine whether a user has been
<classname>SecurityContextHolder</classname> to determine whether a user has been
authenticated during the current request, typically by a non-interactive authentication
mechanism, such as pre-authentication or remember-me <footnote><para>Authentication by
mechanisms which perform a redirect after authenticating (such as form-login) will not be

117
docs/manual/src/docbook/technical-overview.xml
View File

@ -46,7 +46,7 @@
because of the specific way they work with threads. For example, a Swing client might want
all threads in a Java Virtual Machine to use the same security context.
<classname>SecurityContextHolder</classname> can be configured with a strategy on startup
to specify how you would like the contex to be stored. For a standalone application you
to specify how you would like the context to be stored. For a standalone application you
would use the <literal>SecurityContextHolder.MODE_GLOBAL</literal> strategy. Other
applications might want to have threads spawned by the secure thread also assume the same
security identity. This is achieved by using
@ -76,7 +76,7 @@ if (principal instanceof UserDetails) {
}</programlisting>
<para>The object returned by the call to <methodname>getContext()</methodname> is an
instance of the <interfacename>SecurityContext</interfacename> interface. This is the
object that is kept in thread-local storage. As we'll see below, Most authentication
object that is kept in thread-local storage. As we'll see below, most authentication
mechanisms withing Spring Security return an instance of
<interfacename>UserDetails</interfacename> as the principal. </para>
</section>
@ -189,50 +189,31 @@ if (principal instanceof UserDetails) {
own proprietary authentication system. </para>
<section>
<title>What is authentication in Spring Security?</title>
<para> Let's consider a standard authentication scenario that everyone is familiar with. <orderedlist>
<listitem>
<para>A user is prompted to log in with a username and password.</para>
</listitem>
<listitem>
<para>The system (successfully) verifies that the password is correct for the
username.</para>
</listitem>
<listitem>
<para>The context information for that user is obtained (their list of roles and so
on).</para>
</listitem>
<listitem>
<para>A security context is established for the user</para>
</listitem>
<listitem>
<para>The user proceeds, potentially to perform some operation which is potentially
protected by an access control mechanism which checks the required permissions for the
operation against the current security context information. </para>
</listitem>
</orderedlist> The first three items constitute the authentication process so we'll take a
look at how these take place within Spring Security.<orderedlist>
<listitem>
<para>The username and password are obtained and combined into an instance of
<para> Let's consider a standard authentication scenario that everyone is familiar with.
<orderedlist><listitem><para>A user is prompted to log in with a username and
password.</para></listitem><listitem><para>The system (successfully) verifies that the
password is correct for the username.</para></listitem><listitem><para>The context
information for that user is obtained (their list of roles and so
on).</para></listitem><listitem><para>A security context is established for the
user</para></listitem><listitem><para>The user proceeds, potentially to perform some
operation which is potentially protected by an access control mechanism which checks
the required permissions for the operation against the current security context
information. </para></listitem></orderedlist> The first three items constitute the
authentication process so we'll take a look at how these take place within Spring
Security.<orderedlist><listitem><para>The username and password are obtained and
combined into an instance of
<classname>UsernamePasswordAuthenticationToken</classname> (an instance of the
<interfacename>Authentication</interfacename> interface, which we saw
earlier).</para>
</listitem>
<listitem>
<para>The token is passed to an instance of
<interfacename>AuthenticationManager</interfacename> for validation.</para>
</listitem>
<listitem>
<para>The <interfacename>AuthenticationManager</interfacename> returns a fully populated
earlier).</para></listitem><listitem><para>The token is passed to an instance of
<interfacename>AuthenticationManager</interfacename> for
validation.</para></listitem><listitem><para>The
<interfacename>AuthenticationManager</interfacename> returns a fully populated
<interfacename>Authentication</interfacename> instance on successful
authentication.</para>
</listitem>
<listitem>
<para>The security context is established by calling
<code>SecurityContextHolder.getContext().setAuthentication(...)</code>, passing in
the returned authentication object.</para>
</listitem>
</orderedlist>From that point on, the user is considered to be authenticated. Let's look at
some code as an example.
authentication.</para></listitem><listitem><para>The security context is established
by calling <code>SecurityContextHolder.getContext().setAuthentication(...)</code>,
passing in the returned authentication object.</para></listitem></orderedlist>From
that point on, the user is considered to be authenticated. Let's look at some code as an
example.
<programlisting language="java">import org.springframework.security.authentication.*;
import org.springframework.security.core.*;
import org.springframework.security.core.authority.GrantedAuthorityImpl;
@ -375,7 +356,7 @@ Successfully authenticated. Security context contains: \
The main participants (in the order that they are used) are the
<classname>ExceptionTranslationFilter</classname>, an
<interfacename>AuthenticationEntryPoint</interfacename> and an <quote>authentication
mechanism</quote>, which is resposible for calling the
mechanism</quote>, which is responsible for calling the
<classname>AuthenticationManager</classname> which we saw in the previous section.</para>
<section>
<title>ExceptionTranslationFilter</title>
@ -461,7 +442,7 @@ Successfully authenticated. Security context contains: \
</section>
<section xml:id="tech-intro-access-control">
<title>Access-Control (Authorization) in Spring Security</title>
<para> The main interface resposible for making access-control decisions in Spring Security is
<para> The main interface responsible for making access-control decisions in Spring Security is
the <interfacename>AccessDecisionManager</interfacename>. It has a
<methodname>decide</methodname> method which takes an
<interfacename>Authentication</interfacename> object representing the principal requesting
@ -503,29 +484,17 @@ Successfully authenticated. Security context contains: \
<interfacename>Authentication</interfacename> if the principal has been
authenticated.</para>
<para><classname>AbstractSecurityInterceptor</classname> provides a consistent workflow for
handling secure object requests, typically: <orderedlist>
<listitem>
<para>Look up the <quote>configuration attributes</quote> associated with the present
request</para>
</listitem>
<listitem>
<para>Submitting the secure object, current
handling secure object requests, typically: <orderedlist><listitem><para>Look up the
<quote>configuration attributes</quote> associated with the present
request</para></listitem><listitem><para>Submitting the secure object, current
<interfacename>Authentication</interfacename> and configuration attributes to the
<interfacename>AccessDecisionManager</interfacename> for an authorization
decision</para>
</listitem>
<listitem>
<para>Optionally change the <interfacename>Authentication</interfacename> under which
the invocation takes place</para>
</listitem>
<listitem>
<para>Allow the secure object invocation to proceed (assuming access was granted)</para>
</listitem>
<listitem>
<para>Call the <interfacename>AfterInvocationManager</interfacename> if configured, once
the invocation has returned.</para>
</listitem>
</orderedlist></para>
decision</para></listitem><listitem><para>Optionally change the
<interfacename>Authentication</interfacename> under which the invocation takes
place</para></listitem><listitem><para>Allow the secure object invocation to proceed
(assuming access was granted)</para></listitem><listitem><para>Call the
<interfacename>AfterInvocationManager</interfacename> if configured, once the
invocation has returned.</para></listitem></orderedlist></para>
<section xml:id="tech-intro-config-attributes">
<title>What are Configuration Attributes?</title>
<para> A <quote>configuration attribute</quote> can be thought of as a String that has
@ -550,9 +519,9 @@ Successfully authenticated. Security context contains: \
<interfacename>AccessDecisionManager</interfacename> implementation. The use of the
prefix <literal>ROLE_</literal> is a marker to indicate that these attributes are roles
and should be consumed by Spring Security's <classname>RoleVoter</classname>. This is only
relevant when a voter-based <interfacename>AccessDecisionManager</interfacename> is in
use. We'll see how the <interfacename>AccessDecisionManager</interfacename> is
implemented in the <link xlink:href="authz-arch">authorization chapter</link>.</para>
relevant when a voter-based <interfacename>AccessDecisionManager</interfacename> is in
use. We'll see how the <interfacename>AccessDecisionManager</interfacename> is implemented
in the <link xlink:href="authz-arch">authorization chapter</link>.</para>
</section>
<section>
<title>RunAsManager</title>
@ -583,14 +552,10 @@ Successfully authenticated. Security context contains: \
or not change it in any way as it chooses.</para>
<para><classname>AbstractSecurityInterceptor</classname> and its related objects are shown
in <xref linkend="abstract-security-interceptor"/>. <figure
xml:id="abstract-security-interceptor">
<title>Security interceptors and the <quote>secure object</quote> model</title>
<mediaobject>
<imageobject>
xml:id="abstract-security-interceptor"><title>Security interceptors and the
<quote>secure object</quote> model</title><mediaobject><imageobject>
<imagedata align="center" fileref="images/security-interception.png" format="PNG"/>
</imageobject>
</mediaobject>
</figure></para>
</imageobject></mediaobject></figure></para>
</section>
<section>
<title>Extending the Secure Object Model</title>