为什么RBAC既有角色又有权限？

Question

我经常看到需要权限才能执行操作的基于角色的访问控制（RBAC）。为受试者分配授予他们权限的角色。

我最近遇到了一个授权库，它没有单独的权限和角色概念。主题仍然被授予角色，但授权检查直接在角色上完成，并且没有权限的概念。我担心这种设计有缺点，因为我经常看到这种设计。由于角色和权限以这种方式组合可能会出现什么问题？在这个系统中哪些事情更难？

Answer 1

通常，“角色”是应用程序管理员根据业务/用户需求定义的内容。并且“权限”是应用程序预定义的内容。只要应用程序中存在需要访问控制的功能，就会向系统添加新的“权限”，这涉及一些开发工作。相反，添加新角色是一个配置问题，可以从应用程序界面（GUI或命令行工具）完成。拥有“角色”并为角色分配“权限”有助于创建具有不同访问级别的多个角色。

在您所描述的系统中，似乎创建新的“角色”需要更改应用程序，因为每个“角色”似乎都带有预定义的权限。

根据您需要的灵活性，您可以选择是否使用此新框架。有时，如果应用程序满足非常特定的需求，那么就没有用户可定义的角色。以Tomcat Manager为例 - 其中包含几个预定义的角色 - 这似乎足以满足大多数用例。

Answer 2

RBAC标准[0]定义为四个级别。 RBAC0定义users，roles，permissions（要actions执行objects）及其分配。 RBAC1添加了定义角色层次结构，RBAC2添加了separation of duty等约束。我不认为RBAC3与此相关。 诸如RBAC之类的授权模型的目的是将策略与代码分开，以便可以在不修改代码的情况下对策略进行更改。在系统管理员无法访问代码，或者在每次更改访问控制策略后无法负担重新部署系统的情况下，这一点尤为重要。

你提到的授权库的工作方式不同，我认为它实际上并没有实现RBAC标准，至少从迂腐的角度来看。通过取消权限，授权逻辑将集成到代码中，在授予（或拒绝）访问某些功能之前查找特定角色。优点是管理员不必担心权限分配。然而，缺点是对特定功能所需角色的任何改变都需要对代码本身进行更改，可能在很多地方。缺少其中一些将导致讨厌的错误。