Entitlements, Permissions and Authorization Constructs
Imprecise terminology leads to miscommunication
The IGA information model is properly understood as being composed of two complementary halves:
IT side — actual or observed state — abstractions that represent the managed environment, primarily consisting of IT systems, accounts, resources and permissions
Business side — business intent or desired state — abstractions (e.g., identities, entitlements) that provide business context for IT-side entities in a manner that makes user access legible to business stakeholders
Identity governance and administration (IGA) has a communication problem, largely because vendors and practitioners have been making it up as they go along. This is a natural consequence of creating an entirely new discipline, as occurred around 25 years ago when user administration and provisioning (UAP, a predecessor to IGA) first appeared on the scene.
Over time, as a discipline matures, one would expect a shared taxonomy to emerge, allowing practitioners to communicate more efficiently and reason collectively about challenges. I’m concerned that this has not happened yet for IGA. There is broad agreement about the distinction between identities and accounts, but not much beyond that. Establishing a taxonomy was one of my motivations for formalizing the IGA information model.
The IGA information model can be thought of as a reference model — a framework for reasoning about IGA tools and practices. Its origin comes from formal modeling of the IGA domain, using my research into IGA products as a starting point. What do IGA solutions have in common? Where do they differ?
This modeling was the point where I first recognized that IGA possesses both a business side and an IT side:
The IT side is a set of abstractions that represent the real digital world of IT systems, the subject matter that IGA is tasked with monitoring and manipulating
The business side is a set of abstractions that provide business context for IT-side entities, making user access legible to business stakeholders
These complementary sets of abstractions (business and IT sides) exist in all IGA solutions, but implementation details can vary greatly. What practically every solution has in common is that identities are on the business side and accounts are on the IT side. Things are more inconsistent, especially terminology, the farther you stray from identities and accounts, however.
This article explains how authorization models provided by IT systems are reflected in the IGA information model through entitlements (on the business side) and permissions (on the IT side). Admittedly, much of the content in this article is foundational and likely to be perceived as basic by experienced practitioners. The purpose for introducing the IGA information model in this way is to orient readers of this newsletter to the terminology that will be used throughout.
Modeling the Real World
Let’s step back a little bit to modeling of the IGA domain. Such a model starts with the external environment, the real world where people and things (such as devices and applications) are assigned access to resources protected by IT systems. People and things belong on the business side while the IT systems and their resources belong on the IT side.
I’m not trying to claim that the resources on the IT side do not possess business value. Instead, the business value of these resources is obscured by abstractions that were created on the IT side in order to control access. What are the natures of these abstractions?
IT systems are not necessarily hosts in the classic sense (machines with names and IP addresses), although often this is the case. An IT systems in this model is properly understood to be a boundary around a set of resources and one or more authorization systems that are used to control access to those resources. This boundary could surround a single host or a collection of hosts.1
User Accounts2 are provided by IT systems to identify the users that wish to interact with an authorization system to access protected resources. User accounts are not a required element, but reliance on user accounts is almost universal — there are cases where IT systems do not provide their own user accounts and instead rely on accounts provided by some other IT system.
Resources are the things that are protected by an authorization system. Most resources are digital (folders, files, tables, columns, rows, transactions, forms, fields and so on) but can also be physical things (like doors, gates or rooms in a physical security system).
An Authorization System possesses an authorization (run-time) engine and an authorization model. An IT system will occasionally support multiple authorization systems simultaneously. Authorization engines can be implemented as primarily static or dynamic:
With static authorization, policies that interpret elements of the authorization model (such as roles) are implemented in code. Note that IGA focuses almost exclusively on static authorization systems, which presently applies to at least 95% of information systems.
With dynamic authorization, policies are isolated from code and often interpreted externally from the code.3
An Authorization Model is a set of authorization constructs and rules. The model’s rules control how its authorization constructs are interpreted by the authorization system’s run-time engine when associated with user accounts and resources.
There is significant variety in authorization models, especially the authorization constructs they utilize. However, there are common patterns — chief among these are what I call the Authorization Trinity:
Groups are constructs that possess a single list of user account references and occasionally references to other groups (when nesting is allowed).
Profiles are constructs that possess a single lists of resource references (most often paired with allowed operations) and occasionally references to other profiles (when nesting is allowed).
Roles combine the characteristics of both groups and profiles into a single object, possessing both a list of user account references and a list of resource references (most often paired with allowed operations). Role nesting is a special case that is usually referred to as hierarchical roles.
Nearly every authorization model utilizes at least one of these authorization constructs. Roles are more versatile — and obviously more complex — than groups and profiles, yet as a data structure roles remain quite simple. The key advantage of roles is locality of behavior — one can achieve a specific control objective (who can perform actions with certain resources) through the role itself. Groups and profiles, on the other hand, usually require involvement of other constructs in the authorization model to realize control objectives.4
There are numerous other types of authorization constructs that are not used as frequently, including access control lists, attributes, switches, policies, and so on.
Modeling the IT Side In Relation to the Real World
The purpose of the IT side is to represent the external environment in a manner that makes its management practical and efficient. This is accomplished through use of abstractions that represent IT systems and the accounts, resources and authorization constructs they provide:
A target integration (often called simply a target) anchors an IT system into the IT side of the information model, acting as a container for the accounts, resources and authorization constructs that are assimilated from the IT system:
There may be more than one target integration for a given IT system, which may be necessary when an IT system possesses multiple authorization systems (with each authorization system applied to different types of resources).
Additional target integrations may be needed to assimilate data provided by the IT system that may not be accessible through its authorization system(s).
Accounts are representations of user accounts provided by the IT system, with each account rendered as a set of attributes.
Resources are representations of resources protected by the IT system.
Permissions are representations of authorization constructs provided by the IT system. The goal of this abstraction is to normalize the representation of the various forms that authorization constructs can take, whether they are groups, profiles, roles or almost anything else.5
The primary mechanism by which user access is manipulated with IGA tools is through assignment of accounts to permissions. IGA does not care about the physical forms of authorization constructs that are represented by permissions — the relationship between accounts and permissions is assumed to be simply assigned or not assigned. There are some authorization constructs, such as policies6, that are more complex than can be accommodated by permissions — these would be handled through abstractions that are not represented in this view of the model.
Resources are not universally supported within the information models of modern IGA tools. It is possible, and quite common, to manage user access without resources. However, resources provide important context for user access on the IT side, since accounts can be authorized to perform certain actions with resources either directly or indirectly through permissions depending on the authorization model’s rules.
Modeling the Business Side In Relation to the IT Side
The purpose of the business side is to provide context to entities on the IT side of the IGA information model in a manner that makes user access legible to business stakeholders. This is accomplished primarily through use of abstractions such as identities and entitlements:
Identities can represent humans or non-humans as collections of attributes, with attribute values sourced from affiliations controlled by identity life cycle processes. This model for identities is unique to Declarative IGA and will be introduced in a future article.
Entitlements represent bundles of permissions and/or resources that can be assigned to users. When a resource is bundled in an entitlement, one or more corresponding actions must be specified (represented as an association class in the diagram and consistent with the distinction between permissions and resources explained above).
An entitlement can be assigned to an identity, and through this assignment the bundled permissions and/or resources are assigned to accounts (provided by the corresponding IT system) owned by the identity. A plurality of entitlements (possibly greater than 50%) will map to only a single permission or resource.
Entitlements are the most powerful entities in the IGA information model, representing the primary surface area for managing user access and the focal point for policy-driven administration. Entitlements will be explored more thoroughly in future articles.
Clarifying the Terminology
My use of the term entitlement on the business side and permission on the IT side usually are the most controversial aspects of the IGA information model. Initial modeling of the IGA domain was focused on getting the structure right before assigning names to structural entities.
Once the model was stabilized, assigning names to entities resembled a game of Pin the Tail on the Donkey. Certain names could plausibly be applied to multiple entities. In practice, multiple names are applied across modern IGA tools to the same structural entity. What I call an entitlement in the IGA information model is variously called a role, technical role, access role, access package, access bundle, permission, grant or simply access in various IGA tools.
I deliberately avoided using the term role in place of entitlement because I wanted to emphasize that roles are authorization constructs.7 First, role is such an overloaded term today that it has been rendered meaningless. Second, and most importantly, use of the term role within IGA tools has led too many practitioners to assume that RBAC (role-based access control) methodologies could be applied to roles in IGA.
IGA is not an authorization system, but instead it is a set of tools and practices for managing the static elements of various authorization systems in a heterogeneous environment. Attempting to apply RBAC methodologies to arrange and manage entitlements is best understood as an IGA anti-pattern that will be explored in a future article.
When working with an IGA tool, if you ever felt like something was weird (or too IT-centric), it was probably because the tool was not properly observing distinctions between the business and IT sides — some IGA tools allow IT-side entities to leak into the business side. The IGA information model provides practitioners with a vocabulary for reasoning about these issues.
Every IGA tool implements its own information model, with its own structural entities, relationships and terminology. You should expect there to be significant overlap between the IGA information model and a tool’s structural entities and relationships, although there will be significant differences in some details. Once structural elements and relationships have been reconciled, terminology can be mapped to allow more efficient communication about IGA practices independent of tooling.
Interestingly, there are cases where the same host could be represented by multiple IT systems.
Technically, user accounts are not provided by the IT system itself but through the accounting subsystem — the reason the term account is used — as a way to account for the consumption of system resources (CPU, memory, file system and so on) by specific users.
Modern IGA tools’ emerging inclusion of CIEM (cloud infrastructure entitlement management) features points toward a future where IGA is more involved with dynamic authorization. Although cloud infrastructure authorization engines are generally static (or at least operate as if they are), their authorization models share some characteristics with models commonly paired with dynamic authorization engines.
Examples with the simplest authorization systems:
To observe access allowed for a group, it likely would be necessary to scan resources and associated authorization constructs (often access control lists) to find references to the group
To observe users with access to a profile, it likely would be necessary to scan user accounts to find references to the profile
More sophisticated authorization systems tend to provide back-links on objects:
Groups may possess references to resources or access control lists that reference the groups to allow evaluation of access scope similar to roles while observing only the group
Profiles may possess references to user accounts that reference the profiles to allow evaluation of access assignments similar to roles while observing only the profile
One reality of working with various authorization models is that authorization constructs are not named consistently. I have observed IT systems that provide “roles” that, upon closer inspection, are implemented as profiles, groups or even simple attributes.
The typical structure of a policy is a list of subject-verb-object statements:
Subject would be some type of selector that references accounts by some attribute values, rendered as a logical expression
Verb is some type of operation that could be allowed or denied for the selected objects
Object would be some type of selector that references resources by some attribute values or tags, rendered as a logical expression
IGA tools certainly have internal authorization needs, and these are properly handled with authorization constructs such as groups, profiles or roles. These constructs should be managed separately, preferably through a virtual IT system within the IGA tool that can then be managed alongside other IT systems in the environment.