具有实体框架的行级安全性

Question

我一直在考虑如何使用实体框架实现行级安全性。我们的想法是拥有一个数据库不可知的方法，它将提供限制来自ObjectContext的行的方法。

我的一些初步想法涉及修改EDMGEN工具创建的部分类，并提供了一些有限的支持。用户仍然可以使用自己的eSQL语句和QueryObject来解决此问题。

我一直在寻找一种全面的解决方案，它将存在于数据库提供商之上，以便它保持不可知。

Answer 1

当然可以做到。重要的是阻止直接访问对象上下文（阻止用户构建自己的ObjectQuery），而是为客户端提供一个更窄的网关，在其中访问和改变实体。我们使用Entity Repository pattern来完成。你可以找到一个example implementation of this pattern for the entity framework in this blog post。同样，关键是阻止访问对象上下文。请注意，对象上下文类是部分的。因此，您应该能够防止“未经授权”实例化它，即在您的存储库程序集之外。

但是，需要考虑一些细微之处。如果通过存储库模式对某个实体类型实现行级视图安全性，则必须考虑客户端可以访问相同实体的其他方法。例如，通过导航关系。您可能需要将其中一些关系设为私有，您可以在模型中执行此操作。您还可以选择specifying a custom query或存储过程来加载/保存实体。存储过程往往是特定于DB服务器的，但SQL可以通用方式编写。

虽然我不同意使用实体框架无法做到这一点，但我同意“在数据库服务器上执行”评论，因为您应该实施defense in depth。

Answer 2

您添加安全性的地方实际上取决于您尝试防范的人。

例如，如果您要保护网站，那么在上下文级别添加过滤就足够了，因为在这种情况下，“用户”位于网站上。他们别无选择，只能通过你的上下文，因为你会完全针对上下文编写应用程序。

在您的情况下，听起来像您试图防范的“用户”是开发人员。这有点困难。如果开发人员无权修改数据库本身，那么您必须将安全性置于数据库级别。没有多少eSQL访问能够绕过数据库说“不”。

Answer 3

根据定义，您要实现的目标是不可能的。

如果底层数据库应用程序（SQL Server，Oracle，无论如何）没有显式处理安全性，那么像SQL Management Studio这样的标准工具就会超越它。

您可以做的最好的事情是，只有当这些用户无法通过其他机制访问数据库时，才能强制执行应用程序用户的行级安全性。

Answer 4

您可能会发现本文很有用：

http://msdn.microsoft.com/en-us/magazine/ff898427.aspx

“拒绝表格访问实体框架而不会引起叛变”

Answer 5

我找到了一种使用Postgres和名为Veil的扩展程序的方法。它实际上（用于）使用Views进行所有操作（选择，更新，删除，插入）和验证WHERE子句中的权限。但Veil只是增加了数学，以便有效地管理内存中的权限信息，而不是每次都查询它。因此，使用Veil，虽然您直接连接到DBMS，但您只能获得为您授予的行级访问权限。

我在某种程度上用面纱修改了我的风格，例如，我开始使用Triggers代替Views来应用权限限制。

我建议你研究这个解决方案并试着在这里应用它的逻辑。

即：你进行了select * from table查询，你得到的是你想要的（行级别）。