DAO Authentication Provider

Spring Security includes a production-quality AuthenticationProvider implementation called DaoAuthenticationProvider. This authentication provider is compatible with all of the authentication mechanisms that generate a UsernamePasswordAuthenticationToken, and is probably the most commonly used provider in the framework. Like most of the other authentication providers, the DaoAuthenticationProvider leverages a UserDetailsService in order to lookup the username, password and GrantedAuthority[]s. Unlike most of the other authentication providers that leverage UserDetailsService, this authentication provider actually requires the password to be presented, and the provider will actually evaluate the validity or otherwise of the password presented in an authentication request object.

Aside from adding DaoAuthenticationProvider to your ProviderManager list (as discussed at the start of this part of the reference guide), and ensuring a suitable authentication mechanism is configured to present a UsernamePasswordAuthenticationToken, the configuration of the provider itself is rather simple:

        
<bean id="daoAuthenticationProvider"
    class="org.springframework.security.providers.dao.DaoAuthenticationProvider">
  <property name="userDetailsService" ref="inMemoryDaoImpl"/>
  <property name="saltSource" ref bean="saltSource"/>
  <property name="passwordEncoder" ref="passwordEncoder"/>
</bean>        
    

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. A SaltSource enables the passwords to be populated with a "salt", which enhances the security of the passwords in the authentication repository. PasswordEncoder implementations are provided with Spring Security covering MD5, SHA and cleartext encodings. Two SaltSource implementations are also provided: 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 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 UserCache interface enables the DaoAuthenticationProvider to place a 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. A usable caching implementation is also provided, EhCacheBasedUserCache, which is configured as follows:

<bean id="daoAuthenticationProvider"
    class="org.springframework.security.providers.dao.DaoAuthenticationProvider">
  <property name="userDetailsService" ref="userDetailsService"/>
  <property name="userCache" ref="userCache"/>
</bean>
        
<bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
  <property name="configLocation" value="classpath:/ehcache-failsafe.xml"/>
</bean>
    
<bean id="userCacheBackend" class="org.springframework.cache.ehcache.EhCacheFactoryBean">
  <property name="cacheManager" ref="cacheManager"/>
  <property name="cacheName" value="userCache"/>
</bean>

<bean id="userCache" class="org.springframework.security.providers.dao.cache.EhCacheBasedUserCache">
  <property name="cache" ref="userCacheBackend"/>
</bean>        
    

All Spring Security EH-CACHE implementations (including EhCacheBasedUserCache) require an EH-CACHE Cache object. The Cache object can be obtained from wherever you like, although we recommend you use Spring's factory classes as shown in the above configuration. If using Spring's factory classes, please refer to the Spring documentation for further details on how to optimise the cache storage location, memory usage, eviction policies, timeouts etc.

A design decision was made not to support account locking in the DaoAuthenticationProvider, as doing so would have 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 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 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 operate with Strings (as was the case for releases prior to Spring Security 0.6), you should set the DaoAuthenticationProvider.forcePrincipalAsString property to true in your application context