Identity management is made a heck of a lot easier if you have a fool-proof way of identifying someone – no wonder governments are so keen on the idea of identity cards. I make no claim either way on the id cards, but I will say that unique identifiers make ILM/MIIS system so much easier to run that, more than a best practise, they are an absolute essential.
Some points to consider…
The identifier must be unique in the metaverse
There is no technical reason preventing you re-using an identifier, but there are a lot of good design reasons. You should always be able to re-join to a metaverse object using the identifier, with no possibility of multiple matches.
I recommend not even re-using the same identifier across different object types.
Export the identifier into all your connected directories
Find a suitable attribute, set up an export flow rule, and get the identifier out. Then use the same attribute to join back (you should always have join rules, on every MA).
Very rarely there will be some application where you can’t find a suitable attribute to stick the identifier in. In my experience so far, these have always involved extensible MAs, and with XMAs I always maintain a SQL table where I can record extra info that will not go into the target system – such as a mapping between my unique identifier and whatever I’m being forced to use in the external app.
Use something that won’t change
Usernames, email addresses and names are no good. They can change. Forget them.
Ideally use something that comes out of a database system which will already be enforcing a unique ID, such as an HR system.
Ensuring uniqueness
Many organisations are suffering under multiple import systems – perhaps company mergers mean multiple HR systems to incorporate, or different user types being generated in different systems. If there is any risk of a conflict, use an import flow rule to insert a prefix, or stage via a database where you can manipulate the identifier and assure uniqueness.
Don’t use the metaverse GUID
I was, I confess, somewhat horrified when I realised people do this. Just don’t! You never know when you will need to clear out and re-import. You should always plan for this possibility!
Don’t use something system specific
I also have concerns when I hear of the AD SID being used as a unique identifier. I feel that a person (or group, or other object) should be uniquely identifiable whether it is currently in AD or not. Sometimes accounts get deleted and re-created, but that doesn’t stop the person being themself.
I would only consider this a defensible design if AD was your primary, and most trustworthy, data source.
So remember:-
the unique identifier is unique, it doesn’t change, you get it everywhere, and you can rely on it in join rules. Perfect KISS philosophy.
