IAmDavid

Okta Privileged Access and Access Certification – Getting Roles into the Group Description

Written by

iamdavid

in

, , , ,

on

As with many SaaS applications in Okta, application entitlement can be managed via Okta Groups pushed to Okta Privileged Access (OPA). This means membership in OPA policies and roles is based on Okta Group membership and thus can be governed by access requests and access certification for those groups.

In this article we look at how the Okta Group description can be updated to show the OPA roles and polices assigned to help a reviewer in a certification campaign decide if the user should retain access. It shows the outcome and then how the mechanism was built using Okta Workflows.

Leveraging Governance Controls for Okta Privileged Access

Okta Privileged Access (OPA) is an OIDC/SCIM application like many other SaaS applications in Okta. Users and groups in Okta can be pushed to OPA, and then connected to the relevant OPA policies or administrative roles. This means the users and the groups they belong to are managed in Okta and can be subject to governance controls provided by Okta Identity Governance (OIG) – such as access requests and access certification for the group memberships.

If a reasonable naming standard is applied to the groups in Okta, it may be easy for business users (such as managers) to understand what access the group is granting in OPA. But groups in Okta also have a Description field to help understand what the group is used for, What if we could populate these Descriptions with the entitlements (policy and role membership) in OPA? That way when a manager is reviewing access for their people they can get a better understanding of the access they have.

Both Okta (the Workforce Identity Cloud platform) and Okta Privileged Access have APIs that can be used to build a mechanism to discover what groups are connected to in OPA and update the group description in Okta. Let’s look at the result and then how it was built.

The Outcome – Roles and Policies in Okta Group Descriptions

The aim of this is to make life easier for the business user and we do this by populating the Group Description with the OPA roles and polices.

The group description is a text attribute on the Group profile. So it is perfect place to store additional information about the group. Using the mechanism described later, the group definitions have been updated to reflect the OPA roles and policies.

This group view is in the Administrative Console of Okta, and thus is only useful to Okta Admins.

But it becomes more powerful when used in an Access Certification campaign visible to non-admins, such as managers that need to periodically review the access of their people. I built a User Access Review (UAR) campaign to look at all users assigned to the OPA application, looking at the direct group assignments.

The reviewer view is shown below, with users and their assigned groups. Clicking into the review row shows details about the user and group.

If we zoom in on the Resource Details we can see that whilst the description has been truncated, the mouse over function shows all the description.

Thus the reviewer has detail on what roles and policies this user has access to based on that group membership.

Now that we understand the outcome, let’s explore how the Workflows-based mechanism achieved it.

The Mechanism Implemented in Okta Workflows

Whilst this mechanism could have been built using any programming language supporting the Okta and OPA REST APIs, I chose to use Okta Workflows.

Overview

The background assumption for this implementation is that there are groups in Okta pushed to OPA, and those groups are assigned to policies and roles in OPA. The groups in Okta are Okta groups not application/directory groups. Also, that there may already be group descriptions for the groups that should be retained.

The overall flow of the mechanism is:

  1. Lookup all policies in OPA and store them with the groups that are assigned to them. This is so that when processing OPA groups individually later you don’t need to go back and search all policies again (to minimise API calls).
  2. Find all OPA groups (this will include all the OPA roles assigned to the groups)
  3. For each group
    • Skip if it’s the “everyone” or “owners” group as these don’t map to groups in Okta
    • Get the policies for the group from the table (step 1. above)
    • Search for the group, by name, in Okta and if not found, stop
    • Read the Okta group to get the current description
    • Build the new description from the current (if it’s there), the roles list from the earlier group search (step 2. above) and policies list
    • Update the Okta group with the new description

This could be run periodically or after any major change to the groups in OPA.

For the OPA API calls, the generic API Connector card is used (alternatively you could use the Workflows ASA connector). For the Okta API calls, the standard Okta Connector cards are used.

There are a set of main flows, sub flows and common utility flows.

The following sections look at the flows to implement this mechanism.

The Main Flows

There are two main flows to implement drive this mechanism.

The MAIN flow works on all OPA groups (steps 1. and 2. above), whereas the MAINa flow works on each individual group (step 3. above).

MAIN Flow

The MAIN flow starts by building the common fields needed for all OPA API calls, the authorization header and the prefix (i.e. {opa_url}/v1/teams/{team_name}). This is done in a utility flow (UTL20 – Get API Variables).

Then it calls another utility flow (UTL40 – Get All Security Policies) to get all policies and security groups and store them in a workflows table.

Next it uses a subflow (PAM10 – Get Group List) to return all OPA groups. The list retuned includes the roles assigned to the groups.

Each group object from the list is passed to a subflow (MAINa – Process a Single OPA Group).

MAINa Flow

The MAINa subflow will be passed the group object (from the list in MAIN) and unpack the group id, name and list of roles.

It checks that this particular group is not the “everyone” or “owners” group and, if not, it continues on.

Another subflow (PAM20 – Get Policies for Group) will find all entires in the policies-group table (built earlier) and return the list as a string.

It will then use the Okta Search Groups card to try to find the OPA group in Okta by name. If it can’t there will be a null Id returned and the flow will stop for this group.

It will take the earlier roles list (extracted from the group object in the first card of this flow) and convert it into a string.

Next it reads the Okta group using the Okta Read Group card and the Id from the search to get any existing description.

If there is a description present, it will append the new list of roles and policies to it, otherwise it will create a description with the roles and policies.

Finally it updates the group description with an Okta Update Group card.

Sub Flows

In addition to the two main flows, there are a number of subflows being used. In summary the important ones are:

  • PAM10 – Get Group List. This flow runs the List all Groups for a Team API endpoint to get a list of all groups in OPA with details (including the role list) and returns the object list to the calling flow.
  • PAM20 – Get Polices for Group. This flow is passed a group name and searches through the Policy Groups table (built by UTL40) for all policies that this group is a member of and returns the list of policies as a comma separated string to the calling flow.
  • UTL20 – Get API Variables. This utility flow sets up the API URL prefix ({opa_url}/v1/teams/{team_name}) and API authorization header. Documentation on how to setup the bearerAuth token used in the authorization object can be found here.
  • UTL40* – Get All Security Policies. This flow runs the List all Security Policies API endpoint to return a list of all polices, which includes an object list of all groups assigned as principals of the policy. This list of groups is extracted and the Policy Groups table is updated for each group-policy combination. An example is shown below.

The other UTL** flows are for more mundane tasks such as retrieving values from the environment variables table and doing text filtering.

That concludes the exploration of the mechanism.

Conclusion

Having groups in Okta pushed to Okta Privileged Access and mapped to security policies and administrative roles means that governance controls such as access certification can be used to manage user entitlements in OPA. To make life easier for a business user who needs to review access, the group description for OPA groups can contain the OPA roles and policies that group is connected to.

This article has shown how this can be implemented and the outcome as shown to the business user. This is just an example to show how the different APIs and Workflows can be used to enhance the business user experience. You could extend the mechanism to make the roles/polices more human-readable if naming standards weren’t helpful. You could also highlight the high-risk OPA-wide roles (pam_admin, security_admin and resource_admin) in the description.

Hopefully this article shows the value of leveraging Okta Identity Governance with Okta Privileged Access to provide a multi-layered approach to managing privileged access.