Hi Salim,
see my replies embedded below.
Regards.
On 07/08/2013 13:36, Salim Boulkour wrote:
Hi everyone,
I'm currently taking a look at the inner data model of Syncope, and
what we can do with it.
S
o far I understood the way to extend user attributes, the difference
between plain/derived/virtual attributes, resources mappings, Syncope
entitlements, password policies etc.
W
hen it comes to roles, there are few questions I couldn't answer to
while reading the wiki :
* What is the purpose of the role tree ? Is it only as a tidy
presentation purpose ? Or is there a feature behing like scoping
admin rights on sub-parts of the roles set ?
A role can inherit some aspects from its parent role, if checked:
* owner
* attributes
* derived attributes
* virtual attributes
* password policy
* account policy
* Can we create role inclusions ? Like giving role A to a user, also
gives the user roles S and T ?
No: if you want to accomplish this, you'd probably need (depending on
your scenario) to provide some custom action to be attached to the
workflow definition. You can do this
* Can we specify parameters or some kind of attribute to a role in
order to specialized it ?
o As an example can I have a unique "Buyer" role, with a
parameters that sets his max $amount and another that sets his
geographic area ?
Roles can have attributes (normal, derived and virtual) as users, so you
can define any kind of role schema and then provide values for such
attributes.
Referring to your example above, I would define a couple of role schema
(see how to do this via the admin console [1]):
1. amount (Double)
2. geoArea (Enum, with enumeration values for all area you would like
to manage)
o Then I would like to have actions based on those parameters :
+ geographic areas may have differents ADs/LDAP so I'd like
to provision different resources regarding the geographic
parameter
+ max $amount would also be useful to give different
entitlements in the resource (LDAP groups for example)
In order to implement such custom logic you would likely need to have
your own SyncActions class [2].
* Are the owner fields of a role attached to Syncope entitlements in
a way ? The owners can update/delete the role ?
Of course: see [3].
* I couldn't test that case as Syncope crashes when my owner tries
to read the role (see attached file "/*Alert:*//**Error while
contacting Syncope core/"). Error in logs :
*org.apache.catalina.core.StandardWrapperValve* invoke SEVERE:
Servlet.service() for servlet [syncope-core-rest] in context with path
[/syncope] threw exception [Request processing failed; nested
exception is
*org.apache.syncope.core.rest.controller.UnauthorizedRoleException*:
Missing entitlement for role(s) [1]] with root
causeorg.apache.syncope.core.rest.controller.UnauthorizedRoleException: *Missing
entitlement for role(s) [1]*
The current authorization model (which is going to change completely in
next release 1.2.0) requires different entitlements for an user (except
for admin) to access certain sections of the admin console.
So, for an user U configured as owner of role R, you will need to grant
U with (at least) POLICY_LIST and USER_READ entitlements.
This can be accomplished by giving such entitlements to one of roles
assigned to U: in the simplest form, you can just give such two
entitlements to role R and assign R to U (besides ownership). At this
point, as reported in [3], U will be able to administer R.
Let me stress that this entitlement assignment is only required for the
admin console, not for plain role administration via REST access: this
because the admin console performs multiple REST calls when constructing
the role form.
[1] https://cwiki.apache.org/confluence/display/SYNCOPE/Schema
[2] https://cwiki.apache.org/confluence/display/SYNCOPE/SyncActionsClass
[3]
https://cwiki.apache.org/confluence/display/SYNCOPE/Authentication+and+authorization#Authenticationandauthorization-Roleownership
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
