diff --git a/docs/modules/ROOT/pages/servlet/authentication/anonymous.adoc b/docs/modules/ROOT/pages/servlet/authentication/anonymous.adoc
index b1b02c26b39..db3f7b53224 100644
--- a/docs/modules/ROOT/pages/servlet/authentication/anonymous.adoc
+++ b/docs/modules/ROOT/pages/servlet/authentication/anonymous.adoc
@@ -36,13 +36,19 @@ The filter and authentication provider is defined as follows:
 ----
 <bean id="anonymousAuthFilter"
 	class="org.springframework.security.web.authentication.AnonymousAuthenticationFilter">
-<property name="key" value="foobar"/>
-<property name="userAttribute" value="anonymousUser,ROLE_ANONYMOUS"/>
+<constructor-arg value="foobar"/>
+<constructor-arg value="anonymousUser"/>
+<constructor-arg>
+	<bean class="org.springframework.security.core.authority.AuthorityUtils"
+		factory-method="commaSeparatedStringToAuthorityList">
+	<constructor-arg value="ROLE_ANONYMOUS"/>
+	</bean>
+</constructor-arg>
 </bean>
 
 <bean id="anonymousAuthenticationProvider"
 	class="org.springframework.security.authentication.AnonymousAuthenticationProvider">
-<property name="key" value="foobar"/>
+<constructor-arg value="foobar"/>
 </bean>
 ----
 
@@ -52,15 +58,14 @@ The `key` is shared between the filter and authentication provider, so that toke
 
 [NOTE]
 ====
-The use of the `key` property should not be regarded as providing any real security here.
+The use of the `key` should not be regarded as providing any real security here.
 It is merely a book-keeping exercise.
 If you share a `ProviderManager` that contains an `AnonymousAuthenticationProvider` in a scenario where it is possible for an authenticating client to construct the `Authentication` object (such as with RMI invocations), then a malicious client could submit an `AnonymousAuthenticationToken` that it had created itself (with the chosen username and authority list).
 If the `key` is guessable or can be found out, the token would be accepted by the anonymous provider.
 This is not a problem with normal usage. However, if you use RMI, you should use a customized `ProviderManager` that omits the anonymous provider rather than sharing the one you use for your HTTP authentication mechanisms.
 ====
 
-The `userAttribute` is expressed in the form of `usernameInTheAuthenticationToken,grantedAuthority[,grantedAuthority]`.
-The same syntax is used after the equals sign for the `userMap` property of `InMemoryDaoImpl`.
+The filter's constructor takes the `key`, followed by the principal and the granted authorities of the `AnonymousAuthenticationToken` that it creates.
 
 As explained earlier, the benefit of anonymous authentication is that all URI patterns can have security applied to them, as the following example shows:
 
diff --git a/docs/modules/ROOT/pages/servlet/configuration/xml-namespace.adoc b/docs/modules/ROOT/pages/servlet/configuration/xml-namespace.adoc
index f13585130a2..136d7bf6666 100644
--- a/docs/modules/ROOT/pages/servlet/configuration/xml-namespace.adoc
+++ b/docs/modules/ROOT/pages/servlet/configuration/xml-namespace.adoc
@@ -189,7 +189,7 @@ The password is prefixed with `+{bcrypt}+` to instruct `DelegatingPasswordEncode
 The `<http>` element is responsible for creating a `FilterChainProxy` and the filter beans that it uses.
 Previously common problems, such as incorrect filter ordering, are no longer an issue, as the filter positions are predefined.
 
-The `<authentication-provider>` element creates a `DaoAuthenticationProvider` bean, and the `<user-service>` element creates an `InMemoryDaoImpl`.
+The `<authentication-provider>` element creates a `DaoAuthenticationProvider` bean, and the `<user-service>` element creates an `InMemoryUserDetailsManager`.
 All `authentication-provider` elements must be children of the `<authentication-manager>` element, which creates a `ProviderManager` and registers the authentication providers with it.
 You can find more detailed information on the beans that are created in the xref:servlet/appendix/namespace/index.adoc#appendix-namespace[namespace appendix].
 You should cross-check this appendix if you want to start understanding what the important classes in the framework are and how they are used, particularly if you want to customize things later.
diff --git a/kerberos/kerberos-web/src/main/java/org/springframework/security/kerberos/web/authentication/SpnegoAuthenticationProcessingFilter.java b/kerberos/kerberos-web/src/main/java/org/springframework/security/kerberos/web/authentication/SpnegoAuthenticationProcessingFilter.java
index 568b9a669cb..8ff7fd458bc 100644
--- a/kerberos/kerberos-web/src/main/java/org/springframework/security/kerberos/web/authentication/SpnegoAuthenticationProcessingFilter.java
+++ b/kerberos/kerberos-web/src/main/java/org/springframework/security/kerberos/web/authentication/SpnegoAuthenticationProcessingFilter.java
@@ -87,14 +87,9 @@
  * 	&lt;property name=&quot;userDetailsService&quot; ref=&quot;inMemoryUserDetailsService&quot; /&gt;
  * &lt;/bean&gt;
  *
- * &lt;bean id=&quot;inMemoryUserDetailsService&quot;
- * 	class=&quot;org.springframework.security.core.userdetails.memory.InMemoryDaoImpl&quot;&gt;
- * 	&lt;property name=&quot;userProperties&quot;&gt;
- * 		&lt;value&gt;
- * 			mike@SECPOD.DE=notUsed,ROLE_ADMIN
- * 		&lt;/value&gt;
- * 	&lt;/property&gt;
- * &lt;/bean&gt;
+ * &lt;sec:user-service id=&quot;inMemoryUserDetailsService&quot;&gt;
+ * 	&lt;sec:user name=&quot;mike@SECPOD.DE&quot; authorities=&quot;ROLE_ADMIN&quot; /&gt;
+ * &lt;/sec:user-service&gt;
  * &lt;/beans&gt;
  * </pre>
  *