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, was announced at Oktane23 and is currently in Early Access. 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 (sometimes 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/user, may be based on membership of some grouping (like a Role, such as in a RBAC model) or even dynamically assigned (such as in an ABAC model).
Entitlements Management can cover the entire spectrum from managing user assignments 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).
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 BYOE, entitlements and values can be managed via either the user interface or APIs (perhaps via Okta Workflows). For application integration existing Okta Integration Network (OIN) connectors have been modified to support the entitlements that the applications support. They can consume the entitlements and existing user-entitlement mapping, and also provision changes to user-entitlement mapping. As of today there are five connectors enabled for this – salesforce.com, Google Workspace, Oracle Netsuite, Box and Microsoft Office365. This list will grow over time.
Splitting the Entitlements Out from the Application Profiles
A key aspect of the new capability is that the entitlement attributes have been split out from the application (user) profiles.
This is shown in the figure below – the left is an existing salesforce.com application user profile, the right is the new split with the reduced application user profile and the separate entitlements for the user.
You can still use the existing tools to manage the remaining application profile attributes – groups assignments for shared attributes (like departmental common attributes) and attribute mapping from the Okta profile.
But there is no longer a need to use groups to assign entitlements to a user – the Entitlement Policies and Entitlements Bundles will do this. This is significant and should make a lot of Okta deployments simpler.
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.
