Re: Role/membership attributes synchronization

[Fabio Martelli <fa...@gmail.com>]

Il giorno 24/feb/2012, alle ore 12.28, Francesco Chicchiriccò ha scritto:

> On 24/02/2012 11:13, Fabio Martelli wrote:
>> Hi All,
>> I'd like to open a discussion about a certain implementation. I would open a new issue but I would be sure about the requirements.
>> What I'm going to ask is a little bit hard to explain. I apologize in advance for the length.
>> 
>> Yesterday I closed the issue SYNCOPE-7 about the propagation of role and membership attributes.
>> At the moment you can map role/membership attributes to propagate role/membership information towards a specific external resource as is for normal user attributes.
> 
> ...and this is indeed a nice achievement :-)
> 
>> Role attribute propagation usefulness:
>> ###########################
>> Think about an external resource where group memberships are identified by a specific user attribute value.
>> May be, an attribute "groups" could be used to specify all the membership of an user.
> 
> For example, "memberOf" in LDAP.
> 
>> Probably, integrating this resource someone could be interested into create memberships on external resource just assigning roles on syncope.
>> 
>> Now, this is feasible just performing two steps:
>> 1. specifying a role attribute valued with the identifier of the corresponding remote role;
>> 2. providing a resource schema mapping for this role attribute.
>> 
>> During propagation (user create or update), all the retrieved values of the attribute specified above will be propagated as a multi-value user attribute as specified by the resource schema mapping.
> 
> This would mean, for example,
> 
> 1. create a role attribute schema "membershipsOnLDAP", type String,
> multivalue
> 2. on the LDAP resource, define a mapping between membershipsOnLDAP (on
> Syncope, internal) and "memberOf" (on external resource)
> 3. assign membershipsOnLDAP to role A, B and C (for example):
>  for A, assign "cn=A,ou=groups,dc=tirasa,dc=net"
>  for B, assign "cn=B,ou=groups,dc=tirasa,dc=net"
>  for C, assign "cn=C,ou=groups,dc=tirasa,dc=net"
> 
> Now, when creating users with roles A, B or C (or a combination of such)
> and the LDAP resource, you will end up with users in LDAP with memberOf
> containing one or more of the values specified above.
> 
>> ###########################
>> 
>> Membership attribute propagation usefulness:
>> ###########################
>> Syncope membership is the association between a user and a role. Each membership could have one or more membership attributes.
>> A membership attribute is an attribute that is owned by a user because it is associated to a certain role.
>> 
>> For example: I have the attribute "ASF Id" because I have the role "ASF committer" .
>> The usefulness to propagate these type of attributes is obvious ....
> 
> Continuing the example I have started above:
> 
> 1. let's suppose that we have an additional "ASF committer" role in Syncope
> 2. define a membership attribute schema "ASF Id", type String with
> UNIQUE and MANDATORY constraints
> 3. on the LDAP resource, define a mapping between "ASF Id" (on Syncope,
> internal) and "uid" (on external resource) - actually this could happen
> by selecting "ASF Id" as AccountId
> 
> Now, when creating users with role "ASF committer" and the LDAP resource
> you will end up with users in LDAP having their ASF Id as uid.
> 
>> ###########################
>> 
>> The behavior described above has been implemented yet with the issue SYNCOPE-7.
>> The problem is: what should be the behavior during synchronization?
> 
> A little side note for fresh Syncopers: so far, we have been referring
> to "propagation" when data flows from Syncope to external resources
> (database, LDAP, Active Directory, ...) and to "synchronization" when
> the data flows from external resources to Syncope.
> See [1] for more details.
> 
>> The possible implementations could be:
>> 1. I could ignore role/membership attribute mappings during synchronization (this is the current implementation ---> no issue to open)
>> 2. I can try to synchronize these information also:
>> 	a. Role attribute mappings could be used to assign syncope roles dynamically during synchronization
> 
> Example, again: let's suppose we are synchronizing an LDAP user user1
> with memberOf "cn=B,ou=groups,dc=tirasa,dc=net"; in this case Syncope
> will try to assign role B (i.e. Syncope role with same value of
> "membershipsOnLDAP") to Syncope user matching user1 on LDAP.
> 
> I say here "Syncope will try to assign role B" because there could be
> for example some mandatory membership attributes that need to be filled
> in with values. The following items could solve this.
> 
>> 	b. Membership attribute mappings could be synchronized but
>> 		b.1. Memberships must exist
>> 		b.2. if mapped attributes are owned by more than one membership, then all such memberships will receive the same values because there is no way to know which membership should own a specific value.
> 
> Hum, all this above seems a bit too much complex to me so be solved in a
> general fashion: I would rather prefer to implement point (a) above and
> fill the gap that can occur on deployments by empowering Synchronization
> action classes [2].
> 
> Side note: we must move ASAP all documentation from old to new wiki,
> reorganize, update...
> 
>> Sorry again for this rant.
> 
> It's not a rant, Zio, it's community-wise project building ;-)

Thank you for your clarification and your opinion.
Related issue at https://issues.apache.org/jira/browse/SYNCOPE-26.

Regards,
F.

> 
> Cheers.
> 
> [1]
> http://wiki.syncope-idm.org/index.php?title=ConnectorInstancesAndResources
> [2] http://wiki.syncope-idm.org/index.php?title=SynchronizationActionsClass
> -- 
> Francesco Chicchiriccò
> 
> Apache Cocoon PMC and Apache Syncope PPMC Member
> http://people.apache.org/~ilgrosso/
>