IBM® WebSphere® Service Registry and Repository (以下称为 WSRR)基于 WebSphere Application Server（以下称为 WAS）的安全机制保证了只有授权用户才能访问特定资源。默认情况下，WSRR 支持粗粒度的访问控制，然而大多数企业需要更细粒度的访问控制，例如为不同的用户提供针对不同对象的访问权限，为此 WSRR 提出了细粒度的访问控制。
本文接下来将向您介绍 WSRR 访问控制模型的结构，并由浅入深地说明粗粒度和细粒度的WSRR 访问控制的定义和配置方法。您可以在了解 WSRR 访问控制模型的基础上，通过阅读 WSRR 访问控制应用场景案例来更好地了解 WSRR 访问控制。
WSRR 是一个基于 WebSphere Application Server（以下称为 WAS）开发的符合 J2EE 规范的产品，因此 WSRR 的安全是构建在 WAS 基础之上的。当打开 WAS 的全局安全机制时，这些 J2EE 安全角色可以在运行环境中限制访问 WSRR 的角色。
WSRR 中定义的 J2EE 的安全角色（图 1-1）包括：
- User
- Administrator
图1-1 J2EE 安全角色
为了能够访问 WSRR 的用户界面或调用 WSRR 的 API，用户需要被赋予一个 J2EE 角色。默认情况下，WSRR 将会把 Administrator 和 User 的角色赋予 AllAuthenticatedUsers 用户组。此用户组中的用户可以对 WSRR 进行任何操作。WSRR 的安全配置以 WAS 为基础，因此需要为 WSRR 配置 J2EE 安全角色的用户和组。WAS 中的 J2EE 角色的用户和组的来源包括以下四种类型（如图 1-2 所示）：
- LDAP：来自于 LDAP 用户目录的用户和组。
- Local operating system directory：来自于 WSRR 所运行的平台的操作系统的用户和组。
- Custom directory：来自于定制目录的用户和组。
- Federated repositories：来自于 Federated repositories。
图1-2 WAS 中的用户和组来源
J2EE 安全角色提供的访问控制的粒度较粗，它只能控制谁能访问 WSRR 的用户界面和 WSRR 的 API，而不能控制 WSRR 中的对象，因此 WSRR 提供了更细粒度的访问控制方式，即通过对于不同角色（Role）赋予不同许可（Permission）来控制对 WSRR 中存储的对象的访问。用户可以在如图 1-3 的配置视图下根据需求配置细粒度的角色定义。
图 1-3 WSRR访问控制角色
许可（Permission）用于表示对目标对象所能够实施的操作，它的数据结构包括三项内容（如图 1-4 所示）：
图 1-4 WSRR 中的角色与许可
1. 许可名称（Permission Name）用于表示许可名称。
2. 许可操作（Permission Action）用于表示用户在被赋予某种许可后所能够进行的操作，其中包括六种类型（图 1-5）：
- srrCreate：用于表示创建对象的操作。
- srrRetrieve：用于表示取回对象的操作。
- srrUpdate：用于表示更新对象的操作。
- srrDelete：用于表示删除对象的操作。
- srrTransition：用于表示治理生命周期状态转换的操作。
- srrManageGov：用于表示启动或终止治理的操作。
图1-5 操作类型
3. 许可目标（Permission Target）用于表示许可的目标操作对象，我们可以通过 XPATH 定位目标对象。
WSRR 访问控制许可如图 1-6 所示。
图 1-6 WSRR 访问控制许可
图 2-1 说明了一个 WSRR 访问控制的应用场景，它描述了 JK 证券公司的不同角色的工作人员根据业务需求通过使用 WSRR 访问控制模型实现业务功能的场景。
图 2-1访问控制应用场景
JK 证券公司营销策划部根据中国用户的需求，计划开发一个全新的投资海外市场的 QDII 基金产品 China QDII，于是在 WSRR 创建了一个新的业务应用- China QDII。这个新的业务应用有一系列的业务流程构成，营销策划部在 WSRR 创建相应的业务流程对象。当营销策划部在 WSRR 中建立了业务流程以后，就将这个业务模型移交给产品开发部进行具体的 IT 技术层面的实现。产品开发部根据营销策划部构建的业务模型进行产品的开发，并将开发出来的服务对象保存在 WSRR 中，因此 WSRR 中保存了产品的开发过程中的不同开发阶段的服务信息。在产品开发部门完成了产品的开发后，产品将会正式上线供用户使用。
针对以上需求，WSRR 的用户可以划分为以下四种角色：
- 产品分析师（Analyst）
- 产品架构师（Architect）
- 产品开发人员（Developer）
- 用户（User）
针对不同的角色，其访问控制设计如下：
- 产品分析师（Analyst）拥有创建、查询、更新、删除业务模型对象的权限。
- 产品架构师（Architect）拥有创建、查询、更新、删除技术模型对象的权限。
- 产品开发人员（Developer）拥有创建、更新、删除、治理服务的权限。
- 用户（User）拥有查看已上线的服务的权限。
具体权限设置请参照下载内容。
访问控制应用场景的流程如下：
1. 产品分析师（Analyst）根据需求在 WSRR 中构建业务模型对象，例如应用、流程、服务、组织、契约。如图 2-2 所示：
图 2-2 产品分析师构建业务模型对象
2. 产品架构师（Architect）在 WSRR 中查找业务模型对象（应用、流程、服务、组织、契约），并在 WSRR 中构建技术模型对象。如图 2-3 所示：
图 2-3 产品架构师构建技术模型对象
3. 产品开发人员（Developer）在 WSRR 中查找业务模型对象和技术模型对象，并在 WSRR 中创建服务。如图 2-4 所示：
图 2-4 产品开发人员创建服务
4. 用户（User）可以在 WSRR 中查找已上线的服务。如图 2-5 所示：
图 2-5 用户查找已上线的服务
基于以上的场景，不同用户角色和许可的配置步骤如下：
1. 在 WAS 控制台中配置 “ServiceRegistry” 和 “ServiceRegistryTS” 的 “Security role to user/group mapping” 选项，选择 “Administrator” 和 “User” 的 “All authenticated” 选项（图 2-6）。
图 2-6 配置 J2EE 角色
2. 在 WSRR 的配置界面（图 2-7）中创建四种角色：
- 产品分析师（Analyst）
- 产品架构师（Architect）
- 产品开发人员（Developer）
- 用户（User）
图 2-7 创建新角色
3. 为每一种用户创建并添加许可权限。选择角色，点击新建许可权限。添加许可权限的名称、动作、目标（图 2-8）。
图 2-8 创建许可权限
4. 为每种角色查找并添加用户（如图 2-9）。A 用户赋予产品分析师（Analyst）角色，B 用户赋予产品架构师（Architect）角色，C 用户赋予产品开发人员（Developer）角色，D 用户赋予用户（User）角色。
图 2-9查找并添加用户
5. 配置完成后，角色和许可权限设置如图 2-10 所示。
图 2-10 角色和许可权限设置
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-589248/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14789789/viewspace-589248/
325
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
