基于角色的访问控制（RBAC）

来自：编程新说

很多时候，需要对一些事物进行控制，如一个房间，为了不让人随便进，通常会装一把锁，如果要想进入，你必须得有一把钥匙，且还得和这个锁匹配才行。

基于此做一个抽象，其实包含三方面内容：

1）一个是被控制的事物，通常就算资源。

2）一个是想访问这些资源的人所必须拥有的东西，通常就算凭证。

3）还有一个就是进行凭证和资源的匹配。


Web应用中的资源


网络时代绝大多数都是web应用。web应用的一大特点就是Client和Server。客户端发起一个请求，服务器就给出一个响应。

对客户端的要求只有一个，那就是要知道请求对应的URL。客户端请求不同的URL就可以得到不同的内容，或者反过来说，客户端为了得到不同的内容只要请求不同的URL即可。

这些内容可以认为是服务器开放给客户端的资源，所以站在客户端的角度，服务器上的资源就是由许多URL组成的，因为客户端只能通过URL的方式和服务器打交道。

URL可以说是一个底层本质的东西，它的上面会有很多不同的展现形式：

菜单可以对应URL

页面可以对应URL

按钮可以对应URL

Ajax可以对应URL

服务API可以对应URL

文件下载可以对应URL

静态文件css、js、images可以对应URL

这些就是通常我们见到的资源，它们就是要被控制访问的事物。


把凭证授给用户


凭证这个东西的作用，大家都很熟悉，就是可以用来证明一个事物的合法性。比如一个身份证可以证明你是一个合法公民。一张车票可以证明你是一个合法乘客。

但是对凭证的存在形式，其实并没有什么硬性规定，因为随着时间的推移，它是会变的，也就是说具有阶段性。

就拿锁来说，它的凭证以前是一把钥匙，后来变成一串数字密码，再后来变成一个指纹，现在又变成一张人脸或一个声纹，再往未来发展，可能就是一种意念了。

web应用中的资源就是URL，我们可以把这个URL直接作为凭证授予用户，只需把这些授予关系存储起来即可，说白了就是，哪个用户可以访问哪些URL。

或者也可以把这些URL进行等价变形，把变形后的产物授予用户，总之，只要能建立起合理的映射关系就行了。


角色出现的必然性


假如有一个新闻系统，为了让某人能顺利的发新闻，需要由技术人员授予她一大堆的URL。这样一个“简单”的事情中，就存在两个潜在的弊端。

一个是必须由技术人员来做，因为非技术人员可能连URL这个词都不知道是什么。一个是一大堆的URL，太多了，操作麻烦，还可能漏掉某个。

究竟由谁发新闻，这是业务和管理上的事情，不应该由技术来做，他们不做的原因是因为门槛太高，所以技术应该想办法来降低工作的门槛。

可能领导觉得现在的新闻发布人员工作很认真，于是让她去审核新闻了，又来了一个新的新闻发布人员。这下又要“折腾”技术人员了。

技术需要先把她的发布新闻URL去掉，授给她审核新闻的URL，然后再把发布新闻的URL授给新来的人员。可能过两天又来了一个新闻发布人员。

这可简直要了技术人员的“命”了，所以技术应该想办法来降低工作的繁琐性，绝对是利人又利己。

在计算机里，解决此类问题的一个“标准指导方针”就是，抽象和封装。抽象出一层来，把复杂的东西封装起来。

就是让不该看的人看不到他不该看的东西，只让他看到他该看到的东西。就像同一个事物在不同人眼里是不一样的。

一栋大楼，在设计人员眼里就是一堆图纸，在工程人员眼里就是一堆结构和承重计算的公式，在建筑工人眼里就是一堆钢筋和混凝土，在装修人员眼里就是毛坯房，在业主眼里就是他自己未来的家。

最终角色这个东西就是被抽象出来的一层，它起到过渡的作用，从这一层向下是技术人员负责的，从这一层向上是业务管理人员负责的。

技术人员预定义好一些角色，比如新闻发布员、新闻审核员，然后把和发布相关的所有URL授予发布员这个角色，把和审核相关的所有URL授予审核员这个角色。

剩下的工作就交给业务管理人员来做，他们把角色授予某个人，只需一步即可，也不涉及什么技术知识。这真是各管各的，两全其美。

其实这个角色就是上面提到的一堆URL的等价变形，最终起到的也是一个传递映射关系的桥梁作用。


凭证和资源的匹配方式


在持有凭证去访问资源的时候需要进行凭证和资源的匹配。就像进考场要看准考证、上车前要验票一样。

凭证的存在形式不同，匹配的方式也不同，如果是钥匙，需要机械匹配。如果是密码，需要相等性匹配。

如果是指纹、图像、声纹，需要的是概率性匹配，因为这些东西貌似无法相等，只有一个匹配度。

对于web应用的URL，只有用户访问时才需要匹配，我们就在请求必经的路上设置一到多道关卡进行拦截，常用的就是过滤器和拦截器。

在被拦截以后，从请求中解析出本次访问的URL，从当前登陆用户信息中拿到具有的角色和能访问的URL，然后按自己设定的一套逻辑去匹配。

如果匹配成功就放行，会自动进行后续处理。匹配不成功就禁止通行，告诉他不能通行的原因，结束本次访问。


基于角色的访问控制


其实上面讲的就是基于角色的访问控制的原理。原理很简单，如果没有特殊要求的话，实现也不难。

就是经典的五张表：

1）权限表，也称资源表，记录所有的资源URL。

2）角色表，记录所有的角色。

3）角色权限表，记录每个角色都能访问哪些权限。

4）用户表，记录所有用户。

5）用户角色表，记录每个用户被授予的角色。

按实际需求决定的部分：

1）一个用户是只能有一个角色，还是可以有多个，这个依托用户角色表即可实现。

2）角色之间是否可以继承，是单继承还是多继承，这个需要一个单独的角色继承表来存储。

两个特殊的事物：

1）一个是没有任何限制的公共资源，如js、css、images等，可以设置一个白名单，把它们放入其中，这些URL相当于“免检”。

2）一个特殊的用户，如超级管理员，这个需要在用户表进行标识，遇到它后直接放行，因为它也是“免检”。


是否选择现成的框架


常用的现成的框架就是Spring Security和Apache Shiro。它们属于上手不难，想用好却不简单的那种。

我觉得可以按以下情况来选择：

1）有专门团队或人员维护的，可以选择从零研发或基于框架的深度扩展。

2）没有专人负责，也不想麻烦的，建议不要用框架，应该自己写代码简单实现。

3）不怕麻烦的，爱研究的，可以选择框架，掌握使用方式，明白运行原理，看看底层源码。

总之，一定要做到可控，特别是自身或团队在条件不允许的情况下，千万别去捅马蜂窝。

特别推荐一个分享架构+算法的优质内容，还没关注的小伙伴，可以长按关注一下：

长按订阅更多精彩▼

如有收获，点个在看，诚挚感谢