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
