From de379dc2acb0fe96280ed62eebc029546e14089b Mon Sep 17 00:00:00 2001 From: Luke Taylor Date: Tue, 2 Sep 2008 01:05:57 +0000 Subject: [PATCH] Converted literals to classname/interfacename docbook tags for easier indexing --- src/docbkx/anon-auth-provider.xml | 18 +- src/docbkx/authorization-common.xml | 136 +++++++------- src/docbkx/basic-authentication.xml | 10 +- src/docbkx/cas-auth-provider.xml | 38 ++-- src/docbkx/channel-security.xml | 8 +- src/docbkx/common-auth-services.xml | 84 ++++----- src/docbkx/container-adapters.xml | 24 +-- src/docbkx/dao-auth-provider.xml | 22 +-- src/docbkx/digest-authentication.xml | 8 +- src/docbkx/domain-acls.xml | 32 ++-- src/docbkx/form-authentication.xml | 10 +- src/docbkx/jaas-auth-provider.xml | 10 +- src/docbkx/ldap-auth-provider.xml | 2 +- src/docbkx/namespace-config.xml | 20 +-- src/docbkx/preauth.xml | 2 +- src/docbkx/remember-me-authentication.xml | 16 +- src/docbkx/runas-auth-provider.xml | 36 ++-- src/docbkx/samples.xml | 2 +- src/docbkx/secured-objects.xml | 54 +++--- src/docbkx/siteminder-auth-provider.xml | 8 +- src/docbkx/springsecurity.xml | 4 +- src/docbkx/supporting-infrastructure.xml | 64 +++---- src/docbkx/technical-overview.xml | 210 +++++++++++----------- src/docbkx/x509-auth-provider.xml | 2 +- 24 files changed, 410 insertions(+), 410 deletions(-) diff --git a/src/docbkx/anon-auth-provider.xml b/src/docbkx/anon-auth-provider.xml index 6ff00ed036..a37365fd95 100644 --- a/src/docbkx/anon-auth-provider.xml +++ b/src/docbkx/anon-auth-provider.xml @@ -14,11 +14,11 @@ logout and home pages of an application. There are also other situations where anonymous authentication would be desired, such as when an auditing interceptor queries the - SecurityContextHolder to identify which principal + SecurityContextHolder to identify which principal was responsible for a given operation. Such classes can be authored with more robustness if they know the - SecurityContextHolder always contains an - Authentication object, and never + SecurityContextHolder always contains an + Authentication object, and never null. @@ -28,8 +28,8 @@ Spring Security provides three classes that together provide an anonymous authentication feature. AnonymousAuthenticationToken is an implementation - of Authentication, and stores the - GrantedAuthority[]s which apply to the anonymous + of Authentication, and stores the + GrantedAuthority[]s which apply to the anonymous principal. There is a corresponding AnonymousAuthenticationProvider, which is chained into the ProviderManager so that @@ -37,8 +37,8 @@ Finally, there is an AnonymousProcessingFilter, which is chained after the normal authentication mechanisms and automatically add an AnonymousAuthenticationToken to the - SecurityContextHolder if there is no existing - Authentication held there. The definition of the + SecurityContextHolder if there is no existing + Authentication held there. The definition of the filter and authentication provider appears as follows: @@ -91,12 +91,12 @@ isAnonymous(Authentication) method, which allows interested classes to take into account this special type of authentication status. The - ExceptionTranslationFilter uses this interface in + ExceptionTranslationFilter uses this interface in processing AccessDeniedExceptions. If an AccessDeniedException is thrown, and the authentication is of an anonymous type, instead of throwing a 403 (forbidden) response, the filter will instead commence the - AuthenticationEntryPoint so the principal can + AuthenticationEntryPoint so the principal can authenticate properly. This is a necessary distinction, otherwise principals would always be deemed "authenticated" and never be given an opportunity to login via form, basic, digest or some other normal diff --git a/src/docbkx/authorization-common.xml b/src/docbkx/authorization-common.xml index 6352410371..1640365e14 100644 --- a/src/docbkx/authorization-common.xml +++ b/src/docbkx/authorization-common.xml @@ -5,50 +5,50 @@ Authorities As briefly mentioned in the Authentication section, all - Authentication implementations are required to - store an array of GrantedAuthority objects. These + Authentication implementations are required to + store an array of GrantedAuthority objects. These represent the authorities that have been granted to the principal. The - GrantedAuthority objects are inserted into the - Authentication object by the - AuthenticationManager and are later read by - AccessDecisionManagers when making authorization + GrantedAuthority objects are inserted into the + Authentication object by the + AuthenticationManager and are later read by + AccessDecisionManagers when making authorization decisions. - GrantedAuthority is an interface with only + GrantedAuthority is an interface with only one method: String getAuthority(); - This method allows AccessDecisionManagers to + This method allows AccessDecisionManagers to obtain a precise String representation of the - GrantedAuthority. By returning a representation as - a String, a GrantedAuthority can - be easily "read" by most AccessDecisionManagers. If - a GrantedAuthority cannot be precisely represented + GrantedAuthority. By returning a representation as + a String, a GrantedAuthority can + be easily "read" by most AccessDecisionManagers. If + a GrantedAuthority cannot be precisely represented as a String, the - GrantedAuthority is considered "complex" and + GrantedAuthority is considered "complex" and getAuthority() must return null. - An example of a "complex" GrantedAuthority + An example of a "complex" GrantedAuthority would be an implementation that stores a list of operations and authority thresholds that apply to different customer account numbers. - Representing this complex GrantedAuthority as a + Representing this complex GrantedAuthority as a String would be quite complex, and as a result the getAuthority() method should return null. This will indicate to any - AccessDecisionManager that it will need to - specifically support the GrantedAuthority + AccessDecisionManager that it will need to + specifically support the GrantedAuthority implementation in order to understand its contents. Spring Security includes one concrete - GrantedAuthority implementation, + GrantedAuthority implementation, GrantedAuthorityImpl. This allows any user-specified String to be converted into a - GrantedAuthority. All - AuthenticationProviders included with the security + GrantedAuthority. All + AuthenticationProviders included with the security architecture use GrantedAuthorityImpl to populate - the Authentication object. + the Authentication object.
@@ -64,10 +64,10 @@
The AccessDecisionManager - The AccessDecisionManager is called by the - AbstractSecurityInterceptor and is responsible for + The AccessDecisionManager is called by the + AbstractSecurityInterceptor and is responsible for making final access control decisions. The - AccessDecisionManager interface contains three + AccessDecisionManager interface contains three methods: void decide(Authentication authentication, Object secureObject, ConfigAttributeDefinition config) throws AccessDeniedException; @@ -75,33 +75,33 @@ boolean supports(Class clazz); As can be seen from the first method, the - AccessDecisionManager is passed via method + AccessDecisionManager is passed via method parameters all information that is likely to be of value in assessing an authorization decision. In particular, passing the secure Object enables those arguments contained in the actual secure object invocation to be inspected. For example, let's - assume the secure object was a MethodInvocation. It - would be easy to query the MethodInvocation for any + assume the secure object was a MethodInvocation. It + would be easy to query the MethodInvocation for any Customer argument, and then implement some sort of - security logic in the AccessDecisionManager to + security logic in the AccessDecisionManager to ensure the principal is permitted to operate on that customer. Implementations are expected to throw an AccessDeniedException if access is denied. The supports(ConfigAttribute) method is - called by the AbstractSecurityInterceptor at + called by the AbstractSecurityInterceptor at startup time to determine if the - AccessDecisionManager can process the passed + AccessDecisionManager can process the passed ConfigAttribute. The supports(Class) method is called by a security interceptor implementation to ensure the configured - AccessDecisionManager supports the type of secure + AccessDecisionManager supports the type of secure object that the security interceptor will present.
Voting-Based AccessDecisionManager Implementations - Whilst users can implement their own AccessDecisionManager to control all aspects of - authorization, Spring Security includes several AccessDecisionManager implementations that are + Whilst users can implement their own AccessDecisionManager to control all aspects of + authorization, Spring Security includes several AccessDecisionManager implementations that are based on voting. illustrates the relevant classes.
Voting Decision Manager @@ -115,13 +115,13 @@
Using this approach, a series of - AccessDecisionVoter implementations are polled on + AccessDecisionVoter implementations are polled on an authorization decision. The - AccessDecisionManager then decides whether or not + AccessDecisionManager then decides whether or not to throw an AccessDeniedException based on its assessment of the votes. - The AccessDecisionVoter interface has three + The AccessDecisionVoter interface has three methods: int vote(Authentication authentication, Object object, ConfigAttributeDefinition config); @@ -130,7 +130,7 @@ boolean supports(Class clazz); Concrete implementations return an int, with possible values being reflected in the - AccessDecisionVoter static fields + AccessDecisionVoter static fields ACCESS_ABSTAIN, ACCESS_DENIED and ACCESS_GRANTED. A voting implementation will return ACCESS_ABSTAIN if it has no opinion on an @@ -139,7 +139,7 @@ boolean supports(Class clazz); ACCESS_GRANTED. There are three concrete - AccessDecisionManagers provided with Spring + AccessDecisionManagers provided with Spring Security that tally the votes. The ConsensusBased implementation will grant or deny access based on the consensus of non-abstain votes. Properties are provided to control behavior in the @@ -157,21 +157,21 @@ boolean supports(Class clazz); abstain. It is possible to implement a custom - AccessDecisionManager that tallies votes + AccessDecisionManager that tallies votes differently. For example, votes from a particular - AccessDecisionVoter might receive additional + AccessDecisionVoter might receive additional weighting, whilst a deny vote from a particular voter may have a veto effect.
<classname>RoleVoter</classname> - The most commonly used AccessDecisionVoter + The most commonly used AccessDecisionVoter provided with Spring Security is the simple RoleVoter, which treats configuration attributes as simple role names and votes to grant access if the user has been assigned that role. It will vote if any ConfigAttribute begins with the prefix ROLE_. - It will vote to grant access if there is a GrantedAuthority which returns a + It will vote to grant access if there is a GrantedAuthority which returns a String representation (via the getAuthority() method) exactly equal to one or more ConfigAttributes starting with @@ -222,7 +222,7 @@ boolean supports(Class clazz); In the above example, you'd define ACL_CONTACT_READ or ACL_CONTACT_DELETE against some methods on a - MethodSecurityInterceptor or + MethodSecurityInterceptor or AspectJSecurityInterceptor. When those methods are invoked, the above applicable voter defined above would vote to grant or deny access. The voter would look at the method invocation to @@ -230,7 +230,7 @@ boolean supports(Class clazz); sample.contact.Contact, and then pass that Contact to the AclManager. The AclManager will then return an access control list - (ACL) that applies to the current Authentication. + (ACL) that applies to the current Authentication. Assuming that ACL contains one of the listed requirePermissions, the voter will vote to grant access. If the ACL does not contain one of the permissions defined @@ -252,21 +252,21 @@ boolean supports(Class clazz);
Custom Voters It is also possible to implement a custom - AccessDecisionVoter. Several examples are provided + AccessDecisionVoter. Several examples are provided in Spring Security unit tests, including ContactSecurityVoter and DenyVoter. The ContactSecurityVoter abstains from voting decisions where a CONTACT_OWNED_BY_CURRENT_USER ConfigAttribute is not found. If voting, it queries - the MethodInvocation to extract the owner of the + the MethodInvocation to extract the owner of the Contact object that is subject of the method call. It votes to grant access if the Contact owner matches the principal presented in the - Authentication object. It could have just as easily + Authentication object. It could have just as easily compared the Contact owner with some - GrantedAuthority the - Authentication object presented. All of this is + GrantedAuthority the + Authentication object presented. All of this is achieved with relatively few lines of code and demonstrates the flexibility of the authorization model.
@@ -276,8 +276,8 @@ boolean supports(Class clazz);
After Invocation Handling - Whilst the AccessDecisionManager is called by - the AbstractSecurityInterceptor before proceeding + Whilst the AccessDecisionManager is called by + the AbstractSecurityInterceptor before proceeding with the secure object invocation, some applications need a way of modifying the object actually returned by the secure object invocation. Whilst you could easily implement your own AOP concern to @@ -317,21 +317,21 @@ boolean supports(Class clazz); Please be aware that if you're using AfterInvocationManager, you will still need configuration attributes that allow the - MethodSecurityInterceptor's - AccessDecisionManager to allow an operation. If + MethodSecurityInterceptor's + AccessDecisionManager to allow an operation. If you're using the typical Spring Security included - AccessDecisionManager implementations, having no + AccessDecisionManager implementations, having no configuration attributes defined for a particular secure method - invocation will cause each AccessDecisionVoter to + invocation will cause each AccessDecisionVoter to abstain from voting. In turn, if the - AccessDecisionManager property + AccessDecisionManager property "allowIfAllAbstainDecisions" is false, an AccessDeniedException will be thrown. You may avoid this potential issue by either (i) setting "allowIfAllAbstainDecisions" to true (although this is generally not recommended) or (ii) simply ensure that there is at least one configuration - attribute that an AccessDecisionVoter will vote to + attribute that an AccessDecisionVoter will vote to grant access for. This latter (recommended) approach is usually achieved through a ROLE_USER or ROLE_AUTHENTICATED configuration attribute @@ -357,8 +357,8 @@ boolean supports(Class clazz); Quite often, only principals with permission to read the Contact should be allowed to obtain it. In this - situation the AccessDecisionManager approach - provided by the AbstractSecurityInterceptor will + situation the AccessDecisionManager approach + provided by the AbstractSecurityInterceptor will not suffice. This is because the identity of the Contact is all that is available before the secure object is invoked. The @@ -381,10 +381,10 @@ boolean supports(Class clazz); AclEntryAfterInvocationProvider. The provider will thrown an AccessDeniedException if one of the listed requirePermissions is not held by the - Authentication. The + Authentication. The AclEntryAfterInvocationProvider queries the AclService to determine the ACL that applies for - this domain object to this Authentication. + this domain object to this Authentication. Similar to the AclEntryAfterInvocationProvider is @@ -410,7 +410,7 @@ boolean supports(Class clazz); must be a Collection or array for this provider to operate. It will remove any element if the AclManager indicates the - Authentication does not hold one of the listed + Authentication does not hold one of the listed requirePermissions. The Contacts sample application demonstrates these two @@ -437,8 +437,8 @@ boolean supports(Class clazz); Quite often, only principals with permission to read the Contact should be allowed to obtain it. In this - situation the AccessDecisionManager approach - provided by the AbstractSecurityInterceptor will + situation the AccessDecisionManager approach + provided by the AbstractSecurityInterceptor will not suffice. This is because the identity of the Contact is all that is available before the secure object is invoked. The @@ -463,10 +463,10 @@ boolean supports(Class clazz); BasicAclEntryAfterInvocationProvider. The provider will thrown an AccessDeniedException if one of the listed requirePermissions is not held - by the Authentication. The + by the Authentication. The BasicAclEntryAfterInvocationProvider queries the AclManager to determine the ACL that applies for - this domain object to this Authentication. + this domain object to this Authentication. Similar to the BasicAclEntryAfterInvocationProvider is @@ -492,7 +492,7 @@ boolean supports(Class clazz); must be a Collection or array for this provider to operate. It will remove any element if the AclManager indicates the - Authentication does not hold one of the listed + Authentication does not hold one of the listed requirePermissions. The Contacts sample application demonstrates these two @@ -505,7 +505,7 @@ boolean supports(Class clazz); AuthorizeTag is used to include content if the current principal holds certain - GrantedAuthoritys. + GrantedAuthoritys. The following JSP fragment illustrates how to use the AuthorizeTag: diff --git a/src/docbkx/basic-authentication.xml b/src/docbkx/basic-authentication.xml index a45a4b886d..1abb7fe044 100644 --- a/src/docbkx/basic-authentication.xml +++ b/src/docbkx/basic-authentication.xml @@ -40,21 +40,21 @@ - The configured AuthenticationManager + The configured AuthenticationManager processes each authentication request. If authentication fails, the - configured AuthenticationEntryPoint will be used to + configured AuthenticationEntryPoint will be used to retry the authentication process. Usually you will use the BasicProcessingFilterEntryPoint, which returns a 401 response with a suitable header to retry HTTP Basic authentication. If authentication is successful, the resulting - Authentication object will be placed into the - SecurityContextHolder. + Authentication object will be placed into the + SecurityContextHolder. If the authentication event was successful, or authentication was not attempted because the HTTP header did not contain a supported authentication request, the filter chain will continue as normal. The only time the filter chain will be interrupted is if authentication - fails and the AuthenticationEntryPoint is called, + fails and the AuthenticationEntryPoint is called, as discussed in the previous paragraph
\ No newline at end of file diff --git a/src/docbkx/cas-auth-provider.xml b/src/docbkx/cas-auth-provider.xml index a413fae753..b31a83c194 100644 --- a/src/docbkx/cas-auth-provider.xml +++ b/src/docbkx/cas-auth-provider.xml @@ -71,16 +71,16 @@ The user eventually requests a page that is either secure or one of the beans it uses is secure. Spring Security's - ExceptionTranslationFilter will detect the + ExceptionTranslationFilter will detect the AuthenticationException. - Because the user's Authentication object + Because the user's Authentication object (or lack thereof) caused an AuthenticationException, the - ExceptionTranslationFilter will call the - configured AuthenticationEntryPoint. If using + ExceptionTranslationFilter will call the + configured AuthenticationEntryPoint. If using CAS, this will be the CasProcessingFilterEntryPoint class. @@ -126,11 +126,11 @@ CasProcessingFilter.CAS_STATEFUL_IDENTIFIER, whilst the credentials will be the service ticket opaque value. This authentication request will then be handed to the configured - AuthenticationManager. + AuthenticationManager. - The AuthenticationManager implementation + The AuthenticationManager implementation will be the ProviderManager, which is in turn configured with the CasAuthenticationProvider. The CasAuthenticationProvider only responds to @@ -205,18 +205,18 @@ CasAuthenticationProvider will next request a CasAuthoritiesPopulator to advise the - GrantedAuthority objects that apply to the user + GrantedAuthority objects that apply to the user contained in the TicketResponse. Spring Security includes a DaoCasAuthoritiesPopulator - which simply uses the UserDetailsService - infrastructure to find the UserDetails and - their associated GrantedAuthoritys. Note that + which simply uses the UserDetailsService + infrastructure to find the UserDetails and + their associated GrantedAuthoritys. Note that the password and enabled/disabled status of - UserDetails returned by the - UserDetailsService are ignored, as the CAS + UserDetails returned by the + UserDetailsService are ignored, as the CAS server is responsible for authentication decisions. DaoCasAuthoritiesPopulator is only concerned - with retrieving the GrantedAuthoritys. + with retrieving the GrantedAuthoritys. @@ -224,7 +224,7 @@ CasAuthenticationProvider constructs a CasAuthenticationToken including the details contained in the TicketResponse and the - GrantedAuthoritys. The + GrantedAuthoritys. The CasAuthenticationToken contains the hash of a key, so that the CasAuthenticationProvider knows it created it. @@ -244,12 +244,12 @@ - As the Authentication object is now in + As the Authentication object is now in the well-known location, it is handled like any other authentication approach. Usually the - HttpSessionContextIntegrationFilter will be - used to associate the Authentication object - with the SecurityContextHolder for the duration + HttpSessionContextIntegrationFilter will be + used to associate the Authentication object + with the SecurityContextHolder for the duration of each request. @@ -323,7 +323,7 @@ CasProcessingFilter needs a reference to it. For CAS to operate, the - ExceptionTranslationFilter must have its + ExceptionTranslationFilter must have its authenticationEntryPoint property set to the CasProcessingFilterEntryPoint bean. diff --git a/src/docbkx/channel-security.xml b/src/docbkx/channel-security.xml index 0b77c25dce..9cc477315d 100644 --- a/src/docbkx/channel-security.xml +++ b/src/docbkx/channel-security.xml @@ -66,7 +66,7 @@ ]]> - Like FilterSecurityInterceptor, Apache Ant + Like FilterSecurityInterceptor, Apache Ant style paths are also supported by the ChannelProcessingFilter. @@ -146,15 +146,15 @@ To decide whether a security check belongs in a ChannelProcessor or an - AccessDecisionVoter, remember that the former is + AccessDecisionVoter, remember that the former is designed to handle unauthenticated requests, whilst the latter is designed to handle authenticated requests. The latter therefore has access to the granted authorities of the authenticated principal. In addition, problems detected by a ChannelProcessor will generally cause an HTTP/HTTPS redirection so its requirements can be met, whilst problems detected by an - AccessDecisionVoter will ultimately result in an + AccessDecisionVoter will ultimately result in an AccessDeniedException (depending on the governing - AccessDecisionManager). + AccessDecisionManager).
\ No newline at end of file diff --git a/src/docbkx/common-auth-services.xml b/src/docbkx/common-auth-services.xml index 1130261c2f..92528d62f5 100644 --- a/src/docbkx/common-auth-services.xml +++ b/src/docbkx/common-auth-services.xml @@ -8,8 +8,8 @@ To use Spring Security's authentication services, you'll usually need to configure a web filter, together - with an AuthenticationProvider and - AuthenticationEntryPoint. In this section we are + with an AuthenticationProvider and + AuthenticationEntryPoint. In this section we are going to explore an example application that needs to support both form-based authentication (so a nice HTML page is presented to a user for them to login) and BASIC authentication (so a web service @@ -81,8 +81,8 @@ each of these authentication mechanisms. Recall that - HttpSessionContextIntegrationFilter keeps the - contents of the SecurityContext between invocations + HttpSessionContextIntegrationFilter keeps the + contents of the SecurityContext between invocations inside an HTTP session. This means the authentication mechanisms are only used once, being when the principal initially tries to authenticate. The rest of the time the authentication mechanisms sit @@ -97,13 +97,13 @@ The major authorization provider for secure objects has previously been introduced as - AbstractSecurityInterceptor. This class needs to - have access to an AuthenticationManager. It also + AbstractSecurityInterceptor. This class needs to + have access to an AuthenticationManager. It also has configurable settings to indicate whether an - Authentication object should be re-authenticated on + Authentication object should be re-authenticated on each secure object invocation. By default it just accepts any - Authentication inside the - SecurityContextHolder is authenticated if + Authentication inside the + SecurityContextHolder is authenticated if Authentication.isAuthenticated() returns true. This is great for performance, but not ideal if you want to ensure up-to-the-moment authentication validity. For such cases you'll @@ -112,9 +112,9 @@ property to true. You might be asking yourself, "what's this - AuthenticationManager?". We haven't explored it + AuthenticationManager?". We haven't explored it before, but we have discussed the concept of an - AuthenticationProvider. Quite simply, an + AuthenticationProvider. Quite simply, an AuthenticationManager is responsible for passing requests through a chain of AuthenticationProviders. It's a little like the filter chain we discussed earlier, although there @@ -137,11 +137,11 @@ It's probably worth mentioning at this point that your authentication mechanisms (which are usually filters) are also injected with a reference to the - AuthenticationManager. So both - AbstractSecurityInterceptor as well as the + AuthenticationManager. So both + AbstractSecurityInterceptor as well as the authentication mechanisms will use the above ProviderManager to poll a list of - AuthenticationProviders. + AuthenticationProviders. In our example we have three providers. They are tried in the order shown (which is implied by the use of a List @@ -161,7 +161,7 @@ limited to) BASIC and form authentication. Equally, some authentication mechanisms create an authentication request object which can only be interpreted by a single type of - AuthenticationProvider. An example of this + AuthenticationProvider. An example of this one-to-one mapping would be JA-SIG CAS, which uses the notion of a service ticket which can therefore only be authenticated by CasAuthenticationProvider. A further example of a @@ -176,11 +176,11 @@ to authenticate is made. After configuring the correct authentication mechanisms in the - FilterChainProxy, and ensuring that a corresponding - AuthenticationProvider is registered in the + FilterChainProxy, and ensuring that a corresponding + AuthenticationProvider is registered in the ProviderManager, your last step is to configure an - AuthenticationEntryPoint. Recall that earlier we - discussed the role of ExceptionTranslationFilter, + AuthenticationEntryPoint. Recall that earlier we + discussed the role of ExceptionTranslationFilter, which is used when HTTP-based requests should receive back an HTTP header or HTTP redirect in order to start authentication. Continuing on with our earlier example: @@ -202,12 +202,12 @@ < value="false"/> ]]> - Notice that the ExceptionTranslationFilter + Notice that the ExceptionTranslationFilter requires two collaborators. The first, AccessDeniedHandlerImpl, uses a RequestDispatcher forward to display the specified access denied error page. We use a forward so that the - SecurityContextHolder still contains details of the + SecurityContextHolder still contains details of the principal, which may be useful for display to the user (in old releases of Spring Security we relied upon the servlet container to handle a 403 error message, which lacked this useful contextual @@ -221,7 +221,7 @@ AuthenticationProcessinFilterEntryPoint and the URL of the login page. Your application will usually only have one entry point, and most authentication approaches define their own specific - AuthenticationEntryPoint. Details of which entry + AuthenticationEntryPoint. Details of which entry point to use for each authentication approach is discussed in the authentication approach-specific chapters of this reference guide. @@ -233,43 +233,43 @@ As mentioned in the first part of the reference guide, most authentication providers take advantage of the - UserDetails and - UserDetailsService interfaces. The contract for + UserDetails and + UserDetailsService interfaces. The contract for this latter interface consists of a single method: UserDetails loadUserByUsername(String username) throws UsernameNotFoundException, DataAccessException; - The returned UserDetails is an interface that + The returned UserDetails is an interface that provides getters that guarantee non-null provision of basic authentication information such as the username, password, granted authorities and whether the user is enabled or disabled. Most authentication providers will use a - UserDetailsService, even if the username and + UserDetailsService, even if the username and password are not actually used as part of the authentication decision. Generally such providers will be using the returned - UserDetails object just for its + UserDetails object just for its GrantedAuthority[] information, because some other system (like LDAP or X509 or CAS etc) has undertaken the responsibility of actually validating the credentials. A single concrete implementation of - UserDetails is provided with Spring Security, being + UserDetails is provided with Spring Security, being the User class. Spring Security users will need to - decide when writing their UserDetailsService what - concrete UserDetails class to return. In most cases + decide when writing their UserDetailsService what + concrete UserDetails class to return. In most cases User will be used directly or subclassed, although special circumstances (such as object relational mappers) may require - users to write their own UserDetails implementation + users to write their own UserDetails implementation from scratch. This is not such an unusual situation, and users should not hesitate to simply return their normal domain object that represents a user of the system. This is especially common given that - UserDetails is often used to store additional + UserDetails is often used to store additional principal-related properties (such as their telephone number and email address), so that they can be easily used by web views. - Given UserDetailsService is so simple to + Given UserDetailsService is so simple to implement, it should be easy for users to retrieve authentication information using a persistence strategy of their choice. Having said that, Spring Security does include a couple of useful base @@ -278,12 +278,12 @@
In-Memory Authentication Whilst it is easy to use create a custom - UserDetailsService implementation that extracts + UserDetailsService implementation that extracts information from a persistence engine of choice, many applications do not require such complexity. This is particularly true if you're undertaking a rapid prototype or just starting integrating Spring Security, when you don't really want to spend time configuring - databases or writing UserDetailsService + databases or writing UserDetailsService implementations. For this sort of situation, a simple option is to use the user-service element from the security namespace: @@ -316,7 +316,7 @@ JDBC Authentication Spring Security also includes a - UserDetailsService that can obtain authentication + UserDetailsService that can obtain authentication information from a JDBC data source. Internally Spring JDBC is used, so it avoids the complexity of a fully-featured object relational mapper (ORM) just to store user details. If your application does @@ -372,9 +372,9 @@ customisation of the SQL statements. Please refer to the JavaDocs for details, but note that the class is not intended for complex custom subclasses. If you have a complex schema or would like a - custom UserDetails implementation returned, + custom UserDetails implementation returned, you'd be better off writing your own - UserDetailsService. The base implementation + UserDetailsService. The base implementation provided with Spring Security is intended for typical situations, rather than catering for all possible requirements.
@@ -403,7 +403,7 @@ In addition, you will need to add the org.springframework.security.concurrent.ConcurrentSessionFilter - to your FilterChainProxy. The + to your FilterChainProxy. The ConcurrentSessionFilter requires two properties, sessionRegistry, which generally points to an instance of SessionRegistryImpl, and @@ -446,7 +446,7 @@ Authentication Tag Libraries AuthenticationTag is used to simply output a - property of the current Authentication object to the web + property of the current Authentication object to the web page. The following JSP fragment illustrates how to use the @@ -456,8 +456,8 @@ This tag would cause the principal's name to be output. Here we are assuming the Authentication.getPrincipal() is a - UserDetails object, which is generally the case - when using one of Spring Security's stadard AuthenticationProvider + UserDetails object, which is generally the case + when using one of Spring Security's stadard AuthenticationProvider implementations.
\ No newline at end of file diff --git a/src/docbkx/container-adapters.xml b/src/docbkx/container-adapters.xml index f1cb4f762e..1d095802bb 100644 --- a/src/docbkx/container-adapters.xml +++ b/src/docbkx/container-adapters.xml @@ -48,18 +48,18 @@ As is always the case, the container adapter generated - Authentication object still needs to be - authenticated by an AuthenticationManager when + Authentication object still needs to be + authenticated by an AuthenticationManager when requested to do so by the - AbstractSecurityInterceptor. The - AuthenticationManager needs to be certain the - adapter-provided Authentication object is valid and + AbstractSecurityInterceptor. The + AuthenticationManager needs to be certain the + adapter-provided Authentication object is valid and was actually authenticated by a trusted adapter. - Adapters create Authentication objects which + Adapters create Authentication objects which are immutable and implement the AuthByAdapter interface. These objects store the hash of a key that is defined by - the adapter. This allows the Authentication object + the adapter. This allows the Authentication object to be validated by the AuthByAdapterProvider. This authentication provider is defined as follows: @@ -80,13 +80,13 @@ AuthByAdapter instance that contains a hash code of the key. Later, when an application calls a security interceptor managed resource, the AuthByAdapter instance in the - SecurityContext in the - SecurityContextHolder will be tested by the + SecurityContext in the + SecurityContextHolder will be tested by the application's AuthByAdapterProvider. There is no requirement for additional authentication providers such as DaoAuthenticationProvider within the application-specific application context, as the only type of - Authentication instance that will be presented by + Authentication instance that will be presented by the application is from the container adapter. Classloader issues are frequent with containers and the use of @@ -206,7 +206,7 @@ In this configuration acegisecurity.xml contains the spring context definition including all the authentication manager beans. You have to bear in mind though, that - SecurityContext is created and destroyed on each + SecurityContext is created and destroyed on each login request, so the login operation might become costly. Alternatively, the second approach is to use Spring singleton capabilities through @@ -230,7 +230,7 @@ In the above code fragment, authenticationManager is a helper property that defines the expected name of the - AuthenticationManager in case you have several + AuthenticationManager in case you have several defined in the IoC container. The singletonId property references a bean defined in a beanRefFactory.xml file. This file needs to be diff --git a/src/docbkx/dao-auth-provider.xml b/src/docbkx/dao-auth-provider.xml index 3acfc44aef..d355230eaa 100644 --- a/src/docbkx/dao-auth-provider.xml +++ b/src/docbkx/dao-auth-provider.xml @@ -6,7 +6,7 @@ Overview Spring Security includes a production-quality - AuthenticationProvider implementation called + AuthenticationProvider implementation called DaoAuthenticationProvider. This authentication provider is compatible with all of the authentication mechanisms that generate a UsernamePasswordAuthenticationToken, and @@ -43,8 +43,8 @@ The PasswordEncoder and SaltSource are optional. A PasswordEncoder provides encoding and decoding of - passwords presented in the UserDetails object that - is returned from the configured UserDetailsService. + passwords presented in the UserDetails object that + is returned from the configured UserDetailsService. A SaltSource enables the passwords to be populated with a "salt", which enhances the security of the passwords in the authentication repository. PasswordEncoder @@ -54,15 +54,15 @@ SystemWideSaltSource which encodes all passwords with the same salt, and ReflectionSaltSource, which inspects a given property of the returned - UserDetails object to obtain the salt. Please refer + UserDetails object to obtain the salt. Please refer to the JavaDocs for further details on these optional features. In addition to the properties above, the DaoAuthenticationProvider supports optional caching - of UserDetails objects. The + of UserDetails objects. The UserCache interface enables the DaoAuthenticationProvider to place a - UserDetails object into the cache, and retrieve it + UserDetails object into the cache, and retrieve it from the cache upon subsequent authentication attempts for the same username. By default the DaoAuthenticationProvider uses the NullUserCache, which performs no caching. @@ -105,19 +105,19 @@ A design decision was made not to support account locking in the DaoAuthenticationProvider, as doing so would have - increased the complexity of the UserDetailsService + increased the complexity of the UserDetailsService interface. For instance, a method would be required to increase the count of unsuccessful authentication attempts. Such functionality could be easily provided by leveraging the application event publishing features discussed below. DaoAuthenticationProvider returns an - Authentication object which in turn has its + Authentication object which in turn has its principal property set. The principal will be either a String (which is essentially the username) - or a UserDetails object (which was looked up from - the UserDetailsService). By default the - UserDetails is returned, as this enables + or a UserDetails object (which was looked up from + the UserDetailsService). By default the + UserDetails is returned, as this enables applications to add extra properties potentially of use in applications, such as the user's full name, email address etc. If using container adapters, or if your applications were written to diff --git a/src/docbkx/digest-authentication.xml b/src/docbkx/digest-authentication.xml index 029ee907c1..c5dd17962f 100644 --- a/src/docbkx/digest-authentication.xml +++ b/src/docbkx/digest-authentication.xml @@ -107,7 +107,7 @@ - The configured UserDetailsService is needed + The configured UserDetailsService is needed because DigestProcessingFilter must have direct access to the clear text password of a user. Digest Authentication will NOT work if you are using encoded passwords in your DAO. The DAO @@ -121,14 +121,14 @@ calculations. Like BasicAuthenticationFilter, if - authentication is successful an Authentication + authentication is successful an Authentication request token will be placed into the - SecurityContextHolder. If the authentication event + SecurityContextHolder. If the authentication event was successful, or authentication was not attempted because the HTTP header did not contain a Digest Authentication request, the filter chain will continue as normal. The only time the filter chain will be interrupted is if authentication fails and the - AuthenticationEntryPoint is called, as discussed in + AuthenticationEntryPoint is called, as discussed in the previous paragraph. Digest Authentication's RFC offers a range of additional diff --git a/src/docbkx/domain-acls.xml b/src/docbkx/domain-acls.xml index 204e4a85b0..4a0eaba3a2 100644 --- a/src/docbkx/domain-acls.xml +++ b/src/docbkx/domain-acls.xml @@ -15,8 +15,8 @@ org.springframework.security.acls package. Complex applications often will find the need to define access permissions not simply at a web request or method invocation level. Instead, security decisions need to - comprise both who (Authentication), where - (MethodInvocation) and what (SomeDomainObject). In + comprise both who (Authentication), where + (MethodInvocation) and what (SomeDomainObject). In other words, authorization decisions also need to consider the actual domain object instance subject of a method invocation. Imagine you're designing an application for a pet clinic. There will be two main @@ -32,21 +32,21 @@ collection within the Customer domain object instance to determine which users have access. By using the SecurityContextHolder.getContext().getAuthentication(), - you'll be able to access the Authentication + you'll be able to access the Authentication object. - Write an AccessDecisionVoter to enforce the security + Write an AccessDecisionVoter to enforce the security from the GrantedAuthority[]s stored in the - Authentication object. This would mean your - AuthenticationManager would need to populate the - Authentication with custom - GrantedAuthority[]s representing each of the + Authentication object. This would mean your + AuthenticationManager would need to populate the + Authentication with custom + GrantedAuthority[]s representing each of the Customer domain object instances the principal has access to. - Write an AccessDecisionVoter to enforce the security + Write an AccessDecisionVoter to enforce the security and open the target Customer domain object directly. This would mean your voter needs access to a DAO that allows it to retrieve the Customer object. It would then access the @@ -58,16 +58,16 @@ authorization checking to your business code. The main problems with this include the enhanced difficulty of unit testing and the fact it would be more difficult to reuse the Customer authorization logic elsewhere. Obtaining the - GrantedAuthority[]s from the Authentication + GrantedAuthority[]s from the Authentication object is also fine, but will not scale to large numbers of Customers. If a user might be able to access 5,000 Customers (unlikely in this case, but imagine if it were a popular vet for a large Pony Club!) the amount of memory consumed and time required to construct - the Authentication object would be undesirable. The final method, + the Authentication object would be undesirable. The final method, opening the Customer directly from external code, is probably the best of the three. It achieves separation of concerns, and doesn't misuse memory or CPU cycles, but it is still inefficient in that both the - AccessDecisionVoter and the eventual business method itself will + AccessDecisionVoter and the eventual business method itself will perform a call to the DAO responsible for retrieving the Customer object. Two accesses per method invocation is clearly undesirable. In addition, with every approach listed you'll need to write your own access control list (ACL) @@ -119,8 +119,8 @@ system ("SID" stands for "security identity"). The only columns are the ID, a textual representation of the SID, and a flag to indicate whether the textual representation refers to a prncipal name or a - GrantedAuthority. Thus, there is a single row for - each unique principal or GrantedAuthority. When used in + GrantedAuthority. Thus, there is a single row for + each unique principal or GrantedAuthority. When used in the context of receiving a permission, a SID is generally called a "recipient". @@ -193,7 +193,7 @@ GrantedAuthority[]s. A level of indirection is provided by the Sid interface, which is an abbreviation of "security identity". Common classes include PrincipalSid (to represent - the principal inside an Authentication object) and + the principal inside an Authentication object) and GrantedAuthoritySid. The security identity information is stored in the ACL_SID table. @@ -289,7 +289,7 @@ aclService.updateAcl(acl); Once you've used the above techniques to store some ACL information in the database, the next step is to actually use the ACL information as part of authorization decision logic. You have a number of choices here. You could write your own - AccessDecisionVoter or AfterInvocationProvider + AccessDecisionVoter or AfterInvocationProvider that respectively fires before or after a method invocation. Such classes would use AclService to retrieve the relevant ACL and then call Acl.isGranted(Permission[] permission, Sid[] sids, boolean diff --git a/src/docbkx/form-authentication.xml b/src/docbkx/form-authentication.xml index 21123eb637..85597c05d3 100644 --- a/src/docbkx/form-authentication.xml +++ b/src/docbkx/form-authentication.xml @@ -30,7 +30,7 @@ ]]> - The configured AuthenticationManager + The configured AuthenticationManager processes each authentication request. If authentication fails, the browser will be redirected to the authenticationFailureUrl. The @@ -40,15 +40,15 @@ enabling a reason to be provided to the user on the error page. If authentication is successful, the resulting - Authentication object will be placed into the - SecurityContextHolder. + Authentication object will be placed into the + SecurityContextHolder. - Once the SecurityContextHolder has been + Once the SecurityContextHolder has been updated, the browser will need to be redirected to the target URL which is usually indicated by the HttpSession attribute stored under AbstractProcessingFilter.SPRING_SECURITY_TARGET_URL_KEY. This attribute is automatically set by the - ExceptionTranslationFilter when an + ExceptionTranslationFilter when an AuthenticationException occurs, so that after login is completed the user can return to what they were originally trying to access. If for some reason the HttpSession does not diff --git a/src/docbkx/jaas-auth-provider.xml b/src/docbkx/jaas-auth-provider.xml index c5213744a6..62a0aa21f8 100644 --- a/src/docbkx/jaas-auth-provider.xml +++ b/src/docbkx/jaas-auth-provider.xml @@ -64,7 +64,7 @@ JAASTest { mechanism). Thus, by the time the authentication request is delegated through to JAAS, Spring Security's authentication mechanism will already have fully-populated an - Authentication object containing all the + Authentication object containing all the information required by the JAAS LoginModule. @@ -97,9 +97,9 @@ JAASTest { JAAS works with principals. Even "roles" are represented as principals in JAAS. Spring Security, on the other hand, works with - Authentication objects. Each - Authentication object contains a single - principal, and multiple GrantedAuthority[]s. To + Authentication objects. Each + Authentication object contains a single + principal, and multiple GrantedAuthority[]s. To facilitate mapping between these different concepts, Spring Security's JAAS package includes an AuthorityGranter interface. @@ -109,7 +109,7 @@ JAASTest { String. The JaasAuthenticationProvider then creates a JaasGrantedAuthority (which implements Spring - Security’s GrantedAuthority interface) containing + Security’s GrantedAuthority interface) containing both the AuthorityGranter-returned String and the JAAS principal that the AuthorityGranter was passed. The diff --git a/src/docbkx/ldap-auth-provider.xml b/src/docbkx/ldap-auth-provider.xml index c1cdb65bd0..26df1ad8e4 100644 --- a/src/docbkx/ldap-auth-provider.xml +++ b/src/docbkx/ldap-auth-provider.xml @@ -396,7 +396,7 @@ property. The authenticator would then call the search object to obtain the correct user's DN before attempting to bind as this user.
-
+
LDAP Attributes and Customized UserDetails The net result of an authentication using LdapAuthenticationProvider is the diff --git a/src/docbkx/namespace-config.xml b/src/docbkx/namespace-config.xml index 995107f8f7..936894c74f 100644 --- a/src/docbkx/namespace-config.xml +++ b/src/docbkx/namespace-config.xml @@ -496,7 +496,7 @@ SESSION_CONTEXT_INTEGRATION_FILTER - HttpSessionContextIntegrationFilter + HttpSessionContextIntegrationFilter http @@ -536,7 +536,7 @@ REMEMBER_ME_FILTER - RememberMeProcessingFilter + RememberMeProcessingFilter http/remember-me @@ -546,7 +546,7 @@ EXCEPTION_TRANSLATION_FILTER - ExceptionTranslationFilter + ExceptionTranslationFilter http @@ -556,7 +556,7 @@ FILTER_SECURITY_INTERCEPTOR - FilterSecurityInterceptor + FilterSecurityInterceptor http @@ -587,8 +587,8 @@ Note that you can't replace filters which are created by the use of the <http> - element itself - HttpSessionContextIntegrationFilter, ExceptionTranslationFilter or - FilterSecurityInterceptor. + element itself - HttpSessionContextIntegrationFilter, ExceptionTranslationFilter or + FilterSecurityInterceptor. @@ -596,11 +596,11 @@ an attempt by an unauthenticated user to access to a secured resource), you will need to add a custom entry point bean too.
- Setting a Custom <literal>AuthenticationEntryPoint</literal> + Setting a Custom <interfacename>AuthenticationEntryPoint</interfacename> If you aren't using form login, OpenID or basic authentication through the namespace, you may want to define an authentication filter and entry point using a traditional bean syntax and link them - into the namespace, as we've just seen. The corresponding AuthenticationEntryPoint can be set using the + into the namespace, as we've just seen. The corresponding AuthenticationEntryPoint can be set using the entry-point-ref attribute on the <http> element. @@ -763,9 +763,9 @@ We've touched on the idea that the namespace configuration automatically registers an authentication manager bean for you. This is an instance of Spring Security's ProviderManager class, which you may already - be familiar with if you've used the framework before. You can't use a custom AuthenticationProvider if you are + be familiar with if you've used the framework before. You can't use a custom AuthenticationProvider 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. + the AuthenticationProviders that are used. You may want to register additional AuthenticationProvider beans with the ProviderManager diff --git a/src/docbkx/preauth.xml b/src/docbkx/preauth.xml index c55a39169d..c395158466 100644 --- a/src/docbkx/preauth.xml +++ b/src/docbkx/preauth.xml @@ -112,7 +112,7 @@
PreAuthenticatedProcessingFilterEntryPoint - The AuthenticationEntryPoint was discussed in the technical + The AuthenticationEntryPoint was discussed in the technical overview chapter. Normally it is responsible for kick-starting the authentication process for an unauthenticated user (when they try to access a protected resource), but in the pre-authenticated case this doesn't apply. You would only configure the ExceptionTranslationFilter with an instance of this class if you aren't diff --git a/src/docbkx/remember-me-authentication.xml b/src/docbkx/remember-me-authentication.xml index 29c3953bba..eea2baa910 100644 --- a/src/docbkx/remember-me-authentication.xml +++ b/src/docbkx/remember-me-authentication.xml @@ -95,7 +95,7 @@ AuthenticationProcessingFilter, and is implemented via hooks in the AbstractProcessingFilter superclass. The hooks will invoke a concrete - RememberMeServices at the appropriate times. The + RememberMeServices at the appropriate times. The interface looks like this: Authentication autoLogin(HttpServletRequest request, HttpServletResponse response); @@ -107,9 +107,9 @@ AbstractProcessingFilter only calls the loginFail() and loginSuccess() methods. The autoLogin() method is called by - RememberMeProcessingFilter whenever the - SecurityContextHolder does not contain an - Authentication. This interface therefore provides + RememberMeProcessingFilter whenever the + SecurityContextHolder does not contain an + Authentication. This interface therefore provides the underlying remember-me implementation with sufficient notification of authentication-related events, and delegates to the implementation whenever a candidate web request might contain a cookie @@ -130,7 +130,7 @@ UserDetailsService from which it can retrieve the username and password for signature comparison purposes, and generate the RememberMeAuthenticationToken to contain the - correct GrantedAuthority[]s. Some sort of logout + correct GrantedAuthority[]s. Some sort of logout command should be provided by the application that invalidates the cookie if the user requests this. TokenBasedRememberMeServices also implements Spring Security's LogoutHandler interface so can be used with LogoutFilter @@ -155,13 +155,13 @@ ]]> Don't forget to add your - RememberMeServices implementation to your + RememberMeServices implementation to your AuthenticationProcessingFilter.setRememberMeServices() property, include the RememberMeAuthenticationProvider in your AuthenticationManager.setProviders() list, and add - RememberMeProcessingFilter into your - FilterChainProxy (typically immediately after your + RememberMeProcessingFilter into your + FilterChainProxy (typically immediately after your AuthenticationProcessingFilter).
diff --git a/src/docbkx/runas-auth-provider.xml b/src/docbkx/runas-auth-provider.xml index ba1afc14e7..3abfdf6c0f 100644 --- a/src/docbkx/runas-auth-provider.xml +++ b/src/docbkx/runas-auth-provider.xml @@ -4,27 +4,27 @@
Overview - The AbstractSecurityInterceptor is able to - temporarily replace the Authentication object in - the SecurityContext and - SecurityContextHolder during the secure object + The AbstractSecurityInterceptor is able to + temporarily replace the Authentication object in + the SecurityContext and + SecurityContextHolder during the secure object callback phase. This only occurs if the original - Authentication object was successfully processed by - the AuthenticationManager and - AccessDecisionManager. The + Authentication object was successfully processed by + the AuthenticationManager and + AccessDecisionManager. The RunAsManager will indicate the replacement - Authentication object, if any, that should be used + Authentication object, if any, that should be used during the SecurityInterceptorCallback. - By temporarily replacing the Authentication + By temporarily replacing the Authentication object during the secure object callback phase, the secured invocation will be able to call other objects which require different authentication and authorization credentials. It will also be able to perform any internal security checks for specific - GrantedAuthority objects. Because Spring Security + GrantedAuthority objects. Because Spring Security provides a number of helper classes that automatically configure remoting protocols based on the contents of the - SecurityContextHolder, these run-as replacements + SecurityContextHolder, these run-as replacements are particularly useful when calling remote web services
@@ -38,12 +38,12 @@ - The first method returns the Authentication + The first method returns the Authentication object that should replace the existing - Authentication object for the duration of the + Authentication object for the duration of the method invocation. If the method returns null, it indicates no replacement should be made. The second method is used by - the AbstractSecurityInterceptor as part of its + the AbstractSecurityInterceptor as part of its startup validation of configuration attributes. The supports(Class) method is called by a security interceptor implementation to ensure the configured @@ -59,7 +59,7 @@ ConfigAttribute is found, the replacement RunAsUserToken will contain the same principal, credentials and granted authorities as the original - Authentication object, along with a new + Authentication object, along with a new GrantedAuthorityImpl for each RUN_AS_ ConfigAttribute. Each new GrantedAuthorityImpl will be prefixed with @@ -70,10 +70,10 @@ ROLE_RUN_AS_SERVER granted authority. The replacement RunAsUserToken is just like - any other Authentication object. It needs to be - authenticated by the AuthenticationManager, + any other Authentication object. It needs to be + authenticated by the AuthenticationManager, probably via delegation to a suitable - AuthenticationProvider. The + AuthenticationProvider. The RunAsImplAuthenticationProvider performs such authentication. It simply accepts as valid any RunAsUserToken presented. diff --git a/src/docbkx/samples.xml b/src/docbkx/samples.xml index 69f0babdac..28563fd078 100644 --- a/src/docbkx/samples.xml +++ b/src/docbkx/samples.xml @@ -92,7 +92,7 @@ currently logged on user are displayed, and only users with ROLE_SUPERVISOR are granted access to delete their contacts. Behind the scenes, the - MethodSecurityInterceptor is securing the business + MethodSecurityInterceptor is securing the business objects. The application allows you to modify the access control lists associated with different contacts. Be sure to give this a try and understand how diff --git a/src/docbkx/secured-objects.xml b/src/docbkx/secured-objects.xml index 000a783ad1..aa079a0ca5 100644 --- a/src/docbkx/secured-objects.xml +++ b/src/docbkx/secured-objects.xml @@ -7,7 +7,7 @@ - Prior to Spring Security 2.0, securing MethodInvocations needed quite a + Prior to Spring Security 2.0, securing MethodInvocations needed quite a lot of boiler plate configuration. Now the recommended approach for method security is to use namespace configuration. This way the method security infrastructure beans are configured automatically for you so you don't really need to @@ -67,7 +67,7 @@ security interceptors in the same application, with AspectJSecurityInterceptor being used for domain object instance security and the AOP Alliance - MethodSecurityInterceptor being used for services + MethodSecurityInterceptor being used for services layer security. Let's first consider how the @@ -92,11 +92,11 @@ AspectJSecurityInterceptor is exactly the same as the AOP Alliance security interceptor. Indeed the two interceptors can share the same objectDefinitionSource, as the - ObjectDefinitionSource works with + ObjectDefinitionSource works with java.lang.reflect.Methods rather than an AOP library-specific class. Of course, your access decisions have access to the relevant AOP library-specific invocation (ie - MethodInvocation or JoinPoint) + MethodInvocation or JoinPoint) and as such can consider a range of addition criteria when making access decisions (such as method arguments). @@ -178,7 +178,7 @@ public void afterPropertiesSet() throws Exception { FilterInvocation Security Interceptor To secure FilterInvocations, developers need - to add a FilterSecurityInterceptor to their filter chain. + to add a FilterSecurityInterceptor to their filter chain. A typical configuration example is provided below: In the application context you will need to configure three @@ -217,43 +217,43 @@ public void afterPropertiesSet() throws Exception { the filter will call the AuthenticationEntryPoint to commence the authentication process (e.g. a user login). - The AuthenticationEntryPoint will be called + The AuthenticationEntryPoint will be called if the user requests a secure HTTP resource but they are not authenticated. The class handles presenting the appropriate response to the user so that authentication can begin. Three concrete implementations are provided with Spring Security: - AuthenticationProcessingFilterEntryPoint for + AuthenticationProcessingFilterEntryPoint for commencing a form-based authentication, BasicProcessingFilterEntryPoint for commencing a HTTP Basic authentication process, and CasProcessingFilterEntryPoint for commencing a JA-SIG Central Authentication Service (CAS) login. The - AuthenticationProcessingFilterEntryPoint and + AuthenticationProcessingFilterEntryPoint and CasProcessingFilterEntryPoint have optional properties related to forcing the use of HTTPS, so please refer to the JavaDocs if you require this. - FilterSecurityInterceptor is responsible for + FilterSecurityInterceptor is responsible for handling the security of HTTP resources. Like any other security interceptor, it requires a reference to an - AuthenticationManager and an - AccessDecisionManager, which are both discussed in + AuthenticationManager and an + AccessDecisionManager, which are both discussed in separate sections below. The - FilterSecurityInterceptor is also configured with + FilterSecurityInterceptor is also configured with configuration attributes that apply to different HTTP URL requests. A full discussion of configuration attributes is provided in the High Level Design section of this document. - The FilterSecurityInterceptor can be + The FilterSecurityInterceptor can be configured with configuration attributes in two ways. The first, which is shown above, is using the <filter-invocation-definition-source> namespace element. This is similar to the <filter-chain-map> - used to configure a FilterChainProxy but the <intercept-url> + used to configure a FilterChainProxy but the <intercept-url> child elements only use the pattern and access attributes. The second is by writing your own - ObjectDefinitionSource, although this is beyond the + ObjectDefinitionSource, although this is beyond the scope of this document. Irrespective of the approach used, the - ObjectDefinitionSource is responsible for returning + ObjectDefinitionSource is responsible for returning a ConfigAttributeDefinition object that contains all of the configuration attributes associated with a single secure HTTP URL. @@ -261,24 +261,24 @@ public void afterPropertiesSet() throws Exception { It should be noted that the FilterSecurityInterceptor.setObjectDefinitionSource() method actually expects an instance of - FilterInvocationDefinitionSource. This is a marker - interface which subclasses ObjectDefinitionSource. - It simply denotes the ObjectDefinitionSource - understands FilterInvocations. In the interests of + FilterInvocationDefinitionSource. This is a marker + interface which subclasses ObjectDefinitionSource. + It simply denotes the ObjectDefinitionSource + understands FilterInvocations. In the interests of simplicity we'll continue to refer to the - FilterInvocationDefinitionSource as an - ObjectDefinitionSource, as the distinction is of + FilterInvocationDefinitionSource as an + ObjectDefinitionSource, as the distinction is of little relevance to most users of the - FilterSecurityInterceptor. + FilterSecurityInterceptor. When using the namespace option to configure the interceptor, commas are used to delimit the different configuration attributes that apply to each HTTP URL. Each configuration attribute is assigned into its own SecurityConfig object. The SecurityConfig object is discussed in the High - Level Design section. The ObjectDefinitionSource + Level Design section. The ObjectDefinitionSource created by the property editor, - FilterInvocationDefinitionSource, matches + FilterInvocationDefinitionSource, matches configuration attributes against FilterInvocations based on expression evaluation of the request URL. Two standard expression syntaxes are supported. The default is to treat all @@ -317,10 +317,10 @@ public void afterPropertiesSet() throws Exception { As with other security interceptors, the validateConfigAttributes property is observed. When set to true (the default), at startup time the - FilterSecurityInterceptor will evaluate if the + FilterSecurityInterceptor will evaluate if the provided configuration attributes are valid. It does this by checking each configuration attribute can be processed by either the - AccessDecisionManager or the + AccessDecisionManager or the RunAsManager. If neither of these can process a given configuration attribute, an exception is thrown.
diff --git a/src/docbkx/siteminder-auth-provider.xml b/src/docbkx/siteminder-auth-provider.xml index e9156e41c7..f39bce8a83 100644 --- a/src/docbkx/siteminder-auth-provider.xml +++ b/src/docbkx/siteminder-auth-provider.xml @@ -49,7 +49,7 @@ </bean> In our example above, the bean is being provided an - AuthenticationManager, as is normally needed by + AuthenticationManager, as is normally needed by authentication mechanisms. Several URLs are also specified, with the values being self-explanatory. It's important to also specify the HTTP header that Spring Security should inspect. If you additionally want @@ -61,15 +61,15 @@ SiteminderAuthenticationProvider configured against your ProviderManager in order to use the Siteminder authentication mechanism. Normally an - AuthenticationProvider expects the password + AuthenticationProvider expects the password property to match what it retrieves from the UserDetailsSource, but in this case, authentication has already been handled by Siteminder, so password property is not even relevant. This may sound like a security weakness, but remember that users have to authenticate with Siteminder before your application ever receives the requests, so the purpose of your custom - UserDetailsService should simply be to build the - complete Authentication object (ie with suitable + UserDetailsService should simply be to build the + complete Authentication object (ie with suitable GrantedAuthority[]s). Advanced tip and word to the wise: If you additionally want to diff --git a/src/docbkx/springsecurity.xml b/src/docbkx/springsecurity.xml index e44bdad0aa..b1b7e15dbd 100644 --- a/src/docbkx/springsecurity.xml +++ b/src/docbkx/springsecurity.xml @@ -150,7 +150,7 @@ in the Technical Overview chapter. In this part of the reference guide we will examine individual authentication mechanisms and their corresponding - AuthenticationProviders. We'll also look at how to + AuthenticationProviders. We'll also look at how to configure authentication more generally, including if you have several authentication approaches that need to be chained together. @@ -213,7 +213,7 @@ in a consistent and simple way. In this part we'll explore the different - AbstractSecurityInterceptor implementations, which + AbstractSecurityInterceptor implementations, which were introduced in Part I. We then move on to explore how to fine-tune authorization through use of domain access control lists. diff --git a/src/docbkx/supporting-infrastructure.xml b/src/docbkx/supporting-infrastructure.xml index 0ba8fd4024..434a8158eb 100644 --- a/src/docbkx/supporting-infrastructure.xml +++ b/src/docbkx/supporting-infrastructure.xml @@ -86,7 +86,7 @@ are using your own customized versions of classes. In this case, you have a choice in how these filters are added to your web application, in that you can use either Spring's DelegatingFilterProxy or - FilterChainProxy. We'll look at both below. + FilterChainProxy. We'll look at both below. When using DelegatingFilterProxy, you will see something like this in the web.xml file: @@ -135,14 +135,14 @@ for more information Rather than using DelegatingFilterProxy, we - strongly recommend that you use FilterChainProxy instead. + strongly recommend that you use FilterChainProxy instead. Whilst DelegatingFilterProxy is a very useful class, the problem is that the number of lines of code required for <filter> and <filter-mapping> entries in web.xml explodes when using more than a few filters. To overcome this issue, Spring Security provides a - FilterChainProxy class. It is wired using a + FilterChainProxy class. It is wired using a DelegatingFilterProxy (just like in the example above), but the target class is org.springframework.security.util.FilterChainProxy. @@ -162,9 +162,9 @@ You may notice similarities with the way - FilterSecurityInterceptor is declared. Both regular + FilterSecurityInterceptor is declared. Both regular expressions and Ant Paths are supported, and the most specific URIs - appear first. At runtime the FilterChainProxy will + appear first. At runtime the FilterChainProxy will locate the first URI pattern that matches the current web request and the list of filter beans specified by the filters attribute will be applied to that request. The filters will be invoked in the order @@ -172,28 +172,28 @@ which is applied to a particular URL. You may have noticed we have declared two - HttpSessionContextIntegrationFilters in the filter + HttpSessionContextIntegrationFilters in the filter chain (ASC is short for allowSessionCreation, a property of - HttpSessionContextIntegrationFilter). As web + HttpSessionContextIntegrationFilter). As web services will never present a jsessionid on future requests, creating HttpSessions for such user agents would be wasteful. If you had a high-volume application which required maximum scalability, we recommend you use the approach shown above. For smaller applications, using a single - HttpSessionContextIntegrationFilter (with its + HttpSessionContextIntegrationFilter (with its default allowSessionCreation as true) would likely be sufficient. In relation to lifecycle issues, the - FilterChainProxy will always delegate + FilterChainProxy will always delegate init(FilterConfig) and destroy() methods through to the underlaying Filters if such - methods are called against FilterChainProxy itself. - In this case, FilterChainProxy guarantees to only + methods are called against FilterChainProxy itself. + In this case, FilterChainProxy guarantees to only initialize and destroy each Filter once, irrespective of how many times it is declared by the - FilterInvocationDefinitionSource. You control the + FilterInvocationDefinitionSource. You control the overall choice as to whether these methods are called or not via the targetFilterLifecycle initialization parameter of the DelegatingFilterProxy that proxies @@ -222,17 +222,17 @@ ConcurrentSessionFilter, because it - doesn't use any SecurityContextHolder + doesn't use any SecurityContextHolder functionality but needs to update the - SessionRegistry to reflect ongoing requests + SessionRegistry to reflect ongoing requests from the principal - HttpSessionContextIntegrationFilter, so a - SecurityContext can be setup in the - SecurityContextHolder at the beginning of a web - request, and any changes to the SecurityContext + HttpSessionContextIntegrationFilter, so a + SecurityContext can be setup in the + SecurityContextHolder at the beginning of a web + request, and any changes to the SecurityContext can be copied to the HttpSession when the web request ends (ready for use with the next web request) @@ -243,8 +243,8 @@ CasProcessingFilter, BasicProcessingFilter, HttpRequestIntegrationFilter, JbossIntegrationFilter etc - so that the - SecurityContextHolder can be modified to - contain a valid Authentication request + SecurityContextHolder can be modified to + contain a valid Authentication request token @@ -257,46 +257,46 @@ - RememberMeProcessingFilter, so that if no + RememberMeProcessingFilter, so that if no earlier authentication processing mechanism updated the - SecurityContextHolder, and the request presents + SecurityContextHolder, and the request presents a cookie that enables remember-me services to take place, a suitable remembered - Authentication object will + Authentication object will be put there AnonymousProcessingFilter, so that if no earlier authentication processing mechanism updated the - SecurityContextHolder, an anonymous - Authentication object will be put there + SecurityContextHolder, an anonymous + Authentication object will be put there - ExceptionTranslationFilter, to catch any + ExceptionTranslationFilter, to catch any Spring Security exceptions so that either an HTTP error response can be returned or an appropriate - AuthenticationEntryPoint can be launched + AuthenticationEntryPoint can be launched - FilterSecurityInterceptor, to protect web + FilterSecurityInterceptor, to protect web URIs All of the above filters use DelegatingFilterProxy or - FilterChainProxy. It is recommended that a single + FilterChainProxy. It is recommended that a single DelegatingFilterProxy proxy through to a single - FilterChainProxy for each application, with that - FilterChainProxy defining all of Spring Security + FilterChainProxy for each application, with that + FilterChainProxy defining all of Spring Security filters. If you're using SiteMesh, ensure Spring Security filters execute before the SiteMesh filters are called. This enables the - SecurityContextHolder to be populated in time for + SecurityContextHolder to be populated in time for use by SiteMesh decorators
diff --git a/src/docbkx/technical-overview.xml b/src/docbkx/technical-overview.xml index fdcd57ead4..9cc8d92483 100644 --- a/src/docbkx/technical-overview.xml +++ b/src/docbkx/technical-overview.xml @@ -45,10 +45,10 @@ SecurityContextHolder, SecurityContext and Authentication Objects The most fundamental object is - SecurityContextHolder. This is where we store + SecurityContextHolder. 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 SecurityContextHolder uses a + default the SecurityContextHolder uses a ThreadLocal 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 SecurityContextHolder.MODE_THREADLOCAL in two ways. The first is to set a system property. Alternatively, call a static - method on SecurityContextHolder. Most applications + method on SecurityContextHolder. Most applications won't need to change from the default, but if you do, take a look at - the JavaDocs for SecurityContextHolder to learn + the JavaDocs for SecurityContextHolder to learn more. - Inside the SecurityContextHolder we store + Inside the SecurityContextHolder we store details of the principal currently interacting with the application. - Spring Security uses an Authentication object to + Spring Security uses an Authentication object to represent this information. Whilst you won't normally need to create - an Authentication object yourself, it is fairly - common for users to query the Authentication + an Authentication object yourself, it is fairly + common for users to query the Authentication object. You can use the following code block - from anywhere in your application - to obtain the name of the authenticated user, for example: @@ -95,14 +95,14 @@ if (obj instanceof UserDetails) { The above code introduces a number of interesting relationships and key objects. First, you will notice that there is an intermediate - object between SecurityContextHolder and - Authentication. The + object between SecurityContextHolder and + Authentication. The SecurityContextHolder.getContext() method is - actually returning a SecurityContext. + actually returning a SecurityContext. + SecurityContext. -->
@@ -119,40 +119,40 @@ if (obj instanceof UserDetails) { The UserDetailsService Another item to note from the above code fragment is that you - can obtain a principal from the Authentication + can obtain a principal from the Authentication object. The principal is just an Object. Most of - the time this can be cast into a UserDetails - object. UserDetails is a central interface in + the time this can be cast into a UserDetails + object. UserDetails is a central interface in Spring Security. It represents a principal, but in an extensible and - application-specific way. Think of UserDetails as + application-specific way. Think of UserDetails as the adapter between your own user database and what Spring Security - needs inside the SecurityContextHolder. Being a + needs inside the SecurityContextHolder. Being a representation of something from your own user database, quite often - you will cast the UserDetails to the original + you will cast the UserDetails to the original object that your application provided, so you can call business-specific methods (like getEmail(), getEmployeeNumber() and so on). By now you're probably wondering, so when do I provide a - UserDetails object? How do I do that? I thought you + UserDetails 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 UserDetailsService. The only + interface called UserDetailsService. The only method on this interface accepts a String-based - username argument and returns a UserDetails. Most + username argument and returns a UserDetails. Most authentication providers that ship with Spring Security delegate to a - UserDetailsService as part of the authentication - process. The UserDetailsService is used to build - the Authentication object that is stored in the - SecurityContextHolder. The good news is that we - provide a number of UserDetailsService + UserDetailsService as part of the authentication + process. The UserDetailsService is used to build + the Authentication object that is stored in the + SecurityContextHolder. The good news is that we + provide a number of UserDetailsService 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 SecurityContextHolder, as per the above code + the SecurityContextHolder, as per the above code fragment.
@@ -161,23 +161,23 @@ if (obj instanceof UserDetails) { GrantedAuthority Besides the principal, another important method provided by - Authentication is + Authentication is getAuthorities(). This method provides an array of - GrantedAuthority objects. A - GrantedAuthority is, not surprisingly, an authority + GrantedAuthority objects. A + GrantedAuthority is, not surprisingly, an authority that is granted to the principal. Such authorities are usually "roles", such as ROLE_ADMINISTRATOR or ROLE_HR_SUPERVISOR. 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. - GrantedAuthority objects are usually loaded by the - UserDetailsService. + GrantedAuthority objects are usually loaded by the + UserDetailsService. - Usually the GrantedAuthority objects are + Usually the GrantedAuthority objects are application-wide permissions. They are not specific to a given domain object. Thus, you wouldn't likely have a - GrantedAuthority to represent a permission to + GrantedAuthority to represent a permission to Employee 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. Last but not least, sometimes you will need to store the - SecurityContext between HTTP requests. Other times + SecurityContext between HTTP requests. Other times the principal will re-authenticate on every request, although most of the time it will be stored. The - HttpSessionContextIntegrationFilter is responsible - for storing a SecurityContext between HTTP + HttpSessionContextIntegrationFilter is responsible + for storing a SecurityContext between HTTP requests. As suggested by the name of the class, the HttpSession is used to store this information. You should never interact directly with the HttpSession for security purposes. There is simply no justification for doing so - - always use the SecurityContextHolder + always use the SecurityContextHolder instead.
@@ -208,41 +208,41 @@ if (obj instanceof UserDetails) { - SecurityContextHolder, to provide any - type access to the SecurityContext. + SecurityContextHolder, to provide any + type access to the SecurityContext. - SecurityContext, to hold the - Authentication and possibly request-specific + SecurityContext, to hold the + Authentication and possibly request-specific security information. - HttpSessionContextIntegrationFilter, to - store the SecurityContext in the + HttpSessionContextIntegrationFilter, to + store the SecurityContext in the HttpSession between web requests. - Authentication, to represent the + Authentication, to represent the principal in a Spring Security-specific manner. - GrantedAuthority, to reflect the + GrantedAuthority, to reflect the application-wide permissions granted to a principal. - UserDetails, to provide the necessary + UserDetails, to provide the necessary information to build an Authentication object from your application's DAOs. - UserDetailsService, to create a - UserDetails when passed in a + UserDetailsService, to create a + UserDetails when passed in a String-based username (or certificate ID or alike). @@ -321,37 +321,37 @@ if (obj instanceof UserDetails) { 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 ExceptionTranslationFilter, an - AuthenticationEntryPoint, an authentication - mechanism, and an AuthenticationProvider. + are used) are the ExceptionTranslationFilter, an + AuthenticationEntryPoint, an authentication + mechanism, and an AuthenticationProvider.
ExceptionTranslationFilter - ExceptionTranslationFilter is a Spring + ExceptionTranslationFilter 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 AbstractSecurityInterceptor, which is + thrown by an AbstractSecurityInterceptor, which is the main provider of authorization services. We will discuss - AbstractSecurityInterceptor in the next section, + 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 + 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 + launching an AuthenticationEntryPoint (if the principal has not been authenticated and therefore we need to go commence step three).
AuthenticationEntryPoint - The AuthenticationEntryPoint is responsible + 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 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 AuthenticationEntryPoint + have its own AuthenticationEntryPoint implementation, which takes actions such as described in step three. @@ -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 - "Authentication request" object is built and then + "Authentication request" object is built and then presented to an AuthenticationProvider.
@@ -371,31 +371,31 @@ if (obj instanceof UserDetails) {
AuthenticationProvider The last player in the Spring Security authentication process is - an AuthenticationProvider. Quite simply, it is - responsible for taking an Authentication request + an AuthenticationProvider. Quite simply, it is + responsible for taking an Authentication request object and deciding whether or not it is valid. The provider will either throw an exception or return a fully populated - Authentication object. Remember our good friends, - UserDetails and - UserDetailsService? If not, head back to the + Authentication object. Remember our good friends, + UserDetails and + UserDetailsService? If not, head back to the previous section and refresh your memory. Most - AuthenticationProviders will ask a - UserDetailsService to provide a - UserDetails object. As mentioned earlier, most + AuthenticationProviders will ask a + UserDetailsService to provide a + UserDetails object. As mentioned earlier, most application will provide their own - UserDetailsService, although some will be able to + UserDetailsService, although some will be able to use the JDBC or in-memory implementation that ships with Spring - Security. The resultant UserDetails object - and + Security. The resultant UserDetails object - and particularly the GrantedAuthority[]s contained - within the UserDetails object - will be used when - building the fully populated Authentication + 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 + 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 + AuthenticationProvider rejected the request, the authentication mechanism will ask the user agent to retry (step two above). @@ -405,11 +405,11 @@ if (obj instanceof UserDetails) { 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 + 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 @@ -474,22 +474,22 @@ if (obj instanceof UserDetails) { AbstractSecurityInterceptor Each secure object type supported by Spring Security has its own class, - which is a subclass of AbstractSecurityInterceptor. - Importantly, by the time the AbstractSecurityInterceptor is called, the - SecurityContextHolder will contain a valid - Authentication if the principal has been + which is a subclass of AbstractSecurityInterceptor. + Importantly, by the time the AbstractSecurityInterceptor is called, the + SecurityContextHolder will contain a valid + Authentication if the principal has been authenticated. - AbstractSecurityInterceptor provides a + 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 Authentication - and configuration attributes to the AccessDecisionManager for + Submitting the secure object, current Authentication + and configuration attributes to the AccessDecisionManager for an authorization decision - Optionally change the Authentication under which the invocation + Optionally change the Authentication under which the invocation takes place Allow the secure object to proceed (assuming access was granted) Call the AfterInvocationManager if configured, once the invocation @@ -501,9 +501,9 @@ if (obj instanceof UserDetails) { What are Configuration Attributes? A "configuration attribute" can be thought of as a String that has special meaning to the classes used by - AbstractSecurityInterceptor. They may be simple role names or have more complex meaning, depending on the - how sophisticated the AccessDecisionManager implementation is. - The AbstractSecurityInterceptor is configured with an ObjectDefinitionSource which + AbstractSecurityInterceptor. They may be simple role names or have more complex meaning, depending on the + how sophisticated the AccessDecisionManager implementation is. + The AbstractSecurityInterceptor is configured with an ObjectDefinitionSource 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 <intercept-url> syntax). @@ -512,14 +512,14 @@ if (obj instanceof UserDetails) {
RunAsManager - Assuming AccessDecisionManager decides to - allow the request, the AbstractSecurityInterceptor + Assuming AccessDecisionManager decides to + allow the request, the AbstractSecurityInterceptor will normally just proceed with the request. Having said that, on rare occasions users may want to replace the - Authentication inside the - SecurityContext with a different - Authentication, which is handled by the - AccessDecisionManager calling a + Authentication inside the + SecurityContext with a different + Authentication, which is handled by the + AccessDecisionManager calling a RunAsManager. 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) { AfterInvocationManager Following the secure object proceeding and then returning - which may mean a method invocation completing or a filter chain - proceeding - the AbstractSecurityInterceptor gets + proceeding - the AbstractSecurityInterceptor gets one final chance to handle the invocation. At this stage the - AbstractSecurityInterceptor is interested in + AbstractSecurityInterceptor 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, - AbstractSecurityInterceptor will pass control to an + AbstractSecurityInterceptor will pass control to an AfterInvocationManager 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. - AbstractSecurityInterceptor and its related objects + AbstractSecurityInterceptor and its related objects are shown in .
@@ -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 - MethodInvocation, AspectJ + MethodInvocation, AspectJ JoinPoint and web request - FilterInvocation) with complete + FilterInvocation) with complete transparency.
diff --git a/src/docbkx/x509-auth-provider.xml b/src/docbkx/x509-auth-provider.xml index 807b058082..462e8b1e05 100644 --- a/src/docbkx/x509-auth-provider.xml +++ b/src/docbkx/x509-auth-provider.xml @@ -34,7 +34,7 @@ subject-principal-regex. The regular expression used to extract a username from the certificate's subject name. The default value is - shown above. This is the username which will be passed to the UserDetailsService to load the authorities for the + shown above. This is the username which will be passed to the UserDetailsService to load the authorities for the user.