You deployed an identity provider (IdP) solution for single-sign-on (SSO) for your cloud applications, and the project went well. You onboarded seventy-five SaaS apps to your IdP, got identity federation working with your AWS, Azure or GCP infrastructure, and all was good.
Then you realized you needed to go down the identity governance and administration (IGA) path starting with user access reviews for regulatory compliance and least-privilege-security.
“That’s easy,” your IdP vendor promised.
You checked in with your favorite industry analyst who said, “Light IGA is worth checking out.”
You considered engaging with the traditional IGA vendors but the bleached bones of failed legacy IGA deployments scared you away from complex, hard-to-deploy IGA suites.
Tempted by visions of “Light IGA” and vendor consolidation, you signed up for IGA with your IdP vendor, without doing an in-depth proof-of-value. Three months later, you realized you had a mess on your hands.
What happened? The featherweight IGA your IdP vendor delivered wasn’t up to the task! Let’s look under the IdP hood to see why.
The evolution of IdPs and what they excel at
Before IdPs showed up twenty years ago, user profiles were consolidated in directories like Microsoft Active Directory (AD), Novell eDirectory or open-source LDAP directories. User authentication was typically delegated to these directories, and web SSO layered over authentication was based on vendor-proprietary cookies. The rise of the cloud and identity federation led to the emergence of SAML and OIDC, and the concept of IdPs and service providers. In short, IdPs were conceived as the modern directories and shared authentication services for a cloud-first era.
Okta, Microsoft Azure AD, OneLogin and other IdPs quickly gained traction as SaaS and cloud infrastructure adoption accelerated. Today, these solutions have evolved to become excellent at supporting use cases around directory, authentication, SSO and session management. They tackle the complexity of integration with on-prem AD and HR applications, profile attribute synchronization, and SSO integration with cloud applications, with aplomb. Over time, IdPs have grown to offer limited identity lifecycle management to the extent that they can provision and deprovision user accounts and groups to some cloud applications. More recently, they’ve added so-called IGA support.
IdP solutions have a flawed permission model
It is important to understand that the underlying repository for IdPs is a database of user profiles, user group memberships and authenticated sessions. IdPs attempt to track the reality of enterprise identity and access primarily with these three object types. When it comes to IGA, therein lies the problem. IdPs gather user profile attributes and user groups from other directories and HR applications. They also support their own groups. For example, IdPs use a single group per application to manage who should have an account in that application and the ability to sign-on to that application. Similarly, they manage groups that map to and optionally sync with application-specific groups.
What makes IGA challenging for IdPs is that governing access is about governing permissions (also known as entitlements). IGA is about making sure that the right enterprise-wide permissions, not just the application-specific accounts and groups, but also the roles and granular permissions are all configured correctly and are always job-appropriate. These permissions need to be monitored, reviewed, provisioned and de-provisioned as necessary based on a variety of lifecycle events and other compliance and security policy considerations.
However, an IdP’s notion of governing access is based on the premise that every permission, whether it’s coarse-grained or fine-grained, maps to a group membership. An IdP can only manage a user’s ability to sign-in to an application or have a specific permission in an application, if a corresponding group exists in the IdP repository. This is the only permissions “pattern” IdPs understand. For the most part, this is a “push” model, wherein IdP groups are manually linked to application groups and group memberships are pushed to the application groups. Application-specific permissions that are not application groups are simply ignored. It is estimated that less than 20% of permissions across an enterprise are group memberships; the number likely varies by the size of the enterprise and the nature of applications in use.
Permissions are foundational to “real” IGA
Real IGA requires direct integration with all the systems in use in an organization, whether the system permissions are groups or not and whether the system supports security APIs or not. It requires knowledge of the permissions model of all these systems, the permissions hierarchy if any, including which permissions are privileged and which are assignable. It requires that all permissions, including accounts, groups, roles, application-level permissions and granular resource-level permissions, be correlated to identities in one more IdPs or other identity sources, so that a complete picture of “who has access to what” is available. This view of permissions is foundational to IGA. IdP user profiles and group memberships are essential components that make up the big picture of access but these components don’t reflect the reality of enterprise access by themselves.
The IdP model based on user profiles and groups fits in with the original IdP charter of delivering shared directory, authentication and SSO services. IdP’s rely on the SCIM protocol for lifecycle management, and since SCIM was modeled mostly on accounts and groups, the IdP approach is consistent with SCIM. However, this approach doesn’t match the permissions model for most applications. Every permission is not a group and managing permissions across an organization can’t be accomplished exclusively through IdP groups and group synching to applications and infrastructure. IdPs can indeed deliver identity lifecycle management to some degree through SCIM-based provisioning. But only a fraction of enterprise applications support SCIM, and when they do, the SCIM support is almost always limited to user and group objects and their attributes, and falls short of read and write capabilities on other permissions.
If the bar for “Light IGA” is simply support for permission reviews and permissions lifecycle management, IdPs fail even that test since they can’t review or provision any permissions beyond a user’s ability to sign-on to an application, a user’s accounts and group memberships! Enterprise use cases around audit, compliance, and least-privilege security demand a complete and accurate view of permissions, which featherweight IdP IGA can’t provide.
The counter argument for featherweight IGA
“Don’t worry, we have APIs for everything. Between our no-code integrations and professional services help, you can build the workflows you need,” says your friendly IdP account executive.
IdP vendors try to position “workflows” as the solution to the gap in their IGA strategy. They want you to believe that it’s trivial to use the APIs provided by applications to create custom workflows that manage permissions or turn permissions into group memberships. But building workflows for dozens or hundreds of applications is a recipe for long and painful professional services engagements. Moreover, only a fraction of enterprise applications support APIs that can read and write permissions; custom homegrown applications, web portals and most on-prem systems almost never have such APIs. And if the industry has learned anything from the challenges of legacy IGA, it is that professional services centric IGA is egregiously expensive, and a path to avoid.
Another frequently used argument is “vendor consolidation”. Wouldn’t it be nice to have a single vendor solve all your identity and access business problems? It might, and perhaps, over time that will come to pass, but consolidate too early at your own peril!
Let’s get real
In summary, forget featherweight IGA! Let’s continue to use IdPs for what they were originally designed for. Comprehensive monitoring, permissions lifecycle management and remediation of enterprise-wide permissions to support security, compliance and IT provisioning is hard, and requires a purpose-built solution. IdP vendors haven’t adapted their architecture to address these use cases. To be fair, some of them have announced support for “entitlement management” over the last few months but re-architecting to forge a fundamentally different permission model across hundreds of application connectors is implausible, and at odds with the design center of an identity provider. And since accounts and group memberships which they’ve always supported are also entitlements, one wonders how new silos of entitlement management will come together with old silos!
To see how purpose-built, comprehensive, easy-to-deploy, “real” IGA with 600+ out-of-the-box integrations can deliver business value quickly, reach out to Zilla Security.
