[CONF] Apache Syncope > [DISCUSS] Realms
Title: Message Title Francesco Chicchiricco edited a page [DISCUSS] Realms ... Table of Contents outline true style none 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). ... View page • Add comment • Like Stop watching space • Manage notifications This message was sent by Atlassian Confluence 5.8.4
[CONF] Apache Syncope > [DISCUSS] Realms
Title: Message Title Francesco Chicchiricco commented on a page Re: [DISCUSS] Realms we could have a separate section that shows how everything relates without reference to the old model? Such information is surely needed, I believe it should be found in the reference guide (as per SYNCOPE-700) as part of the Syncope data model, rather than in this page, which is instead meant for "internal" (e.g. dev) reference. Reply • Like In reply to Colm O hEigeartaigh I'd suggest to update "5 Update the User entity by" by adding that a user also has multiple references to both groups and roles, it's not really clear from the existing text. Or alternatively, we could have a separate section that shows how everything relates without reference to the old model? Stop watching space • Manage notifications This message was sent by Atlassian Confluence 5.8.4
[CONF] Apache Syncope > [DISCUSS] Realms
Title: Message Title Colm O hEigeartaigh commented on a page Re: [DISCUSS] Realms I'd suggest to update "5 Update the User entity by" by adding that a user also has multiple references to both groups and roles, it's not really clear from the existing text. Or alternatively, we could have a separate section that shows how everything relates without reference to the old model? Reply • Like Stop watching space • Manage notifications This message was sent by Atlassian Confluence 5.8.4
[CONF] Apache Syncope > [DISCUSS] Realms
Title: Message Title Francesco Chicchiricco edited a page [DISCUSS] Realms ... 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. Rename the Role entity to Group and remove inheritance; remove references to account or password policies; remove references to entitlements; adding add reference to a realm: each group of a sub- realm will also be group of its parent realmsub-realms (as group is a specialization of any objects); Rename all ROLE_* entitlements to GROUP_* Create the new Role entity, with the following characteristics: has multiple references to entitlements; has multiple reference to realms: selected entitlements will be associated to the given realms (and sub-realms). Update the User entity by adding reference to a realm: each user of a sub- realm will also be user of its parent realm.sub-realms (as user is a specialization of any objects); 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. ... 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): User U can be member of group G either if U and G are in the same realm, or G is in one of super-realms of the realm of U Any A1 can be in relationship with any A2 either if A1 and A2 are in the same realm, or A2 is in one of super-realms of the realm of A1 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. Example Let's rephrase the sample used for current security model: ... View page • Add comment • Like Stop watching space • Manage notifications This message was sent by Atlassian Confluence 5.8.4
[CONF] Apache Syncope [DISCUSS] Realms
Francesco Chicchiricco edited the page:
[DISCUSS] Realms
...
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 /usersGET /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 /usersPOST /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
