Over the last few months I have been working on ideas about modern IAM architecture, what it contains, and how to think about it. This is the first of four posts that expand on my previous thoughts. This post will examine the principles that should inform a modern IAM architecture. The second post will offer up a way to think about the systems a modern IAM architecture enables and protects along with the controls it provides. The third post will describe a notional architecture that embodies the principles discussed next and allows for the deployment of IAM controls. Lastly, I will talk about how to get started building a modern IAM architecture.
Before diving in, I have to express my gratitude. I am indebted to my friends and colleagues who have helped make me improve upon the raw material with which I started. And with that…
Enterprise Patterns for Modern IAM
In the past 20 years, enterprises have shifted from static, on-premises environments to highly distributed, cloud-first ecosystems. This shift has resulted in organizations being more dynamic, interconnected, and dependent on real-time data flows and external services than ever before. With the rise of remote work, the adoption of SaaS applications, and the increasing number of devices and non-human identities in use, enterprises now operate in a world where they need to be aware of and able to act upon contextual information and real-time signals. This enables the IAM infrastructure to act in accordance with the realities of today, and not some idealized picture of the world, and react to changes without relying on a human after the fact. This kind of IAM architecture is a far cry from the set-it-and-forget-it world of birthright entitlements, quarterly access certification, and infinite session lengths enabled by single sign-on.
At the same time this dynamic IAM infrastructure cannot be constructed out of reverse- engineered alien spacecrafts and exotic magically imbued metals. It has to be built of components that are at least vaguely familiar to today’s IAM practitioners, relying upon technical standards, and must not require a complete rip-and-replace of their existing IAM infrastructure.
Let’s then consider what the architectural patterns would be for an IAM infrastructure up to the challenges of the modern dynamic enterprise.
Establishing Basic Principles
Before diving into the traditional boxes and arrows of an architecture, let’s establish what our basic principles will be. These principles inform decisions that enterprise IAM and cybersecurity architects need to make.
An architecture to enable dynamic IAM services must be:
- Fully contextually aware;
- Humanless and real-time reactive;
- Augmenting functionality, not replacing it;
- Standards assumptive;
- Adaptable and open to change.
Fully contextually aware
To claim that our enterprises, and thus our identity infrastructures, do not operate in a perfect idealized world is an understatement. Both have to adjust to changes in business, cybersecurity, and other IT conditions. To do that requires context. While not every decision an identity system needs to make requires context, high impact decisions do. For example, whilst granting a new employee access to the productivity suite doesn’t require much if any context (although allowing persistent access to that productivity suite does require context), giving someone access to a production environment outside of a maintenance window certainly does. So for more critical decisions, identity systems need to consider context—whether it is business-oriented, like a major product launch, IT-oriented, like a system maintenance window, or cybersecurity-oriented, such as detecting if a user’s endpoint is compromised.
Humanless and real-time reactive
A dynamic enterprise reacts to changes and events in its environment; so too should its identity infrastructure. To do this, the identity infrastructure requires both the ability to sense those changes and to take prescribed steps to react to those changes. For example, an end user’s laptop becomes infected with a well known dropper malware; the identity infrastructure detects this and reacts by cascading session termination requests as well as invalidating any access token issued to the device. Notice that identity infrastructure didn’t need to pull a human into the process to determine the best course of action. Similarly, one can easily picture the identity infrastructure detecting a new hire in the HR system and trigger a response loop of creating associated user accounts with birthright entitlements - again, no human in the response loop of creating those user accounts, although they may be involved in the follow-on reviews and audits.
The modern enterprise has to, for a variety of reasons, minimize pulling humans into response loops, if only to cut down on the distractions of repetitive tasks. There is a second way in which human involvement in response loops can be minimized - taking the burden of creating the prescribed reaction steps the identity infrastructure follows away from the human and handing it instead to artificial intelligence (AI). Having generative AI systems propose recommended reaction policies, reviewed and enhanced by humans, further removes humans from the overall work of creating real-time reactive systems.
Augmenting functionality, not replacing it
Pairing humans and generative AI is an example of the third basic principle. Augmenting an overburdened IAM practitioner with AI helps expedite policy creation and allows the practitioner to focus more intently on other matters - which could include further refinement of those as business needs warrant. But augmenting, not replacing, means more than just helping the humans; it reorients the way identity leadership thinks about the components in its infrastructure.
The replacement cycle for large identity infrastructure components is between 8 to 10 years. IAM teams cannot, nor want to, replace major components every other year. A more pragmatic approach is to augment existing identity components with “assistants.” These smaller components can introduce new capabilities and extend the reach of the overall identity infrastructure. While these assistants might be significant solutions on their own, they are initially licensed and used in a more limited capacity. Over time, as legacy components are replaced, these solutions can be evaluated for more widespread use..
Standards assumptive
Gone are the days where IAM practitioners hope for technical standards support in the products they rely upon as well as within their enterprise infrastructure and services; we are well into an age of assuming the use of standards. Technical standards are tools - in and of themselves they don’t do anything; their implementation provides the value. A modern architecture assumes standards, and often requires robust implementation of those standards. Basic, superficial implementations of OAuth and OpenID Connect are no longer sufficient, if only because those standards can do so much more than “just” providing SSO and delegating authorization to use resources. Assuming the presence and full use of standards in an architecture simultaneously simplifies that architecture and also highlights future challenges where bridging between standards and proprietary components is needed.
Adaptable and open to change
While accommodating change may feel like a tried and true trope, it is never more relevant than in identity and security. The types of attacks targeting enterprises are constantly changing and the rate of that change is accelerating. To make things more interesting, the defenses and controls needed to fend off these threats are also in constant flux, along with the services that provide them. Toss in shifting regulatory requirements, and what you’ve got is a pot of change stew, bubbling with uncertainty. Additionally, not only are adversaries’ techniques and tactics changing, so are the needs of the business - yet along ingredient of the change stew.
But there is another kind of change that is not as frequently discussed: the rate at which enterprise infrastructure can change. Obviously, an enterprise cannot (nor would want to) swap out major components of its IAM infrastructure on a yearly basis. Neither the implementers nor the operating staff would survive very long, and employee satisfaction would be guaranteed to be low. Replacement cycles for major IAM move at their own rhythm, dictated by organizational restructuring, leadership turnover, budgetary cycles, and political capital.
Next week I will release the second part of this monstrosity which will talk about a means of optimizing technical controls to enterprise resources… until next time!