You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@syncope.apache.org by Salim Boulkour <sa...@arismore.fr> on 2013/08/07 13:36:04 UTC
Roles in Syncope
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 ?
- Can we create role inclusions ? Like giving role A to a user, also
gives the user roles S and T ?
- Can we specify parameters or some kind of attribute to a role in order
to specialized it ?
- 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 ?
- 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)
- Are the owner fields of a role attached to Syncope entitlements in a
way ? The owners can update/delete the role ? 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]*
--
*
Salim BOULKOUR*
Re: Roles in Syncope
Posted by Salim Boulkour <sa...@arismore.fr>.
Hi Francesco,
thank you for your help.
2013/8/8 Francesco Chicchiriccò <il...@apache.org>
> 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 ?
> - 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)
>
>
>
> - 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 Memberhttp://people.apache.org/~ilgrosso/
>
>
--
*Salim BOULKOUR*
Consultant IAM[image: Logo]
------------------------------
ARISMORE
137 Bureaux de la Colline - 92213 Saint-Cloud Cedex - France
Ligne directe : +33 (0)1 78 16 48 26 - Portable : +33 (0)6 01 34 41 71
Standard : 01 55 57 21 60 - Fax : 01 55 57 04 45
Re: Roles in Syncope
Posted by Francesco Chicchiriccò <il...@apache.org>.
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/