To my rather basic knowledge in that area, the basic actors of an RBAC are:
Resources.
Permissions.
Users.
Roles (i.e. Groups).
Resources <- require -> (one or many) Permissions.
Roles <- are collections of -> (one or many) Permissions.
Users <- can have -> (one or many) Roles.
The tables for such a model would be:
permission
role
user
role_permission
user_role
Now you might want to include resources here as well if you want users of your application to be able to configure which permissions a resource need. But I never needed that. Hope that helps.
rule 14: guest role + page name + read permission
rule 46: approver role + add column + execute permission
等等。 我将把 ERD 作为练习留给读者；-) 如果您有疑问，请发表评论。
尤瓦尔=8-)
I happen to be working on the RBAC sub-system here at work at them moment... what a coincidence.
My model is based on the building blocks of the different entities in the system that require permissions, be they attributes to view/update or actions to perform. There are also, of course, different roles in the system (which can be given to users), and the glue that holds the whole thing together is the access rule, which connects a specific role, a specific permission-needing entity and the permission granted. An access rule might look like these:
rule 14: guest role + page name + read permission
rule 46: approver role + add column + execute permission
and so on. I'll leave the ERD as an exercise to the reader ;-) if you have questions, leave a comment.
I think the answer to your question goes as deep as you wish to go. If you happen to think about putting roles into groups and then associating groups with users wouldn't be enough. Eventually you'll need to give specific permissions to a user on a specific object (a forum, a video etc).
I'm more close to Yuval's answer, all we need is to associate project-wide objects + actions + users. To provide this; a base object (Entity) makes perfect sense. Any object inheriting from Entity can be easily associated with a user + action this way.
As you also wish to keep things simple; my suggestion would be;
Any object due to rbac restrictions should derive from a base Entity.
There should be a list of roles, which are one-to-one related with an Entity.
There should be a list of relations between users and roles.
To take things one step further, I would also reccomend the following (for an automated rbac)
I use service-based access to my objects. That is; I create respositories of objects (which do the db-access for me) and I access repositories via service functions.
I use a custom attribute at the beginning of every service function. This defines the required role to access that function.
I use the User parameter to access to all my service functions, and each service function does a role check before executing itself. Reflection helps me to understand which function I call, and what kind of role it has (via custom attributes)
I also run an initializer on my application startup, and it checks for all the functions (and their attributes) and sees if I added a new required role. If there's a role I just added and doesn't appear to be on the db, it creates it on db.
But alas, that's just available for .NET, as far as I know Java doesn't have custom attributes so that's not yet likely to be available for Java.
I'd like to come up with some code examples but I'm too lazy to do that. Still if you have questions about my way of rbac; you can ask here and I'll surely reply.
For .net applications you should look at something like Visual Guard http://www.visual-guard.com/ to avoid having to handle permissions and roles from scratch.
Role based access control system is a method of restricting access to 'some sources or applications or some features of applications' based on the roles of users of organization.
Here, restrictions can be by means of multiple permissions, those are created by administrator to restrict access, and these permissions collectively represents a role, which will be assigned to user.
And if we go slight deeper in RBAC, it basically contains 3 features.
1) Authentication - It confirms the user's identity. Usually it is done via user accounts and passwords or credentials.
2) Authorization - It defines what user can do and cannot do in an application. Ex. ‘Modifying order’ is allowed but ‘creating new order’ is not allowed.
3) Auditing of user actions on applications. - It keeps track of user's actions on applications, as well as who has granted which access to which users?
This was very basic top view picture of RBAC system.
Basic Structure of RBAC system can contain following components: Users, Roles, Permissions or restrictions, resources.
Permissions or restrictions – permissions represents an access to application’s resource.
Role – It contains collection of permissions
User – Single or multiple roles assigned to user, so eventually user contains permissions via means of role.
In addition to this, you can also have collection of users – called – groups, and role can be assigned to groups, if you want to support complex scenarios. So, This was very basic information about RBAC structure.
It seems that ryanb of railscasts thought along the same lines and created a gem called cancan https://github.com/ryanb/cancan using a basic technique similar to the pivotollabs post.
发布评论
评论（10）
根据我在该领域的基本知识，RBAC 的基本参与者是：
资源 <- 需要-> （一个或多个）权限。
角色 <- 是 -> 的集合 （一个或多个）权限。
用户 <- 可以拥有-> （一个或多个）角色。
这种模型的表为：
现在，如果您希望应用程序的用户能够配置资源需要哪些权限，您可能还需要在此处包含资源。 但我从来不需要那个。 希望有帮助。
To my rather basic knowledge in that area, the basic actors of an RBAC are:
Resources <- require -> (one or many) Permissions.
Roles <- are collections of -> (one or many) Permissions.
Users <- can have -> (one or many) Roles.
The tables for such a model would be:
Now you might want to include resources here as well if you want users of your application to be able to configure which permissions a resource need. But I never needed that. Hope that helps.
这是一个简单的图表来说明 Amr Mostafa 的出色答案
Here is a simple diagram to illustrate Amr Mostafa's excellent answer
我当时正好正在研究 RBAC 子系统……真是太巧了。
我的模型基于系统中需要权限的不同实体的构建块，无论是要查看/更新的属性还是要执行的操作。 当然，系统中还存在不同的角色（可以分配给用户），而将整个系统结合在一起的粘合剂就是访问规则，它连接特定的角色、特定的需要权限的实体和授予的权限。 访问规则可能如下所示：
等等。 我将把 ERD 作为练习留给读者；-) 如果您有疑问，请发表评论。
尤瓦尔=8-)
I happen to be working on the RBAC sub-system here at work at them moment... what a coincidence.
My model is based on the building blocks of the different entities in the system that require permissions, be they attributes to view/update or actions to perform. There are also, of course, different roles in the system (which can be given to users), and the glue that holds the whole thing together is the access rule, which connects a specific role, a specific permission-needing entity and the permission granted. An access rule might look like these:
and so on. I'll leave the ERD as an exercise to the reader ;-) if you have questions, leave a comment.
Yuval =8-)
您可以使用 Restful ACL Rails 插件。
You can use Restful ACL Rails plugin.
我认为你的问题的答案就如你所愿的那样深入。 如果您碰巧考虑将角色放入组中，然后将组与用户相关联是不够的。 最终，您需要向用户授予对特定对象（论坛、视频等）的特定权限。
我更接近尤瓦尔的答案，我们需要的只是关联项目范围的对象+操作+用户。 提供此； 基础对象（实体）非常有意义。 任何继承自 Entity 的对象都可以通过这种方式轻松地与用户 + 操作关联。
因为您也希望让事情变得简单； 我的建议是；
为了更进一步，我还建议
但可惜的是，这仅适用于 .NET，据我所知 Java 没有自定义属性，因此它还不太可能适用于 Java。
我想提供一些代码示例，但我懒得这样做。 如果您对我的 rbac 方式有疑问； 你可以在这里提问，我一定会回复。
I think the answer to your question goes as deep as you wish to go. If you happen to think about putting roles into groups and then associating groups with users wouldn't be enough. Eventually you'll need to give specific permissions to a user on a specific object (a forum, a video etc).
I'm more close to Yuval's answer, all we need is to associate project-wide objects + actions + users. To provide this; a base object (Entity) makes perfect sense. Any object inheriting from Entity can be easily associated with a user + action this way.
As you also wish to keep things simple; my suggestion would be;
To take things one step further, I would also reccomend the following (for an automated rbac)
But alas, that's just available for .NET, as far as I know Java doesn't have custom attributes so that's not yet likely to be available for Java.
I'd like to come up with some code examples but I'm too lazy to do that. Still if you have questions about my way of rbac; you can ask here and I'll surely reply.
角色要求与 Restful Authentication 配合得很好，可以提供基于角色的身份验证功能，并且非常适合 -保持。
Role Requirement works with Restful Authentication very well to provide role-based auth functions and is well-maintained.
试试https://github.com/ThoughtWorksStudios/piece，它是一个供您管理用户的规则引擎基于角色的访问控制：
您可以在此处找到完整的 Rails 应用程序示例：https ://github.com/xli/piece-blog
Try https://github.com/ThoughtWorksStudios/piece, it is a rule engine for you to manage user role based access control:
You can find full Rails application example here: https://github.com/xli/piece-blog
对于 .net 应用程序，您应该查看类似 Visual Guard http://www.visual-guard.com/< /a> 以避免从头开始处理权限和角色。
同样对于 .net，您可以通过配置处理成员资格和角色提供程序以及授权。 http://www.odetocode.com/Articles/427.aspx
For .net applications you should look at something like Visual Guard http://www.visual-guard.com/ to avoid having to handle permissions and roles from scratch.
Also for .net, you have the membership and role providers and authorisation handled with configuration. http://www.odetocode.com/Articles/427.aspx
RBAC 简介 -
基于角色的访问控制系统是一种根据组织用户的角色限制对“某些源或应用程序或应用程序的某些功能”的访问的方法。
这里，限制可以通过多个权限来实现，这些权限是由管理员创建的，用于限制访问，这些权限共同代表一个角色，该角色将被分配给用户。
如果我们进一步深入了解 RBAC，它基本上包含 3 个功能。
1) 身份验证 - 确认用户的身份。 通常它是通过用户帐户和密码或凭据完成的。
2) 授权 - 它定义用户在应用程序中可以做什么和不能做什么。 前任。 允许“修改订单”，但不允许“创建新订单”。
3) 审核用户对应用程序的操作。 - 它跟踪用户对应用程序的操作，以及谁向哪些用户授予了哪些访问权限？
这是 RBAC 系统非常基本的俯视图。
RBAC系统的基本结构可以包含以下组件：
用户、角色、权限或限制、资源。
应用程序的资源。
通过角色包含权限。
除此之外，如果您想支持复杂的场景，您还可以拥有称为组的用户集合，并且可以将角色分配给组。
这是有关 RBAC 结构的非常基本的信息。
Introduction to RBAC -
Role based access control system is a method of restricting access to 'some sources or applications or some features of applications' based on the roles of users of organization.
Here, restrictions can be by means of multiple permissions, those are created by administrator to restrict access, and these permissions collectively represents a role, which will be assigned to user.
And if we go slight deeper in RBAC, it basically contains 3 features.
1) Authentication - It confirms the user's identity. Usually it is done via user accounts and passwords or credentials.
2) Authorization - It defines what user can do and cannot do in an application. Ex. ‘Modifying order’ is allowed but ‘creating new order’ is not allowed.
3) Auditing of user actions on applications. - It keeps track of user's actions on applications, as well as who has granted which access to which users?
This was very basic top view picture of RBAC system.
Basic Structure of RBAC system can contain following components:
Users, Roles, Permissions or restrictions, resources.
application’s resource.
contains permissions via means of role.
In addition to this, you can also have collection of users – called – groups, and role can be assigned to groups, if you want to support complex scenarios.
So, This was very basic information about RBAC structure.
我真的很喜欢这篇博文： https://content.pivotal.io /blog/access-control-permissions-in-rails
编辑：
railscasts 的 ryanb 似乎也有同样的想法，并创建了一个名为 cancan 的 gem https://github.com/ryanb/cancan 使用类似于pivollabs帖子的基本技术。
I really like this blog post: https://content.pivotal.io/blog/access-control-permissions-in-rails
EDIT:
It seems that ryanb of railscasts thought along the same lines and created a gem called cancan https://github.com/ryanb/cancan using a basic technique similar to the pivotollabs post.