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 the organization grows, roles and access rights assignments grow exponentially in complexity, creating potential platform organizational and reliability problems. All of that could substantially increase your maintenance costs.

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, becomes 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