[midPoint] LDAP role/group inducement

Tue Jan 21 15:50:01 CET 2020

Hi,

May I also add that I tried this setup with midPoint versions 4.0.1, 4.0
and 3.9 all with the same result (lingering uniqueMember attributes in
LDAP).

Op di 21 jan. 2020 om 14:47 schreef Jan Lievens <jan.lievens at biggerfish.be>:

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

-- 
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/142b9d70/attachment.htm>