[midPoint] - SciptedSQL connector misshandling inherited roles deletion

Nicolas Rossi nrossi at identicum.com
Mon Nov 14 16:11:12 CET 2016


Hi guys, I'd like to add more information to this issue. We are also facing
the same issue with the AD-Ldap driver when a Role loses an inducement to
another Role. After reconcile the user the group membership is not removed.

I've added the <tolerant>false</tolerant> flag to the Meta Role as Ivan
said but there was no change.

Regards,



Ing Nicolás Rossi
Identicum S.A.
Jorge Newbery 3226
Tel: +54 (11) 4552-3050
www.identicum.com

On Fri, Nov 11, 2016 at 5:09 PM, Nicolas Rossi <nrossi at identicum.com> wrote:

> Hi Ivan / Radovan
>
> I guess there is a problem in the ScriptedSQL driver (not the scripts)
> when an inducement is unassigned from a Role because we are facing the same
> issue in two different situations:
>
>    1. When a technical role with inducements to entitlements is
>    unassigned from user the script does not receive the action
>    REMOVE_ATTRIBUTE_VALUE
>    2. When a technical role (with MetaRole) is unassigned from a
>    functional role assigned to user when recompute the user the script does
>    not receive the action REMOVE_ATTRIBUTE_VALUE
>
> Both situations are working when you assign the inducements. I have an
> isolated example here
> <https://dl.dropboxusercontent.com/u/9319179/ScriptedSQLTest.zip>.
>
> Best regards,
>
>
>
> Ing Nicolás Rossi
> Identicum S.A.
> Jorge Newbery 3226
> Tel: +54 (11) 4552-3050
> www.identicum.com
>
> On Fri, Nov 11, 2016 at 11:00 AM, Rodrigo Yanis <ryanis at identicum.com>
> wrote:
>
>> Ivan,
>>
>> Just tried configuring the meta-role just like that. Unfortunately no
>> progress. We'll continue analyzing this and keep you posted if we find
>> anything.
>>
>> Thanks a lot.
>>
>> Regards,
>>
>>
>> *Rodrigo Yanis.*
>> Identicum S.A.
>> Jorge Newbery 3226
>> Tel: +54 (11) 4824-9971
>> ryanis at identicum.com
>> www.identicum.com
>>
>> 2016-11-11 2:46 GMT-05:00 Ivan Noris <ivan.noris at evolveum.com>:
>>
>>> Hi Rodrigo,
>>>
>>> I meant this:
>>>
>>> ...
>>>
>>>     <inducement>
>>>         <construction>
>>>                 <resourceRef oid="00000000-dc00-dc00-0001-000000000021"
>>> type="c:ResourceType"/><!-- Portal intranet -->
>>>         <kind>account</kind>
>>>         <intent>default</intent>
>>>         <association>
>>>             <ref>ri:wsEntitlements</ref>
>>>             <outbound>
>>> *                <strength>strong</strength>*
>>>                 <source>
>>>                     ...
>>>                 </source>
>>>                 <expression>
>>>                 ...
>>>
>>> But I think your problem should be resolved by tolerance (set to false)
>>> - strong mapping strength is to allow midPoint to enforce the group
>>> assignment when reconciling. Still I don't have any other idea. I hope
>>> that's not a problem with that specific connector because I wouldn't be
>>> able help with Java.
>>>
>>> Best regards,
>>>
>>> IVan
>>>
>>> On 11/10/2016 09:36 PM, Rodrigo Yanis wrote:
>>>
>>> Ivan,
>>>
>>> I've compared your XML to my association attribute's deffinition on the
>>> resource and it looks the same. Can you please explain further what you
>>> mean by defining strength on the role itself? We've got a Meta-role ->
>>> Application role -> High level role architecture going (I believe it's just
>>> the same as yours except for the meta-role), and the group association is
>>> defined on the meta-role. Do you mean we should somehow define strength
>>> there? because it isn't explicitly set.
>>>
>>> This is the inducement for the group association on the meta-role
>>> definition:
>>>
>>> <inducement id="2">
>>>       <construction>
>>>          <resourceRef oid="00000000-0000-1de4-0002-000000000003"
>>> type="c:ResourceType"><!-- BANNER_USUARIOS --></resourceRef>
>>>          <kind>account</kind>
>>>          <intent>default</intent>
>>>          <association>
>>>             <c:ref>ri:GroupObjectClass</c:ref>
>>>             <outbound>
>>>                <expression>
>>>                   <associationFromLink>
>>>                      <projectionDiscriminator>
>>>                         <kind>entitlement</kind>
>>>                         <intent>default</intent>
>>>                      </projectionDiscriminator>
>>>                   </associationFromLink>
>>>                </expression>
>>>             </outbound>
>>>          </association>
>>>       </construction>
>>>       <order>2</order>
>>>    </inducement>
>>>
>>> Don't mind me if I sound a bit confused.
>>>
>>> Thanks for your help.
>>>
>>>
>>> *Rodrigo Yanis.*
>>> Identicum S.A.
>>> Jorge Newbery 3226
>>> Tel: +54 (11) 4824-9971
>>> ryanis at identicum.com
>>> www.identicum.com
>>>
>>> 2016-11-10 13:51 GMT-05:00 Ivan Noris <ivan.noris at evolveum.com>:
>>>
>>>> Hi Rodrigo,
>>>>
>>>> unfortunately no other idea yet. I was running recompute ca. two weeks
>>>> ago to remove some application groups that were not added by midPoint, the
>>>> goal was to have association configuration with tolerant=false and it
>>>> worked (this was custom connector, not ScriptedSQL):
>>>>
>>>>                 <association>
>>>>                     <ref>ri:wsEntitlements</ref>
>>>>                     <tolerant>false</tolerant>
>>>>                     <matchingRule>mr:stringIgnoreCase</matchingRule>
>>>>                     <kind>entitlement</kind>
>>>>                     <intent>ws-entitlement</intent>
>>>>                     <direction>objectToSubject</direction>
>>>>                     <associationAttribute>ri:accou
>>>> ntId</associationAttribute>
>>>>                     <valueAttribute>icfs:uid</valueAttribute>
>>>>                 </association>
>>>>
>>>>
>>>> In all roles where association is used, <strength>strong</strength> is
>>>> used as well (but the tolerant=false is a must). The recompute then worked
>>>> as supposed and removed all non-midpoint groups from the accounts. The
>>>> accounts were constructed by hierarchical roles (User - assign - Business
>>>> role - inducement - Application role) and the association was in the
>>>> Application role.
>>>>
>>>> Best regards,
>>>>
>>>> Ivan
>>>>
>>>> On 11/10/2016 06:21 PM, Rodrigo Yanis wrote:
>>>>
>>>> Hello Ivan, thanks for you response.
>>>>
>>>> Unfortunatelly this didn't work. All our association attributes are set
>>>> to tolerance=false by default.
>>>>
>>>> Strange thing is, this only happens when reconciling on already
>>>> assigned high level roles, not on assignment time.
>>>>
>>>> Any other suggestion?
>>>> Thanks again,
>>>>
>>>>
>>>> *Rodrigo Yanis.*
>>>> Identicum S.A.
>>>> Jorge Newbery 3226
>>>> Tel: +54 (11) 4824-9971
>>>> ryanis at identicum.com
>>>> www.identicum.com
>>>>
>>>> 2016-11-10 9:48 GMT-05:00 Ivan Noris <ivan.noris at evolveum.com>:
>>>>
>>>>> Hi Rodrigo,
>>>>>
>>>>> maybe <tolerant>false</tolerant> for association or your group
>>>>> attribute (if not using associations) could help...
>>>>>
>>>>> Ivan
>>>>>
>>>>> On 11/10/2016 03:33 PM, Rodrigo Yanis wrote:
>>>>>
>>>>> Hello everyone,
>>>>>
>>>>> We're having issues with our ScriptedSQL connector misshandling group
>>>>> membership removals when said memberships come from roles that are
>>>>> inherited from a higher level role, that is assigned to the user.
>>>>>
>>>>> When we remove the database role (the one that is linked to the
>>>>> resource's meta-role, and represents a database group) from the higher
>>>>> level role, and perform a reconciliation on the user, this does not remove
>>>>> the group membership of this user in the database. This only happens if the
>>>>> database role is assigned directly to the user, and then removed.
>>>>>
>>>>> We've also tried with a recompute task on the user, still with no luck.
>>>>>
>>>>> Since our role hierarchy does not support this last option, we must
>>>>> find a way (either through a task or directly) to remove memberships to
>>>>> roles that are no longer induced into the high level role.
>>>>>
>>>>> Do you have an idea on how to proceed?
>>>>>
>>>>> Thanks for your help
>>>>>
>>>>> *Rodrigo Yanis.*
>>>>> Identicum S.A.
>>>>> Jorge Newbery 3226
>>>>> Tel: +54 (11) 4824-9971
>>>>> ryanis at identicum.com
>>>>> www.identicum.com
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>>>>>
>>>>> --
>>>>> Ivan Noris
>>>>> Senior Identity Engineerevolveum.com
>>>>>
>>>>> _______________________________________________ midPoint mailing list
>>>>> midPoint at lists.evolveum.com http://lists.evolveum.com/mail
>>>>> man/listinfo/midpoint
>>>>
>>>> _______________________________________________
>>>> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>>>>
>>>> --
>>>> Ivan Noris
>>>> Senior Identity Engineerevolveum.com
>>>>
>>>> _______________________________________________ midPoint mailing list
>>>> midPoint at lists.evolveum.com http://lists.evolveum.com/mail
>>>> man/listinfo/midpoint
>>>
>>> _______________________________________________
>>> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>> --
>>> Ivan Noris
>>> Senior Identity Engineerevolveum.com
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>>
>>
>> _______________________________________________
>> midPoint mailing list
>> 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/20161114/75c3d786/attachment.htm>


More information about the midPoint mailing list