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

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  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  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  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__,
> > > Value=[o=Foobarb,dc=scz,dc=vnet]}}  Method: handle
> > > 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=[Foobar2]},
> > > ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute:
> > > {Name=__NAME__, Value=[o=Foobar2,dc=scz,dc=vnet]}, Attribute:
> > > {Name=__UID__, Value=[Foobar2]}, Attribute: {Name=l,
Value=[/Foobar2]},
> > > Attribute: 

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

Re: Provisioning Realms

[Andrea Patricelli]

Hi Martin,

first of all I suggest to refer to this blog post [1] to have a 
reference on how con configure (also) mapping for realm provisioning.



Il 03/05/2018 12:14, Martin van Es ha scritto:

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?

Not at all.


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

Please check if realm path is correctly created on Syncope.


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]
While pulling realms you need to correctly manage the realm matching, 
please refer to the blog post to correctly configure realms pull 
(§Advanced: Pull Organizational Units as Syncope Realms).

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

HTH,
Andrea

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

--
Dott. Andrea Patricelli
Tel. +39 3204524292

Developer @ Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 085973
http://www.tirasa.net

Apache Syncope PMC Member