Implied Roles and Permissions
Building and maintaining a role-based access control (RBAC) model at a growing company can be a challenge as your application evolves with continually changing product requirements. As requirements and features are updated, your access model needs to keep up. Today, we're excited to introduce a new concept and features to help you manage your RBAC model with less complexity: implied roles and permissions.
What is it?
Many RBAC models involve some sort of inheritance, where an admin
role may have all the permissions of a lesser role plus more admin-specific permissions. This can involve duplication of permission assignments across roles and quickly turn your roles and permissions into a complex mess that's difficult to manage.
We've eliminated the need for this duplication and made it simpler to manage complex RBAC models via API or Dashboard with the concept of implied roles and permissions. With implied roles and permissions, you can define a role or permission that will automatically be implied when a user is assigned a particular role or permission. For example, a manager
and basic
role can be implied by the admin
role so any user with the admin
role will automatically be granted the capabilities of both the manager
and basic
roles.
Implied Roles
Take the following example of an authorization model:
- You have three roles:
owner
,manager
, andemployee
. - The
employee
role has the permissionview-items
. - The
manager
role has permissionsedit-items
andview-items
. - The
owner
role has permissionsadd-items
,delete-items
,edit-items
, andview-items
.
With implied roles, we can implement this as such:
- Assign the permission
view-items
toemployee
. - On the
manager
role, add theemployee
role as an implied role and theedit-items
permission to the role. - On the
owner
role, add themanager
role as an implied role and theadd-items
anddelete-items
permissions to the role.
As we add new features to our application and grant additional permissions to each role, we won't need to worry about keeping the other roles in sync because it'll happen automatically. If we decide later on that we now want managers to also be able to delete items as well, we can quickly modify our access model by removing the permission from the owner
role and add it to the manager
role. Now the manager
role will have the delete-items
permission while the owner
role will inherit the permission through the implied role.
Implied Permissions
Let's say we want to implement the following:
- Your application has an
items
resource along with an API that supports CRUD actions onitems
. - You want to create CRUD permissions for
items
:view-items
,edit-items
,create-items
, anddelete-items
. - You want to create a single permission
items
that can grant all of the CRUD permissions.
With implied permissions, you can create an items
permission and add all the CRUD permissions as implied permissions of items
.
This allows us to grant any users or roles the one items
permission rather than having to duplicate all permission assignments across users/roles. If you later decide to add a new permission, like buy-items
, you can then add buy-items
as another implied permission of items
which will automatically grant the new permission to any user with the items
permission.
How can I use it?
New and existing Warrant customers can start using implied roles and permissions right away. To get started, refer to our docs to add an implied role or add an implied permission.
Join us on Slack to give us feedback on implied roles and permissions, and keep up with the latest on Warrant!