RBAC, or Role Based Access Control, assign employee rights to access and change different documents, web pages and code repositories based on their function, i.e role, within the organization.

Why should I care?

As an organization grows, the need to remove bottlenecks often pass through giving more rights to make changes to more people. The increased rate of changes needs to be balanced with security and reliability constraints. Roles and access rights will naturally emerge.

In a typical Software-as-a-Service business, the customer support manager would have access rights to view customer data, the Web designer would have access rights to change the formatting of a web page, the application developer would have access rights to change the code in a repository and the marketing manager would access rights to change the content of a web page or a front-facing customer document.

How does it work?

When starting the application developer will often create an admin user account that can access everything within the app and a regular user account. Usually, permissions are backed into the source code directly. As the product evolves, more almost-but-not-quite admin roles are added. More servers are also added to handle increased customer traffic. Managing permissions, as a result, become more complex. Separate RBAC layers are formally added between the users and the business logic application to implement and audit access policies.

RBAC is often used in conjunction with SSO and deployed with CDNs or load-balancers