THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
This page contains topics supporting ongoing discussion at dev@syncope.apache.org.
Tracked as SYNCOPE-119.
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'.
Entity changes
- Create the new Realm entity, with the following characteristics:
- has a name and a parent realm (except for the pre-defined root realm, which is named '/');
- will be either leaf or root of a sub-tree of realms;
- is uniquely identified by the path from root realm, e.g. /a/b/c identifies the sub-realm 'c' in the sub-tree rooted at 'b', having in turn 'a' as parent realm, directly under root realm;
- optionally refers to account or password policies.
- Update the Role entity by
- removing inheritance;
- removing references to account or password policies;
- adding reference to a realm: each role of a sub-realm will also be role of its parent realm;
- adding multiple reference to realms: selected entitlements will be associated to the given realms.
- Update the User entity by
- adding reference to a realm: each role of a sub-realm will also be user of its parent realm.
- There won't be global account or password policies any more, but simply account / password policies for the root realm; account and password policies can be optionally defined for a given sub-realm: in this case the resulting policy to be applied will be the composition of all defined policies for ancestor realms up to root realm.
REST API changes
| 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/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/a/b | create user under the given realm: root realm in the former case, /a/b in the latter case |
| PUT /users/a/b/{userId} | move user with id {userId} under realm /a/b | |
| GET /users/search | GET /users/search GET /users/a/b/search | search users under the given realm: root realm in the former case, /a/b in the latter case |
| GET /roles | GET /roles GET /roles/a/b | see users |
| POST /roles | POST /roles | see users |
| PUT /roles/a/b/{roleId} | move role with id {roleId} under realm /a/b | |
| GET /roles/search | GET /roles/search GET /roles/a/b/search | see users |
| GET /roles/{roleId}/parent | ||
| GET /roles/{roleId}/children |
New security model
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 roles, depending on the type of Ei) under any Rej or related sub-realms.
Example
