diff --git a/src/docbkx/namespace-config.xml b/src/docbkx/namespace-config.xml index b189aa58f2..57298a26c8 100644 --- a/src/docbkx/namespace-config.xml +++ b/src/docbkx/namespace-config.xml @@ -501,7 +501,9 @@ attribute on the <http> element. - 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 technical + overview chapter. diff --git a/src/docbkx/technical-overview.xml b/src/docbkx/technical-overview.xml index 7f7050b207..3ccd18e316 100644 --- a/src/docbkx/technical-overview.xml +++ b/src/docbkx/technical-overview.xml @@ -317,22 +317,27 @@ if (obj instanceof UserDetails) { AuthenticationEntryPoint, an authentication mechanism, and an AuthenticationProvider. - ExceptionTranslationFilter is an Acegi - Security filter that has responsibility for detecting any Acegi - Security exceptions that are thrown. Such exceptions will generally be - thrown by an AbstractSecurityInterceptor, which is - the main provider of authorization services. We will discuss - AbstractSecurityInterceptor 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 ExceptionTranslationFilter - 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 AuthenticationEntryPoint (if the - principal has not been authenticated and therefore we need to go - commence step three). +
+ ExceptionTranslationFilter + ExceptionTranslationFilter is an Acegi + Security filter that has responsibility for detecting any Acegi + Security exceptions that are thrown. Such exceptions will generally be + thrown by an AbstractSecurityInterceptor, which is + the main provider of authorization services. We will discuss + AbstractSecurityInterceptor 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 ExceptionTranslationFilter + 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 AuthenticationEntryPoint (if the + principal has not been authenticated and therefore we need to go + commence step three). +
+
+ AuthenticationEntryPoint The AuthenticationEntryPoint is responsible for step three in the above list. As you can imagine, each web application will have a default authentication strategy (well, this @@ -353,7 +358,9 @@ if (obj instanceof UserDetails) { "Authentication request" object is built and then presented to an AuthenticationProvider. +
+
AuthenticationProvider The last player in the Spring Security authentication process is an AuthenticationProvider. Quite simply, it is responsible for taking an Authentication request @@ -374,38 +381,42 @@ if (obj instanceof UserDetails) { within the UserDetails object - will be used when building the fully populated Authentication object. - After the authentication mechanism receives back the - fully-populated Authentication object, it will deem - the request valid, put the Authentication into the - SecurityContextHolder, and cause the original - request to be retried (step seven above). If, on the other hand, the - AuthenticationProvider rejected the request, the - authentication mechanism will ask the user agent to retry (step two - above). - - Whilst this describes the typical authentication workflow, the - good news is that Spring Security doesn't mind how you put an - Authentication inside the - SecurityContextHolder. The only critical - requirement is that the SecurityContextHolder - contains an Authentication that represents a - principal before the AbstractSecurityInterceptor - needs to authorize a request. - - You can (and many users do) write their own filters or MVC - controllers to provide interoperability with authentication systems - that are not based on Spring Security. For example, you might be using - Container Managed Authentication which makes the current user - available from a ThreadLocal or JNDI location. Or you might work for a - company that has a legacy proprietary authentication system, which is - a corporate "standard" over which you have little control. In such - situations it's quite easy to get Spring Security to work, and still - 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. + fully-populated Authentication object, it will deem + the request valid, put the Authentication into the + SecurityContextHolder, and cause the original + request to be retried (step seven above). If, on the other hand, the + AuthenticationProvider rejected the request, the + authentication mechanism will ask the user agent to retry (step two + above). + +
+ +
+ Setting the SecurityContextHolder Contents Directly + Whilst this describes the typical authentication workflow, the + good news is that Spring Security doesn't mind how you put an + Authentication inside the + SecurityContextHolder. The only critical + requirement is that the SecurityContextHolder + contains an Authentication that represents a + principal before the AbstractSecurityInterceptor + needs to authorize a request. + + You can (and many users do) write their own filters or MVC + controllers to provide interoperability with authentication systems + that are not based on Spring Security. For example, you might be using + Container-Managed Authentication which makes the current user + available from a ThreadLocal or JNDI location. Or you might work for a + company that has a legacy proprietary authentication system, which is + a corporate "standard" over which you have little control. In such + situations it's quite easy to get Spring Security to work, and still + 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. +