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

SEC-624: Minor updates to docs

This commit is contained in:
Luke Taylor 2008-05-13 17:16:19 +00:00
parent 7a8eec11da
commit 332f8fe5a1
2 changed files with 60 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
src/docbkx/namespace-config.xml
View File

@ -501,7 +501,9 @@
attribute on the <literal>&lt;http&gt;</literal> element. attribute on the <literal>&lt;http&gt;</literal> element.
</para> </para>
<para> <para>
The CAS sample is a good example of the use of custom beans with the namespace, including this syntax. The CAS sample is a good example of the use of custom beans with the namespace, including this syntax. If you aren't
familiar with authentication entry points, they are discussed in the <link xlink:href="#tech-auth-entry-point">technical
overview</link> chapter.
</para> </para>
</section> </section>

103
src/docbkx/technical-overview.xml
View File

@ -317,22 +317,27 @@ if (obj instanceof UserDetails) {
<literal>AuthenticationEntryPoint</literal>, an authentication <literal>AuthenticationEntryPoint</literal>, an authentication
mechanism, and an <literal>AuthenticationProvider</literal>.</para> mechanism, and an <literal>AuthenticationProvider</literal>.</para>
<para><literal>ExceptionTranslationFilter</literal> is an Acegi <section>
Security filter that has responsibility for detecting any Acegi <title>ExceptionTranslationFilter</title>
Security exceptions that are thrown. Such exceptions will generally be <para><literal>ExceptionTranslationFilter</literal> is an Acegi
thrown by an <literal>AbstractSecurityInterceptor</literal>, which is Security filter that has responsibility for detecting any Acegi
the main provider of authorization services. We will discuss Security exceptions that are thrown. Such exceptions will generally be
<literal>AbstractSecurityInterceptor</literal> in the next section, thrown by an <literal>AbstractSecurityInterceptor</literal>, which is
but for now we just need to know that it produces Java exceptions and the main provider of authorization services. We will discuss
knows nothing about HTTP or how to go about authenticating a <literal>AbstractSecurityInterceptor</literal> in the next section,
principal. Instead the <literal>ExceptionTranslationFilter</literal> but for now we just need to know that it produces Java exceptions and
offers this service, with specific responsibility for either returning knows nothing about HTTP or how to go about authenticating a
error code 403 (if the principal has been authenticated and therefore principal. Instead the <literal>ExceptionTranslationFilter</literal>
simply lacks sufficient access - as per step seven above), or offers this service, with specific responsibility for either returning
launching an <literal>AuthenticationEntryPoint</literal> (if the error code 403 (if the principal has been authenticated and therefore
principal has not been authenticated and therefore we need to go simply lacks sufficient access - as per step seven above), or
commence step three).</para> launching an <literal>AuthenticationEntryPoint</literal> (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 <literal>AuthenticationEntryPoint</literal> is responsible
for step three in the above list. As you can imagine, each web for step three in the above list. As you can imagine, each web
application will have a default authentication strategy (well, this application will have a default authentication strategy (well, this
@ -353,7 +358,9 @@ if (obj instanceof UserDetails) {
"<literal>Authentication</literal> request" object is built and then "<literal>Authentication</literal> request" object is built and then
presented to an presented to an
<interfacename>AuthenticationProvider</interfacename>.</para> <interfacename>AuthenticationProvider</interfacename>.</para>
</section>
<section><title>AuthenticationProvider</title>
<para>The last player in the Spring Security authentication process is <para>The last player in the Spring Security authentication process is
an <literal>AuthenticationProvider</literal>. Quite simply, it is an <literal>AuthenticationProvider</literal>. Quite simply, it is
responsible for taking an <literal>Authentication</literal> request responsible for taking an <literal>Authentication</literal> request
@ -374,38 +381,42 @@ if (obj instanceof UserDetails) {
within the <literal>UserDetails</literal> object - will be used when within the <literal>UserDetails</literal> object - will be used when
building the fully populated <literal>Authentication</literal> building the fully populated <literal>Authentication</literal>
object.</para> object.</para>
<para>After the authentication mechanism receives back the <para>After the authentication mechanism receives back the
fully-populated <literal>Authentication</literal> object, it will deem fully-populated <literal>Authentication</literal> object, it will deem
the request valid, put the <literal>Authentication</literal> into the the request valid, put the <literal>Authentication</literal> into the
<literal>SecurityContextHolder</literal>, and cause the original <literal>SecurityContextHolder</literal>, and cause the original
request to be retried (step seven above). If, on the other hand, the request to be retried (step seven above). If, on the other hand, the
<literal>AuthenticationProvider</literal> rejected the request, the <literal>AuthenticationProvider</literal> rejected the request, the
authentication mechanism will ask the user agent to retry (step two authentication mechanism will ask the user agent to retry (step two
above).</para> above).</para>
<para>Whilst this describes the typical authentication workflow, the </section>
good news is that Spring Security doesn't mind how you put an
<literal>Authentication</literal> inside the <section>
<literal>SecurityContextHolder</literal>. The only critical <title>Setting the SecurityContextHolder Contents Directly</title>
requirement is that the <literal>SecurityContextHolder</literal> <para>Whilst this describes the typical authentication workflow, the
contains an <literal>Authentication</literal> that represents a good news is that Spring Security doesn't mind how you put an
principal before the <literal>AbstractSecurityInterceptor</literal> <literal>Authentication</literal> inside the
needs to authorize a request.</para> <literal>SecurityContextHolder</literal>. The only critical
requirement is that the <literal>SecurityContextHolder</literal>
<para>You can (and many users do) write their own filters or MVC contains an <literal>Authentication</literal> that represents a
controllers to provide interoperability with authentication systems principal before the <literal>AbstractSecurityInterceptor</literal>
that are not based on Spring Security. For example, you might be using needs to authorize a request.</para>
Container Managed Authentication which makes the current user
available from a ThreadLocal or JNDI location. Or you might work for a <para>You can (and many users do) write their own filters or MVC
company that has a legacy proprietary authentication system, which is controllers to provide interoperability with authentication systems
a corporate "standard" over which you have little control. In such that are not based on Spring Security. For example, you might be using
situations it's quite easy to get Spring Security to work, and still Container-Managed Authentication which makes the current user
provide authorization capabilities. All you need to do is write a available from a ThreadLocal or JNDI location. Or you might work for a
filter (or equivalent) that reads the third-party user information company that has a legacy proprietary authentication system, which is
from a location, build a Spring Security-specific Authentication a corporate "standard" over which you have little control. In such
object, and put it onto the SecurityContextHolder. It's quite easy to situations it's quite easy to get Spring Security to work, and still
do this, and it is a fully-supported integration approach.</para> provide authorization capabilities. All you need to do is write a
filter (or equivalent) that reads the third-party user information
from a location, build a Spring Security-specific Authentication
object, and put it onto the SecurityContextHolder. It's quite easy to
do this, and it is a fully-supported integration approach.</para>
</section>
</section> </section>
<section xml:id="secure-objects"> <section xml:id="secure-objects">