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
Original Message:
Sent: Wed May 26, 2021 05:22 AM
From: Felipe Risalde Serrano
Subject: What can we do when the identity policy is not able to generate a unique uid
Dear colleagues,
I would like to know what your approach is regarding next issue: "What can we do in ISIM when the identity policy is not able to generate a unique uid".
In our case, it is due to each user has an unique id wherever the platform where the account is hosted. Thus our error comes when, by an unmanaged situation, two accounts are trying to be generated by the same user in the same system. Nevertheless, it could be happened in another approach, for instance, if the Identiy Policy uses a counter and there is not free uids.
In this kind of situations, can the provisioning of the account stopped in a managed way? AFAIK, it can be only done by workflows customization (add account operation), since nothing can be done in the provisioning policies side.
BTW, we are talking in a RBAC model when the accounts are provisioning automatically by roles granted operation, it is, we are not thinking in a "Request account" operation where the form avoids the operation will be triggered.
Going deeper in this issue, we have realized that if the Identiy Policy returns a 'null' value, it can't be known in the Provisioning Policies by means of 'if ( parameters.eruid !=null && (parameters.eruid).length>0)' condition since it doesn't work (it is an odd behaviour), and java exception is thrown when 'parameters.eruid[0]' is gathered. Thus, an error code (such as '1') has to be returned by the Identity Policy if it could be needed to take into consideration this error situation before reaching the 'parameters.eruid[0]' value, for instance account attributes values which depends on the uid.
Thanks in advance for sharing your viewpoint.
------------------------------
Felipe Risalde Serrano
Security Expert
Banco de España
------------------------------