Added information on config jar to instructions on getting started using namespace.
This commit is contained in:
Luke Taylor
parent
8df356de29
commit
8615369697
|
|
@ -10,8 +10,8 @@
|
|||
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 concise way of configuring an individual bean or, more powerfully, to define an
|
||||
> 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 processing steps are being added to the application context. For
|
||||
|
|
@ -22,15 +22,16 @@
|
|||
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>
|
||||
<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">
|
||||
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, you need to have
|
||||
the <literal>spring-security-config</literal> jar on your classpath. Then all you need
|
||||
to do is add the schema declaration to your application context file: <programlisting language="xml">
|
||||
<![CDATA[
|
||||
<beans xmlns="http://www.springframework.org/schema/beans"
|
||||
xmlns:security="http://www.springframework.org/schema/security"
|
||||
|
|
@ -64,39 +65,33 @@
|
|||
design is based around the large-scale dependencies within the framework, and can be
|
||||
divided up into the following areas: <itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<emphasis>Web/HTTP Security</emphasis> - the most complex part. Sets up
|
||||
<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>
|
||||
authentication mechanisms, to secure URLs, render login and error pages and
|
||||
much more.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<emphasis>Business Object (Method) Security</emphasis> - options for
|
||||
<para> <emphasis>Business Object (Method) Security</emphasis> - options for
|
||||
securing the service layer.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<emphasis>AuthenticationManager</emphasis> - handles authentication
|
||||
<para> <emphasis>AuthenticationManager</emphasis> - handles authentication
|
||||
requests from 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
|
||||
<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>
|
||||
<emphasis>AuthenticationProvider</emphasis>s - mechanisms against which
|
||||
<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>
|
||||
<emphasis>UserDetailsService</emphasis> - closely related to
|
||||
<para> <emphasis>UserDetailsService</emphasis> - closely related to
|
||||
authentication providers, but often also required by other beans.</para>
|
||||
</listitem>
|
||||
<!-- todo: diagram and link to other sections which describe the interfaces -->
|
||||
|
|
@ -129,12 +124,11 @@
|
|||
infrastructure. <classname>DelegatingFilterProxy</classname> is a Spring Framework
|
||||
class which delegates to a filter implementation which is defined as a Spring bean
|
||||
in your application context. In this case, the bean is named
|
||||
<quote>springSecurityFilterChain</quote>, which is an internal infrastructure
|
||||
bean created by the namespace to handle web security. Note that you should not use
|
||||
this bean name yourself. Once you've added this to your
|
||||
<filename>web.xml</filename>, you're ready to start editing your application context
|
||||
file. Web security services are configured using the <literal><http></literal>
|
||||
element. </para>
|
||||
<quote>springSecurityFilterChain</quote>, which is an internal infrastructure bean
|
||||
created by the namespace to handle web security. Note that you should not use this
|
||||
bean name yourself. Once you've added this to your <filename>web.xml</filename>,
|
||||
you're ready to start editing your application context file. Web security services
|
||||
are configured using the <literal><http></literal> element. </para>
|
||||
</section>
|
||||
<section xml:id="ns-minimal">
|
||||
<title>A Minimal <literal><http></literal> Configuration</title>
|
||||
|
|
@ -147,9 +141,9 @@
|
|||
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. You can also use regular-expression
|
||||
matching as an alternative (see the namespace appendix for more details). The
|
||||
<literal>pattern</literal> which is matched against the URLs of incoming requests
|
||||
using an ant path style syntax. You can also use regular-expression matching as an
|
||||
alternative (see the namespace appendix for more details). 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
|
||||
|
|
@ -160,10 +154,10 @@
|
|||
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">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>
|
||||
<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
|
||||
|
|
@ -209,8 +203,8 @@
|
|||
<para> The configuration above defines two users, their passwords and their roles within
|
||||
the application (which will be used for access control). It is also possible to load
|
||||
user information from a standard properties file using the
|
||||
<literal>properties</literal> attribute on <literal>user-service</literal>. See
|
||||
the section on <link xlink:href="#core-services-in-memory-service">in-memory
|
||||
<literal>properties</literal> attribute on <literal>user-service</literal>. See the
|
||||
section on <link xlink:href="#core-services-in-memory-service">in-memory
|
||||
authentication</link> for more details on the file format. Using the
|
||||
<literal><authentication-provider></literal> element means that the user
|
||||
information will be used by the authentication manager to process authentication
|
||||
|
|
@ -219,10 +213,10 @@
|
|||
turn.</para>
|
||||
<para> At this point you should be able to start up your application and you will be
|
||||
required to log in to proceed. Try it out, or try experimenting with the
|
||||
<quote>tutorial</quote> sample application that comes with the project. The
|
||||
above configuration actually adds quite a few services to the application because we
|
||||
have used the <literal>auto-config</literal> attribute. For example, form-based
|
||||
login processing is automatically enabled. </para>
|
||||
<quote>tutorial</quote> sample application that comes with the project. The above
|
||||
configuration actually adds quite a few services to the application because we have
|
||||
used the <literal>auto-config</literal> attribute. For example, form-based login
|
||||
processing is automatically enabled. </para>
|
||||
<section xml:id="ns-auto-config">
|
||||
<title>What does <literal>auto-config</literal> Include?</title>
|
||||
<para> The <literal>auto-config</literal> attribute, as we have used it above, is
|
||||
|
|
@ -237,13 +231,13 @@
|
|||
<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>
|
||||
<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. In anything other than very basic scenarios, it is probably better
|
||||
to omit the <literal>auto-config</literal> attribute and configure what you require
|
||||
behaviour. In anything other than very basic scenarios, it is probably better to
|
||||
omit the <literal>auto-config</literal> attribute and configure what you require
|
||||
explicitly in the interest of clarity.</para>
|
||||
</section>
|
||||
</section>
|
||||
|
|
@ -264,21 +258,20 @@
|
|||
</http>
|
||||
]]>
|
||||
</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>
|
||||
<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
|
||||
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
|
||||
<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, by defining a separate
|
||||
<literal>http</literal> element for the pattern like this: <programlisting language="xml"><![CDATA[
|
||||
particular pattern bypass the security filter chain completely, by defining a
|
||||
separate <literal>http</literal> element for the pattern like this: <programlisting language="xml"><![CDATA[
|
||||
<http pattern="/css/**" secured="false"/>
|
||||
<http pattern="/login.jsp*" secured="false"/>
|
||||
|
||||
|
|
@ -287,27 +280,26 @@
|
|||
<form-login login-page='/login.jsp'/>
|
||||
</http>
|
||||
]]>
|
||||
</programlisting>
|
||||
From Spring Security 3.1 it is now possible to use multiple <literal>http</literal>
|
||||
elements to define separate security filter chain configurations for different
|
||||
request patterns. If the <literal>pattern</literal> attribute is omitted from an
|
||||
<literal>http</literal> element, it matches all requests. Creating an unsecured
|
||||
pattern is a simple example of this syntax, where the pattern is mapped to an empty filter chain
|
||||
<footnote><para>The use of multiple <literal><http></literal> elements is an
|
||||
important feature, allowing the namespace to simultaneously support both stateful and stateless
|
||||
paths within the same application, for example. The previous syntax, using the attribute
|
||||
<literal>filters="none"</literal> on an <literal>intercept-url</literal> element
|
||||
is incompatible with this change and is no longer supported in 3.1.</para></footnote>.
|
||||
We'll look at this new syntax in more detail in the chapter on the
|
||||
<link xlink:href="#filter-chains-with-ns">Security Filter Chain</link>.
|
||||
</para>
|
||||
<para>
|
||||
It's important to realise that these unsecured requests will be completely
|
||||
oblivious to any 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>
|
||||
</programlisting> From Spring Security 3.1 it is now possible to use multiple
|
||||
<literal>http</literal> elements to define separate security filter chain
|
||||
configurations for different request patterns. If the <literal>pattern</literal>
|
||||
attribute is omitted from an <literal>http</literal> element, it matches all
|
||||
requests. Creating an unsecured pattern is a simple example of this syntax, where
|
||||
the pattern is mapped to an empty filter chain <footnote>
|
||||
<para>The use of multiple <literal><http></literal> elements is an important
|
||||
feature, allowing the namespace to simultaneously support both stateful and
|
||||
stateless paths within the same application, for example. The previous syntax,
|
||||
using the attribute <literal>filters="none"</literal> on an
|
||||
<literal>intercept-url</literal> element is incompatible with this change and is
|
||||
no longer supported in 3.1.</para>
|
||||
</footnote>. We'll look at this new syntax in more detail in the chapter on the
|
||||
<link xlink:href="#filter-chains-with-ns">Security Filter Chain</link>. </para>
|
||||
<para> It's important to realise that these unsecured requests will be completely
|
||||
oblivious to any 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'>
|
||||
|
|
@ -327,9 +319,9 @@
|
|||
"/". You can also configure things so that the user <emphasis>always</emphasis>
|
||||
ends up at this page (regardless of whether the login was "on-demand" or they
|
||||
explicitly chose to log in) by setting the
|
||||
<literal>always-use-default-target</literal> attribute to "true". This is
|
||||
useful if your application always requires that the user starts at a "home"
|
||||
page, for example: <programlisting language="xml"><![CDATA[
|
||||
<literal>always-use-default-target</literal> attribute to "true". This is useful
|
||||
if your application always requires that the user starts at a "home" page, for
|
||||
example: <programlisting language="xml"><![CDATA[
|
||||
<http pattern="/login.htm*" secured="false"/>
|
||||
<http>
|
||||
<intercept-url pattern='/**' access='ROLE_USER' />
|
||||
|
|
@ -369,10 +361,9 @@
|
|||
</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
|
||||
<classname>JdbcDaoImpl</classname> bean and point at that using the
|
||||
<literal>user-service-ref</literal> attribute: <programlisting language="xml"><![CDATA[
|
||||
xlink:href="#db_schema_users_authorities">user data tables</link>. Alternatively,
|
||||
you could configure a Spring Security <classname>JdbcDaoImpl</classname> bean and
|
||||
point at that using the <literal>user-service-ref</literal> attribute: <programlisting language="xml"><![CDATA[
|
||||
<authentication-manager>
|
||||
<authentication-provider user-service-ref='myUserDetailsService'/>
|
||||
</authentication-manager>
|
||||
|
|
@ -425,8 +416,8 @@
|
|||
<salt-source user-property="username"/>
|
||||
</password-encoder>
|
||||
]]></programlisting> You can use a custom password encoder bean by using the
|
||||
<literal>ref</literal> attribute of <literal>password-encoder</literal>.
|
||||
This should contain the name of a bean in the application context which is an
|
||||
<literal>ref</literal> attribute of <literal>password-encoder</literal>. This
|
||||
should contain the name of a bean in the application context which is an
|
||||
instance of Spring Security's <interfacename>PasswordEncoder</interfacename>
|
||||
interface. </para>
|
||||
</section>
|
||||
|
|
@ -482,8 +473,8 @@
|
|||
<para>If you wish to place constraints on a single user's ability to log in to your
|
||||
application, Spring Security supports this out of the box with the following
|
||||
simple additions. First you need to add the following listener to your
|
||||
<filename>web.xml</filename> file to keep Spring Security updated about
|
||||
session lifecycle events: <programlisting language="xml"><![CDATA[
|
||||
<filename>web.xml</filename> file to keep Spring Security updated about session
|
||||
lifecycle events: <programlisting language="xml"><![CDATA[
|
||||
<listener>
|
||||
<listener-class>
|
||||
org.springframework.security.web.session.HttpSessionEventPublisher
|
||||
|
|
@ -507,8 +498,8 @@
|
|||
</http>]]>
|
||||
</programlisting>The second login will then be rejected. By
|
||||
<quote>rejected</quote>, we mean that the user will be sent to the
|
||||
<literal>authentication-failure-url</literal> if form-based login is being
|
||||
used. If the second authentication takes place through another non-interactive
|
||||
<literal>authentication-failure-url</literal> if form-based login is being used.
|
||||
If the second authentication takes place through another non-interactive
|
||||
mechanism, such as <quote>remember-me</quote>, an <quote>unauthorized</quote>
|
||||
(402) error will be sent to the client. If instead you want to use an error
|
||||
page, you can add the attribute
|
||||
|
|
@ -521,8 +512,7 @@
|
|||
</section>
|
||||
<section xml:id="ns-session-fixation">
|
||||
<title>Session Fixation Attack Protection</title>
|
||||
<para>
|
||||
<link xlink:href="http://en.wikipedia.org/wiki/Session_fixation">Session
|
||||
<para> <link xlink:href="http://en.wikipedia.org/wiki/Session_fixation">Session
|
||||
fixation</link> attacks are a potential risk where it is possible for a
|
||||
malicious attacker to create a session by accessing a site, then persuade
|
||||
another user to log in with the same session (by sending them a link containing
|
||||
|
|
@ -533,17 +523,17 @@
|
|||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<para><literal>newSession</literal> - Create a new "clean" session, without
|
||||
copying the existing session data.</para>
|
||||
</listitem>
|
||||
</itemizedlist></para>
|
||||
</section>
|
||||
|
|
@ -562,15 +552,14 @@
|
|||
<user name="http://jimi.hendrix.myopenid.com/" authorities="ROLE_USER" />
|
||||
]]></programlisting> You should be able to login using the <literal>myopenid.com</literal> site to
|
||||
authenticate. It is also possible to select a specific
|
||||
<interfacename>UserDetailsService</interfacename> bean for use OpenID by setting
|
||||
the <literal>user-service-ref</literal> attribute on the
|
||||
<literal>openid-login</literal> element. See the previous section on <link
|
||||
xlink:href="#ns-auth-providers">authentication providers</link> 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.</para>
|
||||
<interfacename>UserDetailsService</interfacename> bean for use OpenID by setting the
|
||||
<literal>user-service-ref</literal> attribute on the <literal>openid-login</literal>
|
||||
element. See the previous section on <link xlink:href="#ns-auth-providers"
|
||||
>authentication providers</link> 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.</para>
|
||||
<section>
|
||||
<title>Attribute Exchange</title>
|
||||
<para>Support for OpenID <link
|
||||
|
|
@ -585,12 +574,11 @@
|
|||
</attribute-exchange>
|
||||
</openid-login>]]></programlisting>The <quote>type</quote> of each OpenID attribute is a URI,
|
||||
determined by a particular schema, in this case <link
|
||||
xlink:href="http://axschema.org/">http://axschema.org/</link>. If an
|
||||
attribute must be retrieved for successful authentication, the
|
||||
<literal>required</literal> attribute can be set. The exact schema and
|
||||
attributes supported will depend on your OpenID provider. The attribute values
|
||||
are returned as part of the authentication process and can be accessed
|
||||
afterwards using the following code:
|
||||
xlink:href="http://axschema.org/">http://axschema.org/</link>. If an attribute
|
||||
must be retrieved for successful authentication, the <literal>required</literal>
|
||||
attribute can be set. The exact schema and attributes supported will depend on
|
||||
your OpenID provider. The attribute values are returned as part of the
|
||||
authentication process and can be accessed afterwards using the following code:
|
||||
<programlisting language="java">
|
||||
OpenIDAuthenticationToken token =
|
||||
(OpenIDAuthenticationToken)SecurityContextHolder.getContext().getAuthentication();
|
||||
|
|
@ -603,9 +591,9 @@ List<OpenIDAttribute> attributes = token.getAttributes();</programlisting>The
|
|||
attribute exchange configurations are also be supported, if you wish to use
|
||||
multiple identity providers. You can supply multiple
|
||||
<literal>attribute-exchange</literal> elements, using an
|
||||
<literal>identifier-matcher</literal> attribute on each. This contains a
|
||||
regular expression which will be matched against the OpenID identifier supplied
|
||||
by the user. See the OpenID sample application in the codebase for an example
|
||||
<literal>identifier-matcher</literal> attribute on each. This contains a regular
|
||||
expression which will be matched against the OpenID identifier supplied by the
|
||||
user. See the OpenID sample application in the codebase for an example
|
||||
configuration, providing different attribute lists for the Google, Yahoo and
|
||||
MyOpenID providers.</para>
|
||||
</section>
|
||||
|
|
@ -618,21 +606,21 @@ List<OpenIDAttribute> attributes = token.getAttributes();</programlisting>The
|
|||
which there isn't currently a namespace configuration option (CAS, for example). Or
|
||||
you might want to use a customized version of a standard namespace filter, such as
|
||||
the <literal>UsernamePasswordAuthenticationFilter</literal> which is created by the
|
||||
<literal><form-login></literal> element, taking advantage of some of the
|
||||
extra configuration options which are available by using the bean explicitly. How
|
||||
can you do this with namespace configuration, since the filter chain is not directly
|
||||
<literal><form-login></literal> element, taking advantage of some of the extra
|
||||
configuration options which are available by using the bean explicitly. How can you
|
||||
do this with namespace configuration, since the filter chain is not directly
|
||||
exposed? </para>
|
||||
<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>
|
||||
<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">
|
||||
|
|
@ -656,8 +644,7 @@ List<OpenIDAttribute> attributes = token.getAttributes();</programlisting>The
|
|||
</row>
|
||||
<row>
|
||||
<entry> CONCURRENT_SESSION_FILTER</entry>
|
||||
<entry><literal>ConcurrentSessionFilter</literal>
|
||||
</entry>
|
||||
<entry><literal>ConcurrentSessionFilter</literal> </entry>
|
||||
<entry><literal>session-management/concurrency-control</literal></entry>
|
||||
</row>
|
||||
<row>
|
||||
|
|
@ -752,8 +739,8 @@ List<OpenIDAttribute> attributes = token.getAttributes();</programlisting>The
|
|||
<para> If you are inserting a custom filter which may occupy the same position as
|
||||
one of the standard filters created by the namespace then it's important that
|
||||
you don't include the namespace versions by mistake. Avoid using the
|
||||
<literal>auto-config</literal> attribute and remove any elements which
|
||||
create filters whose functionality you want to replace. </para>
|
||||
<literal>auto-config</literal> attribute and remove any elements which create
|
||||
filters whose functionality you want to replace. </para>
|
||||
<para> Note that you can't replace filters which are created by the use of the
|
||||
<literal><http></literal> element itself -
|
||||
<classname>SecurityContextPersistenceFilter</classname>,
|
||||
|
|
@ -788,8 +775,8 @@ List<OpenIDAttribute> attributes = token.getAttributes();</programlisting>The
|
|||
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
|
||||
<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>
|
||||
|
|
@ -797,8 +784,8 @@ List<OpenIDAttribute> attributes = token.getAttributes();</programlisting>The
|
|||
setting the appropriate attributes on the element), and also to group together
|
||||
security pointcut declarations which will be applied across your entire application
|
||||
context. You should only declare one
|
||||
<literal><global-method-security></literal> element. The following
|
||||
declaration would enable support for Spring Security's <literal>@Secured</literal>: <programlisting><![CDATA[
|
||||
<literal><global-method-security></literal> element. The following declaration
|
||||
would enable support for Spring Security's <literal>@Secured</literal>: <programlisting><![CDATA[
|
||||
<global-method-security secured-annotations="enabled" />
|
||||
]]>
|
||||
</programlisting> Adding an annotation to a method (on an class or interface) would then limit
|
||||
|
|
@ -843,16 +830,13 @@ List<OpenIDAttribute> attributes = token.getAttributes();</programlisting>The
|
|||
annotations are a good choice if you need to define simple rules that go beyond
|
||||
checking the role names against the user's list of authorities. You can enable more
|
||||
than one type of annotation in the same application, but you should avoid mixing
|
||||
annotations types in the same interface or class to avoid confusion.
|
||||
<note>
|
||||
<para>The annotated methods will only be secured for instances which are defined
|
||||
as Spring beans (in the same application context in which method-security
|
||||
is enabled). If you want to secure instances which are not created by Spring
|
||||
(using the <literal>new</literal> operator, for example) then you need to use
|
||||
AspectJ.
|
||||
</para>
|
||||
</note>
|
||||
annotations types in the same interface or class to avoid confusion. <note>
|
||||
<para>The annotated methods will only be secured for instances which are defined as
|
||||
Spring beans (in the same application context in which method-security is
|
||||
enabled). If you want to secure instances which are not created by Spring (using
|
||||
the <literal>new</literal> operator, for example) then you need to use AspectJ.
|
||||
</para>
|
||||
</note> </para>
|
||||
<section xml:id="ns-protect-pointcut">
|
||||
<title>Adding Security Pointcuts using <literal>protect-pointcut</literal></title>
|
||||
<para> The use of <literal>protect-pointcut</literal> is particularly powerful, as
|
||||
|
|
@ -866,8 +850,8 @@ List<OpenIDAttribute> attributes = token.getAttributes();</programlisting>The
|
|||
</programlisting> This will protect all methods on beans declared in the application
|
||||
context whose classes are in the <literal>com.mycompany</literal> package and
|
||||
whose class names end in "Service". Only users with the
|
||||
<literal>ROLE_USER</literal> role will be able to invoke these methods. As
|
||||
with URL matching, the most specific matches must come first in the list of
|
||||
<literal>ROLE_USER</literal> role will be able to invoke these methods. As with
|
||||
URL matching, the most specific matches must come first in the list of
|
||||
pointcuts, as the first matching expression will be used. </para>
|
||||
</section>
|
||||
</section>
|
||||
|
|
@ -879,15 +863,15 @@ List<OpenIDAttribute> attributes = token.getAttributes();</programlisting>The
|
|||
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>
|
||||
<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 the access attributes you specify in your
|
||||
<literal>intercept-url</literal> and <literal>protect-pointcut</literal>
|
||||
declarations (and in annotations if you are using annotation secured methods). </para>
|
||||
<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 the access attributes you specify in your <literal>intercept-url</literal> and
|
||||
<literal>protect-pointcut</literal> declarations (and in annotations if you are using
|
||||
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>.
|
||||
You can find out more about these in the chapter on <link xlink:href="#authz-arch"
|
||||
<classname>RoleVoter</classname> and an <classname>AuthenticatedVoter</classname>. You
|
||||
can find out more about these in the chapter on <link xlink:href="#authz-arch"
|
||||
>authorization</link>.</para>
|
||||
<section xml:id="ns-custom-access-mgr">
|
||||
<title>Customizing the AccessDecisionManager</title>
|
||||
|
|
@ -925,8 +909,8 @@ List<OpenIDAttribute> attributes = token.getAttributes();</programlisting>The
|
|||
<para> You may want to register additional <classname>AuthenticationProvider</classname>
|
||||
beans with the <classname>ProviderManager</classname> and you can do this using the
|
||||
<literal><authentication-provider></literal> element with the
|
||||
<literal>ref</literal> attribute, where the value of the attribute is the name of
|
||||
the provider bean you want to add. For example: <programlisting language="xml"><![CDATA[
|
||||
<literal>ref</literal> attribute, where the value of the attribute is the name of the
|
||||
provider bean you want to add. For example: <programlisting language="xml"><![CDATA[
|
||||
<authentication-manager>
|
||||
<authentication-provider ref="casAuthenticationProvider"/>
|
||||
</authentication-manager>
|
||||
|
|
|
|||
Loading…
Reference in New Issue