THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
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