Hi Martin,
short answer: your Realm mapping is not correct, hence during pull there
is no way for Syncope to match the incoming data with existing Realms.
You normally "fix" incomplete mappings with Pull policies, but as you
already discovered, Pull policies do not apply to Realms.
Hence, you have no choice but providing a good mapping for Realms.
I'd suggest to take a look at how the resource-ldap-orgunit is defined:
you can check it either via
http://syncope-vm.apache.org:9080/syncope-console/ or by downloading and
running the standalone distribution.
Regards.
On 07/05/2018 11:23, Martin van Es wrote:
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 <[email protected]> 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 <[email protected]> wrote:
Hi,
On Thu, May 3, 2018 at 12:43 PM Andrea Patricelli <
[email protected]> 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
--
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/
