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