asp.net-mvc - 关于使用重写的 AuthorizeAttribute、线程安全、ChildActions 和缓存的 MVC3 自定义安全设置的问题

Question

因此，在为我的 MVC3 应用程序寻找强大的安全解决方案后，我遇到了 this blog post通过里克·安德森。它详细介绍了一种 WhiteList 方法，其中将 AuthorizeAttribute 的自定义实现应用为全局过滤器，并且您可以使用虚拟属性 AllowAnonymousAttribute 装饰您希望允许匿名访问的操作/ Controller (我说是虚拟的，因为 AllowAnonymousAttribute 内部没有逻辑，它是只是一个空的属性类)

bool allowAnnonymous = filterContext.ActionDescriptor.IsDefined(typeof(AllowAnonymousAttribute), true)
|| filterContext.ActionDescriptor.ControllerDescriptor.IsDefined(typeof(AllowAnonymousAttribute), true);
if (allowAnnonymous) return;

这(以及在他的博客中提到的其他安全建议，如 HTTPS)为我提供了一个默认的安全模型，我不必对每个操作都应用安全检查，并记住将其添加到 future 的功能添加中。

问题的第一部分

现在，我没有使用 AuthorizeAttribute 上的用户/角色属性，我需要从数据库中获取这些内容。对我来说，这是 AuthorizeCore 中的东西，因为它的唯一责任是返回一个真假，用户是否有权访问。但是我有一个问题，根据我对 AuthorizeAttribute 类的源代码的阅读，AuthorizeCore 必须是线程安全的，而且我不确定访问我的数据库以确定用户权限并坚持这一点的最佳方法。我的应用程序正在使用 IoC 并且当前让我的 IoC 容器将我的存储库处理所有这些注入(inject)到 AuthorizeAttribute 的构造函数中，但是通过这样做然后在 AuthorizeCore 中访问它，我是否不会导致线程安全问题？或者我用来向我的自定义 AuthorizeAttribute 构造函数提供参数的 IoC 实现和 MVC3 DependencyResolver 是否会充分处理线程安全？请注意，我的存储库正在使用 UnitOfWork 模式，其中包括我的 nHibernate SessionFactory 作为存储库的构造函数，并且工作单元类是从我的 IoC 容器提供的，由 StructureMap 使用下面的行实现，我认为此处使用的范围是否正确会处理线程问题吗？

For<IUnitOfWork>().HybridHttpOrThreadLocalScoped().Use<UnitOfWork>();

问题的第二部分

我的数据模型(以及安全模型)已设置，以便我的主要业务对象全部定义为一种大型层次结构模型，并且当我检查权限时，我会在该层次结构模型中查看用户帐户所在的位置默认情况下定义并授予对其下所有内容的访问权限。
二级权限检查是使用管理定义的业务逻辑权限的检查，例如角色 X 中的用户是否可以访问删除小部件功能。为此，我使用 Route 数据并提取 Controller 和 Action 名称，并将它们与当前用户主体详细信息中的详细信息结合使用，以访问我的数据库以解决此请求的权限。但是，对于页面上使用的每个 ChildAction 也会重复此逻辑，但是因为我使用的是 Route 数据中的 Controller 和 Action 名称，所以我实际上并没有获得 Child Action 信息。它保留为父操作名称，而不是子操作，因为子操作不是通过 URL 请求执行的。这会导致对我的数据库进行冗余安全检查，以获取父操作和不必要的资源点击的详细信息。在研究这一点时，我决定简单地绕过子操作的安全检查，并为此依赖父操作。

bool bypassChildAction = filterContext.ActionDescriptor.IsDefined(typeof (ChildActionOnlyAttribute), true) || filterContext.IsChildAction;
if (bypassChildAction) return;

这样做是否有意义，如果有/没有，为什么？在我看来，如果 Action 用 ChildActionOnlyAttribute 修饰，则无论如何都无法通过 URL 公开访问它。如果它作为子操作执行但不完全是子操作，我可以绕过安全检查，因为父操作将处理权限。您是否曾经遇到过需要限制访问子操作的情况？知道子操作通常是非常小的部分 View ，我不认为这是一个问题，但我也看到对 OnAuthorization 的默认实现中的一行的引用，概述了对缓存的一些关注。有谁知道这是否会影响我提出的解决方案？

总结关注点:

多线程问题
访问用户权限来自
AuthorizeCore 中的数据库

绕过的安全问题
子操作的授权检查

缓存子操作的关注点
结合上一点

对这些方面的任何意见或帮助将不胜感激!

Answer 1

Heya Yarx - 第 1 部分 - 在登录时缓存用户的所有权限。
多线程访问不是问题，因为您的 AuthorizeCore 只是从缓存中获取角色，当时可以将其视为只读。

第2部分:
再次转到上面的第 1 点:) - 如果您的安全检查如此繁重，为什么不在登录时加载用户的所有权限并缓存它们。在点击您的子操作时，您可以要求权限并在那时检查它们的缓存。

肯定有更好的方法来处理这个不那么重的问题。如果您在单个请求中多次访问数据库以获得权限，您需要通过某种机制(自定义或实现另一个基于声明的系统等)缓存您的权限集

我不是 100% 遵循您的机制，但基于路线进行授权。你提到你正在从 route 提取信息 - 你能在这里举个例子吗？

保护您 child 的行为绝对有意义。如果两个 View 调用 Html.Action - 一个专门作为管理员而另一个被错误地复制并粘贴到另一个 View 中怎么办？您的子操作应该始终受到保护，不要认为它们没问题，因为它们只是从另一个 View 调用。

此外，如果您无法为用户缓存整个树，您当然可以在第一次调用 AuthorizeCore 时缓存安全检查。随后的调用将简单地检查前。缓存角色 - 如果有，则使用它们，否则查看数据库。