Hi Francesco, We can of course, file an improvement on the framework [1] and then on > every connector, then wait for the implementation.... but it would take > quite a while. Moreover, this make SYNCOPE-139 (Support OpenICF connector > bundles) harder because we will be making a non retro-compatible change. > > Moreover, I also think we can assume that anyone that wants to work with a > specific connector is supposed to take a look at its documentation [2], > which includes supported object classes.
Thanks for looking into this, I agree with your conclusions. Colm. On Mon, Feb 11, 2013 at 1:09 PM, Francesco Chicchiriccò <ilgro...@apache.org > wrote: > On 08/02/2013 18:11, Francesco Chicchiriccň wrote: > >> On 08/02/2013 17:55, Colm O hEigeartaigh wrote: >> >>> The basic idea is that for propagating / synchronizing users you need a >>>> ConnId connector supporting ObjectClass.ACCOUNT (all available connector >>>> bundles) while for propagating / synchronizing roles you need a ConnId >>>> connector supporting ObjectClass.GROUP (only the LDAP connector bundle, >>>> currently). >>>> >>> Thanks for the explanation Francesco! I'll turn my attention to >>> experimenting with an LDAP backend so. What do you think about a JIRA to >>> query the underlying Connector to see whether it supports >>> ObjectClass.GROUP, and to disable the ability to add Role Mappings in the >>> Resource if it does not? >>> >> >> I am not sure whether ConnId provides a framework operation to check if a >> given ObjectClass is supported nor to list the supported object classes, >> hence I think a sort of guess should be put in place. But disabling some >> console component because of such guess would be an hazard... >> >> I will investigate next week to see if this check is feasible (and >> reliable). >> > > Colm, > the result of my investigation is that the ConnId framework does not > provide any method for querying a connector for supported object classes. > > We can of course, file an improvement on the framework [1] and then on > every connector, then wait for the implementation.... but it would take > quite a while. Moreover, this make SYNCOPE-139 (Support OpenICF connector > bundles) harder because we will be making a non retro-compatible change. > > Moreover, I also think we can assume that anyone that wants to work with a > specific connector is supposed to take a look at its documentation [2], > which includes supported object classes. > > WDYT? > > [1] > https://connid.atlassian.net/**browse/BASE<https://connid.atlassian.net/browse/BASE> > [2] https://connid.atlassian.net/**wiki/display/BASE/Available+** > Connector+Bundles<https://connid.atlassian.net/wiki/display/BASE/Available+Connector+Bundles> > > On Fri, Feb 8, 2013 at 4:18 PM, Francesco Chicchiriccň >>> <ilgro...@apache.org>wrote: >>> >>> On 08/02/2013 17:10, Colm O hEigeartaigh wrote: >>>> >>>> Hi all, >>>>> >>>>> I'm experimenting with synchronizing roles into Syncope on trunk. >>>>> >>>>> Firstly, what is the difference between a User mapping in a Resource >>>>> where >>>>> you select "ROLE" as the entity, and the Role Mapping tab where you can >>>>> only select "ROLE"? >>>>> >>>>> When you add a mapping item for users with ROLE entities, you are >>>> propagating the value(s) of a role attribute as part of the user data. >>>> Here >>>> you are managing an user (i.e. ObjectClass.ACCOUNT for ConnId). >>>> >>>> When you add a mapping item for roles (only ROLE entities allowed), you >>>> are propagating the role data. Here you are managing a role (i.e. >>>> ObjectClass.GROUP for ConnId). >>>> >>>> >>>> Let's say I have a database table with a Username, Password, some >>>> >>>>> attributes, and a Role name. I want to import this Role into Syncope >>>>> and >>>>> also see that the User has this Role when I edit the User in the >>>>> Console. >>>>> Is this possible? >>>>> >>>>> The basic idea is that for propagating / synchronizing users you need >>>> a >>>> ConnId connector supporting ObjectClass.ACCOUNT (all available connector >>>> bundle) while for propagating / synchronizing roles you need a ConnId >>>> connector supporting ObjectClass.GROUP (only the LDAP connector bundle, >>>> currently). >>>> >>>> Moreover, the use case you report above is for propagating memberships >>>> (i.e. the fact that a user belongs to a role), not the role itself. >>>> Propagating memberships is not supported by the ConnId framework; >>>> however, >>>> I've developed some simple actions for achieving this goal, at least for >>>> LDAP as part of SYNCOPE-26. >>>> >>>> Hope this clarifies a bit. >>>> >>>> Regards. >>>> >>> >> -- > Francesco Chicchiriccň > > ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member > http://people.apache.org/~**ilgrosso/<http://people.apache.org/~ilgrosso/> > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
