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 ;-) 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/
