Recently at oso, we've been spending a lot of time thinking about roles, and how they fit into our broader vision of application authorization and access control. Most people are familiar with the concept of roles, and expect them to be a part of any authorization solution. For many app developers, roles are the first, or simplest, step in implementing application authorization.
What is Role Based Access Control (RBAC)?
Roles provide a structure for assigning groups of permissions to users. RBAC, which stands for Role-Based Access Control, is a broad classification of using roles to control the access that users have to resources. Roles can vary in how they are used, and how they are implemented. Because of this, "RBAC" does not have an exact meaning, and it can be confusing and even frustrating to see it characterized as a one-size-fits-all solution.
An Overview of Common Role Patterns in Access Control Systems
We know there is no single solution for authorization, and we are intentional in crafting our opinion of best-practices. Until recently, we've hesitated to provide too strong an opinion on how to implement RBAC with oso, as we know the optimal approach is use-case dependent.
However, it can be overwhelming to make decisions about authorization system design, and it takes time to learn and understand the relevant access control patterns for your application. So, we've developed a guide for implementing various RBAC use cases with oso.
We view this guide as the first step in providing more intentional support for roles. It explains what we believe the important components of a roles system are, and how to implement them for common use cases using oso, including:
- Global roles: a single set of roles that applies to the entire application
- Roles in a multi-tenant application: roles are scoped to only apply to users and resources within a particular tenant
- Role hierarchies: more senior roles inherit permissions from less senior roles
- Resource-specific roles: roles that specifically apply to one resource or another
- Using roles with user groups: assign a role to a group of users, rather than an individual user
- Implied roles: user-role relationships are implied by the data model, rather than directly assigned
In writing the guide, we have laid the groundwork for applying the patterns it covers at the product level and building RBAC features into our libraries (more on that soon).
If you have any feedback on the roles guide or would like to share your particular roles use case, please join us on Slack, or feel free to open an issue.
