[midPoint] - SciptedSQL connector misshandling inherited roles deletion

Fri Nov 25 22:38:23 CET 2016

Hi Ivan, the Global Enforcement Policy is set to Full. The tolerant=false
is working fine when we have the same associations in midPoint and in the
resource. So if we remove a group in midPoint is removed on the resource.
That works.

We are working on a situation where the resource has more user-group
assignments than midPoint has. It can be because entitlements are granted
directly on the resource (not recommended by us but it can happen) or if
you don't load the associations during the initial setup. So if we remove a
role assignment or role inducement on midPoint and reconcile the user, it
loses the removed roles (that would be right) but also loses the roles
granted on the resource.

As Ana said, we know this is not the best approach but we want to be sure
if this is the only way that midpoint works, and we will recommend the
customer to load and maintain all the associations in midPoint.

Best regards,

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

On Thu, Nov 24, 2016 at 4:25 PM, Ivan Noris <ivan.noris at evolveum.com> wrote:

> 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 <apereyra at identicum.com>*
> www.identicum.com
>
> 2016-11-24 7:34 GMT-03:00 Nicolas Rossi <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> 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/mail
>>> man/listinfo/midpoint
>>
>> _______________________________________________ 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/20161125/c69fe082/attachment.htm>