RBAC新解:基于资源的权限管理(Resource-Based Access Control)

本文讨论以角色概念进行的权限管理策略及主要以基于角色的机制进行权限管理是远远不够的。同时我将讨论一种我认为更好的权限管理方式。

什么是角色

当说到程序的权限管理时,人们往往想到角色这一概念。角色是代表一系列可执行的操作或责任的实体,用于限定你在软件系统中能做什么、不能做什么。用户帐号往往与角色相关联,因此,一个用户在软件系统中能做什么取决于与之关联的各个角色。

例如,一个用户以关联了”项目管理员”角色的帐号登录系统,那这个用户就可以做项目管理员能做的所有事情――如列出项目中的应用、管理项目组成员、产生项目报表等。

从这个意义上来说,角色更多的是一种行为的概念:它表示用户能在系统中进行的操作。

基于角色的访问控制(Role-Based Access Control)

既然角色代表了可执行的操作这一概念,一个合乎逻辑的做法是在软件开发中使用角色来控制对软件功能和数据的访问。你可能已经猜到,这种权限控制方法就叫基于角色的访问控制(Role-Based Access Control),或简称为RBAC。

有两种正在实践中使用的RBAC访问控制方式:隐式(模糊)的方式和显示(明确)的方式。

今天依旧有大量的软件应用是使用隐式的访问控制方式。但我肯定的说,显示的访问控制方式更适合于当前的软件应用。

隐式的访问控制

前面提到,角色代表一系列的可执行的操作。但我们如何知道一个角色到底关联了哪些可执行的操作呢?

答案是:目前的大多数应用,你并能不明确的知道一个角色到底关联了哪些可执行操作。可能你心里是清楚的(你知道一个有”管理员”角色的用户可以锁定用户帐号、进行系统配置;一个关联了”消费者”这一角色的用户可在网站上进行商品选购),但这些系统并没有明确定义一个角色到底包含了哪些可执行的行为。

拿”项目管理员”来说,系统中并没有对”项目管理员”能进行什么样的操作进行明确定义,它仅是一个字符串名词。开发人员通常将这个名词写在程序里以进行访问控制。例如,判断一个用户是否能查看项目报表,程序员可能会编码如下:

代码块1. 隐式地基于角色的权限控制:

if (user.hasRole("Project Manager") ) {
    //show the project report button
} else {
    //don't show the button
}

在上面的示例代表中,开发人员判断用户是否有”项目管理员”角色来决定是否显示查看项目报表按钮。请注意上面的代码,它并没有明确语句来定义”项目管理员”这一角色到底包含哪些可执行的行为,它只是假设一个关联了项目管理员角色的用户可查看项目报表,而开发人员也是基于这一假设来写 if/else 语句。

脆弱的权限策略

像上面的权限访问控制是非常脆弱的。一个极小的权限方面的需求的变动都可能导致上面的代码需要重新修改。

举例来说,假如某一天这个开发团队被告知:“哦,顺便说一下,我们需要一个’部门管理员’角色,他们也可以查看项目报表。请做到这一点。”

这种情况下,开发人员需要找到上面的代码块并将其修改为:

代码块2. 修改过的隐式的基于角色的权限控制:

if (user.hasRole("Project Manager") || user.hasRole("Department Manager") ) {
    //show the project report button
} else {
    //don't show the button
}

随后,开发人员需要更新他的测试用例、重新编译系统,还可能需要重走软件质量控制(QA)流程,然后再重新部署上线。这一切仅仅是因为一个微小的权限方面的需求变动!

后面如果需求方又回来告诉你说我们又有另一个角色可查看报表,或是前面关于”部门管理员可查看报表”的需求不再需要了,岂不把人累死了。

如果需求方要求动态地创建、删除角色以便他们自己配置角色,又该如何应对呢?

像上面的情况,这种隐式的(静态字符串)形式的基于角色的访问控制方式难以满足需求。理想的情况是如果权限需求变动不需要修改任何代码。怎样才能做到这一点呢?

显式地访问控制:更好的选择

从上面的例子我们看到,当权限需求发生变动时,隐式的权限访问控制方式会给程序开发带来沉重的负担。如果能有一种方式在权限需求发生变化时不需要去修改代码就能满足需求那就好了。理解的情况是,即使是正在运行的系统,你也可以修改权限策略却又不影响最终用户的使用。当你发现某些错误的或危险的安全策略时,你可以迅速地修改策略配置,同时你的系统还能正常使用,而不需要重构代码重新部署系统。

怎样才能达到上面的理想效果呢?我们可以通过显式的(明确的)界定我们在应用中能做的操作来进行。

回顾上面隐式的权限控制的例子,思考一下这些代码最终的目的,想一下它们最终是要做什么样的控制?

从根本上说,这些代码最终是在保护资源(项目报表),是要界定一个用户能对这些资源进行什么样的操作(查看/修改)。当我们将权限访问控制分解到这种最原始的层次,我们就可以用一种更细粒度(更富有弹性)的方式来表达权限控制策略。

我们可以修改上面的代码块,以基于资源的语义来更有效地进行权限访问控制:

代码块3. 显式的权限控制:

if (user.isPermitted("projectReport:view:12345")) {
    //show the project report button
} else {
    //don't show the button
}

上面的例子中,我们可明确地看到我们是在控制什么。不要太在意冒号分隔的语法,这仅是一个例子,重点是上面的语句明确地表示了“如果当前用户允许查看编号为12345的项目报表,则显示项目报表按钮”。也就是说,我们明确地说明了一个用户帐号可对一个的资源实例进行的具体的操作。

为什么说这种方式更好

上面最后的示例代码块与前面的代码的主要区别:最后的代码块是基于什么是受保护的, 而不是谁可能有能力做什么。看似简单的区别,但后者对系统开发及部署有着深刻的影响:

l 更少的代码重构:我们是基于系统的功能(系统的资源及对资源的操作)来进行权限控制,而相应来说,系统的功能需求一旦确定下来后,一段时间内对它的改动相应还是比较少的。只是当系统的功能需求改变时,才会涉及到权限代码的改变。例如上面提到的查看项目报表的功能,显式的权限控制方式不会像传统隐式的RBAC权限控制那样因不同的用户/角色要进行这个操作就需要重构代码;只要这个功能存在,显式的方式的权限控制代码是不需要改变的。

l 更直观:保护资源对象、控制对资源对象的操作(对象及对象的行为),这样的权限控制方式更符合人们的思想习惯。正因为符合这种直观的思维方式,面向对象的编辑思想及REST通信模型变得非常成功。

l 更有弹性:上面的示例代码中没有写死哪些用户、组或角色可对资源进行什么操作。这意味着它可支持任何安全模型的设计。例如,可以将操作(权限)直接分配给用户 ,或者他们可以被分配到一个角色,然后再将角色与用户关联,或者将多个角色关联到组(group)上,等等。你完全可以根据应用的特点定制权限模型。

l 外部安全策略管理:由于源代码只反映资源和行为,而不是用户、组和角色,这样资源/行为与用户、组、角色的关联可以通过外部的模块或专用工具或管理控制台来完成。这意味着在权限需求变化时,开发人员并不需要花费时间来修改代码,业务分析师甚至最终用户就可以通过相应的管理工具修改权限策略配置。

l 可在运行环境做修改:因为基于资源的权限控制代码并不依赖于行为的主体(如组、角色、用色),你并没有将行为的主体的字符名词写在代码中,所以你甚至可以在程序运行的时候通过修改主体能对资源进行的操作这样一些方式,通过配置的方式就可应对权限方面需求的变动,再也不需要像隐式的RBAC方式那样需要重构代码。

RBAC新解:Resource-Based Access Control

对于上面列出的诸多好处,我重点要说是这种显式的机制带给我们的富有弹性的权限模型。

如果你仍想保留或模拟传统的基于角色的权限访问控制,你可以将权限(可执行的操作)直接分配给某个角色。这种情况下,你依旧是在使用基于角色的权限访问控制方式(不同之处在于你需要明确地界定角色中的权限,而不是传统的使用角色字符串隐式地进行权限控制)。

但在这种新的模型下,已不必再局限于角色了。你可以将权限直接分配给用户、组或其它你觉得可以的对象。

因为上面显式地、基于资源的权限访问控制的诸多好处,或许可以给RBAC一个新的定义:“Resource-Based Access Control”。只是我的一个想法:)

现实世界的例子:Apache Shiro

如果你好奇现实世界有没有被多个系统使用的基于资源的权限控制框架,你可以了解一下Apache Shiro。它是一个java平台的现代权限管理框架。通过它的权限(Permission)概念,Shiro很好地支持基于资源的权限访问控制。

当然,并不需要借用Shiro来理解本文所说的一些概念,但Shiro对理解本文所讨论的概念及示例有一定的帮助。

(原文地址:http://www.katasoft.com/blog/2011/05/09/new-rbac-resource-based-access-control)

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏BestSDK

一款完美的SDK产品,肯定具备这9个特质

即保证用户能够在5分钟以内学会使用代码。这一点非常重要,特别是考虑到有时候用户会评估我们的产品——如果无法轻松上手,他们很可能直接选择放弃。 ? 1. 简单性 ...

463100
来自专栏WeTest质量开放平台团队的专栏

浅谈服务器性能测试的全生命周期——从测试、结果分析到优化策略

服务器性能测试是一项非常重要而且必要的工作,本文是作者Micheal在对服务器进行性能测试的过程中不断摸索出来的一些实用策略,通过定位问题,分析原因以及解决问题...

29540
来自专栏JAVA高级架构

分布式架构的演进

系统架构演化历程-初始阶段架构 ? 初始阶段 的小型系统 应用程序、数据库、文件等所有的资源都在一台服务器上通俗称为LAMP特征:应用程序、数据库、文件等所有的...

51290
来自专栏DevOps时代的专栏

istio 是啥?一文带你简单了解!

如果你比较关注新兴技术的话,那么很可能在不同的地方听说过 istio,并且知道它和 service mesh 有着牵扯。这篇文章是我之前在公司内部做过的分享,可...

1.5K10
来自专栏开发与安全

建议程序员都读一读的31篇论文系列笔记(1~2)

序:前几日网上偶然看到”程序员必读论文系列“,顺便搜了一下,发现有多个版本共31篇,不过看起来都不错,故准备花时间都读一下,可以拓宽下视野。来源论文题目主要参考...

25500
来自专栏即时通讯技术

腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面

我们常常会听说,某个互联网应用的服务器端系统多么牛逼,比如QQ、微信、淘宝。那么,一个大型互联网应用的服务器端系统,到底牛逼在什么地方?为什么海量的用户访问,会...

28730
来自专栏Python小白进阶之旅

学会了爬虫,然后我一不小心就统治了整个Python吧

23180
来自专栏禁心尽力

基于服务的SOA架构_后续篇

昨天简单介绍了一下本人在近期开发过的一个电商购物平台的架构流程和一些技术说明;今天将详细总结一下在项目中用到的各个架构技术的环境部署和细节,希望能够帮到大家,如...

226100
来自专栏后端技术探索

携程异步消息系统实践

今天会跟大家分享一下我们在携程,现在应该是正在推广的一个新的消息系统,主要会偏重于讲一些架构和实现方面的内容。目前我在携程大概一年多都在做新的消息系统Herme...

16530
来自专栏编程心路

GitHub学习文档-1

首先 GitHub 是一个平台级的软件,在 PC端,网页端,手机端都有相应的应用,下面都是根据 GitHub 的网页端介绍的。GitHub 可以看做是一个面向开...

14560

扫码关注云+社区

领取腾讯云代金券