You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@syncope.apache.org by Martin van Es <mr...@gmail.com> on 2021/05/07 11:49:59 UTC
Global uniqueness requirement of username
Hi,
I've been playing around with Syncope again and was trying to sync a src
LDAP scheme that contains multiple organizations, which contain multiple
Groups and People branches. All of these branches contain organisation
specific users, possibly sharing the same uid (login name). You might call
this a multi-tennant lay-out.
I was hoping Realms could keep these tennants separated and the usernames
uniquely scoped to the realm (automatically).
It turns out, that plainly assigning uid to internal attribute username
won't work, for two reasons:
1. admin isn't allowed (in my docker test deploy) because there's already a
global user called admin, even if I provision the user in a separate Realm?)
2. I can't reuse uid's assigned to username, even when I use a different
Realm, so I'd have to assign entryUUID to username and create a separate
user_id attribute mapped to uid for all users?
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.
Best regards,
Martin
--
If 'but' was any useful, it would be a logic operator
Re: Global uniqueness requirement of username
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 12/05/21 08:32, Martin van Es wrote:
> On Tue, May 11, 2021 at 4:52 PM Francesco Chicchiriccò <ilgrosso@apache.org <ma...@apache.org>> wrote:
>
> You can have a look at what can be done in a PropagationActions class by looking at matching classes under
>
> https://github.com/apache/syncope/tree/2_1_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/propagation <https://github.com/apache/syncope/tree/2_1_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/propagation>
>
> Ah! The Tasks cary the properties, this is very helpfull indeed.
> Thx for your patient replies!
You're welcome.
Regards.
--
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/
Re: Global uniqueness requirement of username
Posted by Martin van Es <mr...@gmail.com>.
On Tue, May 11, 2021 at 4:52 PM Francesco Chicchiriccò <il...@apache.org>
wrote:
> You can have a look at what can be done in a PropagationActions class by
> looking at matching classes under
>
>
> https://github.com/apache/syncope/tree/2_1_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/propagation
>
> Ah! The Tasks cary the properties, this is very helpfull indeed.
Thx for your patient replies!
Martin
Re: Global uniqueness requirement of username
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 10/05/21 16:11, Martin van Es wrote:
> Hi Francesco,
>
> Ok, I can log debug statements!
>
> When I inspect the entity object on any of the available methods for e.g. org.apache.syncope.core.provisioning.api.pushpull.PushActions it seems to be of class JPAUser.
>
> Now, what I expect (but maybe I'm completely mistaken) is to be able to manipulate the JPAUser object as it flows into the target resource. For example, I expect some get'ers, and set'ers on (internal) attributes so that I can inspect values, conditionally alter or add them and update the changes back into the object to be provisioned. I know much of this can be done using attribute mapping logic in the normal resource configuration, but what if the logic was a bit more complicated? Are these groovy scripts meant and able to manipulate attributes as I think they are? I've taken a look at the JPAUser API documentation[1], and although the class is quite rich and supports e.g. add(UPlainAttr attr) I don't see ways to get, set or update available attributes on the object?
You can have a look at what can be done in a PropagationActions class by looking at matching classes under
https://github.com/apache/syncope/tree/2_1_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/propagation
About PushActions and PullActions you can check
https://github.com/apache/syncope/tree/2_1_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/pushpull
HTH
Regards.
> [1] http://syncope.apache.org/apidocs/2.0/org/apache/syncope/core/persistence/jpa/entity/user/JPAUser.html <http://syncope.apache.org/apidocs/2.0/org/apache/syncope/core/persistence/jpa/entity/user/JPAUser.html>
>
> Best regards.
> Martin
>
> On Mon, May 10, 2021 at 2:19 PM Francesco Chicchiriccò <ilgrosso@apache.org <ma...@apache.org>> wrote:
>
> On 10/05/21 14:05, Martin van Es wrote:
>>
>>
>> On Mon, May 10, 2021 at 9:07 AM Francesco Chicchiriccò <ilgrosso@apache.org <ma...@apache.org>> wrote:
>>
>> On 07/05/21 19:50, Martin van Es wrote:
>>> Another question.
>>> How would I print debug (core.log) statements in a Groovy propagation action script?
>>
>> Not very related to the subject, but you can find a relevant example here:
>>
>> https://github.com/apache/syncope/blob/2_1_X/fit/core-reference/src/test/resources/rest/SearchScript.groovy#L104 <https://github.com/apache/syncope/blob/2_1_X/fit/core-reference/src/test/resources/rest/SearchScript.groovy#L104>
>>
>> Thx for your input!
>>
>> This is the output when I blindly add log.info <http://log.info>() to a test Groovy propagation action script:
>>
>> 11:57:53.811 DEBUG org.apache.syncope.core.provisioning.java.ConnectorManager - Connector to be registered: ConnectorFacadeProxy{connector=org.identityconnectors.framework.impl.api.local.LocalConnectorFacadeImpl@63b8
>> d810
>> capabitilies=[UPDATE, DELETE, CREATE, SEARCH, AUTHENTICATE]}
>> 11:57:53.811 DEBUG org.apache.syncope.core.provisioning.java.ConnectorManager - Successfully registered bean connInstance-Master-3229BE00-2A72-4A78-A9BE-002A729A784D-service-cloud
>> 11:57:53.813 DEBUG org.apache.syncope.core.provisioning.api.job.SchedTaskJobDelegate - Executing push on JPAExternalResource[service-cloud]
>> 11:57:54.063 DEBUG org.apache.syncope.core.provisioning.api.pushpull.SyncopeResultHandler - Pushing USER with key 89b4b6da-1ef3-4720-b4b6-da1ef3072081 towards JPAExternalResource[service-cloud]
>> 11:57:56.666 ERROR org.apache.syncope.core.provisioning.java.pushpull.OutboundMatcher - While building JPAImplementation[My_Groovy_PropagationAction]
>> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
>> Script_591aa0a4f0c025faabe5fd7f86d74fb0.groovy: 39: [Static type checking] - The variable [log] is undeclared.
>> @ line 39, column 5.
>> log.info <http://log.info>("Entering " + action + " Script");
>> ^
>>
>> The main problem here probably is that I'm not a hard-core Java developer and I'm trying to create a maximum flexibility, zero-compilation identity synchronisation setup for the team to work with. Simple syncope-console editable Groovy scripts would help tremendously with that goal!
>
> Sorry, I did not read well that you were not interested in Groovy scripts for connectors but in Groovy Propagation Actions classes.
>
> You can use Groovy's @Slf4j then:
>
> import groovy.transform.CompileStatic
> import groovy.util.logging.Slf4j
> import org.apache.syncope.core.persistence.api.entity.task.PropagationTask
> import org.apache.syncope.core.provisioning.api.propagation.PropagationActions
> import org.identityconnectors.framework.common.objects.ConnectorObject
>
> @Slf4j
> @CompileStatic
> class MyPropagationActions implements PropagationActions {
>
> @Override
> void before(PropagationTask task, ConnectorObject beforeObj) {
> log.error("About to run {}", task)
> }
> }
>
> Logging statements will be sent to core.log.
>
> Regards.
>
--
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/
Re: Global uniqueness requirement of username
Posted by Martin van Es <mr...@gmail.com>.
Hi Francesco,
Ok, I can log debug statements!
When I inspect the entity object on any of the available methods for
e.g. org.apache.syncope.core.provisioning.api.pushpull.PushActions it seems
to be of class JPAUser.
Now, what I expect (but maybe I'm completely mistaken) is to be able to
manipulate the JPAUser object as it flows into the target resource. For
example, I expect some get'ers, and set'ers on (internal) attributes so
that I can inspect values, conditionally alter or add them and update the
changes back into the object to be provisioned. I know much of this can be
done using attribute mapping logic in the normal resource configuration,
but what if the logic was a bit more complicated? Are these groovy scripts
meant and able to manipulate attributes as I think they are? I've taken a
look at the JPAUser API documentation[1], and although the class is quite
rich and supports e.g. add(UPlainAttr attr) I don't see ways to get, set or
update available attributes on the object?
[1]
http://syncope.apache.org/apidocs/2.0/org/apache/syncope/core/persistence/jpa/entity/user/JPAUser.html
Best regards.
Martin
On Mon, May 10, 2021 at 2:19 PM Francesco Chicchiriccò <il...@apache.org>
wrote:
> On 10/05/21 14:05, Martin van Es wrote:
>
>
>
> On Mon, May 10, 2021 at 9:07 AM Francesco Chicchiriccò <
> ilgrosso@apache.org> wrote:
>
>> On 07/05/21 19:50, Martin van Es wrote:
>>
>> Another question.
>> How would I print debug (core.log) statements in a Groovy propagation
>> action script?
>>
>> Not very related to the subject, but you can find a relevant example here:
>>
>>
>> https://github.com/apache/syncope/blob/2_1_X/fit/core-reference/src/test/resources/rest/SearchScript.groovy#L104
>>
> Thx for your input!
>
> This is the output when I blindly add log.info() to a test Groovy
> propagation action script:
>
> 11:57:53.811 DEBUG
> org.apache.syncope.core.provisioning.java.ConnectorManager - Connector to
> be registered:
> ConnectorFacadeProxy{connector=org.identityconnectors.framework.impl.api.local.LocalConnectorFacadeImpl@63b8
> d810
> capabitilies=[UPDATE, DELETE, CREATE, SEARCH, AUTHENTICATE]}
> 11:57:53.811 DEBUG
> org.apache.syncope.core.provisioning.java.ConnectorManager - Successfully
> registered bean
> connInstance-Master-3229BE00-2A72-4A78-A9BE-002A729A784D-service-cloud
> 11:57:53.813 DEBUG
> org.apache.syncope.core.provisioning.api.job.SchedTaskJobDelegate -
> Executing push on JPAExternalResource[service-cloud]
> 11:57:54.063 DEBUG
> org.apache.syncope.core.provisioning.api.pushpull.SyncopeResultHandler -
> Pushing USER with key 89b4b6da-1ef3-4720-b4b6-da1ef3072081 towards
> JPAExternalResource[service-cloud]
> 11:57:56.666 ERROR
> org.apache.syncope.core.provisioning.java.pushpull.OutboundMatcher - While
> building JPAImplementation[My_Groovy_PropagationAction]
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Script_591aa0a4f0c025faabe5fd7f86d74fb0.groovy: 39: [Static type checking]
> - The variable [log] is undeclared.
> @ line 39, column 5.
> log.info("Entering " + action + " Script");
> ^
>
> The main problem here probably is that I'm not a hard-core Java developer
> and I'm trying to create a maximum flexibility, zero-compilation identity
> synchronisation setup for the team to work with. Simple syncope-console
> editable Groovy scripts would help tremendously with that goal!
>
> Sorry, I did not read well that you were not interested in Groovy scripts
> for connectors but in Groovy Propagation Actions classes.
>
> You can use Groovy's @Slf4j then:
>
> import groovy.transform.CompileStatic
> import groovy.util.logging.Slf4j
> import org.apache.syncope.core.persistence.api.entity.task.PropagationTask
> import
> org.apache.syncope.core.provisioning.api.propagation.PropagationActions
> import org.identityconnectors.framework.common.objects.ConnectorObject
>
> @Slf4j
> @CompileStatic
> class MyPropagationActions implements PropagationActions {
>
> @Override
> void before(PropagationTask task, ConnectorObject beforeObj) {
> log.error("About to run {}", task)
> }
> }
>
> Logging statements will be sent to core.log.
>
> Regards.
>
> --
> Francesco Chicchiriccò
>
> Tirasa - Open Source Excellencehttp://www.tirasa.net/
>
> Member at The Apache Software Foundation
> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMailhttp://home.apache.org/~ilgrosso/
>
>
--
If 'but' was any useful, it would be a logic operator
Re: Global uniqueness requirement of username
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 10/05/21 14:05, Martin van Es wrote:
>
>
> On Mon, May 10, 2021 at 9:07 AM Francesco Chicchiriccò <ilgrosso@apache.org <ma...@apache.org>> wrote:
>
> On 07/05/21 19:50, Martin van Es wrote:
>> Another question.
>> How would I print debug (core.log) statements in a Groovy propagation action script?
>
> Not very related to the subject, but you can find a relevant example here:
>
> https://github.com/apache/syncope/blob/2_1_X/fit/core-reference/src/test/resources/rest/SearchScript.groovy#L104 <https://github.com/apache/syncope/blob/2_1_X/fit/core-reference/src/test/resources/rest/SearchScript.groovy#L104>
>
> Thx for your input!
>
> This is the output when I blindly add log.info <http://log.info>() to a test Groovy propagation action script:
>
> 11:57:53.811 DEBUG org.apache.syncope.core.provisioning.java.ConnectorManager - Connector to be registered: ConnectorFacadeProxy{connector=org.identityconnectors.framework.impl.api.local.LocalConnectorFacadeImpl@63b8
> d810
> capabitilies=[UPDATE, DELETE, CREATE, SEARCH, AUTHENTICATE]}
> 11:57:53.811 DEBUG org.apache.syncope.core.provisioning.java.ConnectorManager - Successfully registered bean connInstance-Master-3229BE00-2A72-4A78-A9BE-002A729A784D-service-cloud
> 11:57:53.813 DEBUG org.apache.syncope.core.provisioning.api.job.SchedTaskJobDelegate - Executing push on JPAExternalResource[service-cloud]
> 11:57:54.063 DEBUG org.apache.syncope.core.provisioning.api.pushpull.SyncopeResultHandler - Pushing USER with key 89b4b6da-1ef3-4720-b4b6-da1ef3072081 towards JPAExternalResource[service-cloud]
> 11:57:56.666 ERROR org.apache.syncope.core.provisioning.java.pushpull.OutboundMatcher - While building JPAImplementation[My_Groovy_PropagationAction]
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
> Script_591aa0a4f0c025faabe5fd7f86d74fb0.groovy: 39: [Static type checking] - The variable [log] is undeclared.
> @ line 39, column 5.
> log.info <http://log.info>("Entering " + action + " Script");
> ^
>
> The main problem here probably is that I'm not a hard-core Java developer and I'm trying to create a maximum flexibility, zero-compilation identity synchronisation setup for the team to work with. Simple syncope-console editable Groovy scripts would help tremendously with that goal!
Sorry, I did not read well that you were not interested in Groovy scripts for connectors but in Groovy Propagation Actions classes.
You can use Groovy's @Slf4j then:
import groovy.transform.CompileStatic
import groovy.util.logging.Slf4j
import org.apache.syncope.core.persistence.api.entity.task.PropagationTask
import org.apache.syncope.core.provisioning.api.propagation.PropagationActions
import org.identityconnectors.framework.common.objects.ConnectorObject
@Slf4j
@CompileStatic
class MyPropagationActions implements PropagationActions {
@Override
void before(PropagationTask task, ConnectorObject beforeObj) {
log.error("About to run {}", task)
}
}
Logging statements will be sent to core.log.
Regards.
--
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/
Re: Global uniqueness requirement of username
Posted by Martin van Es <mr...@gmail.com>.
On Mon, May 10, 2021 at 9:07 AM Francesco Chicchiriccò <il...@apache.org>
wrote:
> On 07/05/21 19:50, Martin van Es wrote:
>
> Another question.
> How would I print debug (core.log) statements in a Groovy propagation
> action script?
>
> Not very related to the subject, but you can find a relevant example here:
>
>
> https://github.com/apache/syncope/blob/2_1_X/fit/core-reference/src/test/resources/rest/SearchScript.groovy#L104
>
> Thx for your input!
This is the output when I blindly add log.info() to a test Groovy
propagation action script:
11:57:53.811 DEBUG
org.apache.syncope.core.provisioning.java.ConnectorManager - Connector to
be registered:
ConnectorFacadeProxy{connector=org.identityconnectors.framework.impl.api.local.LocalConnectorFacadeImpl@63b8
d810
capabitilies=[UPDATE, DELETE, CREATE, SEARCH, AUTHENTICATE]}
11:57:53.811 DEBUG
org.apache.syncope.core.provisioning.java.ConnectorManager - Successfully
registered bean
connInstance-Master-3229BE00-2A72-4A78-A9BE-002A729A784D-service-cloud
11:57:53.813 DEBUG
org.apache.syncope.core.provisioning.api.job.SchedTaskJobDelegate -
Executing push on JPAExternalResource[service-cloud]
11:57:54.063 DEBUG
org.apache.syncope.core.provisioning.api.pushpull.SyncopeResultHandler -
Pushing USER with key 89b4b6da-1ef3-4720-b4b6-da1ef3072081 towards
JPAExternalResource[service-cloud]
11:57:56.666 ERROR
org.apache.syncope.core.provisioning.java.pushpull.OutboundMatcher - While
building JPAImplementation[My_Groovy_PropagationAction]
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
failed:
Script_591aa0a4f0c025faabe5fd7f86d74fb0.groovy: 39: [Static type checking]
- The variable [log] is undeclared.
@ line 39, column 5.
log.info("Entering " + action + " Script");
^
The main problem here probably is that I'm not a hard-core Java developer
and I'm trying to create a maximum flexibility, zero-compilation identity
synchronisation setup for the team to work with. Simple syncope-console
editable Groovy scripts would help tremendously with that goal!
Best regards.
Martin
Re: Global uniqueness requirement of username
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 07/05/21 19:50, Martin van Es wrote:
> Another question.
> How would I print debug (core.log) statements in a Groovy propagation action script?
Not very related to the subject, but you can find a relevant example here:
https://github.com/apache/syncope/blob/2_1_X/fit/core-reference/src/test/resources/rest/SearchScript.groovy#L104
Other samples from Groovy files in the same dir and scriptedsql sibling.
Statements will go to core-connid.log
Regards.
> On Fri, May 7, 2021 at 1:49 PM Martin van Es <mrvanes@gmail.com <ma...@gmail.com>> wrote:
>
> Hi,
>
> I've been playing around with Syncope again and was trying to sync a src LDAP scheme that contains multiple organizations, which contain multiple Groups and People branches. All of these branches contain organisation specific users, possibly sharing the same uid (login name). You might call this a multi-tennant lay-out.
>
> I was hoping Realms could keep these tennants separated and the usernames uniquely scoped to the realm (automatically).
>
> It turns out, that plainly assigning uid to internal attribute username won't work, for two reasons:
>
> 1. admin isn't allowed (in my docker test deploy) because there's already a global user called admin, even if I provision the user in a separate Realm?)
> 2. I can't reuse uid's assigned to username, even when I use a different Realm, so I'd have to assign entryUUID to username and create a separate user_id attribute mapped to uid for all users?
>
> 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.
>
> Best regards,
> Martin
> --
> If 'but' was any useful, it would be a logic operator
>
>
>
> --
> If 'but' was any useful, it would be a logic operator
--
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/
Re: Global uniqueness requirement of username
Posted by Martin van Es <mr...@gmail.com>.
Another question.
How would I print debug (core.log) statements in a Groovy propagation
action script?
Best regards,
Martin
On Fri, May 7, 2021 at 1:49 PM Martin van Es <mr...@gmail.com> wrote:
> Hi,
>
> I've been playing around with Syncope again and was trying to sync a src
> LDAP scheme that contains multiple organizations, which contain multiple
> Groups and People branches. All of these branches contain organisation
> specific users, possibly sharing the same uid (login name). You might call
> this a multi-tennant lay-out.
>
> I was hoping Realms could keep these tennants separated and the usernames
> uniquely scoped to the realm (automatically).
>
> It turns out, that plainly assigning uid to internal attribute username
> won't work, for two reasons:
>
> 1. admin isn't allowed (in my docker test deploy) because there's already
> a global user called admin, even if I provision the user in a separate
> Realm?)
> 2. I can't reuse uid's assigned to username, even when I use a different
> Realm, so I'd have to assign entryUUID to username and create a separate
> user_id attribute mapped to uid for all users?
>
> 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.
>
> Best regards,
> Martin
> --
> If 'but' was any useful, it would be a logic operator
>
--
If 'but' was any useful, it would be a logic operator
Re: Global uniqueness requirement of username
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 17/05/21 08:06, Martin van Es wrote:
> On Fri, May 14, 2021 at 7:27 AM Francesco Chicchiriccò <ilgrosso@apache.org <ma...@apache.org>> wrote:
>
>
> 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 <https://cloud,dc=services,dc=vnet>
>
>
> Except for the newline, which was introduced by the console width of the tail of the core.log output I don't see any difference between the two DN's?
> I'd suggest you try to synchrise groupmembership for members living under a dc containing slashes to see if you can make it work. Like I said, if I only change the dc name and leave the rest of the config identical everything works as expected.
Sorry, I don't have spare cycles to invest in such troubleshooting, maybe someone else (including you) can take some time to debug and attempt to provide some more insights, as I was suggesting in my previous response.
I can of course help with fix.
Regards.
--
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/
Re: Global uniqueness requirement of username
Posted by Martin van Es <mr...@gmail.com>.
On Fri, May 14, 2021 at 7:27 AM Francesco Chicchiriccò <il...@apache.org>
wrote:
>
> 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
>
>
Except for the newline, which was introduced by the console width of the
tail of the core.log output I don't see any difference between the two DN's?
I'd suggest you try to synchrise groupmembership for members living under a
dc containing slashes to see if you can make it work. Like I said, if I
only change the dc name and leave the rest of the config identical
everything works as expected.
Best regards,
Martin
Re: Global uniqueness requirement of username
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 13/05/21 16:38, Martin van Es wrote:
> On Mon, May 10, 2021 at 9:04 AM Francesco Chicchiriccò <ilgrosso@apache.org <ma...@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=[roger@example.org <ma...@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/
Re: Global uniqueness requirement of username
Posted by Martin van Es <mr...@gmail.com>.
On Mon, May 10, 2021 at 9:04 AM Francesco Chicchiriccò <il...@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=[roger@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
Re: Global uniqueness requirement of username
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 07/05/21 13:49, Martin van Es wrote:
> Hi,
>
> I've been playing around with Syncope again and was trying to sync a src LDAP scheme that contains multiple organizations, which contain multiple Groups and People branches. All of these branches contain organisation specific users, possibly sharing the same uid (login name). You might call this a multi-tennant lay-out.
>
> I was hoping Realms could keep these tennants separated and the usernames uniquely scoped to the realm (automatically).
>
> It turns out, that plainly assigning uid to internal attribute username won't work, for two reasons:
>
> 1. admin isn't allowed (in my docker test deploy) because there's already a global user called admin, even if I provision the user in a separate Realm?)
There is one pre-defined admin user: you can change such username to something different in
core/src/main/resources/admin.properties
via the "adminUser" property.
> 2. I can't reuse uid's assigned to username, even when I use a different Realm, so I'd have to assign entryUUID to username and create a separate user_id attribute mapped to uid for all users?
Yes, Syncope's username is defined as unique for the SyncopeUser table.
Currently, there is no predefined way to set the constraint "unique per Realm" on anything.
> 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.
Regards.
--
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/