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
| Name | Source | Type | Description |
|---|
id | role.id + "@" + oktaDomain | string | Unique role identifier (domain-qualified). |
name | role.label | string | Role name. |
displayName | role.label | string | Display-friendly role name. |
oktaDomain | Collector context (non-API) | string | Okta organization domain where the role exists. |
description | role.description | string | Role description text when available. |
permissions | Hardcoded mapping | string[] | 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 Identifier | Role Name |
|---|
| SUPER_ADMIN | Super Administrator |
| ORG_ADMIN | Organization Administrator |
| USER_ADMIN | Group Administrator |
| GROUP_MEMBERSHIP_ADMIN | Group Membership Administrator |
| APP_ADMIN | Application Administrator |
| API_ACCESS_MANAGEMENT_ADMIN | API Access Management Administrator |
API_ADMIN | API Administrator (Deprecated?) |
| HELP_DESK_ADMIN | Help Desk Administrator |
| MOBILE_ADMIN | Mobile Administrator |
| WORKFLOWS_ADMIN | Workflows Administrator |
| REPORT_ADMIN | Report Administrator |
| READ_ONLY_ADMIN | Read-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.