[midPoint] Problem deprovisioning

Wed Oct 21 16:47:02 CEST 2020

I was able to find a reasonable work around for my user population. I have a bulk task that runs every day. One feature that would be nice is this functionality in the query options that I use all of the time in our legacy system in direct SQL

where pk not in (select pk from other_table where user has some sort of attribute)

Since I can't figure out how to do that in this query syntax, have a slight work around. I have a bulk task that runs on schedule. It queries for everyone that has one of the attributes I want to blank out. It then iterates through each of those users to see if they have a shadow in the resource that created those attributes. If they don't, it blanks the attributes out. Attached is one such task. For anyone wondering, I am supporting two different institutions in midPoint, hence the need for custom schema extension for attributes in midPoint already, like title. Plus I'm higher education, so people can be in multiple departments, hence the "primary". This takes just over 3 minutes on just under 6k people. And we really haven't taken any time to tune the performance of our environment other than making sure midPoint has plenty of memory assigned to it.

There's also probably a way to collapse this down to be a bit more efficient, but this is efficient enough for us at this moment. Note my method for checking if the user has a shadow in the specified resource. I was doing bad things previously where I iterated over all shadows the user had, and that wasn't good. So only hunt for the one you want.

On Wed, 2020-10-21 at 16:34 +0200, Pavol Mederly via midPoint wrote:

Hello,

as far as I know, this seemingly "innocent" scenario is surprisingly not directly supported by midPoint. Richard Frovarp asked about it here in July. Just look for "How to blank out user properties?" thread.

The technical reason why the data cannot be cleaned up by the same mapping that provides them is the fact that the inbound mapping is no longer applied when the account is gone.

So a workaround has to be conceived. Some of these workarounds are discussed in the mentioned thread. (What comes to my mind, though, is to map data from the resource to a set of auxiliary user properties, from where they are propagated to the "main" properties - Titolo, Matricola, ... - under condition of hasLinkedAccount for the resource.)

Best regards,

Pavol Mederly

Software developer

evolveum.com

On 21/10/2020 15:43, Andrea Picconi via midPoint wrote:
Hi Petr,

I mean that the field (or fields) must be blank.
With the account still linked, the fields are filled (example here)

[cid:df5ad409679ebf55f0d8ee4eec55763577a41ee4.camel at ndsu.edu]

but if I unlink the account, I expect midpoint to deprovision and remove the attributes of that account (here the same with what I expect)

[cid:6c65daa11e630a21603c8a3f25cbf421316e1909.camel at ndsu.edu]

Thanks

From: Petr Gašparík - AMI Praha a.s. <petr.gasparik at ami.cz><mailto:petr.gasparik at ami.cz>
Sent: Wednesday, October 21, 2020 3:32 PM
To: midPoint General Discussion <midpoint at lists.evolveum.com><mailto:midpoint at lists.evolveum.com>
Cc: Andrea Picconi <andrea.picconi at innovery.net><mailto:andrea.picconi at innovery.net>; Marianna De Biasio <marianna.debiasio at innovery.net><mailto:marianna.debiasio at innovery.net>; Jacopo Giuliano <jacopo.giuliano at innovery.net><mailto:jacopo.giuliano at innovery.net>
Subject: Re: [midPoint] Problem deprovisioning

Please elaborate more on what means "delete attributes" :)

--

s pozdravem

Petr Gašparík
konzultant IT bezpečnosti

gsm: [+420] 603 523 860
e‑mail: petr.gasparik at ami.cz<mailto:petr.gasparik at ami.cz>

AMI Praha a.s.
Pláničkova 11, 162 00 Praha 6

tel.: [+420] 274 783 239 | web: www.ami.cz<https://www.ami.cz>

[Immagine rimossa dal                                              mittente. AMI Praha a.s.]

Textem tohoto e‑mailu podepisující neslibuje uzavřít ani neuzavírá za společnost AMI Praha a.s.
jakoukoliv smlouvu. Každá smlouva, pokud bude uzavřena, musí mít výhradně písemnou formu.

Tento e‑mail je určen výhradně pro potřeby jeho adresáta/ů a může obsahovat důvěrné nebo osobní
informace. Nejste‑li zamýšleným příjemcem, je zakázáno jakékoliv zveřejňování, zprostředkování
nebo jiné použití těchto informací. Pokud jste obdrželi e‑mail neoprávněně, informujte o tom prosím
odesílatele a vymažte neprodleně všechny kopie tohoto e‑mailu včetně všech jeho příloh. Nakládáním
s neoprávněně získanými informacemi se vystavujete riziku právního postihu.

st 21. 10. 2020 v 15:24 odesílatel Andrea Picconi via midPoint <midpoint at lists.evolveum.com<mailto:midpoint at lists.evolveum.com>> napsal:

Hello everyone,

I have a problem while unlinking an account from a user: what happens is that the unlink process correctly removes the account inside the Projections tab , but it doesn’t deprovision the attributes that are mapped within that account.

What could cause this unexpected behaviour? And how do i get all these attributes to be deleted from Midpoint ?

Regards,
Andrea Picconi
IAM (Identity Access Management)
[Innovery]
Skype: precons
T:  +39 06 51963439 (int. 196)

Strada Quattro Palazzina A6 c/o Centro Direzionale Milanofiori, 20057 Assago (MI).
www.innovery.net<http://www.innovery.net/> |  T: +39 06 519 63 439

_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com<mailto:midPoint at lists.evolveum.com>
https://lists.evolveum.com/mailman/listinfo/midpoint

_______________________________________________

midPoint mailing list

midPoint at lists.evolveum.com<mailto:midPoint at lists.evolveum.com>

https://lists.evolveum.com/mailman/listinfo/midpoint

_______________________________________________

midPoint mailing list

midPoint at lists.evolveum.com<mailto:midPoint at lists.evolveum.com>

https://lists.evolveum.com/mailman/listinfo/midpoint

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20201021/3e96840b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 8058 bytes
Desc: image003.png
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20201021/3e96840b/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD0000.jpg
Type: image/jpeg
Size: 823 bytes
Desc: ~WRD0000.jpg
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20201021/3e96840b/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 9004 bytes
Desc: image005.jpg
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20201021/3e96840b/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 10200 bytes
Desc: image002.jpg
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20201021/3e96840b/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ndsu-primary-job-cleanup-iterative-bulk.xml
Type: application/xml
Size: 4843 bytes
Desc: ndsu-primary-job-cleanup-iterative-bulk.xml
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20201021/3e96840b/attachment.xml>