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.

Continue reading on Weave Identity's blog...