Migrating to Entitlement Management

Including Reversal back to non-entitlement provisioning.

What if the applications within the Okta Identity Network (OIN) now support Entitlements? Taking advantage of entitlements offers additional governance capabilities. Let us walk through an overview of Entitlement Management and the steps associated with migration.

Overview

Entitlement Management offers a simple and powerful way to ensure that users in an organization have the right permissions for each resource. The feature is integrated with Access Requests, including Resource Centric Access Requests and Access Certifications, to help manage and monitor users' access to resources. It is also possible to manage their level of access within these resources and how the access was granted from the Admin Console. Additionally, entitlements can take advantage of Separation of Duties (SoD) within the Okta Identity Governance (OIG) product.

Use Entitlement Management to help meet audit and compliance requirements. With Entitlement Management, it is possible to create, store, and manage application entitlements in Okta. Assign entitlements using policy or individually from the Admin Console. This reduces the accumulation of elevated user privileges. It also simplifies the Universal Directory setup because there is no need to use groups to govern users' application entitlements. It is also possible to prevent toxic combinations before they happen or report on users who have been granted this access. 

Group the entitlements into bundles for users to request through self-service Access Requests. The requests are automatically routed to one or more approvers for action, improving IT teams' efficiency. Use Access Certifications campaigns along with Entitlement Management to audit and review user entitlements.

Applies To

• All components of OIG (Access Requests and Access Certifications)
• Okta Provisioning
• Separation of Duties (SoD)

Assumptions

• An existing application with provisioning is configured in the Okta instance.
• All groups assigned to the application with entitlements have been documented.
• All groups assigned will be left intact in case reverting back to traditional provisioning is required.
• All users assigned individually with entitlements have been documented.
• There is Super Admin access to the Okta instance to configure entitlements.
• Migration to entitlements has taken into consideration any impacts on production users. Always test in preview when possible.
• Documentation on how users are assigned entitlements currently within the target application.
• Documentation on how Policy Rules and Entitlement Bundles should be created and applied during cut-over.
• Running imports on an application will pull in what users are assigned in the application.
• This article only applies to applications supported with an OOTB entitlement management connector using SCIM. A list of those applications is visible within the OIN or Apps with entitlement support.
• Some applications will also require an import to be performed as part of the enablement. Please refer to Enable Entitlement Management. 
• Salesforce is used as the example, and other example integration steps may vary based on their setup instructions.

Migration

Migration to Entitlement Management 

This understanding of Entitlement Management can now be used to review how to best take advantage of it within an organization.

Two paths to enable Entitlements for an application:

1. Newly created application instance (see Entitlement Management).
2. Migration of an existing application configured with traditional Okta Provisioning. 

Migration of an existing application to Entitlement Management.

Steps

To initiate the Migration of an existing application:

1. Log in to Okta as an Administrator with the Super Admin role.
2. Select Application > Application menu.
3. Search for and select an existing application previously configured with provisioning. 
4. Locate the Provisioning tab, click the Edit link, and deselect the Enable API integration option. This will temporarily disable provisioning for this application.

Warning:  Make sure to document how users are assigned entitlements prior to disabling provisioning in the previous steps. Once provisioning is disabled, entitlements that were assigned post-import should be visible.

5. Locate the General tab, find the Identity Governance section, and enable the Governance Engine. This step enables a new Governance tab on the application. It may be necessary to refresh the page to see the newly enabled tab. 

NOTE: Some applications will not allow the Governance engine to be enabled while provisioning is already enabled.  Please see the assumptions for a list of applications and steps.  

6. Proceed back to the Provisioning tab and now re-enable the API for Provisioning. Most applications will allow doing this by using the previously saved credentials within the application.

6. • When enabling provisioning, it is recommended not to enable Update User Attributes initially. Perform an import first before enabling it to ensure that how a user is configured in Okta does not overwrite their entitlements in the application.
      

7. Once enabled, it will be necessary to perform an Application Import to pull in any new entitlements are to overall updates granted directly in the application, not from Okta. 
   Select the Import tab, click the Import Now button. The following will be visible:

NOTE:  There may be a banner saying that it is necessary to import to continue.  This ensures that all users within Okta have the same entitlements assigned to them as in the downstream application.  Proceed to the next step after the import completes fully and the user's entitlement update is complete.  Recommended to look in the system log to ensure any entitlement updates look complete. This may take a few minutes, depending on the application, number of users, and entitlements.  Some application configurations will not experience this. 

8. At this time, users within Okta and the downstream applications should have matching entitlements. However, the user within Okta is set to an Assignment Type of Custom.  This means that users are not eligible for entitlements via Policy rules. 

In this example, Logan McNeil was assigned 3 feature licenses and 1 profile license within Okta based upon the import.  

NOTE:  Assignment Type of Custom infers that the user will not be granted any additional birthright entitlements via Policy Rules while in this state.  

9. Next, select the Governance tab, verify that entitlements are now visible under the Entitlement tab as well. This example shows that 5 different types of entitlements with various entitlement values have been imported.

NOTE: Assignment Type of Custom infers that the user will not be granted any additional birthright entitlements via Policy Rules while in this state.  

10. As part of the Assumptions section above and based on how users were assigned this application prior to migration, a set of Policy rules and Entitlement Bundles should be created at this point. 

For reference: 

• • Birthright = Policy rules, assigned when the user has an Assignment Type of Policy.
  • Self Service / Assigned via API = Entitlement Bundles.

NOTE: In this example image, a Policy rule was created that applies to anyone with the first name “Logan,” and they will automatically get the Force.com App Subscription User Profile entitlement. Ideally, leverage an Okta expression including attributes on the user's profile or group membership to assign entitlements. Multiple policy rules based on users' information are recommended for the distribution of entitlements for birthright access.

Also, create an Entitlement Bundle. Bundles are traditionally used in Access Requests, but can be applied in mass using the Grant API.

11. Next, revert users to Policy using the Revert to policy blue button. Locate the button by clicking the ellipse next to the user’s account, select View Access Details, then Edit access button. 

NOTE: Users can be converted back to Policy using the UI Revert to Policy button or via the Grant API (if doing it in bulk). 

Assignment Type of Policy infers that the user may be granted birthright entitlements via Policy Rules while in this state. 

12. Using the Grant API above or via Self Service Access Requests, users can be assigned the appropriate Entitlement Bundles.

13. At this point, users should be assigned the appropriate entitlements using both Policy Rules and Entitlements Bundles.

OPTIONAL:  Steps for spot checking policy and bundles assignment of entitlements.

1. Re-run an Import of the application. This will again import all users with their entitlements. If the entitlements within the application match the user in Okta, nothing will change. If any additional entitlements are found, the user will again be converted back to the Assignment Type of Custom from Policy. These steps will require reverting to Policy again, which will also remove any bundles, resulting in having to do the steps in the Revert to Policy section above over again for any users converted back to the Assignment Type of Custom.
2. Next, see if any users have been converted back to Custom using Access Campaigns.
3. Create an Access Certification Campaign for the application being migrated and select all entitlements.  
4. Launch the campaign, as the reviewer, and edit the Filters for faster reviewing. The filters are located at the top of the review items in a gray bar seen below. It is also possible to see this detail by clicking each individual user, the assignment type is listed on the right under Entitlements detail.

5. Set the filter to Assignment Type equals Custom as shown below and save.

6. Now, the campaign shows any users assigned to this application who are set to a Custom Assignment Type. This means that during the import process, additional entitlements were assigned to a user(s) above and beyond the Policy Rules and Entitlement Bundles within Okta. This allows for determining what differences were identified between the source application and Okta.

At this point, there are three options to rectify any differences:

1. Update Policy Rules / Entitlement Bundles based upon the differences. Repeat the Optional steps above to verify again.
2. Clean up differences in the source application being migrated. Repeat the Optional steps above to verify. 
3. Enable Create Users, Update User Attributes, and Deactivate Users settings. This will clear out any no longer needed entitlements in the target application.

USER Entitlement Verification in the UI

1. Locate the Assignment tab and select any assigned user.  Select the ellipse associated with a user and click the View access details link.
2. A new screen will appear showing any entitlements assigned to that user within the Application. Notice that these entitlements are displayed under Custom entitlements, Policy, or Access Requests. This refers to the method in which the user was assigned those entitlements. 

NOTE: Spot-checking various users is recommended to ensure that any and all entitlements associated with the user in the downstream application are represented within Okta correctly. Log in to the downstream application to compare assignments. Some entitlements are only available in the downstream application and are not imported into Okta. Users assigned to these types of entitlements in the downstream application may be represented within Okta, having no entitlements visible. This is normal behavior. Only imported entitlements will or can be assigned to the user within Okta.

USER Custom Assignment Type

During any migration process, users are imported with entitlements and have an Assignment Type of Custom.  This implies that the users can only acquire additional entitlements by an administrative assignment, Grant API, or via a self-service Access Request.  No Policy rules will apply to this user assigned to a Custom Assignment Type. This also means that this user will not receive any birthright entitlements, which Policy Rules are designed for.

ASSIGNING Birthright Entitlements to Migrated Users

Birthright access is supported with entitlements by using Policy Rules. Users must be converted to Policy before any existing policy rules are evaluated against them. If the Policy Rule applies to a user, any applicable birthright entitlements will be assigned when the Policy Rule engine runs.  

NOTE: Policy engine typically runs roughly every 5-10 Minutes.

Prior to converting, it is recommended to create policy rules associated with any birthright access because when users are converted to Policy, all custom entitlements and/or bundles are revoked. After the conversion, any policy rules are evaluated, and entitlements may be assigned. This will ensure users' access after the migration is intact, and users' entitlements are now being derived from birthright access.  

Users can be converted to Policy by clicking on the ellipse next to them on the Assignment tab. Click the View access detail link. On the next screen, click the Edit access button. On the Edit access screen, click the blue Revert to Policy button. Currently, this is completed per user in the UI, but leveraging the Create Grant API to assign to Policy can be scripted using Workflows or other tools.

Migration back from Entitlement Management to the traditional style of provisioning

Overview

Falling back from Entitlement Management

If an application needs to revert from entitlement management to the traditional style of assigning entitlements via group or individual, below are the steps to accomplish this task.

Applies To

• All components of OIG (Access Requests and Access Certifications)
• Okta Provisioning with Entitlements

Assumptions

• All the original groups were left intact during the migration to the entitlement management connector.
• All users assigned individually were documented and can be duplicated again upon reversal of the provisioning method, as needed. 
• There is Super Admin access to the Okta instance to configure entitlements.
• Migration back from entitlements has considered any impacts on production users. Always test in preview when possible.

Steps

To initiate the reversal of an application using Entitlement Management provisioning back to traditional provisioning. 

1. Log in to Okta as an Administrator with the Super Admin role.
2. Select Application > Application menu.
3. Search and select the existing application previously configured with Entitlement Management and Governance Engine enabled.
4. Locate and Provisioning tab, click the Edit link, and deselect the Enable API integration option. This will temporarily disable provisioning for this application.
5. Click on the General Tab, locate the Governance Engine section, edit it, and disable Governance Engine.

NOTE: Depending on the number of entitlements and number of users this may take some time. View in the system log for all related user updates to complete prior to the next steps.

6. Click back to the Provisioning tab, re-enable Provisioning, and enable Create Users | Update User Attributes | Deactivate Users | Sync Password settings for Provisioning to App. Then, save.
7. Locate the Assignment tab, locate any users assigned individually, and compare their original entitlements captured before the migration to entitlements. They should still have their original entitlements. Groups will also have their original entitlements, but groups will not sync with changes until a change has occurred with group or user.

NOTE: Enhancements are being evaluated to help automate the next few steps or synchronize groups and entitlements when reverting back from entitlements to traditional provisioning. The following steps are workarounds to accomplish the same outcome of ensuring a fallback migration from entitlements, where users are assigned entitlements individually or via groups.

GROUP Re-Connectivity

There are two supported approaches that will re-sync groups, entitlements, and users.

• Un-assign and reassign each group to the application, reselecting all the documented entitlements and saving.

or

• Un-assign and reassign users to a group within Okta.

User Re-Connectivity

Users assigned individually should already have their entitlements, but in the worst-case scenario:

• Un-assign and reassign each user, reselecting all the documented entitlements

Related References

• Revert a user to Policy in Okta Identity Governance
• For disconnected applications using entitlements for UARs, please see the CSV Import feature. 
• Guide on using Okta Identity Governance API’s