《Spring Security3》第十二章翻译（Spring Security扩展）

 

第十二章 Spring Security扩展

         在本章中，我们将会探索一个Spring Security扩展项目的功能——这是很令人兴奋的功能即将Windows Active Directory认证（或其它支持Kerberos的设施）与Spring Security集成以为你的Intranet用户提供完善的单点登录体验。

         在本章中，我们将会：

l 学习Kerberos认证协议及其基于web的凭证；

l  理解使用Kerberos的web应用怎样适用于基于Kerberos的安全设施；

l  配置JBCP Pets应用通过使用Active Directory认证存储为Windows用户提供单点登录认证功能；

l  探索使用Active Directory作为LDAP  UserDetailsService从而在唯一的位置存储用户数据。

Spring Security扩展

         Spring Security扩展（Spring Security Extensions）项目（可以通过以下地址访问：http://static.springsource.org/spring-security/site/extensions.html  ）作为Spring Security扩展功能的孵化器，基于Spring Security的核心框架构建。尽管这个项目相对很新，但是它已经有三个令人兴奋的模块包括Kerberos authentication（Spring Security 2中NTLM的继续），Security Assertion Markup Language 2.0 认证以及Portlet认证。

         在本章中，我们将会介绍Kerberos SPNEGO认证的基本配置和使用。在写这些内容的时候，Spring Security扩展都还没有官方释放，但是Kerberos项目足够稳定所以你读到这些内容的时候应该不会有明显的配置变化。通过这些非官方、社区开发的扩展，我们可以将本章的内容视为对Spring Security实验功能的探究。

Kerberos和SPNEGO认证入门

Kerberos是一个相互的认证协议，用来对认证客户端——独立的用户或网络资源——这通过使用名为KDC（key distribution center）的中心凭证存储。客户端与KDC之间的交互很复杂，在一些互联网标准中有很好的文档（主要是RFC 4120, The Kerberos Network Authentication Service （V5），可以在以下地址查阅：http://tools.ietf.org/html/rfc4120）。

在本章中为了进行讨论，我们将会简化Kerberos设施检查凭证活动的细节。Kerberos认证和Kerberos设施的主要目的是对安全实体（principal）提供安全可信的认证，而这里的安全实体可以是用户、网络资源或软件应用。Kerberos的协议本身和软件实现最初是由麻省理工学院（MIT）开发的。鉴于Kerberos有这样一个光辉的背景，有很多不错的书详细讲解Kerberos的细节。

在Kerberos认证协议之上，开发出了Generic Security Service Application Program Interface （GSS-API），这也是基于RFC标准（RFC 2078, Generic Security Service Application Program Interface, Version 2, http://tools.ietf.org/html/rfc2078）。GSS-API提供了标准的、跨平台、跨语言的认证和安全接口，并包装了Kerberos（以及其它的认证提供者）。它的开发目标是为安全开发人员提供一致的认证和安全编程接口而不需要了解特定安全协议的细节。

GSS-API在Java语言中的标准实现在另一个RFC标准中定义（RFC 2853, Generic Security Service API Version 2: Java Bindings, http://tools.ietf.org/html/rfc2853），它在Sun JVM的org.ietf.jgss包中实现。

【在java支持Kerberos和GSS-API中，有一个很重要的事情是API的实现以及API本身是JRE的一部分，不需要引入任何第三方的库。实际上，你可以查询Sun的站点（http://java.sun.com/javase/6/docs/technotes/guides/security/jgss/tutorials/index.html）来了解这些Sun JVM功能的更多文档。注意的是，其它的JVM实现可能不会像Sun JVM那样提供相同的功能。】

将GSS-API认证集成到web浏览器中是通过使用一个名为Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)的信息交换标准做到的。SPNEGO是明确两个GSS-API实现间行为的算法，确定了它们之间是否可以通过一个通用的安全协议进行通信。就Kerberos SPNEGO而言，我们希望客户端和服务端交互的通用安全协议是Kerberos。

尽管SPNEGO可以被用来进行支持GSS-API的应用或系统通信，但是对于web应用开发人员和安全设计人员来说，这个词汇更多是意味着web客户端认证。Microsoft支持的RFC 4559 （SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows, http://tools.ietf.org/html/rfc4559）描述了服务器通过HTTP协议使用SPNEGO请求来要求GSS-API认证。客户端浏览器就可以响应SPNEGO请求并利用原生的操作系统支持从终端用户那里收集凭证信息。Microsoft为它的Windows操作系统开发了这个规范以支持两个GSS-API的实现——其专有的NT LAN Manager (NTLM)协议和开放的Kerberos协议。最终，这种从基于Window的客户端到Kerberos服务端资源的便利单点登录方式使得其他的浏览器也适应了这种基于浏览器的SPNEGO，包括Mozilla Firefox和Apple Safari。

希望我们没有使你掉进术语汤中（译者注：即被这些术语所迷惑）！让我们现实一些了解这些在基于web认证的场景下是如何工作的。

下图展现了在SPNEGO Kerberos认证过程中，三个参与者之间的交互：

 在进入Spring Security实现Kerberos的SPNEGO认证之前，理解客户端浏览器和应用服务器之间的两个重要HTTP交互是很重要的。

l  当需要认证时，应用服务器必须发送一个包含WWW-Authenticate: Negotiate 值的HTTP响应头给客户端。这会告诉客户端需要使用SPNEGO协议进行认证；

l  客户端要确定用户的凭证（可能会使用弹出提示，这取决于浏览器实现和操作系统），并将凭证信息编码到HTTP Authorize请求头中响应给服务器。

在这里我们更多关注了浏览器和应用服务器的交互，因为这是大多数Spring Security集成所关注的部分。

【尽管SPNEGO成功实现并没有要求，但是我们建议在生产环境中使用SSL，这样SSO凭证能够在web客户端认证过程中保持安全。】

另一个要考虑的重要设施是Kerberos KDC实现。存在开源的选择，其中最主要的就是MIT（著名的大学）的Kerberos实现，这也是Kerberos技术的最初贡献者之一，但是，在企业环境中，开发人员最常见的实现是Microsoft Active Directory （AD）。Windows服务器的Active Directory可以作为Kerberos KDC的功能，所以如果一个组织使用了AD，那也就会自动启用了基于Kerberos的认证。

在Spring Security实现Kerberos认证

         与我们已经看到过的CAS和客户端证书认证类似，对于使用Kerberos安全的站点Kerberos Single Sign-On (SSO)将会作为唯一支持的认证机制（尽管在本章临近结束的时候我们将会看待一种替代的配置以支持form登录）。让我们看一下为Spring Security配置支持Kerberos的基本步骤，随后，我们将会介绍Kerberos环境中其它参与者所需要的配置。

Kerberos Spring Security认证整体流程

         正如我们在整体介绍SPNEGO协议设计时所讲的，关键实现在于客户端浏览器与安全应用之间的信息交换。这就是Spring Security's Kerberos Extension介入的地方——来处理认证凭证的交互。

         如同典型的外部认证存储，如我们看到过的CAS（在第十章：使用CAS进行单点登录和第十一章：客户端证书认证），联合使用一个servlet过滤器和自定义的AuthenticationProvider来进行外部存储的认证并校验返回响应的可靠性和可验证性。

         让我们看一下使用Spring Security进行SPNEGO认证相关的重要类，如下图：

 我们可以看到o.s.s.extensions.kerberos.KerberosServiceAuthenticationProvider主要负责协调校验浏览器SPNEGO响应的合法性。稍后，我们将会介绍将这些类组织在一起的Spring Bean配置细节。

准备工作

         配置任何的Kerberos环境，尤其是Microsoft Active Directory后台，而你又没有Kerberos经验的话会很耗时和复杂。如果你要配置使用Kerberos的应用到一个环境中去，在开始之前要确保环境被正确配置了，否则你将花费更多的时间在诊断环境上而不是开发你的应用上。

         在本课程中，我们假设你写的应用要到Microsoft Active Directory（AD）环境中进行认证，这（对于大多数用户）是结合Spring Security和Kerberos的最常见场景。如果你就是这样，当你读到“Kerberos安全实体”（Kerberos principal），只需将其等同于AD用户。

         在开始之前，要确保：

         你已经为web应用本身建立的一个Kerberos安全实体。我们将会使用这个账号进行应用服务器的附加配置；

         连接站点的电脑（也就是web浏览器运行的机器）必须是Kerberos认证域（Kerberos authentication realm）的一部分。对于Windows用户，这意味着这个电脑必须是AD域（AD domain）的一部分；

         运行web浏览器的电脑运行web应用的电脑不能是同一台机器。对你来说，虚拟机是很便利的选择。

         记住的是Kerberos SSO一般部署在intranet应用中，并运行在AD或Kerberos Realm里，而不会用在面向公众的web应用中。

例子的假设

         在本章的Kerberos例子中，我们假设要建立的环境如下：

配置	值	描述
域名（Domain Name）	jbcppets.com	我们公司网络和站点的域名
AD域（AD domain）	corp.jbcppets.com	Active Directory域——与Kerberos域名匹配（简介起见缩写为CORP）
Web站点安全实体（Website principal）	CORP\website	对应于web站点服务的AD用户

 

创建keytab文件

         你需要创建一个keytab文件，它用来认证要访问KDC的web应用并允许对用户提供的凭证进行认证。keytab文件是一个Kerberos安全实体私钥的加密备份，在向Kerberos服务器认证安全实体的时候能够代替密码。

         我们的应用使用基于web的SPNEGO Kerberos认证。相关的协议RFC（RFC 4559）规定了keytab必须匹配安全实体且以HTTP/fully.qualified.web.server.name作为标识符（这必须与规范声明完全一致）。在我们实例的配置中，我们假设JBCP Pets应用运行在web.jbcppets.com上并在Kerberos域corp.jbcppets.com中，所以在keytab中的实体名应该是HTTP/[e-mail]。

         因为我们以AD作为Kerberos KDC，所以我们需要将AD用户CORP\website与需要的安全实体进行匹配。我们可以使用Microsoft的ktpass工具（在AD域控制器中）来完成，如下：

ktpass -princ HTTP/[e-mail] -mapuser CORP\website -out website.keytab

         你会看到命令的参数与我们以下描述的配置场景所匹配：

l HTTP/[e-mail]：Kerberos安全实体的名字（HTTP/web.jbcppets.com）与域（CORP.JBCPPETS.COM）；

l  CORP\website：与Kerberos安全实体相匹配的域用户名。

注意的是Kerberos域是大小写敏感的，所以要确保在所有环境中大小写一致。便利起见，Kerberos域通常声明为大写。

         这将会在当前目录下创建名为website.keytab的文件。你需要安全的将这个文件传输到运行web应用的机器上以在Spring Security中配置Kerberos。将其放在JBCP Pets web应用的WEB-INF/classes目录下——当我们稍后配置Spring Security Kerberos bean的时候会用到。

【留意这个keytab文件——它包含了到Kerberos域信息，这些信息与预认证凭证相同。不要使用不安全的文件传输技术来复制这个文件到目标服务器，因为这会使你有被网络监听的风险。如果这个文件是缺乏安全的，恶意用户可以使用这些凭证登录你的Kerberos域，就像web应用用户那样。】

注意，ktpass包含在Windows 2008 Server和以后的版本中。以前版本的Windows Server可能需要安装Kerberos支持文件才能使用这些命令行工具。

配置Kerberos相关的Spring bean

         鉴于大多数的Kerberos认证发生在Sun JVM里面，所以在Spring Security Kerberos认证中没有太多的配置（甚至代码）。

         首先，我们要配置AuthenticationEntryPoint来负责发送WWW-Authenticate头，它会首先进入客户端机器并响应Kerberos凭证。在dogstore-base.xml中的bean声明如下：

 

<bean id="kerbEntryPoint"
 class="org.springframework.security.extensions.kerberos.web.SpnegoEntryPoint" />

 接下来，我们要声明解析传入Authorization HTTP请求头并将其按照SPNEGO登录请求进行处理的过滤器：

 

<bean id="kerbAuthenticationProcessingFilter"
class="org.springframework.security.extensions.kerberos.web.SpnegoAuthenticationProcessingFilter">
  <property name="authenticationManager" ref="authenticationManager" />
</bean>

 要记住的是，与我们之前看到的其它SSO实现相同，这个过滤器负责解析SSO头并基于这个头信息来尝试认证用户。SpnegoAuthenticationProcessingFilter将会基于HTTP Authorization头中的凭证填充一个o.s.s.extensions.kerberos.KerberosServiceRequestToken对象。

         现在，我们需要一个AuthenticationProvider，它要提取被填充的KerberosServiceRequestToken对象里面的凭证信息并进行校验。与我们看到的CAS认证类似，Kerberos AuthenticationProvider要负责将token与ticket授予者进行校验。

 

<bean  id="kerberosServiceAuthenticationProvider" 
class="org.springframework.security.extensions.kerberos.KerberosServiceAuthenticationProvider">
  <property name="ticketValidator" ref="ticketValidator"/>
  <property name="userDetailsService" ref="jdbcUserService" />
</bean>
<bean id="ticketValidator"
 class="org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator">
  <property name="servicePrincipal" value="HTTP/[e-mail]" />
  <property name="keyTabLocation" value="classpath:website.keytab"/>
</bean>

 KerberosServiceAuthenticationProvider需要引用o.s.s.extensions.kerberos.KerberosTicketValidator代理实现，后者用来校验从认证token所获取的Kerberos ticket。Spring Security Kerberos Extension中提供的唯一实现是使用Sun JVM's GSS-API来校验keytab的内容并为服务实体执行对Kerberos ticket的校验。

         我们可以看到servicePrincipal和keyTabLocation引用了我们在前面Kerberos server中所作的配置。

         【keytab文件应该放在哪里？我们记得keytab文件是高安全风险的元素，所以，不建议将其放在应用的classpath中（尽管这部署起来很方便）。相反，建议将其放在web应用部署目录以外的文件系统中。你可以使用Spring标准的file:语法来引用这个文件。】

         你可以看到我们配置引用了JDBC UserDetailsService（临时的）。你需要记住往JDBC启动SQL中添加一个新的用户，其用户名要与试图登录的Kerberos用户相匹配。例如，如果你想以用户kerbuser登录应用，所以数据库中完整的用户名应该是包含完整Kerberos实体的[e-mail]。将其添加到WEB-INF/classes/test-users-groups-data.sql中，如下：

 

insert into users(username, password, enabled, salt) values ('[e-mail]','unused',true,CAST(RAND()*1000000000 AS varchar));
insert into group_members(group_id, username) select id,'[e-mail]' from groups where group_name='Administrators';

 需要注意的是使用Active Directory，一般会用到LDAP UserDetailsService，甚至一个自定义的来适应你的业务需求。稍后我们将会介绍这种风格的配置。

织入SPNEGO到security命名空间中

         现在我们需要将已经配置的bean织入到security命名空间配置元素中。首先，我们需要添加对我们新AuthenticationEntryPoint的引用（很像我们在第十章的CAS配置），如下：

 

<http ... 
  entry-point-ref="kerbEntryPoint">

 我们需要将SPNEGO过滤器插入到Spring Security过滤器链中。一个适当位置应该是用SPNEGO过滤器来取代form登录过滤器，如下：

 

<custom-filter ref="kerbAuthenticationProcessingFilter"  position="FORM_LOGIN_FILTER" />

 最后，我们需要一个<authentication-provider>引用新的AuthenticationProvider来负责处理SPNEGO tickets。现在我们添加它：

 

<authentication-manager alias="authenticationManager">
  <authentication-provider ref="kerberosServiceAuthenticationProvider"/>
</authentication-manager>

 这是为我们应用使用SPNEGO SSO安全所需要的额外配置。

         如果你的机器已经正确配置Kerberos认证，现在你可以重启web应用并在域中的另一台机器尝试进行认证。

         首先来尝试使用IE，IE几乎不需要任何配置来使得用户手动响应SPNEGO请求。你在访问受保护页面如“My Account”页面时会看到一个类似于下面的弹出框：

 祝贺你——如果你看到了这个弹出提示，在你提供正确的凭证后就能访问“My Account”页面了，你已经为你的web应用成功配置了Kerberos认证。

         接下来是配置IE基于请求传递用户的网络凭证。必须设置如下的配置IE才能透明的响应SPNEGO SSO请求：

l  确保站点添加到“本地Intranet”安全区域中。你可以使用“Internet选项”中的“安全”tab标签手动添加你的站点到安全区域中；

l  通过检查“启用保护模式”复选框来确保对于intranet区域启用了IE保护模式；

l  在“高级”tab标签中，确保“启动集成windows验证”复选框是选中的。

通过以上明确指明以上的配置（并将IE重启），你应该看到登录用户的凭证会通过SPNEGO认证自动发送到站点上，用户马上就会登录成功。

添加应用服务器所在机器到Kerberos域中

         如果你是一台新的机器上工作还有最后的一步——配置系统范围内的Kerberos配置，以使得Sun GSS-API能够确定到哪里寻找对域中用户进行认证的Kerberos KDC。这需要创建一个krb5.ini文件，它通常放在Windows安装目录下（c:\Windows或等价目录）。

         因为这个文件的配置语法超出了本书的范围，以下的基本配置在单个域的环境中就足够了，其中KDC位于corp.jbcppets.com。

[domain_realm]

.jbcppets.com = CORP.JBCPPETS.COM

[libdefaults]

default_realm = CORP.JBCPPETS.COM

[logging]

[realms]

CORP.JBCPPETS.COM = {

  kdc = corp.jbcppets.com

}

         作为krb5.ini文件的替代方式，也可以使用JVM的属性来声明默认的域和KDC，如下表：

参数	描述	例子
-Djava.security.krb5.realm	默认域	CORP.JBCPPETS.COM
-Djava.security.krb5.kdc	默认KDC	corp.jbcppets.com

         一般来说，我们建议使用krb5.ini，因为这个文件也可以被其它启用Kerberos的应用所使用。

对Firefox用户的特殊考虑

         默认情况下，Firefox不支持Kerberos认证。这有其历史原因（有些人说这增加了安全性），但是不管怎样，默认情况下，当收到WWW-Authenticate: Negotiate请求头，firefox不会提示用户。

         Firefox的用户必须在about:config页面中修改一个设置以明确添加凭证自动发送到的域，这通过在network.negotiate-auth.trusted-uris参数提供域名，如下面的截图所述：

 通过修改默认的（为空）设置，Firefox会自动的将你的Windows域凭证基于请求发送到站点上。这个属性对于不熟悉的用户是隐藏的，如果这进行了修改的话，配置Firefox支持SPNEGO要比IE容易得多。

问题解决

         不幸的是，Kerberos的正确配置特别复杂（特别对于第一次接触的开发者或管理员），而启用Kerberos的web应用增加了这种复杂性。

使用标准工具测试连接

         首先也是最重要的，确认底层的Kerberos基础设施能够正确运行。这意味着你应该使用标准的Kerberos工具（如kinit或ktab）或者图形化的客户端如MIT Kerberos for Windows（KfW）客户端（可在这里获取：http://web.mit.edu/Kerberos/ ）来进行校验。

         kinit和ktab是标准JDK发布版的一部分——ktab的实例命令行如下

ktab -a [e-mail] -k kerbuser.keytab

Password for [e-mail]:xxxxx  Done!

Service key for [e-mail] is saved in kerbuser.keytab

         MIT Kerberos实现提供了图形化的登录和配置界面，这对于新用户来说可能会更容易掌握。

启用Java GSS-API调试

         在Java GSS-API中没有太多的日志，而这个库在通过Kerberos进行认证时做了大量的工作，所以如果能够得到其内部如何工作的将会很有用处。你可以设置JVM属性-Dsun.security.krb5.debug=true或者设置SunJaasKerberosTicketValidator bean的debug属性如下：

 

<bean id="ticketValidator"
 class="org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator">
  <property name="servicePrincipal" value="HTTP/[e-mail]" />
   <property name="keyTabLocation" value="classpath:website.keytab"/>
  <property name="debug" value="true"/>
</bean>

 这两种方式都会在失败的情况下在应用服务器的控制台打印出一些有用的信息。

其它问题解决步骤

         在使用Spring Security Kerberos Extension以kerberizing（将Kerberos用到）你的web应用时，解决常见问题的一些建议如下：

l  确保对Spring Security设置标准级别的日志，对the org.springframework.security.extensions.kerberos包至少是WARN级别或更高。如果应用服务器存在配置问题或ticket校验问题，它们一般会在Spring日志中看到；

l  使用网络监控工具或抓包工具来监控应用服务器和KDC之间的通信。这种工具在监控客户端浏览器和应用服务器时，也会很有用处；

l  如果你使用的是Windows，不要在运行服务器的机器上使用浏览器来进行测试——它将不会好用。这是因为Windows将会自动使用NTLM认证。NTLM认证使用相似的request/response头交换，但是使用不同的数据格式。校验这个问题的一个方式就是查看客户端浏览器返回Negotiate头这部分的Spring日志。如果这个头信息以TlRM开头，它就是一个NTLM头而不是SPNEGO。SPNEGO头会以YII开头并且很长；

l  确保你以域用户而不是本地用户登录Windows，否则Windows将会尝试进行NTLM认证；

l  确保DNS方案对于Kerberos认证过程所有参与者都能运行，包括服务端和客户端机器。

         即使有了这些解决问题的步骤，可能也会发现成功部署SPNEGO和Kerberos也很有挑战——不要放弃，你会成功的！

配置LDAP UserDetailsService使用Kerberos

         简便起见，我们配置了JDBC UserDetailsService并硬编码Kerberos用户ID。通常，在配置Kerberos认证（尤其是使用Active Directory），用户的细节信息是通过LDAP从AD中得到的。我们将了解使用Kerberos认证时，与Microsoft AD比较的常见的LDAP UserDetailsService配置。我们将会略过对Spring Security与LDAP集成的描述，建议你跳回到第九章：LDAP目录服务中，在那里我们详细介绍过LDAP并包括关于通过LDAP集成AD的特别建议。

         我们可以配置认证提供者（authentication provider）引用LDAP UserDetailsService，而后者定义在dogstore-security.xml文件中，如下：

 

<ldap-server url="ldaps://corp.jbcppets.com/DC=corp,DC=jbcppets,DC=com" id="ldapCorp" manager-dn="CN=Administrator,CN=Users,DC=corp,DC=jbcppets,DC=com" manager-password="apassword!"/>
<ldap-user-service id="ldapUserService" server-ref="ldapCorp"
 user-search-filter="(userPrincipalName={0})" user-search-base="CN=Users"
group-search-base="CN=Groups"/>

          这里的关键是user-search-filter，它被userPrincipalName LDAP属性所搜索——这与SPNEGO认证过程中提供的Kerberos安全实体名字相匹配。注意，你要提供一个manager-dn，它只是有访问AD的权限而实际上并不是域的管理员。

         接下来，简单调整KerberosServiceAuthenticationProvider引用UserDetailsService，在dogstore-base.xml文件中，如下：

 

<bean id="kerberosServiceAuthenticationProvider"
 class="org.springframework.security.extensions.kerberos.KerberosServiceAuthenticationProvider">
  <property name="ticketValidator" ref="ticketValidator"/>
  <property name="userDetailsService" ref="ldapUserService" />
</bean>

 配置技术中唯一要说明的是给认证过的用户匹配权限。回忆一下第九章中，Spring Security LDAP期望用户权限能以一种特殊的方式在LDAP中查询出来——如果你AD的设置与LDAP内置的匹配不相容，你可能需要写自己的LdapAuthoritiesPopulator实现。如果你需要这方面的指导，请查询这个接口的实现类作为指导和起点。

         还要注意，Active Directory本身可能很复杂并很难在任何情况下直接匹配。你可能需要与试图集成Active Directory的IT人员进行交流，以确定业务需求和合适的应用模型以满足你的用户和业务需要。

 

使用Kerberos与form登录

         尽管使用SPNEGO为浏览器提供SSO是集成Kerberos和Spring Security的常见驱动力，但是你可能希望只是将Kerberos登录本身作为一个AuthenticationProvider机制（类似于LDAP的绑定认证方式——参考第九章以了解细节）。

         以这种方式配置Kerberos的好处是我们可以同时支持Kerberos认证用户和使用其它的AuthenticationProviders（LDAP，JDBC等等）来进行用户认证。

【如果你想尝试这个练习，确保移除在本章第一节中的配置——最重要的是，SpnegoEntryPoint必须移除以使得用户可以被重定向到登录form，否则没有SPNEGO的用户将会被拒绝访问。】

         现在，让我们了解一下配置步骤。在dogstore-base.xml中，要配置的Spring Bean实际上与SPNEGO风格登录的bean没有任何的重叠之处，所以你尽可以同时对其进行配置（尽管在实际中，你不会很容易地同时拥有SPNEGO和form登录，所以你可能不会这么做）。

         需要如下的bean：

 

<bean id="kerberosAuthenticationProvider"
 class="org.springframework.security.extensions.kerberos.KerberosAuthenticationProvider">
  <property name="kerberosClient" ref="kerbJaasClient"/>
  <property name="userDetailsService" ref="jdbcUserServiceCustom"/>
</bean>
<bean id="kerbJaasClient" 
class="org.springframework.security.extensions.kerberos.SunJaasKerberosClient">
  <property name="debug" value="true"/>
</bean>
<bean id="kerbGlobalJaasConfig" 
class="org.springframework.security.extensions.kerberos.GlobalSunJaasKerberosConfig">
  <property name="debug" value="true"/>
  <property name="krbConfLocation" value="/path/to/krb5.conf" />
</bean>

 在上面我们强调的配置是krbConfLocation属性，它指向了一个Kerberos V5文件。这个文件可以像前面章节提供的krb5.ini文件那样格式化（如果你想知道这个文件的内容，请查阅相关的Kerberos V5文档页面http://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.1/doc/krb5-admin/krb5.conf.html）。

         【请注意，不同于我们前面引用Kerberos keytab文件，这个参数的值必须是文件系统中的物理绝对路径名（如c:\spring\krb5.conf），并不是Spring风格的file:或classpath:引用。这是因为这个文件路径是直接传递给Sun JVM的Kerberos子系统，并不会被Spring bean来解释，如SunJaasKerberosTicketValidator所作那样。同样的，要注意的是这种风格的配置回修改JVM属性设置，所以可能会影响到部署在同一个JVM的其它启用Kerberos的应用。】

         配置文件中列出的default_realm用来认证通过用户界面登录的用户，他们没有提供域名。用户也可以在用户名带上域名（如[e-mail]），通常的Kerberos KDC方案规则都会基于Kerberos配置。

         因为这种风格的Kerberos配置是用来支持基于form的登录，我们只需配置像配置其它AuthenticationProvider那样配置KerberosAuthenticationProvider，这在security命名空间的配置文件dogstore-security.xml里，如下：

 

<authentication-manager alias="authenticationManager">
  <authentication-provider ref="kerberosAuthenticationProvider"/>
</authentication-manager>

 在这些配置修改完成后，你可以重启应用并使用form来登录使用Kerberos的后台应用。记住你也需要一个UserDetailsService实现来处理GrantedAuthority与用户的匹配。记住你可以将这种风格的认证用在其它的AuthenticationProvider后台认证技术上，包括basic认证。

小结

         在本章中，我们学习了怎样构建Kerberos环境，如Windows Domain提供的Microsoft Active Directory，来提供对Windows操作系统用户的集成单点登录。这为用户提供了统一且用户体验良好的（登录方式），并且减轻了系统管理员的负担。在本章中，我们：

l 学习Kerberos SPNEGO认证协议重要元素的整体状况；

l  学习了启用Kerberos的web应用所需要的设施和重要步骤；

l  配置JBCP Pets来支持Kerberos后台的SPNEGO单点登录认证；

l  了解启用Kerberos web应用的常见问题解决办法；

l 学习了使用AD作为LDAP后台存储用户信息所需要的配置；

l  学习了如何配置组合使用基于form的登录以及Kerberos后台系统。

         下一章也是最后一章将会涵盖从较早版本的Spring Security进行迁移。我们希望你能喜欢。