Overview
Okta continues to enhance the Okta Identity Governance product in the areas of Access Requests, Access Certification, and Governance reporting. However, a significant update, Entitlement Management, is entering Early Access soon. This article provides a technical overview of the new Entitlement Management capability.
What is Entitlement Management?
Okta is adding Entitlement Management to Okta Identity Governance (OIG). But what are “entitlements,” and what is “entitlement management”?
Entitlements are anything in a system, application, database, platform, etc., that grant users access (often called fine-grained entitlements). Entitlements are often a connection between users/accounts and the permissions needed to perform a function. Think of Salesforce.com with its Roles or Amazon Web Services (AWS) with Permission Sets. The entitlement models vary widely and can become very complex (for some light reading, have a look at some articles I wrote looking at entitlements in RedHat Linux, IBM zOS RACF, and trying to apply a common governance data model to various systems).
Entitlements may be attributes associated with an account or user, may be based on membership of some grouping (like a Role, such as in an RBAC model), or even dynamically assigned (such as in an ABAC model).
Entitlement management can cover the entire spectrum from managing user connections to entitlements, through managing entitlement relationships to managing entitlement mapping to permissions on resources. Most identity management (IdM) products can manage the user to entitlement mapping. However, when it comes to managing entitlement relationships or entitlement to permission mapping, not many IdM products will implement this. It may be hard to drag a security administrator away from the tools/UI they are comfortable using, and it often involves building system-specific logic into the IdM product and maintaining it. It would be a significant piece of work to implement logic to replicate the AWS or Salesforce.com entitlement management into an IdM tool.
Doesn’t Okta Already Do Entitlement Management?
Okta currently implements some entitlement management into the Lifecycle Management product. Application user profiles contain entitlement attributes that integrations can sync.
These entitlement attributes can be applied at the group level, so assigning a user to a group means the user is granted both the application and any entitlements tied to that group.
Whilst this mechanism works, it can lead to a proliferation of Okta Groups. Also, these fine-grained entitlements aren’t exposed to OIG functions like Access Requests and Access Certification, nor can we report on fine-grained entitlements granted through groups.
This is where the new OIG Entitlement Management capability comes into play - promoting entitlements to first-class objects in Okta so they can be requested in Access Requests, reviewed in Access Certification, and reported in the Reports function of Okta.
A Technical Overview of OIG Entitlement Management
OIG Entitlement Management is a new capability that has been added to Okta Identity Governance. It makes entitlements first-class objects. It supports both automatic policy-based assignment and request-based assignment of entitlements.
In short, Entitlement Management can be thought of as three components for now: the Governance Engine and the entitlements data it manages, extensions to the Access Requests function to support requesting entitlements, and extensions to the Access Certification function to support reviewing entitlements. Reporting will come later.
The following diagram shows the major components and data objects:
The main component of OIG Cloud Entitlement Management is the new Governance Engine. When an Okta Application has the Governance Engine enabled, a new Resource is created in the Governance Engine to represent that application.
The central object is the Entitlement. Entitlements represent entitlements on connected systems (like a role, profile, or license). A resource can have multiple entitlements, and each entitlement can have a set of values. Entitlements can be single-valued or multi-valued.
Entitlements can be automatically assigned to users via an Entitlement Policy. This attribute-based automatic assignment approach is analogous to Group Rules for assigning users to Groups based on some attribute. There will be one policy for a resource, but it may have multiple rules that are applied based on priority to determine what entitlements can be granted to a user.
Entitlements can also be collected into Entitlement Bundles. Bundles represent logical groupings of entitlements, and one bundle may contain multiple entitlements and multiple values for each (for multi-valued entitlements). A bundle might represent a jobrole where all entitlements for a specific job in a single application are bundled together. Or maybe a set of accesses one might request, such as an employee visiting head office needs both building and carpark access, and a bundle could be created to put them in a single access request.
Grants represent the association of a user with an entitlement or an entitlement bundle. With Entitlement Management, the application user profile is no longer used to store entitlements as was done in Lifecycle Management (LCM).
With Entitlement Management, entitlement bundles are exposed to the Access Requests Platform and are resources that can be requested in a Request Type in the same way that groups and applications can. A list of bundles is synchronized to Access Requests into an Entitlement Bundle list that can be used in Request Types to request access. There is a new Okta action to assign a user to an entitlement bundle.
All entitlement grants can be reviewed in an Access Certification Campaign for the Application resource type. If a user has both entitlement and bundle grants, it can show both and may allow automatic revocation where that doesn’t conflict with policy.
Entitlement Management supports both a BYOE (Bring Your Own Entitlements) model and integration with SaaS applications. For application integration, a new set of connectors has been built to support key applications. They can consume the entitlements and existing user-entitlement mapping and also provision changes to user-entitlement mapping. These will replace the existing OIN connectors, and the list will grow over time.
Where To From Here?
This is the first of a series of articles that will look at the new Entitlement Management capability of OIG. If you are an existing OIG customer and want to see more, reach out to your Okta account team.
Related References
