了解如何基於角色或者客戶訪問許可證分配權限
簡介：IBM Rational Team Concert 提供了豐富的組件來支持軟件生命周期管理。像 Process 和 Work 項目這樣由組件提供的操作是由相應的權限設置控制的。本文介紹了影響 Jazz 儲存庫中特定組件 操作身份認證問題的各個方面，以及隱藏在這些操作權限查找背後的邏輯。
基於角色的權限控制
在 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 中基於角色權限查找背後隱藏的邏輯性原理。
