Notional architecture for modern IAM: Part 3 of 4

Welcome back to part 3 of my thoughts on enterprise patterns for modern IAM. Last week I provided a few techniques for thinking about the systems that you need to protect and optimizing controls for them. That included identifying which kind of policy (admin-, run-, or event-time) was most important for which kind of system as well as some thoughts on policy complexity per type of system to be protected.

This week I want to present what I believe is a conceptual architecture for modern IAM. It feels very different from the kinds of IAM infrastructure architectures you might be familiar with. It is, in some sense, a higher level architecture into which you would place classical components such as IGA or an IDP. But instead of me presenting it here, read on and discover!

Notional architecture for modern IAM

Armed with guiding principles and a general plan for aligning controls to enterprise systems, one can now explore an architecture. The notional architecture contains all the use cases that the Pyramid of Pain contains, controls you would use, how complex the policies would be, when they would be applied.

This architecture will describe a policy backplane and the three tiers it united: data, orchestration, and execution.

This architecture does not exist in a vacuum. Each organization will have its own resiliency requirements along with its own preferred approaches to achieving those requirements; those approaches must be used for components within this architecture. This architecture requires a clear understanding of the trust model within and between the tiers. Architects must assume that adversaries are going to try and forge messages between and within the tiers and thus there is a requirement to provide appropriate protections. Additionally, monitoring and response capabilities, both automated and human, have to be baked in to detect and respond to threats to the identity infrastructure itself - e.g., adversaries attempting to misuse or abuse IAM components in each tier.

Events

One of the most defining characteristics of a modern IAM architecture is the use of, typically, event-time signals (hereafter referred to as events) to trigger policy evaluation and decision execution. These events are emitted by components within each of the following tiers of the architecture. These components may be IAM systems such as an IGA system sending a signal to a provisioning connector to modify a specific user account or a privileged access management system signaling an identity provider (IDP) to grant elevated access to a production system. But events can also be emitted by things other than traditional IAM systems. For example, imagine a risk evaluation system trained to watch for token exfiltration and impossible travel. That system may detect suspicious activity and send an event to a session management system to invalidate the errant session token.

Harkening back to the principle of Standards Assumptive, these events should be rooted in identity standards, notably the Shared Signals Framework and the associated CAEP and RISC profiles. These events ought to be based on Security Event Tokens (SET). These modern standards apply not only to run- and event-time time use cases, but also to admin-time use cases via the SCIM profile for security event tokens.

Lastly, although this architecture is oriented around near-real-time signaling to trigger dynamic responses to changes in the business and technical environments, it can also support more traditional means of invoking actions such as polling for data changes and human-driven workflows. Said differently, the future is not one of just fancy AI models roaming the enterprise sending SETs; it is a blend of humans and “robots” doing their jobs, sometimes in collaboration, sometimes separately, to ensure that the right people get the right access at the right time under the right conditions.

Policy Backplane

Every IAM component has rules of the road to which it must adhere and enforce; policy provides those rules. To begin, an enterprise will have multiple policy environments—some tightly bound to a specific tier or IAM component within a specific tier—and a small number that manage policy that applies to multiple tiers. The goal of the policy backplane is to simplify and reduce the overall policy administration, documentation, and auditing across the enterprise. There is an additional goal of the policy backplane—governance—to improve the overall efficacy of policies and controls. A shiner, flashier policy administration experience makes for nice demos but is not valuable unless it can increase the effectiveness of controls while lowering the administrative burdens of maintaining and applying those controls. This must include an impact assessment of policy changes and policy testing.

Policy backplane of the notional architecture for modern IAM

With respect to policy administration, it is imperative that there is a clear line of sight from the policy administration to the security operations center (SOC). Knowing who is changing policy is crucial from an audit perspective, especially when those changes appear to be anomalous; those policy changes likely require further investigation and response.

The expectation is that each of the tiers—data, orchestration, and execution—IAM component will evaluate policy to affect controls. That policy evaluation may be a scheduled one or triggered by an event. Regardless, having constant and continuous evaluation of policy coupled with near real-time signals that enables dynamic IAM capabilities.

Data Tier

To deliver the kinds of dynamic IAM capabilities the modern enterprise requires, one must start with the data: not data that is narrowly scoped to one kind of IAM capability and not one kind of data source from only one kind of attribute source. The data tier must accommodate data from all three of IAM’s times of use: admin-, run-, and event-time. The data tier needs to store or access user account details, target system entitlements, and their assignments (admin-time data). It must also manage authentication and session data, including challenge methods and single sign-on activity (run-time data). But just admin- and run-time data is not enough: the data tier also needs to include event-time signals, including which systems terminated what user accounts’ sessions because of unusual activity, when and where password resets were attempted and which were completed successfully, and more. Said differently, the data tier must be IAM domain independent; it must serve user provisioning services as well as it can serve authentication, privileged access, and fine-grained authorization services.

Policy backplane plus the data tier of the notional architecture for modern IAM

The data tier needs to serve multiple IAM use cases for those domains. It needs to act as an attribute store from which IAM services retrieve information about a person and related user accounts. It needs to act like a policy information point to facilitate authorization decisions. The breadth of IAM services hints at the variety of data that needs to be in the data tier. Additionally, in order to fully address workforce use cases, the data tier should house or have access to data on which entitlements were used by which users to perform specific actions. That kind of instrumentation is not often found in business systems and when it is the resulting audit data is more likely to find its way to a security data lake. Furthermore, the data tier ought to serve more than just workforce and contractor/third-party use cases. It ought to be flexible and robust enough to address customer identity (CIAM) and machine/non-human identity use cases too.

And the data tier needs to serve more than just core IAM use cases as well. It needs to be able to help forensic investigators as easily as it can serve attribute consumers, such an IDP. It needs to be ready to natively serve multiple AI models, some of which are third-party provided and others that are homegrown. Regardless of the needs of the consumers of this data, the data tier needs to provide clarity in terms of which source systems are authoritative for which pieces of information, ideally along with source system metadata on the provenance and confidence in its data.

Organizations also need some degree of future-proofing. When it comes to identity-related data, one cannot assume that the organization has every piece of information it needs a priori. In a potential future world, information such as evidence of professional certifications, citizenship, personhood, and authority to perform a specific function may live at the far edge of the architecture—with the individual in the form of a credential. While the data tier cannot manage this information per se (although it might be called upon to cache such information), the data catalogs associated with this data tier must make it clear that the individual (or, more accurately, their credentials manager/wallet) needs to be consulted to learn the information.

Lastly, one should not make the assumption that the data tier needs its own copy of data from source systems. Referencing data without copying it, so long as that process is within performance requirements, is often a superior way to go. Consider that some of the information relevant to IAM policy decisions might live in adjacent security data lakes or customer data platforms, and be so voluminous that making copying it a nonstarter. Modern data management architectures with techniques like zero-copy data lakes can facilitate this.

But, Reader, if what you have just read doesn’t feel familiar in terms of how you manage IAM data, you are not wrong. This sort of data management is, for the wide majority of organizations, extremely different from how IAM-related information is managed today. As a discipline, IAM is long overdue for a significant increase in its data management skill set and doing so requires partnership and support from data management and data science professionals; no amount of box-and-arrow diagrams can change that.

Orchestration Tier

The coordination of components within an enterprise’s identity fabric is no small feat. Combine that with contributing capabilities such as fraud detection, endpoint detection and response, and threat intelligence, informed by the data tier, and you have a complex mesh of functions to coordinate. This work will be initiated through a combination of traditional Human Resource information system “listeners” to detect joiner, mover, leaver events, continuous IAM policy evaluation, and, eventually, autonomous agents. In fact, given the volume of events the modern dynamic enterprise will generate, humans alone will not be able to scale in response; AI and automation is the sensible path forward.

Today systems such as user provisioning and IT service management are crucial orchestration tier components. And with an eye on achieving greater agility and dynamism, one can foresee that event “hubs” that process near real-time signals become a crucial part of the orchestration tier. This orchestration tier houses both IAM domain-dependent and independent components. Systems like user provisioning and continuous authentication are examples of domain-dependent orchestration systems, whereas a more generic event “hub” which utilizes the SSF and processes SETs is a domain-independent orchestration system.

To deliver the kinds of dynamic capabilities the modern enterprise requires, the orchestration tier needs the ability to consume, transform, and emit events. That said, one must acknowledge that event-based orchestration is an emerging space within IAM and that an enterprise’s near-term architecture will likely be a combination of pre-existing solutions, few of them currently support these standards. To accommodate this, the event hubs in the orchestration layer will have to be able to consume and transform both proprietary calls and non-SET-based signals; in some sense webhooks will be for the event-based world what comma-separated value (CSV) files were for identity governance and administration.

Data and orchestration tiers of the notional architecture for modern IAM

Not only does the orchestration tier provide the coordination between different parts of an enterprise’s identity (as well as larger cybersecurity) infrastructure, but it also needs to provide a form of bookkeeping. The word “bookkeeping” is used here instead of “auditing” for a specific reason; consider that a system might send an event and have no awareness of whether the event was acted upon. Its audit logs reflect an event was thrown but have nothing to say about what happened because of it. In this regard, the throwing of an event could be considered a transaction in the debit column of our double-entry bookkeeping analogy and a subsequent action taken by another system is a transaction in the credit column. Thus there is a need to document which policy evaluations were triggered by which events that in turn resulted in which accounts being granted which privileges and thus ensure the books balance, so to speak.

Consider an example in which an enterprise has a policy that states a devops team member should only be granted access to the production cloud computing environment if there is an open incident, with a ticket assigned to the team member. They must also be using a managed device that is fully patched and up-to-date and if any of those conditions change, including the closure of the ticket, then remove the granted access. Multiple systems will need to work together to orchestrate this policy. That orchestration will likely, especially today, be a combination of proprietary signals and triggers. Each of the systems will undoubtedly have separate audit trails for the actions they took. In such an environment, identity and security practitioners would have to stitch together the separate audit logs on their own; they would manually do the bookkeeping that in the future could and should be produced by a more coordinated orchestration tier.

The future of the orchestration tier includes AI models and autonomous agents taking actions informed by their training and the data tier. To enable this safely requires kill switches between the tiers, especially between the orchestration and forthcoming execution tier. Such switches are not only required to prevent a malfunctioning model from inadvertently disrupting operations across the enterprise, but also to avoid self-inflicted issues like an internal DDoS. This is not a new concern—in the past, connecting a user provisioning system directly to a directory, which served both as an authoritative source for user data and a provisioning target, could lead to similar unintended consequences. The introduction of AI simply amplifies these risks, making them more visible to non-technical stakeholders.

Execution Tier

The execution tier is the interface between IAM components and the platforms and systems that power the enterprise; it makes what the orchestration tier wants to happen, actually happen. It manages user accounts and entitlements, issues OAuth tokens, creates sessions, enforces an authorization decision, and much more. In this regard, the execution tier is heavily IAM domain- specific; an enterprise will have user provisioning execution components, components for single sign-on/off and federation, etc. Because of that, the execution tier more often than not relies upon IAM standards such as SCIM, OpenID Connect, SAML, and OAuth to get its job done. The execution tier is not only responsible for carrying out the work the orchestration tier requires, but it also reports back the bookkeeping information the orchestration tier needs, e.g., the entitlement was successfully added to the user account, the session was destroyed, the token was rotated, etc.

By putting all three tiers (data, orchestration, events) together set against the policy backplane with events flowing throughout one creates the complete notional architecture for modern IAM.

Complete notional architecture for modern IAM

I know this section was lengthy and I deeply appreciate you getting this far. Next week I will wrap up with how one can begin to build such an architecture. Until next time!