我在SQL Server上使用EF Code First继承了一个相当大且复杂的ASP.NET MVC3 Web应用程序。它使用ASP.NET Membership角色和数据库身份验证。控制器操作使用从AuthorizeAttribute派生的属性进行保护，这些属性将角色映射到操作。有更精细点的扩展方法，例如向特定角色显示特定小部件。这很有效，我对当前的安全模型有很好的理解。
我被要求在数据级别提供更细粒度的安全性。例如，“客户”用户只能看到与自己相关的数据（整个数据库）而不是其他客户。问题是“客户”只有5种不同类型中的1种具有自己的特定限制（9种角色中的每一种都是这5种类型中的一种）。
我能想到的最好的事情是遍历所有数据存储库并使用每个用户类型的过滤器扩展每个LINQ语句/查询。即使我有时间，它似乎也不是最优雅的方式。
有什么建议吗？我真的不知道从哪里开始，所以任何事情都可能有所帮助。
非常感谢。
答案 0 :(得分：0)
必须在查询中执行数据驱动的安全性。在项目的后期添加它非常耗时。不是由于编程而是由于测试。如果管理层有此要求，他们必须接受。
您可以从重构一些基本查询开始。每个查询都必须访问一些DbSet，因此不要访问DbSet访问应用该集上的安全性的一些帮助方法。您可以使用在派生上下文中公开的DbSet来玩，或者您甚至可以尝试派生自己的DbSet并重新实现IQueryalbe.Expression（显式实现）以直接添加过滤逻辑集合。
真正的并发症始于懒惰和急切的负荷。 EF没有提供过滤懒惰或急切加载数据的方法。通过精心设计的聚合，您不需要跨客户延迟加载和急切加载。如果您需要它，您将不得不重构该部分代码以使其正常工作（它不仅仅是为查询添加一些条件）。