RBAC权限模型的一些见解

在开发设计中，权限是系统的一块重要的部分，按控制级别和分类，主要有以下三种权限：
1、使用功能权限控制，如菜单、操作等权限控制
2、数据过滤权限控制，如某些数据对特定用户可见或可操作等
3、服务许可权限，控制系统给客户的用户数、cpu核数、功能集合等控制

本文主要对分类1进行分析，大部分应用对这部分的权限控制都是基于角色控制，大体上有以下几部分相关部分内容：
1）组织/部门机构
2）用户
3）用户组或等同概念
4）角色
5）菜单/功能集合
以上内容足够满足简单的粗粒度的权限控制应用，按照rbac原则，用户和功能集合完全分离，唯一的桥梁就是角色，如果把功能权限直接赋予用户那是非常忌讳的事情，而且基本上也很少有软件这样设计，但也不排除没有。这部分内容对软件开发设计人员肯定都是熟悉的，这里就不介绍了，下面将从两部分深化应用：
一）、角色继承
细化分类1的设计，就我个人熟悉的软件中基本都没有角色继承的概念，虽然RBAC早就有这方面的规范，也许是不太好用或不太好理解的原因，导致不多人使用。这部分主要是对象思想上考虑，而且对权限分配过程中的数据量有很大缩减。一种典型的案例说：
企业中普通员工的角色一般是最基础的，经理的角色包括员工能访问的内容，并且还有更多的功能使用权限（如审批等），这时，角色可以定义如下：
员工：角色A
经理：角色B继承角色A
体现在关系型数据中就是典型的父子级概念，子节点继承父节点。角色继承的概念主要体现面向对象的思想，但是也有如下的优缺点：
优点：1、角色对象化，从设计方面考虑更加合理和分析
2、可大幅度减少权限分配数据量
缺点：1、客户不一定熟知对象思想，不易于理解，如果是实施人员参与，那会好很多，毕竟公司会培训。
2、角色继承树形结构中，如果中间节点的权限改变，将影响到所有继承于此节点的角色，所以相对适合于比较固定的权限分配情况

二）角色层次
平常在需求中会有这么个需求，不要所有的权限都由一个人分配，通常这个人是超级管理员，因为这样会存在风险，权限太大容易出问题，而且增加管理员工作量和更新不实时等情况发生，这时，角色层次概念派上用场了。操作可以大体如下：超级管理员分配各个部门的总体权限，部门内分配的权限由部门管理员分配，角色挂在部门上，本部门管理员只能看到们部门内的所有许可操作集合。以上操作属于职能分离内容，这种情况适合于有大量分公司的企业，要不然由总部定义所有角色和分配所有权限，不方便也不灵活，更不符合设计原则。

以上为本人总结对权限分配的一些理解，也建立了一种关系数据的模型图如附件，大家多交流交流，发现以上弊端及更好建议，时间关系，先简述到这。