Design Permission System for Endpoint Access Control #2
Labels
No labels
Blocked
Bounty
$100
Bounty
$1000
Bounty
$10000
Bounty
$20
Bounty
$2000
Bounty
$250
Bounty
$50
Bounty
$500
Bounty
$5000
Bounty
$750
MoSCoW
Could have
MoSCoW
Must have
MoSCoW
Should have
Needs feedback
Points
1
Points
13
Points
2
Points
21
Points
3
Points
34
Points
5
Points
55
Points
8
Points
88
Priority
Backlog
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Signed-off: Owner
Signed-off: Scrum Master
Signed-off: Tech Lead
Spike
State
Completed
State
Duplicate
State
In Progress
State
In Review
State
Paused
State
Unverified
State
Verified
State
Wont Do
Type
Bug
Type
Discussion
Type
Documentation
Type
Epic
Type
Feature
Type
Legendary
Type
Support
Type
Task
Type
Testing
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Blocks
You do not have permission to read 1 dependency
Reference: clevermicro/user-management#2
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Ref epic: #13
Goal: Design a system that allows individual backend services to define which users or groups (from Keycloak) can access their specific REST endpoints, and have this access enforced centrally before requests reach the service.
Background:
We need finer control over who can access specific API endpoints. The requirement is that the service owning the endpoint should ultimately define the access rules (e.g., "Only users in the 'admins' group can call POST /users"). This system needs to integrate with Keycloak for user/group information and likely with Traefik (potentially via the auth-service) for enforcement.
What needs to be done:
Deliverables:
It is important for this feature that we do a model design and schema implementation as first, before hooking it with Traefik API Gateway or AMQ Adapter. Things that need to be designed:
Next we need to determine the maintenance of the privilege matrix or access control list (ACL). Who is responsible for determining the privileges? Is it a Service developers? Management? How do we represent the ACL in both human readable form so it is suitable for review and human amendment and also in machine readable form, so we can feed the entire ACL to the security schema and synchronize the new ACL with existing ACL? Implement the sync function.
What is the user privilege granting process? Who approves the grant request? Can some requests be auto-approved? Do we implement a time limited privilege escalation? (e.g. user can request a sudo privilege for an 1 hr to perform a release or some privilege action?) The privilege is than auto-removed after the period elapse or user can give up the privilege.
Following on discussion on the questions raised above, I have created the following design proposal:
https://docs.cleverthis.com/en/architecture/microservices/feature-discussion/user-privilege-design
@CoreRasurae
@freemo
please feel free to review/comment
Here is the design document for Access control using Keycloak capabilities:
https://docs.cleverthis.com/en/architecture/microservices/feature-discussion/Endpoint-Access-Control-using-Keycloak
It shows how the auth-service endpoint will act as a middleware between Traefik and Keycloak to authenticate and authorize users' requests.
A new version for ACL using Keycloak, in this version, there are two main additions:
Here is the link for the document v1.1
https://docs.cleverthis.com/en/architecture/microservices/feature-discussion/endpoint-keycloakv2
Here is a quick guideline document.
This guide explains how to configure your service in Keycloak so its API endpoints can be protected by our central auth-service. The auth-service checks if a user has the correct "Client Role" in Keycloak before allowing access to an endpoint.
https://docs.cleverthis.com/en/user_pages/abed_alrahman/permission_keycloak