数据库独立的行级安全解决方案
有人知道 Java/C# 数据库独立授权库吗？该库应支持跨公司组织结构的读、写、删除、插入操作。
像这样的事情：
- 用户可以查看所有文档
- 用户可以输入分配给他的单位的新文档
- 用户可以更改分配给他的单位和所有下属单位的所有文档。
- 用户可以删除分配给他的文档
我还应该能够创建自定义操作（除了读、写......），将它们连接到某个类并将该“安全令牌”分配给用户（例如 document.expire）。 如果没有任何免费或商业图书馆，是否有一本书可用于实现此功能？
谢谢。
does anybody knows about Java/C# database independent authorization library. This library should support read, write, delete, insert actions across company organizational structure.
Something like this:
- user can see all documents
- user can enter new document assigned to his unit
- user can change all documents assigned to his unit and all subordinate units.
- user can delete documents that are assigned to him
I should also be able to create custom actions (besides read, write,...) connect them to certain class and assign that "security token" to user (e.g. document.expire).
If there aren't any either free or commercial libraries, is there a book that could be useful in implementing this functionality?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我也对缺乏安全框架感到惊讶。
有Rhino Security。 Ayende 有一些关于它的博客文章。
另一个博客有夫妇的文章 也有关它。
可以将其与 S#arp 架构 也是如此。
不能说我已经在项目中实现了它，只是不久前阅读过它。这是我能找到的唯一的此类实现。
I, too, am surprised at the lack of security frameworks.
There is Rhino Security. Ayende has a handful of blog posts about it.
Another blog has a couple of articles on it, too.
It is possible to use it with S#arp Architecture as well.
Can't say I've implemented it in a project, just read up on it a while back. It was the only implementation of its sort that I could find.
我发现一个库的功能与我的需求类似：
http://www.codeproject。 com/KB/database/AFCAS.aspx
奇怪的是，网络上没有更多这样的内容，因为这是每个严肃的应用程序都面临的问题。至于文档/示例，我发现最好的是 CRM 系统的授权模块，例如：
- Siebel - Siebel 安全指南 - 第 10 章.访问控制
- Sugar CRM - http://www.sugarcrm.com/crm/产品/功能/管理/access.html
- Microsoft CRM - http://msdn.microsoft.com/en-us/ Library/ms955698.aspx
这是我需要的一种功能。我想这将是 DIY 任务。
I found one library that has functionality similar to my needs:
http://www.codeproject.com/KB/database/AFCAS.aspx
It is strange that there aren't any more of it on web since this is a problem that every serious application faces. As for documentation/example, the best I found are authorization modules of CRM systems like:
- Siebel - Siebel security guide - Chapter 10.Access Control
- Sugar CRM - http://www.sugarcrm.com/crm/products/capabilities/administration/access.html
- Microsoft CRM - http://msdn.microsoft.com/en-us/library/ms955698.aspx
That is a kind of functionality I need. I guess it will be DIY task.
在客户端库中实施安全解决方案的问题在于它仅对客户端工具有效。这本身听起来很废，但你却留下了数据库本身的巨大安全漏洞。因此，如果用户直接连接到数据库（例如使用 Access ADP to SQL Server），他们就可以完全控制其用户角色。如果您在客户端库中进行限制，他们将需要完全访问数据库中的所有内容。
唯一不会出现大问题的情况是 Web 应用程序和 Web 服务。如果您的 Web 服务执行了安全性并将其隐藏在 Web 服务接口后面（因此无法直接访问数据库），那么它将是安全的。这可能就是您在谈论的内容，但在您的问题中没有具体说明。
如果您使用胖客户端，是否有理由不想将安全逻辑放在数据库端？您提到了数据库独立性，但是您指定的任何内容都很难在每个平台上提供。您基本上是在描述检查用户是否有权编辑记录的前/后触发器。完整的 RLS 还会限制用户的查看权限，并使事情变得稍微困难，具体取决于平台。
The problem with implementing your security solution in your client library is that it is only effective with the client tool. That sounds pretty DUH on it's own, but you leave open the huge security hole that is the database itself. So if a user connects directly to a database (for example using an Access ADP to SQL Server) they have full control to whatever their user role is. Which they would need full access to everything in the database, if you are doing your restrictions in the client library.
The only case where this wouldn't be as big an issue would be with web applications and web services. If your web service did the security and hid it behind the web service interface (so there was no direct access to the database), then it would be safe. This may be what you're talking about, but didn't specify in your question.
If you are using a fat client, is there a reason why wouldn't want to put the security logic in the database side? You mentioned database independent, but nothing you specified would be difficult to provide in each platform. You basically are describing pre-/post- triggers that check if a user has rights to edit a record. A full RLS would also restrict the user's rights to view and make things slightly more difficult depending on platform.