Role-based access control (RBAC)

The question is no longer "May Ms Meier change prices?" but "May the sales management role change prices?" and "Is Ms Meier head of sales?".

The principle sounds trivial, but it is the reason why permission management in companies can be run at all. Anyone who gives each account rights individually with 200 employees and 80 permissions manages up to 16,000 assignments. With ten roles, there are ten bundles of rights and 200 role assignments. If someone changes department, you swap the role instead of searching for and withdrawing dozens of individual rights.

How RBAC works

At its core, RBAC has four building blocks: users, roles, permissions and sessions. A permission describes a permitted operation on an object, such as "read order" or "edit price list". A role bundles several permissions under a business name. A user is assigned to one or more roles. A session activates a subset of the assigned roles for the duration of a log-in. The check at runtime accordingly runs in two steps: which roles does the user currently have, and does one of these roles contain the required permission?

The decisive factor is the indirection. Permissions hang on roles, roles hang on users. This intermediate level makes changes cheap and audits possible, because the question "Who may do what?" can be answered from two small tables and not from thousands of individual entries.

The NIST reference models

The formalisation that is authoritative today comes from the US National Institute of Standards and Technology. Work by David Ferraiolo and Richard Kuhn in the early 1990s was followed in 2000 by the unified NIST model, which was later adopted as ANSI standard INCITS 359-2004. It describes four levels that build on each other:

• Flat RBAC: users get roles, roles get permissions. Nothing more is needed to get started.
• Hierarchical RBAC: roles can inherit from other roles. A "team lead" role then automatically contains everything that "clerk" may do and adds its own rights.
• Constrained RBAC: restrictions apply, above all separation of duties. Whoever may record invoices may not approve them at the same time.
• Symmetric RBAC: in addition, it is possible to check which roles have a particular permission, which makes permission reviews easier.

For most applications in practice, flat RBAC and a simple hierarchy are enough. The formal framework is still useful because it defines the terms that auditors and security officers work with.

Distinction from other access models

RBAC is not the only way to control access. Which model fits depends on how fine-grained and how dynamic the decisions need to be.

In practice, many systems combine the approaches. An application grants coarse rights via roles and refines individual decisions via attributes, for example "sales management may approve discounts, but only up to 15 per cent and only for customers in its own region". This combination is often called RBAC with an ABAC extension.

Why RBAC is relevant in e-commerce and B2B

A shop back end is a tool with which many departments work on the same data. Accounting sees payments and invoices, marketing maintains content and promotions, customer service processes orders and returns, product management changes items and prices, and external agencies need access to certain areas. Without a role model, there are only two bad options: everyone is an administrator, or every access is enabled individually.

The first variant is a security risk. A compromised account with full rights can change prices, export customer data or switch off payment methods. The second variant is an operational risk, because it has to be updated manually with every staff change and errors reliably creep in. RBAC solves both, provided the roles are cut cleanly.

Then there are compliance requirements. Article 32 of the GDPR requires appropriate technical and organisational measures, and these include restricting access to personal data to those who need it. Anyone who is certified to ISO/IEC 27001, or wants to be, must grant access rights traceably, review them regularly and withdraw them promptly when people leave. A documented role model makes this evidence much easier than an organically grown allocation of individual rights.

Typical roles in a shop back end

The following list shows what a role structure for a mid-sized commerce back end can look like. It is an example, not a standard, and must be adapted to the actual organisation.

• Administration: full access to configuration, user management and integrations. This role should be limited to very few people.
• Product management: edit items, categories, images and attributes, but not approve prices.
• Price and contract management: change price lists and customer-specific terms.
• Customer service: view orders and change their status, create returns, but not manage payment methods.
• Accounting: read and export payments, invoices and credit notes without changing items or prices.
• External agency: access only to content and campaigns, for a limited time.

An example from practice: Kubernetes

A well-documented example of RBAC in operation is Kubernetes. The container orchestration controls access to its API via objects of the types Role and ClusterRole, which define permissions for certain resources and verbs such as get, list or delete. Via RoleBinding and ClusterRoleBinding, these roles are bound to users, groups or service accounts. The model is purely additive: there are only allowing rules, no explicit prohibitions. Whatever is not allowed is forbidden.

The example shows two generally valid points. First, RBAC separates cleanly between the definition of a role and its assignment, so that the same role can be reused for many users. Second, the principle of default denial applies, which is also the right starting point for shop and business software.

RBAC in commerce platforms

How far a system supports roles and rights differs considerably between platforms. Some provide a fine-grained role model as standard, others are limited to a few fixed roles, and still others only offer differentiated rights in commercial editions. With open-source frameworks that work according to the open-core principle, precisely this function is a classic candidate for the paid tier, because companies reliably need it and are willing to pay for it.

A current example is MedusaJS. According to the ENTERPRISE-LICENSE.md in the repository, RBAC and the OIDC connection have been among the building blocks requiring a commercial contract since 2026, while the rest of the core is under the MIT licence. Anyone using such a framework should therefore include the question of permission management in the calculation early on and not discover it only at acceptance. You can find the context in the entry on MedusaJS.

Designing a role model: approach

A role model is rarely right first time on the drawing board. An iterative approach that starts from the actual tasks has proven itself.

1. Record tasks, not people. What activities take place in the system? "Change prices", "cancel order", "invite user". Only then are permissions derived.
2. Bundle permissions. Related activities become roles with a business name. Name them by function, not by people or projects.
3. Apply least privilege. Each role gets as few rights as possible but as many as necessary. If in doubt, start narrower and extend on request.
4. Exclude critical combinations. For sensitive processes, separation of duties is defined, for example between creating and approving credit notes.
5. Document and review assignments. Who has which role, since when and why? A regular review, for example quarterly, prevents permission creep.
6. Link to the HR process. Joining, moving and leaving trigger defined role changes, ideally automated via a central identity system.

Common mistakes and misconceptions

Role explosion. The best-known problem arises when a new role is created for every exception. After two years, there are 90 roles that hardly differ, and nobody knows any more which one applies to what. The remedy is a few clearly cut basic roles, a hierarchy and supplementary attributes for genuine context rules.

Permission creep. If employees change tasks and keep their old roles, rights accumulate. After years, a person has access to areas they will never need again. Regular reviews and a clean transfer process are the only effective measure here.

Shared admin accounts. A shared administrator account for the whole team completely undermines the role model, because actions can no longer be attributed to a person. Without personal accounts, there is no meaningful audit log.

Confusion with authentication. RBAC governs what someone may do, not who someone is. Verifying identity is the job of authentication, for example via password, multi-factor procedures or single sign-on. The two belong together but do not replace each other.

Roles as a security guarantee. A role model only protects if it is enforced everywhere. If a back end checks rights in the user interface but not in the API, restrictions can be bypassed via direct calls. Enforcement must take place on the server side.

Technical implementation

Technically, there are three common patterns. With application logic, the code itself checks whether a user has a role, usually via annotations or middleware. With a central identity provider, a token supplies the roles as claims, and the application evaluates them. With an external policy service such as Open Policy Agent or a cloud IAM solution, the decision is outsourced and made according to uniform rules.

For web applications with tokens, the second route is usual. After log-in, an identity provider issues a signed token that contains, among other things, the user's roles or groups. The application checks the signature and derives rights from it. It is important to note that roles in the token are only as current as the token itself. If rights are withdrawn, they continue to apply until the token expires, unless an additional check takes place. Short validity periods and revocation are therefore part of a robust concept.

RBAC is also widespread in databases themselves. Systems such as PostgreSQL have roles as a central concept, to which rights on tables, schemas and functions are granted. The same applies there: roles bundle rights, accounts inherit them.

Outlook

The development is moving from static roles towards context-based decisions. Zero-trust approaches require that access is not permitted solely on the basis of network position or a one-off log-in but is continuously assessed on the basis of identity, device state and risk. RBAC remains the foundation but is more often supplemented by attribute-based rules. At the same time, permission management is shifting towards automation: roles are derived from the HR system, reviews are tool-supported, and unused rights are identified automatically.

For mid-sized companies, this means one thing above all: the basics count for more than any tool. A manageable role model, personal accounts, least privilege and regular reviews bring the greatest security gain, long before complex policy engines become necessary.

Frequently asked questions about RBAC

What does RBAC mean?

RBAC stands for role-based access control. Permissions are assigned to roles, and users receive them through their role membership.

What is the difference between RBAC and ABAC?

RBAC decides on the basis of a person's role, ABAC on the basis of any attributes of user, object and situation. RBAC is easier to manage, ABAC finer-grained and more context-dependent.

How many roles make sense?

There is no fixed number. As a rule of thumb: as few as possible, as many as necessary. If new special roles keep appearing, that is a sign of role explosion and that attributes or a hierarchy would fit better.

Does a small shop need RBAC?

As long as only two or three people work in the back end, personal accounts with few rights are often enough. At the latest when external service providers, several departments or compliance requirements come into play, a real role model pays off.

Is RBAC the same as authentication?

No. Authentication clarifies who someone is. RBAC clarifies what this person may do. Both steps are necessary and are usually handled by different components.

Further sources

The fundamentals of the model are documented at the NIST Computer Security Resource Center; a general overview is provided by the Wikipedia article on role-based access control. The Kubernetes implementation is described in the official documentation.