(通译)Spring Security-2.0.x参考文档“摘要式认证”
(翻译)Spring Security-2.0.x参考文档“摘要式认证”
摘要式认证
13.1. 概述
Spring Security提供了一个 DigestProcessingFilter，它可以处理HTTP头部中的摘要认证证书。 摘要认证在尝试着解决许多基本认证的缺陷，特别是保证不会通过纯文本发送证书。 许多用户支持摘要式认证，包括FireFox和IE。 HTTP摘要式认证的执行标准定义在RFC 2617，它是对RFC 2069这个早期摘要式认证标准的更新。 Spring Security DigestProcessingFilter会保证"auth"的安全质量（qop），它订明在RFC 2617中，并与RFC 2069提供了兼容。 如果你需要使用没有加密的HTTP（比如没有TLS/HTTP），还希望认证达到最大的安全性的时候，摘要式认证便具有很高吸引力。 事实上，摘要式认证是WebDAV协议的强制性要求，写在RFC 2518的17.1章，所以我们应该期望看到更多的代替基本认证。
摘要式认证，是表单认证，基本认证和摘要式认证中最安全的选择，不过更安全也意味着更复杂的用户代理实现。 摘要式认证的中心是一个“nonce”。 这是由服务器生成的一个值。 Spring Security的nonce采用下面的格式：
base64(expirationTime + ":" + md5Hex(expirationTime + ":" + key))
expirationTime: The date and time when the nonce expires, expressed in milliseconds
key: A private key to prevent modification of the nonce token
这个DigestProcessingFilterEntryPoint有一个属性，通过指定一个key来生成nonce标志，通过nonceValiditySeconds属性来决定过期时间（默认300，等于5分钟）。 只要nonce是有效的，摘要就会通过串联字符串计算出来，包括用户名，密码，nonce，请求的URI，一个客户端生成nonce（仅仅是一个随机值，用户代理每个请求生成一个），realm名称等等，然后执行一次MD5散列。 服务器和用户代理都要执行这个摘要计算，如果他们包含的值不同（比如密码），就会生成不同的散列码。 在Spring Security的实现中，如果服务器生成的nonce已经过期（但是摘要还是有效），DigestProcessingFilterEntryPoint会发送一个"stale=true"头信息。 这告诉用户代理，这里不再需要打扰用户（像是密码和用户其他都是正确的），只是简单尝试使用一个新nonce。
DigestProcessingFilterEntryPoint的 nonceValiditySeconds参数，会作为一个适当的值依附在你的程序上。 对安全要求很高的用户应该注意，一个被拦截的认证头部可以用来假冒主体，直到nonce达到expirationTime。 在选择合适的配置的时候，这是一个必须考虑到的关键性条件，但是在对安全性要求很高的程序里，第一次请求都会首先运行在TLS/HTTPS之上。
因为摘要式认证需要更复杂的实现，这里常常有用户代理的问题。 比如，IE不能在同一个会话的请求进程里阻止"透明"标志。 因此Spring Security把所有状态信息都概括到"nonce"标记里。 在我们的测试中，Spring Security在FireFox和IE里都可以工作，正确的处理nonce超时等等。
13.2. 配置
现在我们重新看一下理论，让我们看看如何使用它。 为了实现HTTP摘要认证，必须在过滤器链里定义DigestProcessingFilter。 application context还需要定义DigestProcessingFilter和它需要的合作伙伴：
<bean id="digestProcessingFilter"
class="org.springframework.security.ui.digestauth.DigestProcessingFilter">
<property name="userDetailsService" ref="jdbcDaoImpl"/>
<property name="authenticationEntryPoint" ref="digestProcessingFilterEntryPoint"/>
<property name="userCache" ref="userCache"/>
</bean>
<bean id="digestProcessingFilterEntryPoint"
class="org.springframework.security.ui.digestauth.DigestProcessingFilterEntryPoint">
<property name="realmName" value="Contacts Realm via Digest Authentication"/>
<property name="key" value="acegi"/>
<property name="nonceValiditySeconds" value="10"/>
</bean>
需要配置一个UserDetailsService，因为 DigestProcessingFilter必须直接访问用户的纯文本密码。 如果你在DAO中使用编码过的密码，摘要式认证就没法工作。 DAO合作者，与UserCache一起，通常使用DaoAuthenticationProvider直接共享。 这个authenticationEntryPoint属性必须是DigestProcessingFilterEntryPoint，这样DigestProcessingFilter可以在进行摘要计算时获得正确的realmName和key。
像BasicAuthenticationFilter一样，如果认证成功，会把Authentication请求标记放到SecurityContextHolder中。 如果认证事件成功，或者认证不需要执行，因为HTTP头部没有包含摘要认证请求，过滤器链会正常继续。 过滤器链中断的唯一情况是，如果认证失败，就会像上面讨论的那样调用AuthenticationEntryPoint。
摘要式认证的RFC要求附加功能范围，来更好的提升安全性。 比如，nonce可以在每次请求的时候变换。 但是，Spring Security的设计思路是最小复杂性的实现（毫无疑问，用户代理会出现不兼容），也避免保存服务器端的状态。 如果你想研究这些功能的更多细节，我们推荐你看一下RFC 2617。 像我们知道的那样，Spring Security实现类遵守了RFC的最低标准。
摘要式认证
13.1. 概述
Spring Security提供了一个 DigestProcessingFilter，它可以处理HTTP头部中的摘要认证证书。 摘要认证在尝试着解决许多基本认证的缺陷，特别是保证不会通过纯文本发送证书。 许多用户支持摘要式认证，包括FireFox和IE。 HTTP摘要式认证的执行标准定义在RFC 2617，它是对RFC 2069这个早期摘要式认证标准的更新。 Spring Security DigestProcessingFilter会保证"auth"的安全质量（qop），它订明在RFC 2617中，并与RFC 2069提供了兼容。 如果你需要使用没有加密的HTTP（比如没有TLS/HTTP），还希望认证达到最大的安全性的时候，摘要式认证便具有很高吸引力。 事实上，摘要式认证是WebDAV协议的强制性要求，写在RFC 2518的17.1章，所以我们应该期望看到更多的代替基本认证。
摘要式认证，是表单认证，基本认证和摘要式认证中最安全的选择，不过更安全也意味着更复杂的用户代理实现。 摘要式认证的中心是一个“nonce”。 这是由服务器生成的一个值。 Spring Security的nonce采用下面的格式：
base64(expirationTime + ":" + md5Hex(expirationTime + ":" + key))
expirationTime: The date and time when the nonce expires, expressed in milliseconds
key: A private key to prevent modification of the nonce token
这个DigestProcessingFilterEntryPoint有一个属性，通过指定一个key来生成nonce标志，通过nonceValiditySeconds属性来决定过期时间（默认300，等于5分钟）。 只要nonce是有效的，摘要就会通过串联字符串计算出来，包括用户名，密码，nonce，请求的URI，一个客户端生成nonce（仅仅是一个随机值，用户代理每个请求生成一个），realm名称等等，然后执行一次MD5散列。 服务器和用户代理都要执行这个摘要计算，如果他们包含的值不同（比如密码），就会生成不同的散列码。 在Spring Security的实现中，如果服务器生成的nonce已经过期（但是摘要还是有效），DigestProcessingFilterEntryPoint会发送一个"stale=true"头信息。 这告诉用户代理，这里不再需要打扰用户（像是密码和用户其他都是正确的），只是简单尝试使用一个新nonce。
DigestProcessingFilterEntryPoint的 nonceValiditySeconds参数，会作为一个适当的值依附在你的程序上。 对安全要求很高的用户应该注意，一个被拦截的认证头部可以用来假冒主体，直到nonce达到expirationTime。 在选择合适的配置的时候，这是一个必须考虑到的关键性条件，但是在对安全性要求很高的程序里，第一次请求都会首先运行在TLS/HTTPS之上。
因为摘要式认证需要更复杂的实现，这里常常有用户代理的问题。 比如，IE不能在同一个会话的请求进程里阻止"透明"标志。 因此Spring Security把所有状态信息都概括到"nonce"标记里。 在我们的测试中，Spring Security在FireFox和IE里都可以工作，正确的处理nonce超时等等。
13.2. 配置
现在我们重新看一下理论，让我们看看如何使用它。 为了实现HTTP摘要认证，必须在过滤器链里定义DigestProcessingFilter。 application context还需要定义DigestProcessingFilter和它需要的合作伙伴：
<bean id="digestProcessingFilter"
class="org.springframework.security.ui.digestauth.DigestProcessingFilter">
<property name="userDetailsService" ref="jdbcDaoImpl"/>
<property name="authenticationEntryPoint" ref="digestProcessingFilterEntryPoint"/>
<property name="userCache" ref="userCache"/>
</bean>
<bean id="digestProcessingFilterEntryPoint"
class="org.springframework.security.ui.digestauth.DigestProcessingFilterEntryPoint">
<property name="realmName" value="Contacts Realm via Digest Authentication"/>
<property name="key" value="acegi"/>
<property name="nonceValiditySeconds" value="10"/>
</bean>
需要配置一个UserDetailsService，因为 DigestProcessingFilter必须直接访问用户的纯文本密码。 如果你在DAO中使用编码过的密码，摘要式认证就没法工作。 DAO合作者，与UserCache一起，通常使用DaoAuthenticationProvider直接共享。 这个authenticationEntryPoint属性必须是DigestProcessingFilterEntryPoint，这样DigestProcessingFilter可以在进行摘要计算时获得正确的realmName和key。
像BasicAuthenticationFilter一样，如果认证成功，会把Authentication请求标记放到SecurityContextHolder中。 如果认证事件成功，或者认证不需要执行，因为HTTP头部没有包含摘要认证请求，过滤器链会正常继续。 过滤器链中断的唯一情况是，如果认证失败，就会像上面讨论的那样调用AuthenticationEntryPoint。
摘要式认证的RFC要求附加功能范围，来更好的提升安全性。 比如，nonce可以在每次请求的时候变换。 但是，Spring Security的设计思路是最小复杂性的实现（毫无疑问，用户代理会出现不兼容），也避免保存服务器端的状态。 如果你想研究这些功能的更多细节，我们推荐你看一下RFC 2617。 像我们知道的那样，Spring Security实现类遵守了RFC的最低标准。