Skip to main content
Applies to BloodHound Enterprise and CE

Overview

Okta provides a handful of built-in administrative roles that can be assigned to users, groups, and applications to delegate administrative tasks. These roles have predefined permissions and cannot be modified. The following roles are organization-wide:
  • Super Administrator
  • Organization Administrator
  • API Access Management Administrator
  • Mobile Administrator
  • Workflows Administrator
  • Report Administrator
  • Read-only Administrator
The most powerful role is the Super Administrator, which has full access to all features and settings in the Okta organization. The following roles can either be scoped to specific resources or assigned organization-wide:
  • Group Administrator (AKA User Administrator)
  • Group Membership Administrator
  • Help Desk Administrator
  • Application Administrator
Although the Workflows Administrator role is a built-in role, the Okta API treats it as a custom role that is scoped to the built-in Workflows Resource Set.
In OktaHound, built-in roles are represented as Okta_Role nodes.

Edges

The tables below list edges defined by the OktaHound extension only. Additional edges to or from this node may be created by other extensions.

Inbound Edges

Outbound Edges

No outbound edges are defined by the OktaHound extension for this node.

Properties

NameSourceTypeDescription
idrole.id + "@" + oktaDomainstringUnique role identifier (domain-qualified).
namerole.labelstringRole name.
displayNamerole.labelstringDisplay-friendly role name.
oktaDomainCollector context (non-API)stringOkta organization domain where the role exists.
descriptionrole.descriptionstringRole description text when available.
permissionsHardcoded mappingstring[]Effective permission labels associated with the role.

Sample Property Values

id: APP_ADMIN@contoso.okta.com
name: Application Administrator
displayName: Application Administrator
oktaDomain: contoso.okta.com
permissions:
    - okta.apps.manage
    - okta.apps.read
    - okta.apps.assignment.manage
    - okta.apps.clientCredentials.read
    - okta.users.appAssignment.manage
    - okta.groups.appAssignment.manage
    - okta.policies.manage
    - okta.policies.read
    - okta.users.read
    - okta.groups.read
    - okta.users.userprofile.manage
    - okta.users.userprofile.read
    - okta.profilesources.import.run
    - okta.agents.register
    - okta.realms.read

Built-In Role Identifiers

When working with roles using the Okta API, the built-in roles are referenced by the following identifiers:
Role IdentifierRole Name
SUPER_ADMINSuper Administrator
ORG_ADMINOrganization Administrator
USER_ADMINGroup Administrator
GROUP_MEMBERSHIP_ADMINGroup Membership Administrator
APP_ADMINApplication Administrator
API_ACCESS_MANAGEMENT_ADMINAPI Access Management Administrator
API_ADMINAPI Administrator (Deprecated?)
HELP_DESK_ADMINHelp Desk Administrator
MOBILE_ADMINMobile Administrator
WORKFLOWS_ADMINWorkflows Administrator
REPORT_ADMINReport Administrator
READ_ONLY_ADMINRead-Only Administrator
To make the role identifiers unique, the OktaHound collector adds the organization domain name as a suffix to each role’s ID, e.g., SUPER_ADMIN@contoso.okta.com.

Built-In Role Permissions

Unlike custom roles, built-in roles have fixed permissions that cannot be changed. However, the exact OAuth 2.0 scopes granted to each built-in role are not publicly documented by Okta and cannot even be retrieved via the API. We therefore did the mapping by ourselves based on the role descriptions in the Okta documentation. Hence, the resulting permissions ingested to BloodHound are best-effort approximations and may not be 100% accurate.