IAM implementation patterns
IAM systems are deployed in many contexts. Among these, they may be used to create and delete identities and to grant and revoke access for:
- The workforce of an organization, be it a corporation or non-profit, government or military entity. In this case, it is normally the identities and security access rights (entitlements) of employees and contractors that are managed. This is sometimes called the "business to employee" or B2E pattern, or the corporate pattern.
- The partners of an organization -- i.e., users who work for organizations that are affiliated with the one hosting an IAM system. Such IAM systems typically support some sort of a partner portal. This is also called the "business to business" or B2B pattern.
- The customers of an organization -- whether they are retail customers of a commercial entity, or citizens interacting with a government, or patients interacting with a healthcare provider. This is also called the "business to consumer" or B2C pattern, and it also applies to "e-Health" and "e-Government."
- Faculty, students, staff and alumni of an institution of higher learning. This is also called the "EDU" pattern.
- Employees, doctors and other caregivers and clinicians in a single hospital or group of affiliated hospitals. This is also called the "Healthcare" pattern.
The patterns described above are called out because there is often a great deal of commonality between the requirements of different IAM deployments within the same pattern. On the other hand, business processes, required controls and typical integrations differ greatly between any two patterns.
Complex business processes
Many organizations struggle to automate IAM business processes. Here we explore the challenges that create a barrier to effective process automation.
Broadly, IAM processes can be thought of as processes relating to 'joiners' -- i.e., users establishing a new relationship with the organization, 'movers' -- i.e., users whose affiliation with the organization is changing in some way (new job, location, manager, etc.) and 'leavers' -- i.e., users whose affiliation with the organization is coming to an end. We can refer to these as J/M/L processes as a short-hand.
Within each IAM deployment pattern, there are different sorts of J/M/L processes. For example, in the workforce IAM pattern, most joiners and leavers can be identified through changes in a system of record (SoR), such as an HR system. On the other hand, in the partner portal pattern, there is rarely a system of record, so different joiner and leaver processes are required.
Prior to attempting IAM process automation, many organizations assume that the challenge in J/M/L process automation will relate to integration with systems and applications where access should be granted and revoked. In most organizations, however, there are only a modest number (tens) of such integrations and many of them are connections to popular systems (AD, PeopleSoft, SAP, Salesforce, etc.), for which most IAM products include connectors. In other words, application integration is not normally a major barrier to J/M/L process automation. The exceptions to this are where there are custom or vertical-market applications, which often do not expose an API for managing user access rights, or cases where there are hundreds of required integrations. These are edge cases, however.
The real challenge faced by most organizations is process complexity. Real-world J/M/L processes, even prior to IAM process automation, have to cope with many edge cases. There is an almost fractal level of detail to process definitions -- the closer one looks at process requirements, the more special-case behaviours are required.
Following are examples of such edge case, all drawn from the corporate / workforce deployment pattern.
- What unique identifier should be assigned to a new hire?
In most organizations, this is something based on the user's
name, but the algorithm has to allow for cases where multiple
people have the same name. To handle this, unique IDs are assigned
programmatically and stored in a reservation system. What
happens if there was an error in user input, or if the new
hire never actually shows up for their first day of work?
In these cases, it is preferable to release the ID, so that if
another new hire comes along later with the same or a similar name,
they can use the (often desirable) ID.
In practice, users are assigned multiple unique IDs. For example, an employee number, a short network login ID, a fully qualified LDAP ID, a numeric Unix UID, etc.
Complexity here arises from:
- Unique ID generation.
- ID reservation.
- ID retention when users do start work.
- Releasing the ID reservation in case of input error or no-shows.
- New hires are sometimes not, in fact, new. Employees leave and
return as contractors. Contractors end their work term, leave and
later return to start a new work term. When being onboarded,
users rarely indicate that they are returnees rather than net-new.
Moreover, they may not recall what their unique identifier was in
Any joiner process should:
- Apply heuristics to identity information provided for the new hire (name, date of birth, government ID numbers, mobile phone number or personal e-mail address, etc.) and flag new hires who appear to actually be returnees.
- Warn IT or HR staff that an apparent new hire may be a returnee.
- Block the onboarding process if there is high confidence that the user in question is a returnee. In this case, either notify someone that this is someone who left on bad terms and should not be allowed back into the organization, or provide a mechanism to reactivate the old identity, to ensure continuity in the audit record.
- New hires should be assigned resources. An account in some container in the directory, a home directory folder on a file server with adequate capacity and near the user's work location, a mail folder on an appropriate mail server, etc. Which resources to assign and where to place them (OU container, filesystem path, mail database, etc.) should be based on rules that take into consideration the user's organizational affiliation, location, etc.
Users sometimes change their name. Surname changes are commonly due to a change in marital status while first name changes are sometimes due to gender reassignment.
Name changes are complex because they often have side-effects:
- Assign new login IDs.
- Convert the old e-mail address to an alias.
- Assign a new e-mail address, based on the user's new name but still unique.
- If the home directory path incorporates the user ID, move it to a new path.
Moreover, user IDs may be embedded in scripts and access rights, in which case these should all be updated after an ID change.
Complexity in the event of a name change arises from the need to detect side-effects and to propagate changes to e-mail addresses and login IDs to systems, applications, scripts and filesystems.
People often move through organizations. They may change job role, manager, department, work location, etc. Such changes often have side effects:
- Add some and revoke other roles.
- Revoke some entitlements and assign others.
- Ask the user's old or new manager to review the user's entitlements, and for each one either certify it or ask that it be revoked.
- Move the user's home directory to a different filesystem location.
- Move the user's e-mail folder to a different mail database.
- Move the user's account in an AD or LDAP directory to a different container (OU).
Essentially, all the rules used to assign entitlements and resources in the onboarding process should be sensitive to attribute changes and should be applied to computing and applying side-effects such as the above.
Leaves of absence
Users sometimes leave for an extended period, only to return later. Examples include paternity or maternity leaves and extended/unpaid holidays. When this happens:
- There may be a scheduled leave-commencement date or else a request for leave of absence (LoA) may take effective immediately.
- The user who left for a LoA may provide a scheduled return date.
- At the end of the LoA, the user may actually return, or fail to return. When users fail to return, this may be because they want to extend the LoA or because they will not return at all.
- While a user is on LoA, their access to systems and applications should be disabled in a manner that is reversible if/when they return.
- When a user does return, their passwords will almost certainly need to be reset, as they will have been both forgotten and expired.
Real world access revocation processes are multi-step, multi-day sequences. For example, a typical scheduled termination works as follows:
- Capture a scheduled termination date for a user, such as a contractor (whose work term will end) or employee (who will retire or who has submitted notice of a resignation).
- Prior to the actual termination date, send one or more advance warnings to the user's manager or other stake-holders.
- Enable the same stake-holders to change the scheduled termination date. Possibly subject such changes to approval.
- On the date of deactivation, disable login rights for the user in question, but ensure that any changes are easily reversible. Send warnings at that time to stake-holders indicating that access was, in fact, deactivated.
- Provide a mechanism to "undo" the deactivation, mainly because managers are quite likely to ignore the warnings described earlier and will call to complain that their subordinate's access was incorrectly deactivated.
- After a suitably long "cooling period," start cleaning up
accounts and other resources:
- Revoke security group memberships.
- Possibly move directory accounts to a special container of terminated users.
- Possibly delete login accounts.
- Archive material such as mail folders and home directories.
- Possibly move and/or change ownership of these resources.
- Possibly send links to archived content to stake-holders.
- Retain identity attributes as well as reason for termination and whether rehiring is allowed, as this data should be available in the 'new hire' processes mentioned earlier, to handle returnees.
A subset of this process is used for urgent termination, for example if someone has to be literally escorted off the premises. In both cases, who can request deactivation and who must approve it are policy questions that must be addressed.
All IAM systems by definition contain personally identifying data (PII) such as names, phone numbers, e-mail addresses, etc. Privacy legislation in most jurisdictions requires that access to such data be controlled and audited:
- Who can see whose user profile?
- Given that one user can see another's profile, what details should be visible?
- Given that one user can see another's profile, what kinds of changes should be requestable?
- Having submitted a change request to a user's identity data or entitlements, who should be invited to approve these changes? What data should the authorizer(s) be able to see?
Consider some potentially privacy-compromising attributes as illustrative examples:
- A user's scheduled termination date -- should probably be visible to the user's manager and to HR, but not to the user's themselves, in the event that the termination is involuntary and has not yet been disclosed.
- A user's home address or emergency contact information -- should be visible to HR who may wish to verify the user's safety in the event that the user does not come to work, and perhaps available to the user's manager in some contexts, but rarely to anyone else.
Such access controls call for a model where different types of relationships between a requester and user or recipient are defined, and are used to determine visibility, requestability and more.