Managing People in Identity and Access Management System

/

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.

Different Groups of People

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:

  • Permanent Staff - These would be all those who are on the payroll. They might be further divided into the different pay grade, but for the purpose of identity management, it is sufficient to group them as permanent staff.
  • Temporary Staff - These would be those who are still on the payroll, but for a limited time. Examples could be contract staff and interns.
  • External Parties - Over the course of business, external parties might require an account or access to the enterprise system. These would be project vendors, or even external auditors. They are similar to temporary staff in that their access are temporary, but they would not be on the payroll and might not have the same kind of access. For some, their access might be even more privileged, and they are consider higher risk than compared to temporary staff.

Some enterprise might also have the following groups of people:

  • Board of Directors - They are not exactly on the payroll, but they do need access, and they are considered as part of the enterprise as well. You would like to handle them in a special way, because they are really special :)
  • Customers - Some enterprise are service providers, and would have customer facing systems. In many case, you might not handle them together with your internal identity and access management system, but you should take an effort to identify them, especially if they share the same user repository as the internal users.

Master Source of Truth

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.

Special Case Scenarios

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!

Rejoiner

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.

Person UUID – The Ultimate Identity Reference - Special callout to Identity Management on a Shoestring from InfoQ

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.