为什么RBAC同时具有角色和权限？

Question

我最常看到基于角色的访问控制（RBAC）需要权限才能执行操作。为主题分配了授予其权限的角色。

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

Answer 1

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

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

根据您需要什么样的灵活性，您可以选择这个新的框架。有时，如果应用程序满足非常特定的需求，则不具有用户可定义的角色是可以的。以Tomcat Manager为例——它几乎没有预定义的角色——这似乎对大多数用例来说已经足够了。

Answer 2

RBAC标准[0]在四个级别上定义。RBAC0定义用户，角色，权限（对对象执行的操作）及其分配。RBAC1添加了定义角色层次结构，RBAC2添加了诸如职责分离等约束。我不认为RBAC3与此相关。授权模型（如RBAC）的要点是将策略与代码分开，以便在不修改代码的情况下对策略进行更改。在系统管理员无权访问代码的情况下，或者在每次更改访问控制策略后无法重新部署系统的情况下，这一点尤为重要。

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