角色与角色指派

角色定义与一个或多个目标系统或应用程序相关的一组许可权限。通过角色和资源选项卡，用户可以请求角色指派，角色指派是角色与用户、组或容器之间的关联。通过角色和资源选项卡，用户还可以定义角色关系，用于在角色层次结构中建立角色之间的关联。

可以将角色直接指派给用户，在这种情况下，这些直接指派使用户可以显式访问与该角色关联的许可权限。也可以定义间接指派，从而允许用户通过角色层次结构中的组、容器或相关角色中的成员资格获取角色。

请求角色指派时，可以选择定义角色指派有效日期，用于指定指派生效的日期和时间。如果将该字段保留为空，则表示指派立即生效。

也可以定义角色指派失效日期，用于指定自动去除指派的日期和时间。

用户请求角色指派时，角色和资源子系统将管理角色请求的生命周期。要了解用户或子系统本身对请求执行了哪些操作，可以在角色编目的请求状态选项卡中检查请求的状态。

角色编目与角色层次结构

必须首先在角色编目中定义角色，然后用户才能开始指派这些角色。角色编目是所有角色定义以及角色和资源子系统所需支持数据的储存库。要设置角色编目，角色模块管理员（或角色管理者）应定义角色与角色层次结构。

角色层次结构建立编目中角色之间的关系。通过定义角色关系，可以简化通过角色指派授予许可权限的任务。例如，可以定义一个 Doctor 角色并指定这个 Doctor 角色与每个医疗角色之间的关系，而无需只要有医生加入贵组织，就指派 50 个不同的医疗角色。通过向用户指派 Doctor 角色，可以向这些用户提供为每个相关医疗角色定义的许可权限。

角色层次结构支持三个级别。最高级别定义的角色（称为“业务角色”）定义组织内具有业务意义的操作。中级角色（称为“IT 角色”）支持技术功能。层次结构最低级别定义的角色（称为“许可权限角色”）定义较低级别的特权。以下示例显示一家医疗组织的样本角色层次结构，其中包含三个级别。层次结构的最高级别位于左侧，最低级别位于右侧：

图 14-1 样本角色层次结构

较高级别的角色自动包含其包含的较低级别角色的特权。例如，一个“业务角色”自动包含该角色下包含的“IT 角色”的特权。同样，一个“IT 角色”自动包含该角色下包含的“许可权限角色”的特权。

层次结构中对等角色之间不允许存在角色关系。此外，较低级别的角色不能包含较高级别的角色。

定义角色时，可以选择为该角色指定一个或多个拥有者。角色拥有者是指定为角色定义的拥有者的一个用户。针对“角色编目”生成报告时，可以基于角色拥有者过滤这些报告。角色拥有者不会自动具备管理角色定义更改的授权。在某些情况下，拥有者必须要求角色管理员对角色执行任何管理操作。

定义角色时，也可以将该角色与一个或多个角色类别相关联。角色类别允许用户对角色分类，以便组织角色系统。将角色与类别关联之后，可以在浏览“角色编目”时将该类别用作过滤器。

如果角色指派请求需要批准，则角色定义将指定用于协调批准的工作流程细节以及批准者列表。批准者是可以批准或拒绝角色指派请求的个人。

责任分离

角色和资源子系统的一个关键功能是定义责任分离 (SoD) 限制。责任分离 (SoD) 限制是定义认为存在冲突的两个角色的规则。安全专员负责为组织创建责任分离限制。通过定义 SoD 限制，这些专员可以防止将用户指派给冲突的角色，或是维护审计追踪，以便跟踪允许冲突的情况。在责任分离限制中，冲突的角色在角色层次结构中的级别必须相同。

某些责任分离限制不经批准即可被覆盖，而其他的则需批准。无需批准即允许的冲突称为责任分离违例。已经批准的冲突称为已批准的责任分离异常。角色和资源子系统无需批准源自间接指派（例如组或容器中的成员资格或者角色关系）的 SoD 违反。

如果责任分离冲突需要批准，则该限制定义将指定用于协调批准的工作流程细节以及批准者列表。批准者是可以批准或拒绝 SoD 异常的个人。将定义一个默认列表，充当角色和资源子系统配置的组成部分。但是，可以在 SoD 限制的定义中覆盖该列表。

角色报告与审计

角色和资源子系统提供了一套丰富的报告工具，帮助审核员分析“角色编目”，以及角色指派与 SoD 限制、违反和异常的当前状态。这个角色报告工具允许角色审计员和角色模块管理员以 PDF 格式显示下列类型的报告：

除了通过报告工具提供信息之外，角色和资源子系统还可以配置为向 Novell 或 OpenXDAS 审核客户端记录事件。

角色安全性

角色和资源子系统使用一组系统角色来保护对角色和资源选项卡内的功能的访问。角色和资源选项卡中的每个菜单操作都映射到一个或多个系统角色。如果用户不是与某个操作关联的某一角色的成员，则角色和资源选项卡上将不显示相应的菜单项。

系统角色是在安装时由系统自动定义的管理角色，用于执行委派管理。这些更改包括以下几点：

下文将详细说明这些系统角色。

角色和资源服务驱动程序

角色和资源子系统使用角色和资源服务驱动程序来管理角色的后端处理。例如，管理所有角色指派，启动需要批准的角色指派请求和 SoD 冲突的工作流程，以及根据组和容器成员资格及相关角色中的成员资格维护间接角色指派。该驱动程序还根据用户的角色成员资格为其授予和撤消权利，并且执行已完成请求的清理过程。

有关角色和资源服务驱动程序的细节，请参见《Identity Manager User Application：管理指南》。

关于基于资源的供应

User Application 中的资源功能的作用是让您可以方便地执行基于资源的供应操作。通过这些操作，用户可以管理组织内的资源定义和资源指派。资源指派可以映射到公司内的用户或角色。例如，可以使用资源执行下列操作：

如果资源指派请求需要组织中一个或多个人的许可，则该请求将启动工作流程。工作流程可协调完成请求所需的批准。 有些资源指派请求需要一个人批准，而另一些请求则需要多个人批准。在某些实例中，可以不经任何批准完成请求。

以下业务规则控制 User Application 中资源的行为：

工作流程设计者和系统管理员负责为您以及组织中的其他用户设置 User Application。基于资源的工作流程的控制流程以及表单外观可能有所不同，具体取决于工作流程的批准定义在 Designer for Identity Manager 中的定义方式。此外，可以查看的内容以及可以执行的操作通常由您的工作要求和权限级别确定。

资源

资源是业务用户进行访问需要具有的任意数字实体，例如用户帐户、计算机或数据库。通过 User Application，最终用户可以方便地请求自己所需的资源。 此外，它还提供了管理员可用于定义资源的工具。

每个资源都映射到一项权利。资源定义只能绑定一项权利。资源定义可以多次绑定到同一权利，每个资源使用不同的权利参数。

资源请求

资源只能指派给用户。不能将它们指派给组或容器。但是，如果将某个角色指派给某个组或容器，则可能会自动授予该组或容器中的用户对于与该角色关联的资源的访问权限。

资源请求可能会需要批准。资源的批准进程可以通过供应请求定义处理，也可以通过外部系统处理（通过设置资源请求中的状态代码）。

如果某个资源授予请求是通过角色指派发出的，那么有可能即使供应了角色，也不会授予该资源。出现这种情况最有可能的原因是未提供必需的批准。

资源请求可以用于向用户授予资源，也可以用于撤消用户的资源。

角色和资源服务驱动程序

User Application 使用角色和资源服务驱动程序来管理资源的后端处理。例如，它管理所有资源请求、启动资源请求的工作流程，以及启动资源请求的供应处理。