1

MSDN 非常清楚MVC 路由和安全性：

保护 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);
        ...
    }
}

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

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

4

1 回答 1

1

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

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

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

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

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

这也允许您实现在授权检查失败时调用的自定义逻辑（HandleUnauthorizedrequest()方法），这可能是授权逻辑失败时您在自定义控制器工厂中必须做的事情（例如重定向到登录或错误页面？ )

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

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

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

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

于 2013-10-08T16:05:30.853 回答