Design the Service-Specific Permissions System #6

New issue

Closed

opened 2025-04-22 23:13:30 +00:00 by abed.alrahman · 2 comments

abed.alrahman commented

2025-04-22 23:13:30 +00:00

Member

Ref epic: #13

Goal: Design a flexible system that allows individual microservices to define and manage their own specific permissions (e.g., "can_edit_widget", "can_view_special_report") while using the central user identity (users, groups) provided by Keycloak via injected headers.

Description:
This ticket will produce a design document describing the service-specific permission system. With this system, a microservice can define its own permissions using the users from Keycloak. The document needs to consider how the new system works with the existing authentication system (where auth-service injects user metadata headers) and how requests will be handled.

What needs to be designed / addressed:

Permission Definition: How will a microservice define its specific permissions (e.g., simple string names, structured objects)?
Permission Storage: Where will these service-specific permissions and the rules associating them with users/groups be stored?
    Option A: Within each microservice (e.g., its database, configuration).
    Option B: Centrally (e.g., extending Keycloak, using a dedicated permission service).
    Analyze pros and cons of decentralised vs. centralised storage in our context.
Permission Association: How will permissions be granted or associated with users or groups from Keycloak? (e.g., via an API within the microservice, configuration files, a central UI).
Enforcement Workflow: Detail the process for checking these permissions. Confirm that this check happens inside the microservice after it receives the request with the injected X-User-* headers (like X-User-Id, X-User-Groups).
Interaction with Existing Auth: Clarify how this fine-grained check within the service complements the initial coarse-grained authentication/authorization performed by Traefik and auth-service.
Flexibility: How will the design accommodate different microservices having potentially very different and complex permission requirements?
Data Flow: Provide sequence diagrams illustrating the request flow, highlighting where the user context is injected and where the service-specific permission check occurs.
Recommendation: Propose a recommended approach based on the analysis.

Deliverables:

A Design Document detailing the proposed system for service-specific permissions, covering definition, storage, association, enforcement workflow, and interaction with the existing architecture.

Ref epic: [#13](https://git.cleverthis.com/clevermicro/user-management/issues/13) Goal: Design a flexible system that allows individual microservices to define and manage their own specific permissions (e.g., "can_edit_widget", "can_view_special_report") while using the central user identity (users, groups) provided by Keycloak via injected headers. Description: This ticket will produce a design document describing the service-specific permission system. With this system, a microservice can define its own permissions using the users from Keycloak. The document needs to consider how the new system works with the existing authentication system (where auth-service injects user metadata headers) and how requests will be handled. What needs to be designed / addressed: Permission Definition: How will a microservice define its specific permissions (e.g., simple string names, structured objects)? Permission Storage: Where will these service-specific permissions and the rules associating them with users/groups be stored? Option A: Within each microservice (e.g., its database, configuration). Option B: Centrally (e.g., extending Keycloak, using a dedicated permission service). Analyze pros and cons of decentralised vs. centralised storage in our context. Permission Association: How will permissions be granted or associated with users or groups from Keycloak? (e.g., via an API within the microservice, configuration files, a central UI). Enforcement Workflow: Detail the process for checking these permissions. Confirm that this check happens inside the microservice after it receives the request with the injected X-User-* headers (like X-User-Id, X-User-Groups). Interaction with Existing Auth: Clarify how this fine-grained check within the service complements the initial coarse-grained authentication/authorization performed by Traefik and auth-service. Flexibility: How will the design accommodate different microservices having potentially very different and complex permission requirements? Data Flow: Provide sequence diagrams illustrating the request flow, highlighting where the user context is injected and where the service-specific permission check occurs. Recommendation: Propose a recommended approach based on the analysis. Deliverables: A Design Document detailing the proposed system for service-specific permissions, covering definition, storage, association, enforcement workflow, and interaction with the existing architecture.

Rows
Columns