权限设计原理

1 权限设计原理权限设计原理 一 一 权限设计概要权限设计概要 2 1 1 前言 2 1 2 目标 2 1 3 现状 2 二 二 权限设计原则权限设计原则 2 2 1 原则简述 2 2 2 相关名词解释 3 2 3 权限设计思想 5 2 4 权限设计示例 5 2 5 权限设计的扩展的思路 6 2 5 需要注意的几个问题 7 三 三 RBAC Role Based Access Control 模型介绍 模型介绍 8 3 1RBAC 发展历史 8 3 1RBAC 模型初探 8 3 1一个 RBAC 模型的实现 11 四 四 ACL Access Control List 介绍 介绍 12 4 1ACL Access Control List 概述 12 2 一 一 权限设计概要权限设计概要 1 11 1 前言前言 权限往往是一个极其复杂的问题 但也可简单表述为这样的逻辑表达式 判断 Who 对 What Which 进行 How 的操作 的逻辑表达式是否为真 针对不同的应用 需要根据项 目的实际情况和具体架构 在维护性 灵活性 完整性等 N 多个方案之间比较权衡 1 21 2 目标目标 直观 因为系统最终会由最终用户来维护 权限分配的直观和容易理解 显得比较重 要 系统不辞劳苦的实现了组的继承 除了功能的必须 更主要的就是因为它足够直观 简单 包括概念数量上的简单和意义上的简单还有功能上的简单 想用一个权限系统 解决所有的权限问题是不现实的 设计中将常常变化的 定制 特点比较强的部分判断为 业务逻辑 而将常常相同的 通用 特点比较强的部分判断为权限逻辑就是基于这样的思 路 扩展 采用可继承的方式解决了权限在扩展上的困难 引进 Group 概念在支持权限以 组方式定义的同时有效避免了权限的重复定义 1 31 3 现状现状 对于在企业环境中的访问控制方法 一般有三种 1 自主型访问控制方法 DAC 授权 Authorization 目前在我国的大多数的信息系统中的访 问控制模块中基本是借助于自主型访问控制方法中的访问控制列表 ACLs 2 强制型访问控制方法 多级安全 Multilevel Security 用于多层次安全级别的军事应用 3 基于角色的访问控制方法 RBAC Role Based Access Control 是目前公认的解决大型企 业的统一资源访问控制的有效方法 其显著的两大特征是 1 减小授权管理的复杂性 降低管理开销 2 灵活地支持企业的安全策略 并对企业的变化有很大的伸缩性 二 二 权限设计原则权限设计原则 2 12 1 原则简述原则简述 权限逻辑配合业务逻辑 即权限系统以为业务逻辑提供服务为目标 相当多细粒度的 3 权限问题因其极其独特而不具通用意义 它们也能被理解为是 业务逻辑 的一部分 比如 要求 合同资源只能被它的创建者删除 与创建者同组的用户可以修改 所有的用户能够 浏览 这既可以认为是一个细粒度的权限问题 也可以认为是一个业务逻辑问题 在这里 它是业务逻辑问题 在整个权限系统的架构设计之中不予过多考虑 当然 权限系统的架 构也必须要能支持这样的控制判断 或者说 系统提供足够多但不是完全的控制能力 即 设计原则归结为 系统只提供粗粒度的权限 细粒度的权限被认为是业务逻辑的职责 需要再次强调的是 这里表述的权限系统仅是一个 不完全 的权限系统 即 它不提 供所有关于权限的问题的解决方法 它提供一个基础 并解决那些具有 共性 的 或者说粗 粒度的 部分 在这个基础之上 根据 业务逻辑 的独特权限需求 编码实现剩余部分 或者 说细粒度的 部分 才算完整 回到权限的问题公式 通用的设计仅解决了 Who What How 的问题 其他的权限问题留给业务逻辑解决 2 22 2 相关名词解释相关名词解释 粗粒度 粗粒度 表示类别级 即仅考虑对象的类别 the type of object 不考虑对象的某个特定实 例 比如 用户管理中 创建 删除 对所有的用户都一视同仁 并不区分操作的具体对象实 例 细粒度 细粒度 表示实例级或数据级 即需要考虑具体对象的实例 the instance of object 或对象的 属性 当然 细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例 比如 合同管理中 列表 删除 需要区分该合同实例是否为当前用户所创建 Who 权限的拥用者或主体 Principal User Group Role Actor 等等 What 权限针对的对象或资源 Resource Class How 具体的权限 Privilege 正向授权与负向授权 User 与 Role 相关 用户仅仅是纯粹的用户 权限是被分离出去了的 User 是不能与 Privilege 直接相关的 User 要拥有对某种资源的权限 必须通过 Role 去关联 注 在如 blog 中的细粒度权限的解决 控制应该在底层解决 Resource 在实例化的时候 必需指定 Owner 和 GroupPrivilege 解决 Who 的问题 Role 是角色 拥有一定数量的权限 是粗粒度和细粒度 业务逻辑 的接口 一个基于粗 粒度控制的权限框架软件 对外的接口应该是 Role 具体业务实现可以直接继承或拓展丰 富 Role 的内容 Role 不是如同 User 或 Group 的具体实体 它是接口概念 抽象的通称 有关 role 和 group 的定义有需要补充的地方 根据模型的不同 如 RBAC 和 GBAC 等等 role 和 group 的概念是有很容易混淆的 下面的对 Group 的定义实际上也是有针对性的 似乎是基于 RGAC 模型的定义 把权限分配给组还是分配给角色应该根据实际情况和权限模型具体分析 在 rbac 中 权限只赋予 role 通过 role 的分层继承概念和强制性约束条件从而达成了权限的控制 但对于细粒度 的控制 如不同部门的相同角色 他们的操作相同 但资源客体不同 上实现就比较复杂 我大致了 解了一下 gbac 出发点似乎更注重将相同权限进行抽象集合 相同的权限规定为一个组 并通过继 承等概念赋予不同用户的操作授权 举个简单的例子 一个公司中如果只一个部门 从这个部门中再划分不同的职务 这样的话 role 和 group 所起的作用是重合的 我们只需引入其一即可 但如果有了多个部门 我们可以同时引入角色 和组 一个部门一个组 组里又有相同的 role 此时 role 拥有相同的权利 但部门不同 职能范围不 同 这样一来 将权限分配给组还是分配和 role 是对 role 进行约束还是对组进行约束是需要我们根 据具体情况进行分析和选型的 这里给出的概念只是网上比较经典的一些论述 整理出来有助于大家 学习 所以在后面介绍 RBAC 时给出的概念可能和现在给出的概念有所区别 4 Group 用户组 权限分配的单位与载体 权限不考虑分配给特定的用户 组可以包括组 以实现权限的继承 组可以包含用户 组内用户继承组的权限 Group 要实现继承 即在 创建时必须要指定该 Group 的 Parent 是什么 Group 在粗粒度控制上 可以认为 只要某用户直接或者间接的属于某个 Group 那么它就具 备这个 Group 的所有操作许可 细粒度控制上 在业务逻辑的判断中 User 仅应关注其直接属于的 Group 用来判断 是否 同组 Group 是可继承的 对于一个分级的权限实现 某个 Group 通过 继承 就已经直接获 得了其父 Group 所拥有的所有 权限集合 对这个 Group 而言 需要与权限建立直接关联 的 仅是它比起其父 Group 需要 扩展 的那部分权限 子组继承父组的所有权限 规则来 得更简单 同时意味着管理更容易 User 与 Group 是多对多的关系 即一个 User 可以属于多个 Group 之中 一个 Group 可以 包括多个 User 子 Group 与父 Group 是多对一的关系 Resource 注 应等同于 object 就是系统的资源 比如部门新闻 文档等各种可以被提供 给用户访问的对象 资源可以反向包含自身 即树状结构 每一个资源节点可以与若干指 定权限类别相关可定义是否将其权限应用于子节点 Privilege 注 应等同于 permission 是 Resource Related 的权限 就是指 这个权限是绑 定在特定的资源实例上的 比如说部门新闻的发布权限 叫做 部门新闻发布权限 这就 表明 该 Privilege 是一个发布权限 而且是针对部门新闻这种资源的一种发布权限 Privilege 是由 Creator 在做开发时就确定的 权限 包括系统定义权限和用户自定义权限用 户自定义 权限之间可以指定排斥和包含关系 如 读取 修改 管理三个权限 管理 权 限 包含 前两种权限 Privilege 如 删除 是一个抽象的名词 当它不与任何具体的 Object 或 Resource 绑定在一起时是没有任何意义的 拿新闻发布来说 发布是一种权限 但是只说发布它是毫无意义的 只有当发布与新闻结合在一起才会产生真正的 Privilege Operator 操作 表明对 What 的 How 操作 Operator 的定义包括了 Resource Type 和 Method 概念 即 What 和 How 的概念 之所以将 What 和 How 绑定在一起作为一个 Operator 概念而不是分开建模再建立关联 这是因为很多的 How 对于某 What 才有意义 比如 发布操作对新闻对象才有意义 对用户对象则没有意义 How 本身的意义也有所不 同 具体来说 对于每一个 What 可以定义 N 种操作 比如 对于合同这类对象 可以定 义创建操作 提交操作 检查冲突操作等 可以认为 How 概念对应于每一个商业方法 其中 与具体用户身份相关的操作既可以定义在操作的业务逻辑之中 也可以定义在操作 级别 比如 创建者的浏览视图与普通用户的浏览视图要求内容不同 既可以在外部定义 两个操作方法 也可以在一个操作方法的内部根据具体逻辑进行处理 具体应用哪一种方 式应依据实际情况进行处理 这样的架构 应能在易于理解和管理的情况下 满足绝大部 分粗粒度权限控制的功能需要 但是除了粗粒度权限 系统中必然还会包括无数对具体 Instance 的细粒度权限 这些问题 被留给业务逻辑来解决 这样的考虑基于以下两点 一方面 细粒度的权限判断必须要在资源上建模权限分配的支持信息才可能得以实现 比如 如果要求创建者和普通用户看到不同的信息内容 那么 资源本身应该有其创建者 的信息 另一方面 细粒度的权限常常具有相当大的业务逻辑相关性 对不同的业务逻辑 常 常意味着完全不同的权限判定原则和策略 相比之下 粗粒度的权限更具通用性 将其实 现为一个架构 更有重用价值 而将细粒度的权限判断实现为一个架构级别的东西就显得 繁琐 而且不是那么的有必要 用定制的代码来实现就更简洁 更灵活 所以细粒度控制应该在底层解决 Resource 在实例化的时候 必需指定 Owner 和 5 GroupPrivilege 在对 Resource 进行操作时也必然会确定约束类型 究竟是 OwnerOK 还是 GroupOK 还是 AllOK Group 应和 Role 严格分离 User 和 Group 是多对多的关系 Group 只用于对用户分类 不包含任何 Role 的意义 Role 只授予 User 而不是 Group 如果用户 需要还没有的多种 Privilege 的组合 必须新增 Role Privilege 必须能够访问 Resource 同 时带 User 参数 这样权限控制就完备了 Domain 为了授权更灵活 可以将 Where 或者 Scope 抽象出来 称之为 Domain 真正的 授权是在 Domain 的范围内进行 具体的 Resource 将分属于不同的 Domain 比如 一个新 闻机构有国内与国外两大分支 两大分支内又都有不同的资源 体育类 生活类 时事政 治类 假如所有国内新闻的权限规则都是一样的 所有国外新闻的权限规则也相同 则可 以建立两个域 分别授权 然后只要将各类新闻与不同的域关联 受域上的权限控制 从 而使之简化 正向授权与负向授权正向授权与负向授权 正向授权在开始时假定主体没有任何权限 然后根据需要授予权限 适合要求严格的系统 负向授权在开始时假定主体有所有权限 然后将某些特殊权限收回 2 32 3 权限设计思想权限设计思想 权限系统的核心由以下三部分构成 创造权限创造权限 Creator 创造 创造 分配权限分配权限 Administrator 分配 分配 使用权限使用权限 User 1 Creator 创造 Privilege Creator 在设计和实现系统时会划分 一个子系统或称为模块 应该有哪些权限 这里完成的是 Privilege 与 Resource 的对象声明 并没有真正将 Privilege 与具体 Resource 实例联系在一起 使之形成 Operator 2 Administrator 指定 Privilege 与 Resource Instance 的关联 在这一步 权限真正与资源 实例联系到了一起 产生了 Operator Privilege Instance Administrator 利用 Operator 这 个基本元素 来创造他理想中的权限模型 如 创建角色 创建用户组 给用户组分配用 户 将用户组与角色关联等等 这些操作都是由 Administrator 来完成的 3 User 使用 Administrator 分配给的权限去使用各个子系统 Administrator 是用户 在他 的心目中有一个比较适合他管理和维护的权限模型 于是 程序员只要回答一个问题 就 是什么权限可以访问什么资源 也就是前面说的 Operator 程序员提供 Operator 就意味 着给系统穿上了盔甲 Administrator 就可以按照他的意愿来建立他所希望的权限框架可以 自行增加 删除 管理 Resource 和 Privilege 之间关系 可以自行设定用户 User 和角色 Role 的对应关系 如果将 Creator 看作是 Basic 的发明者 Administrator 就是 Basic 的 使用者 他可以做一些脚本式的编程 Operator 是这个系统中最关键的部分 它是一个纽带 一个系在 Programmer Administrator User 之间的纽带 6 2 42 4 权限设计示例权限设计示例 A 建立角色功能并做分配 1 如果现在要做一个员工管理的模块 即 Resources 这个模块有三个功能 分别是 增加 修改 删除 给这三个功能各自分配一个 ID 这个 ID 叫做功能代号 Emp addEmp Emp deleteEmp Emp updateEmp 2 建立一个角色 Role 把上面的功能代码加到这个角色拥有的权限中 并保存到数 据库中 角色包括系统管理员 测试人员等 3 建立一个员工的账号 并把一种或几种角色赋给这个员工 比如说这个员工既可以 是公司管理人员 也可以是测试人员等 这样他登录到系统中将会只看到他拥有权限的那 些模块 B 把身份信息加到 Session 中 登录时 先到数据库中查找是否存在这个员工 如果存在 再根据员工的 sn 查找员工 的权限信息 把员工所有的权限信息都入到一个 Hashmap 中 比如就把上面的 Emp addEmp 等放到这个 Hashmap 中 然后把 Hashmap 保存在一个 UserInfoBean 中 最 后把这个 UserInfoBean 放到 Session 中 这样在整个程序的运行过程中 系统随时都可以 取得这个用户的身份信息 C 根据用户的权限做出不同的显示 可以对比当前员工的权限和给这个菜单分配的 功能 ID 判断当前用户是否有打开这个 菜单的权限 例如 如果保存员工权限的 Hashmap 中没有这三个 ID 的任何一个 那这个 菜单就不会显示 如果员工的 Hashmap 中有任何一个 ID 那这个菜单都会显示 对于一个新闻系统 Resouce 假设它有这样的功能 Privilege 查看 发布 删除 修 改 假设对于删除 有 新闻系统管理者只能删除一月前发布的 而超级管理员可删除所有 的这样的限制 这属于业务逻辑 Business logic 而不属于用户权限范围 也就是说权限负 责有没有删除的 Permission 至于能删除哪些内容应该根据 UserRole or UserGroup 来决定 当然给 UserRole or UserGroup 分配权限时就应该包含上面两条业务逻辑 一个用户可以拥有多种角色 但同一时刻用户只能用一种角色进入系统 角 色的划分方法可以根据实际情况划分 按部门或机构进行划分的 至于角色拥有多少权限 这就看系统管理员赋给他多少的权限了 用户 角色 权限的关键是角色 用户登录时是 以用户和角色两种属性进行登录的 因为一个用户可以拥有多种角色 但同一时刻只能扮 演一种角色 根据角色得到用户的权限 登录后进行初始化 这其中的技巧是同一时刻某 一用户只能用一种角色进行登录 针对不同的 角色 动态的建立不同的组 每个项目建立一个单独的 Group 对于新的 项目 建立新的 Group 即可 在权限判断部分 应在商业方法上予以控制 比如 不同 用户的 操作能力 是不同的 粗粒度的控制应能满足要求 不同用户的 可视区域 是不同的 体现在对被操作的对象的权限数据 是否允许当前用户访问 这需要对业务数据建模的时 候考虑权限控制需要 登陆 检查员 工是否存在 是 根据员工 sn 查找员 工权限信息 根据用户的权限 做出不同的显示 7 2 52 5 权限设计的扩展的思路权限设计的扩展的思路 有了用户 权限管理的基本框架 Who User Group 的概念是不会经常需要扩展的 变 化的可能是系统中引入新的 What 新的 Resource 类型 或者新的 How 新的操作方式 在 三个基本概念中 仅在 Permission 上进行扩展是不够的 这样的设计中 Permission 实质上 解决了 How 的问题 即表示了 怎样 的操作 那么这个 怎样 是在哪一个层次上的定义呢 将 Permission 定义在 商业方法 级别比较合适 比如 发布 购买 取消 每一个商业方 法可以意味着用户进行的一个 动作 定义在商业逻辑的层次上 一方面保证了数据访问 代码的 纯洁性 另一方面在功能上也是 足够 的 也就是说 对更低层次 能自由的访 问数据 对更高层次 也能比较精细的控制权限 确定了 Permission 定义的合适层次 更进一步 能够发现 Permission 实际上还隐含了 What 的概念 也就是说 对于 What 的 How 操作才会是一个完整的 Operator 比如 发 布 操作 隐含了 信息 的 发布 概念 而对于 商品 而言发布操作是没有意义的 同样的 购买 操作 隐含了 商品 的 购买 概念 这里的绑定还体现在大量通用的同名的操作上 比如 需要区分 商品的删除 与 信息的删除 这两个同名为 删除 的不同操作 提供权限系统的扩展能力是在 Operator Resource Permission 的概念上进行扩展 Proxy 模式是一个非常合适的实现方式 实现大致如下 在业务逻辑层 EJB Session Facade Stateful SessionBean 中 取得该商业方法的 Methodname 再根据 Classname 和 Methodname 检索 Operator 数据 然后依据这个 Operator 信息和 Stateful 中保存的 User 信 息判断当前用户是否具备该方法的操作权限 应用在 EJB 模式下 可以定义一个很明确的 Business 层次 而一个 Business 可能意 味着不同的视图 当多个视图都对应于一个业务逻辑的时候 比如 Swing Client 以及 Jsp Client 访问的是同一个 EJB 实现的 Business 在 Business 层上应用权限较能提供集中的 控制能力 实际上 如果权限系统提供了查询能力 那么会发现 在视图层次已经可以不 去理解权限 它只需要根据查询结果控制界面就可以了 2 52 5 需要注意的几个问题需要注意的几个问题 1 Group 和 Role 只是一种辅助实现的手段 不是必需的 如果系统的 Role 很多 逐个授权违背了 简单 方便 的目的 那就引入 Group 将权限相同的 Role 组成一个 Group 进行集中授权 Role 也一样 是某一类 Operator 的集合 是为了简化针对多个 Operator 的操作 注 例如员工 财务员工 测试 管理员他们之间有很多共同的权限也 有属于自己的特殊的权限 此时可以将相同的权限规划到一个组 不同的权限另外规划组 其思想就是将通用的东西尽量集中管理并通过组的继承的概念尽量简化授权规划 2 Role 把具体的用户和组从权限中解放出来 一个用户可以承担不同的角色 从而 实现授权的灵活性 当然 Group 也可以实现类似的功能 但实际业务中 Group 划分多 以行政组织结构或业务功能划分 如果为了权限管理强行将一个用户加入不同的组 会导 致管理的复杂性 注 由于 rbac 只是提供一个授权模型 在实际应用中很多人的设计都走了 型只保留了概念而已 如果参考 rbac 的文档会发现上述观点也是一种混淆 个人观点 对于角色不同但权限相同的情况也可以通过 8 3 权限系统还应该考虑将功能性的授权与资源性的授权分开 很多系统都只有对系统 中的数据 资源 的维护有权限控制 但没有对系统功能的权限控制 4 权限系统最好是可以分层管理而不是集中管理 大多客户希望不同的部门能且仅能 管理其部门内部的事务 而不是什么都需要一个集中的 Administrator 或 Administrators 组 来管理 虽然你可以将不同部门的人都加入 Administrators 组 但他们的权限过大 可以管 理整个系统资源而不是该部门资源 5 权限计算策略 系统中 User Group Role 都可以授权 前面说 User 只能 通过组来和授权相联系 权限可以有正负向之分 在计算用户的净权限时定义一套策略 系统中应该有一个集中管理权限的 AccessService 负责权限的维护 业务管理员 安全管 理模块 与使用 最终用户 各功能模块 该 AccessService 在实现时要同时考虑一般权 限与特殊权限 虽然在具体实现上可以有很多 比如用 Proxy 模式 但应该使这些 Proxy 依赖于 AccessService 各模块功能中调用 AccessService 来检查是否有相应的权限 所以说 权限管理不是安全管理模块自己一个人的事情 而是与系统各功能模块都有关系 每个功 能模块的开发人员都应该熟悉安全管理模块 当然 也要从业务上熟悉本模块的安全规则 三 三 RBAC Role Based Access Control 模型介绍 模型介绍 3 13 1 RBACRBAC 发展历史发展历史 访问控制技术是由美国国防部 Department of Defense DoD 资助的研究和开发成果 演变而来的 这一研究导致两种基本类型访问控制的产生 自主访问控制 Discretionary Access Control DAC 和强制访问控制 Mandatory Access Control MAC 两者区别请参 考附录 an introduction to rbac pdf 它们最初的研究和应用主要是为了防止机密信息被 未经授权者访问 近期的应用主要是把这些策略应用到为商业领域 由于 DAC 和 MAC 的特殊背景 人们越来越发现在实际情况中并不适合商用 在 1992 年 由 David Ferraiolo 和 Rick Kuhn 合作提出了 RBAC Role Based Access Control 模型 在 RBAC 模型中 在用户 user 和访问权限 permission 之间引入了角色 role 的概念 用户于特定的一个或多个角色相联系 而角色与一个或多个访问许可权 相联系 角色可以根据实际的工作需要生成或取消 由于 RBAC 在管理大型网络应用安全 时所表现出的灵活性和经济性 使得 RBAC 迅速成为最具有影响的高级访问控制模型 3 13 1 RBACRBAC 模型初探模型初探 RBAC 为了将人和权限解耦引入了 ROLE 的概念 整个 RBAC 参考模型都是围绕 Role 来 建立的 其基本思想是通过分配和取消角色来完成用户权限的授予和取消 根据不同的职 能岗位划分角色 资源访问许可被封装在角色中 用户通过赋予的角色间接地访问系统资 源和对系统资源可进行的操作 授权者根据需要定义各种角色 并设置合适的访问权限 而部门或个人根据其工作性质和职责再被指派为不同的角色 完成权限授予 这样 整个 访问控制过程就分成两个部分 即访问权限与角色相关联 角色再与部门或个人关联 从 而实现了部门或个人与访问权限的逻辑分离 标准的 RBAC 模型由 4 个部件模型组成 下面 分别介绍 9 A 模型 模型 1 CoreCore RBACRBAC Croe RBAC定义了5个基本元素集合 USERS ROLES OBS OPS PRMS RBAC 模型的本质其实就是基于这几个基本集合的一系列关系 如图 包括 角色授权关系 PA 用户的角色授权关系 UA 和角色的层次关系 RH 等 一些函数 包括 会话到用户的映射 会话到角色集合的映射 等 以及一些相关约束 user SU 2Rroles s 用户 Users 一个用户被定义成一个人 虽然它的概念可以扩展成一个机器 网络 以及 智能代理等 但我们为了简单起见 在这个文档中我们将用户定义成一个人 的概念 角色 Role 在一个组织机构的关系中 Role 表示一个工作职责 如果将用户指派到角色 上 则 Role 暗含关联权限和职责的语义 权限 Permission 一个许可 是对一个或多个Object执行operation的许可 资源客体 objects OBS 操作 operations OPS 会话会话 Session Session 会话在 RBAC 标准草案中似乎没有给出具体定义 它跟 web 应用中 session 的概念有些不同 根据标准发布的内容可以看出 session 在 rbac 中是一个关系映 射的概念 具体来说是一个 user 和一 多 个 role 之间关系的映射 在一个 RBAC 模型的系统中 每个用户进入系统得到自己的控制时 就得到了一个 session 每个 session 是动态产生的 从属于一个用户 只要静态定义过这些角色与该用 户的关系 会话根据用户的要求负责将它所代表的用户映射到多个角色中去 一个 session 可能激活的角色是用户的全部角色的一个子集 对于用户而言 在一个 session 内可获得全部被激活的角色所代表的访问许可权 角色和会话的设置带来的好处是容易实 施最小特权原则 Least Privilege Principle 所谓最小特权原则是将超级用户的所有 特权分解成一组细粒度的特权子集 定义成不同的 角色 分别赋予不同的用户 每个用 户仅拥有完成其工作所必须的最小特权 避免了超级用户的误操作或其身份被假冒后而产 生的安全隐患 一个 session 只能关联一个 user 一个 user 可以关联多个 sessions 上面的图例中 有两个函数 user sessions 给出了和用户关联的 session 集合 session roles 给出了 roles activated 激活的角色 session 由用户控制 允许动态激活 取消角色 实现最小特权 应避免同时激活所有 角色 session 和 user 分离可以解决同一用户多账号带来的问题 如审计 计账等 10 实现核心实现核心 RBACRBAC 必须具备的功能必须具备的功能 1 管理方面的功能 增加及删除使用者 增加及删除角色 分配角色给使用者及移 除原先分配给使用者的角色 分配权利给角色及移除原先分配给角色的权利 2 系统支持方面的功能 产生或删除一个会话期 在一个会话期加入或删除角色 既能在一个会话期启动或停止部分角色 检查一个会话期是否具有某个权利 3 核查 Review 功能 查询所有拥有某一角色的使用者 查询一个使用者所拥有 的全部角色 4 增强型核查功能 查询一个角色所有的权利 查询一个使用者所拥有的权利 查 询一个会话期所启用的角色 查询一个会话期所具有的权利 查询一个角色对某 一个物件所能行使的操作 查询一个使用者对某一个物件所能行使的操作 B B 模型模型 1 HierarchicalHierarchical RBACRBAC Hierarchical RBAC 在 core RBAC 的基础上引入了角色继承的概念 如图所示 Hierarchical 是反映一个组织结构层次的授权和责任的自然方式 它定义了角色的继 承关系 如 Role r1 继承 Role r2 则角色 r2 的权限同样是 r1 的权限 相比较 core RBAC 角色分层带来的好处就是解决了重复授权重复授权的问题 例如 在没有引入角色分层 概念时 经理和高级经理的权限可能有 80 都是重合的 这样一来管理员具体实施时对角 色授权的重复操作度就很高 而且随着组织结构层次复杂度的提高 这种授权操作的复杂 度成线性增加 在引入了 role hierarchy 后高级经理自动获取经理的所有权限 然后管理 员在分配其特有的权限即可 见过类似的公式推导 以一个全国性跨地区的公司 角色分 层的实现和不实现相比其赋权的复杂度降低了约十倍 C C 模型模型 2 StaticStatic SeparationSeparation ofof DutyDuty RelationsRelations 11 SSD 定义了一个用户角色分配的约束关系 一个用户不可能同时分配 SSD 中的两个角 色 它的作用就是避免了角色的冲突 举个简单的例子 在一个公司 一个员工不应该既 是会计又是出纳 注意 一个财务经理 如果她既继承了会计的角色又继承了财务的角色 这种特殊的情况没有很好的解决办法 应尽力避免 在 User Assignment 中引入 SSD 这样在系统初始化的时候 当角色授权给用户时来判断是否将冲突的角色给了一个用户 在 Static Separation of Duty Relations 模型中冲突的角色用一个二元关系定义 任何 一个用户只能拥有其中的一个角色 D D 模型模型 1 DynamicDynamic SeparationSeparation ofof DutyDuty RelationsRelations 动态分离的概念是指两个或多个冲突的角色可以赋给一个用户 它的特点不是在系统 初始化时将责任进行分离 而是在一个用户会话过程进行约束 虽然用户可以同时启用这 两种角色 但同一会话期只能选择其一 12 3 13 1 一个一个 RBACRBAC 模型的实现模型的实现 四 四 ACL Access Control List 介绍 介绍 4 14 1ACL Access Control List 概述概述 不好意思 查了 N 久也没看到 ACL 名称的历史和起源 目前大家能看到 ACL 使用最 多的地方基本都是在网络安全配置和 UNIX 系统安全配置中 简单的总结一下 所谓的 ACL 就是指访问控制列表 是存储在计算机中的一张表 它记录了用户和设备可以访问哪 些现有资源 文件目录 单个文件 数据等等 是用来保证系统安全性的一种手段 4 24 2ACL 在在 web 应用中描述应用中描述 1 Java acl 开始第一步是建立一个主体 Principal 其中 SecurityOwner 是主体的拥有者 private static final Principal securityOwner new PrincipalImpl SecurityOwner 补上 主体的定义 主体表示一个实体 如单独用户或一个用户组 2 当用户 login 进来时 他带有两个基本数据 访问密码和他要访问的对象 ApplicationName 首先验证用户名和密码 然后从数据库中取出其权限数据 建立 Permission 这里使用 Feature 继承了 Permission 在 Feature 中定义了有关权限的细节数据 如读 写 删 取出用户和被访问对象之间的权限关系 这种权限关系可能不只一个 也就是说 用户 可能对被访问对象拥有读 写 删等多个权限 将其打包在 Hasbtable 中 Hashtable features loadFeaturesForUser sApplicationName sUserID 3 创建一个用户对象 User user new UserImpl sUserID new Hashtable 4 为这个用户创建一个活动的 acl entry addAclEntry user features 其中最关键的是第四步 addAclEntry 我们看看其如何实现的 为这个用户创建一个新的 Acl entry AclEntry newAclEntry new AclEntryImpl user 遍历 Hashtable features 将其中多种权限加入 feature Feature hFeatures get keyName newAclEntry addPermission feature 最后也要加入主体拥有者 SecurityOwner 这样一个安全体系就已经建立完成 当你在系统 中要检验某个用户使用拥有某个权限 如读的权利时 只要只要 acl checkPermission user feature 就可以就可以 acl 是是 ACL 的一个实例的一个实例 这样权限检查就交给 13 java security acl ACL 去处理了 当一个用户 login 后 我们就要在内存中为其建立相应的授权访问机制 使用 java security acl 可以很方便的建立这样一个安全系统 An introduction to rbac 7 页 页 Grbc 中权限和中权限和 group 相连 实际上相连 实际上 rbac 也借鉴了也借鉴了 gbac 的概念 的概念 group 和和 user 都和组织机构有关 但不是组织机构 二者在概念上是不同的都和组织机构有关 但不是组织机构 二者在概念上是不同的 我个人理解 group 组一般按企业的组织结构来 分部门 role 角色一般按职能来 它 是对组的细化和补充 role 分为全局 role 和局部 roleActor 作为一个通用的接口与 Role 通讯 Role 作为一个用户与权限的代理层 解 耦了权限和用户的关系 所有的授权应该给予 Role 而不是直接给 User 或 Group PrivilegeManager 名字不好听 就是用来进行 R P 之间的关系操作的 例如 getRoleByPrivilege 之类的 SecurityManager 作为系统对外的接口 接受 Actor Resource Operation 作为参数 并判断 Actor 中的 Role 是否有操作 Privilege Resource Operation 的权限 个人理解 这两个函数的作用是 当一个用户做某些操作时 user sessions 给出 了和这个用户关联的 sessions 而 session roles 又给出和用户关联的可用 roles 这样 就完成了用户和角色的关联 暂时标注 1 建立角色功能并做分配 详细步骤见 jive 手册 增加代码 id mp addEmp 修改代码 id mp updateEmp role 管理员 员工 测试人员 账号 1 账号 2 14 另一个 word 文档 通用权限管理系统设计篇 三 通用权限管理系统设计篇 三 概要设计说明书概要设计说明书 删除代码 id mp deleteEmp 2 把身份信息加进 Session 中 所有权限信息放到 Hashmap 中如上面的 Emp addEmp 等然后 把 Hashmap 保存在 一个 UserInfoBean 中 最后把这个 UserInfoBean 放到 Session 中 登陆 检查员 工是否存在 是 根据员工 sn 查找员 工权限信息 根据用户的权限 做出不同的显示 对比当前员工的权限 和给这个菜单分配的 功能 ID 判断当前 用户是否有打开这个 菜单的权限 例如 如果保存员工权限的 Hashmap 中没有这三个 ID 的任何一个 那这个菜单就不会显示 如果 员工的 Hashmap 中有任何一个 ID 那这个菜单都会显示 对于一个新闻系统 Resouce 假设它有这样的功能 Privilege 查看 发布 删除 修改 假设对 于删除 有 新闻系统管理者只能删除一月前发布的 而超级管理员可删除所有的这样的限制 这 属于业务逻辑 Business logic 而不属于用户权限范围 也就是说权限负责有没有删除的 Permission 至于能删除哪些内容应该根据 UserRole or UserGroup 来决定 当然给 UserRole or UserGroup 分配权限时就应该包含上面两条业务逻辑 一个用户可以拥有多种角色 但同一时刻用户只能用一种角色进入系统 角色的划分方法可以根据 实际情况划分 按部门或机构进行划分的 至于角色拥有多少权限 这就看系统管理员赋给他多少 的权限了 用户 角色 权限的关键是角色 用户登录时是以用户和角色两种属性进行登录的 因 为一个用户可以拥有多种角色 但同一时刻只能扮演一种角色 根据角色得到用户的权限 登录后 进行初始化 这其中的技巧是同一时刻某一用户只能用一种角色进行登录 针对不同的 角色 动态的建立不同的组 每个项目建立一个单独的 Group 对于新的项目 建立新 的 Group 即可 在权限判断部分 应在商业方法上予以控制 比如 不同用户的 操作能力 是不同 的 粗粒度的控制应能满足要求 不同用户的 可视区域 是不同的 体现在对被操作的对象的权限数 据 是否允许当前用户访问 这需要对业务数据建模的时候考虑权限控制需要 15 在前两篇文章中 不少朋友对我的设计提出了异议 认为过于复杂 当然 在实际的各种系统的权限管理模块中 并不像这里设计得那么复杂 我以前所 做的系统中 由只有用户和权限的 有只有用户 权限和角色的 还有一个系 统用到了用户 权限 角色 组概念 这个系统是我在思考以前所做系统的权 限管理部分中找到的一些共性而想到的一个设计方案 当然还会有不少设计不 到位的地方 在设计开发过程中会慢慢改进 这个系统权当学习只用 各位朋 友的好的建议我都会考虑到设计中 感谢各位朋友的支持 今天抽时间整了一份概念设计出来 还有一些地方尚未考虑清楚 贴出 1 0 版 希望各位朋友提出宝贵建议 大家也可以点击此处 通用权限管理概要设计说明书 自行下载 这是 1 0 版本 有些地方可能还会进行部分修改 有兴趣的朋友请关注我的 blog 1 1 引言引言 1 11 1 编写目的编写目的 本文档对通用权限管理系统的总体设计 接口设计 界面总体设计 数据 结构设计 系统出错处理设计以及系统安全数据进行了说明 1 21 2 背景背景 a 软件系统的名称 通用权限管理系统 b 任务提出者 开发者 谢星星 c 在 J2EE 的 web 系统中需要使用权限管理的系统 1 31 3 术语术语 本系统 通用权限管理系统 SSH 英文全称是 Secure Shell 1 41 4 预期读者与阅读建议预期读者与阅读建议 预期读者阅读重点 开发人员总体设计 接口设计 数据结构设计 界面总体设计 系统出错处理设计 设计人员总体设计 接口设计 数据结构设计 系统安全设计 16 1 51 5 参考资料参考资料 通用权限管理系统需求规格说明书 通用权限管理系统数据库设计说明书 2 2 总体设计总体设计 2 12 1 设计目标设计目标 权限系统一直以来是我们应用系统不可缺少的一个部分 若每个应用系统 都重新对系统的权限进行设计 以满足不同系统用户的需求 将会浪费我们不 少宝贵时间 所以花时间来设计一个相对通用的权限系统是很有意义的 本系统的设计目标是对应用系统的所有资源进行权限控制 比如应用系统 的功能菜单 各个界面的按钮控件等进行权限的操控 2 22 2 运行环境运行环境 操作系统 Windows 系统操作系统和 Linux 系列操作系统 2 32 3 网络结构网络结构 通用权限管理系统可采用 Java Swing 实现 可以在桌面应用和 Web 应用系统 中进行调用 如果需要要适应所有开发语言 可以将其 API 发布到 WEB Service 上 暂时用 Java Swing 实现 2 42 4 总体设计思路和处理流程总体设计思路和处理流程 在说明总体设计思路前 我们先说明本系统的相关概念 1 1 权限资源权限资源 系统的所有权限信息 权限具有上下级关系 是一个树状的结构 下面来 看一个例子 系统管理 用户管理 17 查看用户 新增用户 修改用户 删除用户 对于上面的每个权限 又存在两种情况 一个是只是可访问 另一种是可 授权 例如对于 查看用户 这个权限 如果用户只被授予 可访问 那么 他就不能将他所具有的这个权限分配给其他人 2 2 用户用户 应用系统的具体操作者 用户可以自己拥有权限信息 可以归属于 0 n 个 角色 可属于 0 n 个组 他的权限集是自身具有的权限 所属的各角色具有的 权限 所属的各组具有的权限的合集 它与权限 角色 组之间的关系都是 n 对 n 的关系 3 3 角色角色 为了对许多拥有相似权限的用户进行分类管理 定义了角色的概念 例如 系统管理员 管理员 用户 访客等角色 角色具有上下级关系 可以形成树 状视图 父级角色的权限是自身及它的所有子角色的权限的综合 父级角色的 用户 父级角色的组同理可推 4 4 组组 为了更好地管理用户 对用户进行分组归类 简称为用户分组 组也具有 上下级关系 可以形成树状视图 在实际情况中 我们知道 组也可以具有自 己的角色信息 权限信息 这让我想到我们的 QQ 用户群 一个群可以有多个用 户 一个用户也可以加入多个群 每个群具有自己的权限信息 例如查看群共 享 QQ 群也可以具有自己的角色信息 例如普通群 高级群等 针对如上提出的四种对象 我们可以整理得出它们之间的关系图 如下所 示 18 总体设计思路是将系统分为组权限管理 角色权限管理 用户权限管理 组织管理和操作日志管理五部分 其中组权限管理包括包含用户 所属角色 组权限资源和组总权限资源四 部分 某个组的权限信息可用公式表示 组权限 所属角色的权限合集 组 自身的权限 角色权限