Assigning Administrators to Realms in Okta

Realms were introduced into Okta to provide an alternative mechanism for delegated administration with discrete user populations. A key aspect of this is the administration – you may need to have different types of administrator roles for the users in the realm, but also allow cross-realm roles. In this article we explore configuring administrators for realms.

The article relates to both realms used for Secure Partner Access (SPA) and realms used within Okta for user management. Realms are currently only available with either the Secure Partner Access or Okta Identity Governance products.

This article is part of a series of articles looking at Realms and Secure Partner Access. More articles can be found here.

An Introduction to Roles, Resources, Administrators and Realms

The new Realms feature leverages the existing Okta RBAC model, where Okta users are assigned administrative privileges based on roles and resources. Roles define the permission set and resources define what objects those permissions are applied to. You may have a role to manage users, and then a resource set to define the users that can be managed. That way you can have common reusable roles and use different resource sets to scope the access for different admins.

This is shown in the following figure.

To manage the realms and the users in the realms, admins can use the Okta Admin Console. If the new Secure Partner Access product is used, then its Partner Admin Portal can be used in addition to or instead of the Admin Console.

You will need to have roles and resource sets assigned to admin users to allow administration of users in realms (with or without Secure Partner Access).

In this article we will explore those admin constructs (Roles, Resources and Assignments) and how to configure the different admin UIs if Secure Partner Access is used.

Roles

Roles define the administrative permissions within Okta. Roles can range from all-powerful Super Administrator to more closely-scoped roles like Read-only Administrator and Report Administrator. For deployments that want more ganularity, custom rules can be defined using the palette of permissions provided within Okta. These can be used to manage realms.

Custom Roles for Realms vs. The SPA-Generated Role

Custom admin roles can be created to manage resources in Realms. If SPA is enabled, there is a custom role generated called Partner Admin.

If you do not have SPA, you will need to create one or more custom roles. Even if you do use SPA, you may want to look at custom roles if the generated role does not meet your needs.

Role Permissions

When assigning permissions for a role related to realms, you need to consider: the realm, the users in the realm, and resource types that users may be associated with such as groups and apps (that are outside the realm).

The default SPA Partner Access role provides a good baseline for realm role permissions.

The User permissions in this role are:

• Edit users’ lifecycle states
• View users and their details (with conditions)
• Edit users’ authenticator operations
• Edit users’ profile attributes (with conditions)
• Edit users’ application assignments
• Create users
• Edit users’ group membership

These may be overly permissive for your environment so you may want to reduce the permissions in the role, or create a new custom role with less permissions.

You an also restrict the user profile attributes that can be viewed and/or edited.

The other permissions in the default role are:

• Group
  • Manage group membership
  • View groups and their details
• Realms
  • View realms and their details
• Application
  • View application and their details
  • Edit application’s user assignments

The realms permission is important to be able to see the realms and users within realms. The group and application permissions allow visibility into the resources, and assignment of the users to them, but not management of the resources themselves.

With roles defined, you need to define the scope of those roles through resource sets and resources.

Resources and Resource Sets

Resources are the Okta objects you are restricting access to, like users and groups. Resource sets define logical grouping of resources. For example you may have a resource set that covers all users in a specific group and a set of applications. These are tied to roles to scope what resources the role permissions are applied to.

Resource Sets for Realms

With Realms, you may want to create a resource set for each realm, such as the example below where there are two resource sets, one for each realm.

You might have resource sets across multiple realms, and there may be overlapping resource sets. They are just configurations to control who (admins) can do what (role permissions) on what (resources).

Resources for Realms

When working with realms, you would define resource sets that include:

• Users – the users in the realm(s) you want to allow a set of admins to manage
• Groups – the groups you may want to manage membership for those users
• Applications – the applications you may want to manage membership for those users, and
• Realms – the realms that this applies to (this is important)

An example is shown below. It is focussed only on the “Atko Partner” realm. The users are limited to those in the “Atko Partner” realm. There are four groups and four applications that the assigned admin can manage membership for.

This is just an example, and your resource sets may cover multiple realms, and may have different groups/apps assigned. You might have different resource sets for different sets of groups/apps across the same realm(s).

Finally, the roles and resource sets must be assigned to users (admins).

Assignments

To grant permissions to any admin function in Okta, you need to associate a role (and possibly a permission set) to a user. This can be done individually or by group (where group membership would be preferred and the admin group membership managed with IGA controls). The following example will show individual admin assignment for simplicity.

Admin assignments can be seen under the Admins tab. In this case the one user, Mike Manager, is assigned to two roles, Partner Realm Admin (a custom role) and Partner Admin (the SPA-generated role).

These two roles could have different sets of permissions. When creating or managing role assignment, you can also associate a resource set. As we saw earlier, you create resource sets for realms.

So in this case the user Mike has the Partner Realm Admin role with the Partner Realm resource set. He also has the (SPA-generated) Partner Admin role with the Atko Partner resource set. So, different sets of permissions on different sets of resources.

You can also view the roles + resource sets assigned to a user via the user view under the Admin roles tab.

We now have a user who is defined as an administrator for two realms in Okta because they are mapped to two admin roles (with resource scoping).

Controlling Administrator UIs (SPA vs Okta Admin)

A standard Okta org has two user interfaces, the Desktop where users access apps, and the Admin Console where administrators manage the org. When a user as assigned to an admin role, they automatically get access to the admin console, with functionality based on the role(s) and resource set(s) assigned to that user.

This includes roles for managing realms and users in realms. Once you assign a user to a role and permission set for a realm, they can access the admin console with functions restricted to what the role gives them.

With the introduction of Secure Partner Access there is a new admin UI called the Partner Admin portal. This is a simplified user experience, designed for partner administrators to manage their users.

But do you want your partner admins to access both the Admin Console and the SPA Partner Admin Portal? Probably not. To address this there is a new Settings tab on the Administrators page where you can define admin role assignment to the Admin Console.

The default behaviour is that all admin users are automatically assigned to the Admin Console. You can change the behaviour so that the super admin assigns users to the Admin Console.

So, to have a realm admin only have access to the Partner portal, you would assign them to the Okta application called Partner Admin Portal.

If that user was already assigned to the Okta Admin Console, you would remove them.

Then when they access the Okta Dashboard, they will see the new Partner Admin Portal tile but not the Admin button.

When they access the portal, they can see the portals, users, groups, and apps that the role + resource set grants them.

You now have Okta users that have scoped access to realms and the users within those realms, via the Partner Admin Portal (and without access to the Okta Admin Console).

But if you are not using SPA, then you will need realm admins to use the Admin Console.

Conclusion

In this article we have looked at how we define administration of realms (with or without Secure Partner Access).

This involves using the standard Okta constructs of admin roles, resource sets and assignment of these to users. We have looked at how these are defined.

The second aspect, driven by the introduction of Secure Partner Access, is which interface will be used for this administration. We have looked at how you can use the default Admin Console or disable it and only allow access via the Secure Partner Access portal.