FIM Best Practice: Represent each person ONCE in the Metaverse

Our Metaverse should be the defining store of digital identities along with the best quality data we can gather about them. And ideally each person in our environment should only be represented once in the Metaverse.

Here are some of the reasons I’ve seen people deliberately duplicate identities in the Metaverse:

The source data lists people multiple times

This has got to be the worst reason for importing duplicate identities into the Metaverse.  I’ve written on some strategies for dealing with this situation before in Overcoming multiple personality disorder in the source data.

People can have multiple roles

Perhaps a person can be both student and staff, or they need both user and admin accounts in a target system. Ideally we would still have only one object for them in the Metaverse, but this can be difficult to achieve, especially when data about them is sourced from different places and there is no identifying “Person ID” to use in joining.

In some cases proceeding with multiple identities will be the only pragmatic choice. But consider these possibilities first:

  • Where a person has multiple accounts in one system do you want to link them both to the same source HR record to drive deactivation and other changes?
  • Do you have systems where the person should only have one account despite having multiple roles?
  • Do you have compliance or SoD rules that mean you need to know all the roles a person has?

If you answered “yes” to any of these then putting in the extra work to get people into the IAM system only once will be well worth it.

A source-target sync relationship exists that is self-contained and unlikely to change

Perhaps you have a set of GALSync MAs that operate independently of the other MAs in your solution. They should also be using a different Metaverse object type so there’s no confusion with people effectively having two identities in the Metaverse.

While this is an ok design I would still prefer to have a single Metaverse object for each person with all their possible CS objects connected because, if nothing else, it simplifies reporting and troubleshooting when you only have one place to look for information.

Got something to add? Disagree? Comments are open!

About: Carol

I've been doing IT for 30 years, and IdM for 15. I live in Australia and build IdM solutions based on Microsoft Identity Manager. I also play the violin, but that doesn't help much with the IdM solutions.


Leave a Reply

Your email address will not be published. Required fields are marked *


*