Skip to main content

Implied Roles and Permissions

· 4 min read
Stanley Phu

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, and employee.
  • The employee role has the permission view-items.
  • The manager role has permissions edit-items and view-items.
  • The owner role has permissions add-items, delete-items, edit-items, and view-items.

With implied roles, we can implement this as such:

  • Assign the permission view-items to employee.
  • On the manager role, add the employee role as an implied role and the edit-items permission to the role.
  • On the owner role, add the manager role as an implied role and the add-items and delete-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 on items.
  • You want to create CRUD permissions for items: view-items, edit-items, create-items, and delete-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!