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/
