管理 SPNEGO TAI:关于使用 Kerberos 服务主体名称的提示

WebSphere® Application Server 简单和受保护的 GSSS-API 协商(Simple and Protected GSS-API Negotiation,SPNEGO)信任关联拦截器(Trust Association Interceptor,TAI)可以作为强大的工具使用,用于实现 Microsoft® Windows® 桌面和基于 WebSphere 的服务器之间的无缝单点登录环境。不过,有些用户在使用 SPNEGO TAI 时会遇到配置服务主体名称方面的问题。本文将介绍一些关于配置 Microsoft Active Directory 和 SPNEGO TAI 的最佳实践。

Martin Lansche, IT 咨询专家, IBM

作者照片Martin LanscheIBM WebSphere 软件服务部的一位咨询 IT 专家。他从事了 14 年的开发工作,涉及的领域包括虚拟机系统编程和 C/C++ 编译器工具。Martin 最近 8 年从事 ISSW 工作,起初从事 C++ 服务,最近重点研究自定义 WebSphere 安全解决方案,包括使用 Kerberos 和 SPNEGO 与 Active Directory 环境集成。他擅长的其他领域还包括 WebSphere 性能优化、故障排除和常规 WebSphere 系统管理。他拥有约克大学数字与计算机科学学士学位。


developerWorks 投稿作者

2009 年 7 月 14 日

引言

IBM WebSphere Application Server 简单和受保护的 GSSS-API 协商(Simple and Protected GSS-API Negotiation,SPNEGO)信任关联拦截器(Trust Association Interceptor,TAI)可以作为强大的工具使用,用于实现 Microsoft Windows 桌面和基于 WebSphere 的服务器之间的无缝单点登录(Single Sign-On (SSO)环境。WebSphere Application Server V6.1 信息中心介绍了如何在 WebSphere Application Server V6.1 中配置 SPNEGO TAI,但这方面存在一些主要问题,可能会对用户使用 SPNEGO 功能造成混淆。

本文将对最常见的问题予以讨论。请访问 WebSphere Application Server 信息中心,以获得完整的配置详细信息,并阅读本文来了解其中一些较为微妙的问题的更多信息。


什么是 SPNEGO?

当配置 Windows 桌面使用 Active Directory (AD) 域时,请使用其核心 Kerberos 中的安全基础结构。Kerberos 一直都提供受支持的分布式身份验证,而 TAI 正利用了此功能。Microsoft 对 Kerberos 进行了扩展,制定了称为简单和受保护的 GSSS-API 协商机制 (SPNEGO) 的协议,用于与 Web 服务器共享 Windows 凭据。此协议允许客户端计算机与 Web 服务器进行协商,确定将使用什么协议进行彼此通信。另外,其中还定义了客户端计算机将可验证身份验证数据发送到 Web 服务器的方法。如果 Web 服务器理解 SPNEGO 令牌,然后会将此令牌用于实现安全 SSO。因此,将通过 Web 服务器的安全方式协商用户的标识。现在访问 Microsoft 的 Internet Information Server (IIS) 时,用户通常遇到的情况就是这样的。请注意,SPNEGO 支持基于 Kerberos 或较旧(安全性也较差)的 NTLM 凭据的 Active Directory 凭据。IBM 的 TAI 解决方案仅支持基于 Kerberos 的凭据。Tivoli® Access Manager 支持 NTLM 和 Kerberos 凭据。

SPNEGO 是得到国际认可的标准


SPNEGO 如何用于 WebSphere 中?

根据 WebSphere Application Server(以下称为 Application Server)的版本不同,可以采用不同方式使用 SPNEGO 实现 SSO。在讨论这些不同的方法前,首先让我们介绍一些 WebSphere 安全概念。

WebSphere Web 身份验证

在大多数基本的情况下,WebSphere Application Server 的 HTTP 客户端(如 Web 浏览器)仅限于基于凭据或用户 ID 和密码提示的简单身份验证机制,通过表单登录或 BasicAuth 提示实现。通过 WebSphere Application Server 名为信任关联拦截器 (TAI) 的高级身份验证功能,WebSphere 可以信任在向 WebSphere 发送请求前执行了此身份验证的第三方。

实际上,当请求到达应用服务器时,如果相应的 TAI 可用,Application Server 安全运行时将要求提供 TAI 来标识用户。TAI 通常用于与身份验证代理集成,如 Tivoli Access Manager WebSEAL 等。此类身份验证代理服务器通常执行其身份验证,然后通过自己专用的机制和对应的 TAI 将用户的标识投影到 WebSphere。

WebSphere Application Server V6.1 中的一个新功能提供了身份验证模型,此模型基于使用 Kerberos 和 SPNEGO 协议的 Windows 桌面身份验证。虽然其他身份验证代理实现单点登录 (SSO) 的方式通常是通过要求用户登录到代理一次,然后将该标识投影到每个下游的 WebSphere 实例,不过,SPNEGO TAI 允许 WebSphere Application Server 与用户的 Windows 域登录集成,然后使用用户的 Windows 凭据以不可见的方式让用户通过 WebSphere 的身份验证。也就是说,用户使用自己的 Windows 域帐户和密码一次性登录到其 Windows 桌面。访问 WebSphere 时,会以静默方式向浏览器获取 Windows 凭据来自动让用户通过 WebSphere 的身份验证。

支持将 Windows 单点登录用于 WebSphere 的备选产品

拥有大量 IBM 提供的解决方案的客户可以实现 Windows 和 WebSphere 之间的这一集成:

  1. IBM 提供了 Tivoli Access Manager (TAM) V5.1 及更高版本的产品解决方案,其中包括了对使用 SPNEGO 的 Windows SSO 的显式支持。TAM 可用于 WebSphere 的 5.x 和 6.x 版。
  2. 使用 WebSphere Application Server Version 5.1.1.x 和 6.0.x 的客户可以获得 IBM WebSphere 软件服务部(IBM Software Services for WebSphere,ISSW)提供的自定义服务产品解决方案。此解决方案提供了源代码,客户可以自行维护此自定义代码。要获得关于用于 WebSphere Application Server V5.1.1 和 V6.0 的 ISSW SPNEGO TAI 服务产品的更多信息,请联系 IBM WebSphere 软件服务部
  3. WebSphere Application Server Version 6.1 提供了基于上面提到的 ISSW 版本的 TAI,是受到全面支持的产品。不过,客户不能获得此版本对应的源代码。

在本文中,我们将重点讨论第二个和第三个选项,因为二者的问题比较相似。

SPNEGO 如何用于 WebSphere 中?

此部分将重点介绍 SPNEGO TAI 身份验证流程的主要部分。

在此场景中,用户已经通过了 Windows 的身份验证(获得了 Active Directory 凭据),然后通过使用 Web 浏览器客户端(以下称为“客户端”)调用 Web 应用程序(部署在支持 SPNEGO 的 WebSphere 服务器上)。协议的相关步骤如下:

  1. 用户请求安全 Web 资源。
  2. 服务器使用 HTTP 提示响应(HTTP 401)进行响应,其中包含“Authenticate: Negotiate”头。
    1. 客户端识别 Negotiate 头,因为已经配置为支持“Integrated Windows Authentication”。
    2. 客户端解析所请求的 URL,以获得主机名。
  3. 客户端从 Kerberos 身份验证服务(Authentication Service,AS)请求票证授予票证(Ticket Granting Ticket,TGT)。
  4. 客户端接收 TGT。
  5. 客户端从 SPN 的 Kerberos 票证授予服务(Ticket Granting Service,TGS)请求服务票证,例如 HTTP/serverrc4.ibm.net_cnnew1@ IBM.NET。客户端解析所请求的 URL 获得协议和主机名,并使用客户端自己的域名作为 Kerberos 安全领域,从而构造 SPN: <protocol>/<host's FQDN>@<Client's Kerberos Security Realm>注意:必须在配置环境时向 Kerberos 密钥分发中心(Key Distribution Center,KDC)注册 SPN。
  6. 客户端收到服务票证。
  7. 客户端重新向安全资源发送原始请求。这次,用户名将包含在加密的 Kerberos 服务票证中,封装为通过 HTTP Authorization 头传递的 SPNEGO 令牌。
  8. 应用服务器收到具有 SPNEGO 令牌的 HTTP Authorization 头。它提取并解密(这将验证其是否来自 TGS)SPNEGO 令牌,以检索用户名,并将此用户名断言到服务器。您可能需要将用户名映射到服务器的注册中心中有意义的主体。
  9. 服务器的安全系统将针对安全注册中心对用户进行验证并获得关于用户的安全信息。用户登录到服务器。
  10. 服务器将此用户安全信息缓存到称为 Java™ Subject 的内存内对象,以避免出现进一步的身份验证提示。
  11. 服务器将内容发回到用户,并提供 LTPA 令牌作为 Cookie。此 Cookie 允许在不需要出现重新身份验证的前提下发送对相同 WebSphere SSO 域的后续请求。
    1. 如果用户被授权访问资源,所得到的响应是 HTTP 200 响应,将提供所请求的资源。
    2. 如果不授权,将向客户端发送“HTTP 403 Not Authorized”。

图 1 描述了在上面描述的场景期间出现的步骤。

图 1. SPNEGO 概述
SPNEGO 概述

请注意,此场景不会提示用户进行身份验证。客户端会将用户的现有 AD 凭据“流动”到服务器。用户将通过其 Windows 凭据访问服务器。永远不会提示用户登录到目录 WebSphere 服务器。

SPNEGO 是否必须使用 Windows?

本文剩下的部分在术语使用方面会刻意较为模糊。严格来说,并不需要使用 Windows。为了准确起见:

  • WebSphere Application Server 并不需要 Windows 服务器。事实上,当 Application Server 在 Windows 上运行时,有一些已知的危险区域需要加以避免(我们将在后面对此进行讨论)。我们已经在大多数可用的受支持 WebSphere 平台上的真实客户环境中部署了 SPNEGO TAI 解决方案。
  • 桌面并不需要为 Windows 桌面。支持 Kerberos 登录且其 Web 客户端包含对 SPNEGO 协议支持的任何桌面都可以。这包括 Linux 和 Apple® 桌面。我们已经为此类环境配置过 SPNEGO TAI 解决方案。
  • 信息中心指出,Kerberos 密钥分发中心 (KDC) 和票证授予服务器(Ticket Granting Server,TGS)需要为 Windows 2000 或 Windows 2003 服务器。
  • 并不需要将 WebSphere 注册中心配置为使用轻量级目录访问协议(Lightweight Directory Access Protocol,LDAP)的 Microsoft Active Directory。通常,从服务器票证获得的用户 ID称为 Kerberos UserPrincipalName。具体来说,Microsoft 将其称为 ClientPrincipalName。此用户 ID 必须映射到 WebSphere 安全注册中心中有意义的名称。最简单的映射是其中 WebSphere 注册中心为 Active Directory 提供的 LDAP 。我们在将 SPNEGO TAI 与各种重要和不重要的映射部署方面有丰富的经验,包括 WebSphere 注册中心为以下内容的情况:
    • 由一个或多个基础 LDAP 注册中心组成的 WebSphere 联合注册中心
    • 单个 Active Directory 域 LDAP
    • 配置为 Active Directory Forest 的 Active Directory LDAP 服务器集
    • IBM Tivoli Directory Server LDAP
    • Domino LDAP
    • z/OS® RACF 注册中心
    • 自定义用户注册中心(各种类型)

这些映射解决方案需要创建特定客户的自定义代码,通常采用 LoginModule 的形式将 TAI 构建的 Java Subject(其中包含 Windows 标识)模拟为包含 WebSphere 中有效的映射目标用户 ID 的新 Java Subject。这些 LoginModules 结构不在本文讨论范围之列,需要由专家创建。

阅读本文剩下的部分时,请将文中的“Windows”的使用视为典型用法,但也不是一定要这样处理。


什么是 Kerberos 主体名称,与 WebSphere 存在什么关系?

我们已经从较为抽象的角度描述了什么 SPNEGO 协议以及 SPNEGO TAI 的工作原理。接下来我们讨论一些新接触的基于 Kerberos 的安全系统的经常混淆的问题。其中很多问题都与 Kerberos 主体名称主题相关。那么什么是主体名称呢?

Kerberos 使用主体名称来标识 Kerberos 中的“主体”。主体可以代表最终用户、系统甚至临时标识。

用户主体名称

登录到传统的 Kerberos 系统中时,通常通过使用您的 UserPrincipalName 完成。用户的 UserPrincipalName 通常采用“userid@REALM”的形式,例如“lansche@IBM.NET”。登录到 Windows 域中时,将使用 Windows 用户登录名称(Windows 2000 前),也称为 sAMAccountName。

请看图 2 中所示的 Windows 中的帐户。红色圈内的字段是 sAMAccountName。

图 2. 典型 Windows Active Directory 用户的属性表
典型 Windows Active Directory 用户的属性表

Microsoft 还将用户的 UserPrincipalName 存储在 Active Directory 中。其形式为“用户登录名称”加上领域名(采用上面的“@ibm.net”形式)。SPNEGO 协商返回 Microsoft 称为 ClientPrincipalName 的名称。即 the sAMAccountName 加 Kerberos 领域。缺省情况下,对于 Active Directory 中的用户,ClientPrincipalName 和 UserPrincipalName 是相同的。不过,并非总是这样。请看图 3 中所示的第二个帐户。

图 3. 不常见但有效的用户 ID 的属性表
不常见但有效的用户 ID 的属性表

图 4 显示了 UserPrincipalName(一个可搜索 LDAP 属性)为 botzum@ibm.net 的帐户。

图 4. 这个不常见用户的 UserPrincipalName 的 LDAP 浏览器视图
这个不常见用户的 UserPrincipalName 的 LDAP 浏览器视图

不过,sAMAccountName 是“键”,如图 5 中所示。

图 5. 这个不常见用户的 sAMAccountName 的 LDAP 浏览器视图
这个不常见用户的 sAMAccountName 的 LDAP 浏览器视图

因此,此用户的 ClientPrincipalName(不是可搜索 LDAP 属性)为“keys@IBM.NET”。

缺省情况下,“用户登录名称”和“:sAMAccountName”最初设置为相同的值,但完全可以对其进行更改。有些企业强制执行更改 sAMAccountName 的策略。这可能会对 SPNEGO TAI 造成极大的破坏,因为此机制关注的是 sAMAccountName,而且这可以采用某种方式映射回注册中心中的可搜索名称。如果 sAMAccountName 是唯一的,则可以对其进行搜索。不幸的是,sAMAccountNames 仅在单个域中保证是唯一的。如果有 Active Directory Forest,则可能同一个 Forest 中的多个域内存在重复 sAMAccountName。

总的说来,在计划 SPNEGO TAI 部署时,必须考虑将用户的主体名称映射到 WebSphere 注册中心中的有意义的名称。当所有用户都位于单个 Active Directory 域中时,WebSphere 注册中心配置为用于同一个 Active Directory LDAP,不需要映射。当用户分布在 Forest 中的多个 Active Directory 域时,WebSphere 注册中心配置为通过 LDAP 用于整个 Forest,当“用户登录名称”和“sAMAccountName”不相同时,映射就可能成为问题。如果映射指向其他注册中心,则映射必须依赖于包含在自定义 JAAS 登录模块中的创造性解决方案。此类映射不在本文讨论范围之列。

服务主体名称

Kerberos 原则也可以代表系统或服务。服务的主体名称(ServicePrincipalName 或 SPN)的形式为 SERVICE/name@REALM。字符串“SERVICE”的实际值根据约定确定。对于我们的情况,请注意 Active Directory 和 SPNEGO 使用的两个重要约定:

  • Web 服务器 SPN 带有字符串“HTTP/”作为前缀。这并不考虑所使用的协议是 HTTP 还是 HTTPS。http://someserver.ibm.net 处的 Web 服务的示例 SPN 为 HTTP/someserver.ibm.net@IBM.NET。在 Active Directory 中,所有“HTTP/”SPN 都添加到 Windows 服务帐户上。Active Directory 中的服务帐户所承担的唯一角色是用于支持某个应用程序或服务。对于 SPNEGO TAI,我们创建服务帐户的唯一目的是为了“拥有”SPN。请注意,一个服务帐户可以定义多个 SPN。它可能会“拥有”多个“HTTP/”SPN。
  • 类型为“Computer”的 Active Directory 对象也是 Kerberos 服务,并具有 SPN。其 SPN 的前缀为“HOST/”。我们的测试 AD 领域 IBM.NET 中的一个“Computer”对象名为 wasserv01,该对象将具有两个定义的 SPN:
    • HOST/wasserv01@IBM.NET
    • HOST/wasserv01.ibm.net@IBM.NET

部署 SPNEGO TAI 时遇到的一个常见问题是具有在 Active Directory 中冲突的 SPN 名称。

建议:始终通过虚拟主机名访问 SPNEGO

问题:如果不从浏览器通过 http://someserver.ibm.net 访问应用程序(我们已将其更改为 http://wasserv01.ibm.net),要求提供此请求的服务票证时 AD 将使用哪个 SPN?

:HOST/wasserv01.ibm.net@IBM.NET。这会给 SPNEGO TAI 带来问题。

在纯 Kerberos 系统中,密钥验证通过以下方式之一完成:

  • 联系 TGS/KDC。
  • 使用包含保密信息的密钥表文件(与 TGS/KDC 共享)。

SPNEGO TAI 仅仅使用包含共享保密信息的密钥表文件来执行此验证。这个共享保密信息是 KDC 中的用户帐户的密码。由于没有办法为 Active Directory 中的“Computer”对象定义密码,必须在自定义服务帐户上设置密码,然后在此帐户上定义 SPN。对于一个 SPN,如果 Active Directory 中存在多个可能的匹配对象,AD 构建服务票证时会选择“HOST/”SPN,而不是“HTTP/”SPN。这显然会给 SPNEGO TAI 带来问题,因为它将尝试使用基于服务帐户的密码的保密信息(嵌入在密钥表文件中)来解密服务票证。

如果 WebSphere Application Server 在 Windows 计算机对象上运行,则不能在 HTTP 请求中使用计算机的主机名,因为服务票证将针对 HOST/,而不是 HTTP/ SPN。这意味着需要为要使用的服务器 SPN 指定第二个主机名。有意思的是,这只有在小型系统、沙箱系统、概念验证(Proof-Of-Concept,POC)系统或开发环境中才是问题。

在最为典型的“真实”WebSphere 环境中,我们已经解决了这个问题,因为在解决方案中部署了额外的网络组件。我们通常用在至少两台计算机上运行的应用服务器集群。对于用户,可以视为有一个始终可用且可扩展的大型服务器(例如,名为“someserver.ibm.net”)。事实上,在应用服务器上处理用户请求前,请求将通过一系列计算机。这是通过虚拟主机名来实现的。图 6 显示了迷你型的“真实”WebSphere 环境。

图 6. 迷你型的“真实”WebSphere 环境
迷你型的“真实”WebSphere 环境

在此环境中,用户无法通过 http://wasserv01.ibm.net 访问应用程序。此主机名在这个真实示例中并不相关。事实上,上面的防火墙将可能会阻止进行此访问。类似地,也不会知道或访问各个 Web 服务器的名称。

在简单的单 Windows 环境中,用户通常知道真实的计算机名称,而这正是名称冲突的原因。为了避免这个名称冲突问题,请将这个简单的环境视为上面的复杂环境的简化示例。移除了防火墙、Sprayer 和冗余服务器甚至将 Web 服务器及应用服务器层压缩后,我们就可以得到图 7 中所示的下列场景。

图 7. 简单的沙箱或开发者环境
简单的沙箱或开发者环境

为了避免名称冲突问题,用户必须使用计算机的实际 Windows 主机名访问服务器(而不是通过虚拟主机名)。如果有 POC 或开发服务器,那么一个简单的解决办法就是,手动编码 etc/hosts 文件以绕过主机名的 DNS 解析。服务器是生产服务器,必须为服务器的 IP 地址添加第二个 DNS 主机记录。请参见下面的讨论,以了解为何不使用 DNS 别名来解决此问题。

在结束这个主题的讨论前,我们考虑一个略大的环境,其中 Application Server 前面配备了一台基于 Windows 的 Web 服务器。在这种情况下,用户不应该使用 Web 服务器的实际主机名。相反,请使用虚拟主机名来避免与 Web 服务器计算机在 Active Directory 中的“Computer”对象的名称冲突。图 8 显示了典型的双计算机设置。

图 8. 典型的双计算机 WebSphere 环境
典型的双计算机 WebSphere 环境

要使用多少个 SPN?

前面说明了由于使用 AD 中的计算机对象的主机名而导致的 SPN 名称冲突的问题。通常,最佳的做法是为每个服务使用单个 SPN。这是用户的浏览器地址字段中输入的 Web 应用程序的虚拟主机名。无论环境的复杂性如何,这都成立。


何时建议使用多个 SPN?

只有总体 WebSphere 计算单元支持多个应用程序,且应用程序承载于不同的虚拟主机名上时,才建议在配置中使用多个 SPN。这方面的讨论较为复杂,大多数部署都不会涉及到这方面。

请注意,我们明确反对设置多个 SPN,以便应用程序的 SSO 访问将正常工作,而不会受到访问路径的影响。请看图 9 中所示的反模式。

图 9. WebSphere 的 SPN 错误设置方式
WebSphere 的 SPN 错误设置方式

这里的想法是,要运行通过所有可能的主机名进行 SPNEGO SSO 访问:

  • http://someserver.ibm.net
  • http://webserv01.ibm.net
  • http://webserv02ibm.net
  • http://wasserv01.ibm.net
  • http://wasserv02.ibm.net

此类配置怎么会出现?我们通常发现,在以下情况下会出现这种配置:系统以单个服务器(例如,wasserv1.ibm.net)为基础构建,而 SPNEGO 配置于此服务器上。开发人员习惯了该主机名,但随着一步步的发展,服务器已经集群化了。添加了第二台服务器 wasserv2.ibm.net。为了确认 SPNEGO 没有被破坏,向密钥表文件添加了第二个 SPN。用户可以通过两个 WebSphere 实例之一访问应用程序。

开发人员认识到直接在 Web 容器的 WebSphere 实例上访问应用程序并不能真实地反映生产环境中的情况,因此引入了一个 Web 服务器。为了确认该 SPNEGO 在其中正常工作,为 webserv1.ibm.net 添加了第三个 SPN。最后,在投入生产使用前,他们添加了第二个 Web 服务器,并为服务添加了第四个 SPN。在即将进入生产使用前,他们需要能访问 IP Sprayer。由于 IP Sprayer 使用另一个主机名,因此添加了第五个 SPN,即 someserver.ibm.net。

虽然可以采用这种方式配置 SPNEGO TAI,我们强烈建议不要这样做。当这些服务器都是 AD Forest 中的 Windows 服务器时,将会遇到上面所述的所有名称冲突问题。此外,此类访问违反了生产系统的所有常规习惯做法,因为用户不应该直接访问内部服务器。

如果需要此类测试访问,请编辑测试桌面上的 etc/hosts 文件。输入目标访问点的 IP 地址(这里使用 someserver.ibm.net),然后测试 SPNEGO SSO。例如:

127.0.0.1       localhost 
# SPNEGO TAI Lab - uncomment the access point you want
9.26.20.145	someserver.ibm.net #Really wasserv01.ibm.net
#9.26.20.146	someserver.ibm.net #Really wasserv02.ibm.net
#9.26.20.147	someserver.ibm.net #Really webserv01.ibm.net
#9.26.20.148	someserver.ibm.net #Really webserv02.ibm.net

SPN 在 Active Directory 中的位置?

在结束 SPN 主题之前,让我们讨论一下应该将 SPN 放入 Active Directory 的什么位置。在前面,我们描述了密钥表文件中包含与 AD 密钥分发中心 (KDC) 共享的保密信息(AD 中用户 ID 的密码)。ktpass 工具供 AD 域管理员用于以下用途:

  • 在帐户上设置 SPN
  • 在密钥表文件中生成用于其他 Kerberos 系统的密钥。

不过,要使用哪个用户 ID 呢?

我们遇到过一些客户,他们错误地将 AD 中尽可能少的用户 ID 用于 WebSphere。对于 WebSphere 6.1,要通过独立 LDAP 注册中心或作为联合注册中心的一部分使用 AD 作为 LDAP,您需要定义以下信息:

  • LDAP 绑定帐户和密码:此帐户是 WebSphere 运行时进行 LDAP 搜索和查询时使用的帐户。例如,其中经常存在“wasbind”帐户。
  • 服务器用户标识:如果是 V6.1,则此标识为可选标识。如果是 V6.0 和更高版本,则不是可选的。各种 WebSphere 流程都使用其进行彼此的身份验证。需要提供用户 ID 和密码。此帐户通常为“wasserver”。
  • 主要管理用户 ID:此为超级管理员帐户,仅用于在注册中心中授予“真实用户”所需的必要管理权限。这通常为“wasadmin”帐户。

前两个帐户在注册表中视为“服务帐户”。这些帐户并不需要任何特殊操作系统(Operating System,OS)权限。这些帐户的密码更改受到控制,不会自动允许进行更改。如果在注册中心中进行了更改,但没有在 WebSphere 配置中更改,WebSphere 将不会工作。可以在不更改 WebSphere 中的任何配置的情况下更改主要管理帐户。

问题:应该将 SPN 置于以上哪个帐户?

:以上都不是。作为最佳实践,我们建议创建第三个服务帐户(例如取名为“wasspnegospn”),在其中定义 ServicePrincipalName。

注意:不要使用上面的任意三个帐户,否则将会遇到操作问题。具体来说,当此服务帐户的密码更改时,必须重新生成密钥表文件,并通过 WebSphere 计算单元重新分发。这就要求 WebSphere 停机。

如果必须在 SPNEGO 中使用多个 SPN(有关建议采用这种方式的唯一情况,请参见何时建议使用多个 SPN?),我们建议将 SPN 归入到单个帐户中,将此帐户用于标识 WebSphere 配置中的公用应用程序集群可能使用的所有 SPN。请看表 1 所示的此示例计算单元内容。此计算单元中承载归三个不同的业务部门所有的四个应用程序。

表 1. 包含多应用程序、虚拟主机和 SPN 的实际计算单元
集群应用程序虚拟主机SPN
Apps Cluster App1 和 App2 app1.ibm.net 和 app2.ibm.net HTTP/app1.ibm.net@IBM.NET 和
HTTP/app2.ibm.net@IBM.NET
Portal Portal portal.ibm.net HTTP/portal.ibm.net@IBM.NET
HRHRhr-sys.ibm.netHTTP/hr-sys.ibm.net@IBM.NET

显然,我们需要四个 SPN,因为对用户而言,有四个不同的虚拟主机。Portal 和 HR 应用程序在自己的 WebSphere 集群上运行。最好的安排方式是,为各自安排一个独立的服务帐户(包含单个 SPN),如表 2 中所示。

表 2. 将 SPN 映射到服务帐户
应用程序SPN服务帐户
Portal HTTP/portal.ibm.net@IBM.NETSvc_PortalSPN
HRHTTP/hr-sys.ibm.net@IBM.NETSvc_HRSPN

“Apps cluster”需要进行仔细的分析。如果两个应用程序紧密耦合(部署在一起,必须同时运行,生命周期相互有关联,属于共同的业务部门所有),则多个 SPN 可以“属于”单个服务帐户。此服务帐户上的密码更改以及此服务帐户的退役都将对这两个应用程序造成影响。

另一方面,如果 App1 和 App2 松散耦合(各自具有不同的服务质量要求、不同的生命周期或属于独立的业务部门),则应该具有自己唯一的服务帐户(具有唯一的 SPN)。服务帐户的密码更改或一个应用程序的退役(以及由此引起的服务帐户退役)将不会对另一个应用程序造成影响(表 3)。

表 3. 耦合应用程序的 SPN 和服务帐户间可能的映射
SPN服务帐户
如果 App1 和 App2 紧密耦合:
HTTP/app1.ibm.net@IBM.NET
HTTP/app2.ibm.net@IBM.NET
Svc_AppsSPN
或者,如果 App1 和 App2 松散耦合:
HTTP/app1.ibm.net@IBM.NETSvc_App1SPN
HTTP/app2.ibm.net@IBM.NETSvc_App2SPN

在 AD Forest 中,在何处定义 SPN 帐户?

如果实际 Active Directory Forest 包含复杂的域层次结构,该如何处理?在 Forest 中何处定义 SPN 服务帐户?

Active Directory Forest 定义了 AD 域的层次结构。在这些域之间,存在这种信任关系。关于在 AD Forest 中特定的地方定义 SPN 并没有特定的要求。在何处定义 SPN 的决策标准可能更多的是管理标准,而不是技术标准。在较低级别的 AD 域中进行更改可能比在较高级别域或 AD Forest 的根中进行相同的更改更为简单。必须将此与在 Forest 中请求服务票证的网络成本加以权衡。请考虑图 10 中所示的以下示例。

图 10. 企业 AD Forest 示例
企业 AD Forest 示例

AD Forest 的根为 ibm.net(Kerberos 域为 IBMNET),其子域为 na.ibm.net 和 eu.ibm.net。其 Kerberos 领域分别为 NA 和 EU。这些域进一步划分为:

  • us.na.ibm.net (US)
  • ca.na.ibm.net (CA)
  • uk.eu.ibm.net (UK)
  • fr.eu.ibm.net (FR)
  • de.eu.ibm.net (DE)

让我们假定 http://someserver.ibm.net 承载于 na.ibm.net 域所运行的计算机上。让我们进一步假设,全部用户中 75% 的用户位于 us.na.ibm.net 域中。

由于站点的 DNS 名称是在公司或 Forest 级别持有的,因此完全可以将 SPN 定义为“HTTP/someserver.ibm.net@IBMNET”。在 Forest 级别的顶部创建用户 ID 可能会需要全局移动批准(管理)。务必认识到,服务票证的搜索将按照 Forest 层次结构进行。如果 SPN 在 Forest 的顶部 IBMNET 中定义,则 US 域中的用户将首先要求其 TGS 来获得服务的票证。这会导致 usdc.us.na.ibm.net 从 nadc.na.ibm.net 发送对用户的 TGT 的请求,并从 rootdc.ibm.net 返回用户的 TGT。客户端对 IBMNET 承载的服务的服务票证的请求必须遍历 Forest 的两个级别才能完成。在此示例中,服务票证的大部分请求都必须进行两次这样的重定向。在此示例中,只有少量客户端位于根级和第二级域中。大部分都位于第三级域中。这可能会在 WAN 上导致过多的 AD 通信流量(操作)。

从管理角度而言,将 SPN 放在 na.ibm.net 域,作为“HTTP/someserver.ibm.net@NA”,这种做法更为简单。通过在 EU 和 NA 之间添加显式的域间信任,从欧洲请求服务票证的操作仅需要两次跳转。此外,Active Directory 管理员可以定义国家/地区域和 NA 域之间的域间信任,从而让所有“外国”域请求仅需要单个跳转。

由于大部分服务票证请求都将来自 US 领域,如“HTTP/someserver.ibm.net@US”。


不要在 Web 服务器上包含 URL

请注意,如果 Web 服务器用于前端 WebSphere Application Server,则必须为“Integrated Windows Authentication”透明。Web 服务器作为(可能为)SSL 终止器,并作为运行 WebSphere 插件进行 Web 工作负载管理的位置。不过,Web 服务器不应通过用户请求的身份验证。如果启用了 SSL 客户端身份验证,为何还要考虑将 SPNEGO 作为身份验证机制使用?

对于 IBM HTTP Server 以及“替代”Apache Web 服务器而言,这通常不是问题。这些 Web 服务器的缺省配置中通常不支持执行请求的身份验证。

不过,Microsoft 的 IIS 服务器缺省情况下在其缺省网站的文件夹上启用了安全性。IIS 内缺省启用了集成 Windows 身份验证(Integration Windows Authentication,IWA)。

在此场景中,原始请求将发送到 WebSphere SPNEGO TAI。将向客户端返回“HTTP 401 Authenticate/Negotiate”响应。客户端重新提交请求,并提供包含 SPNEGO 头的 Authorization 头。IIS 服务器会看到此 Authorization 头并尝试对其进行处理。由于此头与虚拟主机名(而不是 IIS 服务器)对应,因此会拒绝请求并向客户端发回“401”。这会导致出现 BasicAuth 头。这不是所需的单点登录用户体验。

如果 Web 服务器处理 IWA,则 SPNEGO TAI 将无法工作,因为 Web 服务器将尝试处理 SPNEGO 令牌,已失败,并返回 BasicAuth 提示。此 BasicAuth 头对 TAI 是不可接受的。


避免用户 DNS 别名

在前面的 SPN 在 Active Directory 中的位置中,我们告诉您为 WebSphere 服务器定义虚拟主机名,特别是 WebSphere 服务器为 Active Directory 内的 Windows“Computer”对象时更要这样做。可以采用两种方式设置此虚拟主机名:

  1. 在 DNS 中,添加别名或 (CNAME) 记录,用于提供第二个主机名,如图 11 中所示。
    图 11. someserver DNS 记录错误地设置为 DNS 别名
    someserver DNS 记录错误地设置为 DNS 别名
  2. 在 DNS 中,添加第二个主机记录,映射到与原始主机名相同的 IP 地址,如图 12 中所示。
    图 12. someserver DNS 记录正确地设置为第二个 DNS 主机记录
    someserver DNS 记录正确地设置为第二个 DNS 主机记录

我们建议避免为 SPNEGO TAI 使用的主机名使用 DNS 别名。当浏览器从 SPNEGO TAI 收到“401 Authenticate/Negotiate”响应时,会要求提供服务票证。其要求提供的主机名是原始别名主机名。当“someserver.ibm.net”为别名时,上面产生的服务票证用于“HTTP/wasserv01.ibm.net@IBM.NET”。根据我们上面讨论,如果 wasserv01 是 Active Directory 中的 Windows 计算机对象,则使用别名可能会产生“HOST/wasserv01.ibm.net@IBM.NET”服务票证。

在一种情况下,可以让别名与 WebSphere V6.1 SPNEGO TAI 一起工作。ISSW SPNEGO TAI 并不支持此功能。这种情况下需要定义复杂 Kerberos/SPNEGO 配置。我们 建议采用此配置。为了让这个不推荐的配置工作,必须进行以下工作:

  1. 必须使用 WebSphere 6.1 SPNEGO TAI,而不是 ISSW SPNEGO TAI。
  2. 必须应用 APAR PK50383(在 WebSphere Application Server V6.1 Fix Pack 15 中)。
  3. 在 Application Server 的 JVM 的 Custom Properties 上,定义属性 com.ibm.websphere.security.krb.canonical_host=true
  4. 在 Active Directory 中的 SPN 帐户,必须定义两个 SPN:
    1. HTTP/someserver.ibm.net@IBM.NET
    2. HTTP/wasserv01.ibm.net@IBM.NET
  5. 创建包含这些 SPN 的密钥的单个密钥表。
  6. 在 SPNEGO TAI 配置中,创建两个完全相同的属性集,其中仅主机名属性不同:
    1. com.ibm.ws.security.spnego.SPN1.hostName=someserver.ibm.net
    2. com.ibm.ws.security.spnego.SPN2 hostName=wasserv01.ibm.net

与 SPN2 关联的其余属性与 SPN 的对应属性匹配。

运行时,HTTP 请求中的“hostname”将与第一个 SPN 配置匹配(hostName=someserver.ibm.net),以决定是否拦截请求。当服务票证达到时,此拦截决策将基于 HTTP/wasserv01.ibm.net SPN。接下来,处理请求,会将所收到的服务票证与第二组配置属性进行匹配,以执行 SPNEGO SSO。

我们 建议采用此方法。请仅在极少数情况下使用此方法,即:

  • 必须使用 DNS 别名。
  • 别名映射到的主机名不是 Active Directory 中的 Windows 计算机对象。我们强烈支持添加第二个 DNS 主机记录。

结束语

本文讨论了使用 WebSphere Application Server SPNEGO TAI 时定义服务主体名称的各种最佳实践。我们的这些最佳实践源自大量的 ISSW SPNEGO TAI 和 WebSphere Application Server V6.1 SPNEGO TAI 客户部署。

参考资料

学习

获得产品和技术

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=412728
ArticleTitle=管理 SPNEGO TAI:关于使用 Kerberos 服务主体名称的提示
publish-date=07142009