我经常看到需要权限才能执行操作的基于角色的访问控制(RBAC)。为受试者分配授予他们权限的角色。
我最近遇到了一个授权库,它没有单独的权限和角色概念。主题仍然被授予角色,但授权检查直接在角色上完成,并且没有权限的概念。我担心这种设计有缺点,因为我经常看到这种设计。由于角色和权限以这种方式组合可能会出现什么问题?在这个系统中哪些事情更难?
答案 0 :(得分:1)
通常,“角色”是应用程序管理员根据业务/用户需求定义的内容。并且“权限”是应用程序预定义的内容。只要应用程序中存在需要访问控制的功能,就会向系统添加新的“权限”,这涉及一些开发工作。相反,添加新角色是一个配置问题,可以从应用程序界面(GUI或命令行工具)完成。拥有“角色”并为角色分配“权限”有助于创建具有不同访问级别的多个角色。
在您所描述的系统中,似乎创建新的“角色”需要更改应用程序,因为每个“角色”似乎都带有预定义的权限。
根据您需要的灵活性,您可以选择是否使用此新框架。有时,如果应用程序满足非常特定的需求,那么就没有用户可定义的角色。以Tomcat Manager为例 - 其中包含几个预定义的角色 - 这似乎足以满足大多数用例。
答案 1 :(得分:1)
RBAC标准[0]定义为四个级别。 RBAC0定义users
,roles
,permissions
(要actions
执行objects
)及其分配。 RBAC1添加了定义角色层次结构,RBAC2添加了separation of duty
等约束。我不认为RBAC3与此相关。
诸如RBAC之类的授权模型的目的是将策略与代码分开,以便可以在不修改代码的情况下对策略进行更改。在系统管理员无法访问代码,或者在每次更改访问控制策略后无法负担重新部署系统的情况下,这一点尤为重要。
你提到的授权库的工作方式不同,我认为它实际上并没有实现RBAC标准,至少从迂腐的角度来看。通过取消权限,授权逻辑将集成到代码中,在授予(或拒绝)访问某些功能之前查找特定角色。优点是管理员不必担心权限分配。然而,缺点是对特定功能所需角色的任何改变都需要对代码本身进行更改,可能在很多地方。缺少其中一些将导致讨厌的错误。