Page Contents

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.

User scenario

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.

User scenario

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:

A way to annotate endpoints with permission rules. Decorate your endpoints with permission metadata using @authorize().
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 @loopback/authorization.

The architecture diagram is:

RBAC architecture


The example is created in repository access-control-migration, and a tutorial of building it from scratch can be found in access control example migration.