diff --git a/docs/manual/src/docbook/anon-auth-provider.xml b/docs/manual/src/docbook/anon-auth-provider.xml index d36f75212f..7059fcc6da 100644 --- a/docs/manual/src/docbook/anon-auth-provider.xml +++ b/docs/manual/src/docbook/anon-auth-provider.xml @@ -78,7 +78,7 @@ it is possible for an authenticating client to construct the Authentication object (such as with RMI invocations), then a malicious client could submit an - AnonyousAuthenticationToken which it had created + AnonymousAuthenticationToken which it had created itself (with chosen username and authority list). If the key is guessable or can be found out, then the token would be accepted by the anonymous provider. This isn't a problem with normal usage but if you are using @@ -132,7 +132,7 @@ the use of the AuthenticatedVoter which we will see in the authorization chapter. It uses an AuthenticationTrustResolver to process this - particular configuration attribute and grant access to aonymous users. The + particular configuration attribute and grant access to anonymous users. The AuthenticatedVoter approach is more powerful, since it allows you to differentiate between anonymous, remember-me and fully-authenticated users. If you don't need this functionality though, then you can stick with diff --git a/docs/manual/src/docbook/appendix-namespace.xml b/docs/manual/src/docbook/appendix-namespace.xml index 02f4825312..d620614495 100644 --- a/docs/manual/src/docbook/appendix-namespace.xml +++ b/docs/manual/src/docbook/appendix-namespace.xml @@ -453,7 +453,7 @@
The <literal><authentication-manager></literal> Element Every Spring Security application which uses the namespace must have include this - element somewhere. It is resposible for registering the + element somewhere. It is responsible for registering the AuthenticationManager which provides authentication services to the application. It also allows you to define an alias name for the internal instance for use in your own configuration. Its use is described in the <literal>DaoAuthenticationProvider</literal> The simplest AuthenticationProvider implemented by - Spring Security is DaoAuthenticationProvider, which is is also - one of the earliest supported by the framework. It leverages a + Spring Security is DaoAuthenticationProvider, which is also one + of the earliest supported by the framework. It leverages a UserDetailsService (as a DAO) in order to lookup the username, password and GrantedAuthoritys. It authenticates the user simply by comparing the password submitted in a @@ -206,7 +206,7 @@ Password Encoding Spring Security's PasswordEncoder interface is used to support the use of passwords which are encoded in some way in persistent storage. This - will normally mean that the passwords are hashed using a digest alogirthm + will normally mean that the passwords are hashed using a digest algorithm such as MD5 or SHA.
What is a hash? diff --git a/docs/manual/src/docbook/el-access.xml b/docs/manual/src/docbook/el-access.xml index d7f0df4955..258a8930ec 100644 --- a/docs/manual/src/docbook/el-access.xml +++ b/docs/manual/src/docbook/el-access.xml @@ -15,7 +15,7 @@ Security uses specific classes for web and method security as the root object, in order to provide built-in expressions and access to values such as the current principal. -
+
Common Built-In Expressions The base class for expression root objects is SecurityExpressionRoot. This provides some common @@ -79,8 +79,8 @@ isFullyAuthenticated() - Returns true if the user is not an anonyous or - a remember-me user + Returns true if the user is not an anonymous + or a remember-me user @@ -121,7 +121,7 @@ Method security is a bit more complicated than a simple allow or deny rule. Spring Security 3.0 introduced some new annotations in order to allow comprehensive support for the use of expressions. -
+
<literal>@Pre</literal> and <literal>@Post</literal> Annotations There are four annotations which support expression attributes to allow pre and post-invocation authorization checks and also to support filtering of submitted @@ -147,13 +147,13 @@ we're actually using a method argument as part of the expression to decide whether the current user has the adminpermission for the given contact. The built-in hasPermission() expression is linked - into the Spring Security ACL module through the application context, as we'll - see - below. You can access any of the method arguments by name as expression variables, provided - your code has debug information compiled in. Any Spring-EL functionality is - available within the expression, so you can also access properties on the - arguments. For example, if you wanted a particular method to only allow access - to a user whose username matched that of the contact, you could write + into the Spring Security ACL module through the application context, as we'll + see below. You can access + any of the method arguments by name as expression variables, provided your code + has debug information compiled in. Any Spring-EL functionality is available + within the expression, so you can also access properties on the arguments. For + example, if you wanted a particular method to only allow access to a user whose + username matched that of the contact, you could write @PreAuthorize("#contact.name == principal.name)") public void doSomething(Contact contact); Here we are accessing another built–in expression, which is the @@ -196,7 +196,7 @@ we have already seen in use above. The filterTarget and returnValue values are simple enough, but the use of the hasPermission() expression warrants a closer look. -
+
The <interfacename>PermissionEvaluator</interfacename> interface hasPermission() expressions are delegated to an instance of PermissionEvaluator. It is intended to bridge @@ -220,18 +220,16 @@ long as it is consistent with how the permissions are loaded. To use hasPermission() expressions, you have to explicitly configure a PermissionEvaluator in your - application context. This would look something like - this: + application context. This would look something like this: - ]]>Where - myPermissionEvaluator is the bean which implements - PermissionEvaluator. Usually this will be the - implementation from the ACL module which is called + ]]>Where myPermissionEvaluator is the bean which + implements PermissionEvaluator. Usually this will + be the implementation from the ACL module which is called AclPermissionEvaluator. See the Contacts sample application configuration for more details. diff --git a/docs/manual/src/docbook/introduction.xml b/docs/manual/src/docbook/introduction.xml index dbd629fd9c..cc9b272fab 100644 --- a/docs/manual/src/docbook/introduction.xml +++ b/docs/manual/src/docbook/introduction.xml @@ -21,10 +21,10 @@ customisable security features. As you probably know two major areas of application security are authentication and authorization (or - access-control). These are the the two main areas that Spring - Security targets. Authentication is the process of establishing a - principal is who they claim to be (a principal generally means a user, - device or some other system which can perform an action in your application). + access-control). These are the two main areas that Spring Security + targets. Authentication is the process of establishing a principal is who + they claim to be (a principal generally means a user, device or some + other system which can perform an action in your application). Authorization refers to the process of deciding whether a principal is allowed to perform an action within your application. To arrive at the point where an authorization decision is needed, the identity of the principal has already been diff --git a/docs/manual/src/docbook/jaas-auth-provider.xml b/docs/manual/src/docbook/jaas-auth-provider.xml index cd2a322dd1..6ac29162a8 100644 --- a/docs/manual/src/docbook/jaas-auth-provider.xml +++ b/docs/manual/src/docbook/jaas-auth-provider.xml @@ -80,7 +80,7 @@ JAASTest { internal mechanics. For those needing full control over the callback behavior, - internally JaasAutheticationProvider wraps these + internally JaasAuthenticationProvider wraps these JaasAuthenticationCallbackHandlers with an InternalCallbackHandler. The InternalCallbackHandler is the class that diff --git a/docs/manual/src/docbook/ldap-auth-provider.xml b/docs/manual/src/docbook/ldap-auth-provider.xml index d22bf3e350..2800cd1fd1 100644 --- a/docs/manual/src/docbook/ldap-auth-provider.xml +++ b/docs/manual/src/docbook/ldap-auth-provider.xml @@ -254,7 +254,7 @@ LDAP Search Objects - Often more a more complicated strategy than simple DN-matching is required to + Often a more complicated strategy than simple DN-matching is required to locate a user entry in the directory. This can be encapsulated in an LdapUserSearch instance which can be supplied to the authenticator implementations, for example, to allow them to locate a user. The @@ -372,7 +372,7 @@ public interface UserDetailsContextMapper { parameter is the name used to authenticate and the final parameter is the collection of authorities loaded for the user. The way the context data is loaded varies slightly depending on the type of - authentication you are using. With the BindAuthenticatior, + authentication you are using. With the BindAuthenticator, the context returned from the bind operation will be used to read the attributes, otherwise the data will be read using the standard context obtained from the configured ContextSource (when a search is configured diff --git a/docs/manual/src/docbook/namespace-config.xml b/docs/manual/src/docbook/namespace-config.xml index c9681d4059..803b2375a9 100644 --- a/docs/manual/src/docbook/namespace-config.xml +++ b/docs/manual/src/docbook/namespace-config.xml @@ -21,13 +21,13 @@ ]]> 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 ldap-server element and the user is isolated from worrying about which - beans they need to create and what the bean property names are. - You can find out more about the use of the ldap-server element in - the chapter on LDAP. - . 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 SpringSource Tool - Suite as it has special features for working with standard Spring namespaces. + beans they need to create and what the bean property names are. You can find + out more about the use of the ldap-server element in the chapter on + LDAP.. 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 SpringSource Tool Suite as it + has special features for working with standard Spring namespaces. 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: 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: - - + following areas: Web/HTTP Security - 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. - - - + secure URLs, render login and error pages and much + more. Business Object (Method) Security - options for securing the - service layer. - - - + service layer. AuthenticationManager - handles authentication requests from - other parts of the framework. - - - + other parts of the framework. AccessDecisionManager - 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. - - - + custom one, declared using normal Spring bean + syntax. AuthenticationProviders - 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. - - - + traditional syntax. UserDetailsService - closely related to authentication providers, - but often also required by other beans. - + but often also required by other beans. We'll see how to configure these in the following sections. @@ -151,12 +135,12 @@ comparison with the user's authorities should be made. In other words, a normal role-based check should be used. Access-control in Spring Security is not limited to the use of simple roles (hence the use of the prefix to differentiate between different types of security - attributes). We'll see later how the interpretation can vary - The interpretation of the comma-separated values in the access - attribute depends on the implementation of the The + interpretation of the comma-separated values in the access attribute + depends on the implementation of the AccessDecisionManager which is used. In Spring Security 3.0, the attribute can - also be populated with an EL expression. - . + also be populated with an EL + expression.. You can use multiple <intercept-url> elements to define different access requirements for different sets of URLs, but they will be evaluated in @@ -220,15 +204,14 @@ ]]> These other elements are responsible for setting up form-login, basic - authentication and logout handling services respectively - 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 AnonymousAuthenticationFilter is part - of the default <http> configuration, so the - <anonymous /> element is added regardless of whether - auto-config is enabled. - . They each have attributes which can be used to alter their behaviour. - + authentication and logout handling services respectively 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 AnonymousAuthenticationFilter is part of the default + <http> configuration, so the <anonymous + /> element is added regardless of whether auto-config + is enabled. . They each have attributes which can be used to alter + their behaviour.
Form and Basic Login Options @@ -249,16 +232,15 @@ Note that you can still use auto-config. The form-login element just overrides the default settings. Also note that we've added an extra intercept-url element to say that any - requests for the login page should be available to anonymous users - See the chapter on anonymous authentication - and also the AuthenticatedVoter - class for more details on how the value - IS_AUTHENTICATED_ANONYMOUSLY is processed. - . Otherwise the request would be matched by the pattern /** - 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 See the + chapter on anonymous authentication and also the + AuthenticatedVoter class for + more details on how the value IS_AUTHENTICATED_ANONYMOUSLY is + processed.. Otherwise the request would be matched by the pattern + /** 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: @@ -479,20 +461,14 @@ logs in. If you don't require this protection, or it conflicts with some other requirement, you can control the behaviour using the session-fixation-protection attribute on - <session-management>, which has three options - - migrateSession - creates a new session and copies the - existing session attributes to the new session. This is the default. - - - none - Don't do anything. The original session will be - retained. - - - newSession - Create a new "clean" session, without copying - the existing session data. - - + <session-management>, which has three options + migrateSession - creates a new + session and copies the existing session attributes to the new session. This is the + default.none - Don't do + anything. The original session will be + retained.newSession - Create + a new "clean" session, without copying the existing session + data.
@@ -558,112 +534,48 @@ List<OpenIDAttribute> attributes = token.getAttributes();The 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. - 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 <http> element, so the - syntax has changed slightly in 3.0. - The filters, aliases and namespace elements/attributes which create the filters are - shown in . The filters are listed in the order in which they - occur in the filter chain. - Standard Filter Aliases and Ordering - - - - Alias - Filter Class - Namespace Element or Attribute - - - - - CHANNEL_FILTER - ChannelProcessingFilter - http/intercept-url@requires-channel - - - CONCURRENT_SESSION_FILTER - ConcurrentSessionFilter - - session-management/concurrency-control - - - SECURITY_CONTEXT_FILTER - SecurityContextPersistenceFilter - http - - - LOGOUT_FILTER - LogoutFilter - http/logout - - - X509_FILTER - X509AuthenticationFilter - http/x509 - - - PRE_AUTH_FILTER - AstractPreAuthenticatedProcessingFilter Subclasses - N/A - - - CAS_FILTER - CasAuthenticationFilter - N/A - - - FORM_LOGIN_FILTER - UsernamePasswordAuthenticationFilter - http/form-login - - - BASIC_AUTH_FILTER - BasicAuthenticationFilter - http/http-basic - - - SERVLET_API_SUPPORT_FILTER - SecurityContextHolderAwareFilter - http/@servlet-api-provision - - - REMEMBER_ME_FILTER - RememberMeAuthenticationFilter - http/remember-me - - - ANONYMOUS_FILTER - AnonymousAuthenticationFilter - http/anonymous - - - SESSION_MANAGEMENT_FILTER - SessionManagementFilter - session-management - - - EXCEPTION_TRANSLATION_FILTER - ExceptionTranslationFilter - http - - - FILTER_SECURITY_INTERCEPTOR - FilterSecurityInterceptor - http - - - SWITCH_USER_FILTER - SwitchUserFilter - N/A - - - -
You can add your own filter to the stack, using the - custom-filter element and one of these names to specify the position - your filter should appear at: 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 + <http> element, so the syntax has changed slightly in + 3.0.The filters, aliases and namespace elements/attributes which create + the filters are shown in . The filters are listed in the order + in which they occur in the filter chain. Standard Filter + Aliases and OrderingAliasFilter ClassNamespace Element or + Attribute + CHANNEL_FILTERChannelProcessingFilterhttp/intercept-url@requires-channel + CONCURRENT_SESSION_FILTERConcurrentSessionFilter + session-management/concurrency-control + SECURITY_CONTEXT_FILTERSecurityContextPersistenceFilterhttp + LOGOUT_FILTER + LogoutFilterhttp/logout + X509_FILTER + X509AuthenticationFilterhttp/x509 + PRE_AUTH_FILTER + AstractPreAuthenticatedProcessingFilter + SubclassesN/A CAS_FILTER + CasAuthenticationFilterN/A + FORM_LOGIN_FILTER + UsernamePasswordAuthenticationFilterhttp/form-login + BASIC_AUTH_FILTER + BasicAuthenticationFilterhttp/http-basic + SERVLET_API_SUPPORT_FILTERSecurityContextHolderAwareFilterhttp/@servlet-api-provision + REMEMBER_ME_FILTER + RememberMeAuthenticationFilterhttp/remember-me + ANONYMOUS_FILTER + AnonymousAuthenticationFilterhttp/anonymous + SESSION_MANAGEMENT_FILTERSessionManagementFiltersession-managementEXCEPTION_TRANSLATION_FILTER + ExceptionTranslationFilterhttp + FILTER_SECURITY_INTERCEPTOR + FilterSecurityInterceptorhttp + SWITCH_USER_FILTER + SwitchUserFilterN/A
+ You can add your own filter to the stack, using the custom-filter element + and one of these names to specify the position your filter should appear at: @@ -815,12 +727,12 @@ List<OpenIDAttribute> attributes = token.getAttributes();The The main interface which provides authentication services in Spring Security is the AuthenticationManager. This is usually an instance of Spring Security's ProviderManager class, which you may already be familiar - with if you've used the framework before. If not, it will be covered later, in . The bean instance is registered using the - authentication-manager namespace element. You can't use a custom - AuthenticationManager if you are using either HTTP or method security - through the namespace, but this should not be a problem as you have full control over the - AuthenticationProviders that are used. + with if you've used the framework before. If not, it will be covered later, in the technical overview chapter. The bean instance + is registered using the authentication-manager namespace element. You can't + use a custom AuthenticationManager if you are using either HTTP or + method security through the namespace, but this should not be a problem as you have full + control over the AuthenticationProviders that are used. You may want to register additional AuthenticationProvider beans with the ProviderManager and you can do this using the <authentication-provider> element with the ref diff --git a/docs/manual/src/docbook/preauth.xml b/docs/manual/src/docbook/preauth.xml index a8fc73f57f..329f846546 100644 --- a/docs/manual/src/docbook/preauth.xml +++ b/docs/manual/src/docbook/preauth.xml @@ -26,7 +26,7 @@ in a structured fashion, without having to write everything from scratch. You don't need to know about these classes if you want to use something like X.509 authentication, as it already has a namespace configuration option which is simpler - to use and get started with. If you need to use explicit bean confiuration or are planning on + to use and get started with. If you need to use explicit bean configuration or are planning on writing your own implementation then an understanding of how the provided implementations work will be useful. You will find classes under the org.springframework.security.web.authentication.preauth. We just provide @@ -122,7 +122,7 @@
Request-Header Authentication (Siteminder) An external authentication system may supply information to the application by setting - specific headers on the HTTP request. A well known example of this is is Siteminder, which + specific headers on the HTTP request. A well known example of this is Siteminder, which passes the username in a header called SM_USER. This mechanism is supported by the class RequestHeaderAuthenticationFilter which simply extracts the username from the header. It defaults to using the name @@ -132,7 +132,7 @@ checks at all and it is extremely important that the external system is configured properly and protects all access to the application. If an attacker is able to forge the headers in their original request without this being detected then they could - potentially choose any userame they wished. + potentially choose any username they wished.
Siteminder Example Configuration @@ -177,7 +177,7 @@ class="org.springframework.security.web.authentication.preauth.PreAuthenticatedA J2EE Container Authentication The class J2eePreAuthenticatedProcessingFilter will extract the username from the userPrincipal property of the - HttpServletRequest. use of this filter would usually be + HttpServletRequest. Use of this filter would usually be combined with the use of J2EE roles as described above in . There is a sample application in the codebase which uses this approach, so get hold of diff --git a/docs/manual/src/docbook/remember-me-authentication.xml b/docs/manual/src/docbook/remember-me-authentication.xml index 7de289626e..582e064221 100644 --- a/docs/manual/src/docbook/remember-me-authentication.xml +++ b/docs/manual/src/docbook/remember-me-authentication.xml @@ -64,12 +64,11 @@ This approach is based on the article http://jaspan.com/improved_persistent_login_cookie_best_practice with some - minor modifications - Essentially, the username is not included in the cookie, to prevent exposing a - valid login name unecessarily. There is a discussion on this in the comments - section of this article. - . To use the this approach with namespace configuration, you would supply a - datasource reference: Essentially, the username is not included in the + cookie, to prevent exposing a valid login name unecessarily. There is a + discussion on this in the comments section of this article.. + To use the this approach with namespace configuration, you would supply a datasource + reference: ... @@ -110,7 +109,7 @@ authentication-related events, and delegates to the implementation whenever a candidate web request might contain a cookie and wish to be remembered. This design allows any number of remember-me implementation strategies. We've seen above that Spring Security - provides two implementations. We'll look at thes in turn. + provides two implementations. We'll look at these in turn.
TokenBasedRememberMeServices This implementation supports the simpler approach described in This class can be used in the same way as TokenBasedRememberMeServices, but it additionally needs to be configured with a PersistentTokenRepository to - store the tokens. There are two standard implementations. - - InMemoryTokenRepositoryImpl which is intended - for testing only. - - - JdbcTokenRepositoryImpl which stores the tokens - in a database. - - The database schema is described above in InMemoryTokenRepositoryImpl + which is intended for testing + only.JdbcTokenRepositoryImpl + which stores the tokens in a database. + The database schema is described above in .
diff --git a/docs/manual/src/docbook/secured-objects.xml b/docs/manual/src/docbook/secured-objects.xml index b324050754..a65794a629 100644 --- a/docs/manual/src/docbook/secured-objects.xml +++ b/docs/manual/src/docbook/secured-objects.xml @@ -24,7 +24,7 @@ <intercept-methods> or <protect-point> elements. Other implementations will be used to handle annotation-based configuration.
- Explicit MethodSecurityIterceptor Configuration + Explicit MethodSecurityInterceptor Configuration You can of course configure a MethodSecurityIterceptor directly in your application context for use with one of Spring AOP's proxying mechanisms: SessionManagementFilter The SessionManagementFilter checks the contents of the SecurityContextRepository against the current contents of the - SecurityContextHolder to deterine whether a user has been + SecurityContextHolder to determine whether a user has been authenticated during the current request, typically by a non-interactive authentication mechanism, such as pre-authentication or remember-me Authentication by mechanisms which perform a redirect after authenticating (such as form-login) will not be diff --git a/docs/manual/src/docbook/technical-overview.xml b/docs/manual/src/docbook/technical-overview.xml index 6d3e13d698..21e813d692 100644 --- a/docs/manual/src/docbook/technical-overview.xml +++ b/docs/manual/src/docbook/technical-overview.xml @@ -46,7 +46,7 @@ because of the specific way they work with threads. For example, a Swing client might want all threads in a Java Virtual Machine to use the same security context. SecurityContextHolder can be configured with a strategy on startup - to specify how you would like the contex to be stored. For a standalone application you + to specify how you would like the context to be stored. For a standalone application you would use the SecurityContextHolder.MODE_GLOBAL strategy. Other applications might want to have threads spawned by the secure thread also assume the same security identity. This is achieved by using @@ -76,7 +76,7 @@ if (principal instanceof UserDetails) { } The object returned by the call to getContext() is an instance of the SecurityContext interface. This is the - object that is kept in thread-local storage. As we'll see below, Most authentication + object that is kept in thread-local storage. As we'll see below, most authentication mechanisms withing Spring Security return an instance of UserDetails as the principal.
@@ -189,50 +189,31 @@ if (principal instanceof UserDetails) { own proprietary authentication system.
What is authentication in Spring Security? - Let's consider a standard authentication scenario that everyone is familiar with. - - A user is prompted to log in with a username and password. - - - The system (successfully) verifies that the password is correct for the - username. - - - The context information for that user is obtained (their list of roles and so - on). - - - A security context is established for the user - - - The user proceeds, potentially to perform some operation which is potentially - protected by an access control mechanism which checks the required permissions for the - operation against the current security context information. - - The first three items constitute the authentication process so we'll take a - look at how these take place within Spring Security. - - The username and password are obtained and combined into an instance of + Let's consider a standard authentication scenario that everyone is familiar with. + A user is prompted to log in with a username and + password.The system (successfully) verifies that the + password is correct for the username.The context + information for that user is obtained (their list of roles and so + on).A security context is established for the + userThe user proceeds, potentially to perform some + operation which is potentially protected by an access control mechanism which checks + the required permissions for the operation against the current security context + information. The first three items constitute the + authentication process so we'll take a look at how these take place within Spring + Security.The username and password are obtained and + combined into an instance of UsernamePasswordAuthenticationToken (an instance of the Authentication interface, which we saw - earlier). - - - The token is passed to an instance of - AuthenticationManager for validation. - - - The AuthenticationManager returns a fully populated + earlier).The token is passed to an instance of + AuthenticationManager for + validation.The + AuthenticationManager returns a fully populated Authentication instance on successful - authentication. - - - The security context is established by calling - SecurityContextHolder.getContext().setAuthentication(...), passing in - the returned authentication object. - - From that point on, the user is considered to be authenticated. Let's look at - some code as an example. + authentication.The security context is established + by calling SecurityContextHolder.getContext().setAuthentication(...), + passing in the returned authentication object.From + that point on, the user is considered to be authenticated. Let's look at some code as an + example. import org.springframework.security.authentication.*; import org.springframework.security.core.*; import org.springframework.security.core.authority.GrantedAuthorityImpl; @@ -375,7 +356,7 @@ Successfully authenticated. Security context contains: \ The main participants (in the order that they are used) are the ExceptionTranslationFilter, an AuthenticationEntryPoint and an authentication - mechanism, which is resposible for calling the + mechanism, which is responsible for calling the AuthenticationManager which we saw in the previous section.
ExceptionTranslationFilter @@ -461,7 +442,7 @@ Successfully authenticated. Security context contains: \
Access-Control (Authorization) in Spring Security - The main interface resposible for making access-control decisions in Spring Security is + The main interface responsible for making access-control decisions in Spring Security is the AccessDecisionManager. It has a decide method which takes an Authentication object representing the principal requesting @@ -503,29 +484,17 @@ Successfully authenticated. Security context contains: \ Authentication if the principal has been authenticated. AbstractSecurityInterceptor provides a consistent workflow for - handling secure object requests, typically: - - Look up the configuration attributes associated with the present - request - - - Submitting the secure object, current + handling secure object requests, typically: Look up the + configuration attributes associated with the present + requestSubmitting the secure object, current Authentication and configuration attributes to the AccessDecisionManager for an authorization - decision - - - Optionally change the Authentication under which - the invocation takes place - - - Allow the secure object invocation to proceed (assuming access was granted) - - - Call the AfterInvocationManager if configured, once - the invocation has returned. - - + decisionOptionally change the + Authentication under which the invocation takes + placeAllow the secure object invocation to proceed + (assuming access was granted)Call the + AfterInvocationManager if configured, once the + invocation has returned.
What are Configuration Attributes? A configuration attribute can be thought of as a String that has @@ -550,9 +519,9 @@ Successfully authenticated. Security context contains: \ AccessDecisionManager implementation. The use of the prefix ROLE_ is a marker to indicate that these attributes are roles and should be consumed by Spring Security's RoleVoter. This is only - relevant when a voter-based AccessDecisionManager is in - use. We'll see how the AccessDecisionManager is - implemented in the authorization chapter. + relevant when a voter-based AccessDecisionManager is in + use. We'll see how the AccessDecisionManager is implemented + in the authorization chapter.
RunAsManager @@ -583,14 +552,10 @@ Successfully authenticated. Security context contains: \ or not change it in any way as it chooses. AbstractSecurityInterceptor and its related objects are shown in .
- Security interceptors and the <quote>secure object</quote> model - - + xml:id="abstract-security-interceptor">Security interceptors and the + <quote>secure object</quote> model - - -
+
Extending the Secure Object Model