Okta Secure Partner Access Solution

Description:

In this document we will go over the high-level overview of the Secure Partner Access (SPA)  solution in Okta. Also, we will go over the setup of Realms and Partner Admin Portal.

Prerequisite:

  • Workforce Identity Cloud customers with Minimum Okta Identity engine (OIE)
  • For B2B customers managing partners with Realms, a SPA license is required.

Use case:

The Partner Admin Portal is a delegated admin portal designed to manage partner user access. The Partner Admin Portal is a separate first party (Okta) application that allows an Okta Admin to delegate user management out to a partner admin. Each realm can have its own partner admin, which can be defined using Okta’s custom admin role framework. At this time of writing, below are the available features.

Realms

  1. Separate users into different user populations within the same Okta Org
  2. Delegate administration to partner admins with granular permissions to manage specific users, as well as Groups and App assignments for a Realm or multiple Realms (via the customer admin role framework)
  3. Connect a business partner’s IdP to a Realm to import users (using JIT provisioning)
  4. Leverage the API to manage Realms and operations to manage Realm assignments

Partner Admin Portal  

Provide an out-of-the-box portal for partner (Realm) admins to manage their users, as well as Group and App assignments. This removes the need to grant partner admins access to the Okta Admin Console.

For the Realms they manage, partner admins will be able to: 

  1. Create, manage, update, suspend, deactivate, and delete Users
  2. Reset authenticators
  3. Application assignment
  4. Assign Users to Groups 

Note: Each of the above can be scoped based on the admin role definition in Okta.

High level architecture:

Below is the high level overview of Realms and the Partner Admin Portal. Realms are a unique construct of Okta’s Universal Directory. At this time of writing we can create 500 Realms per Okta Org. 

  • The Partner Admin Portal is a delegated administration portal hosted by Okta for customers to provide a management portal for their business partners.
  • Realm assignment policies provide automation around user assignments to Realms.
  • Users must be unique across Realms, meaning a User can only exist in one Realm at a time.
  • Applications and Groups span across Realms
  • Custom admin roles are used to manage delegated permissions inside Okta.

Realms:

You can read more about realms herehttps://help.okta.com/oie/en-us/content/topics/users-groups-profiles/realms/realms.htm

Realms and the Partner Admin Portal:

In this document we will go over creating a Realm and Partner Admin Portal with Secure Partner Access.

  1. Log in to your Okta instance, go under directories – Realms – click Create Realm on the right side.
  2. Put your Realm name and click on generate a portal for external partner admins. In my example, i am creating a Realm called House Stark. Then, click create Realm.
  1. Now, click on Realm assignments at the top of the Realms page.
  2. You can create Realm policies here on which source of users should be automatically assigned to this Realm. Click create Realm assignment. In my example I have created the assignment policy for House Stark. If your partners are authenticating using an IDP, then you can pick that IDP as profile source. You can also define a scope if you need only a specific set of users from that IDP to go to the Realm, rest all go to the default Realm. Finally, assign it to the Realm. You can also create any profile source in Okta. At this time of writing, a maximum of 10 profile sources are supported. If you don’t have any profile source and want to have a partner delegated admin create users manually, then you can skip this policy.
  1. At this time of writing below are the limits of Realms:
  1. Now, let us create a partner admin role and onboard the first partner admin who can manage the users in that realm. There are three steps to this process.
    1. Step 1: Create an admin group for the partner admin
      1. Go to directory – groups and click create group.
  1. Click the newly created group and assign the partner portal application from Okta. This should be created automatically when you click on the “Generate a portal” during Realm creation.
  1. Click another group for partner users. This will be the group that will be assigned to the end application which is given for all partner users in the Okta instance. This is an end user application, not the partner admin portal.
  1. Click the newly created group and assign the group to the application that is developed for partners.

You have completed step 1 successfully. Let us move to step 2.

  1. Step 2: Create a custom admin role for the partner.
    1. In order to set up a Realm admin role. Go to security – Administrators – role and click create role. This can be a default role that can be mapped to any different resource set of realms.  I have created the role below with managing users, specific group permissions, managing Realms, Application assignments.
  1. Click save role and go to resource set and create a resource set for that Realm and groups
  1. Add the resource set Realms, Users, Applications, and Groups
  1. Assign the admin group to the role created.
  1. Save the permissions and you have completed this step.
  2. Step 3: Create the partner admin and assign to the groups. You can also assign any Application admins in your organization who wants to manage that Realm to the role group.
    1. Go to directory – users and create user. Add the users to the necessary group. In my example below, I have created Bran Stark as the partner delegate admin and added to the House of Stark admin and users group. Select the realm as House of Stark.
    2. Activation email should have gone to the end user, where the partner can activate their account. For testing purposes, you can also set the password without an activation email. In this case, I have set the password for my Bran.Stark account. 
    3. Now, log in as the partner user Bran.Stark@atko.email.

Note: I did not walk through any MFA configurations for the partner. You can create MFA enrollment policies based on your company’s security policy. If you create a federated identity, I have provided the additional steps in the federated identity section below.

  1. You should see the Partner Admin Portal assigned to you upon login.
  1. Once you click the icon, you should be taken to the portal where you can see the access to the Realm.
  1. Click on the Realm and you should be able to see the users and groups based on the Realm-specific permissions we defined.
  1. Now, you should be able to create the users and add the user to the necessary groups. You should also be able to reset their authenticators and edit the profile of the users based on the custom admin role permissions in Okta.

Federated Users automation:

In most cases, business partners will need to federate with the Okta customer using their own  IDP, so that the Okta Admin doesn’t need to manage the partner users in Okta. To federate with a partner IDP and automate the groups and admin assignments, please follow the below steps.

Step 1: Set up the IDP

  1. Go to security – Identity provider and create an IDP. You need the metadata from the partner IDP before configuring this.

Note: Always follow best practice for IDP creation. 

  1. In my example below, I have created a partner IDP setup. If your partner comes only from a specific email domain, I will put that as a filter, so no one else can log in to Okta. Account link policy should always be disabled.
  1. On automation of groups, we have two options.
    1. Option 1: Customers don’t want automatic admin role assignments, only assignment of users to specific groups. In the below screen, I automatically assign users to the House of Stark users group.
  1. Option 2: Customers want their partners to decide who should be admins additional to adding in the users group.
  2. In the below screenshot, the IDP should add additional attributes in their IDP. In my example, I have groups as the SAML attribute and the IDP has to send the exact group names in Okta. For example, in the above screenshot, if they want to add to both admins and users, they need to pass House of Stark users andHouse Stark admins in their attribute. 

Note: The Partner IDP has to send groups in an array attribute.

  1. Once you complete the IDP setup. You should create the Realm assignment. Head to Directory – Realms – Realms assignment
  1. If you select not full sync of groups and assign them manually for admin permissions. Then you will need to add them to the admin group manually once they are authenticated from their IDP. Or you can also use our admin role access governance feature. So the partner admin can request an admin role once they authenticate from their IDP. This will create a proper governance process. You can read the documentation here https://iamse.blog/2024/04/08/a-look-at-the-new-govern-okta-admin-roles-feature/

Offboarding users automation

To off board users automatically you can use Okta Workflows. Go to Okta Workflows and under templates, you should see identify inactive user workflow Identify inactive user which can be added and enhanced for automation.

Leave a Reply