Role Based Access Control(RBAC) is one of the most commonly used methods for defining what a user can and cannot access in your application. As its name describes RBAC is based on Roles that describe the different rights. The users are assigned roles and that is how your application will know what a user can and cannot do.
If you have built an application you most surely have stumbled upon the concept when you want to limit parts of the application to specific users, or perhaps allow some users to only view information and others edit it.
When developing an application, RBAC affects both the backend and frontend. You will need to limit all your backend calls to specific roles to prevent unauthorised data access. On the frontend, different roles will have access to different parts and features of your app.
Many descriptions of designing roles are explained from the perspective of an organisation using your application where roles are based on different departments. Designing your roles like this will end up in a mess since the many organisations using your app will definitely have different department names and definitions. The way to think about a role is what it is supposed to do in your app.
Let’s define some roles for a support system where you have Consumers logging in and sending in requests and Support agents helping the Consumers. Consumers should only see their own tickets and not change their status and Support agents should see all tickets and be able to change their status. The roles can be derived from our description. Consumer and Support Agent. Apart from definite roles, you will also need to define permissions.
Consumer:
:send-ticket
:see-own-tickets
Support agent
:see-all-tickets :change-ticket-status
When coding, RBAC will always exist in your day-to-day software development. When changing your code you will need to ensure that the right roles are defined for different parts of your app and make sure that no critical part is wide open to everyone. To avoid a section of your application being wide open you should use a default deny approach.
It is important that both the dev team and product team have an overview of all roles and where in the application they are assigned and that this is tested and your testing data must reflect the different roles of your application. Make sure that you test what parts a role should access and also what parts it should not access.