Table of Contents
What is Secure Partner Access?
How does Okta define business partners?
What specific problems or challenges are we solving for customers?
What key capabilities are we offering?
Who do I reach out to if I am interested in learning more about Secure Partner Access?
What is the process to enable the SPA feature to do configuration and testing on my preview account?
Is Secure Partner Access the same thing as Realms?
Can users exist in multiple Realms?
Can Groups span across multiple Realms?
Can Realm admins administer multiple Realms?
What is the migration plan for customers to move partner users into Realms?
Can I grant Realm Admins the ability to manage apps?
Do Okta Admins need to manually create custom admin roles and resource sets for each and every Realm?
What specific permissions are available within the custom admin role framework to manage Realms?
Are we offering any APIs for user management with this solution?
Is there a system limits and limitation page for SPA?
What Workflows templates exist for SPA?
Terms & Definitions
What is Secure Partner Access?
Secure Partner Access is a new Workforce Identity Cloud (WIC) solution suite that helps customers securely manage identity and access to shared applications for their business partners.
How does Okta define business partners?
Business partners are a collaboration between two or more business entities. Organizations with these ongoing business-to-business relationships share a vested interest in the growth and success of their partners’ businesses.
What specific problems or challenges are we solving for customers?
- Increased business partner risk. Cybercriminals are increasingly targeting partner and third-party access, which takes longer on average to detect and contain than data breaches caused by other factors
- Complex Identity frameworks. Properly onboarding and configuring user identities, including partners, with different access privileges to the same apps is not only cumbersome but is also inherently risky. This often requires developer resources and many customizations that burden IT.
- Pressure to do more with less. In an already challenging macroeconomic climate, companies are faced with added pressures to do more with less. Companies that share data and access to apps with large networks of vendors, distributors, and suppliers face an urgent need to optimize the efficiency of business partner operations, while reducing risk.
What key capabilities are we offering?
During Early Access, we will be offering the following capabilities:
| Capability | Description |
| Okta Realms & Realm Assignment | Create Realms to segment partner users and configure whether a Realm includes a Partner Admin Portal. View users assigned to each Realm and define Realm assignment conditions using profile sources or partner user attributes. |
| Add partner users into a Realm | Configure business partners’ OIDC and SAML 2.0 identity services and add to a Realm using JIT provisioning |
| Delegated Partner Admin | Delegate administration to partner admins with granular permissions to manage specific users, groups, and app assignments |
| Partner Admin Portal | Provide an out-of-the-box portal for partner admins to manage their users and app assignments. This removes the need to grant partner admins access to the Okta Admin Console. |
| Realms and Realms Assignment APIs | Offers APIs for managing Realms and executing Realm Assignments. |
In addition to the above, customers will be able to:
- OIG customers only: Scope access certification campaigns and entitlement policies to users in a Realm and designate partner admins as reviewers
- Workflows customers only: Create lifecycle management workflows for managing Realms
NOTE: Only Okta admins will be able to launch access certification campaigns on Realms from the Okta Admin Console and designate the partner admin as a reviewer. Partner admins will not be able to launch access certification campaigns from the Partner Admin Portal.
Who do I reach out to if I am interested in learning more about Secure Partner Access?
Please reach out to your Okta account rep.
What is the process to enable the SPA feature to do configuration and testing on my preview account?
You will need to reach out to your Okta account rep to ensure you have purchased the appropriate product SKUs before you can get access to the Early Access functionality.
Is Secure Partner Access the same thing as Realms?
No. Realms is just one of the several new feature capabilities we are offering with Secure Partner Access. Realms is a directory construct that we are introducing in two different ways for our customers to leverage:
- Secure Partner Access - For business partner use cases, Realms will be introduced as a part of Secure Partner Access. With this solution, customers can segment their user population, including partner populations, using Realms. They can go one step further, with a new partner admin portal that is being introduced. This partner admin portal provides a subset of actions that partner admins can take without accessing the Okta admin console.
- Realms for Workforce - For employee use cases, Realms is included with OIG, allowing customers to segment their workforce within a single org and delegate user management actions to more local admins (e.g., business unit, division, subsidiary, or help desk admins).
Can users exist in multiple Realms?
No. A Realm user can only exist in one Realm at a time.
Can Groups span across multiple Realms?
Yes, Groups sit at the Org level, which means it can span multiple Realms.
Can Realm admins administer multiple Realms?
Yes. A Realm admin can manage multiple Realms.
What is the migration plan for customers to move partner users into Realms?
If partner users are already in a single tenant, the Okta admin can perform a bulk move of users into the correct Realm. If partner users are in a hub and spoke deployment, the Okta admin will be able to leverage new rules that enable onboarding/user creation into the right Realm in the hub.
Can I grant Realm Admins the ability to manage apps?
No. With Secure Partner Access, Realm Admins will only be able to add new users into a Realm, move users between groups, and assign apps to users. In order to grant an admin the ability to manage an app, they would need to be added as an app admin, which exists outside the Secure Partner Access offering today.
Do Okta Admins need to manually create custom admin roles and resource sets for each and every Realm?
Yes. Currently, the Custom Admin Roles framework does not have a way to automatically generate realm-specific resource sets so Okta Admins will need to create resource sets for each and every realm. Okta Admins will not, however, need to manually create the admin role itself. Upon activation of the SPA SKU, a custom admin role called “Partner Admin” will be automatically generated in the customer's account with recommended permissions. Customers can restrict that role’s permissions further, according to their use case, but it is not recommended to add permissions. We will continue to work on providing additional automation enhancements on our future roadmap for this area of our product.
What specific permissions are available within the custom admin role framework to manage Realms?
The auto-generated custom admin role for delegated partner administration will come with the following permissions:
- Create users
- Includes permissions to assign values to any required custom attributes and assign users to groups in their resource set upon user creation
- View and edit users (names, email addresses, phone numbers)
- Edit users’ life cycle states and authenticators
- Edit users’ group membership
- Edit users’ application access
- View and manage group membership
- View and manage application access
- View realms
The Okta Admin can further restrict those permissions according to their partner admin delegation use case.
Once the permissions have been defined, the Okta Admin will need to define the resource set to complete the setup of the new custom admin role. Some resource sets to consider:
- Users (Users in Realm)
- Groups
- Applications
- Realms
More info provided in our help docs here.
Are we offering any APIs for user management with this solution?
Yes. We are building out functionality with public APIs. For example, Run Realm Assignment as part of a workflow when onboarding a new set of partners. Refer to the Realms API and Realm Assignments API docs for more information.
Is there a system limits and limitation page for SPA?
The limitations are on Realms and Realm Assignment Rules, which are documented here.
What Workflows templates exist for SPA?
Generate Reports for Okta Realms: This template generates a comprehensive report of all Okta Realms created within an Okta organization. It includes detailed information on user assignments to each Realm, providing a clear overview of user distribution and Realm configurations.
Terms & Definitions
| Realms | Realms for mutually exclusive teams Distinct teams within a single Okta Universal Directory identity store |
|
A Realm is a construct within Okta’s Universal Directory product that provides secure boundaries for users and IdPs. It is a new UD organizational structure and directory partition designed for mutually exclusive teams. Unlike Okta groups, users can belong to one – and only one – Realm. With this new construct, Realm-aware configurations and behaviors can be applied to this distinctly segmented population. To start, Realm awareness will extend to IdPs and Custom Admin Roles, allowing an Okta Super Admin to configure an IdP to a specific Realm and constrain a custom admin role to a specific Realm. As the functionality matures, Realm awareness will expand and additional features can be configured to specific Realms. | |
| Realm admins | Realm admins for delegated administration of mutually exclusive teams Custom Admin Roles with permissions to manage users and app assignments for a specific Realm or Realms |
| Realm admins are created by utilizing Okta’s Custom Admin Role capabilities. These admins are scoped to specific resource sets and can be used to delegate ongoing identity management tasks and app assignments to business partner end users. In this context, Realm admins are business partner admins; however, their scope can include delegated administration of more than one Realm. Realm admins are not Realm end users; they do not need to belong to the Realm they are managing. | |
| Realm users | Realm users are members of mutually exclusive teams Users with sole membership on one team |
| Realm users can belong to one – and only one – Realm at a time. When end users are placed in a Realm, they cannot be placed in another. Users are commonly placed in Okta groups, presenting challenges when users can be part of other groups. Groups are not mutually exclusive and cannot enforce firm, secure boundaries between different sets of users within a single Okta tenant. There is also no easy way to delegate administration of sets of users within a single Org | |
| Add partner users into a Realm | Add partner users into a Realm Distinct identity sources for mutually exclusive teams |
| Okta customers can connect and configure business partner IdPs/identity sources and associate it with a specific Realm. To start, OIDC and SAML 2.0 IdPs will be supported. Business partner identities will be JIT provisioned. | |
| Partner Admin Portal | Partner portal for delegated administration of mutually exclusive teams Separate admin console to manage mutually exclusive teams |
| A portal is a separate, scoped-down admin console that customers provide their partners to manage users, groups, and app assignments. Customers provide this app in lieu of the Okta Admin Console to enhance security by providing an app for delegated admin to partners, preventing 3rd party admins from accessing the Okta Admin Console. | |
