[midPoint] - SciptedSQL connector misshandling inherited roles deletion
Rodrigo Yanis
ryanis at identicum.com
Fri Nov 11 15:00:06 CET 2016
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161111/010c17df/attachment.htm>
More information about the midPoint
mailing list