ROLE BASED ACCESS CONTROL (RBAC) DESIGN FOR MICROSERVICES

This article extends the principles and design of API gateway discussed in the article here API Gateway.

RBAC stands for Role Based Access Control. Its an approach to restricting system access to authorized users by using a set of permissions and grants. This approach intends to make the governance of controls between users, vendors and customers efficient.

The model is built on a hierarchical relational manner with the Role group forming the top level. Permissions required to perform a certain role ( example: vendor, user, subscriber, admin) etc. are grouped under appropriate roles. A role group can contain one or more roles under it. This mean that, role-groups inherit combined permissions of all roles under it. Permissions can be further controller by modules if needed.

RBAC SYSTEM DESIGN FOR MICRO-SERVICES

Fig 1: RBAC Design For MicroServices

APPROACH

1. A dedicated set of database tables to hold the role groups, roles and permissions relationships. One service will be responsible for retrieving permissions for a given list of role groups.

Fig 2: RBAC DB Schema Design

2. Which user gets what role group business logic will be encapsulated in the Auth Server. User information will be evaluated during login to derive the role group that needs to be assigned. The role group will be attached to the tokens generated as part of OAuth2 process.

3. The API gateway validates the user tokens and invokes the underlying micro-service API's. The API gateway will have a local cache of map of role groups and associated permission. This cache will be periodically refresh by reaching out to Auth Server in the background. This refresh ensures that the API gateway always has access to any permission changes made by the RBAC Admin in the metadata system.

4. The API gateway lookup the user token, extracts the user details and assigned role groups. It then derives the associated permissions from the cached data and the sends down the permission to the micro-services as part of enriched request headers.

5. All microservices can use a common library to evaluate if "READ" or "EXECUTE" permissions are available to perform a certain action. The presence or absence of the permission will control the API response behavior.

6. The clients can cache the list of permissions available to the user to control UI treatment and behavior. Permission SYNC between the server and the client can be triggered when the HASH of permissions cached on the client doing login flow turns out to be different from the permission HASH that is sent by the clients as part of every API response.

Below are some example metadata for the RBAC system.

Fig 3: Example Data For RBAC