级别: 初级 Naga Praveena Palasamudram (pnpraveena@in.ibm.com), 资深软件工程师, IBM Suma C. Shastry (suma.chakrabarti@in.ibm.com), 高级软件工程师, IBM Aruna Dadi (dadi.aruna@in.ibm.com), 软件工程师, IBM
2007 年 12 月 17 日 IBM® DB2® Content Manager (CM) 提供了一种灵活的方法为您的 Enterprise Content Management 系统定义安全性。根据业务需求的不同,您可以为您的 ECM 系统设计宽松或者严格的安全性。CM 通过身份验证和授权提供了各种级别的安全性,并且使用权限集合和访问控制列表(Access Control Lists,ACL)提供严格的授权机制。本文将探究各种可以保护 ECM 数据的方法。
简介
IBM DB2 Content Management 系统是众多得到广泛应用的企业内容管理产品之一,可用来管理结构化和非结构化的信息。它提供了各种具有特定用途或功能的产品。有关这些产品及其特性的更多信息,请访问 IBM DB2
Content Manager Information Center。
本文涵盖了 CM 安全模型所涉及的各个方面和概念。查看对 CM 系统进行身份验证的不同方法以及各种级别的授权。本文借助示例演示了权限集合和访问控制列表,并授权给 CM 实体,如用户、用户组、项目类型、项目、工作流等。本文还讨论了一个业务场景,演示了一个 CM 系统,其中各个 CM 实体使用不同的安全级别。
CM 安全模型
IBM DB2 CM 提供了灵活的安全模型,管理员可以使用它确定对 ECM 系统应用哪种安全类型。根据业务需求,可以为 ECM 系统设计严格或宽松的安全性。IBM DB2 CM 通过身份验证和授权提供了各种级别的安全性。
图 1. 安全模型
IBM DB2 CM 支持三种级别的用户:OS 级别、CM 级别和 LDAP。然而,用户不必担心如何进行身份验证。CM 使用权限集合和 ACL 提供了一种严格的粒度级授权机制。它支持扁平安全模型,在这种模型中,系统中保存的所有文档/项目都具有相同级别的安全定义。它还提供了一种更加安全的模型,其中的每个项目或文档都具备不同的安全级别。权限、权限组、权限集合 和 ACL 形成了 IBM DB2 CM 授权系统的基本结构,本文后面将详细讨论。
身份验证
CM 系统用户可以大致分为以下几类:
-
管理用户:管理用户必须在 OS 级别定义。他们使用系统密码登录到 CM 系统。这些用户的用户 id 和密码由 IBM DB2 CM 的底层 RDBMS(IBM DB2 或 Oracle)进行验证。管理用户能执行所有数据建模操作,例如项目类型创建、定义 ACL,等等。有关 CM
数据建模的更多信息,请参见 参考资料 一节。IBM DB2 CM 在安装过程中将创建一个管理用户。默认管理员 id 为 ICMADMIN。
-
非管理用户:非管理用户只能由 CM 系统定义,并且不属于 OS 用户。CM 系统对这些用户进行身份验证并使用共享的数据库连接 id 连接到数据库。默认的数据库连接 id 为 ICMCONCT。然而,管理员也可以通过 System Administration Client > Tools
> Manage database connection id 菜单对这个 id 进行配置。注意: 每个库只能有一个连接 id。
IBM DB2 CM 还支持与 LDAP 目录的集成。您可以使用称为 LDAP user import tool 的工具从 LDAP 目录中将用户目录列表导入到 CM 系统。一旦将这些用户导入到 CM 系统,CM 将使用 LDAP 对这些用户进行身份验证。
除了上面提到的身份验证以外,CM 系统还支持单点登录。您可以在 IBM DB2 CM 安装过程中启用这个特性。 有关 IBM DB2 CM 单点登录的更多信息,请访问 IBM
DB2 Content Manager Information Center。
授权
CM 使用权限、权限组、权限集合和 ACL 对用户进行授权,从而对特定项目执行特定操作。您可以通过 CM System Administration Client 进行创建。
权限和权限组
要访问 CM 系统并执行某种 CM 功能,您需要拥有相对应的权限。CM 系统为用户提供了近 100 种预定义的权限。为了便于管理,CM 为管理员提供了一种方便的方法,可以对这些权限进行分组。使用权限组,管理员可以根据各种因素,例如用户执行的角色和使用的功能,对一组权限进行分组。一个权限可以属于多个权限组。
权限集合
IBM DB2 CM 不允许直接将权限分配给用户或用户组。但是,可以使用权限集合 这样做。权限集合由一组权限组成。将权限集合分配给用户,然后对用户进行验证以检查其是否具备执行某项 CM 功能/操作的权限。
下面的图 2 中展示了如何使用权限和权限组生成权限集合。来自多个权限组的权限可以构成一个权限集合。
图 2. 权限集合
您可以从左侧的面板中选择特定的权限组,从而挑选希望添加的权限,以便只显示所选权限组包含的权限。
权限集合有三种用途:
-
在创建用户时,为用户提供最大限度的权限:在创建用户时,需要为用户定义能够拥有的最大权限。可以选择已有的权限集合,也可以创建新的权限集合。这是用户对任何 CM 实体(如项目类型、项目、ACL、处理、工作节点等)所拥有的最大权限。在结合 ACL 规则时,可以减少这些权限。
图 3. 为新用户分配权限集合
-
在创建 ACL 时:
图 4. 在创建 ACL 时使用权限集合
-
如果支持域,则为域分配权限集合。本文稍后将讨论 域。
访问控制列表(ACL)
访问控制列表为用户和用户组定义了对特定 CM 实体的访问级别。在运行时执行创建、读取、更新或删除操作时使用。ACL 最重要的内容是其中的规则。例如,当用户发送请求以添加特定项目类型的项目时,根据 ACL 绑定 级别,CM 系统对 ACL 以及用户的最大权限集合进行检查,查看他是否有权添加项目。CM 还允许绕过 ACL 检查。这可以通过将用户的 “最大权限集合” 设置为 ItemSuperAccess 权限来实现。
 |
预定义的 ACL
IBM CM 为用户提供了四种不同的 ACL,管理员可以使用并进行修改:
-
SuperUserACL:这是在安装过程中创建的空 ACL。也是对用户组使用的默认 ACL。
-
NoAccessACL:该 ACL 阻止用户对对象执行任何操作。其使用范围非常有限。
-
PublicReadACL:允许所有 CM 用户读取实体。只在启用了公共访问的时候才会发挥作用。
-
DocRouteACL:它是文档发送 ACL。默认情况下,它不包含任何 ACL 规则。用户需要添加 ACL 规则,以使其他用户执行文档发送操作。
|
|
用户的 ACL 规则覆盖了用户组的 ACL 规则。换而言之,如果一个 ACL 具有两个规则,一个用于用户,另一个用于该用户所属的用户组,那么后者将被放弃不用,而使用针对特定用户的 ACL。但是,用户组 ICMPUBLIC 是个例外。如果一个 ACL 中的一个规则用于用户,另一个规则用于 ICMPUBLIC,那么两个规则都有效,只要满足任何一个
规则,用户就能够进行访问。
示例 1:用户组的 ACL 规则具有较低级别的访问权限,假设是读访问权,而用户的 ACL 具有较高级别的访问权限,假设为编辑访问权。用户实际获得的访问权限是编辑访问权。这种场景同样适用于 ICMPUBLIC 组。
示例 2:假设启用了公共访问,如果 ACL 的一个规则为用户具有读访问权,而 ICMPUBLIC 具有编辑访问权,那么,如果操作需要编辑访问权,则向用户授予编辑访问权,当然,前提是她的最大权限集合 允许执行该操作。
注意:在上面的示例中,前提条件是,分配给用户的最大权限集合包含编辑权。
用户获得的对特定实体的实际访问权限为以下内容的交集:
ACL 绑定
ACL 绑定级别定义了在运行时对哪些内容应用 ACL,这些绑定都是在创建项目类型时定义的。可以在以下级别绑定 ACL:
- 项目类型级别:特定项目类型的所有项目具有相同的 ACL。
- 项目级别
公共访问
公共访问是一种使 CM 能绕过 ACL 检查的方法。如果启用了公共访问,所有用户都将成为 ICMPUBLIC 用户组的成员,因此,针对 ICMPUBLIC 的所有规则都回被激活。可以使用 LS 配置对话框启用公共访问。如果启用了公共访问,ICMPUBLIC 将拥有比任何其他 ACL 更高的优先权。如果没有启用,所有指定 ICMPUBLIC 的 ACL 将被忽略。
简而言之,权限定义了用户可以执行哪些功能,而 ACL 定义了不同用户/用户组对特定实体的访问级别。
例如,如果用户想要编辑某个项目的属性,那么:
- 用户的最大权限集合中应该包含编辑访问权
- 该项目类型的 ACL 应该包含允许用户编辑项目属性的规则
管理域
管理域使 CM 管理用户(也称为超级用户)能够将管理职责分配给其他管理员,每个管理员被限制在特定的部分或域。超级用户定义域管理员。每个域管理员只能管理自己负责的域。可以通过 System Administration Client 启用管理域。启用了域之后,将不能够废除。默认情况下,在启用域时,将创建三个域 —— 超级域、默认域和公共域。这三种域不能够废除。
一个用户/用户组只能属于一个域。每个域将有一个超级管理员和几个域管理员。可以跨多个域共享权限集合和访问控制列表(换而言之,一个权限集合或 ACL 可以属于多个域)。本文没有深入介绍管理域,因为这已超出了本文的讨论范围。让我们看一下如何向管理域添加用户、权限集合和 ACL。
图 5. 向域添加用户
图 6. 向多个域启用权限集合
图 7. 向多个域启用 ACL
案例分析
让我们假设一个项目交付系统,其中涉及扮演着不同角色的用户和多种内容组合。假设一个系统具有如下用户组:
-
销售人员:销售人员应该能够编辑销售指标并查看/读取产品文档。但是,他们不具有查看架构/设计文档、源代码、批准或测试结果的权限。
-
架构师:架构组不需要了解销售指标和测试结果。但是,该组的成员能够编辑架构文档、功能规范并查看源代码。
-
开发人员:该组的成员能够创建/更新/删除源代码、功能规范并查看测试结果。
-
测试人员:测试人员能够创建/更新/删除测试用例、测试结果,并查看产品/版本、功能规范和产品文档。
要设置上述系统,执行下面列出的步骤(本案例分析假设未启用公共访问)。
表 1. 步骤 1
创建必须的权限和权限集合
| 权限集合 | 权限 |
|---|
| ReadSet | 读取、查询 | | EditSet | 读取、创建、更新、删除、选择 | | CreateSet | 读取、创建、选择 | | Update | 读取、更新、选择 |
表 2. 步骤 2a
创建所需的用户和用户组
| 用户组 | 用户 |
|---|
| Dev | D1、D2、D3 | | Architect | A1、A2、D3 | | QA | T1、T2 | | Sales | S1、S2 |
表 3. 步骤 2b
为用户分配最大权限集合
| 用户 | 所分配的最大权限集合 |
|---|
| D1、D2 | EditSet | | D3 | ReadSet | | A1、A2 | EditSet | | T1、T2 | EditSet | | S1、S2 | EditSet |
 |
规则
- 用户获得的实际访问权限是最大权限集合与相关 ACL 的交集。
- 用户 ACL 覆盖用户组 ACL。
- 如果用户属于多个用户组,则用户获得所有用户组的 ACL。
|
|
表 4. 步骤 3
创建 ACL
| ACL 名称 | 用户,权限集合 |
|---|
| DevACL | 开发人员 - EditSet 架构师 & QA - ReadSet 销售人员 -
NoAccessACL | | CodeACL | 开发人员 - EditSet 架构师 - ReadSet | | ArcACL | 架构师 - EditSet 开发人员 - ReadSet D1 - EditSet QA 和销售人员 - NoAccessACL | | TestACL | QA - EditSet 开发人员 & 架构师 - ReadSet 销售人员 -
NoAccessACL | | SalesACL | 销售人员 - EditSet 开发人员、架构师 QA - NoAccessACL |
注意:本案例分析还使用了 NoAccessACL,由 CM 预定义。
表 5. 步骤 4
使用相关的 ACL 创建项目类型
| 项目类型名称 | ACL | 备注 |
|---|
| ArchDocs | ArcACL | 同时包含架构和设计文档的项目类型 | | FunctionalSpecs | DevACL | 包含功能规范,将与 QA 共享以编写功能验证测试套件 | | Code | CodeACL | 源代码,只有开发人员能够访问 | | SalesDocs | SalesACL | 销售文档,包含客户列表、客户的产品级别、客户数量、每个销售人员的季度销量等等 | | Testcases | TestACL | 测试用例、测试套件、测试结果、有关如何运行测试套件的文档等等 |
根据 规则,表 6 列出了每个用户获得的访问权限:
表 6. 获得的有效访问权限
| 项目类型 | 获得的访问权限 | 说明 |
|---|
| ArchDocs | A1, A2, D3 - EditSet D1 - EditSet D2 - ReadSet T1, T2, S1,
S2 - NoAccess | 由于 D3 同时属于 Architect 组和 Dev 组, D3 获得 Edit 访问权限(参见规则 3)。 ArchACL 的 D1 具有编辑访问权,Dev 组具有读访问权, D1 获得编辑访问权(参见规则 2)。 | | FunctionalSpecs | D1,D2, D3 - EditSet A1, A2, T1, T2 - ReadSet S1, S2 - NoAccess | 即使用户组 Arch、QA 具有 “EditSet” 的最大权限,他们也只能获得读访问权(参见规则 1)。 | | Code | D1, D2, D3 - EditSet A1, A2 - ReadSet T1, T2, S1, S2 - NoAccess | 由于 CodeACL 没有包含针对 QA 和 Sale 的任何规则, 他们没有获得任何访问权限。 | | SalesDocs | S1, S2 - EditSet A1, A2, D1, D2, D3, T1, T2 - NoAccess | (参见规则 1) | | TestCases | T1, T2 - EditSet D1, D2, D3, A1, A2 - ReadSet S1, S2 - NoAccess | (参见规则 1) |
结束语
图 8 所示的流程图总结了当用户试图在 CM 系统中创建项目时,授权机制如何发挥作用。
注意: 在启用 “公共访问” 时,以下流程仍然有效。
图 8. 流程图
建议您参考 参考资料 小节,了解有关 CM 系统的各个方面。
致谢
衷心感谢 IBM DB2 CM Library Server 团队主管 Phong K Truong 和 Monica Ho。同样感谢为本文提出宝贵建议和评论的所有人员。
参考资料 学习
获得产品和技术
- 使用 IBM 试用软件 构建您的下一个开发项目,可直接从 developerWorks 下载获得。
讨论
作者简介  | |  | Praveena 是 IBM 印度软件实验室 Information Management 团队的主管。她在 IBM 工作了 7 年,主要关注 DB2 Content Manager Library Server 开发和支持。目前,她致力于提供 L3 支持和 IBM FileNet Content Services 开发。她是经过 IBM 认证的 Content Manager 解决方案设计师和 IBM DB2 DBA。 |
 | |  | Suma Shastry 是位于印度 IBM 软件实验室 Information Management 团队的一名项目主管。她在 DB2 方面拥有六年的工作经验,主要从事 DB2 工具的开发。她是 IBM 认证的 DB2 DBA,并且在 SVT、FVT、回归和测试自动化方面具有丰富的专业知识。 |
 | |  | Aruna 是 Information Management 团队的一名开发人员,主要研究 ISL。她致力于提供 L3 支持和 IBM DB2 Content Manager Library Server 开发。她是一名 IBM 认证的 DB2 Associate。 |
对本文的评价
|