关于自定义安全保护设置MVC3问题使用重写AuthorizeAttribute，线程安全，ChildActions和缓存 [英] Questions about a Custom Security setup for MVC3 using overriden AuthorizeAttribute, thread safety, ChildActions and caching

问题描述

所以，寻找我的MVC3应用强大的安全解决方案后，我碰到<少时href=\"http://blogs.msdn.com/b/rickandy/archive/2011/05/02/securing-your-asp-net-mvc-3-application.aspx\">this博客文章由里克·安德森的。它详细说明了AuthorizeAttribute的自定义实现应用为全局筛选白名单的做法，你装饰动作/控制器，你希望允许使用虚拟属性AllowAnonymousAttribute（我说的虚拟匿名访问，因为有AllowAnonymousAttribute的内部没有逻辑，这是只是一个空洞的属性类）

So after searching for a robust security solution for my MVC3 app, I came across this blog post by Rick Anderson. It details a WhiteList approach where a custom implementation of AuthorizeAttribute is applied as a Global Filter, and you decorate actions/controllers you wish to allow Anonymous access to using a dummy attribute AllowAnonymousAttribute (I say dummy because there is no logic inside of AllowAnonymousAttribute, it's just an empty attribute class)

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

这（与在他的博客，如HTTPS安全提到的其他建议一起）给了我一个默认安全模型，即我没有安全检查适用于每一个动作，记得也把它添加到将来的功能补充。

This (along with other recommendations for security mentioned on his blog like HTTPS) gives me a secure by default model whereby I don't have to apply a security check to every single action, and remember to also add it to future feature additions.

问题的第一部分

现在，我没有使用上AuthorizeAttribute用户/角色的属性，我需要抓住的东西从数据库中。要我说的东西，将是AuthorizeCore，因为它是唯一responsability是返回一个真正的假，没有用户具有访问权限。不过，我有一个问题，AuthorizeCore有线程安全的基础了我的信号源AuthorizeAttribute类的读数可以了，我不知道最好的方式去访问我的数据库，以确定用户权限和坚持这一点。我的应用程序正在使用的IoC，目前让我的IoC容器注入我的仓库处理所有的AuthorizeAttribute的构造函数，但这样做的，然后在AuthorizeCore访问它，我不能导致与线程安全问题？或将一个IoC实现和MVC3 DependencyResolver我使用提供的参数来我的自定义AuthorizeAttribute构造充分地处理线程安全？请注意，我的仓库使用，其中包括我的NHibernate的SessionFactory的一个构造器到存储库，并从我的IoC容器，使用下面的一行StructureMap实施提供工作类的单元A的UnitOfWork模式，我是正确的思维这里使用范围将处理线程的问题？

Now, I'm not using the Users/Roles properties on the AuthorizeAttribute, I need to grab that stuff from a database. To me that's something that would be in AuthorizeCore, since it's sole responsability is to return a true false, does the user have access. However I have a problem, AuthorizeCore has to be thread safe based off my reading of the source for the AuthorizeAttribute class, and I am not sure the best way to go about accessing my database to determine user permissions and adhere to that. My app is using IoC and currently letting my IoC container inject my repository handling all that to the constructor of the AuthorizeAttribute, but by doing this and then accessing it within AuthorizeCore, am I not causing problems with thread safety? Or will an IoC implementation and the MVC3 DependencyResolver I'm using to provide the parameter to my custom AuthorizeAttribute constructor handle the thread safety adequately? Note, my repositories are using a UnitOfWork pattern that includes my nHibernate SessionFactory as a contructor to the repository and the Unit of Work class is provided from my IoC container, implemented by StructureMap using the line below, am I correct in thinking the scope used here would handle threading concerns?

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

问题的第二部分

我的数据模型（因而安全模式）的设置，使都被定义我的主要业务对象是这样一种方式，它是一个大的层次模型，并且，当我检查的权限我期待在该层次结构模型，其中用户的帐户被定义并授予访问默认一切在它之下。
二级权限检查是使用管理定义的业务逻辑的权限如CAN用户角色X访问删除的Widget功能之一。对于这个我使用的路由数据，拉出控制器和动作的名称，并在结合使用它们与当前用户的主要方式详情打我的数据库来解决此请求的权限。然而正在重复这种逻辑在页面上使用，以及每个ChildAction，而是因为我使用的控制器和动作的名字从路由数据，我没有实际得到儿童行动的信息。它保持父动作名称，而不是孩子的行动，因为没有被通过URL请求执行的子操作。这是导致我的数据库父动作和不必要的资源命中的细节冗余安全检查。在研究这个，我决定干脆绕过安全检查的儿童的行动，并依靠这种情况的家长行动。

My data model (and thus security model) is setup so that my primary business objects are all defined is such a way that it's one large hierarchy model, and that when I check for permissions I look in that hierarchy model for where the user's account was defined and grant access to everything underneath it by default. The secondary permissions check is the one that uses Administrative defined business logic permissions like can users in role X access the Delete Widget functionality. For this I'm using the Route data and pulling out the Controller and Action names, and use them in conjunction with details from the current users Principal details to hit my database to resolve the permissions for this request. However this logic is being repeated for each ChildAction used on the page as well, but because I'm using the Controller and Action names from the Route data, I'm not actually getting the Child Action information. It stays as the parent action name, not the child action since the child action is not being executed via a URL request. This is causes redundant security checks on my database for the details of the Parent Action and needless resource hits. In researching this I decided to simply bypass the security check for Child actions and rely on the parent action for this.

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

是否有意义要做到这一点，如果是/不是，为什么？在我看来，如果操作饰有ChildActionOnlyAttribute，这是人迹罕至的公开通过URL反正。如果它是被作为一个孩子的行动执行，但不完全是一个孩子的行动，我可以绕过安全检查只是因为家长行动将处理这个权限执行。难道你会遇到这样的情况，你需要限制访问孩子的行动？知道了孩子的行为通常是我没有预料到这是一个问题，但我也看到了参考OnAuthorization的默认实现概述了缓存的一些关切一行非常小的部分景色。没有人知道是否会影响到我提出的解决方案？

Does it make sense to do this, and if so/not, why? In my mind, if the Action is decorated with ChildActionOnlyAttribute, it's inaccessible publicly via a URL anyway. And if it's being executed as a Child Action but is not exclusively a child action, I can bypass the security check just for this execution since the parent action will handle the permissions. Would you ever have a situation where you would need restrict access to a child action? Knowing that child actions are typically very small partial views I don't anticipate this being a problem but I also saw reference to a line in the default implementation of OnAuthorization outlining some concerns over caching. Does anyone know if that affects my proposed solution?

摘要担忧：

• 对于多线程的担忧
  访问用户权限
  内AuthorizeCore数据库


• 安全担忧旁路
  儿童行动的授权检查


• 缓存关注儿童行动
  以previous点结合

任何意见或与这些方面的帮助将不胜AP preciated！

Any opinions or help with these aspects would be greatly appreciated!

推荐答案

部屋Yarx - 第1部分 - 高速缓存在登录用户的所有权限。
多线程然后访问不是一个问题，因为你的AuthorizeCore简单地从它在当时可以考虑只读取缓存获取的角色。

Heya Yarx - Part 1- cache all permissions for the user upon login. Multi threaded access then is not an issue as your AuthorizeCore simply gets the roles from the cache which at that time can be considered read only.

2部分：
再次将上述第1点：） - 如果你的安全检查都这么重，为什么不加载所有权限登录时用户并缓存。一旦打你的孩子的行为，你可以要求的权限和当时检查它们的缓存。

Part 2: Again going to point 1 above : ) - if your security checks are so heavy, why not load all permissions for a user upon login and cache them. Upon hitting your child actions you can demand the permissions and at that time check the cache for them.

有绝对是一个更好的方式来处理这个问题不是那么重。如果你击中​​仅用于许可单个请求分贝多次，你需要或者高速缓存您的许可通过某种机制设置（自定义或实施其他债权为基础的系统等）

There is definitely a better way to handle this that isn't as heavy. If you are hitting the db multiple times in a single request solely for permissions, you need to either cache your permission set via some mechanism (custom or implementing another claims based system, etc)

我不是100％以下的机制，虽然根据路线上的授权。你提到，你是从路由信息拉 - 你能举个例子吗？

I'm not 100% following your mechanism though for authorization based on the route. You mentioned that you are pulling info from the route - can you give an example here?

这绝对是有道理的，以保护你的孩子的行为。如果有什么两种观点称Html.Action - 一家专为管理员和其他被错误地复制并粘贴到另一个看法？你的孩子的行为应始终受到保护，不要以为他们是好的，因为他们只从另一个视图调用。

It absolutely makes sense to protect your child actions. What if two views call Html.Action - one specifically as an admin and the other is erroneously copy and pasted into another view? Your child actions should always be protected, don't assume they are ok since they are only called from another view.

此外，如果您不能缓存整个树的用户，你当然可以缓存安全检查中第一次调用AuthorizeCore。后续调用只会检查前。缓存角色 - 如果有则使用它们，否则看到数据库。

Also if you cannot cache the entire tree for a user, you can certainly cache the security checks in the first call to AuthorizeCore. Subsequent calls would simply check for ex. cached roles - if there then it uses them, otherwise look to the database.

这篇关于关于自定义安全保护设置MVC3问题使用重写AuthorizeAttribute，线程安全，ChildActions和缓存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！