RBAC的实现与扩展

1. 什么是RBAC

RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。

简单地说，就是一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。（如图1）

大致描述权限之间的关系

2.如何将RBAC与前端的表现结合起来

视图与权限的选择

一般在前端，我们会单独的菜单管理；菜单管理的页面，其实就是这个用户选择这个角色应该可以看到菜单与页面。

后面更加详细一点，需要对这个页面里涉及到的一些操作的权限进行选择。

当然，我们如果对于RBAC灵活掌握后，结合自己本身的工程项目，在为角色选择页面视图与权限的时候，我们完全可以理解为，如果我选择了这个菜单与视图，那么这个视图页面里所有涉及到的操作，都应该是这个角色该有的权限，那么，理所当然地，我们不用繁琐地，一个一个菜单地去选择，我们在程序设计的时候，默认给它选上，甚至都不让用忘户看到。

更进一步地，我们甚至不做这种操作级别的权限控制，我们认为，只要菜单显示出来的页面，我们就是有权限操作的；那么，在给角色分配视图时，没有权限的页面，我们根本不分配给用户，用户压根就看不到。在这样的场景下，因为没有对权限进行控制，我想，这个RBAC，应该叫VIEW-RBAC，同样基于角色，只是结合了视图。

3 .扩展RBAC与域的概念，或者其它的限制条件.

完成了RBAC的设计工程，那么系统里的用户与角色我们很好的控制起来了； 当然这个验证与授权，也是基于这个RBAC来的。

验证： 根据用户名，验证了用户名与密码，即完成验证。

授权： 验证通过后，我们得知用户的角色，从而知道用户的“权限”：可以看到哪些菜单与视图；可以进行哪些研发级的操作的API的调用 。

在绝大多数的场景里，我们还有域的概念。

比如，一个用户角色，它能管理的对象，是有一个范围的，这个范围是具体的业务范围 ，与RBAC没有关系。那么必须扩展RBAC系统，比如说建立个域的表，与角色关联起来； 当具体的业务逻辑页面要展现业务数据时，需要对这个角色的域进行过滤，而不是全局的显示。于是，就简单地实现了域的概念。

域，举例，可以区别为用户。 可以是业务数据里建立的某种范围。等等。