IAM Myth: IGA Is All About Account Synchronization

Just to be completely clear, account lifecycle management and attribute synchronization are still fundamental functions of every IGA platform. That makes sense, as we need reliable, clean and consistent data to work with. Synchronization is still there, it is still necessary - it is just not the most important responsibility of IGA platforms. IGA platforms are doing so much more that mere synchronization is not playing primary role any more.

Traditional wisdom states that IGA platforms are primarily focused on joiner-mover-leaver (JML) processes. Indeed, the first steps of IGA deployment are usually about JML process automation. However, that is the very beginning of IGA deployment project, not to even mention long-term identity governance program. Even though JML processes are the traditional first steps, they make up relatively small part of IGA landscape. In fact, state-of-the-art IGA platforms are not really focusing on processes at all, they are focusing on policies. IGA platform deals with intricacies of complex lifecycle, managing all possible lifecycle states and state transitions. Of course, the three basic transitions (join, move, leave) are still the most important ones. However, they are not the only ones. Real state models are much more complicated than the "JML" thinking would suggest. User may exist as a candidate before joining, user may be suspended instead of moved (maternal leave, sabbatical), user may still exist after leaving (retiree, alumnus) and so on. Moreover, lifecycle states of an identity is not nearly enough. Identity has numerous relationships to other identities, such as personas, ownership, privileges, membership in organizational units and groups and so on. These need to be managed as well, and they often have lifecycles on their own. Reality of identity management is much more complicated that it would seem.

IGA is not just about user accounts any more. First of all, there are many types of accounts to manage. Majority of accounts are still ordinary user accounts, belonging to employees, contractors and students. However, there are service accounts as well, used by applications and other services instead of users. These correspond to non-human identities, such as machine identities. State-of-the-art IGA platforms are built to manage non-human identities as much as human identities. However, there is a large set of non-human identities that correspond to concepts. Groups, roles, entitlements and access privileges are perhaps the most important examples of such identities. Then there are organizational units, teams, projects, business partners, locations and similar concepts. IGA platform must be able to handle these concepts, as they are intimately related to access control and policies. Good IGA platform must be able to manage wide variety of identity types, not just mere user accounts.

One of the primary responsibilities of IGA platform is access control. However, this much easier said than done. Access control has many shapes and forms. There are many competing access control models, used to express access control policy. Indeed, it is a policy that the IGA systems are built to manage. IGA platforms effectively act as policy administration point (PAP), system which is used to create and manage access control policies. IGA platform then provisions the policy and related data to other components (PRP, PDP, PIP).

It follows that synchronization of entitlements such as groups and roles is one of most useful function of IGA platform. Entitlements are the lifeblood of access control. However, each application works with its own set of entitlements: privileges, permissions, groups, roles and other exotic lifeforms of the access control ZOO. IGA platforms are aligning them, combining them into a unified access control policy. Given the diversity of access control world, this is not entirely easy job.

Even ordinary policies are not easy, unified organization-wide policies are even harder. Static role-based access control (RBAC) models are both very common and very obsolete. However, state-of-the-art IGA systems provide dynamic RBAC models, with policy-based features. E.g. midPoint provides policy-driven RBAC mechanism.

Access control policies are the at the very heart of identity administration. But what about identity governance?

Identity governance is all about policies. However, governance policies are quite different from access control policies. While access control policies specify "who has access to what", governance policies specify "who is responsible for what". These are high-level, business-oriented policies. They are critical for maintaining cybersecurity governance at scale.

Governance policies may take many forms. Some governance policies are at the very boundary of access control, such as segregation of duty (SoD) policies. Governance policies may require that each application has an owner, each entitlement and application role has an owner, critical roles are properly staffed, role definitions are regularly reviewed, risk hot-spots are addressed, applications are properly classified, clearances are reviewed, user awareness is regularly refreshed, and so on. Many governance policies are focused on ownership, as ownership forms a foundation for responsibility. Governance policies are accounting for the technology, yet they are firmly oriented towards business side. They are the best too for identity-based cybersecurity compliance.

Governance policies are the "G" in IGA. No IGA platform would be complete without implementation of identity governance policies.