You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by Colm O hEigeartaigh <co...@apache.org> on 2013/02/15 16:48:02 UTC
LDAP Role queries
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
Re: LDAP Role queries
Posted by Colm O hEigeartaigh <co...@apache.org>.
>
> 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 <co...@apache.org>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").
>
> 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
Re: LDAP Role queries
Posted by Colm O hEigeartaigh <co...@apache.org>.
Patch submitted for review here:
https://issues.apache.org/jira/browse/SYNCOPE-320
Colm.
On Mon, Feb 18, 2013 at 5:14 PM, Francesco Chicchiriccò <ilgrosso@apache.org
> wrote:
> On 18/02/2013 16:08, Colm O hEigeartaigh wrote:
>
>> [...]
>>
>>
>> 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?
>>>>
>>>> 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,
> LDAPMembershipPropagationActio**ns 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ò <
>> ilgrosso@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
Posted by Francesco Chicchiriccò <il...@apache.org>.
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ò <ilgrosso@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
Posted by Emmanuel Lécharny <el...@gmail.com>.
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
Posted by Francesco Chicchiriccò <il...@apache.org>.
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
Posted by Emmanuel Lécharny <el...@gmail.com>.
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
Posted by Colm O hEigeartaigh <co...@apache.org>.
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ò <ilgrosso@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
Posted by Francesco Chicchiriccò <il...@apache.org>.
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
> LDAPMembershipPropagationActions, 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.
> 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?
+1
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/