|
|
|
|
@ -9,8 +9,8 @@
@@ -9,8 +9,8 @@
|
|
|
|
|
<para> Namespace configuration has been available since version 2.0 of the Spring framework. It |
|
|
|
|
allows you to supplement the traditional Spring beans application context syntax with elements |
|
|
|
|
from additional XML schema. You can find more information in the Spring <link |
|
|
|
|
xlink:href="http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/apc.html"> |
|
|
|
|
Reference Documentation</link>. A namespace element can be used simply to allow a more |
|
|
|
|
xlink:href="http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/apc.html" |
|
|
|
|
> Reference Documentation</link>. A namespace element can be used simply to allow a more |
|
|
|
|
concise way of configuring an individual bean or, more powerfully, to define an alternative |
|
|
|
|
configuration syntax which more closely matches the problem domain and hides the underlying |
|
|
|
|
complexity from the user. A simple element may conceal the fact that multiple beans and |
|
|
|
|
@ -21,13 +21,13 @@
@@ -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,28 +61,44 @@
@@ -61,28 +61,44 @@
|
|
|
|
|
<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 these work together in the following sections.</para> |
|
|
|
|
<para>We'll see how to configure these in the following sections.</para> |
|
|
|
|
</section> |
|
|
|
|
</section> |
|
|
|
|
<section xml:id="ns-getting-started"> |
|
|
|
|
@ -91,8 +107,8 @@
@@ -91,8 +107,8 @@
|
|
|
|
|
of the main features of the framework. Let's assume you initially want to get up and running |
|
|
|
|
as quickly as possible and add authentication support and access control to an existing web |
|
|
|
|
application, with a few test logins. Then we'll look at how to change over to authenticating |
|
|
|
|
against a database or other security information repository. In later sections we'll introduce |
|
|
|
|
more advanced namespace configuration options. </para> |
|
|
|
|
against a database or other security repository. In later sections we'll introduce more |
|
|
|
|
advanced namespace configuration options. </para> |
|
|
|
|
<section xml:id="ns-web-xml"> |
|
|
|
|
<title><literal>web.xml</literal> Configuration</title> |
|
|
|
|
<para> The first thing you need to do is add the following filter declaration to your |
|
|
|
|
@ -124,12 +140,28 @@
@@ -124,12 +140,28 @@
|
|
|
|
|
</http> |
|
|
|
|
]]> |
|
|
|
|
</programlisting> Which says that we want all URLs within our application to be secured, |
|
|
|
|
requiring the role <literal>ROLE_USER</literal> to access them.</para> |
|
|
|
|
requiring the role <literal>ROLE_USER</literal> to access them. The |
|
|
|
|
<literal><http></literal> element is the parent for all web-related namespace |
|
|
|
|
functionality. The <literal><intercept-url></literal> element defines a |
|
|
|
|
<literal>pattern</literal> which is matched against the URLs of incoming requests using an |
|
|
|
|
ant path style syntax. The <literal>access</literal> 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 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> |
|
|
|
|
<note> |
|
|
|
|
<para>You can use multiple <literal><intercept-url></literal> elements to define |
|
|
|
|
different access requirements for different sets of URLs, but they will be evaluated in |
|
|
|
|
the order listed and the first match will be used. So you must put the most specific |
|
|
|
|
matches at the top.</para> |
|
|
|
|
matches at the top. You can also add a <literal>method</literal> attribute to limit the |
|
|
|
|
match to a particular HTTP method (<literal>GET</literal>, <literal>POST</literal>, |
|
|
|
|
<literal>PUT</literal> etc.). For a pattern defined both with and without a method, the |
|
|
|
|
method-specific match will take precedence regardless of ordering. </para> |
|
|
|
|
</note> |
|
|
|
|
<para> To add some users, you can define a set of test data directly in the namespace: <programlisting language="xml"><![CDATA[ |
|
|
|
|
<authentication-manager> |
|
|
|
|
@ -144,10 +176,10 @@
@@ -144,10 +176,10 @@
|
|
|
|
|
</programlisting></para> |
|
|
|
|
<sidebar> |
|
|
|
|
<para>If you are familiar with pre-namespace versions of the framework, you can probably |
|
|
|
|
already guess roughly what's going on here. The <http> element is responsible for |
|
|
|
|
creating a <classname>FilterChainProxy</classname> and the filter beans which it uses. |
|
|
|
|
Common issues like incorrect filter ordering are no longer an issue as the filter |
|
|
|
|
positions are predefined.</para> |
|
|
|
|
already guess roughly what's going on here. The <literal><http></literal> element is |
|
|
|
|
responsible for creating a <classname>FilterChainProxy</classname> and the filter beans |
|
|
|
|
which it uses. Common problems like incorrect filter ordering are no longer an issue as |
|
|
|
|
the filter positions are predefined.</para> |
|
|
|
|
<para>The <literal><authentication-provider></literal> element creates a |
|
|
|
|
<classname>DaoAuthenticationProvider</classname> bean and the |
|
|
|
|
<literal><user-service></literal> element creates an |
|
|
|
|
@ -185,14 +217,15 @@
@@ -185,14 +217,15 @@
|
|
|
|
|
<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><http></literal> configuration, so the <literal><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><http></literal> configuration, so the |
|
|
|
|
<literal><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> |
|
|
|
|
@ -213,13 +246,16 @@
@@ -213,13 +246,16 @@
|
|
|
|
|
</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> for more |
|
|
|
|
details.</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"/> |
|
|
|
|
@ -228,9 +264,12 @@
@@ -228,9 +264,12 @@
|
|
|
|
|
<form-login login-page='/login.jsp'/> |
|
|
|
|
</http> |
|
|
|
|
]]> |
|
|
|
|
</programlisting> Note that these requests will be completely oblivious to Spring |
|
|
|
|
Security, so you will not be able to access information on the current user or call |
|
|
|
|
secured methods during the request. </para> |
|
|
|
|
</programlisting>It's important to realise that these requests will be completely |
|
|
|
|
oblivious to any further Spring Security web-related configuration or additional |
|
|
|
|
attributes such as <literal>requires-channel</literal>, so you will not be able to access |
|
|
|
|
information on the current user or call secured methods during the request. Use |
|
|
|
|
<literal>access='IS_AUTHENTICATED_ANONYMOUSLY'</literal> as an alternative if you still |
|
|
|
|
want the security filter chain to be applied.</para> |
|
|
|
|
<para>If you want to use basic authentication instead of form login, then change the |
|
|
|
|
configuration to <programlisting language="xml"><![CDATA[ |
|
|
|
|
<http auto-config='true'> |
|
|
|
|
@ -282,7 +321,7 @@
@@ -282,7 +321,7 @@
|
|
|
|
|
</authentication-provider> |
|
|
|
|
</authentication-manager> |
|
|
|
|
]]> |
|
|
|
|
</programlisting> Where "securityDataSource" is the name of a |
|
|
|
|
</programlisting> Where <quote>securityDataSource</quote> is the name of a |
|
|
|
|
<classname>DataSource</classname> bean in the application context, pointing at a database |
|
|
|
|
containing the standard Spring Security <link xlink:href="#db_schema_users_authorities">user |
|
|
|
|
data tables</link>. Alternatively, you could configure a Spring Security |
|
|
|
|
@ -437,14 +476,20 @@
@@ -437,14 +476,20 @@
|
|
|
|
|
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><session-management></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><session-management></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"> |
|
|
|
|
@ -481,48 +526,112 @@
@@ -481,48 +526,112 @@
|
|
|
|
|
<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><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><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> |
|
|
|
|
@ -569,10 +678,10 @@
@@ -569,10 +678,10 @@
|
|
|
|
|
<para>From version 2.0 onwards Spring Security has improved support substantially for adding |
|
|
|
|
security to your service layer methods. It provides support for JSR-250 security as well as |
|
|
|
|
the framework's original <literal>@Secured</literal> annotation. From 3.0 you can also make |
|
|
|
|
use of new <link xlink:href="el-access">expression-based annotations</link>. |
|
|
|
|
You can apply security to a single bean, using the |
|
|
|
|
<literal>intercept-methods</literal> element to decorate the bean declaration, or you can |
|
|
|
|
secure multiple beans across the entire service layer using the AspectJ style pointcuts. </para> |
|
|
|
|
use of new <link xlink:href="el-access">expression-based annotations</link>. You can apply |
|
|
|
|
security to a single bean, using the <literal>intercept-methods</literal> element to decorate |
|
|
|
|
the bean declaration, or you can secure multiple beans across the entire service layer using |
|
|
|
|
the AspectJ style pointcuts. </para> |
|
|
|
|
<section xml:id="ns-global-method"> |
|
|
|
|
<title>The <literal><global-method-security></literal> Element</title> |
|
|
|
|
<para> This element is used to enable annotation-based security in your application (by |
|
|
|
|
@ -639,7 +748,7 @@
@@ -639,7 +748,7 @@
|
|
|
|
|
<para> This section assumes you have some knowledge of the underlying architecture for |
|
|
|
|
access-control within Spring Security. If you don't you can skip it and come back to it later, |
|
|
|
|
as this section is only really relevant for people who need to do some customization in order |
|
|
|
|
to use more than simple role based security. </para> |
|
|
|
|
to use more than simple role-based security. </para> |
|
|
|
|
<para> When you use a namespace configuration, a default instance of |
|
|
|
|
<interfacename>AccessDecisionManager</interfacename> is automatically registered for you and |
|
|
|
|
will be used for making access decisions for method invocations and web URL access, based on |
|
|
|
|
@ -648,7 +757,8 @@
@@ -648,7 +757,8 @@
|
|
|
|
|
annotation secured methods). </para> |
|
|
|
|
<para> The default strategy is to use an <classname>AffirmativeBased</classname> |
|
|
|
|
<interfacename>AccessDecisionManager</interfacename> with a <classname>RoleVoter</classname> |
|
|
|
|
and an <classname>AuthenticatedVoter</classname>. </para> |
|
|
|
|
and an <classname>AuthenticatedVoter</classname>. You can find out more about these in the |
|
|
|
|
chapter on <link xlink:href="authorization">authorization</link>.</para> |
|
|
|
|
<section xml:id="ns-custom-access-mgr"> |
|
|
|
|
<title>Customizing the AccessDecisionManager</title> |
|
|
|
|
<para> If you need to use a more complicated access control strategy then it is easy to set an |
|
|
|
|
@ -694,9 +804,9 @@
@@ -694,9 +804,9 @@
|
|
|
|
|
</bean> |
|
|
|
|
]]></programlisting></para> |
|
|
|
|
<para> Another common requirement is that another bean in the context may require a reference to |
|
|
|
|
the <interfacename>AuthenticationManager</interfacename>. You can easily |
|
|
|
|
register an alias for the <interfacename>AuthenticationManager</interfacename> and |
|
|
|
|
use this name elsewhere in your application context. <programlisting language="xml"><
Luke Taylor
16 years ago
