I’ve worked on a lot of Identity and Access Management (IAM) projects over the years. The goal is always to centralize the IAM infrastructure. This is due to a lot reasons around Security, Experience, and enforcement of organizational standards. I’ve had a lot of success doing this and saw organizations and users benefit from the enhanced capabilities, improved security and experience. You usually end up with an environment looking like this.
But, as times have changed over the last few years and things are getting more complicated with cloud, service delivery, etc. I’ve had growing challenges maintaining a single IAM stack. This is due to a number of reasons, but primarily I run in to:
- Differences in definition / requirements of what constitutes and identity. For example, some applications may be simple (e.g. first name, last name, mail, etc.) but others require much more complicated attribute sets. Due to the central IAM not maintaining this, developers may look for their own local IAM capability to support this.
- Differences in security / compliance requirements driving separation of capabilities. Some groups (mainly PCI, HIPAA, GDPR, etc.) may have stricter data and/or compliance requirements so their infrastructure is separated out (sometimes multiple times) into separate infrastructure.
- Cloud delivery capabilities and integrations. A lot of the cloud platforms come pre-built with their own local IAM infrastructure (e.g. AWS / Cognito, Azure / AD / ADB2C) which gives ready access to application developers to build their integrations quickly without having to write custom integrations to a central capability. This is one of the bigger challenges I face with the current development and delivery modeling.
All this is leading to fractures into the IAM capability of organizations leading to breakdowns in enforcement and security across business units. Ultimately, this is also leading to degraded customer experience and hacks to integrate different IAM backends. We’re starting to see something akin to the below.
You have different business units with different clouds and backends maintaining their own IAM infrastructure to support their needs. And, as IAM professionals, we’re struggling keeping up with demand for this and being too rigid when asked to support the efforts.
So, how do we fix this? Well, we need to look at the standards and re-evaluate how we’re publishing IAM services and integrations.
Recently, I had a few projects that highlighted this problem, and I took a step back and redesigned how we provide IAM services to the different application and cloud teams. What we developed is what I am dubbing the ‘Pull-Through Identity Model’ or might want to call it a proxy identity model. See, Identity is one of those things that has, and can have, multiple abstraction layers on it to provide chained capabilities. What a user is at authentication doesn’t necessarily mean what they are and are presented to a user as.
The idea and goal here is to have a ‘Golden Record’ where the user is ultimately authenticated, then this record is published / consumed by downstream IAM capabilities that integrate directly with the application and business teams. What you end up with is something like this.
In this design, the application teams can still use their own local IAM capability, but they delegate the sensitive operations (e.g. passwords, primary authentication, MFA) to the central capability and consume the base identity record into their own infrastructure. Once this is done, they can enhance, or profile, additional data into their local IAM capability. What this provides is:
- Local branding and experience: the business unit can maintain their own local branding, experience, etc. in their capability but delegate the sensitive operations to the central IAM infrastructure.
- Central records: Across the organization, you have a master list of users that can be shared / integrated across applications in the environment without having to maintain local accounts or ‘hack’ integrations across platforms (which I see too many times).
- Speed to delivery: By integrating behind the scenes, application developers can leverage their native cloud capabilities for IAM integrations but delegate that infrastructure and policy to the central capability. This reduces risk at the local level and maintains a strong central capability for this enforcement.
I have done a few of these recently, but the biggest I did was related to a very large, multi-tenant, Azure configuration. We leveraged the delegation capabilities of B2C to chain multiple instances together to maintain one central, minimal, authentication instance and each local business unit / agency could have their own local B2C to configure and maintain their own local repositories. An over simplified version of this model is below.
This is not limited to Azure and B2C (like the above), in a different project we are using Keycloak / Ping / Oracle to centralize on the Ping platform and maintain local IAM infrastructure, but central user authentication.
So, the next time you are looking at their distributed, diverse, IAM requirements, start looking at how you can use this type of modeling to delegate between components and still maintain your central capability.
