On 13/05/21 16:38, Martin van Es wrote:
On Mon, May 10, 2021 at 9:04 AM Francesco Chicchiriccò <ilgro...@apache.org
<mailto:ilgro...@apache.org>> wrote:
Got my Groovy script working, good progress!
Technically speaking, it's a Groovy *class*, not script.
There was still one thing lingering around that I forgot the come back to:
> Secondly, some of the organisation DN's contain (forward) slashes in the
dc part of their DN, which makes configuring the resource awkward (I need to
escape the slash using a backslash in the Base Contexts to Synchronize) but worse:
it renders membership matching impossible (the entryDN of the user can not be
found from the member DN in the group although the matching DN string is correct
as inspected from debug output) so I guess that's a bug to be solved in Syncope at
some time, because it works as expected for organisations without the slashes in
the dc part.
Realm names (as all other Entity keys) are set to match the NAME pattern:
https://github.com/apache/syncope/blob/2_1_X/core/persistence-jpa/src/main/java/org/apache/syncope/core/persistence/jpa/validation/entity/RealmValidator.java#L52
<https://github.com/apache/syncope/blob/2_1_X/core/persistence-jpa/src/main/java/org/apache/syncope/core/persistence/jpa/validation/entity/RealmValidator.java#L52>
hence forward slashes are not allowed: consider that the rationales behind
this constraint are that (1) NAME values are normally used in URLs and also
that (2) forward slash is used internally by Syncope as full path separator.
This is not about the Realm name. The problem is that if users lives below an entry containing
forward slashes (e.g. uid=test,ou=People,dc=http://test.org
<http://test.org>,dc=example,dc=org) in the source resource the groupmembership synchronisation
fails, because the group/user matching logic fails to match
"uid=test,ou=People,dc=http://test.org <http://test.org>,dc=example,dc=org" to any
existing user object link, even if that user clearly exists on the resource:
The pull action first succesfully synchronises one of the test users:
13:10:40.581 DEBUG org.apache.syncope.core.provisioning.api.pushpull.SyncopeResultHandler - Successfully handled {Uid=Attribute: {Name=__UID__, Value=[c0a8aa18-42a1-103b-99d3-9ff4281b3bc9]}, ObjectClass=ObjectClass: __ACCOUNT__, DeltaType=CREATE_OR_UPDATE, Token=SyncToken: , Object={Uid=Attribute: {Name=__UID__, Value=[c0a8aa18-42a1-103b-99d3-9ff4281b3bc9]}, ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute: {Name=uid, Value=[roger]}, Attribute: {Name=mail, Value=[ro...@example.org <mailto:ro...@example.org>]}, Attribute: {Name=entryUUID, Value=[c0a8aa18-42a1-103b-99d3-9ff4281b3bc9]}, Attribute: {Name=__NAME__, Value=[uid=roger,ou=People,dc=flat,dc=https://cloud <https://cloud>,dc=services,dc=vnet]}, Attribute: {Name=cn, Value=[urn:roger]}, Attribute: {Name=sn, Value=[n/a]}, Attribute: {Name=__UID__, Value=[c0a8aa18-42a1-103b-99d3-9ff4281b3bc9]}, Attribute: {Name=__ENABLE__, Value=[]}], Name=Attribute: {Name=__NAME__,
Value=[uid=roger,ou=People,dc=flat,dc=https://cloud <https://cloud>,dc=services,dc=vnet]}}, PreviousUid=null}
And later, when the groups are pulled, the member(s) can't be related to any
existing user, even though the DN is correct:
13:10:41.168 DEBUG
org.apache.syncope.core.provisioning.java.pushpull.InboundMatcher - No
ObjectClass: __ACCOUNT__ found on JPAExternalResource[SRAM-Cloud] with __NAME__
uid=roger,ou=People,dc=flat,dc=https:/
/cloud,dc=services,dc=vnet
13:10:41.168 WARN
org.apache.syncope.core.provisioning.java.pushpull.LDAPMembershipPullActions - Could
not find matching user for uid=roger,ou=People,dc=flat,dc=https://cloud
<https://cloud>,dc=services,dc=vnet
This works flawlessly for any LDAP resource without the forward slashes in the
dc above ou=People. To me, this looks like a bug?
The log error above comes from [1]; the likely cause is that namevalue provided
as method argument was not matched by any LDAP user, when searching on LDAP a
few lines above.
This call comes from [2] which is essentially iterating over the values
provided by LDAP's uniquemember of the pulling Group: I would then start by
having a careful look at how such values actually look like in LDAP and how
they are received by method [3].
At a first glance, there seems to be some difference between
"membValue.toString()" from [4] - logged as
uid=roger,ou=People,dc=flat,dc=https:/
/cloud,dc=services,dc=vnet
and "membValue" as reported by log statement at [5] which is instead
uid=roger,ou=People,dc=flat,dc=https://cloud,dc=services,dc=vnet
Regards.
[1]
https://github.com/apache/syncope/blob/2_1_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/pushpull/InboundMatcher.java#L154
[2]
https://github.com/apache/syncope/blob/2_1_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/pushpull/LDAPMembershipPullActions.java#L174-L178
[3]
https://github.com/apache/syncope/blob/master/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/pushpull/LDAPMembershipPullActions.java#L96
[4]
https://github.com/apache/syncope/blob/master/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/pushpull/LDAPMembershipPullActions.java#L176
[5]
https://github.com/apache/syncope/blob/master/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/pushpull/LDAPMembershipPullActions.java#L187
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
