Okta introduces Custom Admin Roles for Identity Threat Protection with Okta AI

Are you looking for more granularity in managing how you configure Identity Threat Protection with Okta AI? We understand that security is a team effort, and different administrators have different responsibilities. To better align access with these responsibilities and adhere to the principle of least privilege, Okta has released a new capability to extend custom admin roles to new permissions and resource types for Identity Threat Protection with Okta AI.

What is Identity Threat Protection with Okta AI?

Identity Threat Protection with Okta AI is a product that runs within Okta Workforce Identity. It’s subject to the administrative model with users/groups assigned to Admin Roles.

Previously, we expanded the Admin Roles function to allow the creation of Custom Admin Roles. This comprised two parts:

• Exposing Role Permissions that were baked into the standard Admin Roles, so that custom roles could be defined. These permissions describe operations that can be performed on objects, like “Manage users,” “Create users,” and “Edit users' lifecycle states.”
• Adding Resource Sets with Resources allows admin roles to be scoped to specific sets of data. For example, you might have a resource set for all users, their groups, and apps in a specific department to restrict admin roles to only those objects.

We’ve now extended this functionality to include new permissions for operations related to Identity Threat Protection and new resources. This is not a new feature but an expansion of the existing feature set with more permissions and resource types.

Roles and permissions

We didn’t add new roles, but new permissions are available, including the ability to:

• View and manage user risk
• View and manage Shared Signals Framework (SSF) receiver streams
• View and manage policies
• View reports
• Configure logout
• Create a workflow

When defining roles, you may want to consider including permissions to:

• View or modify users: Includes access to view or modify users
• Clear users’ sessions: Provides admin access to clear user sessions
• View groups: Required for admins to see group assignments in the entity risk policy and post-auth session policy
• Manage applications: Gives admins the ability to configure Universal Logout for an app
• Run delegated flow: Enables the ability to run a delegated flow for use in the entity risk policy or post-auth session policy
• View delegated flow: Allows the ability to view a delegated flow
• Manage customizations: Required for admins to manage the post-auth session policy

You can use these new permissions to create custom admin roles for Identity Threat Protection. For example, you can extend the ability to view and escalate risk to your user administrators but have separate roles for managing policies and SSF integrations.

For a comparison of role permissions for different admin roles, check out the product documentation.

Resource sets

Resource sets are collections of resources mapped to admin roles to grant administrative access. A role defines what a user can do (operations), and a resource set defines what that role can operate on (data).

Two new resource types have been added for this feature:

• Shared Signals Framework (SSF) Receiver
• Policies (e.g., Entity Risk Policy, Session Protection Policy)

These can be combined with other resource types (such as users, applications, groups, and workflows) to support a delegated administrative model.

Custom admin role example

Let’s look at an instance of a custom admin role for an Identity Threat Protection administrator that covers all aspects of Identity Threat Protection, but not at the level of an Okta Super Admin role.

The role has the following permissions:

• User
  • Deactivate users
  • Suspend users
  • Clear users’ sessions
  • Manage users’ risk
• Group
  • View a group and its details
• Application
  • View an application and its details
• Workflow
  • View a delegated flow
  • Run a delegated flow
• Shared Signals Framework Receiver
  • Manage Shared Signals Framework (SSF) receiver streams
• Policies
  • Manage policies

In this scenario, the role provides limited access to the user — the ability to see (but not modify) the user’s apps and groups and to view user risk (but not access the user profile or devices).

The extension of custom admin roles within Identity Threat Protection allows for more granular control over admin permissions. By adding new permissions and resource types, organizations can create specific roles tailored to Identity Threat Protection management without relying solely on Super Admin privileges. This enhancement improves security and reduces risks by enabling the precise allocation of administrative responsibilities, ultimately leading to a more secure Okta deployment.

Extended features allow clearing the user sessions, elevating risk, and suspending/deactivating the user.

This update also enables access to groups, apps, security policies, and some other common admin functions, as well as the ability to manage SSF receivers. However, it doesn’t allow the configuration of Universal Logout for an app.

The admin role can then be scoped by resources in a resource set: Specific applications, users (by group), workflows, policies, and groups. When combined with the new (and existing) permissions, you can define appropriately permissioned administrators and eliminate the need for the Super Admin role, thus reducing the risks of that role to your Okta deployment.

Ready to learn more? Check out the documentation in our knowledge base or explore more new Identity Threat Protection with Okta AI features in our latest blog post.