我一直在尝试考虑如何使用实体框架实现行级安全性。这个想法是有一个与数据库无关的方法，它可以提供方法来限制来自 ObjectContext 的行。
我最初的一些想法涉及修改由 EDMGEN 工具创建的部分类，这提供了一些有限的支持。用户仍然可以通过使用他们自己的 eSQL 语句和 QueryObject 来绕过这个解决方案。
我一直在寻找一种全面的解决方案，该解决方案将存在于数据库提供程序之上，以便它保持不可知论。
【问题讨论】：
标签： c# database security entity-framework row-level-security
当然可以。要做的重要事情是阻止对对象上下文的直接访问（阻止用户构建自己的 ObjectQuery），而是为客户端提供一个更窄的网关，以便在其中访问和改变实体。我们使用Entity Repository pattern 来实现。您可以找到example implementation of this pattern for the entity framework in this blog post。同样，关键是阻止对对象上下文的访问。请注意，对象上下文类是部分的。因此，您应该能够防止“未经授权”的实例化方式，即在您的存储库程序集之外。
但是，需要考虑一些微妙之处。如果您通过存储库模式在某个实体类型上实现行级视图安全性，那么您必须考虑客户端可以访问相同实体的其他方式。例如，通过导航关系。您可能需要将其中一些关系设为私有，您可以在模型中执行此操作。您还可以选择specifying a custom query 或存储过程来加载/保存实体。存储过程往往是特定于数据库服务器的，但 SQL 可以以通用方式编写。
虽然我不同意实体框架无法做到这一点，但我同意“在数据库服务器上执行”cmets，因为您应该实现 defense in depth。
【讨论】：
您添加安全性的位置实际上取决于您要保护的对象。
例如，如果您要保护网站，那么在上下文级别添加过滤就足够了，因为在这种情况下，“用户”在网站上。他们别无选择，只能通过您的上下文，因为您将完全根据上下文编写应用程序。
在您的情况下，听起来您要保护的“用户”是开发人员。这要困难得多。如果开发人员无权对数据库本身进行修改，那么您必须将安全性置于数据库级别。再多的 eSQL 访问都无法绕过数据库说“不”。
【讨论】：
根据定义，您想要实现的目标是不可能的。
如果底层数据库应用程序（SQL Server、Oracle 等）没有显式处理安全性，那么 SQL Management Studio 等标准工具就会被淘汰。
您能做的最好的事情是仅当应用程序的用户无法通过其他机制访问数据库时才强制执行行级安全性。
【讨论】：
【讨论】：
我找到了一种使用 Postgres 和名为 Veil 的扩展的方法。它实际上（设计用于）使用Views 进行所有操作（选择、更新、删除、插入）并验证WHERE 子句中的权限。但是，Veil 只是添加了有效管理内存中权限信息的数学运算，而不是每次都查询它。因此，使用 Veil，尽管您直接连接到 DBMS，但您只获得了行级访问权限。
我在某些方面用面纱修改了我的风格，例如我开始使用Triggers而不是Views来应用权限限制。
我建议你研究这个解决方案并尝试在这里应用它的逻辑。
即：您进行select * from table 查询并得到您想要的结果（行级发言）。
【讨论】：