[midPoint] [SOLVED] Problem with associationFromLink metarole (v3.8)
Wojciech Staszewski
wojciech.staszewski at diagnostyka.pl
Mon Apr 1 14:20:11 CEST 2019
Hello!
Update V3 (working solution):
Add a
<strength>strong</strength>
in the outbound association mapping of the 2nd order inducement:
<inducement>
<construction>
<resourceRef oid="xxxxxxxxxxxxxxxxxxxxxxxxxxx" relation="org:default" type="c:ResourceType">
</resourceRef>
<kind>account</kind>
<association>
<c:ref>ri:groups</c:ref>
<outbound>
<strength>strong</strength>
<expression>
<associationFromLink>
<projectionDiscriminator>
<kind>entitlement</kind>
<intent>group</intent>
</projectionDiscriminator>
</associationFromLink>
</expression>
</outbound>
</association>
</construction>
<order>2</order>
</inducement>
Regards!
WS
W dniu 23.02.2019 o 19:06, Wojciech Staszewski pisze:
> UPDATE V2:
>
> It turned out, that the "inOid" expression has nothing to do with my
> problem.
> I tested it for the last 2 days and I came to the following conclusion:
>
> 1) I have to remove the account from ALL groups of specified kind in the
> target system,
> then midPoint restores these groups for this account (all of them).
>
> 2) If I remove the account from one group only in the target system,
> midPoint ignores this change and does not restore the membership.
>
> I made a short movie as they say "one picture is worth 1000 words" and
> also I am not sure about my english skills.
>
> Link: https://www.youtube.com/watch?v=zegbzA72mcA
>
> As I wrote before, this association is non-tolerant.
> Where to look for the cause?
>
> W dniu 21.02.2019 o 18:52, Wojciech Staszewski pisze:
>> Hello!
>>
>> A little UPDATE about this issue:
>>
>> The problem seems to be related to the "inOid" expression.
>> If I replace this expression with static Resource OID declaration the
>> metarole works correctly.
>>
>> I have some options now:
>>
>> 1) Replace "inOid" expression with static Oid, multiply this metarole
>> for each resource and correct the synchronization templates (many
>> resources, much work).
>> 2) Maybe the "resolutionTime" is the clue and "run" is incorrect value
>> here? What value can be set in this place and how it actually works?
>> 3) If it's a bug in midPoint, maybe it is fixed already in some
>> "post-fixes" branch?
>>
>> Thanks,
>> WS
>>
>> W dniu 11.02.2019 o 13:15, Wojciech Staszewski pisze:
>>> Hi All!
>>>
>>> I have a strange problem with metarole (association from link) that
>>> gives a group membership to users on some specified resource.
>>> The metarole is assigned to a parent role "Group: HELPDESK", this role
>>> has active linkRef (projection) to a resource group shadow.
>>>
>>> Association is non-tolerant.
>>>
>>> If I assign this role to a midPoint user, the user is correctly
>>> assigned to desired group (HELPDESK) on the target system.
>>> If I unassign this role, the group membership on the resource is removed.
>>> If I add the account to some other group directly on the target system
>>> - this membership is removed by midPoint (non-tolerant assoc.).
>>>
>>> Till now everything is perfectly OK.
>>>
>>> But If I remove the user from "HELPDESK" group directly on the target
>>> system, midPoint ignores that and does not recreate the membership,
>>> though the user has "Group: HELPDESK" assigned.
>>> I tried "reconciliation" of the user and "recompute" role members,
>>> nothing. No changes.
>>>
>>> The only way to recreate group membership is to unassign "Group:
>>> HELPDESK" in midPoint and assign it again.
>>>
>>> For testing purposes I made a role that assign group "HELPDESK" using
>>> simple "shadowRef" and this is working OK.
>>>
>>>
>>> The metarole construction:
>>>
>>> <inducement id="1">
>>> <construction>
>>> <strength>weak</strength>
>>> <resourceRef relation="org:default" type="c:ResourceType">
>>> <filter>
>>> <q:inOid>
>>> <expression>
>>> <script>
>>> <code>
>>> return
>>> basic.getPropertyValue(immediateRole, "extension/resourceRef");
>>> </code>
>>> </script>
>>> </expression>
>>> </q:inOid>
>>> </filter>
>>> <resolutionTime>run</resolutionTime>
>>> </resourceRef>
>>> <kind>entitlement</kind>
>>> <intent>groups</intent>
>>> </construction>
>>> </inducement>
>>> <inducement id="2">
>>> <construction>
>>> <resourceRef relation="org:default" type="c:ResourceType">
>>> <filter>
>>> <q:inOid>
>>> <expression>
>>> <script>
>>> <code>
>>> return
>>> basic.getPropertyValue(immediateRole, "extension/resourceRef");
>>> </code>
>>> </script>
>>> </expression>
>>> </q:inOid>
>>> </filter>
>>> <resolutionTime>run</resolutionTime>
>>> </resourceRef>
>>> <kind>account</kind>
>>> <association id="7">
>>> <c:ref>ri:groups</c:ref>
>>> <outbound>
>>> <expression>
>>> <associationFromLink
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>
>>> xsi:type="c:AssociationFromLinkExpressionEvaluatorType">
>>> <projectionDiscriminator
>>> xsi:type="c:ShadowDiscriminatorType">
>>> <kind>entitlement</kind>
>>> <intent>groups</intent>
>>> </projectionDiscriminator>
>>> </associationFromLink>
>>> </expression>
>>> </outbound>
>>> </association>
>>> </construction>
>>> <order>2</order>
>>> </inducement>
>>>
>>>
>>> Parent role has an extension attribute "resourceRef" with resource OID.
>>> First inducement is weak as this role must work with another role that
>>> gives strong account assignment.
>>> Any ideas?
>>> Thanks!
>
--
Wojciech Staszewski
Administrator Systemów Sieciowych
tel. kom: 663 680 236
www.diagnostyka.pl
Diagnostyka Sp. z o. o.
ul. Prof. M. Życzkowskiego 16, 31-864 Kraków
Numer KRS: 0000381559 (Sąd Rejonowy dla Krakowa-Śródmieścia w Krakowie, XI Wydział Gospodarczy KRS)
NIP: 675-12-65-009; REGON: 356366975
Kapitał zakładowy: 33 756 500 zł.
Pomyśl o środowisku zanim wydrukujesz ten e-mail.
More information about the midPoint
mailing list