Question

保护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()方法），这可能是在授权逻辑失败时您必须在自定义控制器工厂中执行的操作（例如，重定向到登录或错误页面？）

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

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

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

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

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

1 个答案: