74

What are the benefits of each, and when should I choose one over the other? Are there situations where these should be merged?

Do you have examples of common usages?

And what about MAC, where does that fit in?

AviD
  • 72,138
  • 22
  • 136
  • 218

1 Answers1

93

RBAC (Role based access control) is based on defining a list of business roles, and adding each user in the system to one or more roles. Permissions and privileges are then granted to each role, and users receive them via their membership in the role (pretty much equivalent to a group). Applications will typically test the user for membership in a specific role, and grant or deny access based on that.
Discretionary Access Control (DAC) allows a user or administrator to define an Access Control List (ACL) on a specific resource (e.g. file, registry key, database table, OS object, etc), this List will contain entries (ACE) that define each user that has access to the resource, and what her privileges are for that resouce.

The main benefit of RBAC over DAC, is ease of management - in principle you have a very few roles, centrally administered, no matter how many users, and its just a question of granting each user the correct role; as opposed to DAC, where for each new user (or change in user, or deletion, etc), you have to go around to all the resources she needs access to and add them to the list.
On the other hand, DAC is often simpler, and generally more granular. Also, in the DAC model the data owner can decide who has access (if he has that permission on the data) and add or remove people from the list.

Very common example of DAC is the Windows file system. On the other hand, very common example of RBAC is the DAC on corporate file servers - anyone in the "Sales" ActiveDirectory group will have access to the \Sales\ shared folder. More commonly is the Administrators group in Windows.

MAC is Mandatory Access Control, this can be seen as a classification or privacy level. This is most often used in military systems, and back in the Mainframe days :). Not so much used anymore, though current OS's are implementing a flavor of this, such as Vista/Win7's Integrity Levels.

To sum up the differences:

  • DAC is based on personal permissions, RBAC on "group"-level permissions
  • DAC is set by the data owner, RBAC by the system owner/s (usually the developer defines the access given to each role, and the operational admin puts users into roles)
  • DAC definitions are typically attached to the data/resource, whereas RBAC is usually defined in two places: in code/configuration/metadata (the roles access), and on the user object (or table - the roles each user has).
  • On the other hand, RBAC roles are centrally administered (who is associated with which roles), whereas DAC is administered "on the resource" (i.e. you administer each resource individually).
  • The definition of permissions per role is typically static in RBAC, and users are only granted roles; in DAC the permissions per resource are often changed at runtime.
  • DAC should be seen as enumerating "who has access to my data", and RBAC defines "what can this user do".
AviD
  • 72,138
  • 22
  • 136
  • 218
  • 1
    From what I understand of RBAC is that there are no objects - only actions that can be performed. – d-_-b Dec 14 '11 at 05:30
  • @sims yes, that is true too. RBAC does not relate to specific items of data, just "what this role can do". – AviD Dec 14 '11 at 08:58
  • Also in RBAC is the concept of a session: the roles you currently have is related to your login-session. (For example: you can be both an administrator or a normal user, but not both at once, your session tells which role(s) you currently have) – Rolf Rander Mar 10 '12 at 14:06
  • 1
    @RolfRander though that is common in many implementations, that is not inherent to the model. – AviD Mar 10 '12 at 21:42
  • @AviD ok, I actually thought it was the other way around, that it was a central part of the model but not widely implemented. But I don't have any experience with typical products, I have only read this here: https://blogs.oracle.com/identitythink/entry/whats_wrong_with_the_nist_rbac – Rolf Rander Mar 11 '12 at 19:35
  • 5
    It might be nice to note that RBAC and ACL can replace eachother; you can configure RBAC permissions to cover the policy set out by ACL and vice versa. Also, there are quite some implementations of RBAC out there who grant discretionary powers to users. Those RBAC systems have been proven to be able to offer all functionality of DAC. – Jacco May 18 '12 at 10:17
  • 3
    It might also be nice to note that in RBAC there are no negative-permission (deny). Although some implementations do provide them, negative permissions are usually associated with ACL/DAC and not with RBAC. – Jacco May 18 '12 at 10:19
  • @Jacco I agree with your first comment (though that is usually complex and not well implemented), but disagree with your second. Though not built-in, and often complex, RBAC *can be* (and has been) used for SoD (segregation of duties), e.g. blocking a certain action if you are also in another role. I don't necessarily recommend this, but it is possible. – AviD May 18 '12 at 12:37
  • @AviD, I supect we are talking about the same thing, SoD is definately part of (the more complex) RBAC models (including NIST standard). But, to my knownledge, SoD is implemented as a constriant "Conflicting permissions cannot be included in the same role, etc" instead of negative permissions "Allow ALL + Deny DELETE" type permissions sets. (Although some RBAC implementations do also include the latter) – Jacco May 18 '12 at 13:05
  • @AviD, Suggest to add MAC to the sum up as access to system resources can not be controlled by user – Gert Cuykens Jul 23 '13 at 02:15
  • 1
    For negative permissions and more fine-grained authorization on resources, use attribute based access control (ABAC) – David Brossard Aug 17 '16 at 16:43
  • This just sounds like groups added. Correct me if I am wrong, but I think roles need to be independent of user groups. For example, a role may be a set of actions that may be applied by a user/group on a list of objects. Therefore, role is independent of both object and user. This allows you to specify a user/group to be able to run backups (backup role) on one database, but not another. – rfportilla Feb 26 '19 at 23:55
  • @rfportilla groups is one common implementation of roles, especially when using a user directory platform (eg ActiveDirectory). And these can be nested, so adding a group to a role (or a group to a group) works as well. – AviD Feb 27 '19 at 11:30
  • Sure, AviD. I just want to be clear that the purpose is not to group users or objects, but to group tasks. Just grouping users is not really RBAC, is it? – rfportilla Feb 27 '19 at 14:32
  • Well you'd assign users to roles (put them in groups), and then grant permissions to the roles. Strictly speaking a role doesn't group tasks either - there are other models for that, though often systems will implement this kind of "expanded RBAC", and I am all in favor of that (whatever you call it, but clarity is important as well). – AviD Feb 27 '19 at 20:05
  • @AviD could you spot the difference between permissions and privileges? – Federico Piazza Mar 27 '19 at 19:28
  • I think it is mostly a question of nomenclature, but often "permissions" is used on a specific data object, whereas privileges is more system-wide. But this might be my own subjective view. – AviD Mar 27 '19 at 22:56