ibm tivoli_Windows和Tivoli Access Manager的Intranet单一登录

ibm tivoli

基于Microsoft Windows的Intranet提供了使用桌面凭据登录基于Microsoft Internet信息服务的Intranet基础结构的能力。这是使用Microsoft的SPNEGO HTTP身份验证协议来实现的，并使用NTLM或Kerberos凭据进行登录。

在发布IBM Tivoli Access Manager for e-business 4.1之前，无法实现对TAM的WebSEAL Web资源授权引擎的相同登录。

使用TAM 4.1，可以通过将用于IIS的TAM插件的SPNEGO登录功能与WebSEAL的电子社区单点登录功能相结合来实现此登录。

本文详细介绍了完成此工作所需的配置步骤。

图1：从Windows工作站到IIS的单点登录

单一登录到Access Manager

作为上述单点登录功能的扩展，具有Active Directory域登录名的Intranet用户需要单点登录到Access Manager。如果不进行单点登录，用户将登录到其工作站并访问Access Manager（两次登录）。

图2：Intranet SSO要求

检查图2，用户将登录到Active Directory并在Windows工作站上收到凭据，该凭据可用于指示他们已登录。用户希望能够将这些凭证提供给WebSEAL，然后WebSEAL自动将用户登录。因此，用户希望在Active Directory域和Access Manager的WebSEAL之间进行单点登录。

解

推荐的解决方案是在带有WebSEAL的eCommunity单点登录配置中使用AM 4.1 Web服务器插件。 Web服务器插件被配置为主认证服务器（MAS）。

图3：Web服务器插件的使用

顺序如下：

用户登录到其工作站，对其Active Directory域进行身份验证，并接收Kerberos TGT。如果用户没有域登录名，则他们将登录到其工作站，并且将没有Kerberos凭据。
用户尝试在WebSEAL之后访问受保护的应用程序（一个需要认证的应用程序）。 WebSEAL将用户重定向到主身份验证服务器，该服务器是IIS上的Access Manager Web服务器插件。
已为SPNEGO身份验证配置了Web服务器插件。如果用户具有正确的Kerberos凭据，则他们将具有对Web服务器插件的单点登录。在这种情况下，Web服务器插件将与LDAP服务器通信以建立用户的AM凭据。（请注意，在Active Directory和LDAP上，用户的用户名必须相同。此配置假定每个用户的用户名都是唯一的）。然后，将用户重新定向回WebSEAL。 WebSEAL将为用户建立一个AM凭证。
对于用户无法使用SPNEGO进行认证的情况，Web服务器插件上的认证将失败，并且该用户将被重定向回WebSEAL，指示失败。然后，WebSEAL将提示用户进行认证。 WebSEAL将为用户建立一个AM凭证。
WebSEAL现在将授权对其保护的资源的访问。

为TAM Web服务器插件配置SPNEGO身份验证

要为IIS设置TAM Web服务器插件的SPNEGO身份验证模块，请编辑pdwebpi.conf配置文件。该文件位于<PDWebPIInstallDir> \ etc中，其中<PDWebPIInstallDir>是Web服务器的TAM插件安装目录，默认情况下为c：\ Program Files \ Tivoli \ PDWebPI \ etc。

此主机上所需的TAM软件包为：

TAM Run-Time Environment, Version 4.1 (plus pre-reqs)
TAM Plug-in for Web Servers, Version 4.1
TAM Plug-in for Microsoft Internet Information Services, Version 4.1

我们需要设置身份验证和会话处理才能处理SPNEGO。我们假设我们使用专用的IIS服务器进行SPNEGO身份验证，因此该信息在pdwebpi.conf配置文件的[common-modules]节中指定。如果要共享此IIS服务器的角色，则您需要配置的节是虚拟主机特定的节。

Web服务器插件需要支持的唯一身份验证方法是SPNEGO，但是只有Internet Explorer支持SPNEGO身份验证。如果需要支持多种浏览器，则还应指定基本身份验证。由于我们希望优先考虑SPNEGO，因此我们在BA模块之前列出了SPNEGO身份验证模块。因此，我们的身份验证机制将如下所示：

authentication = spnego
authentication = BA

我们需要在会话模块列表中包括SPNEGO。它用于在SPENGO身份验证期间维护会话状态。 SPNEGO身份验证完成后，我们需要将会话维护移交给其他方案-我们将使用会话cookie，因为可以在BA和SPNEGO身份验证的会话之间共享会话cookie。我们的会话模块配置将如下所示：

session = spnego
session = session-cookie

我们还要求帐户管理后授权模块在必要时处理注销和密码更改操作。因此，我们有：

post-authzn = acctmgmt

SPNEGO模块所需的唯一配置是是否让IIS处理SPNEGO身份验证。当IIS处理SPNEGO身份验证本身时，IIS就会知道用户是谁。如果IIS托管需要Windows用户凭据来标识用户的应用程序，则此功能很有用。如果IIS本身不处理SPNEGO身份验证，则Web服务器插件将自行执行。在这种情况下，用户对IIS似乎是匿名的。出于我们的目的，我们不需要IIS来查看用户身份，因此我们将指定SPNEGO身份验证不应委派给IIS。为此，我们在pdwebpi.conf配置文件的[spnego]节中将web-server-does-authn设置为no：

[spnego]
web-server-does-authn = no

为了使用户能够单点登录，他们将需要Windows Active Directory用户注册表和TAM用户注册表中的用户。在TAM用户注册表中，无需为用户维护任何密码信息，除非他们打算使用我们配置的BA身份验证方法，因为用户选择不使用Internet Explorer。当然，如果TAM用户注册表与用于桌面登录的Active Directory相同，则不需要复制用户信息。

在IIS计算机上启动（或重新启动）用于Web服务器的Access Manager插件服务将获取您刚刚进行的配置更改。现在，您应该使用Internet Explorer来访问IIS保护的资源，而无需专门登录TAM。

在IE以静默方式使用户登录网站之前，该网站必须是“受信任的Internet”区域的一部分。还要记住，如果IE 6用户在IE的“高级Internet选项”的“安全性”部分中取消选中“启用集成Windows身份验证”复选框，则将提示他们输入登录信息以登录到MAS。

在Web服务器插件和WebSEAL之间配置eCSSO

TAM支持的电子社区单点登录机制（eCSSO）允许在不同域中的Web服务器之间进行单点登录。在这种情况下，域可以表示两个不同的DNS域（即，不能共享cookie来实现单点登录的域）和完全独立的Access Manager域。

尽管它对于这种高级域间单点登录很有用，但它是一种轻量级的机制，适合在这种情况下使用，因为它允许提名对用户进行身份验证的主身份验证服务器（MAS），然后可以为其担保用户身份。

在我们的案例中，带有TAM插件的IIS服务器充当MAS的角色。当WebSEAL看到来自新用户的请求时，它可以将该用户重定向到可以执行基于SPNEGO的认证的MAS。然后，MAS将重定向回WebSEAL，以保证用户身份。 WebSEAL可以授权用户访问其正在保护的资源，并在适当时授予或拒绝该访问。

用于保证用户身份的机制是在将客户端重定向回WebSEAL时包括一个短暂的加密令牌。为了能够加密和解密此令牌，两个服务器需要共享一个密钥。通过使用Web服务器的TAM插件随附的pdwpi-cdsso-key-gen程序或WebSEAL随附的cdsso_key_gen程序，可以创建此密钥。该程序的两个不同版本产生兼容的密钥文件。在一个系统上创建文件后，应将其复制到另一个系统上。要创建密钥，请发出以下命令：

pdwpi-cdsso-key-gen c:\keys\company.com.key

程序的参数是存储密钥的文件名。实际为插件和WebSEAL配置eCSSO时，将参考此位置。

出于配置目的，我们假设IIS服务器的主机名是plugin.company.com，而WebSEAL的主机名是webseal.company.com。

要将IIS服务器配置为eCSSO MAS，我们需要将ecsso模块注册为授权后模块，然后对其进行配置。由于我们是MAS，因此我们不需要将此模块注册为身份验证模块（尽管这样做无害）。

[common-modules]
post-authzn = ecsso

为了将此服务器标识为MAS，我们在[ecsso]配置节中设置了一个参数：

[ecsso]
is-master-authn-server = yes

我们需要为电子社区选择一个名称-Web服务器插件选择的默认名称为ecsso，WebSEAL并未指定默认名称。电子社区的所有参与者必须对电子社区的名称具有相同的想法-我们将选择company.com作为我们的电子社区名称。

e-community-name = company.com

要指定在加密令牌以供webseal.company.com使用时使用的秘密密钥，我们在[ecsso-domain-keys]节中添加了一个条目：

[ecsso-domain-keys]
company.com = c:\keys\company.com.key

现在，重新启动Web服务器的Access Manager插件服务将获取新配置并开始充当主身份验证服务器。

要将WebSEAL配置为使用该插件作为主认证服务器，我们必须复制我们先前生成的密钥。如果使用FTP，请使用二进制模式传输文件。我们假定WebSEAL在类似UNIX的平台上运行，并且密钥文件存储在/keys/company.com.key中。

WebSEAL所需的大多数配置都在[e-community-sso]节中。要启用WebSEAL的eCSSO功能，我们必须指定我们可以接收触发eCSSO认证的请求的协议集。强烈建议仅启用HTTPS支持，因为客户端重定向到的URL包含一个加密令牌，如果被恶意网络用户捕获，则可以重播该令牌。加密令牌的生存期只有很短的时间（默认情况下为5分钟），以使MAS和WebSEAL上的系统时钟略微不同步。令牌只能在此时间段内重播，但是最好只允许通过HTTPS进行eCSSO操作来消除任何可能性。

[e-community-sso]
e-community-sso-auth = https

我们需要指出此WebSEAL本身不是主认证服务器，而且也不是主认证服务器所在的位置：

is-master-authn-server = no
master-authn-server = plugin.company.com

我们指定电子社区名称，以匹配为MAS指定的名称：

e-community-name = company.com

我们在[e-community-domain-keys]节中指定密钥：

[e-community-domain-keys]
company.com = /keys/company.com.key

WebSEAL使用CDAS来执行eCSSO令牌解码。默认情况下，未启用单点登录令牌使用CDAS（ssoconsume），因此我们需要启用它。我们假定Solaris安装程序具有“ .so”库扩展名，但ssoconsume CDAS随所有WebSEAL平台一起提供，因此可以根据您使用的WebSEAL平台轻松更改此属性值。

[authentication-mechanisms]
ssoconsume = /opt/pdweb/lib/libssoconsume.so

为了解决在eCSSO认证过程中处理失败的可能性，建议为WebSEAL启用辅助认证机制-例如

forms based authentication:[forms]
forms-auth = https

如果eCSSO机制由于任何原因失败，这使WebSEAL可以在登录用户时将WebSEAL故障回复到备用认证策略。

将Active Directory用于TAM用户注册表

如果TAM用户注册表与用于验证桌面登录名的Active Directory相同，则不再需要在Active Directory和TAM用户注册表之间复制用户信息。

图4：将Active Directory用于TAM用户注册表

这样做的唯一缺点是，从TAM 4.1开始，这要求所有TAM基础结构都托管在Windows 2000 Advanced Server计算机上，并且不能在UNIX计算机上运行。这包括以上架构中显示的WebSEAL和TAM策略服务器（未显示）。

配置摘要

总结通过IIS的TAM插件将SPNEGO SSO启用到WebSEAL所需的配置文件更改：

pdwebpi.conf

[pdweb-plugins]
virtual-host = plugin.company.com[common-modules]
authentication = spnego
authentication = BA
session = spnego
session = session-cookie
post-authzn = ecsso
post-authzn = acctmgmt[BA]
realm = "Company.Com Intranet"[spnego]
web-server-does-authn = no[ecsso]
is-master-authn-server = yes
e-community-name = company.com[ecsso-domain-keys]
company.com = c:\keys\company.com.key

webseald.conf

[e-community-sso]
ecsso-authn = https
is-master-authn-server = no
e-community-name = company.com
master-authn-server = plugin.company.com[e-community-domain-keys]
company.com = /keys/company.com.key[authentication-mechanisms]
ssoconsume = /opt/pdweb/lib/libssoconsume.so

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

ibm tivoli