diff --git a/docs/manual/src/docbook/basic-and-digest-auth.xml b/docs/manual/src/docbook/basic-and-digest-auth.xml index f64aa4d85b..cd1cce432e 100644 --- a/docs/manual/src/docbook/basic-and-digest-auth.xml +++ b/docs/manual/src/docbook/basic-and-digest-auth.xml @@ -82,10 +82,10 @@ following format: - base64(expirationTime + ":" + md5Hex(expirationTime + ":" + key)) + base64(expirationTime + ":" + md5Hex(expirationTime + ":" + key)) - expirationTime: The date and time when the nonce expires, expressed in milliseconds - key: A private key to prevent modification of the nonce token + expirationTime: The date and time when the nonce expires, expressed in milliseconds + key: A private key to prevent modification of the nonce token The DigestAuthenticatonEntryPoint has a property specifying the diff --git a/docs/manual/src/docbook/core-filters.xml b/docs/manual/src/docbook/core-filters.xml index 2047d9be24..99402d1fd6 100644 --- a/docs/manual/src/docbook/core-filters.xml +++ b/docs/manual/src/docbook/core-filters.xml @@ -16,7 +16,7 @@ ExceptionTranslationFilter. A typical configuration example is shown below: + class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor"> @@ -70,7 +70,7 @@ be written as follows: + class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor"> @@ -108,14 +108,14 @@ doesn't do any actual security enforcement itself, but handles exceptions thrown by the security interceptors and provides suitable and HTTP responses. - - + class="org.springframework.security.web.access.ExceptionTranslationFilter"> + + - + class="org.springframework.security.web.authentication.LoginUrlAuthenticationEntryPoint"> + FilterChainProxy. A basic configuration only requires the bean itself + class="org.springframework.security.web.context.SecurityContextPersistenceFilter"/> ]]> As we saw previously, this filter has two main tasks. It is responsible for storage of the SecurityContext contents between HTTP requests and for clearing the SecurityContextHolder when a request is diff --git a/docs/manual/src/docbook/core-services.xml b/docs/manual/src/docbook/core-services.xml index 99ce04189e..46bfab56f2 100644 --- a/docs/manual/src/docbook/core-services.xml +++ b/docs/manual/src/docbook/core-services.xml @@ -35,7 +35,7 @@ SecurityContext. If you are using the namespace, an instance of ProviderManager is created and maintained internally, and - you add providers to it by using the namespace authentication provider elements + you add providers to it by using the namespace authentication provider elements (see the namespace chapter). In this case, you should not declare a ProviderManager bean in your application context. However, if you are not using the namespace then you would declare @@ -170,7 +170,8 @@ - + ]]> diff --git a/docs/manual/src/docbook/el-access.xml b/docs/manual/src/docbook/el-access.xml index e1dda5458a..e54f711043 100644 --- a/docs/manual/src/docbook/el-access.xml +++ b/docs/manual/src/docbook/el-access.xml @@ -136,14 +136,16 @@ The most obviously useful annotation is @PreAuthorize which decides whether a method can actually be invoked or not. For example (from the Contacts sample - application) @PreAuthorize("hasRole('ROLE_USER')") - public void create(Contact contact);which + application) + @PreAuthorize("hasRole('ROLE_USER')") + public void create(Contact contact);which means that access will only be allowed for users with the role "ROLE_USER". Obviously the same thing could easily be achieved using a traditional configuration and a simple configuration attribute for the required role. But what - about: @PreAuthorize("hasPermission(#contact, 'admin')") - public void deletePermission(Contact contact, Sid recipient, Permission permission);Here + about: + @PreAuthorize("hasPermission(#contact, 'admin')") + public void deletePermission(Contact contact, Sid recipient, Permission permission);Here we're actually using a method argument as part of the expression to decide whether the current user has the adminpermission for the given contact. The built-in hasPermission() expression is linked @@ -154,8 +156,9 @@ within the expression, so you can also access properties on the arguments. For example, if you wanted a particular method to only allow access to a user whose username matched that of the contact, you could write - @PreAuthorize("#contact.name == principal.name)") - public void doSomething(Contact contact); + + @PreAuthorize("#contact.name == principal.name)") + public void doSomething(Contact contact); Here we are accessing another built–in expression, which is the principal of the current Spring Security Authentication object obtained from the @@ -205,9 +208,13 @@ permissions. It has no explicit dependencies on the ACL module, so you could swap that out for an alternative implementation if required. The interface has two methods: - boolean hasPermission(Authentication authentication, Object targetDomainObject, Object permission); + + boolean hasPermission(Authentication authentication, Object targetDomainObject, + Object permission); - boolean hasPermission(Authentication authentication, Serializable targetId, String targetType, Object permission);which + boolean hasPermission(Authentication authentication, Serializable targetId, + String targetType, Object permission); +which map directly to the available versions of the expression, with the exception that the first argument (the Authentication object) is not supplied. The first is used in situations where the domain @@ -220,14 +227,16 @@ long as it is consistent with how the permissions are loaded. To use hasPermission() expressions, you have to explicitly configure a PermissionEvaluator in your - application context. This would look something like this: - - + application context. This would look something like this: + + + - - - ]]>Where myPermissionEvaluator is the bean which + + +]]>Where myPermissionEvaluator is the bean which implements PermissionEvaluator. Usually this will be the implementation from the ACL module which is called AclPermissionEvaluator. See the diff --git a/docs/manual/src/docbook/namespace-config.xml b/docs/manual/src/docbook/namespace-config.xml index 019024c780..c6f19cc76a 100644 --- a/docs/manual/src/docbook/namespace-config.xml +++ b/docs/manual/src/docbook/namespace-config.xml @@ -499,19 +499,22 @@ xlink:href="http://openid.net/specs/openid-attribute-exchange-1_0.html">attribute exchange. As an example, the following configuration would attempt to retrieve the email and full name from the OpenID provider, for use by the application: - - - - - ]]>The type of each OpenID attribute is a URI, + + + + + + ]]>The type of each OpenID attribute is a URI, determined by a particular schema, in this case http://axschema.org/. If an attribute must be retrieved for successful authentication, the required attribute can be set. The exact schema and attributes supported will depend on your OpenID provider. The attribute values are returned as part of the authentication process and can be accessed afterwards using the following - code:OpenIDAuthenticationToken token = (OpenIDAuthenticationToken)SecurityContextHolder.getContext().getAuthentication(); + code: + +OpenIDAuthenticationToken token = + (OpenIDAuthenticationToken)SecurityContextHolder.getContext().getAuthentication(); List<OpenIDAttribute> attributes = token.getAttributes();The OpenIDAttribute contains the attribute type and the retrieved value (or values in the case of multi-valued attributes). We'll see more about how the diff --git a/docs/manual/src/docbook/remember-me-authentication.xml b/docs/manual/src/docbook/remember-me-authentication.xml index 65d84cc92a..b912f47f62 100644 --- a/docs/manual/src/docbook/remember-me-authentication.xml +++ b/docs/manual/src/docbook/remember-me-authentication.xml @@ -78,7 +78,10 @@ persistent_logins table, created using the following SQL (or equivalent): - create table persistent_logins (username varchar(64) not null, series varchar(64) primary key, token varchar(64) not null, last_used timestamp not null) + create table persistent_logins (username varchar(64) not null, + series varchar(64) primary key, + token varchar(64) not null, + last_used timestamp not null) diff --git a/docs/manual/src/docbook/secured-objects.xml b/docs/manual/src/docbook/secured-objects.xml index eca66bc55f..502ca21d42 100644 --- a/docs/manual/src/docbook/secured-objects.xml +++ b/docs/manual/src/docbook/secured-objects.xml @@ -27,8 +27,8 @@ Explicit MethodSecurityInterceptor Configuration You can of course configure a MethodSecurityIterceptor directly in your application context for use with one of Spring AOP's proxying mechanisms: + @@ -60,8 +60,8 @@ Let's first consider how the AspectJSecurityInterceptor is configured in the Spring application context: + diff --git a/docs/manual/src/docbook/session-mgmt.xml b/docs/manual/src/docbook/session-mgmt.xml index ba03e1d3e6..14e259d193 100644 --- a/docs/manual/src/docbook/session-mgmt.xml +++ b/docs/manual/src/docbook/session-mgmt.xml @@ -38,22 +38,22 @@ AbstractAuthenticationProcessingFilter, so if you are using a customized form-login class, for example, you will need to inject it into both of these. In this case, a typical configuration, combining the namespace and custom beans might look like this: - - - + + + + - + ... - + - + - + ]]> @@ -96,32 +96,33 @@ points to the page to display when a session has expired. A configuration using the namespace to create the FilterChainProxy and other default beans might look like this: - - + + + - - + + - - - - + + + + - - - - + + + + - - - - + + + + - + ]]> Adding the listener to web.xml causes an diff --git a/docs/manual/src/docbook/technical-overview.xml b/docs/manual/src/docbook/technical-overview.xml index 0b733fcf5f..364a792c93 100644 --- a/docs/manual/src/docbook/technical-overview.xml +++ b/docs/manual/src/docbook/technical-overview.xml @@ -426,8 +426,8 @@ Successfully authenticated. Security context contains: \ Even though a ThreadLocal is being used, it is the same instance that is retrieved from the HttpSession for each thread. This has implications if you wish to temporarily change the context under which a thread - is running. If you just use - SecurityContextHolder.getContext().setAuthentication(anAuthentication), + is running. If you just use SecurityContextHolder.getContext(), + and call setAuthentication(anAuthentication) on the returned context object, then the Authentication object will change in all concurrent threads which share the same SecurityContext instance. You can customize the behaviour