0

我们总是在大型系统中使用基于角色的问题。在此类软件中，我们希望超级用户能够设置其组织用户权限。我们可以创建许多原子角色并创建一个控制台来将角色分配给用户。然后我们要创建很多角色，例如：

AddProduct, RemoveProduct, EditProduct, AcceptPurchase, DenayPurchase, ...

这样，对于一个中型系统，我们至少应该有 50 个角色！那么管理员如何为每个用户分配这些角色呢？

乍一看，我们有两个解决方案：

  1. 在数据库（例如Group）中创建一个表以放在用户和角色之间。然后管理员应该创建一组角色，然后将一个组分配给多个用户。

  2. 将角色用作一组权限。例如，创建一个 PermissionInRoles 表并为每个角色分配权限，然后将角色分配给用户。

我们很快发现第一种方法是胡说八道。我们用第二种方法实施了几个项目。但现在我们想在除 WCF RIA 身份验证服务之外的 sivlerlight 项目中使用它。它只支持角色。例如，每个用户实例都有一个IsInRole方法，我们实现了我们的IsInPermission方法。

对服务使用RequiresRole属性时还有另一个问题。我不能也不想为每个服务方法设置硬编码角色名称。

知道我们对基于角色的安全设计非常困惑！我们如何在这些情况下使用它？

4

1 回答 1

2

您基于“角色”的授权的概念似乎有点缺陷。再说一次，这并不少见，因为有各种各样的定义并不完全一致，至少在它们的细节上是这样。它们的唯一共同点是授权尝试通过还是失败的主要决定因素是用户的属性，而不是计划对其执行操作的目标的属性。除此之外，如果授权系统声称是“基于角色的”，您可能不应该过多地假设授权系统实际上做了什么。

例如，在您现在使用的 ASP.NET 基于角色的授权范例中，实际的“角色”对应于一组固定的（即：在编译时已知的）操作。例如，您可能希望看到固定的“产品经理”角色，而不是您在原始帖子中列出的精细的“AddProduct”、“RemoveProduct”和“EditProduct”权限。如果您想在更细粒度的级别进行授权，那么这种“纯”基于角色的方法并不适合，而且 IPrincipal.IsInRole 可能根本不应该使用。

听起来您想授权精细的“操作”，通过运行时配置将操作分组为“角色”。一些“管理”用户将有权管理此配置。他们可以根据需要创建、修改和删除“角色”，每个“角色”都是您的应用程序识别的一组“操作”（即：“角色”是“操作”，“组”是“用户”）。您的应用程序不需要了解角色。相反，它将授权操作。用户将通过以下任何方式获得操作权限：

  1. 授予用户操作权限，
  2. 授予用户所属组的操作权限，
  3. 向用户授予角色权限，或
  4. 授予用户所属组的角色权限。

当仅使用方法 #4 时，授权管理大大简化，但用于授予权限的实际方法对执行操作之前验证权限的代码绝对没有影响。

这种事情并不少见，尽管对它的支持还没有内置到 .NET Framework 中。有一些工具至少可以帮助解决其中的一部分问题（例如：AzMan），但我不知道 .NET 方面的任何商业框架可以提供所有必需的部分，而无需至少一些自定义编码。（该领域有一些小型开源项目，但您需要在应用程序的上下文中评估它们的优缺点。）

于 2011-08-23T18:52:21.480 回答