[midPoint] LDAP role/group inducement

[Jan Lievens]

Hi all,

I have reduced the complexity of my use case and made it easy to reproduce.
Starting from the unix story (
https://wiki.evolveum.com/display/midPoint/Unix+Story+Test)
Now I have the following situation:
 - Sync accounts from CSV to OpenDJ (works great)
 - I have one meta-role that is assigned to a test role which results in an
LDAP group (works great)
 - Then I assign this test role to a user which results in a uniqueMember
attribute on the LDAP group (nice)
 - Then I unassign the test role from said user and the uniqueMember
attribute on the LDAP group is not getting removed (😭)
 - The uniqueMember attribute cannot be removed even after running
reconcile/recompute on accounts and entitlements

More succinct description to reproduce:
- git checkout https://github.com/jalieven/midpoint-docker
- cd midpoint-docker
- git checkout simple-ldap-group
- 'make restart' (starts docker with postgres/opendj/midpoint)
- go to admin GUI http://localhost:8080/midpoint
- login 'administrator' pwd '5ecr3t'
- create a new role 'TestGroup' with an assignment to role 'LDAP Group
Metarole'
[- in OpenDJ: be.didm.group.TestGroup is created] => OK (checking can be
done with 'make check_ldap' in root project)
- in admin GUI: add 'TestGroup' to 'user01' assignments
[- in OpenDJ: the be.didm.group.TestGroup gets the attribute uniqueMember
set to 'uid=user01,ou=people,dc=didm,dc=be'] => OK
- in admin GUI: remove 'TestGroup' from 'user01' assignments (minus button
and SAVE)
[- in OpenDJ: nothing happens: uniqueMember is not removed from
be.didm.group.TestGroup] => Not OK!
- to verify this stale uniqueMember attribute: in root of project do 'make
check_ldap'

Config files can be found in
demo/simple/midpoint_server/container_files/mp-home/post-initial-objects

As you can see reproducing this bug/miss-config takes 5min of work. If this
is a miss-configuration you might want to check because the same is
happening in the unix story test. If this is a bug in midPoint all the more
so to look at it. It is hard for me as a novice to say which one it is.

It seems to me that this is a common use-case. I have come across this
issue a few times in this mailing list, none of which provide a sufficient
solution:
http://lists.evolveum.com/pipermail/midpoint/2016-April/001720.html (the
'it-works-on-my-machine'-stance is kind of lame in this case and it doesn't
help that the referred zip files does not resolve)
http://lists.evolveum.com/pipermail/midpoint/2016-November/002807.html (a
lot of tolerant/strength stuff here)
http://lists.evolveum.com/pipermail/midpoint/2016-November/002843.html
(suggests association shortcuts and multivalued schema fix in scripted sql
connector, the latter of which does not apply in my described use-case)

The midPoint Confluence suggests also to set various packages to trace log
level to debug what is going on but I must say that in so much logging I
have no idea what to look for.
When I set the projector/clockwork to debug all I see is that the remove of
the association is not happening. More specifically this package on
trace org.identityconnectors.framework.spi.operations points to the fact
that the delete is not happening in the connector.

May I also add that the page
https://wiki.evolveum.com/display/midPoint/Initial+Logging+Setup+HOWTO is
not up to date. Setting the skipRepositoryLoggingSettings does not work. So
there is currently no way to add specific loggers at start up through the
logback(-extra).xml. It always gets overwritten by what is inside the
repository.
It appears that the skipRepositoryLoggingSettings was removed from the code
some time ago.

Kind Regards,
Jan Lievens

Op wo 15 jan. 2020 om 16:19 schreef Jan Lievens <jan.lievens at biggerfish.be>:

> Hi,
>
> I have a question related to inducement construction on a role toward an
> LDAP resource.
> I have the following situation in midPoint (see the attachment for all the
> xml files)
> - Accounts and Entitlements (intent: privileges) are imported from a
> ScriptedSQL connector.
> - These imported entitlements have multiple privileges which are created
> as roles with an "assignmentTargetSearch"
> (post-initial-objects/210-entitlement-object-template.xml)
> - I also have these privilege/roles defined with an assignment to
> (multiple) fixed technical roles (kind:entitlement/intent:group).
> - Lastly I would like for these technical roles (groups) and the
> associated accounts to get synced to LDAP in an objectToSubject fashion. I
> do this with inducements and construction tags in
> post-initial-objects/100-profiles-webidm.xml.
> - The result I get in LDAP is that accounts are synced correctly but the
> group names are not what I expect (I expect technical role names
> eg. JiraUser) but get the names of the Entitlements (intent:privileges)
> defined in the DB.
> - Additionally the associations are not synced (no uniqueMember refs are
> synced on the LDAP groups).
>
> Surely I am missing something here. I think this use case is quiet
> standard (a hierarchy of roles and only the leafs get synced to LDAP).
> I have experimented with the order of the inducement but these came out
> even more negative (no accounts or groups were created).
> I also have experimented with the tolerant setting on the association
> (since I find a lot of answers in this mailing list suggesting this) but to
> no avail.
> It is quiet frustrating to be so close to having this use-case implemented
> DB->mP->LDAP but failing in the sync to LDAP.
>
> Kind regards,
> --
> Jan Lievens
> IT Consultant
>
>

-- 
Jan Lievens
IT Consultant
Bigger Fish
Hoogstraat 35
9450 Haaltert
Belgium
VAT: BE 0734.993.447
Mob: +32 494 84 66 97
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20200121/669524f6/attachment.htm>