适用于具有多个安全级别的军事应用。 3.基于角色的访问控制方法（RBAC）。 目前被公认为解决大型企业统一资源访问控制的有效方法。 其两个显着特点是： 1、降低授权管理的复杂度，减少管理开销。 2、灵活支持企业安全策略，对企业变化具有极大的扩展能力。 粗粒度：表示类别级别，即只考虑对象的类别（thetypeobject），而不考虑对象的具体实例。 例如，在用户管理中，创建和删除对所有用户都是平等对待的，不区分操作的具体对象实例。 细粒度：表示实例级别，即需要考虑具体对象（实例对象）的实例。 当然，细粒度是在考虑粗粒度的对象类别之后再考虑具体的实例。 例如，在合约管理中，列出和删除需要区分合约实例是否是当前用户创建的。 权限逻辑与业务逻辑相匹配。 即权限系统旨在为业务逻辑提供服务。 有相当多的细粒度权限问题非常独特，没有普遍意义。 它们也可以理解为“业务逻辑”的一部分。 例如，需求：“合约资源只能由其创建者删除，与创建者同组的人可以修改，所有用户都可以浏览”。 这可以被认为是细粒度的权限问题或业务逻辑问题。 这里是一个业务逻辑问题，在整个权限系统的架构设计中不应该考虑太多。
当然，权限系统的架构也必须能够支持这样的控制判断。 换句话说，系统提供了足够但不完整的控制能力。 即设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。 需要再次强调的是，这里表达的权限系统只是一个“不完整”的权限系统，即它并没有提供与权限相关的所有问题的解决方案。 它提供了一个基础并解决了那些“通用”（或粗粒度）部分。 在此基础上，根据“业务逻辑”独特的权限要求，剩下的（或细粒度的）部分编码实现才算完成。 回到权限的问题公式，通用设计只解决了Who+What+How的问题，其他的权限问题就交给业务逻辑来解决。 Who：权限的所有者或主体（主体、用户、组、角色、参与者等） What：权限所针对的对象或资源（资源、类）。 How：特定权限（特权、正向授权和负向授权）。 角色：是具有一定权限的角色。 操作者：操作。 表示What 的How 操作。 User：与Role相关，用户只是纯粹的用户，权限是分开的。 用户不能与权限直接相关。 如果User想要拥有某个资源的权限，就必须通过Role来关联。
解决谁的问题。 资源：是系统的资源，如部门新闻、文档等可供用户访问的对象。 资源可以反向包含自身，即树结构。 每个资源节点可以关联多个指定的权限类别，并可以定义其权限是否应用于子节点。 Privilege：是ResourceRelated的权限。 也就是说，该权限是绑定到特定的资源实例上的。 例如，发布部门新闻的权限称为“部门新闻发布权限”。 这说明Privilege是一个出版机构，而且是部门新闻等资源的出版机构。 权限是由 Creator 在开发过程中决定的。 权限包括系统定义的权限和用户定义的权限。 可以指定用户自定义权限之间的排除和包含关系（例如：读取、修改、管理三个权限游戏素材，管理权限包括前两个权限）。 诸如“删除”之类的权限是一个抽象名词，当它没有绑定到任何特定的 ObjectResource 时没有任何意义。 以新闻发布为例，发布是一种许可，但光说发布是没有意义的。 因为我不知道release可以操作哪些对象。 真正的特权只有当出版和新闻结合起来时才会出现。 这是PrivilegeInstance。 权限系统可以根据不同的需求扩展成很多不同的版本。
作用：是粗粒度和细粒度（业务逻辑）的接口。 是一款基于粗粒度控制的权限框架软件。 外部接口应该是Role。 具体业务实现可以直接继承或扩展丰富的Role内容。 角色与用户或组不同。 具体实体，是接口概念用户角色权限设计，是抽象的总称。 组：权限分配的用户组、单位、载体。 权限不被视为分配给特定用户。 组可以包含组（以启用权限继承）。 组中可以包含用户，组中的用户继承组的权限。 Group需要实现继承。 即创建Group时必须指定该Group的Parent是什么Group。 从粗粒度的控制来看，可以认为只要一个用户直接或间接属于某个Group，那么就拥有该Group的所有操作权限。 在细粒度控制方面，在业务逻辑的判断上，User重点关注其直接所属的Group来判断是否是“同一组”。 组是可继承的。 对于分层权限实现来说，一个Group通过“继承”直接获得了其父Group的所有“权限集”。 对于这个Group，需要与权限建立直接的关系。 与其父组相比，它只需要“扩展”的那部分权限。 子组继承父组的所有权限，规则更简单用户角色权限设计，更易于管理。 为了进一步实现权限的继承，最直接的方式就是在Group上引入“父子关系”。
用户和组是多对多的关系。 即一个User可以属于多个Group，一个Group中可以包含多个User。 子组和父组之间存在多对一的关系。 Operator在某种意义上类似于ResourcePrivilege概念，但这里的Resource只包括ResourceType，并不代表ResourceInstance。 Group可以直接映射组织结构，Role可以直接映射组织结构中的业务角色，相对直观且足够灵活。 角色对系统的贡献本质上是提供了一个相对粗粒度的分配单元。 Group和Operator的定义包括ResourceType和Method的概念。 即“什么”和“如何”的概念。 之所以将What和How作为一个Operator概念绑定在一起，而不是单独建模然后建立关联，是因为很多How对于某个What来说是有意义的。 例如，发布操作对于新闻对象有意义，但对于用户对象则没有意义。 How本身的含义也不同。 具体来说，可以为每个What定义N个操作。 例如，对于合约这样的对象，可以定义创建操作、提交操作、冲突检查操作等。可以认为How概念对应于每一个业务方法。
其中，与特定用户身份相关的操作可以定义在操作的业务逻辑中，也可以定义在操作层面。 例如，创建者的浏览视图需要与普通用户的浏览视图不同的内容。 您可以在外部定义两种操作方法，也可以在一种操作方法内部根据具体逻辑进行处理。 具体采用何种方法应根据实际情况而定。 这样的架构应该能够满足粗粒度权限控制的大部分功能需求，同时易于理解和管理。 然而，除了粗粒度的权限之外，系统不可避免地会包含无数针对特定实例的细粒度权限。 这些问题就交给业务逻辑来解决。 这种考虑基于以下两点：一方面，细粒度的权限判断必须基于以资源为模型的权限分配的支持信息才可能实现。 例如，如果要求创建者和普通用户看到不同的信息内容，那么资源本身就应该有其创建者的信息。 另一方面，细粒度的权限通常具有相当大的业务逻辑相关性。 不同的业务逻辑往往意味着完全不同的权限判定原则和策略。 相比之下，粗粒度的权限更加通用，将其实现为架构更具有复用价值； 而将细粒度的权限判断作为架构级别的事情来实现是比较麻烦的，也不是那么必要。 ，用定制代码实现更简单、更灵活。 因此，细粒度的控制应该从底层解决。 实例化资源时，必须指定 Owner 和 GroupPrivilege。 在操作Resource时，也会确定约束类型：是OwnerOK、GroupOK还是AllOK。
组与角色应严格分开。 用户和组之间是多对多的关系。 Group仅用于对用户进行分类，不包含任何Role含义； 角色分配给用户，而不是组。 如果用户需要多个尚不存在的权限的组合，则必须添加新的角色。 权限必须能够通过User参数访问Resource，这样权限控制就完成了。 权限系统的核心由以下三部分组成：1.创建权限，2.分配权限，3.使用权限。 那么，系统各部分的主要参与者对比如下：1.创建权限Creator创建，2.分配权限Administrator分配，3.使用权限Creator创建Privilege。 在设计和实现系统时，Creator会划分子系统或模块应具有哪些权限。 这里完成的是Privilege镜像声明，并没有真正将Privilege与具体的Resource实例连接起来形成Operator。 管理员指定权限资源实例的关联。 这一步将权限真正链接到资源实例，并生成Operator（权限实例）。
管理员使用操作员的基本元素来创建他理想的权限模型。 例如音效，创建角色、创建用户组、将用户分配到用户组、将用户组与角色关联等……这些操作都是由管理员完成的。 用户使用管理员分配的权限来使用各个子系统。 管理员是一个用户，他心里有一个更适合他管理和维护的权限模型。 因此，程序员只需要回答一个问题，就是什么权限可以访问什么资源，也就是前面提到的Operator。 当程序员提供Operator时，他们就为系统穿上了铠甲。 管理员可以根据自己的意愿建立自己想要的权限框架，并可以自行添加、删除和管理Resource和Privilege之间的关系。 您可以自行设置User和Role的对应关系。 （如果说Creator是Basic的发明者，那么Administrator就是Basic的使用者，他可以进行一些基于脚本的编程） Operator是这个系统中最关键的部分。 它是程序员和管理员之间的纽带。 用户之间的纽带。
我们以功能模块为例。 一。 建立角色功能并分配： 1、如果要创建一个员工管理模块（即资源），该模块有添加、修改、删除三个功能。 这三个函数各分配一个ID，称为函数代码：Emp_addEmp、Emp_deleteEmp、Emp_updateEmp。 2.创建角色（Role），将上述功能代码添加到该角色拥有的权限中，并保留
