查看原文
其他

基于角色的访问控制(RBAC)

CSDN云计算 2020-02-17

The following article comes from 编程新说 Author 编程新说李新杰

来源 | 编程新说
责编 | Carol
出品 | CSDN云计算(ID:CSDNcloud)

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

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

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)不怕麻烦的,爱研究的,可以选择框架,掌握使用方式,明白运行原理,看看底层源码。

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



福利扫描添加小编微信,备注“姓名+公司职位”,入驻【CSDN博客】,加入【云计算学习交流群】,和志同道合的朋友们共同打卡学习!



推荐阅读:真香,朕在看了!猛戳“阅读原文”,填写中国远程办公-调查问卷

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存