RBAC(基于角色的访问控制)不是简单的概念,实际上在现实中实现起来几乎是不可能的。每个人都有自己对RBAC的“想法”,而且大多数人使用与RBAC相关的不同术语。从LDAP实现的角度来看,你很少拥有所有“部件”来正确地在LDAP中实施RBAC。
简单来说,“部件”包括:
S = 主体 = 人或自动代理或用户
P = 权限 = 对目标资源模式的访问批准
T = 目标资源 = 想要分配权限的对象
角色至少需要关联一个权限和一个用户。目标资源可以完全位于LDAP之外。因此,它可以是Tomcat服务器上的应用程序,也可以是仅具有读取LDAP服务器中的“其他”条目的权限。
因此,在LDAP中最好的情况通常是设置一个包含用户列表的对象,如果有一些资源在LDAP中,则为这些目标资源分配适当的目录权限。
然后就是实现的小问题了。
我们现在需要一个实施我们角色的策略。因此,我们称之为USER-READ-ONLY的角色在没有使用策略的情况下是无用的。
在我们的情况下,我们可以说USER-READ-ONLY角色可以读取我们组织中的任何内容。
所以现在我们有一个策略。这个策略存储在哪里?策略的数字表示存储在“策略信息点”或PIP中。
我们如何解释从PIP提供的策略?策略由策略决策点(PDP)解释。
谁决定主体(用户)是否可以访问资源?策略执行点(PEP)。
将所有这些策略内容放在一起,我们最终得到的是策略的数字表示由策略信息点提供给策略决策点,然后将决策传递给策略执行点,其中允许或拒绝访问。
因此,在我们的RBAC故事中,PIP、PDP和PEP在哪里?
如果目标资源位于LDAP目录中,则LDAP目录就是PIP(我们可能已经硬编码了它而且不是抽象的),PIP同样也是如此,PEP也是如此,这很容易。
但是,如果是我们的Tomcat应用程序,则必须是Tomcat应用程序中的方法,可以中断并知道必须使用方法来说“我有这个主体(用户),他想要访问这个目标资源(库存)以执行此权限(只读)”。
当然,有一些标准适用于所有这些内容。(Google XAML,RFC3198,ISO10181-3,NIST),但它们是具有实际实现的广泛差距的标准。
因此,请记住,RBAC的实际实现很难。
我认为我们应该了解RBAC,并将其作为战略方向进行研究,但是在广泛的供应商和应用程序中实现RBAC,我们还没有达到那个水平。
-jim