[midPoint] - SciptedSQL connector misshandling inherited roles deletion
Nicolas Rossi
nrossi at identicum.com
Fri Nov 11 21:09:46 CET 2016
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/20161111/9df9759a/attachment.htm>
More information about the midPoint
mailing list