[midPoint] - SciptedSQL connector misshandling inherited roles deletion

Nicolas Rossi nrossi at identicum.com
Thu Nov 24 11:34:15 CET 2016


Hi Ivan. I'll check it again but I already tried removing the tolerant
parameter on the association definition. It keeps the groups assigned
directly on the resource but it also keeps the groups removed from the user
in a reconcile process. I mean, a role assigned to a user loses an
inducement to other role and when I reconcile the user the group is not
removed on the resource.

Let me try it again.

Regards

El El jue, 24 de nov. de 2016 a las 04:32, Ivan Noris <
ivan.noris at evolveum.com> escribió:

> Hi Ana,
>
> this is typical behaviour when the <association> in the resource is
> configured as <tolerant>false</tolerant>. Can you check the setting in the
> resource?
>
> Setting tolerant to true will allow also values given not by midPoint
> assignments/mappings.
>
> Setting tolerant to false will drop all values not given by midPoint
> assignments/mappings.
>
> The default is true.
>
> Based on the requirements, some customers and projects require setting
> tolerant to true and others to false.
>
> Regards,
>
> Ivan
>
> On 11/23/2016 09:58 PM, Ana Pereyra wrote:
>
> Hi Radovan,
>
> Despite it is now synchronizing correctly the user groups assignments
> between the application and MidPoint, we are facing the following issue:
>
> As we said before, an account in the resource may have groups that have
> been granted from outside MidPoint. For example, we can have user 1 with
> groups 1 and 2 in MidPoint and groups 1, 2, 3 and 4 in the resource (groups
> 3 and 4 have been assigned directly in the resource).
>
> When we force a reconcile on the user, since MidPoint has no record of
> groups 3 and 4, the groups are deleted in the resource too, based on a
> REMOVE_ATTRIBUTE_VALUES operation on the Update script.
>
> What we would need, is for those groups that have not been assigned by
> MidPoint (in this case, groups 3 and 4) *not to be removed* from the user
> in the resource.
>
> Is this MidPoint's default behaviour, to unassign groups that have not
> been assigned by MidPoint?
> Is there a way to only unassign the groups (on a reconcile after a remove
> inducement operation) that have been granted by MidPoint?
>
> Best Regards,
> --
> *Ana Pereyra*
>  Identicum S.A.
>
> *Jorge Newbery 3226, Argentina Tel: +54 (11) **4552.3050*
> *apereyra at identicum.com <apereyra at identicum.com>*
> www.identicum.com
>
>
> 2016-11-22 14:05 GMT-03:00 Radovan Semancik <radovan.semancik at evolveum.com
> >:
>
> On 11/21/2016 08:33 PM, Nicolas Rossi wrote:
>
> Is that the only way to make it work ?
>
>
> No, definitely not. That solution is more like a hack. Not a real
> solution. The point is that midPoint should correctly use the delete
> attribute operation. It is designed to do that and it works for all
> correctly configured resources that we have tried. So the point here is to
> figure out why it does not work for this specific case.
>
> --
> Radovan Semancik
> Software Architectevolveum.com
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
>
>
>
>
> _______________________________________________
> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
> --
> Ivan Noris
> Senior Identity Engineer
>
> evolveum.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/20161124/a8d249d7/attachment.htm>


More information about the midPoint mailing list