Implement the Service-Specific Permissions #7

New issue

Closed

opened 2025-04-22 23:21:48 +00:00 by abed.alrahman · 3 comments

abed.alrahman commented

2025-04-22 23:21:48 +00:00

Member

Ref epic: #13

Goal: Implement the service-specific permission system based on the approach chosen in the design document #6, enabling microservices to enforce fine-grained access control using their own rules.

Description:
Based on the result of the design ticket, this ticket will implement the system. Sub-tickets might be needed for changes in other components, like amq-adapter (if applicable), and/or auth-service, etc., depending on the chosen design.

Prerequisite:

Completion of the "Design the Service-Specific Permissions System" ticket #6.
The system where auth-service injects X-User-* headers into requests is operational #5.

What needs to be done (will vary based on design):

Implement Core Mechanism: Build the foundational elements defined in the design:
    If central storage/service was chosen: Build/configure that service or Keycloak components.
    If permissions are stored within microservices: Provide clear guidelines, examples (e.g., DB schema examples), or potentially helper libraries.
Develop Service Integration Patterns:
    Provide clear examples, documentation, and potentially shared libraries/middleware for microservice developers showing how to:
        Read the injected X-User-* headers.
        Implement the logic to check if the user/group has the required service-specific permission based on the chosen storage/association method.
        Return a 403 Forbidden HTTP status code if the permission check fails.
        Define and manage their service's permissions and assignments (e.g., example admin API endpoints or configuration methods).
Implement Supporting Changes (If Required):
    Make necessary modifications to auth-service or other shared components only if the chosen design requires them to play an active role in handling service-specific permissions (beyond just injecting the base user identity).
Testing: Develop and execute tests to validate the system, potentially using one or two example microservices modified to use the new permission checking pattern.
Documentation: Create comprehensive documentation for microservice developers explaining how to integrate with the new system to manage and enforce their service-specific permissions.

(Note: This implementation might be broken down into further sub-tickets once the design is finalized, focusing on specific components like shared libraries, Keycloak configuration, or example service implementations.)*

Deliverables:

Implemented core components (if any central parts were designed).
Shared libraries, code examples, and patterns for microservice implementation.
Developer documentation on using the service-specific permission system.
Test results demonstrating the system works as designed.// New ticket, we may make a fake microservice for testing.

Ref epic: [#13](https://git.cleverthis.com/clevermicro/user-management/issues/13) Goal: Implement the service-specific permission system based on the approach chosen in the design document #6, enabling microservices to enforce fine-grained access control using their own rules. Description: Based on the result of the design ticket, this ticket will implement the system. Sub-tickets might be needed for changes in other components, like amq-adapter (if applicable), and/or auth-service, etc., depending on the chosen design. Prerequisite: Completion of the "Design the Service-Specific Permissions System" ticket #6. The system where auth-service injects X-User-* headers into requests is operational #5. What needs to be done (will vary based on design): Implement Core Mechanism: Build the foundational elements defined in the design: If central storage/service was chosen: Build/configure that service or Keycloak components. If permissions are stored within microservices: Provide clear guidelines, examples (e.g., DB schema examples), or potentially helper libraries. Develop Service Integration Patterns: Provide clear examples, documentation, and potentially shared libraries/middleware for microservice developers showing how to: Read the injected X-User-* headers. Implement the logic to check if the user/group has the required service-specific permission based on the chosen storage/association method. Return a 403 Forbidden HTTP status code if the permission check fails. Define and manage their service's permissions and assignments (e.g., example admin API endpoints or configuration methods). Implement Supporting Changes (If Required): Make necessary modifications to auth-service or other shared components only if the chosen design requires them to play an active role in handling service-specific permissions (beyond just injecting the base user identity). Testing: Develop and execute tests to validate the system, potentially using one or two example microservices modified to use the new permission checking pattern. Documentation: Create comprehensive documentation for microservice developers explaining how to integrate with the new system to manage and enforce their service-specific permissions. (Note: This implementation might be broken down into further sub-tickets once the design is finalized, focusing on specific components like shared libraries, Keycloak configuration, or example service implementations.)* Deliverables: Implemented core components (if any central parts were designed). Shared libraries, code examples, and patterns for microservice implementation. Developer documentation on using the service-specific permission system. Test results demonstrating the system works as designed.// New ticket, we may make a fake microservice for testing.

Rows
Columns