You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by Francesco Chicchiriccò <il...@apache.org> on 2017/02/01 10:54:27 UTC
Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
On 31/01/2017 18:03, Colm O hEigeartaigh wrote:
> Hi Francesco,
>
> On Thu, Jan 26, 2017 at 8:06 AM, Francesco Chicchiricc� <il...@apache.org> wrote:
>
>> About the definition of the new Application and Privilege (and their
>> relationship with existing User and Group, for example), however, these
>> will still require new JPA entities to be defined for internal storage, new
>> TO and ultimately something for Admin UI management.
> I'm wondering how (or if) the concept of roles fits into this scenario of
> Applications and Privileges? The problem for us is that the existing
> entitlements/roles concepts in Syncope seems to map perfectly to that of
> SCIM, along the lines of:
>
> https://groups.google.com/forum/#!msg/cloud-directory/fs6szjVrBBA/tt3t0PZg0UEJ
>
> It's not really clear to me why we can't re-use the existing concepts to
> model entitlements/roles external to Syncope? Will there be a way to group
> privileges similar to the way that roles group entitlements?
I have read with interest the link above.
I agree that the existing Roles in Syncope are fine to map that concept;
the problem I see to assimilate the existing Entitlements with the new
entities being discussed so far in this thread, e.g. Privileges and
Applications.
Entitlements are a pre-defined set of strings (which can also be
extended, as we see in the Camel Provisioning Manager), specifically
targeted to implement delegated administration, e.g. only for internal
purpose.
Privileges could be instead used to model the rights on a given
Application; please note that the former might depend on the latter,
e.g. "POST on /a/b/c" but also "Administer printers".
Summarizing: while Roles currently have only Entitlements associated, in
the future we might also associate Privileges (which in turn are related
to Applications) to them. As a result, user U with role R will own both
Entitlements and Privileges.
If "privilege" is not suitable as name, let's then rename the existing
Entitlements to something else and use the word "entitlement" to model
the new concept instead.
>> Finally, I want to let you know that I am quite advanced in building a
>> prototype - which could be likely delivered in a month or two - that
>> introduces Digest Authentication and JWT token management in Syncope 2.0.X
>> (you might want to ask Sergey about my stressful questions around these
>> points in CXF...).
> Cool, are you referring to being able to perform authentication in Syncope
> with a signed JWT token here or something else?
The idea is that the first invocation of a specific REST endpoint will
be used only for authentication (which will be set by default to Digest
Authentication, but could be any other mechanism including SAML 2.0, for
example); such call will return a signed JWT token, which could be used
for subsequent calls. Refresh and ban / blacklist mechanism will be also
provided.
I have found such approach being reported as REST best practice.
Regards.
--
Francesco Chicchiricc�
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 01/02/2017 22:13, Adrian Gonzalez wrote:
> Hello Colm and Francesco,
>
>> Summarizing: while Roles currently have only Entitlements associated, in the future we might also associate Privileges (which in turn are related to Applications) to them. As a result, user U with role R will own both
>> Entitlements and Privileges.> If "privilege" is not suitable as name, let's then rename the existing
>> Entitlements to something else and use the word "entitlement" to model the new concept instead.
> Would it make sense to have an association from Group to Roles also ?
>
>
> If yes, we would end with :
> Role
>
> 0..n entitlements
> 0..n privileges
> Group
> 0..n roles
> 0..n users
> User
> 0..n roles
I don't see the point in associating Groups to Roles: the former are
both for Users and Any Objects, the latter only for Users.
Moreover, you can always define dynamic Group memberships based on Role
assignment and vice-versa [1][2], e.g. User U is dynamically assigned
role R because he is member of Group G or U is dynamically member of G
because he has R assigned.
Regards.
[1]
https://syncope.apache.org/docs/reference-guide.html#memberships-relationships
[2] https://syncope.apache.org/docs/reference-guide.html#roles
--
Francesco Chicchiricc�
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Posted by Adrian Gonzalez <ad...@yahoo.fr.INVALID>.
Hello Colm and Francesco,
> Summarizing: while Roles currently have only Entitlements associated, in
> the future we might also associate Privileges (which in turn are related
> to Applications) to them. As a result, user U with role R will own both
> Entitlements and Privileges.> If "privilege" is not suitable as name, let's then rename the existing
> Entitlements to something else and use the word "entitlement" to model
> the new concept instead.
Would it make sense to have an association from Group to Roles also ?
If yes, we would end with :
Role
0..n entitlements
0..n privileges
Group
0..n roles
0..n users
User
0..n roles
Regards,
Adrian
Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 02/02/2017 17:54, Colm O hEigeartaigh wrote:
> Hi Francesco,
>
> On Wed, Feb 1, 2017 at 10:54 AM, Francesco Chicchiricc� <il...@apache.org> wrote:
>
>> I agree that the existing Roles in Syncope are fine to map that concept;
>> the problem I see to assimilate the existing Entitlements with the new
>> entities being discussed so far in this thread, e.g. Privileges and
>> Applications.
>>
>> Entitlements are a pre-defined set of strings (which can also be extended,
>> as we see in the Camel Provisioning Manager), specifically targeted to
>> implement delegated administration, e.g. only for internal purpose.
>>
>> Privileges could be instead used to model the rights on a given
>> Application; please note that the former might depend on the latter, e.g.
>> "POST on /a/b/c" but also "Administer printers".
>>
>> Summarizing: while Roles currently have only Entitlements associated, in
>> the future we might also associate Privileges (which in turn are related to
>> Applications) to them. As a result, user U with role R will own both
>> Entitlements and Privileges.
>>
>> If "privilege" is not suitable as name, let's then rename the existing
>> Entitlements to something else and use the word "entitlement" to model the
>> new concept instead.
>>
> OK this all sounds fine to me. Hopefully we are nearing agreement :-)
>
> <SNIP from other email>
>> I don't see the point in associating Groups to Roles: the former are both
>> for Users and Any Objects, the latter only for Users.
>>
>> Moreover, you can always define dynamic Group memberships based on Role
>> assignment and vice-versa [1][2], e.g. User U is dynamically assigned role
>> R because he is member of Group G or U is dynamically member of G because
>> he has R assigned.
> I agree that dynamic role association due to group membership models the
> scenario of "every user in Group X should have role Y". There's probably
> nothing too objectionable about supporting being able to statically
> configure it though. Are there potential performance problems with dynamic
> membership I wonder if you're dealing with large amounts of entities?
I don't think so: dynamic memberships are actually not calculated on the
fly but rather stored and updated upon user create / update.
Regards.
--
Francesco Chicchiricc�
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Francesco,
On Wed, Feb 1, 2017 at 10:54 AM, Francesco Chicchiriccò <ilgrosso@apache.org
> wrote:
> I agree that the existing Roles in Syncope are fine to map that concept;
> the problem I see to assimilate the existing Entitlements with the new
> entities being discussed so far in this thread, e.g. Privileges and
> Applications.
>
> Entitlements are a pre-defined set of strings (which can also be extended,
> as we see in the Camel Provisioning Manager), specifically targeted to
> implement delegated administration, e.g. only for internal purpose.
>
> Privileges could be instead used to model the rights on a given
> Application; please note that the former might depend on the latter, e.g.
> "POST on /a/b/c" but also "Administer printers".
>
> Summarizing: while Roles currently have only Entitlements associated, in
> the future we might also associate Privileges (which in turn are related to
> Applications) to them. As a result, user U with role R will own both
> Entitlements and Privileges.
>
> If "privilege" is not suitable as name, let's then rename the existing
> Entitlements to something else and use the word "entitlement" to model the
> new concept instead.
>
OK this all sounds fine to me. Hopefully we are nearing agreement :-)
<SNIP from other email>
I don't see the point in associating Groups to Roles: the former are both
> for Users and Any Objects, the latter only for Users.
>
> Moreover, you can always define dynamic Group memberships based on Role
> assignment and vice-versa [1][2], e.g. User U is dynamically assigned role
> R because he is member of Group G or U is dynamically member of G because
> he has R assigned.
I agree that dynamic role association due to group membership models the
scenario of "every user in Group X should have role Y". There's probably
nothing too objectionable about supporting being able to statically
configure it though. Are there potential performance problems with dynamic
membership I wonder if you're dealing with large amounts of entities?
Colm.
>
> Regards.
>
> --
> Francesco Chicchiriccò
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
>
> Member at The Apache Software Foundation
> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
> http://home.apache.org/~ilgrosso/
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com