角色與角色指定

「角色」定義了與一或多個目標系統或應用程式相關的一組許可。「角色與資源」索引標籤可讓使用者申請「角色指定」，即角色與使用者、群組或容器之間的關聯。「角色與資源」索引標籤還可讓您定義「角色關係」，這會在角色階層中的各角色之間建立關聯。

您可以直接將角色指定給使用者，在這種情況下，「直接指定」可為使用者授予與角色相關聯之許可的明確存取權限。您可以定義「間接指定」，這樣可讓使用者透過群組、容器中的成員資格或角色階層中的相關角色獲取各種角色。

申請角色指定時，您可選擇定義「角色指定生效日期」，以指定該指定生效的日期與時間。如果讓此選項保留為空白，則表示指定立即生效。

您還可以定義「角色指定過期日期」，以指定系統自動移除該指定的日期與時間。

當使用者申請角色指定時，「角色與資源子系統」會管理角色申請的生命週期。若要查看使用者或子系統自身對申請所執行的動作，可在「角色目錄」中的「申請狀態」索引標籤上檢查申請的狀態。

角色目錄和角色階層

「角色目錄」中必須已經定義好角色，使用者才能指定這些角色。「角色目錄」是儲存「角色與資源子系統」所需之所有角色定義和支援資料的儲存機制。為了設定「角色目錄」，角色模組管理員 (或角色管理員) 會定義角色和角色階層。

「角色階層」可在目錄中的各角色之間建立關係。定義角色關係可以簡化透過角色指定授予許可權限的任務。例如，您無需每當有醫生加入組織便指定 50 個獨立的醫療角色，而只需定義一個 Doctor 角色並指定 Doctor 角色與每個醫療角色之間的關係。為使用者指定 Doctor 角色可向這些使用者授予為每個相關醫療角色定義的許可權限。

角色階層支援三個層級。最高層級 (稱為業務角色) 定義的角色可定義在組織中具有業務意義的操作。中間層級 (稱為 IT 角色) 支援技術功能。階層最低層級 (稱為權限角色) 定義的角色可定義較低層級的權限。下面的範例顯示某醫療組織含三個層級的角色階層範例。階層的最高層級在左側，最低層級在右側：

圖 14-1 角色階層範例

較高層級角色自動包括它所包含之較低層級角色的權限。例如，「業務角色」自動包括它所包含之「IT 角色」的權限。同樣，「IT 角色」自動包括它所包含之「許可角色」的權限。

階層中同級角色之間不允許存在角色關係。此外，較低層級角色不能包含較高層級角色。

定義角色時，可以選擇為該角色指定一或多個擁有者。「角色擁有者」是指定為該角色定義之擁有者的使用者。針對「角色目錄」產生報告時，您可以根據角色擁有者過濾這些報告。角色擁有者不會自動擁有管理對角色定義所進行之變更的授權。在某些情況下，擁有者必須要求角色管理員對角色執行管理動作。

定義角色時，可以選擇讓角色與一或多個類別相關聯。「角色類別」可讓您對角色進行分類以方便管理角色系統。將角色與某個類別關聯後，瀏覽「角色目錄」時可將此類別用做過濾器。

如果角色指定申請需要核准，角色定義將指定有關協調核准所用之工作流程程序以及核准人清單的詳細資料。核准人就是可以核准或拒絕角色指定申請的人員。

職務分離

「角色與資源子系統」的主要功能是可用於定義職務分離 (SoD) 條件約束。職務分離 (SoD) 條件約束是定義被視為相互衝突的兩個角色的規則。「安全官」會為組織建立職務分離條件約束。透過定義 SoD 條件約束，這些安全官可以避免為使用者指定相互衝突的角色，或者維護稽核線索以追蹤允許違規的情況。在職務分離條件約束中，相互衝突的角色必須位於角色階層中的同一層級。

某些職務分離條件約束無需核准即可被覆寫，而其他職務分離條件約束則需要核准才可被覆寫。未經過核准即獲得許可的衝突稱為「職務分離違規」。經過核准的衝突稱為「職務分離已核准的例外」。「角色與資源子系統」不需要核准間接指定 (例如群組、容器中的成員資格，或角色關係) 引起的 SoD 違規。

如果職務分離衝突需要核准，條件約束定義將指定有關協調核准所用的工作流程程序以及核准人清單的詳細資料。核准人就是可以核准或拒絕 SoD 例外的人員。「角色與資源子系統」組態中會定義一個預設清單。但可在 SoD 條件約束的定義中覆寫此清單。

角色報告和稽核

「角色與資源子系統」提供了大量報告功能，可協助稽核員分析角色目錄，以及角色指定的目前狀態、SoD 條件約束、違規和例外。角色報告功能可讓角色稽核員及角色模組管理員顯示下列類型的 PDF 格式報告：

除了透過報告機制提供資訊以外，「角色與資源子系統」還可以設定為記錄 Novell 或 OpenXDAS 稽核用戶端。

角色安全性

「角色與資源子系統」使用一組系統角色來保護對「角色與資源」索引標籤中各項功能的存取權限。「角色與資源」索引標籤中的每個功能表動作都與一或多個系統角色對應。如果使用者不屬於與某個動作相關聯之角色的成員，「角色與資源」索引標籤上就不會顯示對應的功能表項目。

「系統角色」是安裝期間系統自動定義以進行所委託之管理的管理角色。這些改變包括：

下表詳細說明了各系統角色：

角色與資源服務驅動程式

「角色與資源子系統」使用角色與資源服務驅動程式來管理角色的後端處理。例如，它管理所有角色指定，啟動需要核准之角色指定申請及 SoD 衝突的工作流程，以及根據群組、容器成員資格及相關角色中的成員資格維護間接角色指定。該驅動程式還會根據使用者的角色成員資格向使用者授予和撤銷授權，並對已完成的申請執行清理程序。

如需角色與資源服務驅動程式的詳細資料，請參閱《Identity Manager 使用者應用程式：管理指南》。

關於資源提供

使用者應用程式內的資源功能主要用於為您提供執行資源提供動作的簡便方法。這些動作可讓您管理組織內的資源定義和資源指定。資源指定可以與公司內的使用者或角色對應。例如，您可以使用資源執行以下動作︰

當資源指定申請需要組織中一或多個人員的許可時，申請便會啟動工作流程。工作流程可以協調完成申請需要執行的各項核准工作。一些資源指定申請需要單個人員的核准；而另外一些申請則需要多個人員的核准。在某些情況下，申請無需任何核准即可完成。

以下業務規則控制著使用者應用程式內資源的行為：

工作流程設計人員和系統管理員負責為組織中的所有人設定使用者應用程式。資源工作流程的控制流及表單的外觀取決於「Identity Manager 適用的 Designer」中工作流程核准定義的定義方式。此外，您可以查看的內容和執行的操作通常由您的工作要求和權限層級來決定。

資源

資源是企業使用者需要有權存取的任何數位實體，如使用者帳戶、電腦或資料庫。使用者應用程式為一般使用者提供了一種簡便的方法來申請他們所需要的資源。此外，它還提供了一些管理員可用來定義資源的工具。

每個資源都對應於一個授權。一個資源定義不能有多個授權與其相繫結。一個資源定義可多次繫結至同一個授權，但每個資源的授權參數不同。

資源申請

資源只能指定給使用者，不能指定給群組或容器。但是，若某個角色指定給某群組或容器，則系統可能會自動為該群組或容器中的使用者授予存取與該角色相關聯之資源的權限。

資源申請可能需要核准。資源的核准程序可以由提供申請定義處理，或者由外部系統透過設定資源申請的狀態碼來處理。

若資源授予申請是透過角色指定啟始，則系統可能不會授予該資源，即使該角色處於已提供狀態。發生此現象最可能的原因就是未提供必要的核准。

資源申請可能會向使用者授予資源，或廢止使用者的資源。

角色與資源服務驅動程式

使用者應用程式使用角色與資源服務驅動程式來管理資源的後端處理。例如，它會管理所有資源申請、啟動資源申請的工作流程以及啟始資源申請的提供程序。