3 Essential RBAC Best Practices

Defining Role-Based Access Control

Consider the Three Primary Rules of RBAC

  1. Role assignment: A subject can exercise a permission only if the subject has selected or been assigned a role.
  2. Role authorization: A subject’s active role must be authorized for the subject. With rule 1 above, this rule ensures that users can take on only roles for which they are authorized.
  3. Permission authorization: A subject can exercise a permission only if the permission is authorized for the subject’s active role. With rules 1 and 2, this rule ensures that users can exercise only permissions for which they are authorized.

Why Create Your Own RBAC System?

  1. The existing RBAC system appears to be insufficient for the current use case. Alternatively, the existing RBAC system seems overly complex or overengineered for a simple use case.
  2. The team feels a DIY solution will take less time during a prototyping or MVP stage than integrating with a third-party solution.
  3. Existing permission systems tie the application to a particular platform or cloud vendor. It may not make sense to implement a solution in one platform if you will soon be moving to a different platform.

What Best Practices Should You Follow for RBAC?

1. Build Your Authorization Model for Evolution

  1. First, take inventory of the business. What resources exist, and who has permission to read, write, delete, and/or act upon those resources in some way? Consider what bottlenecks inappropriate permissions may create when a workflow is held up because permissions are too restricted. Learn what happens when a role only has a few people in it and they’re all out of the office. How do you handle delegations? Furthermore, what happens when someone has too much privilege within the system? You should be aware of how these permissions affect the business from a process and monetary standpoint.
  2. Start with a coarse-grained model. Use as few roles, resources, and permissions as needed. Then gradually build in complexity as requirements and understanding of permissions change. If you start with too many fine-grained roles and permissions, you’ll overcomplicate the model. And oftentimes this requires redesigning the model once nuances of permissions are more fully understood. Alternatively, if redesigning doesn’t happen, overly complicated and incorrect models can lead to a maintenance nightmare, and admins default to “give the new person all these roles, because we can’t figure out which ones they really need.”
  3. Build roles in a hierarchy so that maintenance carries less of a burden. With the proper hierarchy, you can easily control permissions for all users and for those with specialized roles. For example, all users may be able to access their profile and edit certain characteristics. There’s no need to build that for each and every role.
  4. Use the principle of least privilege. When designing roles, ensure that users will have the permission needed to do their job, but no more. This will take some tweaking as sometimes, even when interviewing business folks and auditing processes, we’ll make incorrect assumptions about what level of access particular roles need, until reality hits.

2. Design and Implement Your System for Modification

  1. Use a simple and reusable API. Your RBAC must answer this question: is the current user allowed to perform this action on this resource? Adding more complexity than that will make moving to a third-party system more difficult in the future.
  2. Decouple your application logic from your RBAC system. Here, you’ll want to consider separation of concerns so that you can independently change your application and your authorization system. For many, that means creating a generic wrapper around authorization so that replacing the system in the future will only require changes in one place and not every place that you check permissions.
  3. Keep authorization checks as close to the edge or API controller as possible. This will reduce overly complicated business logic that relies on permission checks in determining flow. It can be a sign of poor design if permission checks litter your application logic and increase the complexity of one API call or process. So if you’re finding that permission checks are used to control programming flow within an API, consider whether a separate endpoint is warranted for certain business functions.
  4. Don’t build everything at once. For the MVP of RBAC, consider skipping the UI and making changes to the authorization structure through scripts or other auditable methods. Oftentimes, the UI for managing roles and user assignments takes a long time to perfect. If your user base is small, look at ways to add functionality iteratively while still keeping application resources secure. And before building a UI, consider whether that’s a good use of your engineering time. Building systems that aren’t differentiators to your primary business, especially when at a growth stage, can cause a tremendous loss in productivity.

3. Provide Auditable RBAC Data and Governance

  1. Include auditability from day one. That doesn’t mean that the sleekest UI with ad hoc reporting needs to be complete on day one. But you need a way to validate who added or removed which users to and from what roles.
  2. Resources need their own audit trail. It’s not enough that your system allows the right people to perform the right actions. You’ll also need to tie that in so that you can see who created, modified, or deleted resources.
  3. Make adding and removing users and roles easy and fast. In case of breaches or other scenarios where access must be removed quickly, you don’t want to find that you have multiple permission systems that must all be updated across the company. Though this conflicts with creating an MVP for your RBAC system, you’ll run into this need sooner rather than later and should plan accordingly. Also, you’ll need to consider integration with other systems in your organization to speed up onboarding, off-boarding, and role changes.




Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


Welcome to modern authorization.