使用实体框架的行级安全

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可以用通用方式编写。

尽管我不同意这不能用Entity Framework来完成，但我同意“在数据库服务器上执行它”的意见，因为您应该实施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。它实际上适用于所有操作（选择，更新，删除，插入）并验证WHERE子句中的权限使用Views。但面纱只是增加了数学，有效地管理内存中的权限信息，而不是每次都查询它。因此，对于Veil，虽然您直接连接到DBMS，但您只有授予您的行级访问权限。

我在某些方面用面纱修改了我的风格，例如，我开始使用Triggers而不是Views来应用权限限制。

我建议你学习这个解决方案，并尝试在这里应用它的逻辑。

即：你做了一个select * from table查询，你得到你想要的（行级说话）。