|
引言
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)。
回页首
理解用户请求流
首先,看一下当用认证代理(例如 WebSEAL)配置 Application Server 时,对 Application Server 的用户请求流,图 1 显示了一个样本流。
图 1. 从 WebSEAL 到 Application Server 的用户请求流
图 1 中的数字涉及到下面这些流步骤:
- 用户请求受 WebSEAL 保护的资源,这个资源充当代理并拦截所有的请求。为了获得证书,WebSEAL 对用户进行提问,用户回答这些问题。
- WebSEAL 通过与它的 LDAP 用户注册中心进行协商来对用户进行认证。它还决定用户能否访问(也就是说,授权是否开放)请求的 URL。
- 如果认证成功,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 消息头中传送。
- Application Server 插件文件检查请求的 URL 的上下文根,确定目标 Application Server 或者进行复制,为完成任务继续执行请求。
- Application Server 中的 TAI(该 Application Server 必须启用 TAI)处理请求。TAI 处理成功后,Application Server 创建了一个名为 LTPA 令牌的加密用户认证 cookie。这个 cookie 存活的时间比较长(通常是两个小时),一直持续到用户会话结束,而且对每个用户的每次会话都是唯一的(也就是说,如果同一用户多次登录,每次他都能看见创建了不同的 cookie)。因此,TAI 不需要对每个用户请求进行处理。
- TAI 接受了终端用户身份,并创建了 LTPA 令牌之后,WebSphere Portal 依靠 LDAP 执行额外的查询,例如查询组信息。它从数据库中查询资源映射,然后显示门户页面。
回页首
使用带信任用户的 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 环境,您需要:
- 安装 WebSphere Portal V5.0.2.1,利用 WebSphere Portal 提供的配置任务用 DB2 和 HTTP Server 对其进行配置。参阅 WebSphere Portal 信息中心可以获得关于这个步骤的帮助。
- 安装并配置 IBM Tivoli DIrectory Server V5.2。相关指导请参阅 IBM Tivoli Directory Server 安装文档。
- 创建 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 目录树。
- 为您的目录配置一个访问控制列表 (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 |
- 转到 Directory management => Manage entries。选择后缀 dc=ibm,dc=com,然后单击 Edit ACL。
图 3.编辑 ACL
- 在左侧,单击 Non-filtered ACLs。选择 Propagate ACLs 复选框,允许没有明确定义 ACL 的后代能从这个条目中继承。输入 wpsbind 用户的专有名称 (distinguished name): uid=wpsbind,cn=users,dc=ibm,dc=com 。
- 对于类型,选择 access-id,由于这个 DN 是一个用户,所以接下来选择 ADD。
图 4.为 wpsbind 用户添加 ACL
您将看见如图 5 所示的窗口。安全类部分为属性类定义了权限:
- Normal属性,例如 commonName 属性,安全需要最低。
- Sensitive属性,例如 homePhone,安全需要适中。
- Critical属性,例如 userPassword,安全需要最高。
- System属性是由服务器维护的只读属性。
- Restricted属性用于定义访问控制。
图 5.添加 ACL
- 将读取和搜索设为 grant ,并比较安全类。将写安全类设为 deny。单击 OK,然后在下面的屏幕上再次单击 OK,保存您的修改。
图 6.保存您的修改
- 要验证您刚才设置的 ACL,退出登录,通过输入您的全限定 DN,作为 wpsbind 登录到控制台。选择 Directory management,然后单击 Manage entries。选择后缀 dc=ibm,dc=com,然后单击 Expand,如图 7 所示。(注意dc=ibm,dc=com 后面的 "+" 标记。)
图 7.作为 wpsbind 登录
现在,您已经完成了用于 LDAP 的 wpsbind 用户的 ACL 配置。
接下来,将用 Directory Server 配置 WebSphere Portal。
- 将 wpsbind 作为用于 Application Server 和 WebSphere Portal 的 LDAP Bind ID。使用 SSO 域 ibm.com 。
- 要检验您的 WebSphere Portal Directory Server 配置,转到 WebSphere Portal 控制台,作为 wpsadmin 登录。例如:
http://rhaalab1.raleigh.ibm.com/wps/myportal |
- 检查您能否看见 Administration 标签。
- 作为 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
- 从 Access Manager Base 光盘安装 Access Manager Base 组件,然后打补丁 2。有关安装的详细指导,请参阅下面 参考资料中列出的 Access Manager 安装文档,
- 接下来,安装 Access Manager Web Portal Manager。
- 安装 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 文件。
- 停止 IBM Directory Server 的服务。
- 从下载文件中将模式文件 V3.am.at 复制到目录服务器模式目录 <LDAP_INSTALL_DIRECTORY>\etc 下,LDAP_INSTALL_DIRECTORY 是 LDAP 的安装目录(默认情况下是 c:\Program Files\IBM\LDAP )。
- 要在窗口中打开目录配置工具,选择 Start => Programs => IBM Directory Server V 5.1 => Directory Configuration。
- 在左侧面板中,单击 Manage schema files。在右侧面板中,选择带全路径的文件名到 VM.am.at 文件中。在模式验证规则中,确保选中了 Version 3 (Lenient),然后单击 Add。
- 检查 V3.am.at 文件是否显示在当前模式文件列表中,然后单击 OK。
图 8.Directory Server V 5.1 配置工具
重要提示:为了提交修改,您必须单击 OK。
创建 secAuthority 后缀
Access Manager 需要一个后缀来维护它的元数据。所需的后缀为 secAuthority=Default 。后缀专有名称对大小写不敏感。
- 要在窗口中打开目录配置工具,选择 Start => Programs => IBM Directory Server V5.2 => Directory Configuration。
- 在右侧面板中,单击 Manage suffixes。输入后缀 secAuthority=Default ,然后单击 Add。您将看见那个后缀已经位于右侧面板中的当前后缀专有名称列表中。
图 9.添加 secAuthority=default 后缀
- 单击 OK。记住,只有单击了 OK之后,修改才被提交。否则,后缀将不会被添加。
添加一个容器存储 Access Manager GSO 数据
接下来,在 LDAP 中您需要一个容器,这样 Access Manager 可以存储它的 Global Single Sign-on (GSO) 数据。从 下载文件中提取文件 c:\wpstam\tamgso.ldif 。
- 打开目录服务器配置工具(如果您还没有打开它),然后单击 Import LDIF data。
- 单击 Clear results。
- 浏览并选择文件 c:\wpstam\tamgso.ldif ,然后单击 Import,开始导入过程,如下所示。
图 10.导入 tamgso.ldif 文件
您将看见如图 11 所示的消息:ldif2db: 2 entries have been successfully added out of 2 attempted. |
图 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 文件
您已经完成了 Access Manager 组件的 LDAP 配置。
设置 Access Manager 基本组件
在 Access Manager 基本组件安装完成后,您需要对他们进行配置。在 Windows 上,使用 pdconfig 工具来配置组件:
- 打开命令提示符,键入 pdconfig ,将打开配置实用工具。
- 选择 Access Manager Runtime,然后单击 Configure。
- 选择 Registry 作为 LDAP,然后单击 Next。输入 LDAP 主机名和端口,在本实例中,主机名和端口分别为rhaalab3.raleigh.ibm.com 和 389 。
- 如果将 SSL 配置为与 LDAP 通信,请输入具体的端口。
- 如果需要启用 SSL,请参阅 Tivoli Access Manager Base Installation Guide中的 "Enabling Secure Sockets Layer"。
- 选择 Access Manager Policy Server,然后单击 Configure,如下所示。
图 13.配置 Configure Access Manager Policy Server
- 在下面的屏幕上,输入 LDAP 系统管理员用户名和密码,然后单击 OK。
- 指定 sec_master 密码,然后单击 OK。
- 接受 Access Manager 的 SSL 连接参数默认值。您将看见 Configuring 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 系统。
- 接下来,选择 Authorization Server,然后单击 Configure,如图 15 所示。
图 15.配置 Access Manager Policy Server 消息
- 指定域名。默认情况下为 Default ,这说明它是管理域。不要修改它。
- 选择 Next。
图 16.域应该是默认的
- 在下一个屏幕上输入 Policy Server 信息。Policy Server 主机名是它用来连接这台服务器的主机名。 Default 是本地系统主机名。Policy Server 端口是它监听请求的端口,默认情况下为 7135 。
- 单击 Next。
- 输入 sec_master 密码。不要修改 sec_master 的值。单击 Next。
- 在下一个对话框上,本地主机名指定认证服务器所在的主机的全限定名称。管理请求端口指定管理请求端口。默认端口是 7137 。认证请求端口指定认证请求端口号。默认端口号是 7136 。单击 OK。
- 应该成功完成了。
接下来,将配置用于 Application Server JRE 内部的 Java 运行时环境组件。
- 选择 Access Manager Java Runtime Environment,然后单击 Configure。
- 选择 Full配置类型,然后单击 Next。
- 指定和 IBM Application Server 一起安装的 JRE(例如: c:\WebSphere \AppServer \java \jre ),然后单击 Next。
- 指定 Policy Server 信息。
- 在通用登录屏幕上单击 Next,然后单击 Finish。您将看见一条消息显示配置完成。
接下来,进行 Access Manager WebSEAL 配置:
- 选择 Access Manager WebSEAL包,然后单击 Configure。
图 17. Access Manager WebSEAL 配置
- 再次单击 Configure,配置一个新 WebSEAL 实例。
图 18.配置新 WebSEAL 实例
- 继续执行下面屏幕所显示的步骤,为 WebSEAL 实例输入名称,主机名以及监听端口,默认的监听端口为 7234 。将它的 HTTP 端口号设为 81 ,HTTPS 端口号设为 444 ,并设置一个文档根目录。
- 在配置实用工具上单击 Close。
要验证您是否在主机上安装了 Access Manager V5.1 组件(例如, RHAALAB2 ):
- 打开命令提示符,键入 pdadmin 。
- 输入这些命令:
Pdadmin > -a sec_master <your password> pdadmin sec_master> server list |
将提供给您新配置的 WebSEAL 实例。
- 确保您可以访问: http://rhaalab2.raleigh.ibm.com:81 。
- 单击下面的链接,利用 https 重新访问页面。它应该为您重定向到您的页面: http://rhaalab2.raleigh.ibm.com:444。
- 检查您能否登录。
现在,您已经完成了对 Access Manager 的配置。
步骤 3.为 SSL 配置 HTTP 服务器
如果您正在设置 WebSEAL 连接来使用 SSL(我们推荐的方法),那么您必须执行该步骤,这样 HTTPS 通信就可以使用自签名(self-signed)证书。如果您使用的是 TCP 而不是 SSL 作为您的 WebSEAL 连接,那么跳过该步骤,转到 步骤 5。Web 服务器必须为 SSL 定义一个端口,通常使用 443。您将使用 IBM Key Management Utility——iKeyman 来生成自签名证书。
- 创建一个名为 c:\ihs\keytab 的目录。
- 选择 Start => Programs => IBM HTTP Server => Start Key Management Utility。
- 选择 Key Database File => New。输入下面的信息:
- Key Database Type:CMS key database file
- File Name: keyfile.kdb
- Location: \ihs\keytab 如下所示。
- 单击 OK。
图 19.密钥文件
- 输入 test 作为密码。检查文本框 Set expiration time和 Stash password to a file。单击 OK。您将看到一条消息提示密码已经被加密并且保存在 c:\ihs\keytab\keyfile.sth 文件中。
图 20. HTTP 服务器密钥文件
- 选择 Create => New Self Signed Cert。输入 IHS 作为 Key Label。Common Name 默认为 hostname。单击 OK。
图 21.创建自签名证书
- 单击 Extract certificate 将证书提取到一个文件中。如下所示,输入 cert1.arm 作为 Certificate file name。单击 OK。
图 22. 将证书提取到文件中
- 现在,您已经将证书提取到 cert1.arm 文件中。退出 iKeyman 实用工具。
- 将下面的代码行添加到 <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> |
- 将本代码中的 * 替换为具体的虚拟主机。
- 停止并重新启动 HTTP 服务器。通过在 Web 浏览器上打开类似 https://yourserver.domain.com/ 的页面来检验它是否在监听端口 443。例如: https://rhaalab1.raleigh.ibm.com/ 。
您已经为 HTTP 服务器完成了 SSL 配置。
步骤 4.将证书加载到 WebSEAL 主存储器中
现在您需要将最后一步创建的证书加载到 WebSEAL 的主数据库中:
- 如果您的 HTTP 服务器与 WebSEAL 不在同一台机器上,那么将步骤 3 中的证书 c:\ihs\keytab\cert1.arm 从 HTTP 服务器上复制到 WebSEAL 所在机器的同一目录下。
- 在 WebSEAL 所在机器上启动 IBM Key Management Utility。
- 从菜单栏选择 Key Database File => Open。
- 将目录切换到 <Access Manager_Install_root>\PDWeb\www-default\certs ,并在 File name 框中输入 pdsrv.kdb 。这是 WebSEAL 用来为 SSL 连接存储可接受的 CA 证书的密钥环。输入 pdsrv 作为密码,然后单击 OK。
- 从下拉菜单中选择 Signer Certificates,然后单击 Add 按钮。
图 23.添加签名证书
- 输入 cert1.arm 作为文件名,输入 c:\ihs\keytab\ 作为路径,如下所示。单击 OK。
图 24.从先前保存的文件中获取证书
- 输入 IHS 作为标签,然后单击 OK继续。
- 退出 IBM Key Management 实用工具。
- 停止并重新启动 Access Manager WebSEAL 服务。
您已经完成了将 HTTP 服务器证书导入到 WebSEAL 的主数据库中。
步骤 5.启用 HTTP 通信的转发
您需要配置 Application Server 插件,将 HTTPS 通信转发到应用服务器。要实现这一点,您需要更新 Application Server 的虚拟主机列表,使其包含正确的主机名称和端口号,并重新生成插件结构。为 ActiveX 控件和 Java Archive 文件添加 MIME 类型。WebSphere Portal Extend 的 Lotus 组件需要这些 MIME 类型。
- 在运行 Application Server 和 WebSphere Portal 的机器上,确保 server1 正在运行:https://rhaalab1.raleigh.ibm.com:9090/admin
- 使用 wpsbind id 和密码登陆到 Application Server 管理控制台。
- 在控制台的左侧面板中,选择 Environment => Virtual Hosts => default_host => Host Aliases => New。
- 为您在步骤 3 中添加到 Web 服务器的 hostname 和 SSL 端口添加一个主机别名。hostname 可能是 * 或者是一个全限定主机名。通常是 Web 服务器的主机名。单击 OK添加一个端口为 443 (HTTP 服务器的 SSL 端口)的虚拟主机。
图 25.在 Application Server 管理控制台中添加虚拟主机
- 单击 Save保存对配置所做的修改。
- 选择 Environment => Update Web Server Plugin,然后单击 OK更新插件。等待显示 Plugin update successful 消息。
- 如果 Web 服务器在另一台机器上,将 plugin-cfg.xml 文件复制到 Web 服务器上。(有关 Application Server 虚拟主机功能的完整的介绍,请参阅它的文档。)
- 检查您能否访问 snoop: https://rhaalab1.raleigh.ibm.com/snoop 。
- 要添加一个 MIME Type,选择 Environment => Virtual Hosts => default_host => MIME Types => New。输入如下值:
- Mime Type: application/java-archive
- Extensions: jar
- 单击 OK,然后将您的修改保存到主配置。
您已经完成了添加虚拟主机和 MIME 类型的操作。现在,为 SSL 配置 WebSphere Portal。
- 如下所示,编辑 <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 |
- 保存并关闭该文件。
步骤 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 。
- 从 下载文件中导入 portalusers.ldif 文件,在 LDAP 中创建 taiuser。您可以使用 LDAP 配置实用工具,或者您也可以使用 ldapadd 或 ldapmodify 来添加用户。
ldapadd -D cn=root -w ldap -f <full path to portalusers.ldif> |
- 确保已经在 Directory Server 中创建了taiuser。
- 接下来,登录到 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 )。
- 在 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 连接
- 继续下一步前先检查下面的 URL:
- WebSEAL 主页: https://rhaalab2.raleigh.ibm.com:444
- HTTP 服务器主页: https://rhaalab1.raleigh.ibm.com/
- 通过 WebSEAL 连接的 HTTP 服务器(应该显示 HTTP 服务器主页):https://rhaalab2.raleigh.ibm.com:444/ssl1
- 要启用 Junction to Request Mapping Table (JMT) 功能,定义一个 ASCII 文本文件,命明为 jmt.conf 。在 jmt.conf 文件中数据条目的格式由连接名称、一个空格和资源定位模式组成。您可以使用通配符来表示资源定位模式。在配置文件的 [junction] 这一节中指定该文件的存放位置:
<Access Manager_install_root>/PDWeb/etc/webseald-default.conf |
例如:
这段语句表示 jmt.conf 位于: <Access Manager_install_root>/PDweb/www-default/lib/ 这个目录下。在 jmt.conf文件中输入如下内容: /ssl1 /wps/* :
- 将数据添加到文件中后,使用 jmt load 命令来 "加载" 数据,这样 WebSEAL 就能够识别新的信息。
图 27.创建 WebSEAL 连接
您已经完成了连接的创建并创建和装载了一个 jmt。
步骤 8.编辑 webseald.conf 文件
在这一步中,您将编辑 WebSEAL 配置文件来配置一些超时和虚假密码问题,这些假密码可能在 HTTP 消息头中传输。
- 打开文件: <Access Manager_install_root>/PDWeb/etc/webseald-default.conf .
- 在 [junction] 这一节中,将 basic-auth-dummy-password 改为 taiuser 的用户密码:
basicauth-dummy-passwd = taiuser1 |
在同一节中,修改下面语句:
- http-timeout = 300
- https-timeout = 300
- 在 [forms] 这一节中,利用这个格式来启用 WebSEAL 认证: forms-auth = https
- 在 [script-filtering] 这一节中,设置: script-filter = yes
- 因为您使用的是基于窗体的认证,而不是基本认证,所以将 ba-auth 从 https 改为 none :
- 停止 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 中
步骤 10.在 Application Server 中配置 TAI
现在,为了用 Application Server 启用 SSO,在 Application Server 中配置 WebSEAL TAI:
- 登录到 Application Server 管理控制台。例如,在 Web 浏览器中打开:https://rhaalab1.raleigh.ibm.com:9090/admin 。
- 导航到 Security => Authentication mechanism => LTPA => Trust Association,然后单击 Enable。
- 在附加属性下单击 Interceptors。拦截器的类名称为:com.ibm.ws.security.web.WebSealTrustAssociationInterceptor 。
- 单击 Custom properties,然后添加表 2 中列出的属性。象该表中列出的那样正确复制属性名称。注意那些值和用 { } 围起来的说明,看那些值是否适合您的环境。 表 2.自定义属性
名称 | 值 | com.ibm.websphere.security.trustassociation.types | webseal | com.ibm.websphere.security.webseal.hostnames | RHAALAB2
{在完全相同的实例中,这里需要输入"主机名"命令的输出。该字段对大小写敏感。它不是全限定主机名。您可以输入逗号将主机名列表分开。} | com.ibm.websphere.security.webseal.id | iv-user
{这是 WebSEAL 在请求 Application Server 时发送的消息头字段。它告诉 TAI 将哪个字段用于终端用户身份。} | com.ibm.websphere.security.webseal.loginId | taiuser
{这个 id 的密码存于 WebSEALd.conf 文件的 basicauth-dummy-passwd 属性中。} | com.ibm.websphere.security.webseal.ports | 444
{这是 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。如果不包含代理,这个选项设为什么都没有关系。} |
- 将您的设置与下面图 29 中所示的设置对比。重要提示:主机名对大小写敏感,为了与我们用于测试的名称相匹配,在这个场景中,主机名 RHAALAB2 全部是大写字母。您可以混合使用或用小写字母作为您实际的主机名。
- 保存配置
图 29.自定义属性
- 保存配置,退出 Application Server 管理控制台。删除下面这个目录下预编译的 JSP 文件: <Application Server_ROOT>/temp/<nondename>/WebSphere_Portal
- 删除预编译的类后重新启动 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 |
- 检查您能否通过下面的 URL 获得 SSO: https://rhaalab2.raleigh.ibm.com:444/ssl1/wps/myportal .
- 作为 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 证书也被破坏了。如果您想保留这个动作,执行下列步骤:
- 在: <WP_ROOT>/shared/app/config/services/ConfigService 这个目录下备份 ConfigService.properties 文件。
- 如下所示,编辑文件:
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 文件中移除自注册:
- 备份每一主题子目录中的 <Application Server_ROOT>/installedApps/<hostname>/wps.ear/wps.war/themes/html/<theme_name>ToolBarInclude.jsp 文件,然后在下一步中编辑该文件。
- 在文本编辑器中打开文件,将登记按钮注释掉,如下所示:
<!-- <%-- 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> --> |
- 通过移除目录: <Application Server_ROOT>/temp/<node_name>/WebSphere_Portal/ 下的内容,从 WebSphere Application Server 高速缓存中删除已经编译过的 JSP 文件。
回页首
结束语
本文讨论了配置 TAI 以集成 Tivoli Access Manager 和 WebSphere Portal 来进行身份验证的几种不同方法。同时您还学习了在集成 Access Manager 和 Application Server 时可能出现的潜在的错误配置问题。经历了配置 WebSphere Portal 的整个过程。用 Directory Server 配置各种 Access Manager 组件。使用 Access Manager 配置 WebSphere Portal 和 Application Server 来进行身份验证。并且您还学会了如何对您的拓扑结构中大部分的组件进行系统故障诊断。 |
|