Thanks Franz for your reply,
in our schema HR is responsible for generating employee numbers and Information System, more concisely, our IAM home-made solution, is responsible for generating unique UIDs, and lastly, ISIM is responsible for provisioning using the defined UID.
Nevertheless, from our personal experience, it doesn't mean that ISIM should rely on the UID has been generated rightly (although it will be the 99,9% of the times). Thus, it is identity policy responsibility to confirm the defined UID is unique. Here we are: how to manage the 0,01%.
From our point for view, it makes no sense to customize the workflows for managing this situations, an easier solution should be provided by the ISIM. Someething like a full-stop or break code in the chain that you describe at the beginning of your reply, and which could be generated by the Identity or Provisioning Policy.
Taking into consideration it doesn't exists, and personally I think it makes nonsense to make the effort to customize the workflow for this exception, we will just include some error entries log in the Identiy Provisioning for debugging if it happens, and we will allow the Provisioning Policy to evaluated (without checking the IP return) and throw the unmanaged error.
In relation to the adoption approach, I am with you, I prefer to trigger an error, since it means that the former deprovisioning didn't work (in our case where there is a unique id by person) and it is needed to look for in depth what the root cause was.
Thanks for sharing your thoughts.
------------------------------
Felipe Risalde Serrano
Security Expert
Banco de España
------------------------------
Original Message:
Sent: Wed May 26, 2021 05:43 AM
From: Franz Wolfhagen
Subject: What can we do when the identity policy is not able to generate a unique uid
Let's look at the whole chain - when a new account is requested the Identity Policy is supposed to calculate a unique ID - then you go through the Provisioning Policies where you can reference the ID as mentioned - and then it is transferred to the account add operation (optionally it may go through the account request workflow first).
As you have found out returning nothing from the Identity Policy gives some challenges as you basically need to catch that in the Provisioning Policies - so another normal approach is to give it a dummy well defined value e.g. "Account cannot be created" and check for that value.
I would NOT do any checking in the provisioning policy - but only in the Account Add operation (and Account Request workflow). There is another situation that often occurs and that is that the account exist as an orphan account - and you may choose (depending on the relevance) to perform adopt of the account instead of trying to add another account - this of course needs also to be checked in the Identity Policy if you are using a numbering scheme (I personally wants to avoid that).
These are all technical solutions - but the real underlying problem is who is responsible for creating and maintaining the UIDs. My 20 years of experience clearly points to having this responsibility as part of the authoritative identity process (e.g. SAP HCM or what ever is used as source for identities) - having it downstream in ISIM as not a (general) good solution. Of course there is a need to maintain technical/service accounts in ISIM and that is where ISIM will have the full responsibility of the UID - but that is easier and normally easy to implement using name schemes...
HTH
------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs
------------------------------