asp.net mvc3用户角色和访问权限

Question

在我的ASP.NET MVC3应用程序中，我有用户，角色和实体。用户角色将有权访问实体。那么在数据库中存储用户和角色时，以下哪种方法是好的方法？

1. 将用户列表存储在实体表

中

2. 用户表中的实体ID。

将来实体数量可能增加到1000,10000，所以我也想考虑性能方面。

Answer 1

我认为角色与实体之间的关系是多对多的。一个角色可以包含零个或多个实体，一个实体可以属于零个或多个角色。因此，请创建第三个表来存储包含2列RoleId和EntityID

的列

示例数据看起来像

ROLE_ID        ENTITY_ID
-----------------------------------
1              144
1              146
2              194
4              14
4              194

Answer 2

根据您的应用程序所需的控件粒度，您可能需要考虑Windows Identity Foundation（WIF）中使用的模型，该模型现在是.NET Framework 4.5的一部分。这是一个claims-based architecture，用于您所谓的实体的术语是资源。与您的模型不同的是，它们还具有操作的概念。 资源可以包含多个操作，典型的操作类似于读取，写入和执行。这就是更精细的控制粒度所在。

因此，在这种情况下，特定资源的操作可以有多个角色，角色可以有许多操作，需要另一个表来映射这种多对多关系。将int用作角色和操作中的主键作为对象ID可以提高性能。 用户可以有多个角色，角色会有多个用户，因此您需要再次管理另一个表这种多对多的关系。

因此问题1的答案是您不将用户列表存储在实体表中。您有一个单独的用户表格，该表格映射到用户到角色的表格，该表格映射到角色，映射到角色-To-Operations ，映射到操作表格，该表格映射到资源表格。如果您不需要操作的粒度，请删除该表并将角色映射到资源，通过另一个表来处理此多对多关系。

问题2的答案是否定的，您在用户表中没有实体（资源）ID。 用户通过上述关系映射到资源。

使用此模型的最佳方法以及基于声明的体系结构的完整范围是不使用AuthorizeAttribute将角色分配给您的方法，这通常是如何完成的在过去。而是将资源和操作分配给您的安全策略与应用程序分离的方法。有关此方法的模型，请查看ClaimsPrincipalPermissionAttribute。您可以创建自己的使用此方法的自定义AuthorizeAttribute。