RBAC (Role Based Access Control)
Overview
There are already great sources that detail the various flavors of Role-Based Access Control. The best ones are:
Composition vs Inheritance
Although inheritance has its place in RBAC, just as it does in Object-Oriented Programming, composition should be favored over inheritance when there’s no obvious choice, because of the lower chance of side effects thanks to more explicit permission grants, and higher malleability thanks to the lack of rigid hierarchies.
However, the two are not mutually exclusive. Even in an inheritance role structure, the permissions (or actions) are assigned in a composite manner (unless they are attached statically to the roles).
Actions
Actions can usually be broken down into Resource + Operation, with Operation being one of Create, Read, Update, or Delete.
Alternatives
Attribute-Based Access Control (ABAC)
ABAC uses policies to determine access, consider attributes of the user, the resource to be accessed, and environments of both the user and resource. An example of this implementation can be found at: What is ABAC for AWS?
Identity-Based Access Control (IBAC)
IBAC is the equivalent of an Access Control List (ACL). Each resource has a list of identities that are allowed access to it.
Considerations in a Distributed System
These considerations are not specific to RBAC, but it’s worth mentioning given the nature of this website.
Centralized vs Distributed Access Control Management
Modern, mainstream access control systems are controlled centrally. Blockchain and peer-to-peer networks are currently the only exceptions to this rule (if one considers them mainstream).
Pull vs Push Updates in Centralized Access Control Management
Push Updates
In a Push Update mechanism, all services that require authorization become subscribers to the Centralized Access Control Management service (the publisher of permission updates). These subscribers are effectively lightweight servers in this context that receive requests from the centralized service upon updates to permissions.
Pull Updates
In a Pull Update mechanism, all services make requests to the Centralized Access Control Management service. The drawback to this solution is that the cached permissions stored locally on each service can go stale in between polling requests to the Centralized Access Control Management Service when permissions are updated by the end-user or end-service. This can be partly alleviated by long-polling, where the requests for permission updates to the Centralized Access Control Management service are held open for a long duration. When an update is received from the Centralized Access Control Management service, those long-polling requests are finally returned with the updates.
Front-End Nuance
In a system with a Front-End, in the event that a user’s permissions have decreased in scope, removing access to something that is presently displayed on-screen may be desirable. This can easily be accomplished by maintaining an open websocket connection for permission updates.
Scaling Nuance
Once a company grows to several hundred developers, defining all permissions for a large distributed system in a single location in the codebase can become a scaling problem as multiple devs battle to make changes to the same file. This problem isn’t specific to Centralized Access Control Management.
And of course, anything centralized in a large distributed system will require sufficient provisioning of compute resources.
Author
Sam Malayek works in Vancouver, using this space to fill in a few gaps. Opinions are his own.