IBM Rational Team Concert 中组件特定操作的身份认证

核心提示：基于角色的权限控制在 IBM® Rational ®Team Concert 中有两种层次的操作，它们运行在 IBM® Jazz™ 技术平台之上：储存库层次的操作：在示例中，IBM Rational Team Concert 中组件特定操作的身份认证，会创建用户或者为用户建档，并在

基于角色的权限控制

在 IBM® Rational ®Team Concert 中有两种层次的操作，它们运行在 IBM® Jazz™ 技术平台之上：

储存库层次的操作：在示例中，会创建用户或者为用户建档，并在 Jazz 平台中创建项目区域。

特定组件的操作：也可以称作资源操作，您可以在某个项目或者团队区域内执行这些操作。这种类型的操作是由项目区域 Process Specification 或者团队区域 Process Customization 内定义的组件控制的。

注意：
Archive 和 Modify 项目区域是对特定组件的操作，而不是储存库层次的操作，因为权限设置是在 Process 组件中定义的，并且可以得到配置。

执行储存库层次操作的权限主要是由储存库层次的权限决定的，但是创建新的项目区域这种操作除外。例如，如果您没有分配有 JazzAdmins 的储存库角色，那么您就不能创建一个新的用户，在这种条件下，如果您创建一个新的用户，那么就会得到如图 1 所示的出错信息。

图 1. “Saving user failed”信息

为了创建新的项目区域，您需要同时拥有 JazzAdmins 角色权限以及必要的 客户访问许可证（Client Access License，CAL）。如果您没有这两样，那么您就会得到如图 2 所示的信息。

图 2. “Saving project area failed”信息

　　图片看不清楚？请点击这里查看原图（大图）。

作为 Jazz 储存库的注册用户，您执行特定组件的操作的权限最终是由以下这些因素决定的：

分配给您的客户访问许可证。

您所执行操作所属的管理团队区域或者项目区域。

分配给您的项目层次或者团队层次的角色，以及该角色所拥有的权限，它们是由 Process Specification 或者 Process Customization 定义的。

您是否拥有改写权限协议的管理员权限，是由 Administrative Override 的过程配置定义的。

客户访问许可证控制的操作

许多项目或者团队层次的操作不能被执行，除非用户拥有相应的客户访问许可证。例如，JazzAdmins 角色的用户在没有所需的客户访问许可证的情况下就不能执行 Save Query 操作。图 3 显示了操作的结果以及对应的解释：“分配给当前用户的客户访问许可证不允许执行‘Save Query’ 操作”。

图 3. “Missing required license”通知

　　图片看不清楚？请点击这里查看原图（大图）。

Jazz 和 Rational Team Concert 中的管理员角色

管理员角色有三个层次：

团队管理员角色

团队管理员可以编辑团队区域，就算他没有变动的权限也可。这种特权只限于对 Process Customization，团队区域成员以及角色分配所做的变动。它还适用于所有子级的团队区域以及它们所做的编辑。

项目管理员角色

项目管理员可以编辑项目区域，就算没有做出变动的权限协议也可。这种特权只适用于对 Process Specification，团队区域成员以及角色分配所做的变动。它还适用于所有的 Team Areas 以及它们所做的编辑。

储存库管理员角色

储存库管理员对应于 LDAP 组 JazzAdmins。他们可以创建和删除用户，项目以及管理储存库所涉及的一切操作，另外他们还有项目管理员的特权。

Administrative Override 特权

Administrative Override 特权分配给有权更改 Process 组件处理的操作的用户，这些操作例如有“Modify the iteration structure”以及“Modify the collection of team members”。它们可以在项目层次或者团队层次上执行，或者在 Process Specification （项目层次）以及 Process Customization（团队层次）上执行，就算基于角色的权限检查会显示“Permission Denied”，它们也可执行。

Process Specification 在 Project Area 编辑器的 Process Configuration 项下显示出来；，Process Customization 在 Team Area 编辑器的 Process Customization 项下显示出来。如果您拥有管理员特权，那么您就可以编辑 Process Specification 和 Process Customization。

Administrative Override 并不适用于非 Process 组件下的操作，例如 Work Items（项目层次的组件）或者 Source Control （团队层次）。但是，因为 Jazz 和 Rational Team Concert 组件拥有的操作许可证，都是由 Process Specification 定义和控制的，因此拥有管理员权限的用户可以编辑“权限”。所以，不要混淆“更改权限的权限”与“执行操作的权限”是十分重要的。

Administrative Override 的范例

Chris 是一位储存库层次的管理员以及 JazzAdmin 用户，但是他既不是团队成员，也不是“Scrum Test Project”的管理员。

图 4. “Scrum Test Project”概述

　　图片看不清楚？请点击这里查看原图（大图）。

但是，通过使用 Administrative Override 特权，Chris 可以向“Scrum Test Project”添加新的成员。

Rational Team Concert 按顺序执行以下的身份认证检查操作：

检查 Chris 是否拥有需要的客户访问许可证（CAL）。如果没有，那么就会显示一个与图 3 相似的出错信息，他所做的操作也就此废止。

检查 Chris 是否拥有基于角色的权限。因为 Chris 既不是团队成员也不是项目区域的管理员，所以会显示出“Permission Denied”的警告信息。

检查 Chris 是否拥有 Administrative Override 特权。如果他有，那么他所做的操作就会执行下去。

图 5. Administrative Override 操作

　　图片看不清楚？请点击这里查看原图（大图）。

基于角色权限查找过程

如 Administrative Override privileges 部分所述的那样，Administrative Override 并不适用于非过程组件拥有的操作。因此，对于大多数的特定组件的操作，权限查找结果就成为特定用户是否能够执行特定操作的关键。权限查找基于用户完整系列的角色，以及每个角色所分配的权限。

正如 Jazz.net 上 “ Process Behavior Lookup ”解释的那样 ：

“用户完整系列的角色是由管理团队区域分配的所有角色与项目区域和上级团队区域分配的任意角色组成的。为了计算所有用户的角色，我们不得不从各个团队区域与项目区域合并角色。这是怎么样影响排序的？首先考虑的是管理的团队区域分配的任意角色，然后是上级团队区域分配的角色，接着是项目区域中分配的角色，最后是应用于储存库所有部分的默认角色。这意味着团队区域内分配的角色要优先于那些上级团队区域或者项目区域内分配的角色 .如果团队想要来自上级团队区域的角色优先于低级层次中分配的角色，那么相同的角色可以在低级层次中再次分配给相同的用户。低级层次中分配的角色的优先级就是正在使用的。”

然后用户会保留每一个角色所拥有的权限。

基于角色权限查找的范例

接下来的范例向您展示了基于角色权限的查找。让我们从使用 Scrum 项目模板的项目区域 A 开始。项目 A 包含了一个 团队区域 B，，B 又含有一个子团队区域 C。

图 6. Project Area 与 Team Area 层级结构

　　图片看不清楚？请点击这里查看原图（大图）。

一个名为“Chris”的用户会添加至 A，B，C 的成员区域。

图 7. Chris 是项目 A 以及团队 B 和 C 的成员

　　图片看不清楚？请点击这里查看原图（大图）。

本例关注于“Delete the stream”操作，它属于 Source Control 组件。既然该操作是非过程组件操作，所以将不会发生 Administrative Override。Chris 是否能够执行该操作，完全由 Role-based permission lookup process 描述中陈述的权限查找协议所决定。

在什么地方更改权限设置

有三个地方，您可以更改“Delete the stream”操作的权限设置：

在项目 A 的 Process Configuration 视图下（图 9）

在团队 B 的 Process Customization 项下（图 10）

在团队 C 的 Process Customization 视图下（图 11）

首先，创建一个团队 C 所有的“Test Stream”（见于图 8）。这就使得团队 C 成为 Test Stream 的管理团队区域，以及可以对流执行的操作。

图 8. 团队 C 拥有的“Test Stream”

　　图片看不清楚？请点击这里查看原图（大图）。


图 9. 团队 A 的 Process Configuration 视图

　　图片看不清楚？请点击这里查看原图（大图）。


图 10. 团队 B 的 Process Customization 视图

　　图片看不清楚？请点击这里查看原图（大图）。


图 11. 团队 C 的 Process Customization 视图（在底端）

　　图片看不清楚？请点击这里查看原图（大图）。

确定默认的角色，也就是 Everyone，没有被授予“Delete the stream”操作的权限。

现在，依次进行下面表格中显示的五个场景。

表 1.场景 1

	团队 C	团队 B	项目 A
分配的角色	团队成员	团队成员	团队成员
Delete Steam 许可	是	否	是
Chris 是否可以删除“Test Stream”？是

表 2. 场景 2

	团队 C	团队 B	项目 A
分配的角色	团队成员	团队成员	团队成员
Delete Steam 许可	否	是	是
Chris 是否可以删除“Test Stream”？否

表 3. 场景 3

	团队 C	团队 B	项目 A
分配的角色	团队成员	Scrum 管理员	Project 拥有人
Delete Steam 许可	是	否	否
Chris 是否可以删除“Test Stream”？是

表 4. 场景 4

	团队 C	团队 B	项目 A
分配的角色	团队成员	Scrum 管理员	Project 拥有人
Delete Steam 许可	否	是	否
Chris 是否可以删除“Test Stream”？是

表 5. 场景 5

	团队 C	团队 B	项目 A
分配的角色	团队成员	Scrum 管理员	Project 拥有人
Delete Steam 许可	否	否	是
Chris 是否能够删除“Test Stream”？是

因为团队 C 是管理性的团队区域，所以权限查找基于分配给团队 C 中 Chris 的角色，而他在团队 B 和项目 A 中扮演的角色也不同，同时分配该各个角色的权限也有所不同。

在第一个和第二个场景中，因为 Chris 在三个层次上都分配有团队成员的角色，而团队 C 中的团队成员角色要优先于团队 B 和项目 A 中的团队成员角色，因为团队 C 是管理团队。因此，如果团队 C 中的团队成员角色被赋予了“Delete the stream”的权限，那么 Chris 就可以删除 Test Stream 项目了。如果没有这个权限，那么操作的结果就是“Permission Denied”。

对于其余的场景，因为不同的角色在不同的层次上分配给 Chris，所以权限查找将会按照以下顺序来进行 ：

来自团队 C 的团队成员角色

来自团队 B 的 Scrum 管理员角色

来自项目 A 的 Project 拥有人角色

如果这些角色中的任意一个被赋予了“Delete a stream”的权限，那么 Chris 就能删除 Test Stream 了。

总结

现在您对影响特定组件操作身份认证的不同方面已经有了一个基本的了解，这些操作例如客户访问控制许可证以及 Administrative Override 特权。现在您已经知道，Rational Team Concert 中基于角色权限查找背后隐藏的逻辑性原理。