spring security中最简单的AuthenticationProvider实现 是DaoAuthenticationProvider，这也是框架中最早支持的功能之一。 它是UserDetailsService的杠杆（作为DAO）， 为了获得username, password和GrantedAuthority。 它认证用户，通过简单比较密码，在UsernamePasswordAuthenticationToken中， 和UserDetailsService中加载的信息。 配置供应器十分简单：

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

PasswordEncoder和SaltSource 都是可选的，一个PasswordEncoder提供了编码和解码密码， 在UserDetails对象中，被返回自配置好的 UserDetailsService。一个SaltSource 可以让密码使用"盐值"生成，这可以提高授权仓库中密码的安全性。更多的细节会在 下面进行讨论。

创建一个自定义的UserDetailsService的实现是很容易的， 可以从选择的持久化引擎中获得信息，但是许多应用没有那么复杂。尤其是如果你建立一个原型应用 或只是开始集成Spring Security的时候，当我们不是真的需要耗费时间配置数据库或者写 UserDetailsService实现。为了这些情况， 一个简单的选择是使用安全命名空间中的 user-service元素：

  <user-service id="userDetailsService">
    <user name="jimi" password="jimispassword" authorities="ROLE_USER, ROLE_ADMIN" />
    <user name="bob" password="bobspassword" authorities="ROLE_USER" />
  </user-service>
  
                    

也支持使用外部的属性文件：

  <user-service id="userDetailsService" properties="users.properties"/>
  

属性文件需要包含下面格式的内容

username=password,grantedAuthority[,grantedAuthority][,enabled|disabled]

比如

 jimi=jimispassword,ROLE_USER,ROLE_ADMIN,enabled
 bob=bobspassword,ROLE_USER,enabled

Spring Security也包含了一个UserDetailsService， 它包含从一个JDBC数据源中获得认证信息。内部使用了Spring JDBC，所以它避免了负责的 功能完全的对象关系映射（ORM）只用来保存用户细节。如果你的应用使用了一个ORM工具， 你应该写一个自己的UserDetailsService 重用你已经创建了的映射文件。返回到JdbcDaoImpl， 一个配置的例子如下所示：

<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
  <property name="driverClassName" value="org.hsqldb.jdbcDriver"/>
  <property name="url" value="jdbc:hsqldb:hsql://localhost:9001"/>
  <property name="username" value="sa"/>
  <property name="password" value=""/>
</bean>

<bean id="userDetailsService" class="org.springframework.security.core.userdetails.jdbc.JdbcDaoImpl">
  <property name="dataSource" ref="dataSource"/>
</bean>        

你可以使用不同的关系数据库管理系统，通过修改上面的 DriverManagerDataSource。你也可以使用通过JNDI获得的全局数据源， 使用其他的Spring配置。

密码加密不是Spring Security唯一的，但这对一个不了解这个概念的用户来说 还是一个很容易搞混的来源。一个散列（或摘要）算法是一个单向方法提供了一小段固定长度 的输出数据（散列）从一些输入数据中，比如一个密码。作为一个例子， 字符串“password”的MD5散列（16进制）是

    5f4dcc3b5aa765d61d8327deb882cf99

散列是 “单向的” 在这种情况下，很难（基本上不可能）根据给出的散列值获得原始输入， 或是找出任何可能的输入将生成散列值。这个特点让散列值对权限方面很有用。 它们可以保存在你的用户数据库中作为原始明文密码的替换，假设这些值被泄露了 也无法立即盗取登录的密码。注意这也意味着你没有办法把编码后的密码还原。

使用密码加密的一个潜在的问题是，因为散列是单向的，如果输入是一个常用的单词的话 找到输入值就相对容易很多了。比如，如果我们查找散列值 5f4dcc3b5aa765d61d8327deb882cf99通过google。我们会很快找到 原始词是“password”。简单的方法，一个攻击者可以建立一个散列值的字典 把标准单词排列，使用它来查找原始密码。一个方法来帮助防止这种问题是使用高强度的密码 策略来防止使用常用单词。另一个是在计算散列时使用“盐值”。 这是一个对每个用户都知道的附加字符串，它会结合到密码中，在计算散列之前。 注意这个数值应该是尽可能的随机数，但是实际中任何盐值通常都是不可取的。 Spring Security有一个SaltSource接口， 可以被验证供应器用来为特定的用户生成一个盐值。 使用盐值，意味着攻击者必须创建单独的散列字典，为不同的盐值， 这让攻击更难了（但不是不可能）。

当一个认证供应器（比如Spring Security的DaoAuthenticationProvider） 需要检验密码，在提交认证请求中，与用户知道的数据进行比较，保存的密码通过一些方式进行了加密， 然后提交的数据必须也使用相同的算法进行加密。这要求你去检查兼容性，因为Spring Security 对持久化的没有任何控制。如果你在Spring Security的认证配置中添加了密码散列功能， 你的数据库包含原始明文密码，那么认证就绝对不可能成功。 如果你在数据库中使用MD5对密码加密，比如，你的应用配置为使用Spring Security的 Md5PasswordEncoder，这也有其他可能的问题。 数据库可能用Base 64进行了加密，比如当加密器使用16进制的字符串（默认） ^[5]。 可以选择，你的数据库可能使用了大写，当编码器输出的是小写。 确定你编写了一个测试来检测从你的密码编码器的输出，使用一个知道的密码和盐值结合 检测它是否与数据库值匹配，在更深入之前，尝试通过你的系统认证。 要想获得更多信息，在默认的方法从结合盐值和密码，查看 BasePasswordEncoder的Javadoc。如果你希望直接通过java生成密码， 为你的用户数据库保存，然后你可以使用PasswordEncoder的 encodePassword方法。