IBM WebSphere 开发者技术期刊: 利用 Tivoli Access Manager 和 WebSphere Portal 配置单点登录

引言

IBM WebSphere Portal 作为一个应用程序在 IBM WebSphere Application Server 上运行，提供内容、应用、流程、个性化和其它服务的集合体。WebSphere Application Server 和 WebSphere Portal 可以和外部安全管理产品集成，例如 IBM Tivoli Access Manager for e-business 或 Netegrity® SiteMinder®。

Tivoli Access Manager（以下称为 Access Manager）中有一个名为 WebSEAL 的逆向代理安全服务器组件。在企业电子商务基础结构中，WebSEAL 可以作为任何 Web 应用服务器或 Web 服务器的前端系统。当 WebSphere Application Server （以下称为 Application Server）和 WebSphere Portal 通过 WebSEAL 实现时，通常需要为终端用户提供一个单点登录 (SSO)。为了获得 SSO，需要将 Application Server 配置为"信任" WebSEAL 服务器，使得如果 WebSEAL 已经认证了一个用户，Application Server 不会向用户再次要求认证。

Application Server 提供了您为第三方安全服务器配置的 Web 信任关联架构。每种类型的安全服务器都需要实现信任关联拦截器 (TAI)。Application Server 和 TAI 一起用于配置 Access Manager。在建立信任的基础上，Application Server 可以将 WebSeal 的结果证书映射为一个有效的 Application Server 证书。

本文着重讨论为了身份验证而将 WebSEAL 和 WebSphere Portal 集成，从而向 WebSphere Portal 提供 SSO。这个信息是针对 Application Server 系统管理员、门户系统管理员以及其他需要为他们的 WebSphere Portal 应用程序提供 SSO 的人。要充分利用本文，您应该熟悉 Application Server、WebSphere Portal 以及 Access Manager 管理任务。您还应该熟悉配置 LDAP 目录服务器，例如 IBM Tivoli Directory Server，本文所描述的场景中就用到了 IBM Tivoli Directory Server。

这个场景中的目标环境由下面这些部分组成：

  • Windows® 2000，内存 2GB。
  • 安装了 WebSphere Portal V5.02.1，并配置了数据库和 LDAP 服务器。该场景使用 IBM DB2® UDB V8.1 和 IBM Tivoli Directory Server V5.2（以下称为 Directory Server）。
  • 安装了 Access Manager V5.1，并用支持 LDAP 的服务器对其进行了配置（在我们的实例中，用的是 Directory Server）。

回页首

术语

深入研究 SSO 配置的详细情况之前，回顾一下本文中所用到的一些术语，如表 1 所示：

表 1.安全术语

术语定义
认证和 授权认证是验证用户身份的过程。授权是验证是否允许用户做他或她所请求的那些事情的过程。
LDAP 用户注册中心一种支持小型目录访问协议 (Lightweight Directory Access Protocol，LDAP) 的服务器，其中包含了关于用户和组的数据库，由 WebSphere Portal 和 Access Manager 共享。
Policy Server（以前称为 Management Server）Access Manager 的一个组件，为 Access Manager 安全域维护主授权数据库。该服务器处理访问控制、认证和授权请求。
WebSEAL一个 Web 逆向代理安全服务器。在产品配置中，该服务器位于 DMZ（非保护区）内部。所有的内部请求都必须通过 WebSEAL。
Web Portal Manager一个基于 Web 的图形用户界面，用于 Access Manager 管理。与 Access Manager V4 一起打包，需要 WebSphere Application Server，单服务器版本，带 Fixpack 2 的版本 4，或者上述那些。同样，与 Access Manager V5.1 一起打包，则需要 WebSphere Application Server V5.0.2。我们在 Application Server V5.0.2 上安装该 Web 应用程序。
pdadmin一个用于配置 Access Manager 的命令行实用工具，任何用 Web Portal Manager 可以配置的程序，用该工具也都可以配置。
WebSEAL 连接WebSEAL 服务器与终端 Web 服务器以及 Application Server 间的连接。终端服务器可以是另一台 WebSEAL 服务器，或者，更常见的是一台 Web 应用服务器。
加密 (SSL) 连接和 不加密连接利用 WebSEAL 连接创建命令的传输选项 ( -t )，可以将连接配置为加密或不加密：
  • -t SSL 创建加密连接
  • -t tcp 创建不加密连接
在加密连接中，WebSEAL 和联接终端服务器间的信息流被加密了。
信任关联拦截器 (TAI)一个能够集成 Application Server 认证和安全服务器的 Application Server 组件，例如 Tivoli WebSEAL。必须将 Application Server 配置为了解并且信任安全服务器。TAI 在 Application Server 和认证服务器（例如，WebSEAL）间建立信任。这是安全服务器提供的一个 Java™ 接口和实现。详细信息请参阅 WebSphere Application Server 信息中心。

Access Manager V5.1 包括一些附件组件，例如 Policy Proxy Server，在集成认证和 Application Server 时并不需要。有关这些组件的详细信息，请参阅 Access Manager 系统管理员指南。

现在，您已经理解这些术语了，我们再来看一下 Application Server 和 Access Manager 间的 SSO。

回页首

理解用户请求流

首先，看一下当用认证代理（例如 WebSEAL）配置 Application Server 时，对 Application Server 的用户请求流，图 1 显示了一个样本流。


图 1. 从 WebSEAL 到 Application Server 的用户请求流
图 1.从 WebSEAL 到 Application Server 的用户请求流 

图 1 中的数字涉及到下面这些流步骤：

  1. 用户请求受 WebSEAL 保护的资源，这个资源充当代理并拦截所有的请求。为了获得证书，WebSEAL 对用户进行提问，用户回答这些问题。
  2. WebSEAL 通过与它的 LDAP 用户注册中心进行协商来对用户进行认证。它还决定用户能否访问（也就是说，授权是否开放）请求的 URL。
  3. 如果认证成功，WebSEAL 利用已经为它配置好的连接将请求传送给 IBM HTTP Server。将从 WebSEAL 到 IBM HTTP Server 的连接配置为传递 HTTP 消息头中的 iv-user, iv-groups 信息。终端用户的身份必须传递给一个名为 iv-user的消息头中的 TAI，该消息头是 WebSEAL 插到 HTTP 请求消息头中的，HTTP 请求消息头是 WebSEAL 发送给 Application Server 的。虽然可以将 WebSEAL 配置为用其它的方法传递终端用户身份，但 iv-user 消息头是 TAI 支持的唯一消息头。终端用户的密码不在 HTTP 消息头中传送。
  4. Application Server 插件文件检查请求的 URL 的上下文根，确定目标 Application Server 或者进行复制，为完成任务继续执行请求。
  5. Application Server 中的 TAI（该 Application Server 必须启用 TAI）处理请求。TAI 处理成功后，Application Server 创建了一个名为 LTPA 令牌的加密用户认证 cookie。这个 cookie 存活的时间比较长（通常是两个小时），一直持续到用户会话结束，而且对每个用户的每次会话都是唯一的（也就是说，如果同一用户多次登录，每次他都能看见创建了不同的 cookie）。因此，TAI 不需要对每个用户请求进行处理。
  6. TAI 接受了终端用户身份，并创建了 LTPA 令牌之后，WebSphere Portal 依靠 LDAP 执行额外的查询，例如查询组信息。它从数据库中查询资源映射，然后显示门户页面。

回页首

SSO 配置选项

在 Access Manager 和 Application Server 间配置 SSO 有多种方法。在这一部分中，您将学习每个选项的优点和缺点。两种主要的设计选择是使用 TAI 和使用 LTPA。

选项 1：使用 TAI

您可以用两种方法配置 TAI 选项：使用信任用户或信任连接

使用信任用户配置 TAI 
在这个配置中，TAI 利用 Basic Authentication 消息头识别 WebSEAL 服务器。在 LDAP 内创建信任用户，用那个 userid 配置 TAI。 WebSEAL 只将密码（不是 userid）放在 Basic Authentication 消息头中。表示这是一个"共享秘密"，只有 TAI 和 WebSEAL 服务器知道。

运行的时候，TAI 检查密码，通过用户注册中心验证密码是否属于信任用户。这个过程使得 TAI 相信确实是 WebSEAL 服务器在表明终端用户的身份，因此 TAI 可以信任它。

要利用 Basic Authentication 消息头建立连接来识别 WebSEAL 服务器，在连接创建命令行上使用 -b supply 选项。然后，WebSEAL 利用密码构建 Basic Authentication 消息头，密码在 Webseald.conf 文件内指定（ basicauth-dummy-passwd 属性）。

连接可以加密或不加密，推荐对连接进行加密。在本文稍后描述的场景中，您将配置一个 WebSEAL 连接和 TAI。在 WebSEAL 中创建一个用户，用于将 WebSEAL 认证到 Application Server。这个用户的密码设置在 Webseald.conf 文件中。

使用信任连接配置 TAI 
在这个配置中，WebSEAL 服务器利用它自身的客户端证书将自己标识和认证到 Web 服务器。在本实例中，TAI 将不再进一步验证 WebSEAL 服务器。在 TAI 中使用下面这句话来进行配置：

com.ibm.websphere.security.WebSEAL.mutualSSL=true

设置 mutualSSL=true 时，TAI 利用主机名这个属性只验证 WebSEAL 主机，而不作进一步验证。它假设从 WebSEAL 到 Application Server 的连接是完全信任的，因此，需要用于认证的客户端证书。

这个设置需要一个 SSL 连接。您可以利用带客户证书的 SSL 设置加密连接，并指定证书标签。

用于 Application Server 的 Web 服务器必须有用于 WebSEAL 服务器的客户证书的签名证书。WebSEAL 服务器必须有用于 HTTP 服务器的服务器证书的签名证书。

为获得证书，必须将用于 Application Server 的 Web 服务器配置成向 WebSEAL 服务器提问。使用 pdadmin 命令行，您可以在单独的一行上输入恰当的命令。适当地替换< >间的变量。详细信息请参阅下一部分。

server task <Webseal_server_instance_name> create -t ssl -h  <web_server_hostname> -p port -j -w -K <certificate_label>  -c iv-user,iv-groups /<junction_name>

完成这些步骤后，您将已经从 WebSEAL 到 Web 服务器创建了一个信任链接。如果 Web 服务器和 Application Server 不在同一台机器上，您必须设置另一个从 Web 服务器到 Application Server 的信任链接。在这里，再次需要客户端证书和客户认证的 SSL。配置步骤在 WebSphere Application Server 信息中心有介绍。

决定使用哪种 TAI 配置 
现在，您知道了如何配置两种 TAI 选项——使用信任用户或信任连接——在决定使用哪种配置的时候需要考虑各自的优缺点。

两种 TAI 选项都为向 Application Server 认证 WebSEAL 提供了一个安全的方法。从向 Application Server WebSEAL TAI 表明身份的角度来看，任一种选项都没有明显超过另一种的优势。关键要记住的一点是如果使用密码，您必须确保注册中心内密码的安全，并对其进行管理，密码是 Application Server TAI 用于验证用的。同样，为了保护密码，从 WebSEAL 到 Application Server 的链接（通过 Web 服务器）应该通过 HTTPS 进行传输。

基于证书的认证方法避免了密码管理问题，但是也带来了管理客户端证书问题。从 WebSEAL 到 Application Server 的链接必须使用客户证书认证，同样的，从 Web 服务器到应用程序服务器的链接也必须使用客户证书认证。假设每个链接都不安全，TAI 仍将照常运行，但运行将不安全。这可能是证书方法的一个缺点，即使在配置中有一个人为错误，它看上去仍就在运行，但事实上，这个运行不安全。基于这个原因，我们在本文稍后的实例中从 WebSEAL 使用密码验证来配置 TAI。

也就是说，如果您的系统不仅仅在向 TAI 表明身份方面依赖于 WebSEAL，那么从 WebSEAL 到 Application Server 的密码验证可能还不够，理解这一点非常重要。例如，有些系统依靠 WebSEAL HTTP 消息头来制定安全策略。那些消息头没有通过 TAI 进行验证。因此，如果 Web 客户端直接向 Application Server 认证（绕过 WebSEAL），然后伪造 WebSEAL 消息头，那么那些消息头可能是假的。这个用户可能是一个有效的通过认证的用户（Application Server 将确保这一点），但是，通常 WebSEAL 提供的附加消息头可以直接由伪客户人为制造。因此，攻击者可能作为一个有效用户通过认证，然后提供一个 HTTP 消息头（可能为 iv-cred ），这个消息头表明他比实际上有更多的权限。这将是非常危险的。

总的来说，如果 WebSEAL 只用于向带 WebSEAL TAI 的 Application Server 表明用户身份，密码或相互 SSL 认证能很好地解决问题。相反，如果应用程序依靠 HTTP 消息头中额外信息保证安全，您应该采用相互 SSL 认证。

选项 2：使用 LTPA

使用这个选项，您不需要在 Application Server 中配置 TAI。相反，需要在 WebSEAL 中配置一个 LTPA 连接，Access Manager 发布 LTPA 令牌。参考下面的图 2。


图 2.用于 LTPA 连接的从 WebSEAL 到 Application Server 的请求流
图 2.用于 LTPA 连接的从 WebSEAL 到 Application Server 的请求流 

现在来看一下 LTPA 连接的请求流场景。下面的步骤号与图 2 中的行号相对应。

  1. 用户请求受 WebSEAL 保护的资源。为了获得证书，WebSEAL 向用户提问，用户回答问题。
  2. WebSEAL 通过与它的用户注册中心通话来认证用户。它还决定用户能否被授权打开请求的 URL。一旦终端用户认证成功， WebSEAL 将创建 LTPA 令牌 cookie。
  3. 利用已经配置的连接将请求传送到 IBM HTTP 服务器。将从 WebSEAL 到 IBM HTTP 服务器的连接配置为传送 iv-user, iv-groups 信息，LTPA 令牌在步骤 2 中创建，创建在 HTTP 消息头中。
  4. 请求被传送到适当的 Application Server 或被克隆，这取决于 Application Server 插件。
  5. 在 Application Server 中，没有启用 TAI，Application Server 获取消息头中的 LTPA 令牌。Application Server 只为这个用户创建会话 cookie，并假设这个用户已经被认证。WebSphere Portal 为组信息搜索 LDAP，从数据库中获取资源映射，然后显示门户页面。

本文没有进一步讨论 LTPA 的配置方法。有关这个配置的详细信息，请参阅 Access Manager 文档。

回页首

使用带信任用户的 TAI 配置 Access Manager

本文剩下的部分描述了一个场景，该场景显示了如何使用 带信任用户的 TAI配置 Access Manager，从而向 Application Server 提供 SSO。TAI 从 WebSEAL 接受基于密码的认证，而不是假设一个 SSL 信任连接。

这个方法指导您设置 TAI 的整个过程。参阅 参考资料获得有关具体任务的更多帮助，例如安装 Access Manager 或 WebSphere Portal。有关理解 WebSEAL 角色、加密或不加密连接以及关于使用 WebSEAL 连接命令选项的帮助，请参阅 WebSEAL 系统管理员指南。

该场景假设 IBM HTTP Server（以下称为 HTTP Server）是 Web 服务器。

步骤 1.安装和配置基本产品

首先，安装并配置 WebSphere Portal、DB2、LDAP 和 HTTP Server。从 WebSphere Portal V4 到 V5，安装程序简化了。V5 程序安装：

  • WebSphere Portal
  • WebSphere Application Server（包括 IBM HTTP Server）
  • IBM Cloudscape™ 数据库。

对于带信任用户的 TAI 环境，您需要：

  1. 安装 WebSphere Portal V5.0.2.1，利用 WebSphere Portal 提供的配置任务用 DB2 和 HTTP Server 对其进行配置。参阅 WebSphere Portal 信息中心可以获得关于这个步骤的帮助。
  2. 安装并配置 IBM Tivoli DIrectory Server V5.2。相关指导请参阅 IBM Tivoli Directory Server 安装文档。
  3. 创建 LDAP 后缀 dc=ibm,dc=com 。这里用到的 LDAP 是 Directory Server，应该这样配置：
    • LDAP Admin id： cn=root
    • Password： ldap
    • Suffix： dc=ibm,dc=com
    • User Search Base for WebSphere Portal： cn=users,dc=ibm,dc=com
    • User object class： inetOrgPerson
    • Group Search Base for WebSphere Portal： cn=groups,dc=ibm,dc=com
    • Group object class： groupOfUniqueNames
    • Portal Admin： uid=wpsadmin,cn=users,dc=ibm,dc=com
    • Portal Admin Group： cn=wpsadmins,cn=groups,dc=ibm,dc=com
    • Application Server 和 WebSphere Portal 的 LDAP Bind Id ： uid=wpsbind,cn=users,dc=ibm,dc=com
    从 下载部分将 portalusers.ldif 文件导入到您的 LDAP 中，创建 LDAP 目录树。 

  4. 为您的目录配置一个访问控制列表 (Access Control List，ACL)，让 wpsbind id 在后缀 dc=ibm,dc=com 下面能读取和搜索目录树。配置 ACL 是一个特定于目录的任务。有关配置 ACL 的详细信息，请参阅您所选的 LDAP 文档。 

    要为 Directory Server V5.x 配置 ACL，作为 cn=root 登录到基于浏览器的 Directory Server V5.x 管理控制台，采用如下的 URL 格式：
    http://<hostname>:<transport-port>/IDSWebApp/IDSjsp/Login.jsp


    例如：
    http://localhost:9080/IDSWebApp/IDSjsp/Login.jsp


  5. 转到 Directory management => Manage entries。选择后缀 dc=ibm,dc=com，然后单击 Edit ACL。 
    图 3.编辑 ACL
    图 3.编辑 ACL 
  6. 在左侧，单击 Non-filtered ACLs。选择 Propagate ACLs 复选框，允许没有明确定义 ACL 的后代能从这个条目中继承。输入 wpsbind 用户的专有名称 (distinguished name)： uid=wpsbind,cn=users,dc=ibm,dc=com 。
  7. 对于类型，选择 access-id，由于这个 DN 是一个用户，所以接下来选择 ADD。 
    图 4.为 wpsbind 用户添加 ACL
    图 4.为 wpsbind 用户添加 ACL 
    您将看见如图 5 所示的窗口。安全类部分为属性类定义了权限：
    • Normal属性，例如 commonName 属性，安全需要最低。
    • Sensitive属性，例如 homePhone，安全需要适中。
    • Critical属性，例如 userPassword，安全需要最高。
    • System属性是由服务器维护的只读属性。
    • Restricted属性用于定义访问控制。

    图 5.添加 ACL
    图 5.添加 ACL 
  8. 将读取和搜索设为 grant ，并比较安全类。将写安全类设为 deny。单击 OK，然后在下面的屏幕上再次单击 OK，保存您的修改。 
    图 6.保存您的修改
    图 6.保存您的修改 
  9. 要验证您刚才设置的 ACL，退出登录，通过输入您的全限定 DN，作为 wpsbind 登录到控制台。选择 Directory management，然后单击 Manage entries。选择后缀 dc=ibm,dc=com，然后单击 Expand，如图 7 所示。（注意dc=ibm,dc=com 后面的 "+" 标记。） 
    图 7.作为 wpsbind 登录
    图 7.作为 wpsbind 登录 

现在，您已经完成了用于 LDAP 的 wpsbind 用户的 ACL 配置。

接下来，将用 Directory Server 配置 WebSphere Portal。

  1. 将 wpsbind 作为用于 Application Server 和 WebSphere Portal 的 LDAP Bind ID。使用 SSO 域 ibm.com 。
  2. 要检验您的 WebSphere Portal Directory Server 配置，转到 WebSphere Portal 控制台，作为 wpsadmin 登录。例如：
    http://rhaalab1.raleigh.ibm.com/wps/myportal


  3. 检查您能否看见 Administration 标签。
  4. 作为 wpsbind 登录到 Application Server 管理控制台，并确保您可以登录。

步骤 2.安装 Access Manager 并用 LDAP 对其进行配置

在这一步中，首先安装 Tivoli Access Manager V5.1，并打上补丁 2（推荐）。或者，您也可以使用带 Fixpack 6 的 Access Manager V4.1。接下来，在 LDAP 服务器上，为 Access Manager 配置 Directory Server。最后，您需要配置 Access Manager 组件。这一部分完成后，您应该能够作为 sec_master 登录到 Access Manager Web Portal manager。

安装 Access Manager V5.1 

  1. 从 Access Manager Base 光盘安装 Access Manager Base 组件，然后打补丁 2。有关安装的详细指导，请参阅下面 参考资料中列出的 Access Manager 安装文档，
  2. 接下来，安装 Access Manager Web Portal Manager。
  3. 安装 Web Security 运行时和 WebSEAL。

向 LDAP 模式中添加 Access Manager 属性文件 
如果您使用的是 Directory Server V5.2，可以跳转到 创建 secAuthority 后缀。

Access Manager 要求向 LDAP 模式中添加特定的 LDAP 属性。这些属性通过 Directory Server V5.2 来添加。如果您使用的是 Directory Server V5.1，执行下面的步骤，使用 下载文件中的 V3.am 文件。

  1. 停止 IBM Directory Server 的服务。
  2. 从下载文件中将模式文件 V3.am.at 复制到目录服务器模式目录 <LDAP_INSTALL_DIRECTORY>\etc 下，LDAP_INSTALL_DIRECTORY 是 LDAP 的安装目录（默认情况下是 c:\Program Files\IBM\LDAP ）。
  3. 要在窗口中打开目录配置工具，选择 Start => Programs => IBM Directory Server V 5.1 => Directory Configuration。
  4. 在左侧面板中，单击 Manage schema files。在右侧面板中，选择带全路径的文件名到 VM.am.at 文件中。在模式验证规则中，确保选中了 Version 3 (Lenient)，然后单击 Add。
  5. 检查 V3.am.at 文件是否显示在当前模式文件列表中，然后单击 OK。 
    图 8.Directory Server V 5.1 配置工具
    图 8.Directory Server V 5.1 配置工具 

重要提示：为了提交修改，您必须单击 OK。

创建 secAuthority 后缀 
Access Manager 需要一个后缀来维护它的元数据。所需的后缀为 secAuthority=Default 。后缀专有名称对大小写不敏感。

  1. 要在窗口中打开目录配置工具，选择 Start => Programs => IBM Directory Server V5.2 => Directory Configuration。
  2. 在右侧面板中，单击 Manage suffixes。输入后缀 secAuthority=Default ，然后单击 Add。您将看见那个后缀已经位于右侧面板中的当前后缀专有名称列表中。 
    图 9.添加 secAuthority=default 后缀
    图 9.添加 secAuthority=default 后缀 
  3. 单击 OK。记住，只有单击了 OK之后，修改才被提交。否则，后缀将不会被添加。

添加一个容器存储 Access Manager GSO 数据 
接下来，在 LDAP 中您需要一个容器，这样 Access Manager 可以存储它的 Global Single Sign-on (GSO) 数据。从 下载文件中提取文件 c:\wpstam\tamgso.ldif 。

  1. 打开目录服务器配置工具（如果您还没有打开它），然后单击 Import LDIF data。
  2. 单击 Clear results。
  3. 浏览并选择文件 c:\wpstam\tamgso.ldif ，然后单击 Import，开始导入过程，如下所示。 
    图 10.导入 tamgso.ldif 文件
    图 10.导入 tamgso.ldif 文件 
    您将看见如图 11 所示的消息：
    ldif2db: 2 entries have been successfully added out of 2 attempted.


    图 11.成功导入 ldif 文件
    图 11.成功导入 ldif 文件 

或者，您也可以命令行来导入这个 ldif 文件。按下面的格式使用 ldapadd 命令：

ldapadd -D <LDAP ADMIN ID> -w <ldap _admin_password> -f <ldif_file_name>

例如：

ldapadd -D cn=root -w ldap -c -f "C:\wpstam\tamgso.ldif"


图 12.使用命令行添加 tamgso.ldif 文件
图 12.使用命令行添加 tamgso.ldif 文件 

您已经完成了 Access Manager 组件的 LDAP 配置。

设置 Access Manager 基本组件 
在 Access Manager 基本组件安装完成后，您需要对他们进行配置。在 Windows 上，使用 pdconfig 工具来配置组件：

  1. 打开命令提示符，键入 pdconfig ，将打开配置实用工具。
  2. 选择 Access Manager Runtime，然后单击 Configure。
  3. 选择 Registry 作为 LDAP，然后单击 Next。输入 LDAP 主机名和端口，在本实例中，主机名和端口分别为rhaalab3.raleigh.ibm.com 和 389 。
  4. 如果将 SSL 配置为与 LDAP 通信，请输入具体的端口。
  5. 如果需要启用 SSL，请参阅 Tivoli Access Manager Base Installation Guide中的 "Enabling Secure Sockets Layer"。
  6. 选择 Access Manager Policy Server，然后单击 Configure，如下所示。 
    图 13.配置 Configure Access Manager Policy Server
    图 13.配置 Configure Access Manager Policy Server 
  7. 在下面的屏幕上，输入 LDAP 系统管理员用户名和密码，然后单击 OK。
  8. 指定 sec_master 密码，然后单击 OK。
  9. 接受 Access Manager 的 SSL 连接参数默认值。您将看见 Configuring Access Manager Policy server ，然后出现下面的消息： 
    图 14.配置 Access Manager Policy Server 消息
    图 14.配置 Access Manager Policy Server 消息 
    Policy server 配置创建了一个默认的名为 pdcacert.b64 的 SSL 证书认证文件。对于 Access Manager 运行时系统，要认证到 Access Manager 服务器，每个运行时系统都需要复制一份这个文件。要获得这个文件，执行下面步骤中的任一步：
    • 在配置 Access Manager 运行时包的过程中（使用 pdconfig 实用工具），自动选择下载 pdcacert.b64 文件。
    • 在配置 Access Manager 运行时组件之前，手动将 pdcacert.b64 文件复制到 Access Manager 系统。 

  10. 接下来，选择 Authorization Server，然后单击 Configure，如图 15 所示。 
    图 15.配置 Access Manager Policy Server 消息
    图 15.配置 Access Manager Policy Server 消息 
  11. 指定域名。默认情况下为 Default ，这说明它是管理域。不要修改它。
  12. 选择 Next。 
    图 16.域应该是默认的
    图 16.域应该是默认的 
  13. 在下一个屏幕上输入 Policy Server 信息。Policy Server 主机名是它用来连接这台服务器的主机名。 Default 是本地系统主机名。Policy Server 端口是它监听请求的端口，默认情况下为 7135 。
  14. 单击 Next。
  15. 输入 sec_master 密码。不要修改 sec_master 的值。单击 Next。
  16. 在下一个对话框上，本地主机名指定认证服务器所在的主机的全限定名称。管理请求端口指定管理请求端口。默认端口是 7137 。认证请求端口指定认证请求端口号。默认端口号是 7136 。单击 OK。
  17. 应该成功完成了。

接下来，将配置用于 Application Server JRE 内部的 Java 运行时环境组件。

  1. 选择 Access Manager Java Runtime Environment，然后单击 Configure。
  2. 选择 Full配置类型，然后单击 Next。
  3. 指定和 IBM Application Server 一起安装的 JRE（例如： c:\WebSphere \AppServer \java \jre ），然后单击 Next。
  4. 指定 Policy Server 信息。
  5. 在通用登录屏幕上单击 Next，然后单击 Finish。您将看见一条消息显示配置完成。

接下来，进行 Access Manager WebSEAL 配置：

  1. 选择 Access Manager WebSEAL包，然后单击 Configure。 
    图 17. Access Manager WebSEAL 配置
    图 17. Access Manager WebSEAL 配置 
  2. 再次单击 Configure，配置一个新 WebSEAL 实例。 
    图 18.配置新 WebSEAL 实例
    图 18.配置新 WebSEAL 实例 
  3. 继续执行下面屏幕所显示的步骤，为 WebSEAL 实例输入名称，主机名以及监听端口，默认的监听端口为 7234 。将它的 HTTP 端口号设为 81 ，HTTPS 端口号设为 444 ，并设置一个文档根目录。
  4. 在配置实用工具上单击 Close。

要验证您是否在主机上安装了 Access Manager V5.1 组件（例如， RHAALAB2 ）：

  1. 打开命令提示符，键入 pdadmin 。
  2. 输入这些命令：
    Pdadmin > -a sec_master  <your password>  pdadmin sec_master> server list


    将提供给您新配置的 WebSEAL 实例。 

  3. 确保您可以访问： http://rhaalab2.raleigh.ibm.com:81 。
  4. 单击下面的链接，利用 https 重新访问页面。它应该为您重定向到您的页面： http://rhaalab2.raleigh.ibm.com:444。
  5. 检查您能否登录。

现在，您已经完成了对 Access Manager 的配置。

步骤 3.为 SSL 配置 HTTP 服务器

如果您正在设置 WebSEAL 连接来使用 SSL（我们推荐的方法），那么您必须执行该步骤，这样 HTTPS 通信就可以使用自签名（self-signed）证书。如果您使用的是 TCP 而不是 SSL 作为您的 WebSEAL 连接，那么跳过该步骤，转到 步骤 5。Web 服务器必须为 SSL 定义一个端口，通常使用 443。您将使用 IBM Key Management Utility——iKeyman 来生成自签名证书。

  1. 创建一个名为 c:\ihs\keytab 的目录。
  2. 选择 Start => Programs => IBM HTTP Server => Start Key Management Utility。
  3. 选择 Key Database File => New。输入下面的信息：
    • Key Database Type：CMS key database file
    • File Name： keyfile.kdb
    • Location： \ihs\keytab 如下所示。
  4. 单击 OK。 
    图 19.密钥文件
    图 19.密钥文件 
  5. 输入 test 作为密码。检查文本框 Set expiration time和 Stash password to a file。单击 OK。您将看到一条消息提示密码已经被加密并且保存在 c:\ihs\keytab\keyfile.sth 文件中。 
    图 20. HTTP 服务器密钥文件
    图 20. HTTP 服务器密钥文件 
  6. 选择 Create => New Self Signed Cert。输入 IHS 作为 Key Label。Common Name 默认为 hostname。单击 OK。 
    图 21.创建自签名证书
    图 21.创建自签名证书 
  7. 单击 Extract certificate 将证书提取到一个文件中。如下所示，输入 cert1.arm 作为 Certificate file name。单击 OK。 
    图 22. 将证书提取到文件中
    图 22.将证书提取到文件中 
  8. 现在，您已经将证书提取到 cert1.arm 文件中。退出 iKeyman 实用工具。
  9. 将下面的代码行添加到 <IHS_INSTALL_ROOT>\conf\httpd.conf 文件的末尾：
    Listen 443 LoadModule ibm_ssl_module modules/IBMModuleSSL128.dll 	<virtualhost *:443> 		SSLEnable 		Keyfile "C:\ihs\keytab\keyfile.kdb" 		SSLV2Timeout 100 		SSLV3Timeout 1000 	</virtualhost>


  10. 将本代码中的 * 替换为具体的虚拟主机。
  11. 停止并重新启动 HTTP 服务器。通过在 Web 浏览器上打开类似 https://yourserver.domain.com/ 的页面来检验它是否在监听端口 443。例如： https://rhaalab1.raleigh.ibm.com/ 。

您已经为 HTTP 服务器完成了 SSL 配置。

步骤 4.将证书加载到 WebSEAL 主存储器中

现在您需要将最后一步创建的证书加载到 WebSEAL 的主数据库中：

  1. 如果您的 HTTP 服务器与 WebSEAL 不在同一台机器上,那么将步骤 3 中的证书 c:\ihs\keytab\cert1.arm 从 HTTP 服务器上复制到 WebSEAL 所在机器的同一目录下。
  2. 在 WebSEAL 所在机器上启动 IBM Key Management Utility。
  3. 从菜单栏选择 Key Database File => Open。
  4. 将目录切换到 <Access Manager_Install_root>\PDWeb\www-default\certs ，并在 File name 框中输入 pdsrv.kdb 。这是 WebSEAL 用来为 SSL 连接存储可接受的 CA 证书的密钥环。输入 pdsrv 作为密码，然后单击 OK。
  5. 从下拉菜单中选择 Signer Certificates，然后单击 Add 按钮。 
    图 23.添加签名证书
    图 23.添加签名证书 
  6. 输入 cert1.arm 作为文件名，输入 c:\ihs\keytab\ 作为路径，如下所示。单击 OK。 
    图 24.从先前保存的文件中获取证书
    图 24.从先前保存的文件中获取证书 
  7. 输入 IHS 作为标签，然后单击 OK继续。
  8. 退出 IBM Key Management 实用工具。
  9. 停止并重新启动 Access Manager WebSEAL 服务。

您已经完成了将 HTTP 服务器证书导入到 WebSEAL 的主数据库中。

步骤 5.启用 HTTP 通信的转发

您需要配置 Application Server 插件，将 HTTPS 通信转发到应用服务器。要实现这一点，您需要更新 Application Server 的虚拟主机列表，使其包含正确的主机名称和端口号，并重新生成插件结构。为 ActiveX 控件和 Java Archive 文件添加 MIME 类型。WebSphere Portal Extend 的 Lotus 组件需要这些 MIME 类型。

  1. 在运行 Application Server 和 WebSphere Portal 的机器上，确保 server1 正在运行：https://rhaalab1.raleigh.ibm.com:9090/admin
  2. 使用 wpsbind id 和密码登陆到 Application Server 管理控制台。
  3. 在控制台的左侧面板中，选择 Environment => Virtual Hosts => default_host => Host Aliases => New。
  4. 为您在步骤 3 中添加到 Web 服务器的 hostname 和 SSL 端口添加一个主机别名。hostname 可能是 * 或者是一个全限定主机名。通常是 Web 服务器的主机名。单击 OK添加一个端口为 443 （HTTP 服务器的 SSL 端口）的虚拟主机。 
    图 25.在 Application Server 管理控制台中添加虚拟主机
    图 25.在 Application Server 管理控制台中添加虚拟主机 
  5. 单击 Save保存对配置所做的修改。
  6. 选择 Environment => Update Web Server Plugin，然后单击 OK更新插件。等待显示 Plugin update successful 消息。
  7. 如果 Web 服务器在另一台机器上，将 plugin-cfg.xml 文件复制到 Web 服务器上。（有关 Application Server 虚拟主机功能的完整的介绍，请参阅它的文档。）
  8. 检查您能否访问 snoop： https://rhaalab1.raleigh.ibm.com/snoop 。
  9. 要添加一个 MIME Type，选择 Environment => Virtual Hosts => default_host => MIME Types => New。输入如下值：
    • Mime Type: application/java-archive
    • Extensions: jar
  10. 单击 OK，然后将您的修改保存到主配置。

您已经完成了添加虚拟主机和 MIME 类型的操作。现在，为 SSL 配置 WebSphere Portal。

  1. 如下所示，编辑 <WP_ROOT>\shared\app\config\services\ConfigService.properties 文件：（443 是 HTTP 服务器的 SSL 端口）
    redirect.logout.ssl = true redirect.login.ssl = true	 redirect.logout.url = https://<webseal-host-name>:<webseal- port>/pkmslogout host.port.https = 443


  2. 保存并关闭该文件。

步骤 6.在 Access Manager 中创建信任用户帐号

在该场景中，这个用户的专有名称为： uid=taiuser,cn=trustedusers,dc=ibm,dc=com 。这是 WebSEAL 用来向 Application Server 表明它自身所使用的用户 ID 和密码。为防止潜在的攻击，不要使用 sec_master 或者 <wpsadmin> 用户作为信任用户帐号。信任用户帐号应该只提供给 TAI。这个 taiuser 的专有名称必须位于 Application Server 能够在上面检索的 Directory Information Tree 中。例如， dc=ibm,dc=com 。

  1. 从 下载文件中导入 portalusers.ldif 文件，在 LDAP 中创建 taiuser。您可以使用 LDAP 配置实用工具，或者您也可以使用 ldapadd 或 ldapmodify 来添加用户。
    ldapadd -D cn=root -w ldap -f <full path to portalusers.ldif>


  2. 确保已经在 Directory Server 中创建了taiuser。
  3. 接下来，登录到 pdadmin ，执行如下的命令，将 taiuser 导入到 Access Manager 中：
    pdadmin sec_master> user import taiuser uid=taiuser,cn=trustedusers,     dc=ibm,dc=com pdadmin sec_master> user modify taiuser account-valid yes pdadmin sec_master> user modify taiuser password-valid yes pdadmin sec_master> user list * 10


    最后一行应该在它的输出信息中提供 taiuser。现在 TAM 已经能够识别 taiuser 了。

您已经创建了 taiuser 并将其导入到 Access Manager 中。

步骤 7.配置到 HTTP 服务器的 WebSEAL 连接

接下来，配置一个从 WebSEAL 服务器到 Web 服务器的 WebSEAL 连接。在 WebSEAL 所在的机器上进行配置（在该场景中，WebSEAL 所在的机器指的是 RHAALAB2 ）。

  1. 在 WebSEAL 所在的机器上，使用 pdadmin 命令行创建一个 WebSEAL 连接。输入如下命令（同时参阅图 26 ）：
    pdadmin -a sec_master  <your paassword> server list    server task <WebSEAL-instance-name> create -t ssl -h  <webserver_host> -p <SSL port> -j -w -b supply -c iv- user,iv-groups -f /ssl1 server task <webseal-instance-name> list


    服务器列表命令为您提供了一个 WebSEAL 实例列表。 <SSL port> 是您的 Web 服务器的端口号，在本实例中为 443。 
    图 26.创建 WebSEAL 连接
    图 26.创建 WebSEAL 连接 
  2. 继续下一步前先检查下面的 URL：
    • WebSEAL 主页： https://rhaalab2.raleigh.ibm.com:444
    • HTTP 服务器主页： https://rhaalab1.raleigh.ibm.com/
    • 通过 WebSEAL 连接的 HTTP 服务器（应该显示 HTTP 服务器主页）：https://rhaalab2.raleigh.ibm.com:444/ssl1
  3. 要启用 Junction to Request Mapping Table (JMT) 功能，定义一个 ASCII 文本文件，命明为 jmt.conf 。在 jmt.conf 文件中数据条目的格式由连接名称、一个空格和资源定位模式组成。您可以使用通配符来表示资源定位模式。在配置文件的 [junction] 这一节中指定该文件的存放位置：
    <Access Manager_install_root>/PDWeb/etc/webseald-default.conf


    例如：
    jmt-map = lib/jmt.conf


    这段语句表示 jmt.conf 位于： <Access Manager_install_root>/PDweb/www-default/lib/ 这个目录下。在 jmt.conf文件中输入如下内容： /ssl1 /wps/* :
  4. 将数据添加到文件中后，使用 jmt load 命令来 "加载" 数据，这样 WebSEAL 就能够识别新的信息。 
    图 27.创建 WebSEAL 连接
    图 27.创建 WebSEAL 连接 

您已经完成了连接的创建并创建和装载了一个 jmt。

步骤 8.编辑 webseald.conf 文件

在这一步中，您将编辑 WebSEAL 配置文件来配置一些超时和虚假密码问题，这些假密码可能在 HTTP 消息头中传输。

  1. 打开文件： <Access Manager_install_root>/PDWeb/etc/webseald-default.conf .
  2. 在 [junction] 这一节中，将 basic-auth-dummy-password 改为 taiuser 的用户密码：
    basicauth-dummy-passwd = taiuser1


    在同一节中，修改下面语句：
    • http-timeout = 300
    • https-timeout = 300
  3. 在 [forms] 这一节中，利用这个格式来启用 WebSEAL 认证： forms-auth = https
  4. 在 [script-filtering] 这一节中，设置： script-filter = yes
  5. 因为您使用的是基于窗体的认证，而不是基本认证，所以将 ba-auth 从 https 改为 none ：
    ba-auth = none


  6. 停止 WebSEAL 服务器，再启动它。

步骤 9.将 WebSphere Portal 用户和组导入到 WebSEAL 中

在这一步中，您将使用 pdadmin 实用工具将 WebSphere Portal 用户和组导入到 WebSEAL 中。

用 sec_master 登录到 pdadmin。使用下面这些命令导入 wpsadmin 和 wpsbind 用户：

pdadmin sec_master> user import wpsadmin uid=wpsadmin,cn=users,dc=ibm,dc=com pdadmin sec_master> user modify wpsadmin account-valid yes pdadmin sec_master> user modify wpsadmin password-valid yes pdadmin sec_master> user import wpsbind uid=wpsbind,cn=users,dc=ibm,dc=com pdadmin sec_master> user modify wpsbind password-valid yes pdadmin sec_master> user modify wpsbind account-valid yes pdadmin sec_master>


图 28.将用户和组导入到 WebSEAL 中
图 28.将用户和组导入到 WebSEAL 中 

步骤 10.在 Application Server 中配置 TAI

现在，为了用 Application Server 启用 SSO，在 Application Server 中配置 WebSEAL TAI：

  1. 登录到 Application Server 管理控制台。例如，在 Web 浏览器中打开：https://rhaalab1.raleigh.ibm.com:9090/admin 。
  2. 导航到 Security => Authentication mechanism => LTPA => Trust Association，然后单击 Enable。
  3. 在附加属性下单击 Interceptors。拦截器的类名称为：com.ibm.ws.security.web.WebSealTrustAssociationInterceptor 。
  4. 单击 Custom properties，然后添加表 2 中列出的属性。象该表中列出的那样正确复制属性名称。注意那些值和用 { } 围起来的说明，看那些值是否适合您的环境。

    表 2.自定义属性 

    名称值
    com.ibm.websphere.security.trustassociation.typeswebseal
    com.ibm.websphere.security.webseal.hostnamesRHAALAB2 
    {在完全相同的实例中，这里需要输入"主机名"命令的输出。该字段对大小写敏感。它不是全限定主机名。您可以输入逗号将主机名列表分开。}
    com.ibm.websphere.security.webseal.idiv-user 
    {这是 WebSEAL 在请求 Application Server 时发送的消息头字段。它告诉 TAI 将哪个字段用于终端用户身份。}
    com.ibm.websphere.security.webseal.loginIdtaiuser 
    {这个 id 的密码存于 WebSEALd.conf 文件的 basicauth-dummy-passwd 属性中。}
    com.ibm.websphere.security.webseal.ports444 
    {这是 WebSEAL 主机的端口号，也是在请求消息头中所期望的。包括任何代理端口。如果com.ibm.websphere.security.WebSEAL.ignoreProxy 的值被设为 true，那么从 WebSEAL 主机名中添加端口号，但是忽略任何代理端口。}
    com.ibm.websphere.security.WebSEAL.mutualSSL可选 
    {默认情况下，该值被设为 false。如果您使用带客户证书的 SSL 创建连接来将 WebSEAL 服务器识别到 TAI，该值应该设为 true。否则，该值应该设为 false。如果该值为 true，TAI 不用进行进一步验证。结果，由于 TAI 是由相互认证的 SSL 连接建立的，它只信任 WebSEAL 所在的机器的身份。}
    com.ibm.websphere.security.WebSEAL.ignoreProxy可选 
    {当包含代理时，设置该值为 true。当把该值设为 true 或 yes，它会告诉 Access Manager 让其忽略代理信息（主机名和端口）。默认情况下，该属性被设为 false。如果不包含代理，这个选项设为什么都没有关系。}

  5. 将您的设置与下面图 29 中所示的设置对比。重要提示：主机名对大小写敏感，为了与我们用于测试的名称相匹配，在这个场景中，主机名 RHAALAB2 全部是大写字母。您可以混合使用或用小写字母作为您实际的主机名。
  6. 保存配置 
    图 29.自定义属性
    图 29.自定义属性 
  7. 保存配置，退出 Application Server 管理控制台。删除下面这个目录下预编译的 JSP 文件： <Application Server_ROOT>/temp/<nondename>/WebSphere_Portal
  8. 删除预编译的类后重新启动 WebSphere Portal。检查 <WebSphere Portal_HOME>/log/SystemOut.log 文件中的下列消息。这些消息表示 TAI 加载成功：
    TrustAssociat A SECJ0121I: Trust Association Init class  com.ibm.ws.security.web.WebSealTrustAssociationInterceptor loaded  successfully [6/2/04 14:28:09:685 EDT] 4de6fe46 WebSealTrustA W SECJ0225W: PD  Authentication disabled. [6/2/04 14:28:09:695 EDT] 4de6fe46 TrustAssociat A SECJ0122I:  Trust Association Init Interceptor signature: WebSeal Interceptor  Version 1.1


  9. 检查您能否通过下面的 URL 获得 SSO： https://rhaalab2.raleigh.ibm.com:444/ssl1/wps/myportal .
  10. 作为 wpsadmin 登录到 Access Manager，检查您是否能获得 Administration 标签。

恭喜！您已经成功配置了 Access Manager 和 WebSphere Portal 间的 SSO。

加快配置步骤

现在，您已经成功配置了 Access Manager 和 WebSphere Portal 间的 Web SSO，还考虑了一些附加的要素。当 SSO 运行的时候，您可能还想涉及到一些有趣的边缘问题来创建一个特殊的用户实例。并不推荐作这些修改，这里只列出顾客对 Access Manager 和 WebSphere Portal 所做的常用的一些修改，把他们作为配置 SSO 的一部分。您需要决定在您的环境中，这些修改是否恰当或有必要。

删除原来的登录页面 
现在，您已经配置了 Access Manager，如果用户单击 WebSphere Portal 登录图标，他或她将被发送到受 Access Manager 保护的入口页面，接下来会导致 Access Manager 将其直接认证到 Portal。但是，原来的登录页面（如果您的主题只有一个登录页面）仍在那里。如果页面确实被触发，用户可以直接输入登录 URL。象 wps/portal/.scr/Login 这样。

为防止发生这种情况，您只需简单地删除您的主题的登录页面。如果您使用的是默认的主题，您首先需要备份该文件，然后删除 Login.jsp ，该文件位于： <AppServ_HOME>\installedApps\<nodename>\wps.ear\wps.war\screens\html 目录下。

修改退出动作 
您可能还需要修改退出动作。对用户来说，首选和默认动作是退出 WebSphere Portal，但是仍保留他们的 Access Manager SSO 证书。毕竟，Access Manager 是一个企业 SSO 产品，可能不只是给 WebSphere Portal 提供 SSO。但是，有些情况下，当用户退出 WebSphere Portal 时，您可能需要优先考虑这一点，同时他们的 Access Manager 证书也被破坏了。如果您想保留这个动作，执行下列步骤：

  1. 在： <WP_ROOT>/shared/app/config/services/ConfigService 这个目录下备份 ConfigService.properties 文件。
  2. 如下所示，编辑文件：
    redirect.logout= true redirect.logout.ssl=false or true, depending on your environment redirect.logout.url=<protocol>://<host_name>/pkmslogout

    where:
    • <protocol> 是 WebSEAL 机器的协议（ http 或 https ）。
    • <host_name> 是全限定 WebSEAL URL。
    redirect.logout.url 的值必须显示在单独的一行上。

在 WebSphere Portal 中禁用用户创建 
因为 Access Manager 负责管理用户，所以您应该确保用户不是通过 WebSphere Portal 创建的。由于这些用户不具备访问 Access Manager 的权限，所以您应该不允许有这样的操作，除非您通过 Access Manager 管理工具，将他们作为 Access Manager 用户手动导入。WebSphere Portal 在目录下自动创建条目有两种方法：从管理方面，使用 Manage Users 和 Groups portlet，或者能够自注册（self-register）的用户。要防止发生这种情况，您可以从它的页面中移除 Manage Users 和 Groups portlet。要从 ToolBarInclude.jsp 文件中移除自注册：

  1. 备份每一主题子目录中的 <Application Server_ROOT>/installedApps/<hostname>/wps.ear/wps.war/themes/html/<theme_name>ToolBarInclude.jsp 文件，然后在下一步中编辑该文件。
  2. 在文本编辑器中打开文件，将登记按钮注释掉，如下所示：
    <!-- <%-- enroll button --%> <wps:if loggedIn="no">   <%     String dt =  com.ibm.wps.puma.UserManager.instance().getDirectoryType();     if (dt==null)       {        dt = "";       }     if (!dt.equals("SSPM"))       {   %>   <td class="wpsToolBar" valign="middle"  align="<%=bidiAlignRight%>"  nowrap>     <a class="wpsToolBarLink" href='<wps:url  command="PrepareEnrollment" home="public"  reqid="no"/>'><wps:text   key="link.enrollment"  bundle="nls.engine"/></a>   </td>   <%     }                 %> </wps:if> -->


  3. 通过移除目录： <Application Server_ROOT>/temp/<node_name>/WebSphere_Portal/ 下的内容，从 WebSphere Application Server 高速缓存中删除已经编译过的 JSP 文件。

回页首

故障诊断

  1. 测试 Web 服务器：
    http://rhaalab1.raleigh.ibm.com https://rhaalab1.raleigh.ibm.com


    如果您无法连接到其中任何一个，那么停止您的 Web 服务器，并重新启动它。如果您的服务器没有监听端口 80 或 443，那么检查您是否使用了端口号。
  2. 检查端口的 Web 服务器的配置文件 —— httpd.conf 文件。查找端口 80，检查是否监听了这个端口。查找端口 443 并检查语法。如果不能肯定，那么将 SSL 片断注释掉，并重新启动 Web 服务器。
  3. 查看 Web 服务器文档以获取详细信息。在您进行下一步前，Web 服务器应该与 SSL 一起工作得很好，并且您应该验证那两个 URL （上文中提到的）是否都能够显示 Web 服务器主页。
  4. 在不使用 WebSEAL 的情况下测试 Snoop。强力推荐：在故障诊断中设法让 snoop 运行。首先检查在不使用 WebSEAL 和 SSL 的情况下，能否访问 snoop：
    http://rhaalab1.raleigh.ibm.com/snoop


    如果不能访问，检查 Application Server 管理控制台中的虚拟主机条目，确保已经为 Web 服务器的 http 端口定义了虚拟主机。确信在不使用 SSL 的情况下，您能够从您的 Web 服务器访问 snoop。
  5. 现在，试图通过 Web 服务器 https 访问 snoop：
    https://rhaalab1.raleigh.ibm.com/snoop


    如果不能访问，检查 Application Server 管理控制台中的虚拟主机条目，确保已经为 Web 服务器的 SSL 端口定义了虚拟主机。打开 httpd.conf 文件检查 SSL 端口，然后检查 SSL 端口的 Application Server Admin Virtual 主机和主机。如果端口不是 443，不用忘记使用这个端口。
  6. 如果您仍然不能从 Web 服务器访问 snoop，那么停止您机器上所有的 Jave 进程。清除WebSphere/AppServer/logs/server1 目录下的日志文件。启动 server1： WebSphere/AppServer/bin/startServer server1 。通过终端的 open for e-business 消息检查 WebSphere/AppServer/logs/server1/tracefile ，确保服务器已经启动。
  7. 如果出现错误，检查 default_host 的虚拟主机别名。检查 default_host 是否为 SSL 端口和非 SSL 端口设置了条目。如果您需要添加端口，确保保存配置的更改。
  8. 重新生成插件文件。停止并重新启动 server 1，同时停止并重新启动 Web 服务器。如果您的 Web 服务器不在同一台机器上，那么复制 plugin-cfg.xml 文件。在进行下一步前，确保您能够通过https://rhaalab1.raleigh.ibm.com/snoop 访问 snoop。
  9. 验证 WebSEAL： https://rhaalab2.raleigh.ibm.com:444/ 。
  10. 通过 WebSEAL 验证 Web 服务器： https://rhaalab2.raleigh.ibm.com:444/ssl1 。您应该能访问 Web 服务器的主页。如果您不能访问，那么有可能是连接的问题。再次使用 server task create 命令创建一个连接，使用 -f 强制生成一个新连接。
  11. 利用 WebSEAL 验证 snoop： https://rhaalab2.raleigh.ibm.com/ssl1/snoop 。
  12. 单点登陆没有出现：这是 TAI 配置的常见错误。尝试访问 https://rhaalab2.raleigh.ibm.com/ssl1/snoop 。在 Access Manager 表单中输入 wpsadmin 用户名和密码。如果 WebSphere Portal 关于用户名和密码向您提问，那么表示 SSO 没有出现。这时候，您应该按照给定的顺序执行如下操作：
    • 检查是否加载了 TAI 类。在 c:\WebSphere\AppServer\logs\server1\SystemOut.log 中搜索如下格式的消息：
      TrustAssociat A SECJ0121I: Trust Association Init class  com.ibm.ws.security.web.WebSealTrustAssociationInterceptor loaded  successfully [6/2/04 14:28:09:685 EDT] 4de6fe46 WebSealTrustA W SECJ0225W: PD  Authentication disabled. [6/2/04 14:28:09:695 EDT] 4de6fe46 TrustAssociat A SECJ0122I: Trust  Association Init Interceptor signature: WebSeal Interceptor Version 1.1


    • 如果没有出现，那么检查 Application Server 管理员控制台，看是否选中了 Trust Association复选框，然后单击 Apply，单击 OK，然后保存。同时检查自定义条目。检查 步骤 10.在 Application Server 中配置 TAI。
  13. 如果您加载了 TAI 类并执行了上述所有步骤，但是您看不见单点登陆，那么您需要启用 TAI 跟踪：
    • 转到管理控制台： http://rhaalab1.raleigh.ibm.com:9090/admin ，作为 wpsbind 登陆。
    • 转到 Troubleshooting => Logs and Trace => server1（如果您正在排除 snoop 故障）或WebSphere_Portal（如果您正在排除 WP => Diagnostic Trace故障）。检查 Enable trace。
    • 为跟踪规范输入如下内容： com.ibm.ws.security.*=all=enabled:com.ibm.ejs.security.*=all=enabled 
      图 30.诊断跟踪服务
      图 30.诊断跟踪服务 
    • 单击 Apply，然后单击 OK，保存。退出。
  14. 再测试一次。现在看一下您的跟踪文件。按下面的格式查找消息的 WebSEALTrust 关键字：
    [10/16/03 21:11:05:502 EDT] 442f8f56 WebSEALTrustA d  isTargetInterceptor: VIA=HTTP/1.1 RHAALAB2:443 [10/16/03 21:11:05:502 EDT] 442f8f56 WebSEALTrustA > checkVia for  RHAALAB2:443 [10/16/03 21:11:05:502 EDT] 442f8f56 WebSEALTrustA < getCheckID:   -1               [10/16/03 21:11:05:502 EDT] 442f8f56 WebSEALTrustA d Host and port:  rhaalab2:443 is not trusted.


  15. 如果出现的错误类型标记为粗体，那么您需要更新 com.ibm.websphere.security.WebSEAL.hostnames ，从而列出从 Access Manager 作为 VIA 关键字发送的主机名称。 com.ibm.websphere.security.WebSEAL.hostnames 文件中应该有RHAALAB2 （注意区分大小写）。我们的主机名称用的都是大写字母。检查您的主机名称大小写是否正确，在 Application Server 管理控制台上正确的将其输入到 TAI 属性中。
  16. 如果您收到消息： No or Bad LTPA ，那么重新生成 keys。登录到管理控制台，然后选择 Security => Authentication mechanism => LTPA => Generate Keys，单击 Save。有关详细信息，请参阅 WebSphere Application Server 信息中心。
  17. 单点登陆域：在 Application Server 管理控制台上检查 SSO 域。如果您使用 Web 服务器的 IP 地址，那么它有可能不工作。

回页首

结束语

本文讨论了配置 TAI 以集成 Tivoli Access Manager 和 WebSphere Portal 来进行身份验证的几种不同方法。同时您还学习了在集成 Access Manager 和 Application Server 时可能出现的潜在的错误配置问题。经历了配置 WebSphere Portal 的整个过程。用 Directory Server 配置各种 Access Manager 组件。使用 Access Manager 配置 WebSphere Portal 和 Application Server 来进行身份验证。并且您还学会了如何对您的拓扑结构中大部分的组件进行系统故障诊断。


回页首

下载

名字大小下载方法
password-authentication-samples.zip3 KBHTTP

关于下载方法的信息


参考资料

作者简介

Irina Singh是 IBM 软件服务部 WebSphere 方面的顾问。她在体系结构和实现软件应用程序方面有八年多经验。最近，她着重研究门户及其相关技术、体系结构和实现方面。她拥有位于坎普尔的印度技术研究院 (IIT) 电子工程学士学位。

Keys Botzum是 IBM 软件服务部 WebSphere 方面的高级顾问。Keys 在大规模分布式系统设计方面有十多年经验，并且专攻安全性问题。他使用过各种分布式技术，包括 Sun RPC、DCE、CORBA、AFS 和 DFS。最近，他着重研究 J2EE 及其相关技术。他拥有斯坦福大学计算机科学硕士学位和卡内基梅隆大学应用数学/计算机科学学士学位。他还与人合著了 IBM WebSphere：部署和高级配置。可以在 www.keysbotzum.com和 IBM developerWorks WebSphere上找到 Keys Botzum 的相关文章和介绍。

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/jjkv3/p/2584640.html