本文讨论以角色概念进行的权限管理策略及主要以基于角色的机制进行权限管理是远远不够的。同时将讨论一种更好的权限管理方式。
当说到程序的权限管理时，人们往往想到角色这一概念。角色是代表一系列行为或责任的实体，用于限定你在软件系统中能做什么、不能做什么。用户帐号往往与角色相关联，因此，一个用户在软件系统中能“做”什么取决于与之关联的各个角色。
例如，一个用户以关联了”项目管理员”角色的帐号登录系统，那这个用户就可以做项目管理员能做的所有事情――如列出项目中的应用、管理项目组成员、产生项目报表等。
从这个意义上来说，角色更多的是一种行为的概念：它表示用户能在系统中进行的操作。
既然角色代表了可执行的操作这一概念，一个合乎逻辑的做法是在软件开发中使用角色来控制对软件功能和数据的访问。你可能已经猜到，这种权限控制方法就叫基于角色的访问控制(Role-Based Access Control)，或简称为 RBAC。
有两种正在实践中使用的 RBAC 访问控制方式：隐式的方式和显示的方式。
今天依旧有大量的软件应用是使用隐式的访问控制方式。但我肯定的说，显示的访问控制方式更适合于当前的软件应用。
前面提到，角色代表一系列的可执行的操作。但我们如何知道一个角色到底关联了哪些可执行的操作呢？
答案是：目前的大多数应用，你并能不明确的知道一个角色到底关联了哪些可执行操作。可能你心里是清楚的（你知道一个有”管理员”角色的用户可以锁定用户帐号、进行系统配置；一个关联了“消费者”这一角色的用户可在网站上进行商品选购），但这些系统并没有明确定义一个角色到底包含了哪些可执行的行为。
拿”项目管理员”来说，系统中并没有对“项目管理员”能进行什么样的操作进行明确定义，它仅是一个字符串名词。开发人员通常将这个名词写在程序里以进行访问控制。例如，判断一个用户是否能查看项目报表，程序员可能会编码如下 参考:
代码块1.隐式地基于角色的权限控制:
if (user.hasRole("Project Manager") ) {
//显示报表按钮
} else {
//不显示按钮
<strong>}
在上面的示例代表中，开发人员判断用户是否有“项目管理员”角色来决定是否显示查看项目报表按钮。请注意上面的代码，它并没有明确语句来定义”项目管理员”这一角色到底包含哪些可执行的行为，它只是假设一个关联了项目管理员角色的用户可查看项目报表，而开发人员也是基于这一假设来写 if/else 语句。
像上面的权限访问控制是非常脆弱的。一个极小的权限方面的需求的变动都可能导致上面的代码需要重新修改。
举例来说，假如某一天这个开发团队被告知：“哦，顺便说一下，我们需要一个‘部门管理员’角色，他们也可以查看项目报表。请做到这一点。”
这种情况下，开发人员需要找到上面的代码块并将其修改为：
代码块2.修改过的隐式的基于角色的权限控制:
if (user.hasRole("Project Manager") || user.hasRole("Department Manager") ) {
//显示报表按钮
} else {
//不显示按钮
}
随后，开发人员需要更新他的测试用例、重新编译系统，还可能需要重走软件质量控制(QA)流程，然后再重新部署上线。这一切仅仅是因为一个微小的权限方面的需求变动！
后面如果需求方又回来告诉你说我们又有另一个角色可查看报表，或是前面关于“部门管理员可查看报表”的需求不再需要了，怎么办？
如果需求方要求动态地创建、删除角色以便他们自己配置角色，又该如何应对呢？
像上面的情况，这种隐式的(静态字符串)形式的基于角色的访问控制方式难以满足需求。理想的情况是如果权限需求变动不需要修改任何代码。怎样才能做到这一点呢？
从上面的例子我们看到，当权限需求发生变动时，隐式的权限访问控制方式会给程序开发带来沉重的负担。如果能有一种方式在权限需求发生变化时不需要去修改代码就能满足需求那就好了。理解的情况是，即使是正在运行的系统，你也可以修改权限策略却又不影响最终用户的使用。当你发现某些错误的或危险的安全策略时，你可以迅速地修改策略配置，同时你的系统还能正常使用，而不需要重构代码重新部署系统。
怎样才能达到上面的理想效果呢？我们可以通过显式的(明确的)界定我们在应用中能做的操作来进行。
回顾上面隐式的权限控制的例子，思考一下这些代码最终的目的，想一下它们最终是要做什么样的控制？
从根本上说，这些代码最终是在保护资源(项目报表)，是要界定一个用户能对这些资源进行什么样的操作(查看/修改)。当我们将权限访问控制分解到这种最原始的层次，我们就可以用一种更细粒度(更富有弹性)的方式来表达权限控制策略。
我们可以修改上面的代码块，以基于资源的语义来更有效地进行权限访问控制：
代码块3.显式的权限控制:
if (user.isPermitted("projectReport:view:12345")) {
//显示报表按钮
} else {
//不显示按钮
}
上面的例子中，我们可明确地看到我们是在控制什么。不要太在意冒号分隔的语法，这仅是一个例子，重点是上面的语句明确地表示了“如果当前用户允许查看编号为12345的项目报表，则显示项目报表按钮”。也就是说，我们明确地说明了一个用户帐号可对一个的资源实例进行的具体的操作。
上面最后的示例代码块与前面的代码的主要区别：最后的代码块是基于什么是受保护的， 而不是谁可能有能力做什么。看似简单的区别，但后者对系统开发及部署有着深刻的影响：
对于上面列出的诸多好处，我重点要说是这种显式的机制带给我们的富有弹性的权限模型。
如果你仍想保留或模拟传统的基于角色的权限访问控制，你可以将权限(可执行的操作)直接分配给某个角色。这种情况下，你依旧是在使用基于角色的权限访问控制方式(不同之处在于你需要明确地界定角色中的权限，而不是传统的使用角色字符串隐式地进行权限控制)。
但在这种新的模型下，已不必再局限于角色了。你可以将权限直接分配给用户、组或其它你觉得可以的对象。
因为上面显式地、基于资源的权限访问控制的诸多好处，或许可以给 RBAC 一个新的定义：“Resource-Based Access Control”。只是我的一个想法：）
如果你好奇现实世界有没有被多个系统使用的基于资源的权限控制框架，你可以了解一下Apache Shiro。它是一个java 平台的现代权限管理框架。通过它的权限Permission概念，Shiro 很好地支持基于资源的权限访问控制。
当然，并不需要借用 Shiro 来理解本文所说的一些概念，但 Shiro 对理解本文所讨论的概念及示例有一定的帮助。
参考：
原文链接：
「龙归科技」 是一个专注于低代码赋能企业级信息化服务提供商。核心创始人团队来自绿盟安全、红帽开源操作系统、知名游戏玩蟹科技、知名开源社区等专家共同创立。
「龙归科技」 致力于让中国每一个企业拥有专属的自动化办公操作系统，助力企业或政府拥抱 （Cloud Native First）云原生优先战略，帮助客户构筑以「身份与应用」为中心的现代化 IT 基础设施！从而实现 「数字化转型」 及 「软件行业工业化生产」 ！
主打产品：ArkOS方舟操作系统：一个企业级办公自动化操作系统 ，结合自研低代码应用开发平台，构建产业生态，专注为各类企业与组织机构打造一体化全栈云原生平台。系统自带应用包括：ArkID 统一身份认证，ArkIDE，ArkPlatform，App Store 等产品。截至目前，公司已经获得 15个 软件著作权、2个发明专利，并与2020年11月份，获得北京海淀区中关村国家高新技术企业认定。
官网：https://www.longguikeji.com/
文档：https://docs.arkid.longguikeji.com/
开源代码仓库地址：
https://github.com/longguikeji
历史文章