-
Notifications
You must be signed in to change notification settings - Fork 11
Home
There are several different philosophies, such as role-based access control and attribute-based access control. These strategies typically implement Mandatory Access Control (MAC) and/or Discretionary Access Control (DAC). Theories aside, we really just wanted a proper and repeatable manner in which to restrict access to resources.
The author of this library took inspiration from IAM and Active Directory. IAM has become a common means of managing cloud services, while Active Directory remains one of the most commonly used and most effective access control systems in the world.
The beauty of Active Directory is combination of an LDAP-style system with access control policies. The LDAP-style organizes people into groups and organizational units (OU's, which are typically treated like groups). Policies are defined to enforce rights on known system resources. These policies can be applied to users and/or groups. It creates a very effective (albeit complex) cascading effect for inheriting permissions from groups or "groups of groups". This library approaches access control in a similar manner. The primary goal is to simplify access control through basic organization and binary authorization questions (i.e. "is the user authorized to do that?").
Why not IAM or LDAP?
Most IAM systems are designed around the mindset that a role is also a group. The lack of distinction between a role (policy) and group can lead to confusion and significant duplication. In practice, there are often many roles that are very similar, with only minor differences. This is part of the reason why services like Amazon Web Services have so many roles and complicated policies.
Active Directory separates the concept of a role (policy) and group. This provides a significantly better organizational hierarchy, but it's more complex for simplistic applications.
The key distinction of this library is groups and roles are separated, but roles can be treated like a group in simpler applications It is entirely possible to use a role like a group by applying it to a several users. It's also possible to assign a role to a group, then use the group to collect users.
Browser applications are much more likely to be dealing with one user at a time. Is IAM overkill in these situations? Absolutely not. Resources, groups, and rights are still applicable to an entire system, even when a user may only be relevant to an individual session. This library's separation of concerns allows developers to maintain resources/roles/groups independently of users.
API's also maintain resources/roles/groups independently of users. API authors can use this library to load aand maintain a configuration in one location while user access to endpoints can be managed individually on each request.
One of the major issues the author of this library kept running into was developing with inconsistent ACL strategies. It was really annoying when a user would be able to access a part of a web page or API they shouldn't.
The scenario was (far too often):
"Hey, that person isn't supposed to be able to do that. I set the permissions correctly, so why do they still have access?".
There really needed to be a way to quickly understand why a user was or wasn't seeing something they shouldn't. Being able to trace a situation back to its source would be really helpful, i.e. "tell me how this user got these permissions". This is a major reason why IAM was written, and it is the entire reason why IAM has a permission lineage system built into it.
At the end of the day, this is just a library that focuses on separation of concerns. There are other libraries which implement different approaches. Many are tied to specific nomenclatures, particular databases, or opinions. This library tries to find a balance between objectivity and simplicity.