RBAC vs ABAC

Posted 2021-05-01 零君聊软件

RBAC和ABAC是两种不同的访问权限控制模式。RBAC是Role-Based Access Control的首字母缩写，而ABAC则是Attribute-Based Access Control的首字母缩写。本文简要描述了两者的区别和联系。

什么是访问控制

访问控制就是对用户的访问权限进行控制。具体来说，就是控制谁（主体）可以对什么资源做什么操作。

Subject: 主体

Resource：资源

Action：操作

具体可以参考零君以前写的一篇文章《》。

RBAC

RBAC根据用户的角色（role）进行权限控制。在大型的企业应用中，角色通常是根据不同的工作岗位来设置，例如Manager、Employee等。每个角色被赋予一组权限，可以针对不同的资源进行某些操作。用户通常不会被直接赋予权限，而是通过分配不同的角色从而获得相应的权限。

例如，假设“Teacher”是一个角色，只有Teacher才能登录课程管理系统。而Alice是一个Teacher，因此Alice就具有登录课程管理系统的权限。

ABAC

ABAC又称为基于策略的访问控制（Policy-Based Access Control）。而每一条策略可以使用任何属性来定义。例如每个教师有一个属性“系”，而每一门课程也有一个属性“系”，那么就可以定义一个策略，只有某个教师与某门课程属于同一个系，那么这个教师就可以查看该课程的详细信息。

通常来说，有三种类型的属性：

1、Subject的属性

2、Resource的属性

3、系统属性

将上面的策略稍微修改一下，只有某个教师与某门课程是同一个系，并且只有在早上9点到下午5点之间，该教师才能查看这门课程的详细信息。那么Subject（教师）和Resource（课程）都具有属性“系”，而时间范围属于系统属性。

RBAC与ABAC的区别和联系

RBAC一般用于粗粒度的权限控制，而ABAC则用于细粒度的权限控制。例如只要是本校的学生都可以从图书馆借阅任何书籍，那么使用RBAC足以。但是如果再加一条限制，任何学生只要在过去半年内逾期归还过图书，那么不能借阅价值超过100元的书籍，那么就要用ABAC来控制了。这里就涉及到几个属性，首先每个学生有一个属性记录最近一次逾期归还书籍的时间，每本书有一个属性来记录该书的价值，最后还涉及到一个系统时间属性。

通常来说，应该尽量优先使用RBAC，然后再考虑使用ABAC。但是在实际应用中，往往会将两者结合起来使用。在实际的应用中，很自然的就可以将实际的各种角色（例如教师、学生等）映射成RBAC中的Role，所以RBAC让人比较容易接受。而另一方面，RBAC又不是很灵活，所以就需要借助于ABAC来处理各种特殊权限控制的需要。

在实际的实现中，不必拘泥于概念上的限制。例如在RBAC中，权限只能赋予某个Role，然后某个用户与某些Role绑定从而获取相应的权限；而实际的实现中，可以直接给某个用户赋予某些权限。

另外，注意一点，本文讲的是权限控制是通用的解决方案（generic solution）。而实际上各个开源项目往往会根据自己的应用场景定制一套权限控制系统。例如在Kubernetes中为某个Role赋予操作某些Resource的权限时，Resource都是预定义的，比如Pod, jobs等等，而且action也只能从特定的action列表中选择。

到目前为止，针对authentication有generic的解决方案。例如现在很多应用都可以直接用微信（WeChat）账户登录了。在Cloud上，也有generic的Identity authentication解决方案，例如Oracle 的IDCS（Identity Cloud Service）。

但是对于authorization还没有类似的generic的解决方案。至于原因，是多方面。首先，是基于性能的考虑，对于Authentication来说，只有第一次登录时需要访问Identity service；而对于Authorization来说，每一个请求都需要与远程的authorization service进行交互，对于性能肯定是有影响的。不过这一点应该还是有解决方案的。另外，一般很多大型软件都倾向于针对自己的应用定制一套权限控制系统，而不会使用第三方的generic的authorization service。当然，在云计算时代，这个可能会有所改变。例如假如你已经购买了 AWS或Oracle的云服务，而这些Cloud Provider已经集成了Access Control的Service，那么直接使用这些Access Control Service就应该是自然的事情。

--END--