Okta Privileged Access – A Look at the Data Model

This article provides a simplified view of the data model used in Okta Privileged Access (OPA).

Note that this is a logical view of data objects and their relationships, and the term “object” is used very loosely (more like data types). Also this is based on the current Early Access product and may change with GA and into the future.

An Overview

If you are familiar with Okta Advanced Server Access (ASA), OPA represents a similar but more sophisticated model to support an administrative RBAC model and scalability for more privileged resource types.

The layout of the OPA user interface gives an indication of the data managed.

It is broken into three broad categories as shown in the menu layout:

  1. DIRECTORY – Users, Groups and Clients
  2. RESOURCE ADMINISTRATION – Resource Management, Gateways and System Configuration
  3. SECURITY ADMINISTRATION – Policies and Labels

It is important to note the separation of resource administration from security administration.

These objects and their relationships are shown below.

We will explore these objects and their relationships in the following sections.

Directory Objects

There are three directory objects that appear under the Directory section of the menu – Clients, Users and Groups (as shown. in the earlier screen shot).

Clients represent the enrolled client software (“sft”) running on user workstations and tied to specific users. When the client is installed and a user enrols in that client, an entry is added to the clients list.

Registered Users are provisioned from Okta when they are assigned to the Okta OPA app. For a user to be able to access the OPA UI or run the command line tool (sft client), they must be defined as a user in OPA (which maps back to an Okta user). There are also Service Users for programmatic access to OPA via APIs.

Groups are generally Okta Groups pushed from Okta, but can also be created locally in OPA (there are two default local groups – everyone and owners from the ASA heritage). Groups have two key uses:

  • Assignment to policy (to access a resource you must be in a group assigned to a policy that gives access to that resource). This is labeled as Principal in the figure above.
  • Assignment to administrative roles. Groups of users who can manage resources or policies. These might be the Common Roles, or Delegated Roles (assigned as Owners for Resource Groups).

There are also Roles in OPA. Groups may be assigned to one or more of the following Roles:

  • PAM Administrator – this role can assign groups to other roles but not perform any resource or policy administration
  • Resource Administrator – users in this role can administer ANY resource objects in this OPA Team
  • Delegated Resource Administrator – users in this role can administer only those resource objects in the Resource Group their group is assigned as an Owner to.
  • Security Administrator – users in this role can administer ANY security policy objects in this OPA Team

These roles are used to control who can manage resources and policies and any scope of that management.

Resource Administration Objects

The next section is the Resource Administration section of the menu.

Resources are the privileged “things” that OPA is controlling access to, like servers or shared credentials (secrets). Resource Administration is concerned with managing the resources, Gateways and System Configuration.

A Resource Group is a container for sets of resources and is used to group resources from an administrative scope perspective. For example, the ‘Linux Server’ resource group is administered by the Linux sysadmin team, whereas the ‘Critical App Secret’ resource group is administered by the Security team. It has a Name and Description. It can have Owners – groups of delegated administrators who can manage objects in that resource group. It also has one or more Projects.

Within Resource Groups are Projects. Projects are containers for related resources, such as servers or secrets. The contents of each project will depend on the resources stored in it. For example, for servers there are the server definitions themselves, the local accounts discovered on the servers (and which ones are managed in the vault) and a set of server settings such as enrolment tokens, discovery and password settings, gateway selection and account lifecycle (JIT or persistent). For secrets it’s the secrets and the secret folder structure.

Gateways are used for network proxying and other functions like SSH/RDP session recording. Gateways are set up with labels and these are used to map gateways to sets of servers in Projects.

There is also some Team-wide System Settings such as session durations and user/group attributes.

Security Administration Objects

The last section is the Security Administration section.

Labels are defined when some resources are enrolled. For example server resources have hostnames, OS types etc. Labels can be used when assigning resources to policies. You cannot change the labels – they are defined my the mechanism to import the resources. This is a security control to separate resource management from policy management – if labels are used to control policy, you can’t have resource administrators being able to change labels.

Policies define who can access what and how. A Policy has a Name and Description. Principals are who the policy applies to, by group. A Policy will have one or more Rules.

The contents of a rule will depend on the resource type it applies to. For secrets it defines the granular access on folders and secrets and any conditions (like requiring an access request approval). For servers it defines the access type (SSH/RDP), the resources (e.g. servers), access methods (i.e. with principal account and/or vaulted shared account) and any conditions (such as access request, per-resource MFA, via a gateway and with session recording).

Ideally resources would be assigned to policies via labels, but there may be situations where there is a direct assignment.

Multiple policies may apply to users and OPA will merge policies for a user when they try to access a resource. Policies can also be in a Draft (un-published) or Active (published) state. Only active policies will be used when determining if and how a user can access a resource.


In summary the following figure shows the objects and their relationships.

The key points are:

  • Users and Groups are provisioned/pushed from Okta (although local groups can be defined)
  • Groups are used to assign users to
    • team-wide roles (PAM Administrator, Resource Administrator, Security Administrator),
    • delegated roles (administrators for specific Resource Groups) and
    • policies (Principals, i.e. who can access a privileged resource)
  • Resource administration is separated from Security Policy administration with separate administrative roles (separation of duties for administrators)
  • A Resource Group contains Projects with resources and resource type-specific settings
  • A Policy contains Rules that define who can access resources and how.

This concludes the exploration of the Okta Privileged Access data model.

Leave a Reply