[midPoint] - SciptedSQL connector misshandling inherited roles deletion
Radovan Semancik
radovan.semancik at evolveum.com
Tue Nov 22 18:00:21 CET 2016
Hi,
Clearly the provisioning is trying to add group 4. So this supports the
theory that midPoint thinks that the account does not have any groups.
My guess would be that does not see the group membership correctly. Can
you see the associations correctly when you look at the account details
in the GUI? If my theory is correct then you probably see no
associations there at all (e.g. you would not see neither group 4 nor 6
for account 8).
Proper setup for reading associations is (of course) critical for
reconciliation. If midPoint cannot see what groups the account has then
midPoint cannot correctly compute what groups to add or remove.
There are two likely reasons for this: connector does not return the
data or midPoint is not configured properly to understand that. You can
check if connector returns the data by looking at the ConnId operation
trace. You should see get/search operation there and check that the
connector is returning group membership attributes correctly. If the
connector really returns the information correctly then the most likely
case is misconfigured association definition. I have realized that the
details of the association definition were not properly documented in
the wiki. The documentation was in the schema, but not in the wiki. So I
have just added that:
https://wiki.evolveum.com/display/midPoint/Entitlements#Entitlements-AssociationDefinition
Please have a look at that and check if your association configuration
is OK.
If nothing helps then you may need to resort to drastic measures:
setting the log level to TRACE :-)
--
Radovan Semancik
Software Architect
evolveum.com
On 11/21/2016 04:17 PM, Nicolas Rossi wrote:
> Hi, here is the provisioning log (DEBUG mode):
>
> 2016-11-21 12:01:07,928 [] [Thread-107] DEBUG
> (org.forgerock.openicf.misc.scriptedcommon.ScriptedConnector): method:
> null msg:Entering SEARCH Script with objectClass __ACCOUNT__
> 2016-11-21 12:01:07,950 [] [Thread-107] DEBUG
> (org.forgerock.openicf.misc.scriptedcommon.ScriptedConnector): method:
> null msg:Search WHERE clause is: WHERE id = 8
> 2016-11-21 12:01:08,016 [] [Thread-107] DEBUG
> (org.forgerock.openicf.misc.scriptedcommon.ScriptedConnector): method:
> null msg:Entering SEARCH Script with objectClass __GROUP__
> 2016-11-21 12:01:08,031 [] [Thread-107] DEBUG
> (org.forgerock.openicf.misc.scriptedcommon.ScriptedConnector): method:
> null msg:Search WHERE clause is: WHERE id = 4
> 2016-11-21 12:01:08,188 [] [Thread-107] DEBUG
> (com.evolveum.midpoint.provisioning.impl.ResourceObjectConverter):
> PROVISIONING MODIFY operation on
> resource:00000000-0000-1de4-0002-000000000010(ScriptedSQL)
> MODIFY object, object class ACCOUNT:default, identified by:
> [
> uid: 8
> ]
> changes:
> [
> Property modification operation:
> attributes/groups
> ADD: 4
> ]
> 2016-11-21 12:01:08,286 [] [Thread-107] DEBUG
> (org.forgerock.openicf.misc.scriptedcommon.ScriptedConnector): method:
> null msg:Entering Update Script with action ADD_ATTRIBUTE_VALUES
> Script for object class __ACCOUNT__
> 2016-11-21 12:01:08,288 [] [Thread-107] DEBUG
> (org.forgerock.openicf.misc.scriptedcommon.ScriptedConnector): method:
> null msg:Sample - Attribute received: groups -> [4]
> 2016-11-21 12:01:08,288 [] [Thread-107] DEBUG
> (org.forgerock.openicf.misc.scriptedcommon.ScriptedConnector): method:
> null msg:Sample - Entro en add attribute values
> 2016-11-21 12:01:08,290 [] [Thread-107] DEBUG
> (org.forgerock.openicf.misc.scriptedcommon.ScriptedConnector): method:
> null msg:Sample - Skipping assignment because user 8 already has group 4
> 2016-11-21 12:01:08,290 [] [Thread-107] DEBUG
> (com.evolveum.midpoint.provisioning.impl.ResourceObjectConverter):
> PROVISIONING MODIFY successful, side-effect changes {
> }
> 2016-11-21 12:01:08,586 [] [Thread-107] DEBUG
> (org.forgerock.openicf.misc.scriptedcommon.ScriptedConnector): method:
> null msg:Entering SEARCH Script with objectClass __GROUP__
> 2016-11-21 12:01:08,601 [] [Thread-107] DEBUG
> (org.forgerock.openicf.misc.scriptedcommon.ScriptedConnector): method:
> null msg:Search WHERE clause is: WHERE id = 4
> 2016-11-21 12:01:08,673 [] [Thread-107] DEBUG
> (org.forgerock.openicf.misc.scriptedcommon.ScriptedConnector): method:
> null msg:Entering SEARCH Script with objectClass __GROUP__
> 2016-11-21 12:01:08,711 [] [Thread-107] DEBUG
> (org.forgerock.openicf.misc.scriptedcommon.ScriptedConnector): method:
> null msg:Search WHERE clause is: WHERE id = 4
>
> The context before the operation was:
>
> * User Celeste has an account with id 8 on ScriptedSQL resource
> * User Celeste has an assignment to ScriptedSQL-SuperRole
> * Role ScriptedSQL-SuperRole has an assignment to ScriptedSQL-Group4
> and ScriptedSQL-Group6
> * Account 8 has roles 4 and 6 on the resource
>
> This was the operation I triggered:
>
> * ScriptedSQL-Group5 role is unassigned from ScriptedSQL-SuperRole
> * User Celeste is reconciled
>
> There is no reference to ScriptedSQL-Group6 (id = 6) in the log.
> Attached is the log in TRACE mode of same operation.
>
> This is the meta role definition:
>
> <association>
> <c:ref>ri:GroupObjectClass</c:ref>
> *<tolerant>false</tolerant>*
> <outbound>
> *<strength>strong</strength>*
> <expression>
> <associationFromLink>
> <projectionDiscriminator>
> <kind>entitlement</kind>
> <intent>default</intent>
> </projectionDiscriminator>
> </associationFromLink>
> </expression>
> </outbound>
> </association>
>
> And this is the association definition on the ScriptedSQL resource:
>
> <association>
> <c:ref>ri:GroupObjectClass</c:ref>
> *<tolerant>false</tolerant>*
> <kind>entitlement</kind>
> <intent>default</intent>
> <direction>subjectToObject</direction>
> <associationAttribute>ri:groups</associationAttribute>
> <valueAttribute>icfs:uid</valueAttribute>
> </association>
>
> Regards,
>
>
>
>
> Ing Nicolás Rossi
> Identicum S.A.
> Jorge Newbery 3226
> Tel: +54 (11) 4552-3050
> www.identicum.com <http://www.identicum.com>
>
> On Mon, Nov 21, 2016 at 11:09 AM, Radovan Semancik
> <radovan.semancik at evolveum.com <mailto:radovan.semancik at evolveum.com>>
> wrote:
>
> Hi,
>
> That's strange. The ScriptedSQL is somehow different. But it
> should not be THAT different. Please once again look at the ConnId
> operation trace. That's the most reliable source of debugging
> information in this case.
>
> But based on your information I would guess that it really is
> midPoint issue. If the connector is not getting the remove
> operation than that means that midpoint is not sending it. If you
> are sure that the "model" configuration is correct (e.g. tolerant
> setting, mapping strength, etc.) then it is most likely that the
> provisioning part is filtering out the operation. There may be
> several reasons for that. E.g. if the read operation does not work
> properly midPoint may think that the value is not there and
> therefore there is no need to remove it. Some resources (namely
> LDAP) are quite touchy and they respond with an error if we try to
> remove a value that is not there. Therefore we are often filtering
> the deltas before sending them to connector. Or there may be
> several other cases. Generally setting provisioning logging to
> DEBUG (and in extreme cases to TRACE) should give you more
> information what it really happening. To be more specific try setting:
> com.evolveum.midpoint.provisioning: DEBUG
>
> --
> Radovan Semancik
> Software Architect
> evolveum.com <http://evolveum.com>
>
>
>
> On 11/21/2016 01:38 PM, Nicolas Rossi wrote:
>> Hi Radovan. It worked for ActiveDirectory connector but didn't
>> for the ScriptedSQL. We have added an echo at the beginning of
>> each groovy scripts printing the action and the object class
>> received and It only receives an ADD_ATTRIBUTE_VALUE of the value
>> that the user already had. There is no REMOVE_ATTRIBUTE_VALUE so
>> I guess the issue is on the connector this time. I have an
>> isolated set of resource, meta role and role to reproduce the
>> issue. You can download it from here
>> <https://dl.dropboxusercontent.com/u/9319179/ScriptedSQLTest.zip>
>> if you want. The main difference with the Active Directory
>> resource is in the association: subjectToObject vs
>> objectToSubject. Do you think the problem could be there ? I'll
>> try it.
>>
>> I guess it would be helpful add this info of tolerant attribute
>> on this page:
>> https://wiki.evolveum.com/display/midPoint/Entitlements
>> <https://wiki.evolveum.com/display/midPoint/Entitlements>.
>>
>> Best regards,
>>
>>
>>
>> Ing Nicolás Rossi
>> Identicum S.A.
>> Jorge Newbery 3226
>> Tel: +54 (11) 4552-3050
>> www.identicum.com <http://www.identicum.com>
>>
>> On Mon, Nov 21, 2016 at 7:15 AM, Radovan Semancik
>> <radovan.semancik at evolveum.com
>> <mailto:radovan.semancik at evolveum.com>> wrote:
>>
>> Hi,
>>
>> I have created the test. And surprisingly it is passing. This
>> is 3.5-SNAPSHOT, but it is very likely that it works also in
>> earlier versions. Therefore it looks it is really a
>> misconfiguration. The cause is really most likely the
>> tolerant flag. The tolerant flag is critical in this situation.
>>
>> For "normal" midPoint operations when you are adding or
>> removing an assignment from user we have the delta. We know
>> what has changed. Therefore we remove the group even if it is
>> set to tolerant. Because we know that the last assignment
>> that "induced" that group was just removed.
>>
>> But if you change the meta role (first operation) and then
>> reconcile the user (second operation) then there is no delta.
>> These operations are independent. MidPoint does not know what
>> has changed in the meta-role. Therefore it cannot use the
>> same logic to remove the user from the group. Slightly
>> different logic is used in reconciliation. Logic that is not
>> based on deltas (because there are none). And in this case
>> the tolerant flag is important. If it is set to true then
>> midPoint will NOT remove the extra values from the attribute
>> or the extra entitlements. If it is set to false then
>> midPoint will remove them.
>>
>> Please make sure you have the association set to non-tolerant
>> in the schemaHandling section of the resource definition.
>> Like this:
>>
>> <resource>
>> <schemaHandling>
>> ....
>> <association>
>> <ref>ri:group</ref>
>> <tolerant>false</tolerant>
>> ....
>> </association>
>> ...
>>
>> This has to be defined in the schemaHandling and NOT in the
>> role or meta-role. The tolerance is the property of the
>> attribute/association itself and NOT a property of any
>> mapping, role or value. The values that are not given by any
>> role and just that - not given by any role. So we do not have
>> any role definition that we can apply to them. Therefore the
>> setting whether the attribute/association is tolerant or not
>> is somehow "global". Therefore it needs to be defined in
>> schemaHandling.
>>
>> Also, please make sure that your mappings are strong, e.g.
>>
>> <role>
>> ...
>> <inducement>
>> <construction>
>> ...
>> <association>
>> <ref>ri:group</ref>
>> <outbound>
>> <strength>strong</strength>
>> ...
>> </outbound>
>> </association>
>> </construction>
>> </inducement>
>>
>> Mappings that are of "normal" strength are inherently
>> delta-based and they are usually NOT processed by the
>> reconciliation at all. For "normal" mappings the last change
>> wins. But in reconciliation we have no idea what change was
>> the last one - whether the one on the resource or the one in
>> midPoint. Therefore we prefer the conservative approach and
>> we rather maintain status quo.
>>
>> --
>> Radovan Semancik
>> Software Architect
>> evolveum.com <http://evolveum.com>
>>
>>
>>
>> On 11/20/2016 04:44 PM, Radovan Semancik wrote:
>>> Hi,
>>>
>>> There is no update operation in the log. Therefor midPoint
>>> is not invoking the group membership removal at all. I'm not
>>> sure what exactly happens here. Your configuration seems to
>>> be OK at the first sight and I would tell that your setup
>>> should work. Therefore this may be a midPoint bug. I will
>>> try to reproduce similar situation in midPoint tests. I'll
>>> let you know how it went.
>>>
>>> --
>>> Radovan Semancik
>>> Software Architect
>>> evolveum.com <http://evolveum.com>
>>>
>>>
>>> On 11/16/2016 01:49 PM, Nicolas Rossi wrote:
>>>> 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 <http://www.identicum.com>
>>>>
>>>> On Wed, Nov 16, 2016 at 7:35 AM, Radovan Semancik
>>>> <radovan.semancik at evolveum.com
>>>> <mailto: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
>>>> <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 Architect
>>>> evolveum.com <http://evolveum.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
>>>>> <http://www.identicum.com>
>>>>> On Fri, Nov 11, 2016 at 5:09 PM, Nicolas Rossi
>>>>> <nrossi at identicum.com <mailto: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 RossiIdenticum S.A. Jorge Newbery 3226
>>>>> Tel: +54 (11) 4552-3050 www.identicum.com
>>>>> <http://www.identicum.com>
>>>>> On Fri, Nov 11, 2016 at 11:00 AM, Rodrigo Yanis
>>>>> <ryanis at identicum.com
>>>>> <mailto: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-9971ryanis at identicum.com
>>>>> <mailto:ryanis at identicum.com>
>>>>> www.identicum.com <http://www.identicum.com/>
>>>>> 2016-11-11 2:46 GMT-05:00 Ivan Noris
>>>>> <ivan.noris at evolveum.com
>>>>> <mailto: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-9971ryanis 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-9971ryanis 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-9971ryanis 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
>>>>>> <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>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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>
>>>>
>>>> _______________________________________________
>>>> 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>
>>
>> _______________________________________________
>> 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>
>
> _______________________________________________
> 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/20161122/7b8d91d7/attachment.htm>
More information about the midPoint
mailing list