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 <authentication-provider> 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.
+
+ UserDetailsService Implementations