代表 LDAP 中的 RBAC 参与者
当使用 LDAP 存储实现 RBAC 模型时（我使用 Apache Directory 1.0.2 作为测试平台），一些参与者显然可以映射到特定的对象类：
- 资源 - 我没有看到这一点的清晰映射。 applictionEntity 似乎只是出于此目的而
- 切线权限 - 权限可以被视为单一目的角色； 显然我没有考虑 LDAP 权限，因为它们管理对 LDAP 对象和属性的访问，而不是对资源
- 角色的 RBAC 权限 - 相当直接地映射到 groupOfNames 或 groupOfUniqueNames，对吗？
- 用户 - 人
在过去，我见过一些模型，其中资源不以任何方式在目录中处理，并且权限和角色被映射到 Active Directory 组。
有没有更好的方式来代表这些演员？ 讨论架构的良好映射和意图的文档怎么样？
When implementing an RBAC model using an LDAP store (I'm using Apache Directory 1.0.2 as a testbed), some of the actors are obviously mappable to specific objectClasses:
- Resources - I don't see a clear mapping for this one. applictionEntity seems only tangentially intended for this purpose
- Permissions - a Permission can be viewed as a single-purpose Role; obviously I'm not thinking of an LDAP permission, as they govern access to LDAP objects and attributes rather than an RBAC permission to a Resource
- Roles - maps fairly directly to groupOfNames or groupOfUniqueNames, right?
- Users - person
In the past I've seen models where a Resource isn't dealt with in the directory in any fashion, and Permissions and Roles were mapped to Active Directory Groups.
Is there a better way to represent these actors? How about a document discussing good mappings and intents of the schema?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
RBAC 不是 RBAC 不是 RBAC，RBAC 在纸面上很困难，但在现实生活中几乎不可能实现。
每个人对 RBAC 都有自己的“想法”，并且大多数人对与 RBAC 相关的每个事物都使用不同的术语。 一般来说，从 LDAP 实现的角度来看，您很少拥有在 LDAP 中进行正确实现的所有“部件”。
简单来说，“各个部分”是：
S = 主题 = 个人或自动代理或用户
P = 权限 = 批准访问目标资源的模式
T = 目标资源 = 您要向其分配权限的对象
角色至少需要关联权限和用户。
目标资源可以完全位于 LDAP 之外。 因此，它可能是 Tomcat 服务器上的应用程序，也可能只是读取 LDAP 服务器中“其他”条目的权限。
因此，通常在 LDAP 中最好的做法是设置一个包含用户列表的对象，如果 LDAP 中有一些资源，请为这些目标资源分配适当的目录权限。
然后是实施方面的小问题。
我们现在需要一项政策来实施我们的角色。 因此，如果没有关于如何使用它的策略，我们的角色（我们将其称为“用户只读”）就没有用。
在我们的例子中，我们可以说用户只读角色可以读取我们组织中的任何内容。
所以我们现在有一个政策。 该策略存储在哪里？ 保单的数字表示形式存储在“保单信息点”或 PIP 中。
我们如何解释 PIP 提供的政策？ 策略由策略决策点 (PDP) 解释。
谁决定主体（用户）是否可以访问资源？ 政策执行点 (PEP)。
将所有这些策略内容放在一起，我们最终得到策略的数字表示，由策略信息点提供给策略决策点，然后策略决策点将决策传递给策略执行点，在策略执行点允许或拒绝访问。
那么在我们的 RBAC 故事中，PIP、PDP 和 PEP 在哪里？
好吧，如果目标资源位于 LDAP 目录中，那么 LDAP 目录就是 PIP（我们可能是硬编码的并且不是抽象的，PIP 同样如此，PEP 也是如此，这很容易。
但是如果它是我们的 Tomcat应用程序，它必须是 Tomcat 应用程序中的一个方法，可以中断知道必须使用一个方法来表示“我有这个主题（用户）并且他想要访问此目标资源（库存）以执行此权限（只读）”当然
，所有这些东西都有一些标准（Google XAML、RFC3198、ISO10181-3、NIST），但它们与实际实现存在很大差距，
因此请记住，真正实现 RBAC 很困难。强>
当然，恕我直言，我们应该了解 RBAC，研究论文并将其作为战略方向，但在广泛的供应商和应用程序基础上的现实生活中，我们还没有做到这一点
-jim 。
RBAC is not RBAC is not RBAC and RBAC on paper is difficult, but nearly impossible to implement in a real-life.
Everyone has their own "idea" of RBAC and most everyone uses different terms for every thing associated with RBAC. Generally from an LDAP implementation perspective you seldom have all the "pieces parts" to do a proper implementation within LDAP.
The "pieces parts" in simple terms are:
S = Subject = A person or automated agent or Users
P = Permissions = An approval of a mode of access to a Target Resource
T = Target Resources = The Object to which you want to assign permissions
The Role, at minimum, needs to associate a Permission and a User.
The Target Resource could be outside of LDAP entirely. So it could be an Application on a Tomcat server or simply the right to read "other" entries within the LDAP Server.
So typically the best you will do within LDAP is to setup an object which has a list of users and if there are some resources that are within LDAP, assigne the proper directory permissions for those target resources.
Then there is the little problem implementation.
We have now need a Policy for implementation of our Role. So our role, we will call it USER-READ-ONLY, is not useful without a policy on how it is to be used.
In our case, we could just say the USER-READ-ONLY Role can read anything in our Organization.
So we now have a Policy. Where is this policy stored? The Digital representation of a Policy is stored in the "Policy information Point" or PIP.
How do we interpret the Policy Supplied from the PIP? Policies are interpreted by the Policy Decision Point (PDP).
Who decides if a Subject (user) can access a resource? The Policy Enforcement Points (PEP).
Putting all this policy stuff together we end up with the digital representation of the Policy is provided by the policy Information Point to the policy Decision Point which then passes the decision to the Policy Enforcement Point where the access is permitted or denied.
So in our RBAC story, where is the PIP, the PDP, and the PEP?
Well if the Target Resource is in the LDAP directory, then it is the LDAP directory that is the PIP (which we probably hardcoded and is not abstracted, the PIP likewise and the PEP too, and that was easy.
But if it is our Tomcat Application, it MUST be a method within the Tomcat Application that can interrupt knows must use a method to say "I have this Subject (user) and he wants access to this Target Resource (inventory) to perform this Permission (READ-ONLY)".
Sure there are some standards for all this stuff. (Google XAML, RFC3198, ISO10181-3, NIST) but they are Standards with wide gaps for practical implementations.
So keep in mind REAL implementations of RBAC is hard.
Sure IMHO, we should know about RBAC, study the papers and make it a strategic direction, but the real life implementation across a broad base of vendors and applications, well we are just not there yet.
-jim
查看 Fortress，它是使用 LDAP 的 ANSI RBAC (INCITS 359) 的真实开源实现。 http://iamfortress.org/
是的，实施起来相当困难，但我们一直在努力解决这个问题超过10年。 ;-)
Check out Fortress which is a real-life, open source implementation of ANSI RBAC (INCITS 359) that uses LDAP. http://iamfortress.org/
and yes it was fairly difficult to implement but we've been working on this problem for over 10 years. ;-)