What's the difference between groups and roles?

A lot of identity management implementations use roles in addition to groups. How are they different? So far I haven't fo开发者_如何学Gound a compelling use case for separating the two. All the explanations I've read are vague and hand-wavey.

Can you give a good example where having roles and groups are necessary?

Roles are sets of rights.

Groups are sets of people.

Imagine you have 2 groups of people (G1, G2) using an application (A1) for which you have two types of users: administrators and read only users.

You can create a role of admin on A1, define its rights and give G1 this role. If G2 also needs these rights, you don't have to grant them one by one, you can simply give G2 the same role you created for G1.

Person - Group - Roles

• A person is a member of one or more groups.
• A group is assigned multiple roles.

Example:

• Two roles exist in a system stock_purchaser, timecard_supervisor.
• Two groups exist in a system shift_supervisor, regional_manager.
• regional_manager has the stock_purchaser and timecard_supervisor role.
• shift_supervisor has the timecard_supervisor role.

In the event a new role (e.g. review_leave_requests) is created - this can be added to all those groups who require this role. In a system only having roles it may be a laborious task adding the role to all people that require it.

One important that is missing in all comments is the fact that you can assign roles to individual users as well, and not just to groups.

Here is a use case: A university Physics professor has "Grade Test" role (aka right or privilege) for a particular course or set of courses. However, he decides to go on sabbatical for year and wants another instructor (or perhaps, several instructors - a group), i.e. his replacement(s), to have the same role(s) (privileges) over the same set of courses. Note that the substituting instructors may belong to different user groups. The administrator can easily assign the role(s) in question to individual users or groups of users. Of course, after the tenured professor returns, the administrator can revoke those roles (privileges).

From a system perspective we only care which methods a user (or a group of users) is allowed to execute. Before executing restricted method we check user roles by calling other methods that normally return Boolean values.

For me the difference between "groups" and "roles" is in the Cardinality

A group can not contain a group. But a role can contain roles.

I like the way PostgreSQL handles it: From Database Roles and Privileges

A role can be thought of as either a database user, or a group of database users, depending on how the role is set up

This means using roles can make applications simpler and more flexible. Imagine an issue tracking tool. With a Foreign-Key to a role, you handle both cases: You can reference a single person or several persons.

The tendency that we do as application implementation with groups is focusing on the association between groups and the user rather than the actual group. I have seen several implementation (and am guilty of doing so myself early on), that just check the name of the group.

This is obviously a bit problematic, because each application will define its own permissions, resulting in elevating permissions in systems and inconsistency in permissions.

The role has explicit association with role and those will change at a central location. This become more consistent and can be managed by an admin for all applications.

Conceptually the idea of groups and roles can be interchangeable but in implementation this can get difficult to manage

Here are some more info here:

https://csrc.nist.gov/projects/role-based-access-control/faqs#:~:text=As%20normally%20implemented%2C%20a%20group,groups%20to%20which%20they%20belong.&text=RBAC%20requires%20all%20access%20through,roles%2C%20not%20directly%20to%20users.