rights - Group vs role (Any real difference?)

Question

Can anyone tell me, what's the real difference between group and role? I've been trying to figure this out for some time now and the more information I read, the more I get the sense that this is brought up just to confuse people and there is no real difference. Both can do the other's job. I've always used a group to manage users and their access rights.

Recently, I've come across an administration software, where is a bunch of users. Each user can have assigned a module (whole system is split into a few parts called modules ie. Administration module, Survey module, Orders module, Customer module). On top of it, each module have a list of functionalities, that can be allowed or denied for each user. So let's say, a user John Smith can access module Orders and can edit any order, but haven't given a right to delete any of them.

If there was more users with the same competency, I would use a group to manage that. I would aggregate such users into the same group and assign access rights to modules and their functions to the group. All users in the same group would have the same access rights.

Why call it a group and not role? I don't know, I just feel it that way. It seems to me that simply it doesn't really matter :] But I still would like to know the real difference.

Any suggestions why this should be rather called role than group or the other way round?

Answer 1

Google is your friend :)

Anyways, the divide between role and group comes from concepts of computer security (as opposed to simply resource management). Prof. Ravi Sandhu provides a seminal coverage of the semantic difference between roles and groups.

http://profsandhu.com/workshop/role-group.pdf

A group is a collection of users with a given set of permissions assigned to the group (and transitively, to the users). A role is a collection of permissions, and a user effectively inherits those permissions when he acts under that role.

Typically your group membership remains during the duration of your login. A role, on the other hand, can be activated according to specific conditions. If your current role is 'medical-staff' you might be able to see some of the medical records for a given patient. If, however, your role is also 'physician', you might be able to see additional medical information beyond what a person with just a role of 'medical-staff' can see.

Roles can be activated by time of day, location of access. Roles can also be enhanced/associated with attributes. You might be operating as 'physician', but if you do not have a 'primary physician' attribute or relation with me (a user with 'patient' role), then you cannot see my entirety of medical history.

You could do all that with groups, but again, groups tend to focus on identity, not role or activity. And the type of security aspects just described tend to align themselves better with the later than with the former.

For many cases, for the usage of classifying things together (and nothing more), groups and roles function just the same. Groups, however, are based on identity, whereas roles are meant to demarcate activity. Unfortunately, operating systems tend to blur the distinction, treating roles as groups.

You see a much clearer distinction with application or system-level roles - carrying application or system-specific semantics (like in Oracle roles) - as opposed to 'roles' implemented at the OS level (which are typically synonymous to groups.)

There can be limitations to roles and role-based access control models (like with anything of course):

http://www.lhotka.net/weblog/CommentView,guid,9efcafc7-68a2-4f8f-bc64-66174453adfd.aspx

About a decade ago I saw some research on attribute-based and relationship-based access control which provide much better granularity than role-based access control. Unfortunately, I haven't seen much activity on that realm in years.

The most important difference between roles and groups is that roles typically implement a mandatory access control (MAC) mechanism. You do not get to assign yourself (or others) to roles. A role admin or role engineer does that.

This is superficially similar to UNIX groups where a user can/might be able to assign himself to a group (via sudo of course.) When groups are assigned according to a security engineering process, the distinction blurs a bit, however.

Another important characteristic is that true RBAC models can provide the concept of mutually exclusive roles. In contrast, identity-based groups are additive - a principal's identity is the sum (or conjunction) of the groups.

Another characteristic of a true-RBAC based security model is that elements created for a particular role typically cannot be transitively accessed by someone who does not act under that role.

On the other hand, under a discretionary access control (DAC) model (the default model in Unix), you cannot get that type of guarantee with groups alone. BTW, this is not a limitation of groups or Unix, but a limitation of DAC models based on identity (and transitively, with identity-based groups.)

Hope it helps.

=======================

Adding some more after seeing Simon's well-put response. Roles help you manage permissions. Groups help you manage objects and subjects. Moreover, one could think of roles as 'contexts'. A role 'X' can describe a security context that rule how subject Y access (or does not access) object Z.

Another important distinction (or ideal) is that there is a role engineer, a person that engineers the roles, the contexts, that are necessary and/or evident in an application, system or OS. A role engineer typically is (but does not have to be) also a role admin (or sysadmin). Moreover, the true role (no pun intended) of a role engineer is in the realm of security engineering, not administration.

This is a novel group formalized by RBAC (even if it seldom gets used), one which has typically not been present with group-capable systems.