Re: Global uniqueness requirement of username

[Francesco Chicchiriccò]

On 17/05/21 08:06, Martin van Es wrote:

On Fri, May 14, 2021 at 7:27 AM Francesco Chicchiriccò mailto:ilgro...@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.


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

[Martin van Es]

On Fri, May 14, 2021 at 7:27 AM Francesco Chicchiriccò 
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

[Francesco Chicchiriccò]

On 13/05/21 16:38, Martin van Es wrote:

On Mon, May 10, 2021 at 9:04 AM Francesco Chicchiriccò 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
 


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?


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] 

Re: Global uniqueness requirement of username

[Martin van Es]

On Mon, May 10, 2021 at 9:04 AM Francesco Chicchiriccò 
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

Re: Global uniqueness requirement of username

[Francesco Chicchiriccò]

On 12/05/21 08:32, Martin van Es wrote:

On Tue, May 11, 2021 at 4:52 PM Francesco Chicchiriccò mailto:ilgro...@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!


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

[Martin van Es]

On Tue, May 11, 2021 at 4:52 PM Francesco Chicchiriccò 
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

[Francesco Chicchiriccò]

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
 


Best regards.
Martin

On Mon, May 10, 2021 at 2:19 PM Francesco Chicchiriccò mailto:ilgro...@apache.org>> wrote:

On 10/05/21 14:05, Martin van Es wrote:



On Mon, May 10, 2021 at 9:07 AM Francesco Chicchiriccò mailto:ilgro...@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.


--

Re: Global uniqueness requirement of username

[Martin van Es]

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ò 
wrote:

> On 10/05/21 14:05, Martin van Es wrote:
>
>
>
> On Mon, May 10, 2021 at 9:07 AM Francesco Chicchiriccò <
> ilgro...@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

[Francesco Chicchiriccò]

On 10/05/21 14:05, Martin van Es wrote:



On Mon, May 10, 2021 at 9:07 AM Francesco Chicchiriccò mailto:ilgro...@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 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

[Martin van Es]

On Mon, May 10, 2021 at 9:07 AM Francesco Chicchiriccò 
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

[Francesco Chicchiriccò]

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 mailto:mrva...@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

[Francesco Chicchiriccò]

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/

Re: Global uniqueness requirement of username

[Martin van Es]

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  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

Global uniqueness requirement of username

[Martin van Es]

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