To get familiar with the authorization module and each element’s responsibility, this page will use the implementation of a RBAC(role-based-access-control) system as example.
This is a RBAC system for users to manage their projects and teams. A user can create a project and an associated team, then it becomes the project owner and other users in the team become team members. When a user wants to perform an action to the protected resource, its role and a collection of access control rules makes decision: allowed or denied.
As you can tell from the table, there are different level’s permission rules:
- class level permission: admin can view all projects.
- instance level permission: a project’s owner/team member can check its balance.
To build such a system, this is a list of what are needed and how to do it:
|WHAT ARE NEEDED||HOW TO DO|
|A way to annotate endpoints with permission rules.||Decorate your endpoints with permission metadata using
|A decision maker that processes the metadata and calls the role resolver.||Create authorizers to make decision. They process context like the metadata and the principal resolved from request, then invoke enforcer which talks to 3rd party libraries to calculate the result.|
|A role resolver to determine whether the principal have access to the resource.||Create enforcers calling 3rd party (casbin in this case) APIs to calculate the decision.|
|A 3rd party system manages the role mapping.||Leverage a casbin system to define and understand the role mapping. It consists of: 1. A model file describes the shape of request, policy, role mapping, and the decision rules. 2. Policy files contains all the policy rules.|
|A module to put all parts above together.||Mount component
The architecture diagram is: