THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| 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 | |
| GET /realms/a/b/c | read realm /a/b/c | |
| 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 /rolesgroups GET /rolesgroups;realm=/a/b | see users |
| POST /roles | POST /rolesgroups | see users |
| PUT /rolesgroups/{roleIdgroupId}?realm=/a/b | move role grpup with id {roleIdgroupId} under realm /a/b | |
| GET /roles/search | GET /rolesgroups/search GET /rolesgroups/search;realm=/a/b | see users |
| GET /roles/{roleId}/parent | ||
| GET /roles/{roleId}/children |
...
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 rolesgroups, depending on the type of Ei) under any Rej or related sub-realms.
...
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 roles groups under realm R8.
As default, Syncope will have defined the following entitlements, among others:
- USER_CREATE, USER_UPDATE, ROLEGROUP_UPDATE
Here it follows how entitlements should be assigned (via roles) to administrators in order to implement the scenario above:
- A: USER_CREATE on R5
- B: USER_UPDATE on R6 and R8
- C: ROLEGROUP_UPDATE on R8
...
- R8
...
- D: ROLE_READ + ROLE_CREATE + ROLE_UPDATE + ROLE_DELETE only on role R (not the whole realm R8)