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

[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

[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

[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

[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

[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

Re: Resource specific counters in Syncope

[Martin van Es]

Hi Francesco,

Thx for the quick reply!

On Wed, Oct 7, 2020 at 11:18 AM Francesco Chicchiriccò 
wrote:

> Hi Martin,
> so you'd want to keep different counters for different External Resources,
> and inject appropriate values from such counters during propagation, to
> populate attributes like as uidNumber and gidNumber, for example.
>

Yes

I think it can be as straightforward as (1) defining appropriate
> configuration parameters to hold counter values and (2) creating
> PropagationActions classes to implement the value injection and counter
> increment logic.
>

Which implies development effort (albeit a little)? Would there be a
"lightweight" possibility via scripts?
Would the configuration parameters be like External Resource specific
variables that can be manipulated at will?

Best regards
Martin

Resource specific counters in Syncope

[Martin van Es]

Hi,

It's been a while since I last took a look at Syncope but we have recently
decided that it may fill a gap in our provisioning landscape.

Our project is brought to life to enable collaborative organisations for
research projects in the Netherlands. As is normal in the education world,
authorisation and authentication is done using federation protocols like
SAML and OIDC which we provide, but some relying parties need a specific
directory structure for legacy applications that we want to provide, or at
least help them with, but we don't want to give them access to our master
directory for read-only purposes.

One of the challenges in this landscape is that some relying parties need
POSIX compliant entries (uidNumber + gidNumber) but they are resource
specific. Ranges will be different across targets and we might need to
reuse existing uid/gidNumbers during migration.

So, (I think) we need (to keep track of) resource specific counters.
Would this be straightforward or in some way possible using Syncope?

Best regards,
Martin
-- 
If 'but' was any useful, it would be a logic operator

Re: Provisioning Realms

[Martin van Es]

We have nested groups living under separate organizations (o) and we reuse
groupnames like this:
cn=CO_members_all,ou=Groups,o=Foobar,dc=scz,dc=vnet
cn=CO_members_all,ou=Groups,o=Foobar2,dc=scz,dc=vnet

While importing (pull) groups from dc=scz,dc=vnet I created a template to
put groups in the realm belonging to the o the group lives under, which
works for the group under o=Foobar. The second group, which would be placed
under a different realm gets a unique naming constraint violation? How
unique do groupnames have to be in Syncope? My impression was that they
needed to be unique in a realm, not globally, but that is apparently a
misconception?

I've tried to set the naming attribute to entryDN instead of cn, but that
results in InvalidName failure, again:

Groups failed to create: CREATE FAILURE (key/name):
null/cn=CO_members_all,ou=Groups,o=Foobar2,dc=scz,dc=vnet with message:
InvalidEntityException: JPAGroup [InvalidName]

Best regards,
Martin
On Tue, May 8, 2018 at 9:53 AM Martin van Es <mrva...@gmail.com> wrote:

> I see that renaming Realms isn't forbidding in console, so keeping track
of
> the o's via entryUUID and renaming Realms should be possible if only I
knew
> how to configure that?
> As soon as I replace 'Account Uid' with entryUUID in resource the second
> pull allways results in inserts, failing unique naming constraints,
instead
> of updates.

> Another question: our groups have quite awkward names, e.g.
> "CO:members:all".
> While pull'ing I get the following error:

> Groups failed to create: CREATE FAILURE (key/name): null/CO:members:all
> with message: InvalidEntityException: JPAGroup [InvalidName,
> InvalidPlainAttr]
> CREATE FAILURE (key/name): null/CO:members:all with message:
> InvalidEntityException: JPAGroup [InvalidName, InvalidPlainAttr]

> Is it the colon in the groupname? And if so, is there a simple JEXL
> expression to replace them with a valid separation character?

> Best regards,
> Martin
> On Mon, May 7, 2018 at 4:50 PM Martin van Es <mrva...@gmail.com> wrote:

> > The only minor remaining problem: 'o' moves are not detected, because
> > there's no way I can find a way to link the realm to the source's
> entryUUID?
> > The result is there is a stale oldname realm left, and a new newname
realm
> > created.
> > On Mon, May 7, 2018 at 4:25 PM Martin van Es <mrva...@gmail.com> wrote:

> > > Fixed it. Setting 'Uid Attribute' = 'o', did the trick!
> > > Thx!

> > > Best regards,
> > > Martin
> > > On Mon, May 7, 2018 at 3:45 PM Martin van Es <mrva...@gmail.com>
wrote:

> > > > Thx for the answer.

> > > > I inspected the resource-ldap-orgunit and discoverd the omission of
> the
> > > > fullpath mapping for realms, which is mapped to LDAP l attribute.
I've
> > > > added an l attribute to my organisations and mapped that to
fullpath,
> > but
> > > > then the persistence class complains about a malformed realm path:
> > > > org.apache.syncope.core.persistence.api.dao.MalformedPathException:
> The
> > > > provided realm path is malformed: Foobar

> > > > What would the correct syntax of realm path look like? I don't see
any
> > > JEXL
> > > > transformations for both fullpath or name in the
resource-ldap-orgunit
> > > > example?

> > > > Some testing reveals the above Foobar is extracted from the o=
> > attribute,
> > > > which I mapped to 'name', which very much resembles the mapping of
ou
> to
> > > > name in the resource-ldap-orgunit example.
> > > > What's wrong with that as a path?

> > > > Here's the complete logging from my test setup:

> > > > 13:36:46.230 DEBUG Enter: search(ObjectClass: __ACCOUNT__, null,
> > > >
> org.apache.syncope.core.provisioning.java.ConnectorFacadeProxy$2@aabea88
> > ,
> > > > OperationOptions:




{PAGED_RESULTS_OFFSET:-1,ATTRS_TO_GET:[__NAME__,__UID__,l,__ENABLE__,o],PAGE_SIZE:100})
> > > >  Method: search
> > > > 13:36:46.232 DEBUG Enter: executeQuery(ObjectClass: __ACCOUNT__,
null,




org.identityconnectors.framework.impl.api.local.operations.SearchImpl$1@5ba5c871
> > > ,
> > > > OperationOptions:




{PAGED_RESULTS_OFFSET:-1,ATTRS_TO_GET:[__NAME__,__UID__,l,__ENABLE__,o],PAGE_SIZE:100})
> > > >Method: executeQuery
> > > > 13:36:46.232 WARN  Attribute __ENABLE__ of object class __ACCOUNT__
is
> > not
> > > > mapped to an LDAP attribute  Method: getLdapAttribute
> > > > 13:36:46.233 DEBUG Searching in [dc=scz,dc=vnet] with filter
> > > > (&(objectClass=organization)(!(objectClass=dcObject))) a

Re: Provisioning Realms

[Martin van Es]

I see that renaming Realms isn't forbidding in console, so keeping track of
the o's via entryUUID and renaming Realms should be possible if only I knew
how to configure that?
As soon as I replace 'Account Uid' with entryUUID in resource the second
pull allways results in inserts, failing unique naming constraints, instead
of updates.

Another question: our groups have quite awkward names, e.g.
"CO:members:all".
While pull'ing I get the following error:

Groups failed to create: CREATE FAILURE (key/name): null/CO:members:all
with message: InvalidEntityException: JPAGroup [InvalidName,
InvalidPlainAttr]
CREATE FAILURE (key/name): null/CO:members:all with message:
InvalidEntityException: JPAGroup [InvalidName, InvalidPlainAttr]

Is it the colon in the groupname? And if so, is there a simple JEXL
expression to replace them with a valid separation character?

Best regards,
Martin
On Mon, May 7, 2018 at 4:50 PM Martin van Es <mrva...@gmail.com> wrote:

> The only minor remaining problem: 'o' moves are not detected, because
> there's no way I can find a way to link the realm to the source's
entryUUID?
> The result is there is a stale oldname realm left, and a new newname realm
> created.
> On Mon, May 7, 2018 at 4:25 PM Martin van Es <mrva...@gmail.com> wrote:

> > Fixed it. Setting 'Uid Attribute' = 'o', did the trick!
> > Thx!

> > Best regards,
> > Martin
> > On Mon, May 7, 2018 at 3:45 PM Martin van Es <mrva...@gmail.com> wrote:

> > > Thx for the answer.

> > > I inspected the resource-ldap-orgunit and discoverd the omission of
the
> > > fullpath mapping for realms, which is mapped to LDAP l attribute. I've
> > > added an l attribute to my organisations and mapped that to fullpath,
> but
> > > then the persistence class complains about a malformed realm path:
> > > org.apache.syncope.core.persistence.api.dao.MalformedPathException:
The
> > > provided realm path is malformed: Foobar

> > > What would the correct syntax of realm path look like? I don't see any
> > JEXL
> > > transformations for both fullpath or name in the resource-ldap-orgunit
> > > example?

> > > Some testing reveals the above Foobar is extracted from the o=
> attribute,
> > > which I mapped to 'name', which very much resembles the mapping of ou
to
> > > name in the resource-ldap-orgunit example.
> > > What's wrong with that as a path?

> > > Here's the complete logging from my test setup:

> > > 13:36:46.230 DEBUG Enter: search(ObjectClass: __ACCOUNT__, null,
> > >
org.apache.syncope.core.provisioning.java.ConnectorFacadeProxy$2@aabea88
> ,
> > > OperationOptions:



{PAGED_RESULTS_OFFSET:-1,ATTRS_TO_GET:[__NAME__,__UID__,l,__ENABLE__,o],PAGE_SIZE:100})
> > >  Method: search
> > > 13:36:46.232 DEBUG Enter: executeQuery(ObjectClass: __ACCOUNT__, null,



org.identityconnectors.framework.impl.api.local.operations.SearchImpl$1@5ba5c871
> > ,
> > > OperationOptions:



{PAGED_RESULTS_OFFSET:-1,ATTRS_TO_GET:[__NAME__,__UID__,l,__ENABLE__,o],PAGE_SIZE:100})
> > >Method: executeQuery
> > > 13:36:46.232 WARN  Attribute __ENABLE__ of object class __ACCOUNT__ is
> not
> > > mapped to an LDAP attribute  Method: getLdapAttribute
> > > 13:36:46.233 DEBUG Searching in [dc=scz,dc=vnet] with filter
> > > (&(objectClass=organization)(!(objectClass=dcObject))) and
> SearchControls:
> > > {returningAttributes=[l, o], scope=SUBTREE} Method: doSearch
> > > 13:36:46.240 WARN  Attribute __ENABLE__ of object class __ACCOUNT__ is
> not
> > > mapped to an LDAP attribute  Method: getLdapAttribute
> > > 13:36:46.240 DEBUG Enter: {Uid=Attribute: {Name=__UID__,
> Value=[Foobarb]},
> > > ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute:
> > > {Name=__NAME__, Value=[o=Foobarb,dc=scz,dc=vnet]}, Attribute:
> > > {Name=__UID__, Value=[Foobarb]}, Attribute: {Name=l,
Value=[/Foobara]},
> > > Attribute: {Name=__ENABLE__, Value=
> > > []}, Attribute: {Name=o, Value=[Foobarb]}], Name=Attribute:
> > {Name=__NAME__,
> > > Value=[o=Foobarb,dc=scz,dc=vnet]}}  Method: handle
> > > 13:36:46.240 DEBUG Return: true Method: handle
> > > 13:36:46.240 DEBUG Enter: {Uid=Attribute: {Name=__UID__,
> Value=[Foobarb]},
> > > ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute:
> > > {Name=__NAME__, Value=[o=Foobarb,dc=scz,dc=vnet]}, Attribute:
> > > {Name=__UID__, Value=[Foobarb]}, Attribute: {Name=l,
Value=[/Foobara]},
> > > Attribute: {Name=__ENABLE__, Value=
> > > []}, Attribute: {Name=o, Value=[Foobarb]}], Name=Attribute:
> > {Name=__NAME__,
> &

Re: Provisioning Realms

[Martin van Es]

Still stuck.
It would be really nice if somebody could explain how to create a REALM
pull policy or tell me that it's not a possibility at the moment?

I've created a new AnyType FOO of AnyTypeClass BaseUser, which gives me the
possibility to choose 'name' as PLAIN ATTRIBUTES Correlation Rule attribute
in Pull Policy 'Realm' which I can apply to the REALM Resource that pulls
in the realms, but I keep getting u_realm_name unique name constraints
violations on all following pulls.

Best regards,
Martin
On Thu, May 3, 2018 at 10:31 PM Martin van Es <mrva...@gmail.com> wrote:

> Ok, I'm a step further but still have problems.
> I encountered the same problems when pull'ing users and it turned out I
> needed to create a pull policy for users and assign that to my resource
for
> update conflict and correlation rules (I'm still learning the basics
here).
> Pull Update now works for users!

> It turns out, I can't find anything like that for REALMS? In the pull
> policy rule composer I can only choose USER or GROUP. When choosing USER,
I
> can only match on username, but the assigned internal REALM attribute is
> called 'name'. For GROUPS I can choose 'name', but then the policy doesn't
> work or apply?

> Also, I tried add a REALM key to AnyTypes to contain the 'name' attribute,
> but that's forbidden.

> Best regards,
> Martin
> On Thu, May 3, 2018 at 2:12 PM Martin van Es <mrva...@gmail.com> wrote:

> > Hi,

> > On Thu, May 3, 2018 at 12:43 PM Andrea Patricelli <
> > andreapatrice...@apache.org> wrote:

> > > > Realms created in the root realm:
> > > > CREATE SUCCESS (key/name):
> 3a3370df-3aa2-4787-b370-df3aa2278786///Foobar
> > > > CREATE SUCCESS (key/name):
> > 38d90785-ab9c-4fc8-9907-85ab9c2fc8e4///Foobar2
> > > > CREATE SUCCESS (key/name):
> > b3c86117-400b-457d-8861-17400bf57d5d///Foobar3
> > > Please check if realm path is correctly created on Syncope.

> > The Foobar realm's path is /Foobar, as expected.

> > > [1] http://blog.tirasa.net/syncope-basics-manage-active-directory.html

> > I've checked the blog and since it's intended for AD I have to mold it
> into
> > LDAP only configuration a bit. Also, my realms come from organizations
> > instead of organizationalUnit, but I assume that doesn't matter for the
> > excersice. I have done that to the best of my knowledge, knowing that
> > mapping organization only wouldn't apply the (!(objectClass=dcObject))
> > filter, effectively resulting in one too many Realms, but I could live
> with
> > that. The original problem however still remains: consecutively pulling
in
> > the Realms results in unique key violoations.

> > Since I deployed Syncope from debian packages I'm not in a position to
> > develop, compile and deploy custom pull Actions. Also, I accept the
Realms
> > being inserted in a flat hierarchy, so I don't need any special mapping
I
> > hope?

> > 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: Provisioning Realms

[Martin van Es]

Hi,

On Thu, May 3, 2018 at 12:43 PM Andrea Patricelli <
andreapatrice...@apache.org> wrote:

> > Realms created in the root realm:
> > CREATE SUCCESS (key/name): 3a3370df-3aa2-4787-b370-df3aa2278786///Foobar
> > CREATE SUCCESS (key/name):
38d90785-ab9c-4fc8-9907-85ab9c2fc8e4///Foobar2
> > CREATE SUCCESS (key/name):
b3c86117-400b-457d-8861-17400bf57d5d///Foobar3
> Please check if realm path is correctly created on Syncope.

The Foobar realm's path is /Foobar, as expected.

> [1] http://blog.tirasa.net/syncope-basics-manage-active-directory.html

I've checked the blog and since it's intended for AD I have to mold it into
LDAP only configuration a bit. Also, my realms come from organizations
instead of organizationalUnit, but I assume that doesn't matter for the
excersice. I have done that to the best of my knowledge, knowing that
mapping organization only wouldn't apply the (!(objectClass=dcObject))
filter, effectively resulting in one too many Realms, but I could live with
that. The original problem however still remains: consecutively pulling in
the Realms results in unique key violoations.

Since I deployed Syncope from debian packages I'm not in a position to
develop, compile and deploy custom pull Actions. Also, I accept the Realms
being inserted in a flat hierarchy, so I don't need any special mapping I
hope?

Best regards,
Martin

Provisioning Realms

[Martin van Es]

Hi,

This is related to my earlier question about creating Realms based on
dynamic VO's (organized as o= entities in LDAP).

I'm trying to get FULL RECONCILIATION working, which succeeds for the first
time, but results in unique "u_realm_name" constraint violations on second
attempt, even though I have set matching rule to ignore. So, it seems
syncope has no way of understand what realms are allready provisioned and
this is intended as a one-time provision action?

The setup uses the __ACCOUNT__ objectclass, because that's the only way I
got the search code to apply my object filter (I don't want objects of
objectClass=dcObject). Mapping to organization only doesn't apply this
filter.

In the mapping, I assign internal 'name' to  external 'o' (Remote Key,
purpose: <-) and use Object link 'o='+name+',dc=scz,dc=vnet'.

I set the resource Account objectClass to organization and LDAP Filter for
Retrieving Accounts to (!(objectClass=dcObject)). I can see this working
correctly when I explore the resource.

First time pull results in these succeful actions:
Realms [created/failures]: 3/0 [updated/failures]: 0/0 [deleted/failures]:
0/0 [no operation/ignored]: 0/0

Realms created in the root realm:
CREATE SUCCESS (key/name): 3a3370df-3aa2-4787-b370-df3aa2278786///Foobar
CREATE SUCCESS (key/name): 38d90785-ab9c-4fc8-9907-85ab9c2fc8e4///Foobar2
CREATE SUCCESS (key/name): b3c86117-400b-457d-8861-17400bf57d5d///Foobar3

But all succesive attempts result in these exceptions in the
core-connid.log (abbreviated for readability):

org.apache.openjpa.persistence.EntityExistsException: The transaction has
been rolled back.  See the nested exceptions for details on the errors that
occurred.

Caused by: org.apache.openjpa.persistence.EntityExistsException: ERROR:
duplicate key value violates unique constraint "u_realm_name"
  Detail: Key (name, parent_id)=(Foobar,
ea696a4f-e77a-4ef1-be67-8f8093bc8686) already exists. {prepstmnt 220401755
INSERT INTO Realm (id, name, ACCOUNTPOLICY_ID, PARENT_ID,
PASSWORDPOLICY_ID) VALUES (?, ?, ?, ?, ?)} [code=0, state=23505]

If I set matching policy to update, this should never result in an INSERT,
so it's clear there is no match and the provisioner tries to "provision".

Best regards,
Martin
-- 
If 'but' was any useful, it would be a logic operator

Infer (virtual) organisation from DN only

[Martin van Es]

Hi,

I was playing around with syncope to manage people in dynamically created
virtual organisations. Would it be possible to deduce their VO and
dynamically assign realm only by their DN (from ,o=,) without syncope
coding effort and without having to create a new resource? Someting like a
regular expresion group match on the DN?

Best regards,
Martin
-- 
If 'but' was any useful, it would be a logic operator

Re: CSVDir pull connector challenge

[Martin van Es]

On Tue, Jan 24, 2017 at 10:03 AM, Francesco Chicchiriccò
 wrote:
>> So, you suggest I turn to Connid now for my functional issues with CSVDir?
>
>
> I would first clarify if there is something wrong ongoing (as suggested
> above), then possibly report to ConnId.

I was referring to the required explicit __NAME_ or __UID__ remote key
mapping to make CSVDir actually work in syncope and/or the absence of
a selectable key attribute when configuring the mapping.

Best regards,
Martin

Re: CSVDir pull connector challenge

[Martin van Es]

On Mon, Jan 23, 2017 at 4:36 PM, Francesco Chicchiriccò
 wrote:
> but essentially, the "mandatory condition" can be specified both at Schema
> level (hence value(s) must be provided globally) or at mapping level (hence
> value(s) must be provided when provisioning to / from that external
> resource).

Ok, that's clear.
But that doesn't explain why email wouldn't propagate from my CSVDir
source into Syncope when the mandatory flag was false?

> Anyway, as commented there, the real issue in only about the failure to
> report the error message to Admin UI; the rest is about the way how the
> ConnId CSVDir bundle works, so not any Syncope issue.

So, you suggest I turn to Connid now for my functional issues with CSVDir?

Regards,
Martin

CSVDir pull connector challenge

[Martin van Es]

Hi,

Finally, I've taken the time and went ahead (re)installing Syncope to
try and play with 2.0.
First: it's a nice improvement (on the admin interface). Well done!

I've (re) created my test LDAP connector and am able to
provision/activate/enable/disable users and groups/groupMembership
from admin console.

Now I'd like to emulate an authoritative source connector (e.g. HR)
from CSVDir connector. I supply five columns in this file called
id,email,sn,status and delete. I inserted a header line designating
these columns and exactly one test account as 2nd line. Values are
separated by comma's.

I created the connector and resource to follow the columnames/order in
my file, but when I try to setup user provision rules, two thing
surprise me:

I can't select target columns that are designated for key, status and
delete by the connector. Is this by-design?

Second, when I finish the provisioning rules (mapping surname to sn
and email to email, because that's all that's available on target) by
clicking "Save" in the last dialog, Syncope fails with error: "Unable
to find property: 'connObjectKeyValidation'. Locale: null, style:
null"

This is the full error in console.log:

13:23:26.249 ERROR
org.apache.syncope.client.console.panels.AbstractModalPanel - While
creating or updating
org.apache.syncope.common.lib.to.ResourceTO@4e48ade6[
 key=CSV local
 connector=3e972c1b-d06f-45dc-972c-1bd06f35dc0e
 connectorDisplayName=CSV import
 provisions=[org.apache.syncope.common.lib.to.ProvisionTO@375fcfeb[
 key=
 anyType=USER
 objectClass=__ACCOUNT__
 auxClasses=[]
 syncToken=
 mapping=org.apache.syncope.common.lib.to.MappingTO@16fab764[
 connObjectLink=
 items=[org.apache.syncope.common.lib.to.MappingItemTO@5b25b01e[
 key=
 intAttrName=surname
 extAttrName=sn
 connObjectKey=false
 password=false
 mandatoryCondition=false
 purpose=PULL
 propagationJEXLTransformer=
 pullJEXLTransformer=
 mappingItemTransformerClassNames=[]
], org.apache.syncope.common.lib.to.MappingItemTO@2dfaeed6[
 key=
 intAttrName=email
 extAttrName=email
 connObjectKey=false
 password=false
 mandatoryCondition=false
 purpose=PULL
 propagationJEXLTransformer=
 pullJEXLTransformer=
 mappingItemTransformerClassNames=[]
]]
 linkingItems=[]
]
 virSchemas=[]
]]
 orgUnit=
 propagationPriority=0
 randomPwdIfNotProvided=true
 enforceMandatoryCondition=false
 createTraceLevel=ALL
 updateTraceLevel=ALL
 deleteTraceLevel=ALL
 provisioningTraceLevel=ALL
 passwordPolicy=
 accountPolicy=
 pullPolicy=
 confOverride=[]
 overrideCapabilities=false
 capabilitiesOverride=[SYNC]
 propagationActionsClassNames=[]
]
java.util.MissingResourceException: Unable to find property:
'connObjectKeyValidation'. Locale: null, style: null
   at org.apache.wicket.Localizer.getString(Localizer.java:268)
~[wicket-core-7.4.0.jar:7.4.0]
   at 
org.apache.wicket.model.StringResourceModel.getString(StringResourceModel.java:439)
~[wicket-core-7.4.0.jar:7.4.0]
   at 
org.apache.wicket.model.StringResourceModel.getString(StringResourceModel.java:424)
~[wicket-core-7.4.0.jar:7.4.0]
   at 
org.apache.syncope.client.console.wizards.resources.ResourceProvisionPanel.onSubmit(ResourceProvisionPanel.java:323)
~[syncope-client-console-2.0.1.jar:2.0.1]
   at 
org.apache.syncope.client.console.wicket.markup.html.bootstrap.dialog.BaseModal$2.onSubmit(BaseModal.java:203)
~[syncope-client-console-2.0.1.jar:2.0.1]
   at 
org.apache.wicket.ajax.markup.html.form.AjaxSubmitLink$1.onSubmit(AjaxSubmitLink.java:111)
~[wicket-core-7.4.0.jar:7.4.0]
   at 
org.apache.wicket.ajax.form.AjaxFormSubmitBehavior$AjaxFormSubmitter.onSubmit(AjaxFormSubmitBehavior.java:215)
~[wicket-core-7.4.0.jar:7.4.0]
   at org.apache.wicket.markup.html.form.Form.delegateSubmit(Form.java:1307)
~[wicket-core-7.4.0.jar:7.4.0]
   at org.apache.wicket.markup.html.form.Form.process(Form.java:974)
~[wicket-core-7.4.0.jar:7.4.0]
   at org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:795)
~[wicket-core-7.4.0.jar:7.4.0]
   at 
org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:171)
~[wicket-core-7.4.0.jar:7.4.0]
   at 
org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:155)
~[wicket-core-7.4.0.jar:7.4.0]
   at 
org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:601)
~[wicket-core-7.4.0.jar:7.4.0]
   at sun.reflect.GeneratedMethodAccessor471.invoke(Unknown Source) ~[?:?]
   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:1.8.0_111]
   at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_111]
   at 
org.apache.wicket.RequestListenerInterface.internalInvoke(RequestListenerInterface.java:258)
~[wicket-core-7.4.0.jar:7.4.0]
   at 
org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:241)
~[wicket-core-7.4.0.jar:7.4.0]
   at 

Re: Multiple Role Approval Requests

[Martin van Es]

Hi,

On Tue, Jan 26, 2016 at 8:51 AM, Francesco Chicchiriccò <ilgro...@apache.org
> wrote:

> On 22/01/2016 14:11, Martin van Es wrote:
>
>> Hoping nobody minds stealing this thread I'd like to ask how (simple)
>> approvals are enabled in the first place? I've updated to 1.2.7 and both
>> created a user in self-service and assigned a role to an existing one, but
>> neither triggered an approval task for admin (and both tasks completely
>> finished)? Does the default workflow support approvals, or do I need to
>> change that in the first place to trigger approvals anyway?
>>
>
> Hi,
> you can take a look at
>
> http://blog.tirasa.net/approval-process-syncope.html
>
>
Thx. I found that, but I hoped "simple" approvals were available out of the
box in syncope.


> Please consider that in recent releases the default workflow definition is
> not configured for any approval.
>

Which explains my findings.
I'll take a look at the tirasa blog.

Regards,
Martin

Re: Remove role membership fails

[Martin van Es]

Hmm... can't reproduce since Chrome update and restart.
Consider mail below as unsent, or just listnoise ;)

Best regards,
Martin

On Tue, Dec 15, 2015 at 4:00 PM, Martin van Es <mrva...@gmail.com> wrote:

> Hi,
>
> I just reinstalled my syncope test installation (1.2.6) and succesfully
> reconfigured LDAP provisioning including groupmembership. Getting better at
> this every time ;)
>
> But!
>
> If I try to remove a user from a role, the "delete" link is dead, it
> doesn't do anything (really nothing happpens in Syncope console). If I try
> to bulk remove a user from the user tab in a role, the same happens when I
> click the red cross (nothing). This is independant of the user and/or role
> having the LDAP resource assigned.
>
> Am I missing a feature in Syncope?
>
> Ah, update: in Chrome only. This doesn't happen in Firefox.
> Chrome version: 47.0.2526.80 (64-bit)
>
> Even the Javascript debugger in Chrome is silent, it looks like there is
> no function bound to the 'delete' link at all?
>
> 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

Remove role membership fails

[Martin van Es]

Hi,

I just reinstalled my syncope test installation (1.2.6) and succesfully
reconfigured LDAP provisioning including groupmembership. Getting better at
this every time ;)

But!

If I try to remove a user from a role, the "delete" link is dead, it
doesn't do anything (really nothing happpens in Syncope console). If I try
to bulk remove a user from the user tab in a role, the same happens when I
click the red cross (nothing). This is independant of the user and/or role
having the LDAP resource assigned.

Am I missing a feature in Syncope?

Ah, update: in Chrome only. This doesn't happen in Firefox.
Chrome version: 47.0.2526.80 (64-bit)

Even the Javascript debugger in Chrome is silent, it looks like there is no
function bound to the 'delete' link at all?

Best regards,
Martin
-- 
If 'but' was any useful, it would be a logic operator

Can't change admin pwd

[Martin van Es]

Hi,

I followed the instructions on
https://cwiki.apache.org/confluence/display/SYNCOPE/Set+administrator+credentials#Setadministratorcredentials-GNU/LinuxandMacOSX.1

but the admin password is still password, no matter how often I restart tomcat.

I used the deb installation for 1.2.5.


Best regards,
Martin van Es
-- 
If 'but' was any useful, it would be a logic operator

Re: PWM as password manager

[Martin van Es]

Hi Francesco,

On Thu, Nov 6, 2014 at 4:34 PM, Francesco Chicchiriccò
ilgro...@apache.org wrote:
 On 05/11/2014 19:09, Martin van Es wrote:
 Hope this clarifies my endavours a bit.


 Only a bit, actually :-)

 But still I don't get why you are not just using AES on Syncope: any
 propagation will then be able to re-obtain clear-text password.
 Isn't this that you just need?

Yes, AES is key to my quest, but I want PWM to be the point where
people set and reset their password, not Syncope. PWM can only talk to
LDAP so I need to temporary write password plaintext to LDAP so
Syncope can pick it up. I don't want any plaintext password left in
LDAP after succesful synchronisation from LDAP to Syncope and back.
This can be accomplished by propagating the now AES encrypted password
in Syncope back to LDAP as SSHA hash (so far, so good).

But now, if I resync LDAP, the SSHA hash gets synced to Syncope,
because there is no plaintext password anymore and at this point I
loose the AES decryptable password in Syncopy. There is no way I can
tell Syncope to only accept plaintext passwords from LDAP and not the
SSHA hashed ones.

Regards,
Martin

Re: PWM as password manager

[Martin van Es]

HI Francesco,

On Thu, Nov 6, 2014 at 5:36 PM, Francesco Chicchiriccò
ilgro...@apache.org wrote:

 Ok, then you need a synchronization action class that, when synchronizing
 from LDAP will inspect the password value and remove it from synchronization
 attributes if the password values starts with {SSHA}.

I was hoping I could solve this without programming ;)
Maybe one day I will pick up this challenge...

Regards,
Martin

Re: PWM as password manager

[Martin van Es]

Hi Francesco,

I managed to set pwd in PWM (cleartext in LDAP), sync (full reconcile)
to Syncope and (re)propagate the same password SSHA hashed back to
LDAP.
This scenario more or less fulfills my desired test scenario, apart
from the short time the password lives unencrypted in LDAP, but which
is hard to overcome without changing PWM (or slapd).

I'll try to write-up something for the how-to page.

Thx for the patient answers and advice!

Regards,
Martin

On Tue, Oct 28, 2014 at 8:41 AM, Francesco Chicchiriccò
ilgro...@apache.org wrote:
 Hi Martin,
 here's some reply to your questions below.

 This hypothetical excercise would require a 2-way encrypted password setup
 between OpenLDAP and Syncope. Is this a possible scenario? Would PLAINTEXT
 Passwords in LDAP be the only solution?


 With Syncope 1.2.0 you can synchronize encrypted passwords from LDAP or DB
 resource and propagate (using the same cipher algorithm, of course) again to
 other LDAP / DB resources.
 For this to happen, usage of LDAPPasswordSyncActions / DBPasswordSyncActions
 (for synchronization) and LDAPPasswordPropagationActions /
 DBPasswordPropagationActions is required.

 Another option could be usage of passthrough authentication, again available
 with Syncope 1.2.0: you have the chance to define, in a relevant Account
 Policy, whether authentication (to Syncope core and console) is to be
 checked against one or more of external resources available.

 I just learned that the connid LDAP connector does not support sync,
 unless you're using Sun Directory Server Enterprise
 Edition? Is this true? Is there no sync possible from LDAP?


 In Syncope two types of synchronizations are supported (more info [1]), full
 (calling SEARCH on connectors to get all existing accounts / groups) and
 incremental (calling SYNC on connectors to get all modified accounts /
 groups since previous synchronization).

 The former is not as accurate as latter (for example, it cannot identify any
 delete on external resource) and also not as efficient (at every execution
 the whole content is requested by Syncope).

 The ConnId LDAP connector supports actual SYNC operation from former Sun
 DSEE (now Oracle DSEE), OpenDS / OpenDJ and Fedora 389 - and at least the
 latter is actually Open Source ;-)

 About OpenLDAP, there is a long-standing open issue [2] at ConnId about
 supporting SYNC - should you be interested in contributing, please join the
 discussion at connid-...@googelgroups.com.

 Of course, I'm looking at NetIQ/eDir/SSPR as a commercial example IdM
 system for my question. It would be nice if Syncope+OpenLDAP+PWM could do
 this trick as well ;)


 Well, should you succeed with a working setup satisfying the requirements
 you have in mind, it would be really nice to host a page on our wiki under
 the How do I...? section [3].

 Regards.

 [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Synchronization
 [2] https://connid.atlassian.net/browse/LDAP-1
 [3]
 https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=27841983


 On 27/10/2014 22:52, Martin van Es wrote:

 To answer myself, I thought I could tackle this by setting the
 password plaintext in LDAP using PWM (using a plaintext password_hash
 rule in slapd) and then sync it to Syncope and have it set by it's
 SSHA equivalent while propagating the change back to the directory.
 This way, the plaintext password would only exist in LDAP in a small
 time window between syncs?

 But alas, I just learned that the connid LDAP connector does not
 support sync, unless you're using Sun Directory Server Enterprise
 Edition? Is this true? Is there no sync possible from LDAP?

 Regards,
 Martin

 On Mon, Oct 27, 2014 at 7:53 PM, Martin van Es mrva...@gmail.com wrote:

 Hi,

 I'd like to use PWM for Password Self-service management, but that
 will only let me set passwords for users in an LDAP server.

 https://code.google.com/p/pwm/

 How would I make (Open)LDAP password leading for all passwords, but
 keep Syncope for propagating users (including passwords) to target
 applications? Of course, I could make all client applications
 authenticate agains LDAP, but that would solve the problem only in
 application layer and needs suitable applications. I'm trying to see
 if this problem also has a solution in data layer.

 This hypothetical excercise would require a 2-way encrypted password
 setup between OpenLDAP and Syncope. Is this a possible scenario? Would
 PLAINTEXT Passwords in LDAP be the only solution? Maybe changing PWM
 so that the password would be AES encrypted into a pwd transport
 attribute, which could be picked up by Syncope and propagated to LDAP
 and other applications?

 Of course, I'm looking at NetIQ/eDir/SSPR as a commercial example IdM
 system for my question. It would be nice if Syncope+OpenLDAP+PWM could
 do this trick as well ;)

 Regards,
 Martin


 --
 Francesco Chicchiriccò

 Tirasa - Open Source Excellence
 http://www.tirasa.net/

 Involved at The Apache Software

Re: Can't change password.cipher.algorithm into AES in console configuration

[Martin van Es]

Thx, workaround 1 did the job! ;)

Regards,
Martin

On Mon, Oct 27, 2014 at 1:39 PM, Francesco Chicchiriccò
ilgro...@apache.org wrote:
 On 27/10/2014 13:17, Martin van Es wrote:

 Hi,

 I've just started looking at Syncope again and installed 1.2.0 from
 debian packages on a fresh ubuntu 14.04LTS server. All works well, and
 I'm able to propagate a test user to a test OpenLDAP server, but not
 without reentering the user's password.

 I thought Syncope had acquired possibility to 2-way encrypt syncope
 password with AES so that it could be propagated?

 When I look at the Syncope configuration parameters in console, I see
 password.cipher.algorithm set to SHA1, so that probably should be set
 to AES. But whenever I do that and click save, when I return to the
 configuration page, it's set to SHA1 again. I found the corresponding
 setting in content.xml in the syncope/WEB-INF/class directory, but
 changing that to AES and restarting tomcat didn't help either (still
 SHA1).

 What am I doing wrong?


 Hi Martin,
 you are right, using AES to propagate password values without re-entering is
 supported since 1.1.0 [1].

 The problem you are experiencing ATM is SYNCOPE-576 [2] whose fix is planned
 for 1.2.1.

 The content.xml is transferred to the actual database only when no
 pre-existing content is found on it, so here's why you keep seeing SHA1;
 should you need to change any configuration file, please consider that using
 Syncope 1.2.0 DEB packages you can just go and modify it under
 /etc/apache-syncope, then restart Tomcat.

 While waiting for SYNCOPE-576 you still have option to

  1. change this value via REST (see reference [3] for more information) -
 e.g. via

 curl -u admin:password -X PUT -H Content-Type: application/json -H
 Accept: application/json -d '{values: [AES]}'
 http://host.port/syncope/rest/configurations/password.cipher.algorithm

  2. change this value in the underlying database table and restart Tomcat

 HTH
 Regards.

 [1] https://issues.apache.org/jira/browse/SYNCOPE-136
 [2] https://issues.apache.org/jira/browse/SYNCOPE-576
 [3] http://syncope.apache.org/rest/1.2/index.html

 --
 Francesco Chicchiriccò

 Tirasa - Open Source Excellence
 http://www.tirasa.net/

 Involved at The Apache Software Foundation:
 member, Syncope PMC chair, Cocoon PMC, Olingo PMC
 http://people.apache.org/~ilgrosso/





-- 
If 'but' was any useful, it would be a logic operator

PWM as password manager

[Martin van Es]

Hi,

I'd like to use PWM for Password Self-service management, but that
will only let me set passwords for users in an LDAP server.

https://code.google.com/p/pwm/

How would I make (Open)LDAP password leading for all passwords, but
keep Syncope for propagating users (including passwords) to target
applications? Of course, I could make all client applications
authenticate agains LDAP, but that would solve the problem only in
application layer and needs suitable applications. I'm trying to see
if this problem also has a solution in data layer.

This hypothetical excercise would require a 2-way encrypted password
setup between OpenLDAP and Syncope. Is this a possible scenario? Would
PLAINTEXT Passwords in LDAP be the only solution? Maybe changing PWM
so that the password would be AES encrypted into a pwd transport
attribute, which could be picked up by Syncope and propagated to LDAP
and other applications?

Of course, I'm looking at NetIQ/eDir/SSPR as a commercial example IdM
system for my question. It would be nice if Syncope+OpenLDAP+PWM could
do this trick as well ;)

Regards,
Martin
--
If 'but' was any useful, it would be a logic operator