Role-based access control in Microservices - Architecture Diagram

System Overview - Role-based access control

This system manages user permissions based on their roles. It ensures users can only access resources allowed by their assigned roles. The system must be scalable, secure, and support multiple microservices enforcing access control consistently.

Architecture Diagram

User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  v
+----------------+       +---------------------+
| Auth Service   |<----->| Role Management      |
| (Token Issuer) |       | Service              |
+----------------+       +---------------------+
        |
        v
+----------------+
| Microservice A |
+----------------+
        |
        v
+----------------+
| Database       |
+----------------+

Cache (Redis) connected to Auth Service and Role Management Service for fast role lookup

Components

User

actor

End user who sends requests with credentials

Load Balancer

load_balancer

Distributes incoming requests evenly to API Gateway instances

API Gateway

api_gateway

Entry point that routes requests to appropriate microservices and enforces initial authentication

Auth Service

service

Authenticates users and issues tokens containing role claims

Role Management Service

service

Manages roles and permissions, provides role data to other services

Microservice A

service

Business logic service that enforces role-based access control on requests

Database

database

Stores user data, roles, permissions, and application data

Cache

cache

Stores role and permission data for fast access to reduce database load

Request Flow - 18 Hops

User → Load Balancer

Load Balancer → API Gateway

API Gateway → Auth Service

Auth Service → Cache

Cache → Auth Service

Auth Service → Role Management Service

Role Management Service → Database

Database → Role Management Service

Role Management Service → Cache

Role Management Service → Auth Service

Auth Service → API Gateway

API Gateway → Microservice A

Microservice A → Auth Service

Microservice A → Database

Database → Microservice A

Microservice A → API Gateway

API Gateway → Load Balancer

Load Balancer → User

Failure Scenario

Component Fails:Cache

Impact:Role and permission lookups become slower as requests go directly to the database, increasing latency and load on the database.

Mitigation:System continues to function correctly by querying Role Management Service and database. Cache can be restored or replaced without downtime.

Architecture Quiz - 3 Questions

Which component is responsible for issuing tokens containing user roles?

A API Gateway

B Auth Service

C Role Management Service

D Load Balancer

Design Principle

This architecture demonstrates separation of concerns by isolating authentication, role management, and business logic into distinct microservices. It uses caching to improve performance and scalability while ensuring secure role-based access control across services.

Practice

1. What is the main purpose of Role-Based Access Control (RBAC) in microservices?

easy

A. To encrypt data between microservices

B. To monitor network traffic for security threats

C. To assign permissions to users based on their roles

D. To deploy microservices automatically

Solution

1. Step 1: Understand RBAC concept

   RBAC assigns permissions to users based on their roles, simplifying access management.

2. Step 2: Identify RBAC purpose in microservices

   In microservices, RBAC controls who can access which service or API based on roles.

3. Final Answer:

   To assign permissions to users based on their roles -> Option C

4. Quick Check:

   RBAC = Role-based permission assignment [OK]

Hint: RBAC controls access by roles, not by encryption or deployment [OK]

Common Mistakes:

• Confusing RBAC with encryption
• Thinking RBAC monitors network traffic
• Assuming RBAC automates deployment

2. Which of the following is the correct way to represent a role in an RBAC system for microservices?

easy

A. {"service": "admin", "level": 5}

B. {"role": "admin", "permissions": ["read", "write"]}

C. {"user": "admin", "access": "full"}

D. {"permission": "admin", "role": "read"}

Solution

1. Step 1: Identify correct role structure

   A role should have a name and a list of permissions it grants.

2. Step 2: Match structure to options

   {"role": "admin", "permissions": ["read", "write"]} correctly shows a role with permissions as a list, matching RBAC design.

3. Final Answer:

   {"role": "admin", "permissions": ["read", "write"]} -> Option B

4. Quick Check:

   Role = name + permissions list [OK]

Hint: Roles have permissions list; user or service keys are incorrect here [OK]

Common Mistakes:

• Confusing user with role
• Using 'permission' as role name
• Assigning access level instead of permissions

3. Given this simplified RBAC check in a microservice:

def can_access(user_role, action):
    permissions = {
        "user": ["read"],
        "admin": ["read", "write", "delete"]
    }
    return action in permissions.get(user_role, [])

print(can_access("user", "delete"))

What is the output?

medium

A. None

B. True

C. KeyError

D. False

Solution

1. Step 1: Understand permissions dictionary

   The "user" role has only ["read"] permission, no "delete".

2. Step 2: Check if "delete" is in user permissions

   Since "delete" is not in ["read"], the function returns False.

3. Final Answer:

   False -> Option D

4. Quick Check:

   "delete" in user permissions = False [OK]

Hint: Check if action is in role's permission list [OK]

Common Mistakes:

• Assuming all actions allowed for user
• Expecting KeyError for missing keys
• Confusing True/False return values

4. A microservice uses this RBAC check:

def check_access(role, permission):
    role_permissions = {
        "editor": ["read", "write"],
        "viewer": ["read"]
    }
    return permission in role_permissions[role]

print(check_access("admin", "write"))

What is the problem and how to fix it?

medium

A. KeyError occurs; fix by using role_permissions.get(role, [])

B. SyntaxError due to missing colon; add colon after function

C. Returns False incorrectly; add "admin" role to dictionary

D. Returns True incorrectly; remove "write" from editor permissions

Solution

1. Step 1: Identify error cause

   Accessing role_permissions["admin"] causes KeyError because "admin" key is missing.

2. Step 2: Fix by safe dictionary access

   Use role_permissions.get(role, []) to return empty list if role missing, avoiding error.

3. Final Answer:

   KeyError occurs; fix by using role_permissions.get(role, []) -> Option A

4. Quick Check:

   Missing key causes KeyError; get() avoids it [OK]

Hint: Use get() to avoid KeyError on missing roles [OK]

Common Mistakes:

• Adding roles without permissions
• Confusing syntax errors with runtime errors
• Ignoring missing key errors

5. In a microservices architecture, where is the best place to enforce RBAC to ensure scalability and security?

hard

A. At the API Gateway before requests reach microservices

B. On the client side before sending requests

C. Only in the database layer with SQL permissions

D. Inside each microservice individually

Solution

1. Step 1: Consider scalability and security needs

   Enforcing RBAC centrally avoids duplication and reduces risk of inconsistent checks.

2. Step 2: Identify best enforcement point

   API Gateway is the central entry point, ideal for RBAC enforcement before microservices.

3. Final Answer:

   At the API Gateway before requests reach microservices -> Option A

4. Quick Check:

   Central RBAC at API Gateway = scalable & secure [OK]

Hint: Enforce RBAC centrally at API Gateway for best results [OK]

Common Mistakes:

• Enforcing RBAC only in microservices causes duplication
• Relying on client-side enforcement is insecure
• Using database permissions alone misses API-level control