[midPoint] - SciptedSQL connector misshandling inherited roles deletion
Ivan Noris
ivan.noris at evolveum.com
Thu Nov 24 20:25:09 CET 2016
Hi Ana,
one other thing which comes to my mind is - can you check what's the
setting of Global Enforcement Policy in System Configuration? The
default is Relative; but "Full" may behave similar to "tolerant=false".
I have used tolerant=false in <association> definition in resource three
weeks ago and I clearly remember that recomputing users with (default)
tolerant=true did not remove values that were not provided by roles
while setting tolerant=false in <association> definition in resource did
the trick during recompute.
No other idea yet.
Ivan
On 11/24/2016 04:39 PM, Ana Pereyra wrote:
> Hi Ivan,
>
> First of all, thank you for your help and quick response.
>
> We understand what you are saying about the tolerance tag behavior: we
> tested both AD and ScriptedSQL connectors with the association
> tolerance set in false and it removes the assignments from the
> resource that have and have not been assigned by MidPoint.
>
> We will discuss this approach with our customer in order to move
> forward with the project implementation.
>
> Ideally, we would need a way to keep the resource assignments that
> have not been granted by MidPoint. If there is any way to do that, we
> would go with that.
>
> We wait for your answer. Thanks in advace.
> Best regards,
>
> --
> *Ana Pereyra*
> Identicum S.A.
> /Jorge Newbery 3226, Argentina
> Tel: +54 (11) //4552.3050/
> /apereyra at identicum.com <mailto:apereyra at identicum.com>/
> www.identicum.com <http://www.identicum.com/>
>
> 2016-11-24 7:34 GMT-03:00 Nicolas Rossi <nrossi at identicum.com
> <mailto:nrossi at identicum.com>>:
>
> 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 <mailto: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 <mailto:apereyra at identicum.com>/
>> www.identicum.com <http://www.identicum.com/>
>>
>>
>> 2016-11-22 14:05 GMT-03:00 Radovan Semancik
>> <radovan.semancik at evolveum.com
>> <mailto: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 Architect
>> evolveum.com <http://evolveum.com>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>> <http://lists.evolveum.com/mailman/listinfo/midpoint>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>> <http://lists.evolveum.com/mailman/listinfo/midpoint>
>
> --
> Ivan Noris
> Senior Identity Engineer
>
> evolveum.com <http://evolveum.com>
>
> _______________________________________________ midPoint
> mailing list midPoint at lists.evolveum.com
> <mailto:midPoint at lists.evolveum.com>
> http://lists.evolveum.com/mailman/listinfo/midpoint
> <http://lists.evolveum.com/mailman/listinfo/midpoint>
>
> _______________________________________________ midPoint mailing
> list midPoint at lists.evolveum.com
> <mailto:midPoint at lists.evolveum.com>
> http://lists.evolveum.com/mailman/listinfo/midpoint
> <http://lists.evolveum.com/mailman/listinfo/midpoint>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
--
Ivan Noris
Senior Identity Engineer
evolveum.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161124/74d60816/attachment.htm>
More information about the midPoint
mailing list