diff --git a/docs/manual/src/docbook/appendix-namespace.xml b/docs/manual/src/docbook/appendix-namespace.xml index 8584b8ad66..f618e11b6a 100644 --- a/docs/manual/src/docbook/appendix-namespace.xml +++ b/docs/manual/src/docbook/appendix-namespace.xml @@ -459,7 +459,12 @@ instance for use in your own configuration. Its use is described in the namespace introduction. All elements which create AuthenticationProvider instances should be children of this - element. + element. + + The element also exposes an erase-credentials attribute which maps + to the eraseCredentialsAfterAuthentication property of + the ProviderManager. This is discussed in the + Core Services chapter.
The <literal><authentication-provider></literal> Element Unless used with a ref attribute, this element is shorthand for configuring a diff --git a/docs/manual/src/docbook/core-services.xml b/docs/manual/src/docbook/core-services.xml index 99ce04189e..29cd586e6b 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 @@ -99,6 +99,28 @@ repository. These will be discussed in more detail below.
+
+ Erasing Credentials on Successful Authentication + + From Spring Security 3.0.3, you can configure the ProviderManager + will attempt to clear any sensitive credentials information from the + Authentication object which is returned by a successful + authentication request, to prevent information like passwords being retained longer + than necessary. This feature is controlled by the eraseCredentialsAfterAuthentication + property on ProviderManager. It is off by default. + See the Javadoc for more information. + + + This may cause issues when you are using a cache of user objects, for example, to + improve performance in a stateless application. If the Authentication + contains a reference to an object in the cache (such as a UserDetails + instance) and this has its credentials removed, then it will no longer be possible to authenticate + against the cached value. You need to take this into account if you are using a cache. An obvious + solution is to make a copy of the object first, either in the cache implementation or in + the AuthenticationProvider which creates the returned + Authentication object. + +
<interfacename>UserDetailsService</interfacename> Implementations