[midPoint] - SciptedSQL connector misshandling inherited roles deletion

[Rodrigo Yanis]

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:accountId</
> 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/mailman/listinfo/midpoint
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161110/c39914ef/attachment.htm>