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，用于您所称的Entity 的术语是Resource。与您的模型不同的是，它们还具有Operation 的概念。一个Resource可以有很多Operations，典型的Operation就是读、写、执行。这就是更精细的控制粒度的用武之地。

所以在这种情况下，一个特定资源的操作可以有很多角色，而一个角色可以有许多操作，需要另一个表来映射这种多对多关系。在 Roles 和 Operations 中使用 int 作为主键作为对象 ID 有利于性能。 用户的可以有很多角色并且角色会有很多用户，所以再次需要另一个表来管理这种多对多的关系。

所以问题 1 的答案是您不要将 User 列表存储在 Entity 表中。您有一个单独的 User 表，该表映射到 Users-To-Roles 表，该表映射到 Roles，该表映射到 Roles -To-Operations，映射到 Operations 表，该表映射到 Resources 表。如果您不需要 Operations 的粒度，请消除该表并通过另一个表将您的 Roles 映射到 Resources 以处理这种多对多关系。

问题 2 的答案是否定的，您在 User 表中不会有 Entity（Resource）ID。 User 通过我上面描述的关系映射到 Resource。

使用此模型和基于声明的架构的全部范围的最佳方法是不使用 AuthorizeAttribute 将 角色 分配给您的方法，这是在过去的。而是将 Resource 和 Operation 分配给您的方法，从而将您的安全策略与您的应用程序分离。对于这种方法的模型，请查看ClaimsPrincipalPermissionAttribute。您可以使用这种方法创建自己的自定义 AuthorizeAttribute。