大量权限如何管理？
我正在开发一个具有 CRM 功能的大型 Java EE Web 应用程序，我们正在寻找一种安全方法/库/解决方案/任何东西。基于角色的基本安全性将不起作用，因为访问控制必须基于角色和层次结构，但必须可以根据文档进行选择性自定义。由于将存储机密和专有信息，因此要求安全性正常工作。
示例：要使用百货商店，货架跟踪者库存人员可以创建其他库存人员可以读取的报告仅当在同一个部门。现在，他们的部门经理可以读取/写入/更新/删除由库存人员编写的所有报告，并编写所有其他部门经理可以读取但看不到商店经理等的报告，而区域经理可以读/写/更新/删除这些报告等现在，复杂性是：较高级别的人员可以让较低级别的人员看到事情，无论是个人（部门向几个特定的库存员）用户还是他们下面的每个人（商店经理向整个商店写入备忘录）或任何人。你可以想象的排列。此外，个人可以创建其他人无法看到的报告，或者可以选择向其他地区的商店库存员授予访问权限等。
我们正在考虑为每个实体提供一个权限的 ACL，但担心会创建大量记录。即使只有一份报告可供 30 人的部门中的其他所有人以及他们之上的每个人（在指挥链中）阅读，创建一份报告也需要大约 40 条记录！每个用户每周 1 个报告，即每个用户每年 2000 个权限。 1,500 个用户意味着每年超过 3,000,000 个权限。
看起来基于规则引擎的方法会很好，但我还没有看到任何博客或文章提到这种方法，所以我们对这种方法犹豫不决。
我们还在考虑一些 ACL/规则自制混合，您可以向带有“经理”或“库存员”等鉴别器的部门 ID 授予权限以进行子选择，但担心检查所有可能的权限（您可能会被授予特别是另一个用户的许可，您作为部门成员获得许可，您可以作为商店或地区成员获得许可）听起来像是一个容易出错的乏味噩梦。
我们的应用程序的最佳方法是什么？
I am working on a large Java EE web-app with CRM functionalit and we are looking for a security approach/library/solution/anything. Basic role-based security won't work since access control must be based on both role and hierarchy, but must be optionally customisable per document. Because there will be confidential and proprietary information stored, it is a requirement that the security works properly.
Example: To use department store, shelf stalkers stockers can create reports that other stockers can read only if they are in the same department. Now their department manager can read/write/update/delete all reports written by stockers and write reports that all others department managers can read but not see reports of store managers, etc, whom the district managers can r/w/u/d etc. Now, the complications: people at higher levels can make things visible to people at lower levels, either to individuals (department writes document to several specific stockers) users or everyone below them (store manager writes a memo to the entire store) or any permutation you can imagine. Also, individuals can create reports that their peers cannot see or they can choose grant access to store stockers in other districts etc.
We are considering an ACL with one permission per entity, but are worried about the large number of records that would create. Even if only a report was readable to everyone else in a department of 30 and every person above them [in the chain of command], creating a single report would require ~40 records! With 1 report per week per user that is 2000 permissions per user per year. 1,500 users means over 3,000,000 permissions per year.
It seems like a rule-engine based approach would be nice, but I have not seen any blogs or articles mentioning that approach so we're hesitant to that approach.
We are also considering some ACL/rule home-brew hybrid where you could grant permission to a department id with a discriminator of "manager" or "stockers" etc to subselect, but are worried that checking for all possible permissions (you could be granted permission specifically by another user, you have permission as a memeber of your department, you could have permission as a member of a store, or of district) sounds like an error-prone tedious nightmare.
What is the best approach for our application?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以考虑使用 Spring Security 和 ACL - Springs ACL 实现的好处是它是使用 AoP 实现的，应该更容易集成。
听起来您的安全要求非常复杂 - 我不知道您将如何实现这一点..但是您可以通过针对对象层次结构创建 ACL 并让对象“继承”权限来减少所需的记录数量来自父对象。您授予用户对报告的父部门的读取权限 - 这样他们就可以继承对该部门的子报告的读取权限。或者，经理可能具有部门的读取和更新权限。这一切的关键是你的java对象模型是如何构建的。
我在一个系统中也遇到过类似的情况，其中业务部门--出版--问题--文章的对象层次结构中有数千篇文章。您可以拥有 ACL 的层次结构 - 因此在我的系统中 - 对特定业务单位具有 C/R/W 权限的用户继承了层次结构中所有子对象的权限。
You could look at using Spring Security and ACL's - the nice thing about Springs ACL implementation is it is implemented with AoP it should be easier to integrate.
It sounds like your security requirements are quite complicated - off the top of my head I dont know how you'd implement this.. but you can reduce the number of records required by creating ACL's against your object hierarchy and having objects 'inherit' permissions from parent objects. You grant a user read permissions to the parent Department of a Report - so they would inherit read access to the child reports of that department. Alternatively a Manager might have read and update permissions on the Department. The key to all this is how your java object model has been structured.
I have had a similar situation in a system where there were thousands of articles in an object hierarchy of Business Unit -- Publication -- Issue -- Article. You can have hierarchys of ACL's - so in my system - users that had C/R/W permissions to a particular business unit, inherited permissions on all child objects in the hierarchy.
在我看来，定制 + 复杂性 = JBoss Drools，我没有太多使用这项技术的经验，但我相信在您的情况下值得一看，请查看最新的 drools 示例：http://blog.athico.com/2011/04/try-drools-示例-不到-分钟.html
In my opinion Customization + Complexity = JBoss Drools, I don't have much experience using this technology but I believe it would be worth a look in your case, check out the latest drools samples at: http://blog.athico.com/2011/04/try-drools-example-in-less-than-minute.html