配置受 Kerberos 保护的 WebSphere DataPower 后端服务器,第 1 部分: 使用 DataPower Web 图形用户界面

这个两部分文章系列的第 1 部分揭示了使用受 Kerberos 保护的后端服务器设置 WebSphere® DataPower 配置所需的工作。第 1 部分介绍如何使用 DataPower Web 图形用户界面以一种静态方式创建这些配置。第 2 部分将介绍如何使用 DataPower 自定义样式表对象,以一种更加动态的方式为一个 Kerberos 后端服务器配置一个网关。

Michael McMahon, 顾问软件工程师, IBM

Michael McMahon 的照片Michael McMahon 是 IBM 的一位顾问软件工程师,在北卡罗来纳州 Research Triangle Park 工作。他参与过各种开发团队和项目,目前在 IBM DataPower 和 IBM PureApplication System 支持组织工作。



Bill Barrus, 高级解决方案架构师, IBM

Bill Barrus 是位于北卡罗来纳州达勒姆市的 IBM WebSphere DataPower Level 2 Support 团队的高级软件工程师和经过认证的 IT 专家,他的专长是安全性和 B2B。他刚加入 IBM 时为美国 Navy F-14 航空电子更新项目研究机械设计,后来从事计算机辅助机械工程,再后来致力于研究与 CATIA Engineering Analysis、Lotus Workplace Client Technology Micro Edition 和 WebSphere Voice Server 相关的新兴商业技术。



Lisa Rich, 顾问软件工程师, IBM

Lisa Rich 的照片Lisa Rich 是 IBM Software Group 的一位顾问软件工程师。他担任 WebSphere DataPower SOA Appliances 的技术支持领导,专攻 DataPower Security。在研究 DataPower 之前,她是 WebSphere Application Server、WebSphere Studio Enterprise Developer and EGL 及 CICSPlex System Manager 的 IBM SWG L2 和 L3 支持专家。Lisa 也是 IBM PureApplication System 和 IBM Workload Deployer 技术支持团队的成员。



2012 年 11 月 12 日

简介

作为 DataPower 支持小组的成员,我们接触的客户常常需要将其客户端应用程序连接到受 Kerberos 身份验证保护的后端服务器。不可避免地,这些客户中很大一部分都有关于如何配置网关或代理来支持此类型的客户端和服务器解决方案的疑问。Kerberos 技术在第一次设置时可能难以理解且复杂,这就可能解释了为什么与此主题相关的问题频率这么高。


Kerberos 解决方案

许多文章都出色地概述了 Kerberos,介绍了 Kerberos 安全模型中的各种组件和发生的各种交互(请参阅本文的 参考资料 一节)。我们假设读者已对 Kerberos 安全性知识有了基本的了解。我们将重点介绍 DataPower 配置直接需要的 Kerberos 相关活动。我们希望这些文章的推出,有助于在尝试确定如何在 DataPower 中设计和实现 Kerberos 相关解决方案时避免延误和混淆。

解决方案场景

我们将在第一篇文章中使用的场景包含一位客户,它有一组需要连接到客户后端服务器上的一个 Web 应用程序的客户端。这个 Web 应用程序通过 Kerberos 身份验证进行保护。但是,传入的客户端未通过 Kerberos 进行保护或进行身份验证。在我们的示例中,将假设客户端通过基本的身份验证和一个轻量级目录访问协议 (LDAP) 服务器进行身份验证,但它可能是多种身份验证形式中的一种(注意:可能会介绍一些 LDAP 相关的信息,因为 LDAP 通常会与 Kerberos 结合使用)。尽管我们通常在使用基本身份验证时使用 SSL,但为简单起见,我们不会在本示例中设置它。

为了允许这些非 Kerberos 客户端与我们受 Kerberos 保护的 Web 应用程序通信和访问它,您将在 DataPower 中设置一个多协议网关。此网关定义为接受传入的客户端请求作为 HTTP GET 请求、身份验证,并根据客户端传入的凭证对客户端进行授权,然后将客户端的请求提交到后端服务器,通过使用一个 Kerberos 令牌对后端服务器进行身份验证来完成此操作。从后端服务器返回的响应然后将从 DataPower 传回到请求客户端。参见图 1。

图 1. 解决方案场景概述图
解决方案场景概述图

Kerberos 交互

在这个示例场景中,我们使用 WebSphere Application Server(以下称为 Application Server)作为后端服务器来托管我们的 Web 应用程序。该 Web 应用程序将是随 Application Server 提供的样例 “snoop” 应用程序。这个 Application Server 配置为支持 Kerberos 身份验证,所以,如果没有正确的 Kerberos 服务票证,将无法访问 Web 应用程序。作为 Kerberos 身份验证的一部分,Application Server 能够访问一个包含服务主体名称 (SPN) 和相应的私钥的 Kerberos keytab 文件。拥有对此 keytab 文件的访问权限,Application Server 能够处理已由密钥分发中心 (KDC) 验证、并已收到一个 Kerberos 服务票证以允许它们与 Web 应用程序交谈的传入客户端请求。

为了消除任何混淆,DataPower 与后端服务器之间的这一交互的一个重要方面是,对 Application Server 的所有客户端请求将由 DataPower 通过单个已验证的 Kerberos 用户 ID 发送。DataPower 的所有传入请求首先通过它们的 LDAP 凭证进行验证和授权。如果用户通过了这个验证或授权阶段,它们将被视为访问 Web 应用程序的合法用户。在此阶段,如果有需要,可能从 Web 应用程序访问权限中筛除某些用户。否则,完全可以通过单个 Kerberos 用户 ID 将所有请求发送到 Web 应用程序。

如果我们的 Web 应用程序更加复杂,且确实需要实际的客户端用户 ID,那么一个选择是将该用户 ID 作为 SOAP 消息的一部分传递到 Web 应用程序。另一个选择将在本系列的下一篇文章中讨论。但现在在本文中,所有客户端请求都使用单个映射的 Kerberos 用户 ID 发送到受 Kerberos 保护的 Web 应用程序。


在 DataPower 中实现解决方案

本节阐述了设置期望的配置所需的 Kerberos 工件,以及生成这些工件所需的命令。我们不会详细介绍 Application Server 上保护 Web 应用程序所需的 Kerberos 相关配置,只会简单提及一些通用的配置步骤和工件。如需了解更多信息,请参阅 IBM 红皮书:在 WebSphere Application Server 环境中实现 Kerberos

创建一个 Kerberos 用户帐户

为了创建一个 SPN 来用作您的 DataPower Kerberos 客户端用户 ID,可在 Active Directory (AD) 中创建一个用户 ID。您将使用在 Domain Controller 机器上运行的 Active Directory Users and Computers 控制台,并创建以下用户 ID:dpkerbclient

  1. 要在 AD Users 控制台中设置此用户 ID,右键单击 Users 文件夹并选择 New > User。在 “Full name” 字段和 “User logon name” 字段中输入 dpkerbclient。单击 Next 按钮,如图 2 所示。
    图 2. 新建的 AD 用户
    新建的 AD 用户
  2. 为此帐户输入一个密码,并取消选择 “User must change password at next logon” 复选框,选择 “User cannot change password” 和 “Password never expires” 复选框,如图 3 所示。单击 Next 按钮。
    图 3. New AD User 选项
    New AD User 选项
  3. 单击 Finish 按钮完成这个新用户帐户的创建。

创建一个客户端 SPN

然后,您将使用 “setspn.exe” 实用程序创建一个 SPN 来与这个新客户端帐户关联。

  1. 在 Domain Controller 机器上打开一个 DOS 命令窗口并执行以下命令:
    setspn -a HTTP/dpkerbclient.csupport.com dpkerbclient

    注意:“CSUPPORT.COM” 是我们的 AD 域的 AD 范围。将它替换为您合适的范围值。

    这会创建一个名为 “HTTP/dpkerbclient.csupport.com” 的 SPN,并将此 SPN 与 “dpkerbclient” 用户 ID 关联。这个 SPN 的 “HTTP” 部分是一个任意但常用的前缀。请注意,该 SPN 供 DataPower 用于识别如何从一个特殊的 keytab 文件(该 keytab 文件将在下面介绍)中查找一个密钥。还需要注意的是,这个 SPN 在供 DataPower 使用时区分大小写,所以您在引用此 SPN 时必须与大小写上下文保持一致。请参见图 4。

    图 4. Setspn 命令和输出
    Setspn 命令和输出

创建客户端 keytab 文件

现在您已有一个用于访问 Web 应用程序的用户 ID 和 SPN,您将为 DataPower Kerberos 配置设置一个 Kerberos keytab 文件。从名称可以看出,keytab 文件包含一个密钥表。每个密钥条目有一个私钥和一个与该私钥关联的服务主体名称 (SPN)。当然,keytab 文件中还包含其他信息,但只有这两项是我们关注的主要属性。keytab 文件仅包含一个密钥条目。这是 DataPower 在调用 Web 应用程序时将所有客户端请求映射到的用户 ID 的密钥和 SPN。

尽管仍然在 Domain Controller 上,但您将使用一个基于 Windows® OS 的实用程序 “ktpass.exe” 来创建我们的 keytab 文件。该 keytab 文件以后会在您配置处理后续安全对象时上传到 DataPower 中。

  1. 执行以下命令,生成 keytab 文件:
    ktpass -out c:\temp\dpkerbclient.keytab -princ
    HTTP/dpkerbclient.csupport.com@CSUPPORT.COM -mapUser dpkerbclient
    -mapOp set -pass * -crypto RC4-HMAC-NT
  2. 单击 Enter 键后,系统会提示您输入此用户 ID 的密码。可能还有一条警告消息,表明 pType 和帐户类型不匹配。可忽略此消息。请参见图 5。
    图 5. KTPASS 命令和输出
    KTPASS 命令和输出

注意:“CSUPPORT.COM” 是我们的 AD 域的 AD 范围。将它替换为您的合适的范围值。

Kerberos keytab 文件 – 服务器应用程序

在 WebSphere Application Server(snoop 应用程序将在其上托管)上,管理员已设置了一个用户 ID 和一个将用作服务器 SPN 的 SPN。管理员还为该服务器 SPN 帐户创建了一个 keytab 文件。这个 keytab 文件已上传到 Application Server,以解密其接收到的任何服务票证。

注意:客户端将一个服务票证发送给该 Application Server。该服务票证中包含仅与该 SPN 关联的服务器可解密和读取的已加密信息(这正是 Application Server 需要访问 keytab 文件获得服务器 SPN 的原因)。这可确保客户端请求被正确的目标使用。

尽管我们假设此工作已由管理员完成,但您还需要知道此服务器 SPN 是什么,以防在 DataPower 与后端服务器通信时,您被要求协助 Application Server 管理员验证 Kerberos 设置是否正确。

因为您仍在 Domain Controller 机器中工作,所以您还将执行一个 setspn 命令以列出和验证与 Web 应用服务器关联的服务器 SPN。

我们假设此 SPN(在我们的示例中为 HTTP/oc4102831681.csupport.com)已在之前由 WebSphere Application Server 管理员和 KDC 管理员设置。您需要确定哪个用户 ID 帐户名称与服务器 SPN 关联。KDC 管理员可提供该信息。有了该信息后,执行一条命令以验证服务器 SPN,如下所示:

setspn -l <userid associated with the server application SPN>

执行此命令后,您会看到以下输出。在我们的示例中,服务器 SPN 的帐户名称 HTTP/oc4102831681.csupport.com 为 “waskerb”。

Registered ServicePrincipalNames for CN=waskerb,CN=Users,DC=csupport,DC=com:
  HTTP/oc4102831681.csupport.com

对服务器 SPN 的这一验证消除了在以后遇到问题时检查此信息的需求。


DataPower 相关活动

现在您已创建了外围的 Kerberos 工件,您可开始使用 DataPower 创建一个多协议网关 (MPG) 配置,以允许客户端向受 Kerberos 保护的后端 Web 应用程序(在本例中为 snoop 应用程序)发出请求。本文开头已提到,这些客户端作为通过基本身份验证进行保护的 HTTP GET 请求传入 DataPower 中。DataPower 接受这些请求,在 LDAP 中验证该用户,然后使用一个 Kerberos 服务票证调用后端 snoop 应用程序来验证后端服务器。来自 snoop 应用程序的响应传回到客户端。

创建多协议网关

  1. 登录到 DataPower 控制台,在 “ default” 域中,创建一个名为 kerbDemo 的新用户域。
  2. 切换到这个新 kerbDemo 域,并单击 Multi-Protocol Gateway (MPG) 图标。
  3. 在 MPG 面板中,单击 Add 按钮,通过在 “Multi-Protocol Gateway Name” 字段中输入 “kerbDemoMPG” 来创建一个名为 “kerbDemoMPG” 的新 MPG 配置。将 “Type” 字段设置为 static-backend

定义前端设置

定义一个 Front Side Handler 来在端口 “50000”(这是我们为传入的请求选择的一个任意端口)接受 HTTP GET 请求,忽略除针对 “snoop” 应用程序的请求之外的所有请求。

  1. 单击 “+” 按钮,然后选择组合列表中的 HTTP Front Side Handler,该组合列表位于 MPG 面板右下侧的 “Front Side Protocol” 一节,如图 6 所示。
    图 6. 选择 Front Side Protocol Handler 类型
    选择 Front Side Protocol Handler 类型
  2. 在结果 “Configure HTTP Front Side Handler” 面板中,在 “Name” 字段中键入 kerbDemoFSH,在 “Port Number” 字段中键入 50000,然后选择下面的 “GET method” 复选框,如图 7 所示。撇开其他字段不管,单击 Apply 按钮。
    图 7. Front Side Handler 设置
    Front Side Handler 设置
  3. 最后,在 “Front side settings” 一节的 “Request Type” 小节中,单击 Non-XML 单选按钮,因为您的客户端不会将 SOAP 或 XML 发送到 DataPower。将所有其他字段或属性设置为默认值。

定义后端设置

  1. 对于后端设置,输入访问 WebSphere Application Server snoop 应用程序所需的 URL。在我们的示例中,该 URL 为 http://9.42.90.238:11000/snoop
  2. 在 “Front side settings” 一节的 “Request Type” 小节中,单击 Non-XML 单选按钮,因为 snoop 应用程序只会以 HTML 格式发回响应。将所有其他字段或属性设置为默认值。

    请参见图 8,了解最终的后端和前端设置。

    图 8. 后端和前端设置
    后端和前端设置

定义多协议网关策略

在下一节中,您将定义 MPG 策略来验证传入的客户端,并添加一个 Kerberos 令牌来验证后端服务器。

  1. 单击 kerbDemoMPG 配置的 “Multi-Protocol Gateway Policy” 一节中的 “+” 符号,为该配置创建一个新 MPG 策略。
  2. 在 “Configure Multi-Protocol Gateway Style Policy” 面板中,输入 kerbDemoMPGPolicy 作为 “Policy Name” 字段。
  3. 在 Rule 一节中,选择 Client to Server 作为 “Rule Direction”。然后单击 New Rule 按钮。
  4. 双击 Match 操作(中间有一个带等号的菱形符号),创建一个匹配所有定向到 snoop 应用程序的传入客户端请求的 “Matching Rule”。
  5. 单击 “Matching Rule” 组合框旁边的 “+” 符号。
  6. 在结果 “Configure Matching Rule” 面板中,同时在 Main 选项卡中,输入 kerbDemoSnoopMatch 作为 Name 字段,如图 9 所示。
    图 9. 配置 Matching Rule 名称
    配置 Matching Rule 名称
  7. 单击 “Configure Matching Rule” 面板的 Matching Rule 选项卡。单击 Add 按钮创建一条新匹配规则。将 “Matching Type” 设置保留为 URL,并输入 /snoop 作为 “URL Match” 值,如图 10 所示。
    图 10. 创建匹配规则
    创建匹配规则
  8. 单击 Apply 保存这些更改。再次单击 “Configure Matching Rule” 面板中的 Apply。单击 “Configure a Match Action” 面板中的 Done,更新这条新匹配规则。参见图 11。
    图 11. 配置匹配操作
    配置匹配操作

定义一个 AAA 操作

接下来将在此 MPG Policy Rule 中定义 AAA 操作。这是最有趣的一组配置步骤,因为它直接涉及到您之前生成的 Kerberos 工件。

  1. 在 “Configure Multi-Protocol Gateway Style Policy” 面板的 “Create rule:” 一节中,单击 AAA 图标并将它拖到规则行上,如图 12 所示。
    图 12. 将 AAA 拖到规则行上
    将 AAA 拖到规则行上
  2. 双击新放置的 AAA 图标以配置 AAA 操作。在结果 “Configure AAA Action” 面板中,首先将 “Input” 选择从 (auto) 更改为 INPUT。接下来将 “Output” 值从 (auto) 更改为 OUTPUT,如图 13 所示。
    图 13. 输入和输出设置
    输入和输出设置
  3. 单击 “AAA policy” 组合框左边的 “+”,创建一个新 AAA Policy 对象,如图 14 所示。
    图 14. AAA Policy Add 按钮
    AAA Policy Add 按钮
  4. 在 “Configure an Access Control Policy” 面板中,输入 kerbDemoAAAPolicy 并单击 Create 按钮。
  5. 在下一个面板中,勾选 “Define how to extract a user's identity ...” 一节下的 HTTP Authentication Header 复选框。单击 Next 按钮。
  6. 在下一个面板的 “Define how to authenticate the user” 一节中,勾选 Bind to Specified LDAP Server 复选框,如图 15 所示。
    图 15. Bind to Specified LDAP Server 选项
    Bind to Specified LDAP Server 选项
  7. 向面板添加其他 LDAP 相关配置字段。填入如下所示的这些值:

    LDAP Load Balancer Group:<load balancer group of LDAP servers; default is "none">

    Host:<ip address or host name of LDAP server>

    Port:<LDAP port; default value is "389">

    SSL Proxy Profile:<name of ssl proxy profile; default is "none">

    LDAP Bind DN:<bind Distinguished Name (DN) that has permission to search LDAP directory>

    LDAP Bind Password: <bind DN password>

    LDAP Search Attribute:<default is "dn">

    LDAP Version:<default is "v2">

    LDAP Search for DN<default is "off">

    LDAP Prefix:<String prepended to username to form a DN to search for, default is "cn=">

    LDAP Suffix:<default is blank field>

    Use Auxiliary LDAP Attributes:<default is none>

  8. 适当填入这些值以匹配您的 LDAP 环境后,单击 Next 按钮,如图 16 所示。

    注意:

    • 这些 LDAP 配置字段所需的信息对每个客户各不相同,具体取决于每个客户的特定 LDAP 环境。在本文中,我们尝试使用默认值来使此演示设置尽可能简单。此示例中使用的一些字段在处理传入的基本验证用户名和密码属性时并不是必要的。例如,在我们的 AAA LDAP 配置中,“LDAP Bind DN” 和 “LDAP Bind Password” 等属性不是必需的,可保留为空,因为它们仅在处理 WS-Security UsernameTokens 时适用。
    • 在演示场景中,通过基本验证标头收到的用户名和密码将用于绑定到 LDAP 并验证用户。如果您的客户端在使用 SOAP 消息和 WS-Security 元素,那么可能需要不同的 LDAP 属性值。这里主要是说这是一个简化的配置。不同的环境所需要的值也明显不同。建议您在配置特定的 LDAP 环境时与 LDAP 管理员沟通。
    图 16. LDAP Server 设置
    LDAP Server 设置
  9. 单击 Next 按钮。在下一个面板的 “Define how to extract the resources” 一节中,单击 URL Sent to Back End 复选框,如图 17 所示,并单击 Next 按钮。
    图 17. 定义提取资源的方式
    定义提取资源的方式
  10. 在下一个面板的 “Define how to authorize a request” 一节中,保留 Allow Any Authenticated Client 选项默认的单选按钮选择,如图 18 所示。这表明任何成功验证的客户端都有权访问后端服务器。单击 Next 按钮。
    图 18. 定义授权一个请求的方式
    定义授权一个请求的方式

    在我们的 AAA Access Control Policy 的最后一个面板上,您将配置 Kerberos 客户端和服务器主体。

  11. 在此面板的 “Choose any post processing” 一节中,选择 Generate a Kerberos SPNEGO token 单选按钮选项。这会强制将其他 Kerberos 相关输入字段添加到面板上。填入值,如下所示:

    Kerberos Client Principal:HTTP/dpkerbclient.csupport.com@CSUPPORT.COM

    Kerberos Client Keytab:<upload the client keytab file previously generated on Domain Controller>

    Kerberos Server Principal: <server SPN>(在我们的示例中为 HTTP/oc4102831681.csupport.com@CSUPPORT.COM)

    注意:“CSUPPORT.COM” 是我们的 AD 域的 AD 范围。将它替换为合适的范围值,比如 HTTP/dpkerbclient.test.com@TEST.COM

  12. 当上传 keytab 文件时,确保还选择了文件上传面板中的 Generate GSS-API Checksum in AP-REQ 单选按钮,如图 19 所示。如果未选择,当令牌未包含一个校验和来确认其未被修改时,WebSphere Application Server 则可能拒绝该令牌。
    图 19. 启用校验和生成
    启用校验和生成
  13. 单击 Commit 按钮,提交并应用此配置,如图 20 所示。
    图 20. Kerberos 配置值
    Kerberos 配置值

    注意:

    • Kerberos Client Principal 名称用于查找和识别 Kerberos Client Keytab 文件中的密钥条目。即使客户端 keytab 文件中只有一个 SPN and Key 条目,此字段中指定的客户端主体也会用于匹配该条目,并从客户端 keytab 文件中提取该条目。在 DataPower 向 KDC 服务器发出一条请求来获取此客户端的 Ticket Granting Ticket (TGT) 时,需要客户端 keytab 条目(包含密钥)。结果 TGT(从 KDC 发回)包含 KDC 插入的信息,只可使用客户端的密钥(KDC 知道客户端的密钥)进行解密。
    • DataPower 收到 TGT,并从 TGT 正确解密一个会话密钥(使用来自客户端 keytab 的密钥)后,它使用 TGT 从 KDC 请求一个 Service Ticket,以允许其与 snoop 应用程序通信。Kerberos Server Principal 会传递到 KDC 以表明 Service Ticket 用于哪个服务。DataPower 收到此 Service Ticket 时,它会缓存该 Service Ticket,然后使用其为 snoop 应用程序的传出请求创建服务令牌(在 HTTP 标头中发送的令牌)。Snoop 应用程序配置了 Kerberos 身份验证,可解密服务票证(因为它是使用指定 Server Principal 的密钥在 KDC 中进行了加密),还可验证用户的身份。
  14. 单击 “Configure an Access Control Policy” 面板上的 Done 按钮,单击 “Configure AAA Action” 面板上的 Done,然后单击 “Configure Multi-Protocol Gateway Style Policy” 面板上的 Apply Policy。然后单击 “Configure Multi-Protocol Gateway Style Policy” 面板上的 Close Window 链接(面板的右上部分)关闭此面板并返回到 DataPower 主控制台面板,如图 21 所示。
    图 21. 应用和关闭 MPG Style Policy
    应用和关闭 MPG Style Policy
  15. 在 “Configure Multi-Protocol Gateway” 主面板上,单击 Apply 按钮提交这些更改,然后保存此配置,如图 22 所示。现在,您几乎准备好测试新配置了。
    图 22. 应用更新的 MPG 配置更改
    应用更新的 MPG 配置更改

配置 Kerberos KDC 服务器

测试之前,您需要配置一个 KDC 服务器,以供 DataPower 通信。

  1. 在面板的左侧,展开 Objects 文件夹,然后展开 Crypto Configuration 文件夹。单击 Kerberos KDC Server 对象,如图 23 所示。
    图 23. Crypto 配置下的 Kerberos KDC Server
    Crypto 配置下的 Kerberos KDC Server
  2. 在 “Configure Kerberos KDC Server” 面板上,单击 Add 按钮添加一个新 KDC 服务器条目。为您的 KDC 服务器输入一个名称(可以是对您有意义的任何名称),然后在 “Kerberos realm name” 字段中输入范围名称,在 “Kerberos KDC Server” 字段中输入 KDC 服务器的主机名或 IP 地址。可以单击 Ping Remote 按钮来确保您可以联系 KDC 服务器。

    注意:Kerberos 范围名称必须与之前在 AAA Post Processing 操作中定义的客户端和服务器 SPN 值中所使用的范围名称匹配,比如 CSUPPORT.COM。区分大小写也很重要。

  3. 要预防与 Kerberos 令牌大小相关的可能错误,可打开 “Use TCP” 单选按钮。“Server Port Number” 字段通常保留默认值 (88)。单击 Apply 按钮创建这个新 KDC Server 对象,如图 24 所示。最后,保存该配置。
    图 24. 配置 Kerberos KDC Server
    配置 Kerberos KDC Server

测试 DataPower MPG Kerberos 配置

您现在可运行一个测试来确定新的 MPG 配置是否正确设置。为了使测试的设置尽可能简单,可使用 “curl” 实用程序将请求提交给 DataPower。

  1. 执行 curl 命令,模拟一个客户端浏览器向一个定向为 snoop 应用程序的 DataPower 发送一条请求:
    curl -v --basic -u "mjmwasuser2:passw0rd" 
     http://l2dp1.rtp.raleigh.ibm.com:50000/snoop

    在上面的命令中,您使用 --basic -u <username:password> 选项在 HTTP 请求中发送了一个基本的身份验证标头,使用的是有效的 LDAP 用户名和密码。这是在您的 AAA 策略中针对 LDAP 验证客户端的用户 ID 和密码。如果用户 ID 经过成功验证,那么 DataPower 会生成一个 Kerberos 服务票证,并向 snoop 应用程序发送一条请求,且包含了此令牌作为一个 HTTP 标头。如果一切工作正常,并且 Kerberos 令牌经过后端 Application Server 的正确验证,那么响应类似于清单 1 中所示的代码段。

    清单 1. 测试 Kerberos 配置的样例 curl 命令
    $ curl -v  -u "mjmwasuser2:wasUs3r2" http://l2dp1.rtp.raleigh.ibm.com:50000/snoop
    * About to connect() to l2dp1.rtp.raleigh.ibm.com port 50000 (#0)
    *   Trying 9.42.125.160... connected
    * Connected to l2dp1.rtp.raleigh.ibm.com (9.42.125.160) port 50000 (#0)
    * Server auth using Basic with user 'mjmwasuser2'
    > GET /snoop HTTP/1.1
    > Authorization: Basic bWptd2FzdXNlcjI6d2FzVXMzcjI=
    > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 
    NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
    > Host: l2dp1.rtp.raleigh.ibm.com:50000
    > Accept: */*
    >
    < HTTP/1.1 200 OK
    < X-Backside-Transport: OK OK
    < Connection: Keep-Alive
    < Transfer-Encoding: chunked
    ...
    ...
    ...
    <tr><td>javax.servlet.context.tempdir</td><td>/opt/ibm/
    SDP/runtimes/base_v7/profiles/WTE_APPSRV71/temp/localhostNode01/server1/
    DefaultApplication/DefaultWebApplication.war</td></tr>
    <tr><td>com.ibm.websphere.servlet.event.ServletContextEventSource
    </td><td>com.ibm.ws.webcontainer.webapp.WebAppEventSource@2e5f2e5f
    </td></tr>
    <tr><td>com.ibm.wsspi.portletcontainer</td><td>
    com.ibm.ws.portletcontainer.pcinvoker.PortletContainerImpl@7c627c62</td></tr>
    </table><BR><BR>
    </body></html>
    * Connection #0 to host l2dp1.rtp.raleigh.ibm.com left intact
    * Closing connection #0
    $

    如果在浏览器中打开来自响应的 HTML 内容,它似乎类似于图 25 所示。

    图 25. Snoop 应用程序响应
    Snoop 应用程序响应

Probe 分析

一个有助于分析经过 DataPower 的流量流并确认正确行为的工具是 “DataPower Probe” 实用程序。作为测试 Kerberos MPG 配置的最终活动,您将为此配置启用 Probe,然后再次运行 “curl” 测试。要使用 Probe 工具启用和验证测试,执行以下操作:

  1. 转到 kerbDemoMPG 配置的主要 MPG 面板并单击 Show Probe 链接,如图 26 所示。
    图 26. Show Probe 链接
    Show Probe 链接
  2. 在 Probe 面板中,单击 Enable Probe 按钮启用一次 probe 捕获,如图 27 所示。
    图 27. Enable Probe 按钮
    Enable Probe 按钮
  3. 再次运行 curl 测试,如上所述。运行此测试后,返回到 Probe 面板并单击 Refresh 按钮。您现在会看到显示了一条新 Probe 记录,如图 28 所示。该 Probe 记录之前有一个放大镜图标。
    图 28. 捕获的 Probe 记录
    捕获的 Probe 记录
  4. 单击放大镜图标查看 Probe 记录。从结果面板中,单击 AAA 图标(如图 29 所示的方形 AAA 图标)。如果请求成功运行,您会看到两条与 AAA 处理相关的记录:“ldap-authen” 记录和 “get-kerberos-apreq” 记录。这两条记录都有一个针对请求和响应的可单击 “(show nodeset)” 链接。这两条记录中任何一个缺少请求或响应链接则表明存在一个问题。请参见图 29。
    图 29. AAA Probe 执行跟踪
    AAA Probe 执行跟踪
  5. 要验证是否已生成了一个有效的 Kerberos 令牌,单击此面板上的 (show nodeset) 链接。您会看到一个 <apreq> 令牌元素,如图 30 所示。<spnego-apreq-base64> 子元素(包含在此元素内)作为一个 HTTP 标头传递到后端服务器(图 30)。
    图 30. 生成的 Kerberos 令牌
    生成的 Kerberos 令牌
  6. 最后,返回到 Probe 面板,单击 AAA 操作图标后面的放大镜图标。从这里,单击 Headers 选项卡。确认您看到了 “Authorization” 标头,该标头包含来自前面看到的 <spnego-apreq-base64> 子元素的内容(属于标头的一部分),如图 31 所示。这可确认 Kerberos 相关处理已成功完成,以及为向后端服务器传出的请求生成了一个 Kerberos 令牌。
  7. 如果遇到问题,返回到您启用 Probe(参见 图 27图 28)的 Probe 主面板,单击 View Log 按钮,检查与失败测试相关的日志消息。如果有必要,转到 DataPower 中的 Troubleshooting Panel,将 Log Level 设置为 debug 以允许生成更详细的日志消息。然后再次重复您的测试并查看生成的日志消息。
    图 31. HTTP Authorization 标头
    HTTP Authorization 标头

故障排除技巧

本节提供您在设置 DataPower 的 Kerberos 身份验证时可能遇到的一些常见问题。表 1 显示了其中每个问题的相关解决方案。

注意:

  • Debug Log Level 可通过导航到 Troubleshooting > Logging 以将日志记录级别提升到 “Debug-Level” 来进行设置。
  • 表 1 中提及的 CWSPN0011E 错误几乎总是需要 MustGather 文档 Problems with Spnego 中介绍的额外跟踪。
表 1. 故障排除常见问题
问题症状解决方案
在 DataPower AAA Post Processing 中为 Kerberos 客户端主体使用了无效的客户端 SPN。在 DataPower 错误日志中看到的调试级消息:
mpgw (kerbDemoMPG): Kerberos error in post processing: Client principal 'HTTP/BADdpkerbclient.csupport.com@CSUPPORT.COM' not found in Kerberos KDC database
为 Kerberos 客户端主体使用正确的 SPN
在 DataPower AAA Post Processing 中为 Kerberos 客户端主体使用了无效的服务器 SPN。在 DataPower 错误日志中看到的调试级消息:
mpgw (kerbDemoMPG): Kerberos error in post processing: Server principal 'HTTP/BADoc4102831681.csupport.com@CSUPPORT.COM' not found in Kerberos KDC database
为 Kerberos 服务器主体使用正确的 SPN。
在 DataPower AAA Post Processing 中,范围名称未包含在客户端或服务器 SPN 中。在 DataPower 错误日志中看到的调试级消息:
mpgw (kerbDemoMPG): Kerberos error in post processing: Invalid Kerberos principal name: 'HTTP/dpkerbclient.csupport.com'
确保范围名称包含在 Kerberos 客户端主体和 Kerberos 服务器主体中(例如 HTTP/dpkerbclient.csupport.com@CSUPPORT.COM)。
在 DataPower AAA Post Processing 中为 Kerberos 客户端主体使用了错误的客户端 SPN。在此情况下,该客户端 SPN 是 KDC 中一个有效的 SPN,但它不是与客户端 keytab 文件中的 SPN/密钥条目匹配的 SPN。在 DataPower 错误日志中看到的调试级消息:
mpgw (kerbDemoMPG): Kerberos error in post processing: Kerberos KDC 'CSUPPORTKDC' required preauthentication that could not be provided
确保 Kerberos 客户端主体字段中使用的 SPN 与客户端 keytab 文件中的 SPN 匹配。
在 DataPower AAA Post Processing 中为 Kerberos 服务器主体使用了错误的服务器 SPN。在此情况下,该服务器 SPN 是 KDC 中一个有效的 SPN,但它不是与客户端请求最终所针对的后端服务器关联的 SPN。这会导致后端服务器收到一个 Service Ticket 令牌,该令牌无法解密,且通常会导致后端服务器记录一条错误并返回错误的响应。DataPower 生成了一个令牌,并可在 Probe 中看到该令牌。对于针对 WebSphere Application Server 的后端服务器,以下是一条可在此情况下的 Application Server 跟踪日志中观察到的错误消息:
0000000f Context E com.ibm.ws.security.spnego.Context begin CWSPN0011E: A non-valid SPNEGO token has been encountered while authenticating a HttpServletRequest: 0000: a1143012 a0030a01 01a10b06 092a8648 ..0. .... .... .*.H
确保 Kerberos 服务器主体字段中使用的 SPN 对该服务而言是正确的 SPN。WebSphere Application Server 管理员可对 Application Server 使用的 keytab 文件发出一条 “klist” 命令,以验证服务 SPN 值。
在 DataPower AAA Post Processing 中未打开校验和选项。如果后端服务器配置为希望 Service Ticket 令牌中有一个校验和值,这通常会导致后端服务器记录一条错误并返回一个错误响应。DataPower 生成了一个令牌并可在 Probe 中看到该令牌。对于针对 WebSphere Application Server 的后端服务器,以下是一条可在此情况下的 Application Server 跟踪日志中观察到的错误消息:
0000000f Context E com.ibm.ws.security.spnego.Context begin CWSPN0011E: A non-valid SPNEGO token has been encountered while authenticating a HttpServletRequest: 0000: a1143012 a0030a01 01a10b06 092a8648 ..0. .... .... .*.H
确保勾选了 Kerberos Client Keytab 配置面板中的 “Generate GSS-API Checksum in the "AP-REQ"” 单选按钮(在 AAA 配置中)。
将一个更早的或与 SPN 的 KDC 中存在的版本号不同的密钥版本号 (kvno) 与一个客户端 keytab 文件中的 SPN 关联。
症状:在 DataPower 错误日志中看到的调试级消息:
mpgw (kerbDemoMPG): Cannot parse file for Kerberos keytab 'dpkerbclientKeytab'
在 DataPower 错误日志中看到的调试级消息:
mpgw (kerbDemoMPG): Cannot parse file for Kerberos keytab 'dpkerbclientKeytab'
确保客户端 keytab 文件中的 kvno 与 KDC 中与该 SPN 关联的 kvno 匹配。在 KDC Domain Controller 机器上使用 “ldifde” 命令确定 KDC 为给定 SPN 使用了什么 kvno 值。然后在 Linux 机器上使用 “klist” 实用程序确定 keytab 文件中的 kvno (klist -k <keytab file>)。如果它们不同,创建一个新 keytab 文件来确保它的 kvno 与 KDC 使用的 kvno 匹配。
当调用 ktpass 命令创建一个 keytab 文件并使用 “-kvno” 参数显式指定密钥版本号 (kvno) 时,keytab 文件中的 kvno 仍然与 KDC 中的 kvno 不匹配。在 DataPower 错误日志中看到的调试级消息:
mpgw (kerbDemoMPG): Cannot parse file for Kerberos keytab 'dpkerbclientKeytab'
似乎一些 ktpass 版本(如果不是所有版本)会强制 kvno 在每次为一个给定 SPN 生成 keytab 文件时在 KDC 中递增。如果在命令行指定了 “-kvno” 参数,它只会将 keytab 文件中的 kvno 设置为指定的值。KDC 中的 kvno 会递增到下一个更高的值。用户将在 Domain Controller 上多次使用 “ldifde” 命令在 KDC 中获取针对给定 SPN 的最新 kvno 值,然后调用 ktpass 命令并使用 “-kvno” 参数创建一个与该 kvno 匹配的新 keytab 文件。这不会生效,因为 KDC 针对该 SPN 的 kvno 会由于发出 ktpass 命令而递增。相反,只需发出不带 “-kvno” 参数的 ktpass 命令,并且结果 keytab 文件具有与 KDC 相同的 kvno 值。
Kerberos KDC Server 对象(在 Objects > Crypto Configuration 下)未创建,或者其 “Kerberos 范围名称” 值与 AAA Post Processing 面板中的 Kerberos Principal 所包含的值范围不匹配。当匹配这些范围值时,需要考虑大小写区分性。在 DataPower 错误日志中看到的调试级消息:
mpgw (kerbDemoMPG): Kerberos KDC for realm 'CSUPPORT.COM' not found
确保在 Kerberos KDC Server 对象中指定的范围与 AAA Post Processing 面板中的 Kerberos Principal Names 中指定的范围匹配。
测试 DataPower Kerberos 配置并监控网络流量时,似乎 DataPower 和 KDC 服务器之间没有网络通信。在测试 Kerberos 配置期间捕获网络数据包时,未看到任何与 Kerberos 相关的 IP 数据包在 DataPower 和 KDC 服务器之间流动。但是,DataPower 仍然能够生成以后端服务器为目标的 Kerberos 令牌。DataPower 会缓存从 KDC 发送的服务票证,所以它不会为每个请求请求一个新服务票证。无需任何解决办法,因为这是 DataPower 中一个正常且正确的行为。

结束语

本文演示了如何使用 DataPower WebUI 设置一个多协议网关配置,它允许非 Kerberos、经过验证的客户端连接到仅接受来自 Kerberos 验证的客户端请求的后端 WebSphere Application Server Web 应用程序。在该演示的过程中,您了解了如何使用一种不同的身份验证方法来验证客户端,然后在单个 Kerberos 主体名称下将所有请求提交到后端服务器。

您还了解了如何生成您的配置所需的必要的 Kerberos 工件,以及这些工件的使用位置和用途。最后,您还了解了一种使用 “curl” 实用程序测试 MPG 配置的便捷方式,以及如果事情从一开始就未成功发展时如何排除您的配置问题。

在我们的下一篇文章中,我们将介绍如何使用 DataPower 客户样式表 dp:get-kerberos-apreq 方法,以一种更加程序化的方式生成 Kerberos 令牌。我们还将探讨您将使用此方法的原因,以及它相对于我们在本文中演示的方法有何优缺点。


IBM 支持

如果您需要进一步协助,可收集以下 MustGather 信息并联系 IBM 支持

参考资料

学习

获得产品和技术

讨论

条评论

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=845333
ArticleTitle=配置受 Kerberos 保护的 WebSphere DataPower 后端服务器,第 1 部分: 使用 DataPower Web 图形用户界面
publish-date=11122012