Governance for Okta Privileged Access Server Resources

IGA, OIG Access Requests, OIG Entitlement Management, Okta WIC Platform, OPA, PAM, Workflows for PAM, Workforce Identity Products 25 Minutes

This document describes the approach and mechanism to run a certification campaign to review Okta Privileged Access Resource (Server) access.

Introduction

The solution captured in this document is to demonstrate the power of the Unified Identity platform. The focus of this document is to provide the ability for our customer to enable self-service to request Okta Privileged Access resources and run an Access Certification campaign to audit user access, where reviewers can take decision if the user should  continue access or his access should be revoked.

The solution has been developed based on the BYOE concept of OIG (Okta Identity Governance).

Overview

The Aim of the Solution

The aim of this solution is to represent Okta Privileged Access (OPA) objects as entitlements in Okta Identity Governance (OIG) against a dummy app: to show the contents of an OPA policy as an Entitlement Bundle so it can be requested in OIG Access Requests, and to show the mapping of users to OPA policies as Entitlement Bundle Grants so that the access can be reviewed.

To be able to represent all the contents of an OPA Policy in an entitlement bundle, the components (resources, principals and any shared accounts) need to be represented as Entitlements. These are not used directly (e.g. exposed to OIG Access Requests).

For example, we have an OPA policy to allow some users access to some servers.

When transferred into OIG, we can see two users (Fred Flinstone and Eric Cartman) who are assigned to OPA (via a new dummy OPA – Entitlement app).

We can see the entitlements assigned to each, in this case there is a single entitlement bundle (reflecting the OPA “General Resource Policy” policy) and the bundle comprises a number of entitlements representing the servers, principals and shared accounts in OPA that are mapped to the policy.

As the policy is shown as an entitlement bundle, it can be exposed in OIG Access Requests as something that can be requested. However there is no mechanism to apply the user to the policy in OPA – the workflows covered later will raise a ticket (in JIRA).

An Access Certification Campaign run against the OPA – Entitlements app (the one we create the entitlement bundles against) shows the user assignment to OPA policy, with all of the policy content (servers, principals and shared accounts).

If the access is flagged to be revoked, a workflow will run to raise a ticket to have the user removed from the appropriate group mapped to the policy.

Next, let’s explore how the solution gets us to this point.

How the Solution is Built

This solution will help you to build a connector to read the Okta Privileged Access Policies and map it to OIG entitlements and entitlement bundles. Okta Privileged Access policies will be represented as entitlement bundles and other associated components will be treated or represented as entitlements (e.g. Groups, resource labels and Shared accounts). The below table describes how each Okta Privileged Access  object mapped, managed and audited in OIG.

Okta Privileged Access ObjectsOIG Objects
PoliciesEntitlement Bundles
Groups associated with PoliciesEntitlements and Entitlement Values
System Generated Server labelsEntitlements and Entitlement Values
Discovered Local AccountsEntitlements and Entitlement Values

Once objects are in OIG from Okta Privileged Access, this will open the ability for end users to request for policies and run the Access Certification campaigns for those policies in the form of entitlement bundles. 

This document has been written based on currently available features and APIs in OIG and Okta Privileged Access. Okta Workflow has been used to sync the Okta Privileged Access policies and associated resource information as entitlement bundles and entitlements respectively leveraging Okta Privileged Access Workflow connector.

The Workflows are structured as follows:

  1. Import OPA data into OIG Entitlements Management, including:
    1. Get and store a list of all OPA groups
    2. Get and analyze the OPA policies, then store the resources (labels), shared accounts and groups
    3. Create entitlements for the OPA groups
    4. Create entitlements for the OPA Policy labels
    5. Create entitlements for the OPA policy shared accounts
    6. Create entitlement bundles for each of the OPA policies, mapping the appropriate entitlements for the groups (principals), labels (resources) and shared accounts in the OPA policy
    7. Create grants to the entitlement bundles for each user in each group mapped to a policy
  2. Access Requests with OPA Entitlement Bundles, trigger workflow from within a Request Type, log a JIRA ticket for the changes and send emails to the requester and reviewer
  3. Access Certification with OPA Entitlement Bundles, trigger a workflow from the revoke action, raise a JIRA ticket and send an email to the administrator

This document assumes your tenant has OIG and Okta Privileged Access SKUs enabled and configured. Admin/user working has knowledge of OIG, Okta Privileged Access and Okta Workflow,

This document will have following sections to help you understand and adopt the solution:

  • Create Okta application
  • Setup Workflow
  • Sync Data and grant Access
  • Setup self service request
  • Setup Access Certification Campaign 
  • Access Certification Remediation Workflow

Note:- This solution will not support assignment of OPA entitlement using OIG entitlement policy, policy rules or custom assignment or individual entitlement assignment. Only supported mechanism is entitlement bundles assigned using workflow on day 0 or using self service requests. Access certification campaigns will only be reviewed for entitlement bundles.

Building Okta Privileged Access Sync Connector

As of today the Okta Privileged Access application in Okta does not have the ability to read or import any component from Okta Privileged Access. To accomplish this step, the solution will use a new (dummy) OIDC application. This application will mimic the user assignment as the Okta Privileged Access application. 

OPA Data Sync Steps

There are multiple stages of this solution, including workflow setup and configuring OIG components for Access Request and Access certification campaigns. They are:

  • Stage 1 – Create Okta application
    • Steps prior to triggering the Okta workflow – prior to triggering the data sync from OPA to Okta for OIG, the new OPA environment must be configured and OPA policies must be operational.
    • Step 1 – Setup the Okta OIDC application, with all default values, of type Web Application following Create OIDC App Integrations, Enable the Governance Engine and Assign group to this application.
  • Stage 2 – Setup Workflow 
    • Step 2 – Import workflow to sync data from OPA to OIG, to grant entitlement bundles to users and to handle remediation.
  • Stage 3 – Sync Data and grant access
    • Step 3 – Trigger Workflows to populate table data, create entitlements, create entitlement bundles and process initial grants. 
  • Stage 4 – Setup self service request
    • Step 4 – Configure Okta Access Request to enable self service to request Entitlement Bundles. 
  • Stage 5 – Setup Access Certification campaign
    • Step 5 – OPA Entitlement bundles Access Certification Campaign to review resource Access. 
  • Stage 6 – Testing
    • Step 6 – User cases can be tested. 

The following sections provide more details on the data sync flow stages.

Step 1: Okta Application Setup

  1. Login to Okta admin console.
  2. Navigate to Applications -> Applications.
  3. Click on the “Create App Integration” button.
  4. Select “OIDC – OpenID Connect” as the Sign-in method.
  5. Select “Web Application” as Application type and Click “Next” button
  6. Enter a name as “OPA – Entitlement” (note that the workflows are hardcoded to this name)
  7. Under the assignment section, select “Skip group assignment for now” and click the “Save” button.
  8. On the “General” tab of this application and scroll down to the Identity Governance action, click the Edit button, change Governance Engine to Enabled and Save.It will take a few moments to enable the Governance Engine.
  1. Navigate to the “Assignment” tab of this application and assign the same group (Group used here is “PAMAllUsers” group) to this application which is assigned to Okta Privileged Access application for Application authorization.

You will also need to enable the okta.governance.*** scopes in the Okta Workflows OAuth application. To do this:

  1. Go into Applications -> Applications and find the Okta Workflows OAuth application
  2. Go to the Okta API Scopes tab
  3. Scroll down to the okta.governance.*** scopes and Grant them all

This will allow the Workflows to read and manage access certifications, access requests and entitlements via APIs. 

You should not need any additional scopes as the default set that is granted should be sufficient for the Okta actions performed. If you find you are getting 403’s in workflows, check the scopes the actions are expecting and grant them in the Okta Workflows OAuth app.

Step 2: Setup Workflow

The step involves importing the Workflow flow pack to sync OPA data as entitlement and entitlement bundles into OIG. Workflow can be found on GitHub.

Step 2.1 Create Connections 

To work with flow for this solution we need to create connections for two workflow connectors.

2.2.1 Okta Connection

Follow the Okta Connector Authorization guide to create an Okta Connector connection. If you have an existing Okta connection and change the OAuth scopes (as per above) you may need to reauthorize the connection (you will need the client ID and secret from the Okta Workflows OAuth application in Okta, found on the Authentication tab).

2.2.2 Okta Privileged Access Connection

Follow the Okta Privileged Access Connector Authorization guide to create an Okta Connector connection.

2.2.3 Gmail Connection

Follow the Gmail Connector Authorization guide to create a Gmail Connector connection.

2.2.4 Jira Connection

Follow the Jira Connector Authorization guide to create a Jira Connector connection. 

Notes:- Provided solution uses Jira for ticketing application. If you practice any other ticketing system, replace the cards with the respective application connector.

Step 2.2 – Import the Workflow folder

In Okta Workflows create a new workflow folder and import the provided .folder file that contains the flows and tables.

Step 2.3 – Configure Okta for Delegated flows

The request access use case covered later involves calling a workflow from the access request. For this to function, Okta must be configured to allow access requests to see and use the Delegated workflows. 

See the blog article “OIG Access Requests – Calling an Okta Workflow from Within a Request Type”, specifically the step to Configure Roles and Resources in Okta, to see how to do this. Note that there’s a step to assign the Okta Access Requests OAuth user to the new role. You may need to type that in fully to see the name to select.

Step 3 – Sync Data and Grant Access

This section will guide the sequence of steps to populate the data in the Workflow table for entitlements and entitlement bundles creation and granting permission to users on day 0.

The following sections contain a lot of detail about the flows that are run to create entitlement objects in Okta (OIG) to reflect the OPA resources, groups and policies. In summary you will run the following workflows to create the objects:

  1. Run 1.1 List of OPA Groups – to get and store the OPA groups in a workflows table
  2. Run 1.2 List OPA Policies – to get the policies and their contents and store them in workflows tables
  3. Run 1.3 Principals Entitlement – to create OIG entitlements for each group
  4. Run 1.4 Infrastructure Access – Servers Entitlement – to create OG entitlements for each label (note label not actual server)
  5. Run 1.5 Shared Account Entitlements – to create OIG entitlements for each shared account defined in any policy rule
  6. Run 1.6 OPA Entitlement Bundles – to create a bundle for each OPA policy, with the principals (groups), labels and shared accounts as entitlements mapped to the bundle
  7. Run 1.7 Grant Entitlement Bundle – to assign each bundle to the users in the groups mapped to the policies, so you can see who (OPA user) is mapped to which OPA policy

See the following sections for the details. After these steps are run, you can look at access requests and access certification with the Entitlement Bundles these steps have created.

Step 3.1 – Populate the OPA Groups Table

This step is to read all the groups pushed from Okta UD to OPA and storing them into the workflow table. The 1.1 List of OPA Groups workflow is the one to list all groups from OPA and filter out locally created groups in OPA and store it in workflow table OPA Groups. 

The table looks like this:

cont.

Run the 1.1 List of OPA Groups workflow and list all the groups from OPA to store it in a workflow table and later reference the table data to create OIG entitlements and Entitlement Values. Once workflow is triggered it also triggers child flows 2.1 Prepare OPA Principals to store groups in workflow table OPA Groups. The high-level flow is shown in the following figures.

Main Flow: 1.1 List of OPA Groups

This is the main flow which initiates to prepare the list of all OPA groups and store them in the workflow table.

Child Flow: 2.1 Prepare OPA Principal 

This child flow filters out groups shipped as part of the OPA products (owner,everyone) or directly created in OPA and stores them in the workflow table.

Cont.

Step 3.2 – Populate the OPA Resource Details Tables

This step is to read all the policies in OPA which grants users access to server resources via resource labels and shared accounts and storing them into the multiple workflow tables. The 1.2 List OPA Policies workflow is the one to list all policies in OPA and filter out server resource labels and shared accounts and store it in workflow tables OPA Labels, OPA Vaulted Resource, Policy Resource Details and Policy group Details.

The tables looks like this:

Table1 – OPA Labels:

Table2 – OPA Vaulted Resource:

Table3 – Policy Resource Details:

Table4 – Policy Group Details:

The high-level flow is shown in the following figure.

Run the 1.2 List OPA Policies workflow which will list all the OPA policies and filter out all the resource labels and shared accounts used to store it in a workflow table and later reference the table data to create OIG entitlements and Entitlement Values. Once workflow is triggered it also triggers child flows 2.2 Read Resources and 2.3 Read Policy Groups to store followings:

  • Resource labels details in OPA Labels table
  • Shared Accounts details in OPA Vaulted Resource table
  • OPA Policy and groups association details in Policy Group Details table
  • OPA Policy association with Resource labels and Shared accounts in Policy Resource Details table
Main Flow: 1.2 List OPA Policies

This is the main flow which reads all the OPA policies and initiates the data processing for Resource labels, shared accounts and their association with OPA policies.

2.2 Read Resources child workflow internally triggers 3.1 Prepare Policy Resource Data workflow to capture unique resource labels and shared accounts details. 3.1 Prepare Policy Resource Data workflow internally triggers following helper flows to help with data processing and store processed data in tables:

  • 4.1 Process Individual Vault Acct List
  • 4.2 Preparing Policy labels
  • 4.3 Processing labels
  • 4.4 Processing Vaulted Accounts

Child Flow: 2.2 Read Resources

This child workflow triggers to filter out policies or rules which are enforced for secrets and delegate the process with relevant policies to child flow 3.1 Prepare Policy Resource Data.

Child Flow: 3.1 Prepare Policy Resource Data

This child workflow reads each policy and processes data to find unique resource labels and shared accounts with the help of other helper flows and store them in workflow tables.

cont…

cont…

Child Flow: 4.1 Process Individual Vault Acct List

Reads policy rules json objects to find out the shared accounts

Child Flow: 4.2 Preparing Policy labels

Reads policy rules json objects to find out the resource labels

Child Flow: 4.3 Processing labels

Processes resource labels data to avoid duplicates and stores them in OPA Labels workflow table.

cont…

Child Flow: 4.4 Processing Vaulted Accounts

Processes shared accounts data to avoid duplicates and stores them in the OPA Vaulted Resource workflow table.

cont…

2.3 Read Policy Groups child workflow internally triggers 3.2 Prepare Policy Group Data workflow to capture Policy and OPA group association and store data in Policy Groups Details table.

Child Flow: 2.3 Read Policy Groups

Read policy and group association and pass it to helper flow to store it in the table.

Child Flow: 3.2 Prepare Policy Group Data

Read data and create a row in the table at a time.

Step 3.3 – Create Principal Entitlements

This section provides the detailed steps to Create Principals entitlement for the application created in Step1, reading OPA Groups table and then updating back the same table with entitlementIds from responses.

The high-level flow is shown in the following figure.

Run the 1.3 Principals Entitlement workflow which will read the OPA Groups table to read all the Groups stored and prepare a list of unique groups. Once the list is prepared, passed to 2.4 Create OIG Entitlements child workflow to create entitlement as Principals for the application created in  Step1 and all groups as entitlement Values. Once entitlement and entitlement values are created another child workflow 1.3.1 Update Principals Entitlements triggered to update workflow table OPA Groups with entitlement and entitlement values Ids.

Main Flow: 1.3 Principals Entitlement

Prepare the list of all OPA groups by reading OPA Groups workflow table and pass the list to another child workflow 2.4 Create OIG Entitlements.

cont…

Child Flow: 2.4 Create OIG Entitlements

Creates entitlement and entitlements values for the application created in Step1.

cont…

Child Flow: 1.3.1 Update Principals Entitlements

Updates OPA Groups table with entitlement Id, entitlement values Ids and processing status.

Step 3.4 – Create Infrastructure Access – Servers Entitlements

This section provides the detailed steps to Create Infrastructure Access – Servers entitlement for the application created in Step1, reading OPA Labels table and then updating back the same table with entitlementIds from responses.

The high-level flow is shown in the following figure.

Run the 1.4 Infrastructure Access – Servers Entitlement workflow which will read the OPA Labels table to read all the resource labels stored and prepare a list of unique labels. Once the list is prepared, passed to 2.4 Create OIG Entitlements child workflow to create entitlement as Infrastructure Access – Servers for the application created in  Step1 and all labels  as entitlement Values. Once entitlement and entitlement values are created another child workflow 1.4.1 Update Infrastructure Access – Servers Entitlements triggered to update workflow table OPA Labels with entitlement and entitlement values Ids.

Main Flow: 1.4 Infrastructure Access – Servers Entitlement

Prepare the list of all OPA Labels by reading OPA Labels workflow table and pass the list to another child workflow 2.4 Create OIG Entitlements.

Child Flow: 2.4 Create OIG Entitlements

Creates entitlement and entitlements values for the application created in Step1.

cont…

Child Flow: 1.4.1 Update Infrastructure Access – Servers Entitlements

Updates OPA Labels table entitlement Id, entitlement values Ids and processing status.

Step 3.5 – Create Shared Accounts Entitlements

This section provides the detailed steps to Create Shared Accounts as entitlement for the application created in  Step1, reading OPA Vaulted Resource table and then updating back the same table with entitlementIds from responses.

The high-level flow is shown in the following figure.

Run the 1.5 Shared Account Entitlements workflow which will read the OPA Vaulted Resource table to read all the Shared accounts stored and prepare a list of unique shared accounts. Once the list is prepared, passed to 2.4 Create OIG Entitlements child workflow to create entitlement as Shared Accounts for the application created in  Step1 and all shared accounts as entitlement Values. Once entitlement and entitlement values are created another child workflow 1.5.1 Update Shared Accounts Entitlements triggered to update workflow table OPA Vaulted resource with entitlement and entitlement values Ids.

Main Flow: 1.5 Shared Account Entitlements

Prepare the list of all OPA Shared Accounts used across policies by reading OPA Vaulted Resource workflow table and pass the list to another child workflow 2.4 Create OIG Entitlements.

Child Flow: 2.4 Create OIG Entitlements

Creates entitlement and entitlements values for the application created in Step1.

cont…

Child Flow: 1.5.1 Update Shared Account Entitlements

Updates OPA Vaulted Resource table with entitlement Id, entitlement values Ids and processing status.

Step 3.6 – Create Entitlement Bundles

This section provides the detailed steps to create entitlement bundles mirroring OPA policy as entitlement bundle and keeping the same name as policy for entitlement bundles and associating with same Principals, Infrastructure Access – Servers and Shared Accounts as entitlement values.

The high-level flow is shown in the following figure.

Main Flow: 1.6 OPA Entitlement Bundles

Run the 1.6 OPA Entitlement Bundles workflow which will read the Policy Groups Details table to read all OPA Policies names and descriptions and create a list which will be used to create entitlement bundles. Once the list is prepared, passed to 1.6.1 Prepare OPA Entitlement Bundles child workflow to create entitlement bundles for the application created in  Step1. Once entitlement bundles are created, triggers 1.6.5 Prepare Entitlement bundle ID to store the entitlement bundle Ids in Policy Groups Details table.

Child Flow: 1.6.1 Prepare OPA Entitlement Bundles

1.6.1 Prepare OPA Entitlement Bundles child workflow internally triggers a few helper workflows to read entitlement Ids from a few workflow tables to construct json objects to pass to entitlement bundles API endpoints to create entitlement bundles.

Following helper flows are triggered to read data in tables and construct json objects:

  • 1.6.6 Verify Okta Group
  • 1.6.2 Prepare Principals for Entitlement Bundle
  • 1.6.3 Read Infrastructure Access – Servers for Entitlement Bundle
  • 1.6.4 Read Vaulted Accounts for Entitlement Bundle

cont…

cont…

cont…

cont…

cont…

cont…

cont…

cont…

cont…

Child Flow: 1.6.6 Verify Okta Group

This child workflow verifies and confirms that the supplied group exists in Okta.

Child Flow: 1.6.2 Prepare Principals for Entitlement Bundle

This child workflow reads the OPA Groups table to prepare a list of entitlement and entitlement value Ids for Principals entitlement.

Child Flow: 1.6.3 Read Infrastructure Access – Servers for Entitlement Bundle

This child workflow helps to build and prepare a list of entitlement and entitlement value Ids for Infrastructure Access – Servers entitlement with the help of another helper workflow 1.7.1 Prepare Resources for Entitlement Bundle.

cont…

Child Flow: 1.7.1 Prepare Resources for Entitlement Bundle

This flow helps reading OPA Labels table to get entitlement and entitlement values Ids for  Infrastructure Access – Servers entitlement.

Child Flow: 1.6.4 Read Vaulted Accounts for Entitlement Bundle

This child workflow helps to build and prepare a list of entitlement and entitlement value Ids for Shared Accounts entitlement with the help of another helper workflow 1.7.2 Prepare Vaulted Accounts for Entitlement Bundle.

cont…

Child Flow: 1.7.2 Prepare Vaulted Accounts for Entitlement Bundle

This flow helps reading OPA Vaulted Resource tables to get entitlement and entitlement values Ids for  Shared Accounts entitlement.

Child Flow: 1.6.5 Prepare Entitlement bundle ID

Once entitlement bundles are created another child workflow 1.6.5 Prepare Entitlement bundle ID triggered to update workflow table Policy Groups Details with entitlement bundle Ids using a helper workflow 1.7.3 Update Entitlement Bundle ID.

cont…

Child Flow: 1.7.3 Update Entitlement Bundle ID

This flow updates the entitlement bundle IDs in Policy Groups Details table.

Step 3.7 – Grant Entitlement Bundles

This section provides the detailed steps to grant entitlement bundles to existing users which will help to run the certification campaign to identify user access to OPA policies and review for continued access. This will grant the entitlement bundle which is a mirror of OPA policies.

The high-level flow is shown in the following figure.

Main Flow: 1.7 Grant Entitlement Bundle

Run the 1.7 Grant Entitlement Bundle workflow which will read the Policy Groups Details table to read the OPA policy name and respective entitlement bundle IDs with groups association information to identify the members of each group and then grant the entitlement bundles to each member accordingly and keep in sync with OPA policies. This flow will use following child flows to grant the entitlement bundles to OPA users:

  • 1.8.1 Prepare Entitlement Bundle Assignment
  • 1.9.1 Prepare List of Members
  • 1.10.1 Assign Entitlement Bundle
Child Flow: 1.8.1 Prepare Entitlement Bundle Assignment

This flow reads the entitlement bundle IDs and groups associated with an OPA policy from Policy Groups Details table.

Child Flow: 1.9.1 Prepare List of Members

This flow gets the entitlement bundle ID and associated groups to prepare a list of group members.

Child Flow: 1.10.1 Assign Entitlement Bundle

This flow verifies the user status in Okta to only handle Active users and assign the entitlement bundle.

cont…

Step 4 – Setup self service request

This section provides the detailed steps to set up self service to make OPA policy/entitlement requestable using a new resource catalog.

Step 4.1 – Create a Delegated Workflow for Entitlement Self Service

This step is to create delegated workflow which will be called by self service requests for OPA policies (Mapped as entitlement bundle in OIG). Once a request is submitted by requester, this workflow will be triggered to create an  issue in the ticketing system and send emails to requester and assignee informing about the same. Request assignee would require to add requester in a group for that policy manually and approve the request in Okta OIG which will make sure the access in OPA and entitlement bundles in OIG are in sync. In this example we have used Jira but any other ticketing system can be used or plugged into this flow.

The high-level flow is shown in the following figure.

Main Flow: 1.8 OPA Entitlement Request

1.8 OPA Entitlement Request workflow will be triggered when the end user will request for Entitlement Bundles. This workflow needs to be added in the Access Request condition Sequence (detailed below). You may need to update some values in this sample flow.

cont…

cont…

Step 4.2 – Configure Self Service for OPA entitlement Bundle

This step is to configure an Access Request to enable self service for users to request OPA entitlement bundles. 

Step 4.2.1 – Create an Access Request

These steps assume that you are familiar with the new OIG Resource Catalog approach to create a condition.

  1. Login to Okta admin console.
  2. Navigate to Applications -> Applications.
  3. Search for “OPA – Entitlement” Application and click to open
  4. Once application is open click on Access requests tab
  1. On Access requests page click on Create Condition button to start
  1. Once condition page is open give a name as “OPA Resource Access Request”
  2. Define requester scope as “PAMAllUsers” as group. This group will have all members who have access to “Okta Privileged Access” application and “OPA – Entitlement” applications.
  1. Select “Requester must Specify entitlements” as an option and list all the entitlement bundles created as part of Step 3.6 in Access level section.
  1. Skip Access Duration
  2. The last section of a condition is the Approval sequence. You can build up a library of approval sequences that can be used in different Access request conditions. Here we will create a new sequence for OPA.
  1. Click the Select sequence button to see the sequences page and click on New sequence button.
  1. A new sequence designer page will open in a new tab and display the standard sequence template to start with.
  2. Click on the pencil icon to give a sequence name.
  1. Provide sequence name and description, then click Continue
  1. For this sequence we’re asking for business justification and the user’s manager as the first approver. Click on + sign and select Questions to collect business justification from the requester.
  2. Once Business justification is added now click on + sign again to select the first Approval step and select Requester’s manager for the Assign to.
  1. After the first approver’s approval this sequence will be called an Okta workflow. To do that click on ‘+’ after “Approval for Requester’s Manager”.
  1.  Select the workflow which was created in step 4.1. Once selected it will prompt with few input parameters required for workflow. Map those relevant attributes.
  1. Finally add PAM Resource Owner (Owner of the PAMResourceApprover group) as approver who will manually assign the OPA policy and then approve the request. This will help data to be in sync at both places OIG and OPA. Click on Save button and close the browser tab.
  1. Click the refresh icon on the screen to see the new sequence.
  1. Now select the above created sequence to assign it to condition.
  1. Now you should see the sequence assigned as approval sequence on the condition page. Click on the Create button to create the condition.
  1. Now the newly created Access Request Condition should be visible in the disabled state.
  1. Enable the condition. 
  1. Once the condition is enabled, ready to use.

The steps to test are covered in a later section.

Step 5 – Setup Access Certification Campaign

This step is dependent on all the above steps taken to create entitlements and entitlement  bundles. It will set up an Access Certification campaign to review user access to OPA resources and the remediation steps.

Step 5.1 – Configure Access Certification Campaign for OPA Entitlements

This section will walkthrough to create an Access Certification campaign for Okta Privileged Access server resources. 

Step 5.1.1 – Create an Access Certification Campaign

These steps assume that you are familiar with the OIG Access Certification Campaigns.

To create a new Access Certification:

  1. Log into Okta as an Administrator with the Access Certification role or Super Admin.
  2. Select Identity Governance menu.
  3. Select Access Certification application.
  4. Locate and click the blue Create campaign button.
  5. Select Resource Campaign
  6. Fill out each step to create a campaign.
  1. Enter the name of the campaign and description. The description is visible to the reviewer and can be used as part of a verification rule.
  2. Select the start date / time, time zone.
  3. Select the duration of time the campaign will run.  Note:  A duration of at least 8 days is required as a minimum to support multiple levels of reviewers.
  4. Lastly, select Make this recurring and set up those related options as needed if desired.
  5. Click the Next button.
  6. Select Resource Type as Application
  1. Select the application name created above for OPA entitlement in Step 1 and turn on the Review entitlements selector. Leave the selection as is. Click Next.
  1. Select the user scope who should be included for review. 
  1. Setup first level reviewer as user’s manager
  1. Setup second level reviewer as PAM Resource Reviewer (Used Group is “PAM Request Approvers” group)
  1. Select all the notification options which you want to send and select both options under additional settings. Click Next.
  1. Finally select remediation action as “remove access from user” when Reviewer revokes access.
  1. Click on the Schedule Campaign button.

We will test it in a later section. The following section describes the Workflows that will be called.

Step 5.2 – Configure Workflow to handle OPA entitlements remediation

This section will help to set up a workflow to handle remediation when Access review is revoked. For OPA entitlement bundle reviews we will be taking 2 levels of review approach. First level will confirm that the user is entitled to continue with the OPA entitlement bundle access or not and if access has been revoked by first level reviewer then second level of reviewer will take action in OPA manually and then come back on Access Review console and revoke the access. This will make sure that OIG data are in sync with OPA. This step will guide us to configure workflow for Access Certification Reviews which will be triggered once Access is revoked.

The high-level flow is shown in the following figure.

Main Flow: 1.9 Access Certification Remediation

1.9 Access Certification Remediation workflow will be triggered when an Access reviewer  will revoke the user access from the entitlement bundle. When the first reviewer reviews and revokes the access, flow will create a Jira ticket with details (this can be replaced by any workflow supported ticketing system) and send a notification to the second reviewer. Based on ticket and notification reviewers need to remove the user access first from OPA and then come on Access Certification Review console and revoke the access which will remove the entitlement bundle assignment from OIG and keep both ends data in sync. There are 2 helper flows: 1.9.2 Find Entitlement Name to find the entitlement name based on ID and 1.9.3 Get Entitlement Details to fetch the entitlement details from the workflow table OPA Groups.

cont…

cont…

cont…

cont…

cont…

cont…

Note the sample 1.9 flow send an email to a specific email address that you should change.

Child Flow: 1.9.2 Find Entitlement Name

This flow gets the entitlement name associated with the entitlement bundle.

Child Flow: 1.9.3 Get Entitlement Details

This flow gets the entitlement details.

Step 6 – Testing Steps

Once the above set up and configuration is completed, then the access review can be tested.

Step 6.1 – Request for OPA Entitlements

This section will guide you through how a user requests for OPA entitlements and sequence of actions once the request has been submitted.

Step 6.1.1 – Request Submission Process

This section guides step by step process to demonstrate the request submission process.

  1. Create a test user in Okta with an assigned manager,if you do not have a user to test with,  and Login to Okta tenant using test user credential.
  2. Once landed on the Okta dashboard, click on “Request Access” button
  1. Click on “OPA-Entitlement” tile
  1. Once you click on the tile, a list of entitlement bundles with descriptions will be displayed
  1. Select one of the entitlement bundle and provide justification and submit the request
  1. Once request submitted, user should see status as “Request submitted”

Step 6.1.2 – Request Approval Process

This section guides step by step process to demonstrate the request approval process.

  1. Login to Okta as using test user manager credential
  2. On Okta dashboard click on Access Request portal to see the request
  3. Approve the request which will trigger next action in sequence to trigger a workflow to create a jira and assign the next level of approver to PAM Resource Approver
  4. Login to Okta as resource approver and access the Access Request portal
  5. Search for the relevant request assigned and refer to the respective Jira ticket.
  6. Look for details and add users to the group which grants him the  requested OPA policy. Assuming pushed groups are configured for OPA application.
  7. Once a user is assigned to the Okta group, approve the request in OIG.  Once a request is approved a user will be assigned to the entitlement bundle and make sure that policy in OPA is in sync with OIG entitlement bundle.

Step 6.2 – Launch and Review OPA Entitlements Access

This section will guide you through how user access can be reviewed for OPA entitlements and sequence of actions once the remediation action taken by reviewers.

Step 6.2.1 – Launch the Campaign

  1. Login to Okta as Access Certifications administrator
  2. Navigate to the admin console
  3. Open Access Certification application
  1. Select the campaign under the scheduled section and Launch the Access certification campaign created in step 5.1.1
  2. Once a campaign is launched successfully, As an admin you can view the list of all the users in review scope, their respective reviewers and Review level. If required you should be able to reassign the reviews to others.

Step 6.2.2 – Review the Access

Once a campaign is launched successfully, reviews will be assigned to reviewers and they will be notified.

  1. Login as a reviewer to Okta tenant
  2. Once land on Okta dashboard, click on Okta Access Certification Review tile
  1. Once Access Certification Review console is opened, click on the review 
  1. Once Access the reviews console starts reviewing. To test the remediation click on the Revoke button.
  1. Once the first level reviewer revokes, the second level of reviewer will be notified and also a workflow will be triggered to create a Jira ticket and reviewer will receive a mail with details ticket URL link.
  2. Second level reviewers need to login to Okta admin console as group administrator and remove the user from the group which grants users the OPA policy, mentioned in the jira ticket details. 
  3. Once user access is fixed in Okta for OPA policy, navigate back to Okta dashboard as a second level reviewer and follow the same process to review in OIG and revoke user access. This will sync OIG and OPA information. 

Published by Rajesh Kumar

Over 20+ years of enterprise security professional with extensive experience in designing, implementing and integrating Identity and Access Management solutions across multitudes of market segments and industries (including public, retail, research, financial, HealthCare etc.).

Published

One thought on “Governance for Okta Privileged Access Server Resources”

  1. Pingback: Privileged Access Management for Federated Users – IAMSE

Leave a Reply