在ASP.NET MVC应用程序中实现细粒度的安全（即授权）最好的机制是什么？ [英] What is the best mechanism to implement granular security (i.e. authorization) in an ASP.NET MVC application?
问题描述
假设一个高速的开发与建设将由许多不同的人访问的银行应用程序的任务。每个人会想访问他或她自己的账户信息，但不希望别人来访问它。我想知道在MVC应用程序限制访问，这样只有谁拥有的信息（或管理员）的用户可以访问它的最佳做法。
Suppose a high-speed developer was tasked with building a banking application which would be accessed by many different people. Each person would want to access his or her own account information but would not want others to access it. I would like to know the best practice for restricting access in an MVC application so that only the user who owns the information (or an administrator) could access it.
的授权属性允许我们通过角色来限制。虽然这是一个起点，似乎任何身份验证的用户可以访问任何其他用户的信息。
The Authorize attribute allows us to restrict by role. While this is a starting point, it seems that any authenticated user could gain access to any other user's information.
ActionFilters似乎提供了一小更精细的控制选项，很可能被用来完成任务。不过，我不清楚他们是否会推荐的方法。
ActionFilters seem to offer the option for a little more granular control and could probably be used to accomplish the task. However, I am unclear as to whether they would be the recommended approach.
任何指导或想法，欢迎。
Any guidance or ideas are welcome.
推荐答案
ActionFilter可能是一个很好的起点，但根据你的架构，你可能要考虑的外线防守是否足够好。
ActionFilter is probably a good starting point, but depending on your architecture, you may want to consider whether perimeter defense is good enough.
如果你基本上是建立一个单层ASP.NET MVC应用程序（也有可能是完全合理的理由来做到这一点），一个ActionFilter将提供防御是不够好，而在同一时间是非常简单的应用。
If you are essentially building a single-layer ASP.NET MVC application (and there may be perfectly reasonable reasons to do this), an ActionFilter will provide defense that is good enough while at the same time being very simply to apply.
在另一方面，如果你的应用程序是一个多层应用，纵深防御是比较合适的。在这种情况下，你应该甚至在数据访问层考虑在域模型应用授权逻辑，或者。这将确保如果你曾经开发基于相同的域模型（例如Web服务）的另一个应用程序，授权逻辑将仍然适用。
On the other hand, if your application is a multi-layer application, Defense in Depth is more appropriate. In that case, you should consider applying the authorization logic in the Domain Model, or perhaps even in the Data Access layer. This will ensure that if you ever develop another application based on the same Domain Model (e.g. a web service), the authorization logic would still apply.
不管你做什么，我强烈建议您基于IPrincipal的实际授权实现。
No matter what you do, I strongly recommend that you base the actual authorization implementation on IPrincipal.
在一个更具体的笔记，你问这里最好使用基于ACL的授权模型：对每个用户配置文件设置ACL，默认情况下授予只能访问用户他/她自己和管理员。如果/当你以后需要扩展应用程序，以允许其他用户的个人资料进行委托授权访问（我不知道这是否是在特定情况下，甚至远程现实做），你可以简单地做，通过添加新条目的ACL。
On a more specific note, what you are asking about here is best modeled with ACL-based authorization: Set an ACL on each user profile that by default grants access to only the user him/herself and the administrator. If/when you later need to expand the application to allow delegated access to other users' profiles (I don't know whether that's even remotely realistic in your specific case), you can simply do that by adding a new entry to the ACL.
在这种情况下，评估访问包括检索所请求的资源的ACL和检查当前用户（的IPrincipal）是否包含在该访问控制列表。这样的操作很可能涉及到外的过程中的操作（查找在数据库中ACL），通过后面的ActionFilter听起来像它可能隐藏某些性能问题隐藏它，有它作为应用程序的一个隐含部分。在这种情况下，我会考虑授权模型更加露骨一点/可见。
In such a case, evaluating access involves retrieving the ACL for the requested resource and checking whether the current user (IPrincipal) is included in that ACL. Such an operation is very likely to involve out-of-process operations (looking up the ACL in a database), so having it as an implicit part of an application by hiding it behind an ActionFilter sounds like it could potentially hide some performance issues. In such a case, I would consider making the authorization model a bit more explict/visible.
这篇关于在ASP.NET MVC应用程序中实现细粒度的安全（即授权）最好的机制是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
