I am reaching out to seek your guidance on a critical aspect of resource, scope, and permission management in Keycloak. I will break down the context and challenges we are currently facing:
For our use case we have n merchants and each merchants can have m users. we want to manage role creation and permission assignment. Here merchant will have the capability to create any no. of role lets say at max 20 roles per merchant , and we can have 3lakh merchant approx.
Core Concepts
Resource:
- Represents objects we want to protect, like products (e.g., PG, PAYOUT, VRS), features (e.g., PG-TRANSACTION, PAYOUT-BENEFICIARY), or subfeatures.
Scope:
- Denotes actions applicable to a resource, including common actions (view, edit, delete) and specific actions like initiating refunds or creating orders.
Permission:
- Links a protected object (resource) with policies to determine access.
- Example: X (user, role, or group) can do Y (action) on resource Z (“/accounts”).
Setting Scope-Based Permissions
In Keycloak, we adopt a scope-based permission model where one permission combines one resource and one scope.
- Example: “PG_Order_create_permission” signifies permission for creating PG_ORDER.
Roles and Policies in Keycloak
Roles define access levels and permissions, with two main types:
- Realm Roles: Apply globally across all clients within a realm (e.g., “admin,” “user,” “manager”).
- Client Roles: Specific to individual client applications (e.g., “post,” “comment,” “like”).
Current Challenges and Approaches
Approach 1: 1 Policy per Role
- Description: Creating a policy for each role.
- Problem: The substantial user base (3 lakh merchants) leads to a vast number of roles and policies, causing UI performance issues.
- Specific Issue: The evaluation API struggles, having to assess all 30 lakh policies for each user, becoming a performance bottleneck.
Approach 2: 1 Policy per Permission
- Description: Creating a policy for each permission.
- Problem: Reduces the number of policies but introduces challenges when evaluating policies for users, potentially resulting in 30 lakh roles attaching to a single policy.
- Elaboration: Fetching a policy associated with a specific permission leads to fetching all roles connected to that policy (up to 30 lakh roles), impacting system performance.
New Approach: Separate Client for Each Merchant
- Description: Creating a separate client for each merchant and managing resource-scope within that client.
- Issues: KEYCLOAK-14329
I am reaching out to the community for advice, insights, and potential solutions. If anyone has encountered similar scenarios, has ideas for optimizing performance, or can provide guidance on the new approach,