kerberos跨域互信_使用Kerberos的Web服务安全互操作性

最新推荐文章于 2024-04-19 19:15:09 发布

cuyi7076

最新推荐文章于 2024-04-19 19:15:09 发布

阅读量2k

点赞数

文章标签： python linux java 大数据数据库

原文链接：https://www.ibm.com/developerworks/tivoli/library/t-tfim-kerberos/index.html

版权

kerberos跨域互信

需要Web服务安全性标准，以确保异构环境中的互操作性。 WS-Security标准及其依赖项（例如WS-Trust和WS-Security Policy）是该领域中的重要标准。 WS-Security与安全令牌无关，允许使用多种安全令牌类型。在内联网方案中流行的一种安全令牌类型是Kerberos令牌。这主要是因为Kerberos是Microsoft Active Directory服务器中安全系统的组成部分。

可以合理预期使用这些标准可以实现Web服务的安全互操作性，而事实确实如此。但是，要实现Microsoft .NET和IBM WebSphere环境之间的互操作性，需要执行一些非显而易见的步骤。本文提供了有关如何使用Kerberos安全令牌作为Microsoft .NET和IBM WebSphere环境之间Web服务的身份验证机制的端到端示例。

本文本节的其余部分介绍了用于实现此解决方案的关键技术。

的Kerberos

Kerberos是一种网络身份验证协议，最初是由麻省理工学院开发的。它最初在RFC 1510中进行了描述，而协议的最新版本在RFC 4120下进行了描述。 Kerberos协议需要一个称为密钥分发中心（KDC）的受信任第三方。 KDC具有两个主要组件：身份验证服务器（AS）和票证授予服务器（TGS）。身份验证服务器与Kerberos领域（域）中的每个客户端和服务器共享一个秘密。这些共享机密用于导出对称密钥，该对称密钥用于在客户端或服务器与KDC之间交换加密信息。

图1. Kerberos的概念图

TGS发出“票证”作为允许客户端向服务器进行身份验证的方式。 KDC设计的好处之一是，服务器在验证从客户端收到的票证时无需与KDC通信。图1显示了从客户端身份验证到客户端身份验证到服务器应用程序的步骤顺序。

UserA向身份验证服务器进行身份验证。用户A的密码不需要通过网络传输到身份验证服务器。成功认证后将返回票证授予票证（TGT）。 TGT允许UserA与票证授予服务器联系，以请求其他服务器的票证。
UserA使用TGT来向票证授予服务器进行身份验证。 TGT可以由TGS验证，因为它已使用TGS的密钥加密。 UserA获得与ServerB一起使用的服务票证。
UserA将在上一步中获得的服务票证提供给ServerB。 ServerB可以通过使用其密钥对其进行解密来在本地验证此票证。

在Windows 2000（包括Windows 2000）以后的Microsoft Windows服务器发行版中，Microsoft Active Directory中的安全子系统部分基于Kerberos。当用户登录配置为Microsoft Active Directory域的桌面时，他们正在向Kerberos身份验证服务器的Microsoft实现进行身份验证。然后可以从Microsoft Active Directory获取Kerberos票证，以通过简单和受保护的GSSAPI协商机制（SPNEGO）对其他服务器（例如Microsoft Internet信息服务器（IIS））进行身份验证。

Microsoft网站提供了有关Windows Server 2003中Kerberos实现的内容。

Kerberos的有用参考站点位于：

Microsoft Web服务增强

Microsoft Web服务增强功能是Microsoft .NET框架受支持的扩展，可以在Web服务领域提供高级功能。 .NET框架提供了包括基本安全性在内的某些Web服务功能，而WSE包含Microsoft对诸如WS-Security和WS-Trust之类的Web服务中的关键行业标准的实现。 WSE提供与Microsoft Visual Studio开发环境的集成，并且与较新的Microsoft Windows Communications Foundation（WCF）有线兼容。

Web服务通过“策略声明”在WSE中得到保护。提供了许多内置的断言（交钥匙断言）。交钥匙声明的示例包括：

usernameOverTransportSecurity-使用UsernameToken进行身份验证，但不对消息进行加密或签名；
usernameForCertificateSecurity-使用UsernameToken对客户端进行身份验证。使用X.509证书提供服务器身份验证，并执行消息级别的安全性。
kerberosSecurity-使用Kerberos令牌对客户端和服务器进行身份验证，并执行消息级安全性。

通常使用策略配置文件以声明方式配置安全策略，该配置文件包含对Microsoft .NET程序集的引用，这些Microsoft .NET程序集包含策略声明类以及每个安全策略声明的任何配置。在应用程序的配置文件（即Web.config或app.config）中引用了策略配置文件，并且应用程序本身指定了要使用的策略配置的名称。清单2包含一个策略配置文件的示例，该文件期望UsernameToken可以验证传入的Web服务请求。

清单1. WSE 3.0策略文件的示例

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">
  <extensions>
    <extension name="usernameOverTransportSecurity" \
      type="Microsoft.Web.Services3.Design.UsernameOverTransportAssertion, \
      Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, \
      PublicKeyToken=31bf3856ad364e35" />
    <extension name="requireActionHeader" \
      type="Microsoft.Web.Services3.Design.RequireActionHeaderAssertion, \
      Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, \
      PublicKeyToken=31bf3856ad364e35" />
  </extensions>
  <policy name="ServicePolicy">
    <usernameOverTransportSecurity />
    <requireActionHeader />
   </policy>
</policies>

Tivoli联合身份管理器

Tivoli Federated Identity Manager（TFIM）是用于SOA中身份传播的IBM解决方案。在SOA中启用身份传播的TFIM的核心组件是安全令牌服务（STS）。 STS支持WS-Trust规范（请参阅参考资料），该规范为SOA基础结构提供了一种基于标准的机制，以供访问SOA基础结构以验证，转换和发布表示身份的安全性令牌。 SOA组件和TFIM STS之间的交互如图2所示。

图2.在SOA中使用TFIM STS

在TFIM STS中，可以指定不同的身份传播配置。这些配置称为“信任模块链”。根据AppliesTo，Issuer和TokenType参数的值，将STS的传入请求与TFIM中的信任模块链进行匹配。这样，相同的逻辑STS实例可以支持各种不同的身份要求。

TFIM STS可以使用许多不同的安全令牌类型进行操作，包括：

SAML 1.0
SAML 1.1
SAML 2.0
用户名
的Kerberos
X.509证书
轻量级第三方认证（LTPA）
Tivoli Access管理器
树液

此外，如果需要，可以为自定义安全令牌开发新的安全令牌模块。

TFIM中的Kerberos支持

TFIM 6.1.1包括用于验证Kerberos令牌的Kerberos STS模块，但没有用于生成这些令牌的功能。 TFIM 6.2通过支持验证和生成Kerberos令牌扩展了此功能。此外，TFIM 6.2引入了一个新的STS模块，即Kerberos委托模块，该模块使用Windows Server 2003约束的委托Kerberos扩展。

Kerberos委派STS模块的优点是在发出Kerberos令牌时不需要客户端的密码。 Kerberos STS模块提供了通用的Kerberos安全令牌功能，但是在发出Kerberos令牌时，要求客户端的密码可以通过TFIM信任模块链处理中的STS通用用户对象进行访问。

另一个考虑因素是，Kerberos委托模块必须在具有“作为操作系统”特权的一部分的“帐户”下运行（例如，“本地系统”帐户）。

表1总结了这两个STS模块的相对优点。

表1.比较TFIM STS Kerberos模块

	Kerberos模块	Kerberos委托模块
TFIM STS平台	任何	仅Windows Server 2003
需要操作系统特权	没有	是
Kerberos KDC	任何	仅Microsoft Active Directory
发行令牌？	是	是
验证令牌？	是	没有
需要客户端密码吗？	是	没有

在以下情况下，应考虑使用Kerberos委托STS模块：

Kerberos令牌仅需要发布，无需验证；
TFIM Runtime在Windows Server 2003服务器上以具有“作为操作系统”特权的一部分的帐户运行；
托管TFIM运行时的Windows Server 2003服务器是Active Directory域的一部分，该域将充当Kerberos KDC。和
Active Directory已配置为受约束的委派。

如果不满足以上任何条件，请使用Kerberos STS模块。

在某些情况下，可以减轻Kerberos委托STS模块不需要客户端密码的优点。例如，如果Kerberos STS模块是STS模块链的一部分，其中包括对传入的用户名令牌的验证，并且该令牌包括KDC中定义的主体的密码，那么在发行Kerberos令牌时可以使用此密码。如果无法从传入令牌获得密码，则可以通过STS映射模块（例如Tivoli Access Manager全局登录映射模块）来提供密码。

Microsoft .NET和IBM WebSphere Application Server之间的Kerberos互操作性

Microsoft WSE提供了交钥匙安全性断言，该断言使用Kerberos安全性令牌。除其他事项外，交钥匙安全声明将：

为客户端生成Kerberos安全令牌
在Web服务请求的WS-Security标头中包含Kerberos安全令牌
使用Kerberos安全令牌对请求的一个或多个元素进行签名
使用Kerberos安全令牌对请求的一个或多个元素进行加密
为服务生成Kerberos安全令牌
使用Kerberos安全令牌对响应的一个或多个元素进行签名
使用Kerberos安全令牌对响应的一个或多个元素进行加密

Microsoft WSE中的交钥匙安全性断言无法使用WebSphere Application Server和Tivoli Federated Identity Manager与IBM解决方案进行互操作。尽管可以由Tivoli Federated Identity Manager验证和生成兼容的Kerberos安全令牌，但是IBM解决方案当前不支持消息级别的签名和加密，这对于交钥匙安全性断言是必不可少的。

相反，已经开发了针对Microsoft WSE的自定义安全性断言，该断言仅提供消息身份验证的互操作性。本文的“ 下载”部分中提供了源代码作为示例代码的一部分。 Echo应用程序下载包含一个名为“ KerberosOverTransport”的Microsoft Visual Studio 2005项目。该项目包括三个类别：

KerberosOverTransportAssertion
此类扩展了Microsoft.Web.Services3.Design.SecurityPolicyAssertion类。它注册将用于过滤传入和传出消息的自定义类（请参阅此列表中的下两个类），并为所有配置参数解析WSE策略配置。
KerberosClientOutputFilter
KerberosOverTransportAssertion类引用了该类。编写外发Web服务消息时，将调用其SecureMessage（）方法。 SecureMessage（）方法创建一个Kerberos安全令牌，并将其添加到将包含在传出消息的WS-Security SOAP标头中的安全令牌集中。
KerberosServiceReceiveFilter
KerberosOverTransportAssertion类也引用了该类。当收到传入的Web服务消息并对其进行验证时，将调用其ValidateMessageSecurity（）方法。 ValidateMessageSecurity（）方法验证传入消息中的Kerberos安全令牌是否有效，然后在SOAP消息的执行上下文中使用Kerberos安全令牌中的身份。

使用安全性声明来验证Web服务接收的传入Kerberos令牌时，除了指定空的kerberosOverTransportAssertion元素外，无需进行其他配置，如清单2所示。

清单2.指定kerberosOverTransportAssertion作为Web服务策略的一部分

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">
  <extensions>
    <extension name="kerberos" \
      type="Microsoft.Web.Services3.Design.KerberosTokenProvider,Microsoft.Web.Services3,\
      Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    <extension name="kerberosOverTransportAssertion" \
      type="KerberosOverTransport.KerberosOverTransportAssertion,KerberosOverTransport" />
  </extensions>
  <policy name="ServerPolicy">
    <kerberosOverTransportAssertion/>
  </policy>
</policies>

在使用安全性断言向Web服务请求中添加Kerberos安全性令牌时，需要指定服务器/服务的Kerberos主体名称，如清单3所示。

清单3.指定kerberosOverTransportAssertion作为Web服务客户端策略的一部分

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">
  <extensions>
    <extension name="kerberos" \
      type="Microsoft.Web.Services3.Design.KerberosTokenProvider,Microsoft.Web.Services3,\
      Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    <extension name="kerberosOverTransportAssertion" \
      type="KerberosOverTransport.KerberosOverTransportAssertion,KerberosOverTransport" />
  </extensions>
  <policy name="ClientPolicy">
    <kerberosOverTransportAssertion>
      <!--
        For a Web service hosted in Microsoft .NET, the targetPrincipal will
        be of the form host/<hostname>, where <hostname> is the name of the
        host running the service.

        For a Web service hosted in and IBM WebSphere environment where the TFIM
        Kerberos STS module is used to validate the Kerberos token in the
        incoming message, the targetPrincipal must match the value in the
        STS module's configuration parameters.
      -->
      <targetPrincipal>fimservice</targetPrincipal>
    </kerberosOverTransportAssertion>
  </policy>
</policies>

示例：与TFIM Echo应用程序的互操作性

TFIM Web服务安全管理（WSSM）组件包括示例J2EE Web服务客户端和服务器应用程序。本文提供了指向示例WSE 3.0 Web服务客户端和服务器应用程序的下载链接。目标是从WSE客户端应用程序到J2EE Web服务应用程序以及从J2EE客户端应用程序到WSE Web服务应用程序进行通信。在这两种情况下，都使用Kerberos安全令牌对Web服务请求进行消息级身份验证。

在本节的其余部分，假定存在以下必备环境：

TFIM管理域已创建；
TFIM运行时已部署；
已安装示例J2EE应用程序echoclientapplication.ear和echoapplication.ear ；和
已安装Windows Server 2003 SP2或更高版本，并安装和配置了Active Directory和Windows Server支持工具（包括Kerberos命令行实用程序）。

图3显示了各种应用程序的部署。 TFIM服务器fimserver.fim.example.com使用TFIM随附的WebSphere Application Server的嵌入式版本来托管TFIM运行时。示例J2EE应用程序已部署到WebSphere Application Server 6.1的单独实例。托管TFIM服务器的计算机不必是Active Directory域的一部分。

Active Directory服务器fimtest.fim.test.com承载示例Microsoft WSE应用程序。在生产环境中，将WSE应用程序运行在单独的服务器上会更为常见。在这种情况下，托管Microsoft WSE应用程序的服务器必须是Active Directory域的一部分。

图3.示例应用程序环境

作为域管理员，在Active Directory服务器上执行以下初步步骤。

在fim.test.com下的Active Directory中创建一个名为fimclient的用户，密码为Passw0rd 。密码包含大写和小写字符以及一个数字，以满足默认密码策略。
在fim.test.com下创建另一个名为fimservice的用户，该用户的密码也为Passw0rd 。
在命令行中，运行ksetup将fimservice Kerberos主体名称映射到fimservice用户帐户。

ksetup /mapuser fimservice/fimtest.fim.test.com@FIM.TEST.COM fimservice
在命令行中，运行ktpass为fimservice创建密钥表文件。 keytab文件提供对服务器实体秘密密钥的访问（与可以将其密码输入到交互式应用程序中的用户相反）。

ktpass -out fimservice.keytab -princ fimservice/fimtest.fim.test.com@FIM.TEST.COM -Crypto RC4-HMAC-NT -mapUser fimservice@FIM.TEST.COM -pass Passw0rd -ptype KRB5_NT_PRINCIPAL

将生成的fimservice.keytab文件复制到TFIM服务器上的某个位置。

在TFIM服务器上执行以下初步步骤。

使用TFIM控制台，导航到“默认Kerberos令牌”模块实例，并更新其属性以指定krb5.conf和jaas.conf配置文件的位置。示例krb5.conf和jaas.conf文件与TFIM WSSM组件一起安装，可以在Windows上的C：\ Program Files \ IBM \ FIM \ wssm \ examples \ etc和/ opt / IBM / FIM / wssm / examples /中找到等在Linux /UNIX®。
通过确保Kerberos领域名称和KDC的位置正确，验证krb5.conf配置文件的内容正确。
jaas.conf配置不需要修改。

IBM WebSphere客户端到Microsoft .NET服务

以下步骤描述了WSE Web服务应用程序的安装，TFIM STS模块链的配置，以代表J2EE客户端应用程序生成Kerberos安全令牌，以及运行J2EE客户端应用程序。

在Active Directory服务器上，使用别名EchoService在IIS下安装示例WSE Web服务应用程序。
使用浏览器导航到此应用程序，以确保已正确安装。例如：

http://fimtest.fim.test.com/EchoService/Echo.asmx
使用TFIM控制台，创建一个信任链，该信任链将用于在与WSE Web服务应用程序进行通信时发出Kerberos安全令牌，以供J2EE客户端包含。
- 将“ AppliesTo”地址设置为REGEXP：（。* / EchoService / Echo.asmx），并将“发行者”地址设置为urn：itfim：wssm：tokengenerator。
- 创建一个链，该链由处于验证模式的默认SAML 2.0令牌模块，处于发布模式的默认映射模块和默认Kerberos令牌模块组成。
- 配置SAML 2.0模块以跳过签名验证。
- 通过导入TFIM附带的wssm_test.xsl样式表来配置地图模块。该样式表提供了Kerberos客户端名称（fimclient）和密码（Passw0rd）。
- 如图4所示配置Kerberos模块。将领域名称设置为FIM.TEST.COM（Active Directory域的名称），将服务名称设置为host / fimtest.fim.test.com。名称host / fimtest.fim.test.com是运行WSE Web服务的服务器的主机主体名称。选择此主体名称是因为IIS服务器在映射到该主体的本地系统帐户下运行。
  图4. Kerberos模块问题配置
确保在TFIM运行时中更新了TFIM配置更改。
使用浏览器导航到J2EE客户端应用程序。例如：

http://fimserver.fim.example.com:9080/EchoClientApplication
使用之前创建的fimclient用户登录到应用程序，然后选择Kerberos作为令牌类型。
将http://fimtest.fim.test.com/EchoService/Echo.asmx指定为Echo Web服务URL，然后单击WhoAmI按钮。
图5显示了J2EE客户端应用程序调用WSE Web服务的结果。 WSE Web服务返回Kerberos安全令牌中包含的信息，包括客户端主体名称和目标主机主体名称。
图5. J2EE客户端应用程序

图6说明了J2EE客户端应用程序和WSE Web服务应用程序之间的消息流。

J2EE客户端应用程序的部署描述符规定Kerberos安全令牌包含在Web服务请求中。
TFIM WSSM代表该应用程序对TFIM STS进行WS-Trust调用，以发出Kerberos安全令牌。它以SAML 2.0安全令牌将经过身份验证的用户的身份信息提供给STS。
TFIM STS执行配置的STS模块链，并向WSSM返回Kerberos安全令牌，以将其包含在Web服务请求中。
Web服务请求（包括Kerberos安全令牌）被发送到WSE Web服务应用程序。 WSE验证Kerberos安全令牌，并以fimclient用户的身份执行Web服务请求。
Web服务执行，并且WSE Web服务应用程序将响应返回到J2EE客户端应用程序。

图6. WSE服务的J2EE客户端

可下载资源部分中提供了Echo客户端和服务之间的示例SOAP消息以及TFIM WSSM和TFIM STS之间的示例WS-Trust消息。

Microsoft .NET Client到IBM WebSphere Service

以下步骤描述了TFIM STS模块链的配置（代表J2EE Web服务应用程序验证Kerberos安全令牌），WSE客户端应用程序的配置以及运行WSE客户端应用程序。

使用TFIM控制台，创建一个信任模块链，该链将用于验证J2EE Web服务应用程序接收到的Kerberos安全令牌。
- 将“ AppliesTo”地址设置为REGEXP：（。* / EchoApplication / services / EchoServiceKerberos），并将“发行者”地址设置为urn：itfim：wssm：tokenconsumer。
- 创建一个链，该链由处于验证模式的默认Kerberos令牌模块，处于发布模式的默认映射模块和默认SAML 2.0令牌模块组成。
- 配置Kerberos模块，如图7所示。将keytab文件名设置为先前创建的从Active Directory服务器复制的fimservice.keytab文件。
  
  图7. Kerberos模块验证配置
- 通过导入TFIM附带的wssm_test.xsl样式表来配置地图模块。
- 在发布组织设置为fim.test.com的情况下配置SAML 2.0模块，并且不对SAML声明进行签名或加密。
在Active Directory服务器上，在WSE客户端应用程序的bin目录中找到EchoClient.exe.config文件，并将URL更新为J2EE Web服务的URL。例如：

http://fimserver.fim.example.com:9080/EchoApplication/services/EchoServiceKerberos.

wse3policyCache.config文件位于同一目录中，并将目标主体指定为fimservice / fimtest.com.test.com。在此环境中无需更改此设置，但可以更改为匹配Active Directory中为其他服务创建的任何服务主体。
从命令行运行WSE客户端应用程序EchoClient.exe。 J2EE Web服务从其登录上下文返回信息，包括用户身份。

图8说明了WSE客户端应用程序和J2EE Web服务应用程序之间的消息流。

WSE客户端将Web服务请求（包括Kerberos安全令牌）发送到J2EE Web服务应用程序。
TFIM WSSM代表应用程序对TFIM STS进行WS-Trust调用，以验证Kerberos安全令牌。
TFIM STS执行配置的STS模块链，使用配置的keytab文件验证Kerberos安全令牌，并将用户的身份信息以SAML 2.0安全令牌返回给TFIM WSSM。
Web服务执行，并且J2EE Web服务应用程序将响应返回到WSE客户端应用程序。

图8. WSE客户端到J2EE服务

可下载资源部分中提供了Echo客户端和服务之间的示例SOAP消息以及TFIM WSSM和TFIM STS之间的示例WS-Trust消息。

故障排除

本节列出了一些常见的配置问题和可能的解决方案。下述错误消息将在Echo客户端应用程序中显示。此处描述的配置参数值对应于以上示例中使用的值。

WSE594找不到网络路径
如果配置了无效的目标主体名称，则Microsoft WSE客户端应用程序将显示WSE594错误。查看wse3policyCache.config文件，并确保targetPrincipal为fimservice / fimtest.fim.test.com。
J2EE Web服务返回的NullPointerException
如果Microsoft WSE客户端指定了错误的目标主体名称，则J2EE Web服务应用程序将返回NullPointerException并显示在Microsoft WSE客户端中。查看wse3policyCache.config文件，并确保targetPrincipal为fimservice / fimtest.fim.test.com。确保将Kerberos STS模块配置为使用生成的fimservice.keytab文件。
STSClientException-空凭证
如果Kerberos STS模块中配置的领域名称无效，则J2EE Web服务应用程序将返回STSClientException并显示在Microsoft WSE客户端中。确保Kerberos STS模块配置了领域名称FIM.TEST.COM。
STSClientException-在Kerberos数据库中找不到服务器
如果Kerberos STS模块中配置的服务名称无效，则J2EE Web服务应用程序将返回STSClientException并显示在Microsoft WSE客户端中。确保Kerberos STS模块配置了服务名称为host / fimtest.fim.test.com。
WSE594登录失败：用户名未知或密码错误
如果在Kerberos STS模块中配置了错误的服务名称，则WSE Web服务应用程序将返回WSE594错误并显示在J2EE客户端中。确保Kerberos STS模块配置了服务名称为host / fimtest.fim.test.com。
传入请求中没有Kerberos安全令牌
WSE Web服务应用程序期望具有特定值类型的Kerberos安全令牌。确保将Kerberos STS模块配置为使用GSS_Kerberosv5_AP_REQ值类型。

结论

本文演示了Microsoft .NET与IBM WebSphere环境之间安全，启用Kerberos，可互操作的Web服务所需的步骤。 IBM Tivoli Federated Identity Manager是此解决方案的关键推动力，它具有与IBM WebSphere Application Server集成以及灵活地验证和发出Kerberos安全令牌的能力。

翻译自: https://www.ibm.com/developerworks/tivoli/library/t-tfim-kerberos/index.html