TIM&TAM产品介绍 - 图文

1. 方案中的主要产品介绍

1.1. IBM Tivoli Identity Manager

1.1.1. IBM Tivoli Identity Manager概述

IBM Tivoli Identity Manager提供了一个安全、自动而且基于策略的用户管理解决方案，满足客户无论是在原有的IT环境还是电子商务时代的IT环境下将企业的核心业务展现给客户、供应商、合作伙伴甚至竞争对手的需求。在现有的业务流程中引入基于Web的管理和自助式服务接口的动机，反应了客户对简化及基于安全策略的自动化用户管理的需求。Tivoli Identity Manager包含一个工作流引擎，同时利用用户身份信息提供如审计、报告等功能。

IBM Tivoli Identity Manager既可以直接与用户交互，也可以与两种类型的外部系统－身份数据源和访问控制机制直接交互。身份系统管理需要在各个系统中建立帐号的用户身份的权威数据。发布系统与访问控制系统直接交互，从而建立用户帐号，提供用户信息以及密码，定义用户的授权信息。与之相反的是，在访问控制系统中进行的改动能够被发布系统所捕获并报告，然后按照安全策略对这些改动进行评估。

1.1.2. IBM Tivoli Identity Manager产品架构

IBM Tivoli Identity Manager的逻辑结构根据功能的不同设计为三层，如下图所示，各个组件分别为：

? Web用户界面层 ? 应用层

? 服务层 ? LDAP目录 ? 数据库 ? 资源连结器

图3-1 逻辑组件结构

1.1.2.1. Web用户界面层

Web用户界面模块是一组结合在一起的子程序，包括提供用户浏览器的内容和启动applet（同时在客户端和服务器端运行），如工作流设计和表单创建。Web用户界面是用户浏览器和身份管理应用层的连接层。

在上面的图中，用户交互点有三种类型：终端用户，监督员和管理员。这些类型仅仅是概念上的，因为IBM Tivoli Identity Manager允许您随意的定义各种权限的不同用户类型。

在上面的图中，指出的重要一点是系统的基础为系统用户功能的一般性概念。例如，假定管理员需要更高的权力，要求更高级的用户界面；假定监督人员需要稍微低一些的权力，但仍需要如组织图表之类的概念；最后，终端用户没有任何假定，显示给终端用户的接口必定是仅具有基本的、直接的功能接口。

1.1.2.2. 应用层

IBM Tivoli Identity Manager系统的核心正是应用层。应用层驻存于应用服务器中，提供了对其他所有进程对象的管理功能。

应用界面模块由所有的特定应用的用户界面组件构成。例如，该界面需要创建一个指派规则或者该模块中的一个帐户。这一模块可以使用Web用户界面子系统中的其他模块，例如表单提交和搜索模块。

1.1.2.3. 服务层

如果说IBM Tivoli Identity Manager服务器是一个为复杂规则所开发的应用，那么应用服务器就是运行这些规则或对象的引擎。它不仅与运行用户界面的Web服务器交互，还与从属于所管理服务的适配器、存储信息的目录服务器进行交互。

核心服务子系统包含了所有的模块，提供了可用于进行用户身份管理一般性服务，如认证、授权、工作流和规则执行。这些服务经常利用其他服务来达到目的。

1.1.3. IBM Tivoli Identity Manager产品功能

1.1.3.1. 集中式的帐户管理

IBM Tivoli Identity Manager 可以集中的为一个组织创建、管理、挂起和移除所有用户的帐户。从而降低各种用户帐号管理的成本。

1.1.3.2. 基于角色的用户管理和访问控制

基于角色的访问这一概念是指，利用个人的某些已知信息来决定赋予其相应的权利。IBM Tivoli Identity Manager将用户按照角色来管理。大多数情况下，一个角色代表着通用的职责。例如，可以在组织中创建一个会计的角色，使其能够访问所有的跟会计相关的应用和资源。同样职责的应用有银行机构中的信贷人员，或者保险公司中的理赔评估人等等。为用户分配角色可以是固定的，也可以是动态的。

固定：管理员必须手动的为每位用户添加相应的角色；

动态：按照一项或多项个人数据项（LDAP属性），为每位用户自动的添加角色。例如，所有的信贷人员都会依照他们的职位、部门编号或管理者的名字统一添加到一个信贷人员角色。

一旦某位用户被IBM Tivoli Identity Manager分配了一个特定的角色，也就会获得该角色相关的资源。在我们的解决方案中，角色或者是在我们产品中唯一的被创建，或者是从您公司的HR系统依照现存角色提取出的模型。

1.1.3.3. 委托管理

IBM Tivoli Identity Manager提供了委托管理功能。使用内置的访问控制项（Access Control Information，ACI）的策略，实现多方面的细粒度控制，如用户信息、报告和指派功能（策略、工作流、服务）、所有用户的身份属性和操作（移除、转移、搜索、恢复、挂起、添加和修改）的详细的GRANT和DENY选项。管理的范围是对系统中的所有用户，直至单个用户的级别。

例如，您可以创建一个服务台角色和一个安全管理员角色。服务台角色将被限制接入到机密或敏感信息，而安全管理员角色拥有全部权限。这些角色一旦被创建，您就可以管理相应的ACI。安全管理员角色将“允许”访问所有安全级别的信息。服务台角色将会被限制查看个人机密信息，但可以修改某些属性，如“职位”。

1.1.3.4. 用户自助式服务

IBM Tivoli Identity Manager 的自助服务功能非常有用。自助式服务功能使用户（和委托管理员）可以通过用户指派系统管理授权数据。利用角色和ACI规则，用户可以对其他用户和委托管理员指派特定的权限，对个人数据执行某特定操作，如添加或移除。通过自助式服务功能，授权用户可以自己重设密码，自助的注册以申请所要管理资源的访问权限。

1.1.3.5. 用户数据和密码的同步

IBM Tivoli Identity Manager与IBM Tivoli Directory Integrator结合在一起，提供对组织中所有被管理系统的用户帐户信息以及密码同步的能力。通过IBM Tivoli Identity Manager既可以保证企业内部用户信息的一致性，又可以保证用户密码的统一管理。经过

密码同步之后，用户只需要记住一个密码就行了，从而提高了生产力，保证了对各个系统无缝的访问。

1.1.3.6. 基于WEB的管理界面

IBM Tivoli Identity Manager提供了一个功能全面的基于Web的管理员使用界面。所有的管理工作都可以通过这个Web工具非常轻松地完成。这个Web工具不仅可以为管理人员提供管理界面，而且可以同样为最终用户提供一个管理和使用界面。它的目的就是要为各种用户提供一个统一的、直观的、简单的、互动的、全面的管理工具。该界面的截图如下所示：

图3-2 基于Web的管理界面

1.1.3.7. 审批业务流程的自动化

IBM Tivoli Identity Manager还具有内置的工作流引擎，结合客户自身的业务流程，自动的为业务管理的相应资源，使得业务更具弹性。工作流的粒度，简单时只需获得一个批准，复杂时必须请求多重准许，如附加信息、通知、工作单、子流程、环路和客户通过Java? Script定制的扩展步骤。

工作流程的审批过程是通过对用户间关系（如管理员，责任人或系统拥有者等）的分解，关联到某特定个人。或者按规定路线发送到某特定角色相关的任何个人。我们的解决方案能够基于实际行动来决定相关的审批者。例如，可以将“服务所有者”或“管理员”的关系设置成审批者。在这种方式下，工作流引擎能够按照服务和被指派的人来动态的决定服务所有者和/或管理者。

在我们解决方案的工作流程设计工具的帮助下，能够通过简单的拖拽来定制自己的审批工作流程。

图3-3 生命周期管理和工作流程设计工具

如上例所示，当承包商进入到组织中时需要运行的一个客户证明流程，得到相应的许可，并发送一个“允许”或“拒绝”的通知到特定的电子邮箱。

1.1.3.8. 整合功能

IBM Tivoli Identity Management解决方案具有基于策略的整合功能，旨在根据策略核对本地系统对用户环境、所管理资源的改动。通过定义策略来处理这些被检测的帐户，决定是否使这些包含改动信息的帐户暂停或打上标记以便于管理人员查阅，应用程序是否需要自动处理这些异常，要么将所管理系统的信息的改动撤销，与主数据库保持一致，要么考虑认可本地系统的改动，并更新对应的主数据库。

1.1.3.9. 智能补救功能

IBM Tivoli Identity Manager对违反策略之处会记上标准按钮（标记、挂起、纠正），还会将不符合策略的部分送到权威处以待进一步的分析。IBM Tivoli Identity Manager能够显示每个帐户违规的准确原因，不必手动查询该帐户是否合乎安全规则。另外，还会提供一组解决问题的建议供分析人员参考。

1.1.3.10. 密码策略管理

IBM Tivoli Identity Manage的解决方案允许您为每一种所管理的资源设定密码规则。除了像长度要求这种基本参数外，还包括通过Java Script来定制规则，以满足更为复杂的需求。

IBM Tivoli Identity Manager的密码规则包含多个方面，包括： ? 最小长度和最大长度 ? 最大重复字符数

? 最小符号字符数和/或数字字符数 ? 定义无效和/或必需的字符

? 限定首字符和/或整个密码来自一个声明的字符集 ? 不允许重复历史密码（前向和/或反向拼写）的次数 ? 不允许将用户姓名和/或用户ID设为密码 ? 不允许出现包含在定制的字典中的密码

图3-4 Tivoli Identity Manager的密码策略设置

IBM Tivoli Identity Manager提供了服务器级别的密码策略，所以当用户试图通过GUI（或API机制）来修改密码时，在相应的更新作用到实际的目标帐号之前，这些改动有效性将会得到核对。

1.1.3.11. 规则模拟实施

IBM Tivoli Identity Manager帮助您在授权规则作用于生产系统的目标用户帐号之前，全面的了解这些改动将会带来的影响。管理人员能够预览多少帐户被增加、移除、修改、挂起或者与规则冲突。这一强大功能可以消除由于错误的授权规则产生的系统宕机时间。规则的改变能以草案方式保存，以供将来实施。

1.1.3.12. 用户帐户审计和报表

IBM Tivoli Identity Manager审计功能包括：跟踪终端用户和管理者在系统中进行的所有事务操作，包括用户授权的改动等。IBM Tivoli Identity Manager使用集中的轻量级目录访问协议（Lightweight Directory Access Protocol，LDAP）目录来保存用户身份信息，同时使用关系数据库作为集中的日志审计数据容器。两者都作为输入来生成预定义的报表，同时还能通过第三方应用程序来创建定制的报表。

IBM Tivoli Identity Manager通过Web报表界面为访问控制策略，当前的授权情况，集中各个被管理系统的审计事件等提供报表。下面列举其中的一些报表：

? 个人帐户：列举个人的帐户信息。

? 某角色的个人帐户：列出某特定角色的所有个人帐户。

? 管理某角色的规则：显示所有的与某特定角色相关的规则（和相关资源）。 ? 授予个人的权利：列出已指派给个人的所有权利和支配个人的指派规则。 ? 帐户操作：显示帐户的活动。

? 个人实施的帐户操作：显示某个人或多个人请求的帐户操作。 ? 操作报告：报告分类的操作行为，如增加一个新用户。

? 服务报告：如果提交的操作影响到指派的所管理系统（如Solaris Server），就发

送该报告。

? 用户报告：如果提交的操作影响到用户帐户，就发送该报告。 ? 拒绝报告：若帐户在工作流程中被审批者拒绝时发送的报告。

? 整合操作报告：对所管理资源（如，Solaris Server）的最近的整合操作的结果。 ? 休眠报告：列出与所管理资源（如，Solaris Server）相关的休眠帐户。 ? 帐户报告：列出人员和相关的帐户，以及该帐户是否遵从当前的规则。

? 审计事件：显示用户行为的审计记录。 ? 违规帐户：显示违规帐户和相关的服务。

? 自定义报表：自定义报表模板由嵌入式的报表设计器生成，也可引进第三方的报表

设计工具（如水晶报表等）。当然，自定义报表可直接运行于IBM Tivoli Identity Manager用户界面下。

1.1.3.13. 外部应用集成

IBM Tivoli Identity Manager（TIM）开放式设计允许您的组织对解决方案进行轻松的扩展。它提供了一整套的Java应用程序接口（API）来创建定制的接口，通过编码来完成定制的任务。IBM Tivoli Identity Manager的大多数自带功能都可以同外界系统进行整合，包括用户身份创建，属性管理，规则分析，Email通知和嵌入式工作流操作等。此外，还可以在显示层对原有Web用户界面进行改动，使得TIM与您企业的标准应用的“观感”相一致。

1.1.3.14. 柔性连接结构

IBM Tivoli Identity Manager对所管理目标系统提供柔性的连接选项，可以从下列结构中选择一种：

? 安装一个适配器程序（adapter）到所管理的平台上，通过适配器实现平台与TIM

服务器的交互，利用原有的管理程序或操作对象的API调用，本地执行指派的命令。

? 安装一个适配器程序（adapter）到一个拥有对所指派目标系统的管理能力的远程

系统上（代理系统）。这种方法通常用于数据库环境下，代理系统是个与数据库服

务器独立的系统，这样的话就能满足客户的不希望把适配器直接安装到被管理对象的服务器上的需求，而管理功能同样能够实现。

1.1.3.15. 规则和配置的导入/导出

IBM Tivoli Identity Manager使您能方便的将所有的规则和关键配置在开发、测试和产品环境下进行迁移。将当前环境的规则和配置导出为一个XML文件当作脱机版本，还可以进行版本间的“回滚”操作。

1.1.3.16. 扩展性和高可用性架构

IBM Tivoli Identity Manager被设计成为一个企业级安全解决方案，它的扩展性和高可靠性同时依赖于应用程序服务器技术。TIM可以部署在应用服务器集群中，在前端加上负载均衡，用以提高故障恢复和扩展能力。TIM服务器的集群能力对于用户是透明的，集群中某一资源失效时对用户没有任何干扰。最终的结果增加了产品的可用性和可靠性。这种服务器架构是柔性的，按照需要可以水平或垂直的扩展。例如，采用单一的企业级服务器或服务器集群。

至于数据层，则要受到硬件及其供应商解决方案的约束。当您选用软件包中自带的IBM DB2 Universal Database的话，它是完全支持集群的安装和数据库复制以提高系统的扩展性和可靠性。同样的，IBM Tivoli Directory Server也支持大多数操作平台上的复制和集群。

1.1.4. IBM Tivoli Identity Manager产品优势

? 降低了服务台的负担，通过使用Web自助式服务和密码重置/同步接口，帮助提高

用户的生产力；

? 通过集中控制和本地自治结合，确保敏感的系统的安全； ? 根据规则管理密码的功能，可以按照整体的或个体的；

? 降低过去的启动时间，自动化进行日常管理工作，帮助消除错误；

? 通过提供准确的报错和推荐的解决方法，协助解决所出现的违反规则的问题，从而

让您的组织对内部审计和监管做出快速的相应；

? 统一控制和本地自治，保证了安全性和您的大多数敏感系统规则的一致性； ? 组织管理能力，对您的组织结构进行建模，包括业务单元，位置，合作伙伴，甚至

内部的组织；

? 先进的工作流功能，使工作流过程与用户身份变动相关的复杂的业务流程的映射紧

密的结合；

? 先进的生命周期管理功能，提供了与个人相关的更为灵活的自定义操作，包括对实

体的全新操作的定义；

? 通过模拟规则变化的场景，准确评估规则改动的影响，而无需猜测规则的效果； ? 提供Java API，使用户身份管理功能能够和客户的门户解决方案及其他的面向客户

和员工的应用轻松的整合； ? 开放式标准以适应的环境；

? 与实际环境更大范围的整合，支持与行业标准规范相关的多重数据存储，个性化的

适配器开发更加简单；

? 适配器的配置灵活，可以是本地方式或远程方式；

? 大量的预定义和特别的报表，使您可以用任何能想到的方法来“切割”信息，通过

与外在报表工具整合的提供更为强大的自定义报表功能。

1.1.5. IBM Tivoli Identity Manager软硬件要求

IBM Tivoli Identity Manager可以运行在下面的操作系统之上： ? IBM AIX 5.3 ? IBM AIX 6.1 ? Sun Solaris 10

? Microsoft Windows 2003 Standard Edition and Enterprise Edition ? Microsoft Windows 2008 Standard Edition and Enterprise Edition ? Red Hat Linux Enterprise 4.0 ? Red Hat Linux Enterprise 5.0 ? SUSE Linuc Enterprise Server 10.0

IBM Tivoli Identity Manager本身的数据存储支持以下数据库中： ? IBM DB2 Enterprise Version 9.1 ? IBM DB2 Enterprise Version 9.5

? Microsoft SQL Server 2005, Enterprise Edition ? Oracle 10g Release 2 ? Oracle 11g

IBM Tivoli Identity Manager可以运行在下面的应用服务器上：

? WebSphere Application Server Version 6.1

IBM Tivoli Identity Manager中的用户和账号信息的存储支持以下的目录服务器： ? IBM Tivoli Directory Server Version 6.1 ? IBM Tivoli Directory Server Version 6.2

? Sun Java System Directory Server Enterprise Edition 6.3

1.2. Tivoli Access Manager for e-Business

1.2.1. Tivoli Access Manager for e-Business产品架构

1.2.1.1. 产品设计原则

IBM Tivoli Access Manager for e-Business的结构来自于业界标准的授权模型，如下图所示。

可以看到在这个标准的授权模型中，在访问者和目标之间有一个策略执行者，这是区别于传统模型的不同之处，在传统的模型中，访问者的请求直接到目标，所有的授权管理都在目标处完成。

所有访问者访问目标的请求（例如：HTTP和HTTPS的请求等）会被策略执行者所截获，策略执行者截获到访问者的请求后，会根据策略管理器中定义的规则来判断访问者的请求是否符合规则。如果符合安全规则的话，策略执行者会把访问者提出的请求转发给目标，并且把目标处理完后的结果转发给访问者，这时它相当于一个代理服务器。经过判断，如果访问者访问目标的请求不符合安全规则的话，策略执行者会直接拒绝访问者的这个请求，也不会把访问者的请求转发给目标。

在这个模型中，可以看到有几个特点：

? 所有访问者到目标的请求都会被策略执行者所截获，这些请求不会直接到达目标，

而是会通过策略执行者进行转发。

? 在这个模型中，目标不再做URL级别的用户授权判定，所有URL级别的授权判定

都由策略执行者和策略管理器来完成。

? 所有安全策略的定义都是通过策略管理器来完成的，它和目标是分开的，或者说它

和应用程序的开发是相对独立的、相对分开的。

1.2.1.2. 产品架构

IBM Tivoli Access Manager for e-Business的整体结构100%符合业界标准的授权模型，如下图所示，

图 错误！未找到引用源。-5 TDI在WebSphere Portal环境中的应用 上图是一个标准的企业提供的Web环境，它由两个防火墙隔成了以下三个部分： ? Internet部分：在这部分可以是各种Web浏览器，也可以是手机等客户端 ? DMZ部分：它处于两个防火墙之间，主要是用于有效地、安全地隔离Internet

和Private Network并且保护处于Private Network中的各种资源

? Private Network（私有网络）：在这部分主要用于放置企业对外的各种Web服

务器或者Web应用服务器等

在IBM Tivoli Access Manager for e-Business的结构中，所有的客户端（例如：Web浏览器等）是授权模型中的访问者，后端的各种Web服务器，例如：WebSphere、Domino、.Net应用等是授权模型中的目标，而处在DMZ区的WebSEAL是授权模型中的策略执行者。

在IBM Tivoli Access Manager for e-Business的整体结构中，作为策略执行者的WebSEAL相当于一个反向代理服务器，对于客户端来说，它相当于一个Web服务器，对于后端的Web服务器来说，它相当于一个客户端。它会对来自客户端的HTTP/HTTPS请求做访问权限的判定，并且对符合安全策略的请求做转发。通过WebSEAL可以保护后端的所有Web资源（Web服务器上的静态页面、动态页面、EJB中的资源、门户服务器上的各种资源等）。

这种基于反向代理的架构是最为安全的架构，他会给所有的后台应用系统建立起一个安全层，用户的所有访问请求不再直接到后台的应用系统，而是通过IBM Tivoli Access Manager for e-Business经过认证、授权和审计的工作之后再转发到后台的应用系统上，从而确保了后台系统的安全性。

1.2.1.3. 产品功能模块

IBM Tivoli Access Manager for e-Business由以下几个模块组成： ? LDAP Server ? Policy Server ? Web Portal Manager ? pdadmin命令行 ? WebSEAL

? Authorization Server ? Administration API ? Authorization API

下面，我们分别对以上提到的各个功能模块进行简单的介绍，

1.2.1.3.1. 目录服务器（LDAP Server）

IBM Tivoli Access Manager for e-Business会使用业界流行的LDAP服务器作为用户的注册库。IBM Tivoli Access Manager for e-Business现在支持包括IBM Directory

Server、Microsoft Active Directory、Lotus Domino、Sun Java System Directory Server在内的多种LDAP服务器。

LDAP技术不仅发展得很快而且也是激动人心的。在企业范围内实现LDAP可以让运行在几乎所有计算机平台上的所有的应用程序从LDAP目录中获取信息。

LDAP目录中可以存储各种类型的数据：电子邮件地址、邮件路由信息、人力资源数据、公用密匙、联系人列表，等等。通过把LDAP目录作为系统集成中的一个重要环节，可以简化员工在企业内部查询信息的步骤，甚至连主要的数据源都可以放在任何地方。

严格地说，LDAP不是数据库而是用来访问存储在信息目录（也就是LDAP目录）中的信息的协议。更为确切和正式的说法应该是像这样的：“通过使用LDAP，可以在信息目录的正确位置读取（或存储）数据”。

目录服务功能是以网络为中心的计算架构的重要组成部分。现在带有目录功能的应用系统推动着包括企业资源计划（ERP）、价值链管理、安全/防火墙和资源分配在内的企业关键业务。

LDAP最大的优势是：可以在任何计算机平台上，用很容易获得的而且数目不断增加的LDAP的客户端程序访问LDAP目录。而且也很容易定制应用程序为它加上LDAP的支持。

LDAP协议是跨平台的和标准的协议，因此应用程序就不用为LDAP目录放在什么样的服务器上操心了。实际上，LDAP得到了业界的广泛认可，因为它是Internet的标准。厂商都很愿意在产品中加入对LDAP的支持，因为他们根本不用考虑另一端（客户端或服务端）是怎么样的。

LDAP服务器可以是任何一个开发源代码或商用的LDAP目录服务器（或者还可能是具有LDAP界面的关系型数据库），因为可以用同样的协议、客户端连接软件包和查询命令与LDAP服务器进行交互。

与LDAP不同的是，如果软件产商想在软件产品中集成对DBMS的支持，那么通常都要对每一个数据库服务器单独定制。

1.2.1.3.2. 策略管理器（Policy Server）

Policy Server是IBM Tivoli Access Manager for e-Business的核心，它负责和其它IBM Tivoli Access Manager for e-Business功能模块的通讯工作，其中主要包括以下几个功能：

维护着授权策略库里的信息（例如：用户信息、被保护的资源信息、访问控制列表ACL的信息等）

如果在环境中有复制的授权策略库的话，他还负责同步其它的经过复制的授权策略库 保存着其它IBM Tivoli Access Manage功能模块的位置信息。

Policy Server的另外一个重要的功能就是负责维护逻辑Web名称空间，下面就对逻辑Web名称空间做一个介绍。

1.2.1.3.3. 逻辑Web名称空间

如果公司在一个逻辑Web名称空间组织公司Web资源，那么信息的管理可以得到简化。在这一逻辑空间中，内容的访问是通过一个互联网地址（或URL），这一地址反映了公司选择的一个逻辑结构。这样，就可以在逻辑上对信息进行组织，如按部门或项目组织信息，而不是按照资源的物理地点组织信息。

为创建一个逻辑Web空间，WebSEAL的位置应在现有的Web服务器及公司Web资源树之前。WebSEAL在引用Web服务器内容时使用一个用户定义的逻辑名（作为逻辑URL的一部分）。当一个用户（使用逻辑URL）请求访问某一资源时，服务器截取请求并使用智能节点（Smart Junctions）使Web服务器的逻辑名称与物理地址相匹配。事实上，IBM Tivoli Access Manager对逻辑URL进行翻译，确定信息所在的位置，并将信息返回给用户 — 而用户仍然不知道信息的物理位置。

这一结构允许在WebSEAL中设置访问政策，而不是个别地在存储信息的物理服务器上。智能节点功能可以支持任何后端Web服务器，包括Microsoft IIS、NetScape和Apache等。

除了可以透明地支持任何Web服务器，IBM Tivoli Access Manager逻辑Web空间还可以包括通过Web应用进行访问的资源，如PeopleSoft 7.5和SAP。这意味着IBM Tivoli Access Manager可以控制从传统数据库和其它后端应用对信息的访问，所采用的方式与处理静态Web资源时完全一样。下图说明了如何通过使用智能节点使一种逻辑编址模式更加容易。

在这一例子中，公司开发了一种编址模式，在这一模式中，一个部门的所有信息都可以在一个单一位置—市场行销部门找到，即使这些信息是在多个不同的计算机上。这样，用户可以更容易地访问信息，并使Web的管理更加容易。智能节点允许一个组织创建任何一

种对自己来说最有用的地址结构。例如，可以按照项目或主题对信息进行分组，而不是按照部门。此外，当组织的需要发生变化时，可以很容易地对分组进行调整。通过IBM Tivoli Access Manager，一个组织可以重新组织自己的Web名称空间，而不必在服务器之间移动基于Web的信息。

这一逻辑编址模式还使得网络的改变更加容易。如果必须在服务器间移动信息，或添加新的服务器，那么Web管理员可以在完成改变后调整智能节点。用户永远不会知道已经发生了变化 — 除了可以感到系统的速度更快，效率更高。

如本文在安全政策管理部分中讨论的那样，逻辑Web名称空间的使用还使安全管理得到简化，因为WebSEAL可以针对逻辑Web空间设置访问政策，而不是针对每一服务器。

1.2.1.3.4. 图形化管理界面（Web Portal Manager）

Web Portal Manager是一个基于Web的图形化管理工具。他主要用于IBM Tivoli Access Manager的安全策略的管理，其中包括对用户、用户组、角色、权限、策略和应用访问等的管理工作。

下图是一个Web Portal Manager的图例，

1.2.1.3.5. 命令行工具（PDADMIN）

这是一个基于命令行方式的IBM Tivoli Access Manager for e-Business管理工具，这个工具会提供一个全面的管理功能，而Web Portal Manager只能提供部分的管理功能。唯一的区别就是Web Portal Manager是一个图形化的工具，而pdadmin Command Line Utility是一个命令行的管理工具。

1.2.1.3.6. 反向代理服务器（WebSEAL）

WebSEAL为HTTP/HTTPS请求提供了细化的访问控制。WebSEAL是一个高性能、多进程、可以截获HTTP/HTTPS访问请求的Web服务器。WebSEAL为URL、CGI程序、HTML文件、JAVA Servlets、JAVA class files等资源提供了访问控制的管理。

WebSEAL还可以为后台基于Web的资源提供单一登陆的管理能力。

1.2.1.3.7. 授权服务器（Authorization Server）

在和传统应用作集成的时候，应用程序使用由Authorization API提供的功能调用来和Authorization Server进行通讯。Authorization Server维护着一个授权策略库的备份并且作为一个授权的决策者。API把授权决策的请求发给Authorization Server。

Authorization Server在基于安全策略的前提下返还一个决策建议。Authorization Server同时还可以写下一个审计记录用于日后的核查。

1.2.1.3.8. 管理接口（Administration API）

为了提供更为强大的管理功能，IBM Tivoli Access Manager for e-Business不仅提供了图形和命令行方式的管理工具，而且还为应用开发人员提供了方便实用的管理用API – Administration API，应用开发人员可以通过这些API直接与Policy Server进行通讯，管理在IBM Tivoli Access Manager for e-Business上的资源，例如：用户和用户组的信息、Web资源信息、访问控制列表（ACL）、Web名称空间等信息。现在，Administration API支持JAVA和C/C++两种编程语言，具体的使用方法，可以参考IBM Tivoli Access Manager for e-Business产品盘上的使用手册。

1.2.1.3.9. 授权接口（Authorization API）

IBM Tivoli Access Manager for e-Business不仅为应用开发人员提供了用于管理的API，而且还为他们提供了用于用户认证和授权判定的Authorization API，应用的开发人员可以通过使用这些API来对用户的身份进行确认，并且对用户提出的访问请求进行判定。现在，Authorization API支持JAVA和C/C++两种编程语言，具体的使用方法，可以参考IBM Tivoli Access Manager for e-Business产品盘上的使用手册。

1.2.2. IBM Access Manager for e-Business产品功能

1.2.2.1. 集中的用户管理

通过IBM Tivoli Access Manager for e-Business可以集中地管理企业LDAP服务器的所有用户，例如：用户的创建、用户状态的改变、用户的删除等。

为了符合企业的人员结构和管理层次，IBM Tivoli Access Manager for e-Business可以实现用户的分层管理，例如：全国中心的管理员可以管理全国范围的用户信息；北京市的管理员只可以管理北京市的用户信息；东城区的管理员则只能管理东城区的用户信息，它不能管理北京市的用户信息或者其他区的用户信息。

1.2.2.2. 集中的安全策略管理

在公司传统的应用中，安全管理（包括：用户库、用户的认证和授权、用户登陆和访问的记录和审计等）会由于应用的不同而不同，不同的应用实施的安全策略也会有所不同。因

此，在公司内部没有一个统一的安全策略管理，而只是一些分散的安全策略的管理，从而会大大增加由此引起得安全隐患和管理的复杂度。

我们的目标就是建立一个整体的安全管理策略。所有安全策略的定制、修改和删除等操作都通过一个统一的平台来完成，从而达到统一管理企业内部安全策略的目标。

1.2.2.3. 集中的Web资源管理

通过IBM Tivoli Access Manager for e-Business可以管理在企业Web环境中存在的各种各样的Web资源，例如：

? Web服务器上的静态页面（HTML）

? Web服务器上的动态页面（CGI、JSP、ASP等），如下图所示：

? Web应用服务器（Websphere）上的资源（Servlet、EJB）

? Web门户服务器上的资源（Portlet、Pages、Place等），如下图所示：

1.2.2.4. 灵活多样的用户身份认证方式

WebSEAL提供了一个灵活的身份认证服务，并能够通过IBM Tivoli Access Manager交叉域身份认证服务（CDAS）与一种身份认证机制集成在一起。

? 基于表单的登录 ? HTTP 基本认证

? 数字证书 (X.509v3) - IBM Tivoli Access Manager可与大量流行的公钥基础架

构（PKI）解决方案集成，其中包括Tivoli SecureWay Public Key Infrastructure和Entrust PKI。IBM Tivoli Access Manager支持证书签名和撤销检查。它还能够支持将公钥证书映射为访问许可。 ? RSA SecurID Token ? WAP身份认证机置

? 资源敏感的认证 – 对于特殊的资源需要额外的用户认证机制，例如：在访问一般

资源是只需要使用HTTP的基本认证机制，但当这个用户访问其它更为机密的信息使，还会提示用户提供数字证书来再次确定身份。

? EAI（External Authentication Interface）：利用外部提供的认证机制来进行认

证。Tivoli Access Manager for e-Business以前一直只能通过基于C语言的机制来实现用户个性化认证机制，从而或者产品支持的认证方式。目前，有许多的工具和案例都是通过这个接口扩展实现的。从6.0版本开始，Tivoli Access Manager for e-Business引入了一种新的认证选项-外部认证接口（External

authentication interface, EAI），它支持通过HTTP协议与认证断言进行通信。这意味着对外部认证服务的实现方式几乎没有任何的限制。例如，外部认证服务可以运行于J2EE或者.NET应用服务器，与用户进行交互，访问任何进行认证判定时所需要的数据，同时把任何需要的属性信息加入到用户的身份信息中。Tivoli Access Manager for e-Business还包括一个限制使用许可的Tivoli目录集成软件（IBM Tivoli Directory Integrator），通过它来更加轻松的使用外部认证接口。目录集成软件是一个元目录管理和数据复制解决方案，它能够在异质的数据源中方便的进行数据交换。Tivoli Access Manager for e-Business中提供了一个使用目录集成软件实现外部认证接口的范例，用户可以免费下载。 ? 其它客户化的方法

IBM Tivoli Access Manager还可与任何第三方身份认证引擎集成。在很多情况下，一个组织往往已经拥有一个部分网络资源的访问权限数据库，而IBM Tivoli Access Manager外部身份认证服务（External Authorization Service）可以将现有的身份认证引擎和规则引擎合并在一起。外部身份认证服务可以调用适当的外部应用来确定一个用户是否

拥有某一资源的访问权。这样，IBM Tivoli Access Manager就能够与组织现有的安全政策和基础架构集成在一起。这一集成使IBM Tivoli Access Manager的安全模型可以扩展到使用规则，如只允许在一天中的特定时间访问某些资源。

用户完成身份认证以后，IBM Tivoli Access Manager授予包括身份信息的身份认证证书，如用户属于哪些用户组以及用户与哪些角色相关。

1.2.2.4.1. 基于RSA SecurID Token的认证机制

IBM Tivoli Access Manager for e-Business提供了内置的认证模块来支持基于RSA SecurID Token的认证机制。这个认证模块是利用RSA Authentication API来开发的RSA SecurID客户端。WebSEAL提供了RSA认证客户端的功能，并且是经过RSA认证过的。

WebSEAL基于令牌的认证模块需要在WebSEAL服务器上安装RSA ACE/Agent客户端软件，并且配置可以和RSA ACE/Server进行通讯。WebSEAL本身的认证功能也许要配置为使用Token的认证机制。

在配置外WebSEAL上的认证模块后，用户可以使用RSA SecurID Token作为用户身份的认证机制。如下所示：

发工作，因此实施成本和维护成本都相对较高。第三个不足之处是：人员和后台系统中一对多对应关系的维护需要额外的工作。

1.3. IBM Tivoli Directory Integrator

1.3.1. 元目录产品和技术简介

随着现有企业规模的扩大，内部员工以及外部客户数目的增多。每个企业开始寻求一种方法或者技术，用以提高内部员工、外部客户、IT维护人员等对人员信息的操作和使用效率。一个坚固可靠的“身份结构”甚至可以帮助企业把他们内部的流程安全地展现给他们的供应商、客户以及大量的、自动的机器到机器的交易。对于您来说，目录树的概念也许并不陌生，它可以用于存储应用涉及到的用户信息（包括内部员工、外部的供应商、客户等）。在现在的企业中，目录树将会成为安全和应用架构的重要组成部分，甚至于是核心的地位，企业在选择目录树的时候，也会把它作为一个重要的、策略性的决定而认真考虑。

现在，一个典型的大企业会有超过100个不同的用户注册库为不同的应用服务。因此，企业也就会自然而然地面临到下面的这些挑战：

? 如何有效地管理这些不同的用户注册库？ ? 如何管理同一个用户在不同目录树中的信息？ ? 如何有效地控制用户对这些目录树的访问？ ? 如何管理和这些应用相关的安全隐患？

无疑，最新的技术，Meta-Directory（元目录），将会是最好的解决方法。元目录可以连接企业中不同来源的目录树中的数据，并且可以为这些目录树中的数据提供一个企业级的视图。它是一个非常好而且非常实用的技术，可以把不同目录树中的用户信息紧密地结合在一起，从而更有效、更方便地实现用户身份的确认、用户ID的部署。元目录技术强大的功能在于企业可以通过元目录技术快速高效地把那些为不同应用服务的目录树集成到一个企业级的目录树中，同时，原有应用的管理人员还可以利用他们已有的工具来管理他们本地的目录树。来自Gartner Group的调查表明，70%拥有1000台以上机器的企业将会在2005年之前使用Meta-Directory的技术。

为了满足这个增长的需要，IBM推出了基于元目录技术的自己的软件产品 – IBM Tivoli Directory Integrator。IBM Tivoli Directory Integrator是一个用于数据集成的中间件产品，它可以提供元目录服务，同时为人员和资源结构提供更为广阔的信息。它在实现以上功能的同时，保留了很大的灵活性，它不必引入一个用于存储所有数据的集中的数据库，它所实现的管理模式是一种分布式的管理模式。IBM Tivoli Directory Integrator完全开放的环境提供了强大的灵活性和扩展性，它已经做好准备来满足Web服务的需求。实际上，IBM Tivoli Directory Integrator对于它所工作的数据类型和操作系统没有任何限制，它可以对任何类型的数据进行操作。

IBM Tivoli Directory Integrator提供了许多内置的针对不同目录树、不同数据库、不同数据格式、不同传输协议的连接器；提供了一个开放式的Java开发环境以满足对连接器的扩展；提供了各种各样的工具用以配置连接器以满足对数据的各种操作。IBM Tivoli Directory Integrator可以帮助您：

? 在不同的应用和目录树资源之间同步和交换信息 ? 跨不同数据存储库的数据管理

? 建立一个坚固可靠的目录树结构，可以被众多的应用使用

? 集成基于目录树结构的信息，例如：产品名称和价格数据等这些并非和

用户相关的信息

不象第一代元目录产品，IBM Tivoli Directory Integrator把复杂的集成过程简化成一个个小的、可以管理的流程，叫做组装线（AssemblyLines）。组装线代表了被连接系统间的单独的数据流向，同时，它也可以很容易地进行开发和部署。IBM Tivoli Directory Integrator显著地减少了由于高度复杂的集成造成的人力、物力和财力的浪费。

IBM Tivoli Directory Integrator开放式的结构为企业提供了最大的自由度以保护他们已有的投资，例如：他们已有的目录树工具和数据，他们现有的IBM或者非IBM的解决方案。其他一些元目录产品和解决方案需要建立一个企业环境中的集中控制点，它使用的是一种占用大量网络和系统资源的、过时的目录树到目录树的技术，这种解决方案很难升级，并且有很大的限制。IBM Tivoli Directory Integrator使用的是一种开放的、灵活的拓扑结构，它摒弃了那种不灵活的使用集中数据库的结构，采用的是无永久数据储存的模式来提供显著的可扩展性和性能优势。

1.3.2. IBM Tivoli Directory Integrator概念

1.3.2.1. 问题的简化

无可置疑的是，元目录是一项非常复杂的技术，它涉及到许多领域中的技术，它的实现也是非常复杂的。IBM Tivoli Directory Integrator的方法是尽可能的简化这个复杂的、庞大的数据集成工程，把它分成若干个独立的单元，然后逐一地进行处理。这些独立的单元是就是数据流，他们代表着不同系统之间数据的传输和转译，在IBM Tivoli Directory Integrator中，我们把这些数据流叫做组装线（AssemblyLines）。每一条组装线提供了一个唯一的、智能的数据通路，我们可以对在这条通路上传输的数据做各种各样的处理，例如：数据集合、数据转译、遵循业务逻辑处理数据、事件触发机制、错误处理机制等。

1.3.2.2. 建立连接

组装线包括了多个双向的数据访问模块，我们叫做连接器（Connector）。每一个连接器针对于一种特定的数据资源，例如：数据库、目录树、消息队列等。

IBM Tivoli Directory Integrator包括有一个全面的连接器库，我们可以根据实际的环境对连接器进行选择和配置，并把他们放入到组装线中。每一个单独的连接器，或者整条组装线可以在任何时候做测试和调试工作。这会把一个集成的过程变成一个互动的、探索的过程，使得整个集成的过程变为简单而且愉快的配置和调试过程。

1.3.2.3. 业务规则和事件处理

当一个组装线完成之后，我们还可以通过编写Java程序来实现在组装线之上的额外的处理逻辑和功能。或者利用系统支持的编程语言（例如：JavaScript、VBScript、PerlScript）直接在组装线和连接器中加入额外的处理逻辑和功能。

为了支持被连接系统的实时的数据集成，IBM Tivoli Directory Integrator提供了大量的事件处理器（EventHandlers）。事件处理器是建立在连接器之上的，因此，每一个事件处理器都针对于一个特定的数据源。一旦设置好连接参数之后，事件处理器便被配置好等待变更事件的产生，例如：

? 数据库触发器 ? 目录树的变更

本文来源：https://www.bwwdw.com/article/nnjd.html