RBAC (Role-Based Access Control, role-based access control), that is, by associating user roles and permissions. Simply put, a user has several roles, each role has a number of privileges. In this way, it is configured to "user - role - permission" license model. In this model, between the user and roles between roles and permissions, the general who is many to many relationship. (As shown below)
What role? It can be understood as a collection of a number of rights, privileges carrier. For example: a forum system, a "super administrator", "moderator" are roles. Moderators can post, and other users within the manageable version in version management, these permissions. Give a user to grant these permissions, without direct grant user permissions, "moderator" This role can be given to the user.
When a very large number of users, each user is authorized to give the system one by one (grant role), it is a very troublesome thing. In this case, it is necessary to user packets, each user has a plurality of users within the group. In addition to authorize the user, the user may further authorize groups. As a result, all the rights and privileges of the user owns, is owned by the individual user permissions of the user's own user group. (The following figure shows the user groups, user associations and roles of the three)
In the application system, the performance rights to what? The operation of the functional modules, deletion of uploaded files, access the menu, and even a button on the page, a picture of visibility controls, can fall within the competence of the category. Some rights design, the operation will function as a class, and the documents, menus, and other page elements as another class, this constitutes a "user - role - authority - resources" licensing model. In doing modeling data table, can the functional operation and integrated management of resources, that is, are carried out directly associated with permissions on the table, this may be more convenient and easy scalability. (See below)
Please note that permission table has a "right type", which according to our values is to distinguish what kind of privileges, such as the "MENU" express access to the menu, "OPERATION" represents the operating authority functional modules, "FILE" represents modify file permissions, "eLEMENT" represents the visibility of the control elements on the page and so on.
这样设计的好处有二。其一，不需要区分哪些是权限操作，哪些是资源，（实际上，有时候也不好区分，如菜单，把它理解为资源呢还是功能模块权限呢？）。其二，方便扩展，当系统要对新的东西进行权限控制时，我只需要建立一个新的关联表“权限XX关联表”，并确定这类权限的权限类型字符串。
这里要注意的是，权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。（文件、页面权限点、功能操作等同理）。也就是每添加一个菜单，就得同时往这三个表中各插入一条记录。这样，可以不需要权限菜单关联表，让权限表与菜单表直接关联，此时，须在权限表中新增一列用来保存菜单的ID，权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。
到这里，RBAC权限模型的扩展模型的完整设计图如下：
随着系统的日益庞大，为了方便管理，可引入角色组对角色进行分类管理，跟用户组不同，角色组不参与授权。例如：某电网系统的权限管理模块中，角色就是挂在区局下，而区局在这里可当作角色组，它不参于权限分配。另外，为方便上面各主表自身的管理与查找，可采用树型结构，如菜单树、功能树等，当然这些可不需要参于权限分配。
以上，是从基本的RBAC模型进行了扩展，具体的设计要根据项目业务的需要作调整。欢迎大家提出批评意见！