Commoditization of User Access
Entitlements provide a much better user experience for IGA than forms ever could
In the bad old days of user administration and provisioning (UAP), forms were the foundation for all access requests. This was a natural progression from manual, form-driven request processes that UAP was intended to replace. UAP provided a workflow engine and connectors to automate the work of security administrators. The expectation was that most work would go into workflows and connectivity with managed systems, but it turned out that maintenance of forms became a significant burden.
Ambiguity in forms that were intended to be processed by human administrators could be tolerated because humans would read between the lines and even follow up with requesters to fill gaps. Such ambiguity could not be tolerated with forms driving automation. These forms required tight coupling with the systems for which accounts were being managed, so changes in a given system had to be reflected in the forms. For example, making a new group available in a system might require an update to its corresponding forms to allow users to select the new group for requests.
Inevitably, more complex logic was built into and around forms to minimize the need for manual updates as changes occurred within systems. Imagine a script that listed groups available in a system and updated the list of groups that could be selected through a form. As these solutions became increasingly elaborate, they were tied to specific types of systems. Those involved in the market at the time suspected this was not a sustainable arrangement.
Forms were pretty awful from a user experience (UX) perspective as well. UAP tools were built around account provisioning, so forms were specific to account requests. A managed system typically required at least three forms:
Create a new account
Modify an existing account
Remove an existing account
Business users usually did not think of access in terms of accounts. If a user needed access to a Windows file share, it was reasonable for the requester to assume that this would be a request for new access. However, if the user already had an Active Directory account, the proper form to use would be one for modifying access. UAP rarely supported multiple accounts for a user on the same system, so submitting a Create Account request for a user that already possessed an account on that system likely would produce an error.
What made the UX of forms even worse was the absence of context. The data about existing user access maintained by UAP systems was not easily consumed within forms, so it was rare for forms to adapt to access assigned to subjects of a request. It took a lot of work to build a form that filtered the list of available groups on a system to exclude those that were already assigned to the subject’s account. More intelligence in a form also meant more opportunities for the form to produce errors at run-time.
Permissions and Entitlements
The introduction of permissions and eventually entitlements with identity and access governance (IAG) was intended originally to make user access more legible and to facilitate access certification and/or review campaigns. Permissions provided a generalized data structure for representing the groups, profiles, roles and other authorization constructs that systems assigned to user accounts. The generalized nature of the permission data structure abstracted away the details of various systems, providing a standardized representation of user access across multiple authorization models.
Entitlements emerged once it was recognized that permissions on their own were still too IT-centric for business users to understand. Initially, entitlements started out merely as permissions that were enriched with metadata to make them easier for business users to understand — friendly names, descriptions, tags or labels and so on. Eventually, due to the volume of permissions, entitlements became a vehicle for compressing the surface area of user access by allowing cohesive sets of permissions to be bundled into them (often characterized as roles). Applying analytics to existing assignments of permissions to accounts allowed mining of entitlements, simplifying the process of bundling permissions into entitlements
A driving force for the consolidation of UAP and IAG into a new market, identity governance and administration (IGA), was the recognition that entitlements could be used for access requests in addition to certifications and reviews. I characterize this evolution as the commoditization of user access. Entitlements bundling permissions from a wide variety of system types are now published in catalogs that can be searched and browsed like any other product catalogs offered through electronic commerce systems. Some IGA solutions leverage this characteristic of entitlements to provide a flexible, non-linear shopping cart experience for user access requests.
By using the word commoditization in this context, I am not suggesting that entitlements are fungible. Each entitlement has unique characteristics in terms of the access they can provide as well as their risk profiles. Commoditization in this sense suggests that the representation of individual entitlements has been standardized (homogenized) to such an extent that they can be stored, searched and filtered effortlessly. This is similar to how containers revolutionized the shipment of goods across the globe.
Requests that once required complex, independently maintained forms can now be facilitated through a standard catalog and even a shopping cart experience if desired. This opens the possibility of decentralizing the management of entitlements. Form-based access requests required a centralized group of specialists to build and maintain the forms, often in close collaboration with team members responsible for onboarding systems. With support of proper tooling, business application owners can take on the responsibility of creating and maintaining the entitlements for their applications secure in the knowledge their entitlements will be published in the IGA solution’s catalog.
Can We Take Commoditization Even Further?
Unfortunately, commoditization of user access has not eliminated forms entirely from access requests. There are two specific scenarios where forms are still used routinely with IGA solutions:
Requests that are not directly related to user account access, such as requests related to management of permissions, resources and identities — these are requests that occasionally cross into the territory of ITSM (IT service management):
Requests for the creation of a new role, group, profile or authorization construct in a managed IT system
Resource requests for things such as databases, storage, shared email inboxes, collaboration sites and so on
Requests related to contingent workers or business partners that are not covered by authoritative sources such as human resources
Manipulation of account attributes that cannot be handled through deterministic attribute mapping rules:
Selecting the default database for a database user account
Setting quotas and other characteristics of certain accounts, for example email or storage accounts
Synthetic Permissions and Resources
Forms are likely to be needed for the first scenario above, however I have developed a concept that applies commoditization to the second scenario. Synthetic permissions and resources allow static permissions or resources to be defined for an IT system in such a way that allows for manipulation of account attributes when assigned to an account.
First, let’s establish what distinguishes permission entities from resource entities (according to the Declarative IGA information model):
Permissions are simple representations of authorization constructs such as groups, roles or profiles, possessing only two possible states: assigned or not assigned.
Resources are the things protected by an authorization system and are typically associated with multiple potential protection states:
CRUD (create, read, update and delete) is a common paradigm for describing these potential protection states, but systems often allow more specialized states
It’s important to note that assignment of an account to a resource requires the specification of one or more protection states
Some authorization systems allow permissions (groups, roles, profiles and so on) to be assigned to resources as well to reduce the need for assigning accounts individually to resources
Let’s take the scenario of a database user account that needs to specify a default database. Although it is possible to provide a form at some point in the request flow that allows the requester to select the default database, a more elegant solution could be to specify a synthetic resource for the IT system that is assigned through an entitlement, requiring the selection of the default database.
This choice of a synthetic resource over a form may appear to be a distinction without a difference, but this further commoditization increases transparency and legibility of user access. In the absence of synthetic permissions and resources, user access reflected through account attributes remains obscured in most cases. With synthetic permissions or resources, this user access is surfaced at the same level as all other access-related permission and resource assignments. There are important implications for this in terms of audit surveys (access certifications and reviews).
Parameterized Entitlements
Most implementations of entitlements in IGA solutions conform to the simple characteristics of permissions, possessing only two possible states: assigned or not assigned. Given that the intention behind introducing entitlements as distinct entities on the business side of the IGA information model was to reduce administrative surface area through bundling of permissions, it’s ironic that the presence of resources on the IT side of the information can lead to entitlement explosion.
As I mentioned previously, resources typically possess multiple potential protection states. Let’s imagine a collaboration site that associates the assignment of accounts (or permissions) with the following site roles:
Administrator
Editor
Contributor
Reader
To represent each of these distinct roles as entitlements, it would be necessary to create four entitlements for this one collaboration site resource:
Site Administrator
Site Editor
Site Contributor
Site Reader
If the collaboration site resource does not allow multiple roles to be selected for individual user accounts, it might also be necessary to introduce some type of constraint to prevent more than one of these entitlements from being assigned to individual identities.
Parameterized entitlements offer an elegant solution to this problem. One or more parameters could be associated with an entitlement, allowing for different mappings to bundled permissions and/or resources depending on the parameters selected for an entitlement assignment. In the simplest case for the above scenario, a single parameter with values corresponding to available site roles could be associated with an entitlement that models the collaboration site:
Administrator
Editor
Contributor
Reader
This would allow the collaboration site to be represented in the entitlement catalog as a single entitlement instead of four. I analogize this approach to how product characteristics are handled in electronic commerce product catalogs.
Imagine you are selling a t-shirt with a unique design that comes in four colors (white, black, blue and red) and three sizes (small, medium and large). From a product inventory perspective, you have 12 SKUs (stock-keeping units) representing each combination of color and size for the t-shirt. Once your SKUs are entered into the inventory system, it is time to make the shirt available in the catalog. You have two choices:
Create 12 products in the catalog representing each combination of color and size for the t-shirt (perhaps Unique Design T-Shirt Black Small, Unique Design T-Shirt Black Medium and so on)
Create a single product in the catalog called Unique Design T-Shirt that allows shoppers to select the color and size when placing it in their carts
I would argue that the second option provides a better UX, as evidenced by the fact that this pattern is applied almost universally across electronic commerce sites. This certainly requires more complexity in the product catalog as the various combinations of product options must be mapped to distinct SKUs, but the benefits outweigh the costs. The same argument can be made for parameterized entitlements for IGA.
Commoditization of user access lies at the heart of effective, business-friendly IGA, allowing organizations to shift away from the mind-numbingly complex form-based access requests of the old user provisioning tools. If we keep our focus on the benefits provided by commoditization, we could extend the power of IGA with some simple enhancements such as synthetic permissions and resources as well as parameterized entitlements.