There were some interesting lessons I learnt on my recent Identity and Access Management journey, particularly in the area of handling the person aspect within the system. Some were expected, while there were others which creep up and hit me bad. Nevertheless, here are some of the reflections from the journey so far.
First off, we need to identify how many different groups of people we have in the enterprise that we want the identity and access management system to manage. We would minimally have the following groups:
Some enterprise might also have the following groups of people:
Now that we have a list of possible person type, we need to go about locating the master source of truth for each of these types. Sometimes a single source could be the master source of more than one type, and in worse cases, there could be multiple sources of truth for a single type. When that happens, you will need to perform aggregation to have the complete picture.
For many enterprise, an important source of truth would be the Human Resource system. It would be that authoritative source for Permanent Staff, and sometimes Temporary Staff.
Next we would have a user directory/repository store like Active Directory or LDAP. These would be where your permanent staff and temporary staff reside in as well. In some cases, you would have the External Parties residing in them as well. Hopefully, you had designed it such that they reside in different tree/container of the directory services, or there is some designated field differentiating them.
Finally, we could to the exception cases of Board of Directors and Customers. The board of directory might reside in the same user directory as well, hopefully as a different tree/container again or some way to identify them. As for the customers, most would really have them totally separate from the enterprise infrastructure in a separate user directory.
Regardless, it is important to identify a master source of truth for each type, such that you can tell when a new person has on-boarded or an existing person is being off-boarded.
When you roll out the identity and management system first time, the world seems perfect. Within a month, however, things start to fall apart. And likely, it is due to one of the below cases which you had neglect to handle. There could be much more special cases, but these are the few that I came across so far.
Personnel or Account Renames
You would think you had the perfect account name generation algorithm. But likely, there are edge cases which result in very ugly names. The derived account name might be some vulgarity or funny meaning, and no one in their right mind would accept it. So you had to rename the account manually. Only to find out that there is no one click Web Interface button to do that. You had to go through a convoluted process of twenty steps to rename one account. And you have twenty accounts to rename!
The same person was previously working in the enterprise, and had left the company a few years back. Now he has joined back the company. If the identity and access management system had a strict rule of no account id reuse, it would generate a new account name for this person. Except, he is really the same person. And in most cases, they really want to use back the same account name. It would be easier for the audit if it is the same name as well, as it would be a smooth continuity instead of having to run through two different account names.
Conversion between Different Groups
He was previously an intern, and now he has joined as a permanent staff. This is similar as a rejoiner, except he had never left. If not catered in the design of the identity and access management system, we might end up with two different accounts, or unnecessary account deletion during the conversion.
I came across this InfoQ mini-book after my journey, and in it contain a very interesting piece of gem. There is a concept of Person UUID, which is a unique ID to identify a person across multiple engagements under different user identities.
Recall earlier that I mention the need to support account name renames. Once that is supported, new audit trail would be logged under the new account name. When doing investigations, however, you should run the audit trail across the two different account names to get an accurate picture. Hence, the concept of Person UUID would come in useful here. From the identity and access management system perspective, these audit trail of these two account names are the same person. This is an extremely useful and important concept. I have yet to see any product implementing this yet, but it would be great if they do in the future.