[midPoint] - SciptedSQL connector misshandling inherited roles deletion
Ivan Noris
ivan.noris at evolveum.com
Fri Nov 11 08:46:22 CET 2016
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 <mailto:ryanis at identicum.com>
> www.identicum.com <http://www.identicum.com/>
>
> 2016-11-10 13:51 GMT-05:00 Ivan Noris <ivan.noris at evolveum.com
> <mailto: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:accountId</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 <mailto:ryanis at identicum.com>
>> www.identicum.com <http://www.identicum.com/>
>>
>> 2016-11-10 9:48 GMT-05:00 Ivan Noris <ivan.noris at evolveum.com
>> <mailto: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 <mailto:ryanis at identicum.com>
>>> www.identicum.com <http://www.identicum.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>
>>
>> --
>> 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>
> --
> 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
> 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/20161111/799ad142/attachment.htm>
More information about the midPoint
mailing list