syncope-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Chicchiriccò <ilgro...@apache.org>
Subject Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Date Mon, 06 Feb 2017 10:34:57 GMT
On 02/02/2017 17:54, Colm O hEigeartaigh wrote:
> 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?

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/


Mime
View raw message