图 1. Access Manager Policy Server
管理应用程序将使用 C 或 Java 管理 API 来管理 Access Manager 用户和组的详细信息。
管理 API 通过加密的 TCP/IP 连接与 Access Manager Policy Server 进行通信，它以这种方式来工作。这个加密的 TCP/IP 连接称为安全性上下文。该安全性上下文提供了管理应用程序和 Policy Server 之间请求和数据的安全传送。在执行任何管理功能前必须建立安全性上下文。
安全性上下文是通过调用 C 函数 ivadmin_context_createdefault() 或者在 Java 中创建新的 PDContext() 来创建的。这些函数将使用存储在 pd.conf 中的 Access Manager 运行时环境来确定 SSL 的配置和 Policy Server 的位置。这些函数接受 Access Manager 用户（具有执行 Access Manager 管理操作的必要访问权限）的用户名和密码。下面是一个使用 C 管理 API 创建安全性上下文的示例。安全性上下文作为变量 ctx 返回。
ivadmin_context ctx;
ivadmin_response rsp;
unsigned long status;
const char *username = "admin_user";
const char *password = "admin_user_password";
status = ivadmin_context_createdefault( username, password, &ctx, &rsp );
if ( status != IVADMIN_TRUE ) {
/* The context could not be created */
/* run the necessary cleanup functions and exit */
handleError( rsp, "Error creating security context" );
}
这里用户名和密码的硬编码值只是为了进行说明。在建立了安全性上下文之后，出于安全原因会将该密码去掉。handleError() 代码未包含在本示例中。
下面是使用 Java 管理 API 创建安全性上下文的示例。
//Create locale for US English
Locale myLocale = new Locale("ENGLISH","US");
String adminName = “admin_user”;
String adminPwd = “admin_user_password”;
char [] adminPassword = adminPwd.toCharArrary();
URL configFileURL = new URL(file:///c:/WebSphere/AppServer/PDPerm.properties);
PDContext myContext =new PDContext(myLocale,
adminName,
adminPassword,
configFileURL);
Java PDContext 需要知道 Access Manager 配置文件的位置，该文件由 SvrSslCfg 类创建。
管理应用程序
由于很多组织都在尝试使用户能更方便地注册组织提供的服务，因此出现了许多提供自注册和自照管能力的应用程序。这些应用程序使用户可以快速地创建和管理他们自己在某个组织中的帐户，并且能即时访问他们的一些服务，而无需填写书面报告或者联系服务台。
除了自照管应用程序外，许多组织还需要集成和定制 Access Manager 管理过程，以便与其管理环境保持一致。其范围可以从 z/OS 到基于 WebSphere 的 Java 应用程序。
对于要在 Access Manager 环境中使用的这些类型的应用程序而言，它们将使用管理 API。
图 2. 管理 API 应用程序
然后管理员可以使用 3270 绿屏应用程序、某些 Web 客户机或者甚至是 Web 服务来连接到组织的管理服务。该管理服务器然后可以使用管理 API 调用 Policy Server，以管理 Access Manager 环境。
策略服务器群集
为了提高 Access Manager Policy Server 的可用性，或者为了将管理操作的负载分摊到几个 Policy Server 上，建议创建 Policy Server 群集。
Policy Server 群集由一个或多个 Policy Server 构成，可以有以下几种配置：
高度可用的 Policy Server，包含一个主 Policy Server 和几个备用 Policy Server。
负载均衡的 Policy Server，包含多个可以均衡用户和组操作负载的 Policy Server。
高度可用和负载均衡的 Policy Server 组合。
所有这些群集配置都需要群集地址，该地址由 TCP/IP 路由设备（如 WebSphere Edge Server、Network Dispatcher 组件）管理。TCP/IP 路由器必须确保保持管理客户机和 Policy Server 之间的密切关系，因为管理 API 使用 SSL 进行通信，相关联的安全性上下文每次只对一个 Policy Server 有效。任何群集配置中的所有服务器都将共享用户注册表；本文将不介绍 Access Manager 环境中用户注册表的群集或负载均衡方面的任何详细信息。
一些群集配置尝试使用 DNS 以将请求重定向到备用 Policy Server。由于 Access Manager 组件的自动重建特性（支持该功能）将不会重新解析 Policy Server 的 IP 地址，则使用 DNS 将导致重新启动所有 Access Manager 组件，因为 DNS 的变化将更改 Policy Server 的 IP 地址。
高度可用的策略服务器
在高度可用的群集中，有一个主 Policy Server 和几个备用 Policy Server。每个备用 Policy Server 都包含授权数据库的一个副本和主 Policy Server 配置的副本，它具有在主 Policy Server 发生致命故障而不能执行任何任务的情况下接管主 Policy Server 的能力。
图 3. 高度可用的策略服务器群集
管理应用程序将维护与主 Policy Server 之间的安全性上下文，除非主 Policy Server 发生故障，并且备用 Policy Server 接管了管理功能。当发生这种情况时，在备用 Policy Server 被提升为新的主 Policy Server 后，TCP/IP 路由器将把管理操作路由到备用 Policy Server。
因为每个管理应用程序都必须只维护与一个 Policy Server 之间的安全性上下文，因此当主 Policy Server 发生故障，并且备用 Policy Server 接管了其功能时，必须重新建立新的安全性上下文。C 管理 API 和 Java 管理 API 将会对此进行不同的处理。
使用 C 管理 API 进行的故障转移需要管理应用程序通过调用 ivadmin_context_createdefault() 函数重新建立安全性上下文。而 Java 管理 API 将利用下一次对 Java 管理 API 方法的调用自动恢复安全性上下文。
为了在备用 Policy Server 上维护一份 Access Manager 授权服务器使用的授权数据库的副本，Access Manager Policy Server 不会自动复制彼此之间的授权数据库。授权服务器将自动复制主 Policy Server 的授权数据库，在备用 Policy Server 被提升为主 Policy Server 时，备用 Policy Server 可以使用该授权数据库的副本。
最好只将该选项用于冗余目的。通过一个 Policy Server 运行多个管理应用程序并没有性能好处。但是 Policy Server 可以并行地处理多个同时的管理请求。
负载均衡的策略服务器
负载均衡的 Policy Server 群集将在几个 Policy Server 之间均衡用户和组请求。只能对用户和组操作进行负载均衡，对授权数据库进行的任何负载均衡操作都将失败。
与主和备用 Policy Server 相比，负载均衡的 Policy Server 应是一组独立的服务器。这把负载均衡的 Policy Server 从主 Policy Server 中分离出来。主 Policy Server 是用于下载授权数据库的唯一 Policy Server，这很重要，因为它是唯一拥有最新授权数据库副本的服务器。在这种配置中，Policy Server 通常只是到用户注册表的网关，它提供了一组高级别的功能以对 Access Manager 用户注册表进行操作。在这种情况下，授权数据库通常是空的且没有被使用，这意味着不支持委托管理。
图 4. 对用户操作进行负载均衡
每个管理应用程序每次只能与一个 Policy Server 建立安全性上下文。对于有多个都执行用户和组操作的管理应用程序而言，该群集配置很理想。TCP/IP 路由器必须确保维持每个管理应用程序和 Policy Server 之间的连接。如果 TCP/IP 路由器决定在管理客户机上切换 Policy Server，那么只能在某个 Policy Server 发生故障时才能这样做。
由于管理客户机的安全性上下文是由管理应用程序维护的，因此当 TCP/IP 路由器将管理功能重定向到另一个 Policy Server 时，管理应用程序必须创建与新的 Policy Server 之间的新的安全性上下文。Java 管理 API 将自动恢复安全性上下文，而 C 管理 API 不会这样做。
创建管理 API 安全性上下文有很大的开销，因此只有在必要的时候才执行该任务。
该选项最好用于高性能的情形，因为有多个专用的服务器都运行 Plicy Server，它们只处理用户和组的管理请求。其中，每个 Policy Server 都可以完全并行地处理多个管理请求。但是，因为这些 Policy Server 不包含授权数据库的副本，因此它们不能就哪些管理可以确定地执行管理请求做任何授权决定，这些请求将留给管理应用程序，从而使得在修改了缺省的管理访问控制规则时（如委托管理）不可使用该选项。
组合的策略服务器群集
将高度可用的群集和负载均衡的群集组合在一起需要备用 Policy Server 承担负载均衡的用户管理服务器和备用 Policy Server 双重角色。该配置需要 TCP/IP 路由器处理多个群集地址。一个地址用于高度可用的 Policy Server，另一个地址用于负载均衡的 Policy Server。该配置的优点在于，执行负载均衡任务无需额外的 Policy Server 硬件。使高度可用的配置和负载均衡的配置的群集地址保持独立很重要，因为只有主 Policy Server 才被保证拥有最新的授权数据库的副本。需要授权数据库最新副本的 Access Manager 组件只使用高度可用的群集地址（如 WebSEAL），而用户管理应用程序将使用负载均衡的群集地址。
图 5. 高度可用和负载均衡的策略服务器
该配置具有支持委托管理的优点，因为在备用策略服务器上，授权数据库可能包含有关委托管理的规则。在这种情形中，备用 Policy Server 上的授权数据库不能为空，因为备用 Policy Server 必须知道如何根据管理员委托权限对不同域的用户实施访问。在这种情形下，备用 Policy Server 与主 Policy Server 是并行地运行的，但是并未对备用 Policy Server 进行配置，以使其可以向 Access Manager 服务器通知有关授权数据库的变化。
如果主 Policy Server 发生故障，那么通过使用复制的授权数据库并且打开更新通知，备用／负载均衡的 Policy Server 可以承担主 Policy Server 的角色。
故障对管理应用程序的影响与其它配置相同。该配置优点在于，体系结构得到了简化，并且提供该解决方案所需的硬件较少。
最好在需要性能和冗余性时使用该选项。两个 Policy Server 都将拥有授权数据库的副本，其中对缺省管理访问控制表的任何更改都将对所有 Policy Server 强制实施。但是备用／负载均衡的 Policy Server 上的授权数据库将需要以手工的方式保持最新（通过使用来自授权服务器的授权数据库）。
该选项的性能不如使用负载均衡的 Policy Server 好，因为 Policy Server 扮演了双重角色，并且将处理额外的流量。但是，考虑到所需的服务器较少，因此，在那些只需中等数量管理事务的环境中，成本收益可能会超过性能损耗。
高度可用的策略服务器配置
高度可用的 Policy Server 配置需要几个 Access Manager 包，它们是：
- PDRTE，Access Manager 运行时环境
- PDAuth，Access Manager 授权服务器
- PDMgr，Access Manager 策略服务器
PDRTE 包包含所有 Access Manager 服务器所需的基本 Access Manager 二进制文件和库。PDAuth 包包含 Access Manager 授权服务器，但在高度可用的群集环境中不使用该服务器做授权决定，而是使用它从主 Policy Server 复制主授权数据库。
PDMgr 包包含 Policy Server。
要配置 Access Manager 备用运行时环境，请执行下列任务。
安装 PDRTE 包
安装 PDAuth 包
配置 PDRTE 和 PDAuth 组件以使用 Policy Server 群集地址。
安装 PDMgr 包
现在可安装任何 Access Manager 修订包
无需配置 PDMgr 组件
要配置备用 Policy Server（PDMgr）组件，请执行下列步骤。
将这些文件从主 Policy Server 复制到备用 Policy Server 上的相同位置。
etc/ivmgrd.conf
keytab/ivmgrd.sth
keytab/ivmgrd.kdb
要创建备用 Policy Server 授权数据库，使用备用 Policy Server 上的授权服务器下载的副本。
# cp db/ivacld.db db/master_authzn.db
无需启动备用 Policy Server，除非主 Policy Server 已经关机。
要使备用授权数据库与主 Policy Server 保持同步，则每隔一段时间执行等价的操作。
# cp db/ivacld.db db/master_authzn.db
要提升备用 Policy Server，则执行下述操作。
通过获取 ivacld.db 的副本，确保备用授权数据库与主授权数据库同步（在备用 Policy Server 上的授权服务器）
# cp db/ivacld.db db/master_authzn.db
更改 TCP/IP 负载均衡器，以便将管理 API 请求定向到备用 Policy Server。
如果主 Policy Server 仍在运行，则停止它
启动备用 Policy Server
要降级备用 Policy Server，必须执行下述步骤。
确保新的主 Policy Server 上的授权数据库与备用 Policy Server 保持同步。通过从备用 Policy Server 获取 db/master_authzn.db 文件的副本，并且将其存储在新的主 Policy Server 上的相同位置中，可以完成该工作。
更改 TCP/IP 负载均衡器，以便将管理 API 请求定向到新的主 Policy Server。
停止备用 Policy Server。
启动新的主 Policy Server
提升或降级 Policy Server 的影响与重新启动 Policy Server 一样，会导致所有 Access Manager 应用程序释放其与 Policy Server 之间的安全性上下文。对于任何要重新继续的管理服务而言，必须建立新的安全性上下文。Policy Server 的重新启动将对 Access Manager 组件和服务器产生下述影响：
pdadmin — 安全性上下文是自动重新建立的，无需管理员重新进行认证。
Web 门户网站管理器（Web Portal Manager，WPM）— 管理员需要重新认证到 WPM。
C 管理 API 应用程序 — 该应用程序需要重新创建安全性上下文。
Java 管理 API 应用程序 — 安全性上下文是随着对 Java 管理 API 的下一次调用自动重新建立的。
Access Manager 服务器 — 其它 Access Manager 服务器将会自动重新建立与 Policy Server 之间的安全性上下文，这不会使它们执行的服务产生任何中断。
负载均衡的策略服务器配置
负载均衡的 Policy Server 配置需要几个 Access Manager 包，它们是：
- PDRTE，Access Manager 运行时环境
- PDMgr，Access Manager 策略服务器
在该配置中不使用授权服务器，因为无需保持授权数据库与主授权数据库之间的同步。因为该数据库不用于存储受保护的数据对象。
要配置负载均衡的 Policy Server，请执行下列任务。
安装 PDRTE 包
针对主 Policy Server 配置 PDRTE 包
安装 PDMgr 包
现在可安装任何 Access Manager 修订包
无需配置 PDMgr 组件
要配置负载均衡的 Policy Server（PDMgr）组件，请执行下述步骤。
1. 将这些文件从主 Policy Server 复制到负载均衡的 Policy Server 上的相同位置
etc/ivmgrd.conf
keytab/ivmgrd.sth
keytab/ivmgrd.kdb
2. 要创建 Policy Server 所需的空授权数据库，请发出下列命令：
# bin/pdmgrd –initdb
对于需要使用负载均衡的 Policy Server 的所有应用程序，修改 master-host 项，使之指向 Policy Server 群集。这一更改是在 etc/pd.conf 文件中进行的。
[manager]
#
# Master server configuration
#
# Hostname of the Policy Server.
master-host = | 欢迎光临 黑色海岸线论坛 (http://bbs.thysea.com/) | Powered by Discuz! 7.2 |