为什么保护 MVC 路由是不好的做法？

Question

MSDN 对MVC Routing and Security 非常清楚：

唯一受支持的保护 MVC 应用程序的方法是将 AuthorizeAttribute 属性应用于每个控制器，并在登录和注册操作上使用 AllowAnonymousAttribute 属性。

但是，我正在考虑以下方法：

首先，我实现了一个自定义控制器工厂，它根据来自我们自定义 STS 的信息执行安全检查。

在其他信息中，STS 颁发的令牌包含描述用户被允许访问的所有 MVC 路由的声明。

然后我在 CreateController 方法中检查用户声明：

public class SecuredControllerFactory : IControllerFactory
{
   public IController CreateController(System.Web.Routing.RequestContext requestContext, string controllerName)
    {
        ...
        bool isAuthorized = principal.HasRequiredRight(verb, ressource);
        ...
    }
}

通过这种方式，我们可以集中配置和更新安全规则，而无需重新部署我们的应用程序。而且，它符合“约定优于配置”的思想。

这种方法有问题吗？我不明白为什么它被认为是一种不好的做法？有人可以对此提出具体的安全问题吗？

Answer 1

我想这是不好的做法，因为它违反了控制器工厂内的单一责任原则。控制器工厂的唯一职责应该是选择和实例化控制器。

我会质疑您使用控制器工厂方法的原因：

这样我们可以集中配置和更新安全规则 方式，无需重新部署我们的应用程序。

如果您使用在代码中指定允许的用户/角色的标准AuthorizeAttribute，这是一个有效的声明。

但是，推荐的方法是从AuthorizeAttribute 派生并通过覆盖受保护的AuthorizeCore() 方法在派生类中实现您的安全规则逻辑。例如，它可以在数据库中查找权限，以便您可以在运行时动态更改它们。

这还允许您实现在授权检查失败时调用的自定义逻辑（HandleUnauthorizedrequest() 方法），这大概是授权逻辑失败时您必须在自定义控制器工厂中执行的操作（例如重定向到标志-on 还是错误页面？）

这样，您可以更改安全规则并集中管理它们，而无需重新部署整个应用程序并且您不会破坏ControllerFactory 的单一职责

ThinkTexture 在其身份模型框架中提供了一个很好的实现，如此处所述

http://leastprivilege.com/2012/10/26/using-claims-based-authorization-in-mvc-and-web-api/

这允许您指定资源/操作并以通常的 WIF 方​​式将授权逻辑封装在自定义 ClaimsAuthorizationManager 中。如果您没有在属性中显式指定资源和操作，框架会使用当前的HttpActionContext 获取值，这很好。