我们如何在动态环境中使用基于角色的安全性？
在大型系统中使用基于角色的方法时我们总是遇到问题。在此类软件中，我们希望超级用户能够设置其组织用户权限。我们可以创建许多原子角色并创建一个控制台来将角色分配给用户。那么我们要创建很多角色，例如：
添加产品、删除产品、编辑产品、接受购买、拒绝购买、...
这样，对于一个中型系统，我们至少应该有 50 个角色！那么管理员如何为每个用户分配这些角色呢？
乍一看，我们有两个解决方案：
在数据库中创建一个表（例如组）以放置在用户和角色之间。然后管理员应该创建一组角色，然后将一个组分配给多个用户。
将角色用作一组权限。例如，创建一个 PermissionInRoles 表并为每个角色分配权限，然后将角色分配给用户。
我们很快发现第一种方法毫无意义。我们用第二种方法实施了几个项目。但现在除了 WCF RIA 身份验证服务之外，我们还想在 sivlerlight 项目中使用它。它只是支持角色。例如，每个用户实例都有一个 IsInRole 方法，我们改为实现 IsInPermission 方法。
使用服务的 RequiresRole 属性时还有另一个问题。我不能也不想为每个服务方法添加硬编码角色名称。
要知道我们对基于角色的安全设计非常困惑！在这些情况下我们该如何使用它呢？
We always have problems to using role-based in large systems. In such softwares we want superusers to able to set their organization users permissions. We can create many atomic roles and create a console for assigning the roles to the users. Then we have to create many roles, for example:
AddProduct, RemoveProduct, EditProduct, AcceptPurchase, DenayPurchase, ...
In this way, for a medium system we should have at least 50 roles! Then how the admin can assign these roles for each user?
We have two solution at first glance:
To create a table in DB (for example Group) to put between the users and roles. Then admin should create a group of roles then assign a group to multiple user.
Use roles as a group of permissions. For example create a PermissionInRoles table and assign the permissions for each roles then assign the roles to the users.
We soon find the first approach nonsense. And we implement several project with second approach. But now we want to use it in a sivlerlight project besides the WCF RIA Authentication services. It just supports the roles. For example each user instance has an IsInRole method which we implement our IsInPermission method instead.
There is another problem when using RequiresRole attribute for services. I can't and I don't want to put a hardcode role name for each service method.
Know we are so confused about the role-based security design! How can we use it in these situations?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您基于“角色”的授权的概念似乎有点缺陷。话又说回来，这种情况并不少见，因为有各种各样的定义并不完全一致，至少在细节上是这样。它们唯一的共同点是，授权尝试通过或失败的主要决定因素是用户的属性，而不是计划执行操作的目标的属性。除此之外，如果授权系统声称是“基于角色”，您可能不应该过多地假设它实际上做了什么。
例如，在您现在使用的 ASP.NET 基于角色的授权范例中，实际的“角色”对应于一组固定的（即：在编译时已知的）操作。例如，人们可能期望看到固定的“产品经理”角色，而不是您在原始帖子中列出的细粒度“添加产品”、“删除产品”和“编辑产品”权限。如果您想在更细粒度的级别进行授权，那么这种“纯粹”的基于角色的方法并不真正合适，并且 IPrincipal.IsInRole 可能根本不应该使用。
听起来您想授权细粒度的“操作”，通过运行时配置将操作分组为“角色”。某些“管理”用户组将有权管理此配置。他们可以根据需要创建、修改和删除“角色”，每个“角色”都是应用程序可识别的一组“操作”（即：“角色”对应“操作”，就像“组”对应“用户”）。您的应用程序不需要了解角色。相反，它将授权行动。用户可以通过以下任意一种方式授予用户操作权限：
当仅使用方法 #4 时，授权管理会大大简化，但用于授予权限的实际方法应该对在执行操作之前验证权限的代码绝对没有影响。
这种情况并不罕见，尽管 .NET Framework 中尚未内置对它的支持。有一些工具至少可以帮助解决部分问题（例如：AzMan< /a>），但我不知道 .NET 方面有任何商业框架可以提供所有必需的部分，而至少不需要一些自定义编码。 （该领域有一些小型开源项目，但您需要在您的应用程序上下文中评估它们的优缺点。）
Your concept of "role"-based authorization seems a bit flawed. Then again, that's not uncommon, given that there are various definitions out there that aren't exactly in violent agreement, at least in their finer details. The only thing they all tend to have in common is that the main determinant whether an authorization attempt passes or fails are properties of the user, not properties of the target against which one is planning to execute an action. Beyond this, you probably shouldn't assume too much about what an authorization system actually does if it claims to be "role-based".
For example, in the ASP.NET role-based authorization paradigm that you're using now, the actual "roles" correspond to a fixed (i.e.: known at compile-time) set of operations. For example, instead of the granular "AddProduct", "RemoveProduct", and "EditProduct" permissions that you listed in your original post, one might expect to see a fixed "Product Manager" role. If you want to authorize at a more granular level, then this "pure" role-based approach isn't really suitable, and IPrincipal.IsInRole probably isn't something you should be using at all.
It sounds like you want to authorize granular "operations", with operations being grouped into "roles" via runtime configuration. Some set of "administrative" users would have permissions to manage this configuration. They could create, modify, and delete "roles" as desired, with each "role" being a set of "operations" that are recognized by your application (i.e.: "role" is to "operation" as "group" is to "user"). Your application wouldn't need to have any awareness of the roles. Instead, it would authorize operations. Users would be granted permissions to operations via any of the following:
Administration of the authorizations is greatly simplified when only approach #4 is used, but the actual approach(es) used for granting the permissions should have absolutely no effect on the code that verifies permissions before executing actions.
This sort of thing is not at all uncommon, although support for it has not been built into the .NET Framework. There are tools out there that can help with at least part of it (e.g.: AzMan), but I am unaware of any commercial framework on the .NET side of things that provides all the required pieces without requiring at least some custom coding. (There are some small open-source projects in this area, but you would need to evaluate their pros and cons within the context of your application(s).)