# DAO Authentication Provider

## Overview

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.

## Configuration

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.

In the majority of cases, where your application is a stateful web application, you don't need to use a cache as the user's authentication information will be stored in the `HttpSession`.

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 `String`s (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