On Mon, May 10, 2021 at 9:04 AM Francesco Chicchiriccò <ilgro...@apache.org> wrote:
Got my Groovy script working, good progress! 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 > > 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,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,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]}, Attribute: {Name=entryUUID, Value=[c0a8aa18-42a1-103b-99d3-9ff4281b3bc9]}, Attribute: {Name=__NAME__, Value=[uid=roger,ou=People,dc=flat,dc=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,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,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? Best regards, Martin
