Identity 3.0

Over the next couple of posts, I will explore the future of identity and access management. Knowing what I know today and based on the technology we have today, I will build the perfect identity platform. At least, in my opinion anyway. Are you ready? Let’s start building!

A brief history on identity and access management

Before we can build the future, I think it’s important to understand where we came from. What we know about identity today grew out of the need for administrators to better handle how accounts were being created and used within an environment. We had scripts galore that could create accounts but had no way of managing the lifecycle of those accounts, nor an inventory of what accounts were there. That’s just the identity management portion; access controls, certifications, and centralized authentication were all an afterthought. Visibility into how accounts were being used or what access was assigned was non-existent.
It’s not that our application admins didn’t want to do their jobs well; it just wasn’t possible. As we move into the future of identity management and application security, I think it is vital for us to understand where we came from before venturing off blindly into the unknown.

Identity at the center of security

Fast forward to today, and identity is everywhere. We’ve built systems to inventory our accounts, we’ve centralized and controlled the lifecycle of those accounts, and we can certify who has access to what at any given time. IAM systems have become an abundance of information from users and their relationships to entitlements, to policies of how access should be assigned and to whom. The security of our systems relies heavily on integrity, confidentiality, and availability. From authentication to authorization, we have built a system to protect assets based on who has access, when they should have it, and for what period.
But as we shift to the world of API-first applications, consumer identities, the internet of things, and machine identities, the scope and complexities of identity and access management are growing. To make identity the center of security, we need to utilize the information in our IAM systems to build applications securely and quickly.

Identity Management and Authentication

The first thing we need is our authoritative source for identities. This is where we define the schema of our digital identity. The schema defines the fields and attributes for each user, device, or organization. It’s cloud-friendly and accessible from any environment and can segregate identities based on purpose. So we can have employee identities, partner identities, consumer identities, non-human identities, etc. Each identity population can be assigned its workspace to provide flexibility in managing the identities and limiting exposure of identity data.
User privacy and consent will be baked into the identity lifecycle. All attributes stored within the identity management system will have the option of being protected by user consent, and access to that attribute will be derived from that consent. User consent grants will be stored and queryable for developers and administrators.
The identity management system will also provide authentication services and allow easy signup, sign-in, passwordless workflows, multi-factor authentication, and authentication orchestration. These features would be provided in a developer-friendly manner, allowing application developers to easily integrate these features into their applications.

Access Management

With the management of identities and authentication taken care of, we now need to focus on managing the access for those identities. The access management features of our system will include the standard capabilities: authorization and adaptive access, single sign-on, session management, identity synchronization, and API access control. This will be the central point where access policies are created and managed. These policies will govern how users are assigned access and provide the runtime enforcement for that access. This will give administrators a centralized place for managing all user’s access relationships: provisioning, certification, authorization, the whole nine yards. What is commonly known as identity governance is now just access management. The same policies and business processes that we create for assigning and monitoring access in IGA systems are now combined with enforcing those policies at runtime. Instead of modeling access around simply what a user has, access will be modeled based on user relationships to entitlements, resources, and access policies. This enables administrators to see how a user is granted access, what access the user is given, and finally, how that user is using that access. We don’t solve the trifecta of questions quickly in one system today, but quite frankly, we should. This brings me to the next feature, Access Modeling.

Access Modeling

To date, IAM systems have centered around assigning a list of things to a set of users. User A has this entitlement or this role. User B has this list of entitlements or this list of roles. This gives us a very coarse-grained account of what this user has access to. We know what User A has. But what we have been missing is what does User A’s access do? In other words, what’s the context behind these assigned entitlements? My perfect identity platform will have a feature called access modeling. You can define and edit relationships between users, policies, entitlements, and resources. Allowing you to quickly answer questions like: “What resources will Shanda have access to if I assign her this policy?” “If I update the access policy, what users will gain access?” VIsualizing the relationships between users and resources allows you to see unintended consequences that can happen from overlapping policies, stale role composition, etc. It’s also the perfect place to bring in the concept of risk. Knowing the relationship between an entitlement and resource means we can more accurately assign a level of risk to that entitlement. Which then gives us a better understanding of risk when that entitlement is assigned to a user. We can then adjust our access model to adhere to a particular risk level, automatically adding mitigations such as an extra authentication step whenever the user tries to access a resource or manager approval before accessing a system.

Alright, so quick recap. My perfect identity system combines identity management, access management, and identity governance into one system. I’ve also introduced the concept of access modeling, allowing administrators to manage access based on relationships and risk. I think we are off to a good start, but what about you? What features do you think we need to build the perfect identity system? Let me know in the comments, and stay tuned for the next post in this series, where I’ll dig into deployment models, automation, and apis.