[midPoint] - SciptedSQL connector misshandling inherited roles deletion
Nicolas Rossi
nrossi at identicum.com
Wed Nov 16 13:49:34 CET 2016
Hi Radovan, here is the log of the operation as you suggested. At the
beginning the "AD-SuperRole" had 3 inducements to roles (with MetaRole):
AD-Group3, AD-Group4 and AD-Group5. The user ltroncoso has this
AD-SuperRole and he has 3 groups assigned on AD. Then we removed the
AD-Group3 from the AD-SuperRole and reconciled the User from the Admin-GUI
but he still has the groupMembership on AD to Group3.
Attached is the AD-SuperRole, the AD_GROUP-ENTITLEMENT (MetaRole), the
AD-Group3 and the User's xml.
Do you need any additional information ?
Best regards,
Ing Nicolás Rossi
Identicum S.A.
Jorge Newbery 3226
Tel: +54 (11) 4552-3050
www.identicum.com
On Wed, Nov 16, 2016 at 7:35 AM, Radovan Semancik <
radovan.semancik at evolveum.com> wrote:
> Hi,
>
> This is a really interesting case. Initially I was suspecting a problem in
> the scripted SQL connector. We do not use these scripted connectors much as
> the configurations are very difficult to maintain. With the many possible
> uses of the scripted connectors these are likely to be a cause of problems.
> But if that issue affects AD/LDAP connector then it may indicate midPoint
> issue.
>
> Just to provide complete information: some time ago I have written a guide
> how to systematically diagnose issues like these. Here it is:
>
> https://wiki.evolveum.com/display/midPoint/Troubleshooting+Mappings
>
> However, to cut it short, first interesting thing would be to see what
> operation midPoint sends to the connector. Please enable the ConnId
> operation logging by setting following logger:
>
> org.identityconnectors.framework: TRACE
>
>
> Then re-try the operation (example of the message that you are looking for
> is in the guide). This should give us information whether the problem is
> that midPoint is sending wrong operation to connector or whether the
> connector is doing wrong thing. Then we will know where to focus further
> search for the problem.
>
> --
> Radovan Semancik
> Software Architectevolveum.com
>
>
>
> On 11/14/2016 04:11 PM, Nicolas Rossi wrote:
>
> Hi guys, I'd like to add more information to this issue. We are also
> facing the same issue with the AD-Ldap driver when a Role loses an
> inducement to another Role. After reconcile the user the group membership
> is not removed.
>
> I've added the <tolerant>false</tolerant> flag to the Meta Role as Ivan
> said but there was no change.
>
> 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 5:09 PM, Nicolas Rossi <nrossi at identicum.com>
> wrote:
>
>> 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/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
>
>
> _______________________________________________
> 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/20161116/70964988/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: midpoint.log
Type: application/octet-stream
Size: 30840 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161116/70964988/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AD_GROUP-ENTITLEMENT.xml
Type: text/xml
Size: 2478 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161116/70964988/attachment.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AD-Group3.xml
Type: text/xml
Size: 2307 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161116/70964988/attachment-0001.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AD-SuperRole.xml
Type: text/xml
Size: 2165 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161116/70964988/attachment-0002.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ltorncoso.xml
Type: text/xml
Size: 3994 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161116/70964988/attachment-0003.xml>
More information about the midPoint
mailing list