[midPoint] Modification of role hierarchy not working

iam-mailing at tk.de iam-mailing at tk.de
Tue Oct 15 09:39:07 CEST 2019 

Hi there,

this seems to be a problem in our system, too.

I tried a few combinations with enforcement options an legalization:
As comparison I tried direct and indirect assignments. The 'Resurce-Role' creates a shadow in the resource
The 'User' has an assignment to the 'Root-Role'.

Enforcement

Legalization

Operation

Action

Shadow action

Expectation

relative

false

add

Root-Role => Resource-Role (inducement) + User reconcile

created and linked

ok

relative

false

remove

Root-Role => Resource-Role (inducement) + User reconcile

stays linked

should be removed

relative

false

add

User => Resource-Role (assignment)

created and linked

ok

relative

false

remove

User => Resource-Role (assignment)

deleted

ok

relative

true

add

Root-Role => Resource-Role (inducement) + User reconcile

created and linked

ok

relative

true

remove

Root-Role => Resource-Role (inducement) + User reconcile

stays linked because new Construction Assignment is created

should be removed

relative

true

add

User => Resource-Role (assignment)

created and linked

ok

relative

true

remove

User => Resource-Role (assignment)

deleted

ok

full

false

add

Root-Role => Resource-Role (inducement) + User reconcile

created and linked

ok

full

false

remove

Root-Role => Resource-Role (inducement) + User reconcile

deleted

ok

full

false

add

User => Resource-Role (assignment)

created and linked

ok

full

false

remove

User => Resource-Role (assignment)

deleted

ok

full

true

add

Root-Role => Resource-Role (inducement) + User reconcile

created and linked

ok

full

true

remove

Root-Role => Resource-Role (inducement) + User reconcile

stays linked because new Construction Assignment is created

should be removed

full

true

add

User => Resource-Role (assignment)

created and linked

ok

full

true

remove

User => Resource-Role (assignment)

deleted

ok


This seems to be a bug in the system…

Regards,
Henrik


Von: Arnošt Starosta - AMI Praha a.s. <arnost.starosta at ami.cz<mailto:arnost.starosta at ami.cz>>
Date: Di., 1. Okt. 2019, 11:04
Subject: Re: [midPoint] Modification of role hierarchy not working
To: midPoint General Discussion <midpoint at lists.evolveum.com<mailto:midpoint at lists.evolveum.com>>

Hi Tom,

as for the not-deleted-projection i believe you need to configure your projection policy and also check your schemaHandling/existence if changed.

see https://wiki.evolveum.com/display/midPoint/Projection+Policy

arnost

po 30. 9. 2019 v 17:52 odesílatel Tom Miller <tommillermp at gmail.com<mailto:tommillermp at gmail.com>> napsal:
Hi everyone!

Has anyone tried to modify an existing role yet?
It seems like changes in the role hierarchy are not distributed to the resources correctly after Recomputation.


1) The scenario starts like this:

  *   The user 'Testuser' has an assignment to the empty 'Root-Role'.
2) In the second step, I edit the role 'Root-Role':

  *   The 'Resource-Role' has an account construction inducement for a resource (e.g. dummy CSV).
  *   The 'Root-Role' has an inducement to the 'Resource-Role'.
Because of MidPoint's eventual consistency, I start a Recomputation of all 'Root-Role' members.

A projection for the resource is created for the 'Testuser'. So far so good.

3) In the third step, I edit the role 'Root-Role' again:

  *   The inducement to 'Resource-Role' is removed from the 'Root-Role'.
To regain consistency, I start a Recomputation of all 'Root-Role' members again.

Nothing happens.
The user 'Testuser' still has his projection for the resource (which should be deleted).
Only one thing happened: The <roleMembershipRef> to 'Resource-Role' was removed during Recomputation.


The same bahaviour happened as I tried these variations:

  *   Deactivating the inducement ('Root-Role' -> 'Resource-Role') instead of deleting it
  *   Reconciling the user 'Testuser' instead of starting the Recomputation of all members of role 'Root-Role'
  *   Use different <strength> values for the construction inducement in the 'Resource-Role'

Sidenote: The system behaves in the same (wrong?) way, when I replace the construction inducement with a group projection.
In this case, the user should already have an account in the resource.

Interestingly, this operation still work:

  *   If I directly assign the 'Resource-Role' to the 'Testuser', the projection is created correctly.
  *   If I remove the direct assignment of 'Resource-Role' from the 'Testuser', the projection is deleted correctly.

Sidenote: The Enforcement Options of the resources are set to the default value ('relative' with no legalization).
This should create accounts after assignment and delete accounts after unassignment.
Other accounts in the resource should not be touched.
The other Enforcement Options and the Legalization are not useful in my scenario (I don't want all unassigned accounts to be whiped from the resource).


The problem seems to be, that the Reconcile/Recompute job doesn't know, that there had ever been an indirect assignment to the 'Resource-Role'.
Instead, the job behaves like the projetion was created manually for the user.
Because of this, there seems to be nothing to recompute for MidPoint.


I tried to analyze this behavior in a primary hook and found something interesting:
When a role is assigned/unassigned directly to a user, this is visible in the <assignment> section and there is a delta with this change.
When a role is assigned/unassigned indirectly to a user, this is visible in the <roleMembershipRef> section, but there is no delta at all.
I assume, this causes the different treatment of direct and indirect assignments.

If indirect assignments (<roleMembershipRef>) would be treated like direct assignments (<assignment>), then everything would propably work as expected.
Changes made to the role hierarchy would cause an effect during Reconcile/Recompute, because the <roleMembershipRef> are already added and removed correctly right now.


Is there any recommended way, how to make changes to the role hierarchy?

Are there any configurations with which MidPoint can process indirect assignments EXACTLY like direct assignments?

Is there any setting or configuration with which MidPoint can process the changes made to indirect assignments when recomputing?

Can I trigger the reconcilation of a role member with some kind of delta (e.g. 'remove indirect assignment')?


The configuration for my problem looks like this:

<role oid="11111111-9ac3-4c09-8bb1-c151bd8cd128">
    <name>Resource-Role</name>
    <inducement>
        <construction>
            <strength>strong</strength>
            <resourceRef oid="33333333-9d55-4bf6-8fd3-d9c7a6f0bd03" relation="org:default" type="c:ResourceType">
                <!-- CSV-System -->
            </resourceRef>
            <kind>account</kind>
            <intent>default</intent>
        </construction>
    </inducement>
</role>

<role oid="22222222-afa2-4a2e-9d3e-c7e8738c673d">
    <name>Root-Role</name>
    <inducement>
        <targetRef oid="11111111-9ac3-4c09-8bb1-c151bd8cd128" relation="org:default" type="c:RoleType">
            <!-- Resource-Role -->
        </targetRef>
    </inducement>
</role>

<user oid="00000000-d56b-4c7d-baf7-61c98afa8851">
    <name>Testuser</name>
    <assignment>
        <targetRef oid="22222222-afa2-4a2e-9d3e-c7e8738c673d" relation="org:default" type="c:RoleType">
            <!-- Root-Role -->
        </targetRef>
    </assignment>
</user>


I hope anyone can help me...
Thanks in advance!
_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com<mailto:midPoint at lists.evolveum.com>
http://lists.evolveum.com/mailman/listinfo/midpoint


--

Arnošt Starosta
solution architect

gsm: [+420] 603 794 932
e‑mail: arnost.starosta at ami.cz<mailto:arnost.starosta at ami.cz>

AMI Praha a.s.
Pláničkova 11, 162 00 Praha 6

tel.: [+420] 274 783 239 | web: www.ami.cz<https://www.ami.cz>

[Das Bild wurde vom Absender entfernt. AMI Praha a.s.]

Textem tohoto e‑mailu podepisující neslibuje uzavřít ani neuzavírá za společnost AMI Praha a.s.
jakoukoliv smlouvu. Každá smlouva, pokud bude uzavřena, musí mít výhradně písemnou formu.

Tento e‑mail je určen výhradně pro potřeby jeho adresáta/ů a může obsahovat důvěrné nebo osobní
informace. Nejste‑li zamýšleným příjemcem, je zakázáno jakékoliv zveřejňování, zprostředkování
nebo jiné použití těchto informací. Pokud jste obdrželi e‑mail neoprávněně, informujte o tom prosím
odesílatele a vymažte neprodleně všechny kopie tohoto e‑mailu včetně všech jeho příloh. Nakládáním
s neoprávněně získanými informacemi se vystavujete riziku právního postihu.
_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com<mailto:midPoint at lists.evolveum.com>
http://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20191015/c34bab71/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD000.jpg
Type: image/jpeg
Size: 823 bytes
Desc: ~WRD000.jpg
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20191015/c34bab71/attachment.jpg>

More information about the midPoint mailing list