Implementation practice for IAM and provisioning automation

March 20, 2024

What Identity and Access Management (IAM) is about?

Let me define what is it about. First we need to start with objects that we want to manage - identities. Usually we may encounter two types of identities:

People identities - identities for users, employees, customers, partners.
System identities - applications, systems, services.

We want to manage access given to these identities. Usually we may encounter three levels of authorization:

Access to the organization’s IT - usually this is done by provisioning an account representing an identity, but it is not a requirement.
Access to a system within organization - usually this is done by provisioning an account within the system. This account usually is connected to organizational account, but it is not a requirement.
Access to data within the system - usually this is done by defining roles within system and assigning roles to an account within system, but it is not a requirement as there could permissions based model on resource level.

Level of authorization are regulated by a set of access rules, the rules that are defined by business, not by IT. This kind of set often called an access matrix. So, we have our identities and access matrix that defines access for each identity. These three concepts are the core concepts on which identity and access management solution is being built.

Now we should not confuse identities and security principals. Identity is an abstracted entity represented by one or more records in organization. Security principal is implemented entity that can help to use associated access defined by rules.

What it is not about?

It is not about things that change over long-term periods:

It is not about authentication methods or multi-factor authentication. Authentication methods and protections evolve - from simple passwords to password policies, to MFA, to OTP, to OAuth…
It is not about employee HR workflows as identities can belong to vendors or systems.
It is not about centralized security principals store such as Active Directory, Azure Active Directory, users database etc. , as today’s systems are distributed between on-prem and cloud, vendors and SaaS.

Every system has its own authentication capabilities. When you are implementing green field infrastructure, you may have an opportunity to standardize it - to use one or two authentication methods, however, as time goes by it will become more and more expensive to keep things standardized. You may also face external systems, that bring more business value than standardization of authentication methods brings. This mean that standardization may be sacrificed. Imagine, if your IAM solution would be dependent on authentication method, that may change in 2-3 years - your IAM solution will eventually loose stability.

Of course employee are not the only users. In todays world microservices, cloud systems are interconnected and your organization is not an exception. These systems and services will require their own kind of security principals. Your systems, talking to external systems, will also need some kind of security principals. In addition to that, temporary workers, interns, visitors, vendors all may require identities and security principals, that have to be managed. So it is not just employee workflows. We often see that there is one integration done between internal HR system to provision security principal based on list of employees contained in HR system. As a result, scope of such of integration is very limited compared to real life situations and cannot be at the core of your IAM solution.

Centralized security principals store is good for green field. But, what will happen if you need to manage identities in a bank mainframe or other similar black box? What, if external SaaS service uses its own identities and security principals management? Imagine situation, when you have only 20% of permanent contract employees and rest of employees are seasonal workers? Seasonal workers may not get an account in centralized store, they may get access to external services using phone login and their personal phones are being used for this. So you cannot fully rely on your centralized principals store as a basis for your IAM solution.

Sure these areas are important, but you should keep in mind that authentication methods, records in your HR system or centralized security principals store are dynamic entities, that are not always present. You should avoid assumptions, where it is assumed that these entities are present and it will save your time in the future.

Existing situation

You may safely assume, that when you will start to implement identity management, you will discover “chaos”.

Access rules are not followed or not implemented.
Unaccounted exceptions to access rules everywhere. Many teams have their own “special case”.
Access rules are outdated, when they were created some time ago, but due to lack of management tools it is hard to track and maintain them.
Developer and vendors have too much access. Missing planning and DevOps, infrastructure-as-a-code result in unmanaged security principals deployed all over the place.
Ghost security principals assign to people who are no longer work for the vendor.

Often you will see some initiatives, like “let’s build IAM around Active Directory/LDAP security groups”, “let’s build IAM around specific cloud vendor capabilities”, “let’s build provisioning around specific protocol”. While these are important, they are limited in scope and could be applicable to specific product or system, not the overall organization IT.

Delivery approach

In some extreme cases, you may say, that you would like to rearchitect your entire IAM strategy, however in existing organization critical business lines that have to be kept alive, have to be up and running every day.

Note: Here, by architecture I mean delivering business value. Architecture is not about specific technical or modular design.

Imagine that there is a team responsible for 80% of organization’s revenue, you don’t want to interrupt their work, even - interrupting their work, even for theoretically correct improvements, poses risks. For instance, consider a bank handling 80% of transactions nationwide. Nobody will allow you to stop it even for a single day, because you will have to prove in numbers, that your IAM strategy will bring more value, that it will require to sacrifice. For you, as an architect quantifying this value in tangible terms - expressed in currency - is essential. In theory it is possible, but in practice it may take months to do the calculations.

You may also have tens or hundreds of internal systems or apps that require access management. This mean that changing, deployment and adoption of new IAM solution adds to the complexity of building one. IAM architecture becomes a long-term endeavor, necessitating management support beyond individual careers.

If you think about it, IAM is similar to ERP, HR, Financial system, productivity suites. They are on the same level. This kind of solutions have to be operational at all times as long as organization is operational. Only then you may say that security is one of your organization’s core processes.

You may argue that you have SOC in your organization and they may have very advanced SIEM analytics and you don’t need another IAM solution. However, in my opinion this is different. SOC is IT. How you can close the gap between the data entered in HR system by HR people and people defining levels of access inside mainframe maintained by vendor and logs? For sure, good IAM solution will be helpful to SOC, especially when business employees and SOC are able to use same solution for their respective needs.

Good approach: focus on consistency

Okey, we have all these challenges. So what could be the good approach? The answer - focus on consistency. What is consistency? It is easier to start with inconsistencies. Inconsistency, in our context is difference or contradiction between the expected access, that should be given to an identity, based on access matrix, and actual access that is given, in the systems supported by IAM solution. Consistency is the absence of inconsistencies.

The concept - process

So we have to focus on consistency between access matrix (see definition above) and actual access given to security principals representing the identities in the systems supported by your IAM solution. The conceptual process is simple:

First, in the first step consistency is evaluated by performing consistency check across all IT systems supported by IAM solution. As a result, we produce list of inconsistencies across all IT systems.
Second, consistency remediation plan is created. Plan contains order or unordered list of remediation actions.
Third, remediation plan is executed, by executing every remediation action. As a result, consistency of all systems becomes closer to ideal.
And this sequence of steps 1-3 repeats.

We understand that it could be impossible to achieve instant remediation for all inconsistencies in a single cycle. Here is the explanation. Consistency is evaluated, in other words, consistency check is performed on regular basis or can be triggered on-demand. It is important to have both capabilities. Here is useful list of what you may need to manage consistency checks:

When regular, say daily, process fails, you should be able trigger consistency check manually.
To save time and costs, you would want to have regular check as well. Regular checks also help in situations, when systems are taken offline temporarily.
You may also want to have capability to pause or dynamically adjust schedule of regular consistency checks. You will be able to control frequency of checks or control align to unexpected system maintenance activities.
For situations, when system is taken offline for longer periods or being decommissioned, you need capability to exclude system from consistency checks - in other words, control scope of consistency checks.

Usually consistency check is performed every several minutes. This means that any inconsistencies are expected to be fixed in the matter of minutes. If consistency is not achieve in one cycle, then solution should be able to do on the next cycle or even later. Eventually consistency will be achieved. Therefore solution should be based on eventual consistency concept (https://en.wikipedia.org/wiki/Eventual_consistency).