2
I would like to know the difference between these two types of ACL and RBAC access control.
I’ve been reading about them, and I’ve been a little confused to understand them. The following questions about them are:
1- Difference (a direct explanation please).
2- Which to use?
3- Advantages between the two.
4
First: I researched to give a more informed answer and I concluded that some people disagree at least with the details of what is each thing, it is not easy to find a formal definition, and this is less desirable, as long as what uses solves the problem well. I’ll put my conclusions.
Access Control List is usually a generic term without indicating the implementation of this. But some people mistake it for DAC (Discretionary Access Control) and I think that’s what you’re asking. I will answer the difference between DAC (which you called ACL) and RBAC.
For me, the main difference is in what type of resource is being privileged. DAC usually does this object by object. It could be a file, a message, an entry in a generic or specialized database, anything individual. RBAC usually gives access to more general resources, to generic entities that have multiple objects. You can access document pages (but not the individual page), registered clients, device, etc.
In general it may have some granularity of what you can do there as create, edit, delete, view, download, approve, etc. Some general privileges only make sense in one of them. For example if you can give property to someone it’s usually interesting in DAC, but not necessarily in RBAC.
Another important point is that RBAC is usually defined in code or if it has some flexibility it can be controlled by a general system administrator. The DAC is usually controlled by the owners of the objects.
In an operating system we usually see a DAC and as the user of that machine is usually the administrator the two get confused. And in fact in some cases some implementations are often hybrid, or at least lend characteristics.
When RBAC starts to become more dynamic and less encoded, when it can conditionally give privilege even by complex formulas it starts to turn into Attribute-Based Access Control (ABAC).
Role Based Access Control usually has 3 entities:
The role is the focus of this modality.
In the RBAC a new privilege is given for the role and all users who are associated with that role gain the privilege. Just as if you add a user you associate it with roles and it gains the privileges of these. And when creating a new role tells you what privileges it will have and who the users are associated with.
It’s much easier to manage this way. But not all flowers are because there are cases that a user should have a specific privilege that people in a role should not have. The solution in a pure RBAC is to create a role just for that.
Ultimately you could have as many roles as the combination of possible privileges, ie you could have zillions of roles with a few existing privileges. Of course this would be in case exaggerated but it gives an idea that can complicate.
For the purpose of understanding and comparison with the DAC one can consider that the owner of the resource in such cases is the system administrator or the developer.
Done correctly is more scalable.
It can create a paradox. A role can be restricted to one action, another role to another. A person has the role of serving the customer, if she who is the least specialized and perhaps less reliable (often even outsourced) must have the privilege of the two previous roles to solve everything the customer needs it. If you do not do this the customer needs to talk to several people to solve their problems and will curse your company, if you do the restriction does not make sense. But of course this is a question of organization.
Some people say that if you have papers it’s not ABAC, but I don’t know, maybe you just change the name because user or group can be considered the same thing. There’s so much dissonant information, it’s hard to give canonical information. And I do not know if it is important, it is to know that there are several mechanisms that can be used and meet your needs. I think someone creates a definition and then others start using something similar using the same term, you know, Bombril or Gilette? So strictly ABAC may have a clear definition, but people use the term for similar things.
ABAC usually considers contexts. So a privilege can even be given depending on where the person is accessing, the moment, whether something has happened before, or any set parameter.
Some consider ABAC a framework (not necessarily a software framework).
In the DAC has a specific owner of the individual resource who is able to give the privilege. The privilege can also be more granular.
This does not usually have the role, so privileges are given directly to users. But some consider a hybrid system that allows to have roles (roughly groups, even if it is a slightly different concept) as if they were users a form of DAC, as long as it retains the property characteristic of the resource.
Here the focus is the resource.
This is why it is common to adopt a hybrid system where RBAC is always adopted and DAC when it is very necessary (unfortunately this is not so well used and starts to become a mess). Including permission to use DAC can be given according to RBAC, which decreases the possibility of failures in the organization.
Some people say that ABAC is just a hybrid form. Some put other characteristics and try to standardize a way of doing every process giving the chance to each have their own needs met.
It’s not a clear requirement, but the RBAC usually has more granularity in the privileges. The DAC usually has the right of access and eventually write or something more general. RBAC usually has privileges that only make sense for one type of resource, for example it can give a discount on a title to be received. But I don’t see why DAC can’t have that, except for the fact that having granularity on both sides creates a pretty big burden to manage. Some will say it begins to be an ABAC.
Papers usually have hierarchies, if we can even use that name. So if a derived role gains a privilege the base role of it automatically wins, which is the inverse of the hierarchy.
In general, RBAC is better where it potentially has many users, or has a lot of volatility of users, which is the vast majority of cases, and DAC adopted as a measure of easing. Only DAC is used when it is known that it will have very few users in any case.
RBAC is obviously a little harder to understand and operate for small volumes. The concept of user and privilege is intuitive by all, the concept of paper is not. And in many cases it is an extra step to make (it is a indirect in the application), it brings advantages, but imposes a cost. But having some roles facilitates management giving stability and vision of who can what.
DAC allows better privacy control and may not be as difficult to manage if there are roles as a complement to the user system and can group resources (some will say they are only groups and not roles).
The best is usually the hybrid, but in some cases to simplify can have only the RBAC, since it does not need great flexibility and the resources are more general and not specific objects, although this works as well). DAC is usually better in a collaborative environment with many unstructured resources (files, tokens, messages, specific objects), but still RBAC in such cases can be useful.
You’ll find more RBAC or ABAC in an ERP or something, and more DAC in an operating system or platform (a social network for example).
If you’re an active OS user do an exercise: here you use an RBAC, DAC or ABAC? What’s Windows like? Tip: It’s not that simple.
How DAC usually gives more work is common for people to end up using it as an A/RBAC or loosening control. Take this into account.
It seems that RBAC is the solution to an ERP, but think of cases where one division competes with another or has legislation that does not allow the data of a particular product to be accessed improperly because it has access to the products as a whole. Or a salesman who can’t see customer data that isn’t his. Or even an employee see the wages of other people who are not his subordinates. It is not so simple to identify what is best. But the hybrid is usually more powerful when it needs it.
I saw some people saying that R/ABAC works better with Apis, but I don’t even see the connection. For me API is not resource, what’s behind it is, API is the access medium but not the access itself.
The specific ways of implementing each one is very vast, you can use a lot of creativity.
As I always say, the concrete need is what defines which to use. Understanding the concepts correctly and knowing how to analyze and define well the problem ahead is that allows you to choose which is the best. You can cite examples as I did above to indicate a path, but you run the risk of deciding simplistically and trying to fit your case as if it were one of these examples and do the same.
Something complex cannot be understood as a cake recipe. Unfortunately people believe this is possible, so there’s more and more bad stuff being developed.
It is always the commitment of the user who will make the control succeed. Both are difficult to keep coherent over time.
I disagree with some of the conclusions that I found out there, perhaps from different experience or because some of them were taken in the past when you didn’t know how to deal with certain situations, including mixing auditing with access control that are very different concepts, linked but independent.
Browser other questions tagged php security-guard acl
You are not signed in. Login or sign up in order to post.
Your question is normal and the answer is simple. Look for the difference in authorization and authentication :)
– Marcelo Guimarães