|
|
@@ -45,10 +45,10 @@
|
|
|
SecurityContextHolder, SecurityContext and Authentication Objects
|
|
|
</title>
|
|
|
<para>The most fundamental object is
|
|
|
- <literal>SecurityContextHolder</literal>. This is where we store
|
|
|
+ <classname>SecurityContextHolder</classname>. This is where we store
|
|
|
details of the present security context of the application, which
|
|
|
includes details of the principal currently using the application. By
|
|
|
- default the <literal>SecurityContextHolder</literal> uses a
|
|
|
+ default the <classname>SecurityContextHolder</classname> uses a
|
|
|
<literal>ThreadLocal</literal> to store these details, which means
|
|
|
that the security context is always available to methods in the same
|
|
|
thread of execution, even if the security context is not explicitly
|
|
|
@@ -70,17 +70,17 @@
|
|
|
You can change the mode from the default
|
|
|
<literal>SecurityContextHolder.MODE_THREADLOCAL</literal> in two ways.
|
|
|
The first is to set a system property. Alternatively, call a static
|
|
|
- method on <literal>SecurityContextHolder</literal>. Most applications
|
|
|
+ method on <classname>SecurityContextHolder</classname>. Most applications
|
|
|
won't need to change from the default, but if you do, take a look at
|
|
|
- the JavaDocs for <literal>SecurityContextHolder</literal> to learn
|
|
|
+ the JavaDocs for <classname>SecurityContextHolder</classname> to learn
|
|
|
more.</para>
|
|
|
|
|
|
- <para>Inside the <literal>SecurityContextHolder</literal> we store
|
|
|
+ <para>Inside the <classname>SecurityContextHolder</classname> we store
|
|
|
details of the principal currently interacting with the application.
|
|
|
- Spring Security uses an <literal>Authentication</literal> object to
|
|
|
+ Spring Security uses an <interfacename>Authentication</interfacename> object to
|
|
|
represent this information. Whilst you won't normally need to create
|
|
|
- an <literal>Authentication</literal> object yourself, it is fairly
|
|
|
- common for users to query the <literal>Authentication</literal>
|
|
|
+ an <interfacename>Authentication</interfacename> object yourself, it is fairly
|
|
|
+ common for users to query the <interfacename>Authentication</interfacename>
|
|
|
object. You can use the following code block - from anywhere in your
|
|
|
application - to obtain the name of the authenticated user, for example:</para>
|
|
|
|
|
|
@@ -95,14 +95,14 @@ if (obj instanceof UserDetails) {
|
|
|
|
|
|
<para>The above code introduces a number of interesting relationships
|
|
|
and key objects. First, you will notice that there is an intermediate
|
|
|
- object between <literal>SecurityContextHolder</literal> and
|
|
|
- <literal>Authentication</literal>. The
|
|
|
+ object between <classname>SecurityContextHolder</classname> and
|
|
|
+ <interfacename>Authentication</interfacename>. The
|
|
|
<literal>SecurityContextHolder.getContext()</literal> method is
|
|
|
- actually returning a <literal>SecurityContext</literal>.
|
|
|
+ actually returning a <interfacename>SecurityContext</interfacename>.
|
|
|
|
|
|
<!-- Commented out as Captcha sandboxed
|
|
|
Spring
|
|
|
- Security uses a few different <literal>SecurityContext</literal>
|
|
|
+ Security uses a few different <interfacename>SecurityContext</interfacename>
|
|
|
implementations, such as if we need to store special information
|
|
|
related to a request that is not principal-specific.
|
|
|
|
|
|
@@ -111,7 +111,7 @@ if (obj instanceof UserDetails) {
|
|
|
current request came from a human user or not. Because such a decision
|
|
|
has nothing at all to do with the principal the request may or may not
|
|
|
be authenticated as, we store it in the
|
|
|
- <literal>SecurityContext</literal>. -->
|
|
|
+ <interfacename>SecurityContext</interfacename>. -->
|
|
|
</para>
|
|
|
</section>
|
|
|
|
|
|
@@ -119,40 +119,40 @@ if (obj instanceof UserDetails) {
|
|
|
<title>The UserDetailsService</title>
|
|
|
|
|
|
<para>Another item to note from the above code fragment is that you
|
|
|
- can obtain a principal from the <literal>Authentication</literal>
|
|
|
+ can obtain a principal from the <interfacename>Authentication</interfacename>
|
|
|
object. The principal is just an <literal>Object</literal>. Most of
|
|
|
- the time this can be cast into a <literal>UserDetails</literal>
|
|
|
- object. <literal>UserDetails</literal> is a central interface in
|
|
|
+ the time this can be cast into a <interfacename>UserDetails</interfacename>
|
|
|
+ object. <interfacename>UserDetails</interfacename> is a central interface in
|
|
|
Spring Security. It represents a principal, but in an extensible and
|
|
|
- application-specific way. Think of <literal>UserDetails</literal> as
|
|
|
+ application-specific way. Think of <interfacename>UserDetails</interfacename> as
|
|
|
the adapter between your own user database and what Spring Security
|
|
|
- needs inside the <literal>SecurityContextHolder</literal>. Being a
|
|
|
+ needs inside the <classname>SecurityContextHolder</classname>. Being a
|
|
|
representation of something from your own user database, quite often
|
|
|
- you will cast the <literal>UserDetails</literal> to the original
|
|
|
+ you will cast the <interfacename>UserDetails</interfacename> to the original
|
|
|
object that your application provided, so you can call
|
|
|
business-specific methods (like <literal>getEmail()</literal>,
|
|
|
<literal>getEmployeeNumber()</literal> and so on).</para>
|
|
|
|
|
|
<para>By now you're probably wondering, so when do I provide a
|
|
|
- <literal>UserDetails</literal> object? How do I do that? I thought you
|
|
|
+ <interfacename>UserDetails</interfacename> object? How do I do that? I thought you
|
|
|
said this thing was declarative and I didn't need to write any Java
|
|
|
code - what gives? The short answer is that there is a special
|
|
|
- interface called <literal>UserDetailsService</literal>. The only
|
|
|
+ interface called <interfacename>UserDetailsService</interfacename>. The only
|
|
|
method on this interface accepts a <literal>String</literal>-based
|
|
|
- username argument and returns a <literal>UserDetails</literal>. Most
|
|
|
+ username argument and returns a <interfacename>UserDetails</interfacename>. Most
|
|
|
authentication providers that ship with Spring Security delegate to a
|
|
|
- <literal>UserDetailsService</literal> as part of the authentication
|
|
|
- process. The <literal>UserDetailsService</literal> is used to build
|
|
|
- the <literal>Authentication</literal> object that is stored in the
|
|
|
- <literal>SecurityContextHolder</literal>. The good news is that we
|
|
|
- provide a number of <literal>UserDetailsService</literal>
|
|
|
+ <interfacename>UserDetailsService</interfacename> as part of the authentication
|
|
|
+ process. The <interfacename>UserDetailsService</interfacename> is used to build
|
|
|
+ the <interfacename>Authentication</interfacename> object that is stored in the
|
|
|
+ <classname>SecurityContextHolder</classname>. The good news is that we
|
|
|
+ provide a number of <interfacename>UserDetailsService</interfacename>
|
|
|
implementations, including one that uses an in-memory map and another
|
|
|
that uses JDBC. Most users tend to write their own, though, with such
|
|
|
implementations often simply sitting on top of an existing Data Access
|
|
|
Object (DAO) that represents their employees, customers, or other
|
|
|
users of the enterprise application. Remember the advantage that
|
|
|
whatever your UserDetailsService returns can always be obtained from
|
|
|
- the <literal>SecurityContextHolder</literal>, as per the above code
|
|
|
+ the <classname>SecurityContextHolder</classname>, as per the above code
|
|
|
fragment.</para>
|
|
|
</section>
|
|
|
|
|
|
@@ -161,23 +161,23 @@ if (obj instanceof UserDetails) {
|
|
|
<title>GrantedAuthority</title>
|
|
|
|
|
|
<para>Besides the principal, another important method provided by
|
|
|
- <literal>Authentication</literal> is
|
|
|
+ <interfacename>Authentication</interfacename> is
|
|
|
<literal>getAuthorities(</literal>). This method provides an array of
|
|
|
- <literal>GrantedAuthority</literal> objects. A
|
|
|
- <literal>GrantedAuthority</literal> is, not surprisingly, an authority
|
|
|
+ <interfacename>GrantedAuthority</interfacename> objects. A
|
|
|
+ <interfacename>GrantedAuthority</interfacename> is, not surprisingly, an authority
|
|
|
that is granted to the principal. Such authorities are usually
|
|
|
"roles", such as <literal>ROLE_ADMINISTRATOR</literal> or
|
|
|
<literal>ROLE_HR_SUPERVISOR</literal>. These roles are later on
|
|
|
configured for web authorization, method authorization and domain
|
|
|
object authorization. Other parts of Spring Security are capable of
|
|
|
interpreting these authorities, and expect them to be present.
|
|
|
- <literal>GrantedAuthority</literal> objects are usually loaded by the
|
|
|
- <literal>UserDetailsService</literal>.</para>
|
|
|
+ <interfacename>GrantedAuthority</interfacename> objects are usually loaded by the
|
|
|
+ <interfacename>UserDetailsService</interfacename>.</para>
|
|
|
|
|
|
- <para>Usually the <literal>GrantedAuthority</literal> objects are
|
|
|
+ <para>Usually the <interfacename>GrantedAuthority</interfacename> objects are
|
|
|
application-wide permissions. They are not specific to a given domain
|
|
|
object. Thus, you wouldn't likely have a
|
|
|
- <literal>GrantedAuthority</literal> to represent a permission to
|
|
|
+ <interfacename>GrantedAuthority</interfacename> to represent a permission to
|
|
|
<literal>Employee</literal> object number 54, because if there are
|
|
|
thousands of such authorities you would quickly run out of memory (or,
|
|
|
at the very least, cause the application to take a long time to
|
|
|
@@ -186,16 +186,16 @@ if (obj instanceof UserDetails) {
|
|
|
domain object security capabilities for this purpose.</para>
|
|
|
|
|
|
<para>Last but not least, sometimes you will need to store the
|
|
|
- <literal>SecurityContext</literal> between HTTP requests. Other times
|
|
|
+ <interfacename>SecurityContext</interfacename> between HTTP requests. Other times
|
|
|
the principal will re-authenticate on every request, although most of
|
|
|
the time it will be stored. The
|
|
|
- <literal>HttpSessionContextIntegrationFilter</literal> is responsible
|
|
|
- for storing a <literal>SecurityContext</literal> between HTTP
|
|
|
+ <classname>HttpSessionContextIntegrationFilter</classname> is responsible
|
|
|
+ for storing a <interfacename>SecurityContext</interfacename> between HTTP
|
|
|
requests. As suggested by the name of the class, the
|
|
|
<literal>HttpSession</literal> is used to store this information. You
|
|
|
should never interact directly with the <literal>HttpSession</literal>
|
|
|
for security purposes. There is simply no justification for doing so -
|
|
|
- always use the <literal>SecurityContextHolder</literal>
|
|
|
+ always use the <classname>SecurityContextHolder</classname>
|
|
|
instead.</para>
|
|
|
|
|
|
</section>
|
|
|
@@ -208,41 +208,41 @@ if (obj instanceof UserDetails) {
|
|
|
|
|
|
<itemizedlist spacing="compact">
|
|
|
<listitem>
|
|
|
- <para><literal>SecurityContextHolder</literal>, to provide any
|
|
|
- type access to the <literal>SecurityContext</literal>.</para>
|
|
|
+ <para><classname>SecurityContextHolder</classname>, to provide any
|
|
|
+ type access to the <interfacename>SecurityContext</interfacename>.</para>
|
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
|
- <para><literal>SecurityContext</literal>, to hold the
|
|
|
- <literal>Authentication</literal> and possibly request-specific
|
|
|
+ <para><interfacename>SecurityContext</interfacename>, to hold the
|
|
|
+ <interfacename>Authentication</interfacename> and possibly request-specific
|
|
|
security information.</para>
|
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
|
- <para><literal>HttpSessionContextIntegrationFilter</literal>, to
|
|
|
- store the <literal>SecurityContext</literal> in the
|
|
|
+ <para><classname>HttpSessionContextIntegrationFilter</classname>, to
|
|
|
+ store the <interfacename>SecurityContext</interfacename> in the
|
|
|
<literal>HttpSession</literal> between web requests.</para>
|
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
|
- <para><literal>Authentication</literal>, to represent the
|
|
|
+ <para><interfacename>Authentication</interfacename>, to represent the
|
|
|
principal in a Spring Security-specific manner.</para>
|
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
|
- <para><literal>GrantedAuthority</literal>, to reflect the
|
|
|
+ <para><interfacename>GrantedAuthority</interfacename>, to reflect the
|
|
|
application-wide permissions granted to a principal.</para>
|
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
|
- <para><literal>UserDetails</literal>, to provide the necessary
|
|
|
+ <para><interfacename>UserDetails</interfacename>, to provide the necessary
|
|
|
information to build an Authentication object from your
|
|
|
application's DAOs.</para>
|
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
|
- <para><literal>UserDetailsService</literal>, to create a
|
|
|
- <literal>UserDetails</literal> when passed in a
|
|
|
+ <para><interfacename>UserDetailsService</interfacename>, to create a
|
|
|
+ <interfacename>UserDetails</interfacename> when passed in a
|
|
|
<literal>String</literal>-based username (or certificate ID or
|
|
|
alike).</para>
|
|
|
</listitem>
|
|
|
@@ -321,37 +321,37 @@ if (obj instanceof UserDetails) {
|
|
|
|
|
|
<para>Spring Security has distinct classes responsible for most of the
|
|
|
steps described above. The main participants (in the order that they
|
|
|
- are used) are the <literal>ExceptionTranslationFilter</literal>, an
|
|
|
- <literal>AuthenticationEntryPoint</literal>, an authentication
|
|
|
- mechanism, and an <literal>AuthenticationProvider</literal>.</para>
|
|
|
+ are used) are the <classname>ExceptionTranslationFilter</classname>, an
|
|
|
+ <interfacename>AuthenticationEntryPoint</interfacename>, an authentication
|
|
|
+ mechanism, and an <classname>AuthenticationProvider</classname>.</para>
|
|
|
|
|
|
<section>
|
|
|
<title>ExceptionTranslationFilter</title>
|
|
|
- <para><literal>ExceptionTranslationFilter</literal> is a Spring
|
|
|
+ <para><classname>ExceptionTranslationFilter</classname> is a Spring
|
|
|
Security filter that has responsibility for detecting any Spring
|
|
|
Security exceptions that are thrown. Such exceptions will generally be
|
|
|
- thrown by an <literal>AbstractSecurityInterceptor</literal>, which is
|
|
|
+ thrown by an <classname>AbstractSecurityInterceptor</classname>, which is
|
|
|
the main provider of authorization services. We will discuss
|
|
|
- <literal>AbstractSecurityInterceptor</literal> in the next section,
|
|
|
+ <classname>AbstractSecurityInterceptor</classname> in the next section,
|
|
|
but for now we just need to know that it produces Java exceptions and
|
|
|
knows nothing about HTTP or how to go about authenticating a
|
|
|
- principal. Instead the <literal>ExceptionTranslationFilter</literal>
|
|
|
+ principal. Instead the <classname>ExceptionTranslationFilter</classname>
|
|
|
offers this service, with specific responsibility for either returning
|
|
|
error code 403 (if the principal has been authenticated and therefore
|
|
|
simply lacks sufficient access - as per step seven above), or
|
|
|
- launching an <literal>AuthenticationEntryPoint</literal> (if the
|
|
|
+ launching an <interfacename>AuthenticationEntryPoint</interfacename> (if the
|
|
|
principal has not been authenticated and therefore we need to go
|
|
|
commence step three).</para>
|
|
|
</section>
|
|
|
|
|
|
<section xml:id="tech-auth-entry-point">
|
|
|
<title>AuthenticationEntryPoint</title>
|
|
|
- <para>The <literal>AuthenticationEntryPoint</literal> is responsible
|
|
|
+ <para>The <interfacename>AuthenticationEntryPoint</interfacename> is responsible
|
|
|
for step three in the above list. As you can imagine, each web
|
|
|
application will have a default authentication strategy (well, this
|
|
|
can be configured like nearly everything else in Spring Security, but
|
|
|
let's keep it simple for now). Each major authentication system will
|
|
|
- have its own <literal>AuthenticationEntryPoint</literal>
|
|
|
+ have its own <interfacename>AuthenticationEntryPoint</interfacename>
|
|
|
implementation, which takes actions such as described in step
|
|
|
three.</para>
|
|
|
|
|
|
@@ -363,7 +363,7 @@ if (obj instanceof UserDetails) {
|
|
|
authentication details from a user agent (usually a web browser), and
|
|
|
that name is "authentication mechanism". After the authentication
|
|
|
details are collected from the user agent, an
|
|
|
- "<literal>Authentication</literal> request" object is built and then
|
|
|
+ "<interfacename>Authentication</interfacename> request" object is built and then
|
|
|
presented to an
|
|
|
<interfacename>AuthenticationProvider</interfacename>.</para>
|
|
|
</section>
|
|
|
@@ -371,31 +371,31 @@ if (obj instanceof UserDetails) {
|
|
|
<section>
|
|
|
<title>AuthenticationProvider</title>
|
|
|
<para>The last player in the Spring Security authentication process is
|
|
|
- an <literal>AuthenticationProvider</literal>. Quite simply, it is
|
|
|
- responsible for taking an <literal>Authentication</literal> request
|
|
|
+ an <classname>AuthenticationProvider</classname>. Quite simply, it is
|
|
|
+ responsible for taking an <interfacename>Authentication</interfacename> request
|
|
|
object and deciding whether or not it is valid. The provider will
|
|
|
either throw an exception or return a fully populated
|
|
|
- <literal>Authentication</literal> object. Remember our good friends,
|
|
|
- <literal>UserDetails</literal> and
|
|
|
- <literal>UserDetailsService</literal>? If not, head back to the
|
|
|
+ <interfacename>Authentication</interfacename> object. Remember our good friends,
|
|
|
+ <interfacename>UserDetails</interfacename> and
|
|
|
+ <interfacename>UserDetailsService</interfacename>? If not, head back to the
|
|
|
previous section and refresh your memory. Most
|
|
|
- <literal>AuthenticationProvider</literal>s will ask a
|
|
|
- <literal>UserDetailsService</literal> to provide a
|
|
|
- <literal>UserDetails</literal> object. As mentioned earlier, most
|
|
|
+ <classname>AuthenticationProvider</classname>s will ask a
|
|
|
+ <interfacename>UserDetailsService</interfacename> to provide a
|
|
|
+ <interfacename>UserDetails</interfacename> object. As mentioned earlier, most
|
|
|
application will provide their own
|
|
|
- <literal>UserDetailsService</literal>, although some will be able to
|
|
|
+ <interfacename>UserDetailsService</interfacename>, although some will be able to
|
|
|
use the JDBC or in-memory implementation that ships with Spring
|
|
|
- Security. The resultant <literal>UserDetails</literal> object - and
|
|
|
+ Security. The resultant <interfacename>UserDetails</interfacename> object - and
|
|
|
particularly the <literal>GrantedAuthority[]</literal>s contained
|
|
|
- within the <literal>UserDetails</literal> object - will be used when
|
|
|
- building the fully populated <literal>Authentication</literal>
|
|
|
+ within the <interfacename>UserDetails</interfacename> object - will be used when
|
|
|
+ building the fully populated <interfacename>Authentication</interfacename>
|
|
|
object.</para>
|
|
|
<para>After the authentication mechanism receives back the
|
|
|
- fully-populated <literal>Authentication</literal> object, it will deem
|
|
|
- the request valid, put the <literal>Authentication</literal> into the
|
|
|
- <literal>SecurityContextHolder</literal>, and cause the original
|
|
|
+ fully-populated <interfacename>Authentication</interfacename> object, it will deem
|
|
|
+ the request valid, put the <interfacename>Authentication</interfacename> into the
|
|
|
+ <classname>SecurityContextHolder</classname>, and cause the original
|
|
|
request to be retried (step seven above). If, on the other hand, the
|
|
|
- <literal>AuthenticationProvider</literal> rejected the request, the
|
|
|
+ <classname>AuthenticationProvider</classname> rejected the request, the
|
|
|
authentication mechanism will ask the user agent to retry (step two
|
|
|
above).</para>
|
|
|
|
|
|
@@ -405,11 +405,11 @@ if (obj instanceof UserDetails) {
|
|
|
<title>Setting the SecurityContextHolder Contents Directly</title>
|
|
|
<para>Whilst this describes the typical authentication workflow, the
|
|
|
good news is that Spring Security doesn't mind how you put an
|
|
|
- <literal>Authentication</literal> inside the
|
|
|
- <literal>SecurityContextHolder</literal>. The only critical
|
|
|
- requirement is that the <literal>SecurityContextHolder</literal>
|
|
|
- contains an <literal>Authentication</literal> that represents a
|
|
|
- principal before the <literal>AbstractSecurityInterceptor</literal>
|
|
|
+ <interfacename>Authentication</interfacename> inside the
|
|
|
+ <classname>SecurityContextHolder</classname>. The only critical
|
|
|
+ requirement is that the <classname>SecurityContextHolder</classname>
|
|
|
+ contains an <interfacename>Authentication</interfacename> that represents a
|
|
|
+ principal before the <classname>AbstractSecurityInterceptor</classname>
|
|
|
needs to authorize a request.</para>
|
|
|
|
|
|
<para>You can (and many users do) write their own filters or MVC
|
|
|
@@ -474,22 +474,22 @@ if (obj instanceof UserDetails) {
|
|
|
<title>AbstractSecurityInterceptor</title>
|
|
|
|
|
|
<para>Each secure object type supported by Spring Security has its own class,
|
|
|
- which is a subclass of <literal>AbstractSecurityInterceptor</literal>.
|
|
|
- Importantly, by the time the <literal>AbstractSecurityInterceptor</literal> is called, the
|
|
|
- <literal>SecurityContextHolder</literal> will contain a valid
|
|
|
- <literal>Authentication</literal> if the principal has been
|
|
|
+ which is a subclass of <classname>AbstractSecurityInterceptor</classname>.
|
|
|
+ Importantly, by the time the <classname>AbstractSecurityInterceptor</classname> is called, the
|
|
|
+ <classname>SecurityContextHolder</classname> will contain a valid
|
|
|
+ <interfacename>Authentication</interfacename> if the principal has been
|
|
|
authenticated.</para>
|
|
|
|
|
|
- <para><literal>AbstractSecurityInterceptor</literal> provides a
|
|
|
+ <para><classname>AbstractSecurityInterceptor</classname> provides a
|
|
|
consistent workflow for handling secure object requests, typically:
|
|
|
|
|
|
<orderedlist>
|
|
|
<listitem><para>Look up the "configuration attributes" associated with the
|
|
|
present request</para></listitem>
|
|
|
- <listitem><para>Submitting the secure object, current <literal>Authentication</literal>
|
|
|
- and configuration attributes to the <literal>AccessDecisionManager</literal> for
|
|
|
+ <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 <literal>Authentication</literal> under which the invocation
|
|
|
+ <listitem><para>Optionally change the <interfacename>Authentication</interfacename> under which the invocation
|
|
|
takes place</para></listitem>
|
|
|
<listitem><para>Allow the secure object to proceed (assuming access was granted)</para></listitem>
|
|
|
<listitem><para>Call the <literal>AfterInvocationManager</literal> if configured, once the invocation
|
|
|
@@ -501,9 +501,9 @@ if (obj instanceof UserDetails) {
|
|
|
<title>What are Configuration Attributes?</title>
|
|
|
<para>
|
|
|
A "configuration attribute" can be thought of as a String that has special meaning to the classes used by
|
|
|
- <literal>AbstractSecurityInterceptor</literal>. They may be simple role names or have more complex meaning, depending on the
|
|
|
- how sophisticated the <literal>AccessDecisionManager</literal> implementation is.
|
|
|
- The <literal>AbstractSecurityInterceptor</literal> is configured with an <literal>ObjectDefinitionSource</literal> which
|
|
|
+ <classname>AbstractSecurityInterceptor</classname>. They may be simple role names or have more complex meaning, depending on the
|
|
|
+ how sophisticated the <interfacename>AccessDecisionManager</interfacename> implementation is.
|
|
|
+ The <classname>AbstractSecurityInterceptor</classname> is configured with an <interfacename>ObjectDefinitionSource</interfacename> which
|
|
|
it uses to look up the attributes for a secure object. Usually this configuration will be hidden from the user. Configuration
|
|
|
attributes will be entered as annotations on secured methods, or as access attributes on secured URLs (using the
|
|
|
namespace <literal><intercept-url></literal> syntax).
|
|
|
@@ -512,14 +512,14 @@ if (obj instanceof UserDetails) {
|
|
|
|
|
|
<section>
|
|
|
<title>RunAsManager</title>
|
|
|
- <para>Assuming <literal>AccessDecisionManager</literal> decides to
|
|
|
- allow the request, the <literal>AbstractSecurityInterceptor</literal>
|
|
|
+ <para>Assuming <interfacename>AccessDecisionManager</interfacename> decides to
|
|
|
+ allow the request, the <classname>AbstractSecurityInterceptor</classname>
|
|
|
will normally just proceed with the request. Having said that, on rare
|
|
|
occasions users may want to replace the
|
|
|
- <literal>Authentication</literal> inside the
|
|
|
- <literal>SecurityContext</literal> with a different
|
|
|
- <literal>Authentication</literal>, which is handled by the
|
|
|
- <literal>AccessDecisionManager</literal> calling a
|
|
|
+ <interfacename>Authentication</interfacename> inside the
|
|
|
+ <interfacename>SecurityContext</interfacename> with a different
|
|
|
+ <interfacename>Authentication</interfacename>, which is handled by the
|
|
|
+ <interfacename>AccessDecisionManager</interfacename> calling a
|
|
|
<literal>RunAsManager</literal>. This might be useful in reasonably
|
|
|
unusual situations, such as if a services layer method needs to call a
|
|
|
remote system and present a different identity. Because Spring
|
|
|
@@ -532,18 +532,18 @@ if (obj instanceof UserDetails) {
|
|
|
<title>AfterInvocationManager</title>
|
|
|
<para>Following the secure object proceeding and then returning -
|
|
|
which may mean a method invocation completing or a filter chain
|
|
|
- proceeding - the <literal>AbstractSecurityInterceptor</literal> gets
|
|
|
+ proceeding - the <classname>AbstractSecurityInterceptor</classname> gets
|
|
|
one final chance to handle the invocation. At this stage the
|
|
|
- <literal>AbstractSecurityInterceptor</literal> is interested in
|
|
|
+ <classname>AbstractSecurityInterceptor</classname> is interested in
|
|
|
possibly modifying the return object. We might want this to happen
|
|
|
because an authorization decision couldn't be made "on the way in" to
|
|
|
a secure object invocation. Being highly pluggable,
|
|
|
- <literal>AbstractSecurityInterceptor</literal> will pass control to an
|
|
|
+ <classname>AbstractSecurityInterceptor</classname> will pass control to an
|
|
|
<literal>AfterInvocationManager</literal> to actually modify the
|
|
|
object if needed. This class can even entirely replace the object, or
|
|
|
throw an exception, or not change it in any way.</para>
|
|
|
|
|
|
- <para><literal>AbstractSecurityInterceptor</literal> and its related objects
|
|
|
+ <para><classname>AbstractSecurityInterceptor</classname> and its related objects
|
|
|
are shown in <xref linkend="abstract-security-interceptor"/>.
|
|
|
|
|
|
<figure xml:id="abstract-security-interceptor">
|
|
|
@@ -570,9 +570,9 @@ if (obj instanceof UserDetails) {
|
|
|
around advice semantics) is capable of being made into a secure
|
|
|
object. Having said that, most Spring applications will simply use the
|
|
|
three currently supported secure object types (AOP Alliance
|
|
|
- <literal>MethodInvocation</literal>, AspectJ
|
|
|
+ <classname>MethodInvocation</classname>, AspectJ
|
|
|
<literal>JoinPoint</literal> and web request
|
|
|
- <literal>FilterInvocation</literal>) with complete
|
|
|
+ <classname>FilterInvocation</classname>) with complete
|
|
|
transparency.</para>
|
|
|
</section>
|
|
|
</section>
|
Luke Taylor