IGA Anti-Pattern: Role-Based Access Control
Identity governance and administration (IGA) solutions almost universally provide entities for bundling access (permissions and/or resources) provided by IT systems for assignment to users. Such entities may are usually called some variant of role, entitlement, bundle or package. The intention is to ease administration by reducing administrative surface area and providing users with items that are easier to request and review. Teams responsible for deploying and operating an IGA solution must develop a strategy for creating and managing these entities.
Even if the tools do not refer to these entities explicitly as roles, these entities resemble roles to the extent that they bring together users and access. Given that role-based access control (RBAC) is a well-known and effective concept within the authorization domain, it is natural for practitioners to gravitate toward RBAC modeling when planning such entities. Some vendors and professional services providers even provide specific methodologies for applying RBAC modeling to these entities. Yet treating these entities as roles almost invariably leads to undesirable, avoidable outcomes such as poor leverage, high volatility, excessive ceremony and ambiguous governance.
This anti-pattern typically manifests in three forms:
Cookie-cutter roles emerge from a top-down role design approach based on the formal organization structure, where groupings of people are pre-defined (such as by department, location or job function) and then access is assigned to 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.
The nature of unnecessary challenges presented by RBAC in the context of IGA will differ based on the specific manifestation — building-block roles, although still painful, can perform marginally better than the others. The antidote is to recognize that IGA is a distinct problem domain from authorization — although IGA is used to manage authorization systems, it is not an authorization system itself beyond the need to control what actions users are allowed to do within the tool itself. This is the reason for the Declarative IGA information model to eschew the use of the term role for these entities in favor of entitlements and teams.
For years, RBAC has served as a straightjacket for practitioners, preventing them from achieving high leverage, low volatility, minimal ceremony and proper governance. A more productive approach is the two-layer structure that is at the heart of policy-driven administration:
Entitlements bundle together cohesive sets of permissions and/or resources that are assigned as a unit to enable desirable access within a specific application
Teams are groupings of identities that are meaningful from a policy perspective
RBAC in the context of IGA is a variant of the Golden Hammer anti-pattern in software development.