I Was Wrong About Roles In IGA
A not-so-simple misunderstanding may be at the core of IGA misery
Policy-driven administration is the core of sound access risk management, the basis for distinguishing easily between access that is policy-compliant and access that is not — this allows risk management efforts to be concentrated on exceptional access.
Imagine there is a problem domain known as Alfa that is mature enough for there to be multiple solution patterns to problems in the domain. Now imagine there is another problem domain known as Bravo that shares similar characteristics to Alfa but is less mature — there are no Bravo-specific solution patterns yet.
Practitioners working in the Bravo domain, recognizing the similarity between the domains, start experimenting with Alfa solution patterns. However, over time these practitioners observe that Alfa-specific solution patterns do not work well, and even cause an unmanageable mess, in the Bravo domain.
One should expect that such practitioners would start experimenting with other solution patterns to start addressing the actual problems in the Bravo domain. Yet this does not happen. Practitioners continue to apply the same Alfa-specific solution patterns while complaining about the results, blaming the Bravo tools or suggesting that techniques imported from the Alfa domain are outdated.
This problem could be characterized as analogical failure: a comparison is made between two scenarios that are similar in one or more ways, but that similarity is not relevant to the characteristic being inferred.1 There may be a more formal name for this phenomenon, but I have not found one yet.
Obviously I’m talking here about identity governance and administration (IGA) — Bravo is IGA and Alfa is static authorization. IGA certainly resembles static authorization — all the elements are there (imported from IT systems) including accounts, permissions and resources. Intuitively, it makes sense that the business side of the IGA information model might resemble an authorization model, just at a larger scale.
Role-based access control (RBAC) is an important pattern for managing static authorization. It is mature and relatively standardized, and it generally works well in this domain. Yet structuring the business side of IGA along RBAC lines rarely produces desirable outcomes. Why might this be?
I was once an enthusiastic advocate for applying RBAC structures to IGA, even though RBAC had developed a poor reputation in the context of IGA. Many practitioners, including me, have witnessed costly failures when RBAC modeling was applied to IGA and its predecessors.
Some practitioners have wondered if RBAC may be outdated, and whether ABAC (attribute-based access control) might be the a better alternative. However, RBAC remains relevant for static authorization, while ABAC is applicable for dynamic authorization.
I viewed my work on role management in IGA originally as a somewhat contrarian corrective to those arguing for the irrelevance of RBAC. My position was that RBAC was the most correct framework — IGA is closer to static authorization rather than dynamic authorization — it just needed to be approached differently. I even made a red “Make Roles Great Again” hat at one point.
In retrospect, I realize now that I was wrong. I certainly recognized that standard RBAC models could not be successful in the IGA context, but I failed to fully appreciate the fundamental distinction between IGA and static authorization.
Role Management Anti-Patterns
The original focus of my IGA role management research was to investigate why common patterns of designing roles for IGA tended to produce undesirable outcomes. From that work I identified my first set of IGA anti-patterns:
Cookie-cutter roles emerge from a top-down role design approach based on organization structure, where groupings of people are pre-defined (such as by department, location or job function) and then access is assigned to the resulting roles
Building-block roles are hierarchical, often formed from a bottom-up role design approach, where coarse-grained roles are aggregations of multiple fine-grained roles
Workforce classification could be characterized as a middle-out role design approach, where seemingly ad hoc groupings of people (often based on reporting hierarchy) who possess similar access are combined into roles
All of these design approaches fall squarely within an orthodox understanding of RBAC (flat, hierarchical, constrained and even symmetric models) and have been demonstrated to work well with authorization systems. My goal was to explain why they fell flat in IGA, so I developed a framework for explaining these approaches in the context of IGA:
Leverage: Do more with less — it is desirable for a single role to provide as much risk-appropriate access as possible to a distinct group of users, all with minimal investment of time and effort.
Volatility: Reduce the need to redesign or restructure multiple sets of roles (often involving multiple owners) based on predictable changes in the access environment.
Ceremony: Limit the scope of stakeholders who must be involved in the construction of roles — access risk is transitive, so bundling resources and/or permissions into a role carries their associated risks as well and requires the sign-off of resource/permission owners.
Governance: In this context, governance means making good decisions about risk, which implies unambiguous and undiluted control over specific roles in terms of both structure and membership.
The table below summarizes how the identified anti-patterns could be evaluated with respect to the above framework.
An underlying assumption of RBAC appears to be that it is intended to be applied within the fixed boundary of a single authorization system.2 Within this boundary, permissions and resources do not change unpredictably — changes within an authorization system, for instance, are usually introduced with new software releases. Thus, the authorization system provides a stable environment within which roles can be designed, analyzed, deployed and managed.
IGA is responsible for managing numerous discrete authorization systems, all of which have the potential to evolve independently. These authorization systems provide the raw materials (i.e., resources and permissions) that could be bundled into roles; however, IGA is not a stable environment given that the scope of authorization system coverage grows incrementally over time as IT systems are onboarded. Assuming the fixed-boundary assumption is valid, IGA would not be a suitable domain for the successful application of RBAC.
The Two-Layer Enterprise Role Management Pattern
Through research into a problem I understood to be role management at enterprise scale, I managed to document a two-layer role management pattern for IGA that could be characterized as an outside-in role design approach. My research was informed by personal observations from the field and discussions with practitioners who had managed to come to terms with the limitations of RBAC in the context of IGA. At the time, I believed this was still RBAC and thus the model described two types of roles:
Technical roles operated as a (lower) layer adjacent to IT systems, as a means to bundle sets of permissions for assignment to accounts through identities
Business roles operated as a (higher) layer adjacent to identities, as a means to group users together for selection via policies
There were two reasons for arranging the model into two layers:
Loose coupling between layers allows each layer to evolve independently:
Changes in permissions could drive changes to technical roles, most often simply by adding new roles instead of redesigning existing ones
Changes in identity attributes could drive changes to business roles
The area between the the layers allows policies to connect business and technical roles
Such a model satisfied the objectives of the evaluation framework presented above better than any known alternatives:
Leverage: High leverage through incremental analysis and usage of policies to precisely target desired members of technical roles through combinations of business roles, imposing no artificial limits on possible groupings
Volatility: Low volatility from a structural perspective as onboarding systems typically requires only addition of new technical roles, while other structural changes are usually isolated in response to exogenous changes
Ceremony: Potential for low ceremony as technical roles often include resources and permissions only from a single system, and the number of technical roles that include resources from a given system is usually limited
Governance: At worst neutral, as technical roles have unambiguous ownership although there is potential for ambiguity in some business role ownership
Despite describing what I believed to be a fairly elegant pattern, my published research on the topic of role management with IGA did not have much of an impact. Aside from being wrong about the suitability of RBAC in IGA, a big part of the problem was that it was too easily interpreted by practitioners as yet another role design approach. Furthermore, it presented a model that deviated from NIST RBAC guidance, which increased suspicion among some practitioners about its viability. Finally, some practitioners expressed concerns about role explosion.
Overall, it appears that I was too focused on operating within the RBAC frame of reference, so I failed to make a compelling case for why IGA was a distinct problem domain that required special treatment.
Policy-Driven Administration
I didn’t recognize it at the time, but my IGA role management research was describing what I now call policy-driven administration3. Roles were just a sideshow; policies were the main event! Further, my domain modeling efforts revealed that what I identified as roles did not conform to the expected role data structure.4 These were entirely novel entities, although perhaps one could see roles when squinting and viewing them from just the right angle.
Domain-driven design accommodates polysemes when developing a ubiquitous language by allowing bounded contexts to be isolated for context-specific definitions of entities in a model. Thus, it would have been acceptable for me to continue associating RBAC-inspired names to entities on the business side of my reference model. Doing so, however, ran the risk of inviting even more opportunities for misunderstanding by practitioners who might assume RBAC was part of the model. That’s why I settled on entitlements (instead of technical roles) and teams (instead of business roles).
Is this merely semantic fussiness? I don’t think so. If policies are the main event, then it is desirable to avoid distractions caused by importing unrelated terminology. In RBAC, the structure of a role is the embodiment of a policy that dictates the privileges available to members of that role. The term entitlement does not carry this excess baggage while also being long associated with IGA (through IAG, one of its predecessors).
When roles are the only means to express policy, the implication is that out-of-role entitlements are allowed — it is not feasible to express every valid (plausibly acceptable) assignment of user access through roles. To accommodate this, a tool’s information model needs to do one of two things:
Explicitly model entitlements on the business side by mapping them (usually one-to-one) to permissions on the IT side
Allow permissions from the IT side to leak into the business side
Both of these approaches impose costs from a user experience perspective, often requiring users to be able to distinguish between roles and entitlements (or permissions).
[I]n the absence of policies, all access is exceptional.
A policy in IGA is the means by which an entitlement can be assigned automatically to identities based on characteristics of those identities, and subsequently be removed when the the policy is no longer applicable. The most important thing that an IGA solution can contribute to effective management of access risks is the ability to distinguish easily between access that is policy-compliant and access that is not — this allows risk management efforts to be concentrated on exceptional access. I often say that in the absence of policies, all access is exceptional.
Policies in modern IGA tend to be rudimentary, often bolted-on to the information models of tools as standalone objects. Some standalone policies are so simple that they basically implement hierarchical roles with more steps. It is also common for some policies to rely on explicit references to attribute values, which introduces significant change management friction.
Standalone policy objects are another IGA anti-pattern that make policy governance a nightmare, most likely guaranteeing that policies remain under the control of a centralized IGA team. This typically relegates policies to coarse-grained, widely distributed access that is usually characterized as birthright access.
To support governance objectives, policies should conform to the principle of Locality of Behavior — policies would be embedded in various entities to ensure that owners control them. Rather than being monolithic, policies should instead take multiple forms to offer more precise control. For example, entitlements may support the following types of policies:
An attachment policy specifies the conditions under which the entitlement is assigned automatically to an identity
A detachment policy specifies what happens when the attachment policy no longer applies, with the following possible options:
Allow the entitlement to remain assigned, which transitions it to a request-based assignment
Remove the entitlement assignment immediately, or after a specified period of time
Remove the entitlement assignment, but submit a request for it to be added again if approved
Initiate a review to allow someone to determine if the entitlement assignment should be removed
An eligibility policy specifies the conditions under which an entitlement can even be assigned to an identity, overriding all other methods of assignment such as attachment policy or request
A visibility policy specifies the conditions under which an entitlement is visible to users in various situations
An approval policy specifies conditions for entitlement-specific approval
Another way that policy-driven administration improves access risk management is through measurement. The ability to distinguish between policy-compliant and exceptional access allows for measurement of administrative leverage: the proportion of access that is controlled by policies. Leverage can be measured for individual entitlements, for applications (collections of entitlements), for users, for teams, for target integrations, and even the entire organization (or organizational units). Such measurements could provide insight into trends and help identify opportunities to make adjustments.
My intention with this article was to explain in some detail why my thinking on the business side of the IGA information model has shifted over time:
From a focus on enterprise role management to policy-driven administration
From usage of RBAC-inspired terminology to entitlements and teams
The original research on role management was published prior to my recognition that the IGA information model possesses complementary business and IT sides. I have not repudiated my earlier research on role management; instead, I have refined my understanding of the overall model and adopted terminology that I consider to be more precise and less subject to misunderstanding. There is much more to say about policy-driven administration, which I intend to cover in future articles.
Thanks to J.B. O’Kane, a long-time collaborator of mine, who came up with this summary of the phenomenon.
Such an assumption is not stated in the literature surrounding RBAC as far as I can tell.
Some practitioners confuse policy-driven administration with ABAC (attribute-based access control) or PBAC (policy-based access control), even though ABAC and PBAC are associated with dynamic authorization and not IGA.
Recall from a previous article that role was formally defined as combining “the characteristics of 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)”