What is the exact difference between ACL and RBAC in general?

Question

Hello all this may be a silly question but I am really confused about ACL, RBAC, DAC, MAC...

with the simple example of online university management system that has following user types:

• admin
• hod
• faculty
• student

each of them have different privileges to access.

Can some one make me understand what will be used here ACL? RBAC? DAC? MAC? and why it will be preferable than others? I have searched alot but was not able to understand how to decide which authorization technique most fits the above situation...

Answer 1

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".

Answer 2

In your example, I would suggest to use RBAC rather than ACL, because RBAC is more flexible for enhancements and maintenance, which will be always in system like University management system.

In this kind of system, the privilege or permissions you will apply on the resources, and these resources will be frequently changed as the system expands. so technically managing all these resources and their access controls will be a headache, in terms of database, code and architecture.

and if we apply RBAC in this case, database and architecture will be flexible enough for handling future changes, where you just need to manage permissions and actions accordingly,