Re: LDAP Role queries
On 19/02/2013 14:13, Emmanuel Lécharny wrote: Don't use uniqueMemeber. Never. Nine. Niet. Nix. http://rfc-ref.org/RFC-TEXTS/4519/chapter2.html#d4e443387 This is far from what you expect it to be, and you'll get hard time with some Windows identifier having a # in their DN. Hi Emmanuel, what's your advice for LDAP group object class, since groupOfUniqueNames (and uniqueMemeber) is Never. Nine. Niet. Nix.? Thanks. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: LDAP Role queries
Le 2/20/13 11:26 AM, Francesco Chicchiriccò a écrit : On 19/02/2013 14:13, Emmanuel Lécharny wrote: Don't use uniqueMemeber. Never. Nine. Niet. Nix. http://rfc-ref.org/RFC-TEXTS/4519/chapter2.html#d4e443387 This is far from what you expect it to be, and you'll get hard time with some Windows identifier having a # in their DN. Hi Emmanuel, what's your advice for LDAP group object class, since groupOfUniqueNames (and uniqueMemeber) is Never. Nine. Niet. Nix.? GroupOfNames and member. You can control the cardinality at a upper level. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: LDAP Role queries
Le 2/18/13 4:08 PM, Colm O hEigeartaigh a écrit : attribute name, whereas LDAPMembershipSyncActions has uniquemember. Is there a reason why it is different in both cases? Shouldn't they also check the value of the groupMemberAttribute property of the LDAP Connector? Could you explain the difference between ldapGroups and uniquemember here? Shouldn't the latter be uniqueMember? Don't use uniqueMemeber. Never. Nine. Niet. Nix. http://rfc-ref.org/RFC-TEXTS/4519/chapter2.html#d4e443387 This is far from what you expect it to be, and you'll get hard time with some Windows identifier having a # in their DN. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: LDAP Role queries
Hi Francesco, This derives from UserTO.username and RoleTO.name, as per bean property resolution: to turn the latter into rolename we should change the property name and getter / setter on RoleTO. Ok thanks. I'm fine with leaving it as it is - I just wanted to know why the difference between users + roles. LDAPMembershipPropagationActions has ldapGroups as the group member attribute name, whereas LDAPMembershipSyncActions has uniquemember. Is there a reason why it is different in both cases? Shouldn't they also check the value of the groupMemberAttribute property of the LDAP Connector? Could you explain the difference between ldapGroups and uniquemember here? Shouldn't the latter be uniqueMember? Thanks, Colm. On Fri, Feb 15, 2013 at 5:12 PM, Francesco Chicchiriccò ilgro...@apache.org wrote: On 15/02/2013 16:48, Colm O hEigeartaigh wrote: Hi all (Francesco), I've been experimenting with propagating/synchronizing roles from an LDAP backend on trunk...here are some questions: 1) When specifying the Account Id, where does the name come from? For example, for user mapping it's username, for the role mapping it's name, which is a bit confusing (I would have guessed rolename). This derives from UserTO.username and RoleTO.name, as per bean property resolution: to turn the latter into rolename we should change the property name and getter / setter on RoleTO. 2) If I create a new Role and propagate it with LDAPMembershipPropagationActio**ns, it selects the principal specified in the Connector as the member in the backend resource. Is this expected behaviour? Unfortunately, yes: memberOf requires at least one value, and I've found that this is a common practice to overcome such limitation. 3) Are role hierarchies supported for either propagation or synchronization? They don't appear to be, but thought I'd check anyway. Currently, role hierarchy is not supported neither in propagation nor in synchronization. 4) Role membership is working fine for propagation (create a new role + propagate it, create a new user with that role + propagate it, and the new role in the backend has the correct member entry). However, synchronization doesn't work. If I then synchronize by running the task again (with LDAPMembershipSyncActions), the role of the User actually disappears. Was this working when testing or is it possibly a bug when using member instead of memberof? Definitely yes. LDAPMembershipPropagationActio**ns has ldapGroups as the group member attribute name, whereas LDAPMembershipSyncActions has uniquemember. Is there a reason why it is different in both cases? Shouldn't they also check the value of the groupMemberAttribute property of the LDAP Connector? +1 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
Re: LDAP Role queries
On 18/02/2013 16:08, Colm O hEigeartaigh wrote: [...] LDAPMembershipPropagationActions has ldapGroups as the group member attribute name, whereas LDAPMembershipSyncActions has uniquemember. Is there a reason why it is different in both cases? Shouldn't they also check the value of the groupMemberAttribute property of the LDAP Connector? Could you explain the difference between ldapGroups and uniquemember here? ldapGroups is the 'special' attribute that the LDAP connector uses internally to process group memberships. This attribute name is not subject to configuration, in the LDAP connector. This is needed because the ConnId framework does not support memberships, but only ACCOUNT and GROUP. uniqueMember is the actual LDAP attribute used when the object class 'groupOfUniqueNames' is configured. I am not sure whether there is any mean to derive this attribute name from LDAP connector configuration: if this is possible, I am totally +1 to change LDAPMembershipSyncActions#getGroupMembershipAttrName implementation to empower that. Moreover, I agree with you that the method name (getGroupMembershipAttrName()) might be misleading and that we should change at least one: any proposal? Finally, consider that, as reported in SYNCOPE-26, LDAPMembershipPropagationActions and LDAPMembershipSyncActions are sample classes provided by reference when needing to implement an unsupported operation, e.g. propagate and synchronize memberships from an external resource. Shouldn't the latter be uniqueMember? AFAIK LDAP is not case sensitive... Regards. On Fri, Feb 15, 2013 at 5:12 PM, Francesco Chicchiriccò ilgro...@apache.org wrote: On 15/02/2013 16:48, Colm O hEigeartaigh wrote: Hi all (Francesco), I've been experimenting with propagating/synchronizing roles from an LDAP backend on trunk...here are some questions: 1) When specifying the Account Id, where does the name come from? For example, for user mapping it's username, for the role mapping it's name, which is a bit confusing (I would have guessed rolename). This derives from UserTO.username and RoleTO.name, as per bean property resolution: to turn the latter into rolename we should change the property name and getter / setter on RoleTO. 2) If I create a new Role and propagate it with LDAPMembershipPropagationActio**ns, it selects the principal specified in the Connector as the member in the backend resource. Is this expected behaviour? Unfortunately, yes: memberOf requires at least one value, and I've found that this is a common practice to overcome such limitation. 3) Are role hierarchies supported for either propagation or synchronization? They don't appear to be, but thought I'd check anyway. Currently, role hierarchy is not supported neither in propagation nor in synchronization. 4) Role membership is working fine for propagation (create a new role + propagate it, create a new user with that role + propagate it, and the new role in the backend has the correct member entry). However, synchronization doesn't work. If I then synchronize by running the task again (with LDAPMembershipSyncActions), the role of the User actually disappears. Was this working when testing or is it possibly a bug when using member instead of memberof? Definitely yes. LDAPMembershipPropagationActio**ns has ldapGroups as the group member attribute name, whereas LDAPMembershipSyncActions has uniquemember. Is there a reason why it is different in both cases? Shouldn't they also check the value of the groupMemberAttribute property of the LDAP Connector? +1 Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: LDAP Role queries
4) Role membership is working fine for propagation (create a new role + propagate it, create a new user with that role + propagate it, and the new role in the backend has the correct member entry). However, synchronization doesn't work. If I then synchronize by running the task again (with LDAPMembershipSyncActions), the role of the User actually disappears. Was this working when testing or is it possibly a bug when using member instead of memberof? LDAPMembershipPropagationActions has ldapGroups as the group member attribute name, whereas LDAPMembershipSyncActions has uniquemember. Is there a reason why it is different in both cases? Shouldn't they also check the value of the groupMemberAttribute property of the LDAP Connector? Colm. On Fri, Feb 15, 2013 at 3:48 PM, Colm O hEigeartaigh cohei...@apache.orgwrote: Hi all (Francesco), I've been experimenting with propagating/synchronizing roles from an LDAP backend on trunk...here are some questions: 1) When specifying the Account Id, where does the name come from? For example, for user mapping it's username, for the role mapping it's name, which is a bit confusing (I would have guessed rolename). 2) If I create a new Role and propagate it with LDAPMembershipPropagationActions, it selects the principal specified in the Connector as the member in the backend resource. Is this expected behaviour? 3) Are role hierarchies supported for either propagation or synchronization? They don't appear to be, but thought I'd check anyway. 4) Role membership is working fine for propagation (create a new role + propagate it, create a new user with that role + propagate it, and the new role in the backend has the correct member entry). However, synchronization doesn't work. If I then synchronize by running the task again (with LDAPMembershipSyncActions), the role of the User actually disappears. Was this working when testing or is it possibly a bug when using member instead of memberof? Thanks, Colm. -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
