Re: LDAP hierarchy mapping

[Francesco Chicchiriccò]

On 03/04/2018 20:29, varontron wrote:

Hi,

Wondering about the best way to map an ldap hierarchy in 2.0.8...

Use Case:
---
All P and S entities are instances of 'groupOfNames' ObjectClasses, with DNs
like:
cn=P1,ou=groups,dc=ldap,dc=example,dc=com
cn=S3,cn=P1,ou=groups,dc=ldap,dc=example,dc=com
cn=S3,cn=P2,ou=groups,dc=ldap,dc=example,dc=com




I considered a flat mapping of users to each of the “P” level and “S” level,
however that confounds the requirements.  For example, if UserA is a member
of S3 and P2, and also S2 and P1, a flatter User-to-Group mapping would not
be able to distinguish the restriction of UserA from S3/P1 stuff.  Only a
pre-existing relationship between P and S level, that is then, in turn,
mapped to the user seems to suffice.

What is the most effective method for mapping this hierarchy in Syncope
2.0.8?

Is there a jexl expression for ObjectLink which would preserve this
relationship “as is” with a “cn” or each level (i.e., DN=“cn=S3,cn=P1,ou…?”
or DN=“cn=S4,cn=P1,ou…”)
Is “realms” the way to go, perhaps mapping all “P” levels to realms and “S”
levels to GROUP types?
Are custom anytypes (e.g., “P AnyType” an “S AnyType”) applicable?
Some other option?
You're doing it wrong?

Any insight you can provide will be most helpful.



Not sure if you have solved in the meanwhile, but this should help:

https://syncope.apache.org/docs/reference-guide.html#object-link-realms-hierarchy

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