Well, here is the question that has been bouncing around for a while which has many of us stumped. It has to do with uniqueness of values within the FIM portal and how to enforce them.
As we all have found out, some harder than others , there is already a uniqueness enforcement on the combination of domain name and account name values. This is enforced under the proverbial covers of FIM with a specialized table in the FIM service called “fim.DomainAndAccountName” where there is a uniqueness index to validate whether or not the combination exists or not. (As an interesting point of note, if you do not specify a domain in user A but do specific a domain in user B, the strings of user A and B who both share the same account name will not be the same ergo, you will not get an error. So be careful here).
But that still begs the question about how do we, the end user and or system integrators of FIM, create our own uniqueness filters. There are really two methods to do this and there are issues with both of them due to some other mechanisms that were built which “conflict” with each other:
1. As of RC2 there is the capability to put a uniqueness filter within the create RCDC’s of the particular object being created. Note that I have only used the word “created” as the filter syntax will fail in the edit RCDC’s because the object itself already has said value configured. Therefore the uniqueness check fails because an object in the database (which is the same object being edited) already has that value configured. Another of our intrepid bloggers, Jorge, has documented this feature here: http://blogs.dirteam.com/blogs/jorge/archive/2009/12/10/checking-uniqueness-of-an-attribute-in-fim-2010-during-the-create-process.aspx
2. Use of an Authorization workflow which will do a search of the FIM service data (or perhaps another external source like AD itself) to validate whether or not the value has already been used and therefore fail the request entirely. Note the “fail the request entirely” portion of that statement. That means that a user who has entered in a lot of data will lose that input if the authorization workflow fails. Once you click the submit button, the portal does not allow you to “recover” the request data that failed and you’d have to key it in all over again. Therefore, a combination of both 1 and 2 would be really good for creation tasks so that you don’t end up with really aggravated users.
There is a caveat to both of these methods and it is the synchronization engine account. This account writes the data directly to the FIM Service web service interface and therefore, does not actually use RCDC’s so the uniqueness filter on the particular attribute will not be applied. Also, due to the requirements of the Synchronization Engine and not wanting it to be waiting for authorization or be authenticated with different requests, the FIM Service actually bypasses the authorization workflows that we created as part of the second solution. So regardless of the solution you put in place within the portal, you will still have to give careful consideration on how you are going to enforce any uniqueness requirements on data coming from the Synchronization Engine. To do this, you may have to have uniqueness validations on the inbound attribute flow of contributing MA’s which make the calls to the FIM service to check for uniqueness prior to the data being committed to the Metaverse (remember, there is no rules extension capabilities in the FIM MA)
Just something to look out for and consider as part of your design planning sessions!