认证与访问控制（崔永泉）访问控制第七章-基于角色访问控制的管理模型.pptVIP

* 在层次图中删除一个角色是一件复杂的事情 我们假定在一个授权范围内的角色可以由该授权范围的管理员删除， 而不管这个角色是如何加入到这个授权范围的 RRA97模型——Delete Role * 为了避免悬挂引用，RRA97提供两种选择： 被can_assign,can_revoke和can_modify引用的角色不能被删除。 当需要删除被can_assign,can_revoke和can_modify引用的角色时，可以使它们进入不活动状态（inactive, 休眠状态）。 RRA97模型——Delete Role * 插入一条过渡边是毫无意义的，因此我们只考虑在不可比角色间插入边。当一条边插入后，我们必须保证授权范围的封闭性没有被破坏， 插入边的两个角色必须具有相同的直接授权范围；或者 如果新插入的边的一个角色在授权范围内，而另一个角色在授权范围外，则授权范围的封闭性一定不能被破坏。 RRA97模型——Create RH * 删除过渡边不会改变角色层次，因此对过渡边的删除是毫无意义的。在RRA97中，我们只考虑那些在删除后会改变角色层次的边。如果边AB不是这样的，那么它就不适合作为被删除边。 RRA97模型——Delete RH * RRA97模型——Delete RH * RRA97模型——Delete RH * RRA97模型——总结篇 ARBAC97有三个部分组成： URA97用于用户—角色指派， PRA97用于权限—角色指派， RRA97用于角色—角色指派。 URA97和PRA97两者其实是相似的，都是基于先决条件和角色范围的概念 * RRA97模型——总结篇 RRA97区分三种形式的角色， ARA97处理ablity指派到UP—roles，类似与PRA97； GRA97处理将group指派到UP—roles，类似于URA97； UP-roles - UP-roles处理角色之间关系；定义四类操作：Create Role、Delete Role、CreateRH和DeleteRH； * Page: * 提纲 RBAC管理模型的产生背景 RBAC管理模型分类 URA管理模型分析 PRA管理模型分析 RRA管理模型分析 * 区分三种类型角色的主要原因是要用不同的管理模型来建立它们之间的关系。首先要区分的是abilities 一个ability是一个权限的集合，应当作为一个单一的单元指派给一个角色 RRA97模型——角色分类 * 比如，在银行应用中开一个帐户需要多种不同的权限，仅仅将这些权限的一部分指派到一个角色是没有意义的，因为需要整个权限的集合才能正确完成任务。因此应用开发者可以把这些权限组成一个集合，称之为abilities，它必须整体作为一个单元指派给角色 RRA97模型——角色分类 * ability的作用是集合权限以便管理员可以将它们作为一个单一的单元对待，因此将abilities指派到角色就和将权限指派到角色是十分相似的。为了方便，将abilities组织成层次结构（例如偏序结构） 因此可以改造PRA97模型以产生类似的ARA97模型来管理ability-role指派 RRA97模型——角色分类 * 引入abilities的概念后，对于用户也有相似的概念 一个group是一些用户的集合，它是作为一个单一的整体被指派到角色的。这样的group可以看作是一个队(team)，虽然它的成员随时间不同而有可能改变，但却是一个整体 RRA97模型——角色分类 * Groups也可以组织成层次结构。对于group-role指派，可以改造URA97模型而得到GRA97模型来管理group-role 指派 RRA97模型——角色分类 * 定义8 在ARA97模型中，ability-role指派和回收分别是 can_assigna ? AR ×CR ×2A can_revokea ? AR×2A 定义9 在GRA97模型中，group-role指派和回收分别是 can_assigng ? AR ×CR ×2G can_revokeg ? AR×2G RRA97模型——角色分类管理A * 对于这些模型，CR是UPR中的一些角色构成的先决条件的集合，先决条件分别由abilities和groups构成 一个ability的成员在一个UP-role中为真需要满足这个UP-role拥有这个ability，否则为假 相反地，一个group的成员在一个UP-role中为真需要满足这个UP-role由这个group所拥有，否则为假 Group UP-role