The roots of modern-day identity governance and administration (IGA) go back to user administration and provisioning (UAP), which emerged once organizations finally began to surrender the fantasy that directory services were going to arrest the proliferation of account repositories. Password synchronization and various single sign-on technologies were able to reduce some of the users’ pain caused by multiple account repositories, but provisioning was needed to alleviate the administrative burden.
When Sarbanes-Oxley Section 404 hit in the US, SEC-registered corporations were obliged to attest to their internal controls over financial reporting. This included periodic testing of user access for in-scope systems and applications. The vast majority of this access was managed in discrete account repositories scattered across the enterprise. User provisioning tools seemed like the answer at first since they were supposed to have tentacles reaching out to these account repositories, but the technology just wasn’t suitable. That’s the reason identity and access governance (IAG) products eventually entered the stage.
The most significant innovation offered by IAG products was the standardization of the entitlement as a unit of management. With user provisioning tools, everything associated with accounts looked like attributes. Even adding or removing group memberships often involved manipulating a list of groups for a user (or a list of users for a group). When all you can see are accounts and attributes, it is difficult to answer the classic “Who has access to what?” question beyond the coarse-grained account level.
User provisioning allowed identities to be tied to accounts and coordinated coarse-grained account life cycles with global identity life cycles. Access governance pierced the veil of accounts to reveal the entitlements that represent the privileges that users actually possess.
One of the significant shortcomings of many provisioning deployments was that their access request processes were clumsy and IT-oriented. Also, policy was difficult to enforce because of the set-and-forget nature of attribute-oriented account updates. Provisioning implementations usually made do with a stimulus-response type of policy that relied on events being raised from things like HR feeds, triggering actions that would flow through workflows and connectors. The result was that policy-driven assignment of accounts and access was only reliable for “birthright” entitlements with provisioning tools.
The concept of an entitlement as a standard unit of management turned out to be powerful enough that it was extended to cover administration. Entitlements allowed credible role management and more robust policies to be applied to administration of user access for the first time. Entitlements also allowed for a consistent, business-friendly representation of privileges across access certifications, access requests and workflow approvals.
Governance-oriented vendors started to add more administration features to their products while provisioning-oriented vendors were extending their data models to accommodate standardized entitlements. Although IAG and UAP tools could be integrated, there was enough overlap that organizations were getting confused about where to draw the lines for integration — and they wondered why separate products were needed.
We have now reached the point in the market where our clients do not look for separate products for provisioning and access governance — they want a unified approach to the problem of managing user access across multiple discrete account repositories. Even when a client desires only provisioning, they will often evaluate IGA products and services since most of the vendors now provide consolidated offerings.
I view the move from provisioning to IGA as a shift in focus from automation and compliance to security management. Organizations are concerned with making sure users have the right access and that the contents of account repositories are properly controlled. Many IGA deployments continue to struggle with fulfilling this mission, often because they were designed to automate manual processes that were inadequate to begin with. This represents the next challenge for IAM programs and IGA vendors as they move forward.
Read Complimentary Relevant Research
Five Golden Rules for Creating Effective Security Policy
Policy writing is a risk communication exercise that is frequently performed by people who lack the skills needed to create good security...
View Relevant Webinars
Fundamental Principles of Software Asset Management
Whether you've got too much software or not enough, uncontrolled software costs are a drain on your IT department, consuming resources...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.