This page contains topics supporting ongoing discussion at dev@syncope.apache.org. |
Tracked as SYNCOPE-119.
Also see [DISCUSS] Dynamic Realms.
This topic dates very early in Syncope's history (the mail thread referenced in the issue mentioned above was started in 2011, even before entering the incubator).
Fundamentally, it is intended as a proper replacement for the current authorization mechanism, which is in place since almost the beginning, based on the concept of role entitlement.
The idea is to introduce the concept of realm - widely employed elsewhere as a mean to define security constraints in order to restrict access to shared resources.
before | after | description |
---|---|---|
GET /realms GET /realms/a/b | list realms starting at given root: all realms in the former case, realms rooted at /a/b in the latter case | |
POST /realms/a/b | create realm under /a/b | |
PUT /realms/a/b/c/d | update realm /a/b/c/d | |
DELETE /realms/a/b | delete realm /a/b (and all sub-realms) | |
GET /users | GET /users GET /users;realm=/a/b | list users under the given realm (e.g. assigned to given realm and related sub-realms): all users in the former case, users in realm /a/b (all all sub-realms) in the latter case |
POST /users | POST /users POST /users?realm=/a/b | create user under the given realm: root realm in the former case, /a/b in the latter case |
PUT /users/{userId}?realm=/a/b | move user with id {userId} under realm /a/b | |
GET /users/search | GET /users/search GET /users/search;realm=/a/b | search users under the given realm: root realm in the former case, /a/b in the latter case |
GET /roles | GET /groups GET /groups;realm=/a/b | see users |
POST /roles | POST /groups | see users |
PUT /groups/{groupId}?realm=/a/b | move group with id {groupId} under realm /a/b | |
GET /roles/search | GET /groups/search GET /groups/search;realm=/a/b | see users |
GET /roles/{roleId}/parent | ||
GET /roles/{roleId}/children |
This is a direct replacement of current security model.
The idea is that any user U assigned to a role R, which provides entitlements E1...En for realms Re1...Rek can exercise Ei on entities (users or groups, depending on the type of Ei) under any Rej or related sub-realms.
About group membership and any relationships (see the related discuss page for details):
The rationale behind such conditions is to allow the definition of common groups and any objects (to enter in relationship with) at the topmost position in the realm tree, so that they can be shared by various realm sub-trees.
Let's rephrase the sample used for current security model:
Let's suppose that we want to implement the following scenario:
Administrator A can create users under realm R5 but not under realm R7, administrator B can update users under realm R6 and R8, administrator C can update groups under realm R8.
As default, Syncope will have defined the following entitlements, among others:
Here it follows how entitlements should be assigned (via roles) to administrators in order to implement the scenario above: