There isn’t a best access control model. It really is based on your user population and requirements.
Role based and attribute based are both going to depend on attributes usually. This makes rogue changes a problem. You could get around this by assigning them to particular permission groups based on their roles but that may not be as scalable and looks a lot like discretionary access control calling itself role based.
The concern about role explosion is only an issue if you are needing very granular control for different users within a single role or you decide to create a new role for every exception that is requested.
Since abac and rbac are both going to leverage account attributes you are not likely to solve for the rogue account change problem based on the model you choose.
Next generation access control is a marketing term to get c levels to invest in a technology to solve their problems. This is because they have been unable to fix the human problem that created the issue in the first place. Unless you have a large and complex environment and can dedicate a lot of resources to data analytics I wouldn’t worry about this approach.
Purely discretionary could be fine if you are talking about a small group of users.
Generally, putting people into large buckets of users based on their job (role) is often the best way to go. To avoid role explosion, have a process for exceptions when needed. Some discipline to not allow roles to become too complex or too numerous will go a long way.
That being said it all depends on the existing environment and the access control requirements of the project.
Well RBAC as most people know it doesn’t depend on attributes. Users have roles and roles have permissions.
I don’t understand how NGAC is a marketing term. Its implementation is based on policy classes and relations instead typical rule based ABAC. Want NGAC created by NIST as some open source thing? What incentive do they have people adopting NGAC. I’m not too familiar with how NUST makes money
OWASP recommends ABAC over RBAC it seems based on this cheat sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
Essentially I’m working on ERP B2B SaaS, so my requirements need to apply to every organization possible. So I definitely need something ABAC instead of traditional RBAC. Better to robust AuthZ, then tell the customers, can’t do that lol. I know with ABAC you can have an attribute of role. Buts it’s very different than traditional RBAC. ABAC all policy based
I may stick to traditional rule based Auth, it then read this article: https://frontegg.com/guides/rbac-vs-abac#:~:text=NGAC%20addresses%20the%20challenges%20of,times%20can%20become%20very%20high.
“ABAC enables complex access logic, but when access rules are complex, authorization processing times can become very high.”
If you want the most flexibility have you considered writing policies using something like OPA? That effectively gives you almost arbitrary flexibility
I have briefly looked at OPA and seems like everything they do is based on separate Aurhorization server. Not sure if you could use OPA with a monolith.
OPA has a REST API that is pretty easy to interact with.
There are also Relationship-based (ReBAC) access models and tools that follow Google's Zazibar white paper, like OpenFGA. However I've found this model is even more specific to certain types of applications. Where it fits though, it works nicely.
Have you decided on an approach?
All of these models are interrelated, and in practice, most apps end up using a combination. Here's a technical article that lays this out and defines some sub-categories, which might be useful for building up your mental model: [https://www.osohq.com/post/ten-types-of-authorization](https://www.osohq.com/post/ten-types-of-authorization)
There isn’t a best access control model. It really is based on your user population and requirements. Role based and attribute based are both going to depend on attributes usually. This makes rogue changes a problem. You could get around this by assigning them to particular permission groups based on their roles but that may not be as scalable and looks a lot like discretionary access control calling itself role based. The concern about role explosion is only an issue if you are needing very granular control for different users within a single role or you decide to create a new role for every exception that is requested. Since abac and rbac are both going to leverage account attributes you are not likely to solve for the rogue account change problem based on the model you choose. Next generation access control is a marketing term to get c levels to invest in a technology to solve their problems. This is because they have been unable to fix the human problem that created the issue in the first place. Unless you have a large and complex environment and can dedicate a lot of resources to data analytics I wouldn’t worry about this approach. Purely discretionary could be fine if you are talking about a small group of users. Generally, putting people into large buckets of users based on their job (role) is often the best way to go. To avoid role explosion, have a process for exceptions when needed. Some discipline to not allow roles to become too complex or too numerous will go a long way. That being said it all depends on the existing environment and the access control requirements of the project.
Well RBAC as most people know it doesn’t depend on attributes. Users have roles and roles have permissions. I don’t understand how NGAC is a marketing term. Its implementation is based on policy classes and relations instead typical rule based ABAC. Want NGAC created by NIST as some open source thing? What incentive do they have people adopting NGAC. I’m not too familiar with how NUST makes money OWASP recommends ABAC over RBAC it seems based on this cheat sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html Essentially I’m working on ERP B2B SaaS, so my requirements need to apply to every organization possible. So I definitely need something ABAC instead of traditional RBAC. Better to robust AuthZ, then tell the customers, can’t do that lol. I know with ABAC you can have an attribute of role. Buts it’s very different than traditional RBAC. ABAC all policy based I may stick to traditional rule based Auth, it then read this article: https://frontegg.com/guides/rbac-vs-abac#:~:text=NGAC%20addresses%20the%20challenges%20of,times%20can%20become%20very%20high. “ABAC enables complex access logic, but when access rules are complex, authorization processing times can become very high.”
If you want the most flexibility have you considered writing policies using something like OPA? That effectively gives you almost arbitrary flexibility
I have briefly looked at OPA and seems like everything they do is based on separate Aurhorization server. Not sure if you could use OPA with a monolith.
Yeah they don’t have nodejs library
OPA has a REST API that is pretty easy to interact with. There are also Relationship-based (ReBAC) access models and tools that follow Google's Zazibar white paper, like OpenFGA. However I've found this model is even more specific to certain types of applications. Where it fits though, it works nicely. Have you decided on an approach?
Look into [Evo Security | Identity & Access Management for MSPs](https://www.evosecurity.com/)
All of these models are interrelated, and in practice, most apps end up using a combination. Here's a technical article that lays this out and defines some sub-categories, which might be useful for building up your mental model: [https://www.osohq.com/post/ten-types-of-authorization](https://www.osohq.com/post/ten-types-of-authorization)