Entitlement administration and governance

In the identity and access management (IAM) market, we’ve got the terminology all wrong. With bad labels comes misdirected thinking, which ultimately contributes to project failure and disappointed stakeholders. This sounds like a big claim, so allow me to explain. Depending on what milestones you care to consider, the IAM market has been evolving for about twenty years. Perhaps it’s time for a reboot.

It began with moving identities and, in some cases, passwords out of the silos of individual applications and into a single directory. Organizations then discovered that one directory was an unrealistic goal and that moving the data out of the silos was not enough; the change management process must be consolidated as well. This is when the term “identity management” was invented, in reference to shared processes for managing identities. Meta directories (to synchronize data) and virtual directories (to present an aggregate view) appeared around this time, as did user provisioning in order to help manage those applications that still couldn’t leverage a directory.

Access management shortly ensued, but its focus was on runtime authentication and authorization. While in principle, web access management products support central control over authorization rules, using URL filters and web services APIs, most organizations deployed access management systems mostly for single sign-on across their Intranet or Extranet. Let’s pause there.

We now have two terms that are really unrelated. Identity management, which includes user provisioning, directories, meta directories and virtual directories, refers to software used to manage the setup and teardown of users. Access management refers to software for signing users into applications and control what they can access. Administration versus runtime. These two things do not belong in a single product or even the same category. So, of course, vendors and analysts began to refer to the market as “Identity and Access Management”, which conflates administration and runtime enforcement.

Despite both identity management and access management systems being widely adopted, medium to large organizations continued to encounter problems. They were never really interested in managing identities for their own sake – that’s just a means to an end. What most organizations really care about is what users can access. You have to know who they are before you can grant access rights, but identifying users is not really enough.

Organizations want user setup to be fast and efficient. Teardown should be prompt and reliable. Security rights, now more properly called security entitlements, should be appropriate to a user’s business needs. Audit records should be rich and available directly to auditors. Internal controls should be strictly enforced, in part to comply with regulatory requirements.

In response to this, a handful of firms have launched products in a newly imagined market, “Access Governance”, providing controls over security rights assigned to users. The idea is to layer this on top of existing deployments of user provisioning systems, which have proven to have limited utility, perhaps because of a focus on identities rather than security entitlements, or maybe simply because they have terrible user interfaces which are difficult to configure and use.

So now we have even more confusion because the governance here is of security entitlements, not of runtime access enforcement. Perhaps this new product category would be more accurately called “Entitlement Governance.”

If we actually stop to listen to what organizations want, it is efficient and secure administration AND governance. They want to manage security entitlements first and foremost, and identities only insofar as this is pre-requisite to grant entitlements to users.

Which brings me to the starting point: “Identity and Access Management” is misleading, as is “Access Governance.” Moreover, the security controls implicit in “governance” must be enforced at every phase of every administration process. The notion of two product categories layered on top of each other, one for governance and another for administration, is neither architecturally sound nor commercially attractive.

I propose a simpler and more accurate label for our market: “Entitlement Administration and Governance,” or EAG for short.

And what does EAG mean?

• Focus on granting and revoking entitlements.
• Automate the management of identities, since users must be assigned digital identities before they can be granted entitlements.
• Include a rich set of connectors to pull information about login IDs and security entitlements from existing systems and directories, and to write updates back to those systems and applications as a consequence of approved change requests.

It includes a rich set of features such as:

• Automation to setup and tear down identities and entitlements based on an HR data feed
• A request portal so that users can request changes on their own behalf and for others, including recipients, who do not appear in an HR data feed.
• An authorization workflow, to get business users to approve or reject proposed changes.
• Access certification, to invite stake-holders to periodically review and correct security entitlements.
• Policy engines, to prevent violations to segregation of duties and other rules.
• Reports and dashboards, so business users can monitor both enterprise-wide security configuration and the change management process.

I think this is what the market really wants: an integrated solution to manage both identities and entitlements throughout the user lifecycle, with integrated governance (i.e., policy and workflow controls throughout). So, let’s stop talking about IAM and focus instead on EAG.