On this page
Multi-tenant solutions
Organizations that need to manage a diverse set of user types should consider the Okta multi-tenant solution. This doc provides an overview of the solution, identifies reasons why organizations may want to consider it, and lists the different multi-tenant configurations available.
Important: When implementing a multi-tenant solution, ensure that all tenants are on the same version of Okta, either Okta Classic Engine or Okta Identity Engine. See Identify your Okta solution (opens new window) to determine your tenant's Okta version.
Acme Bank example
Acme Bank, a fictitious bank, is used throughout this doc to explain the details and key concepts around multi-tenancy. The company came to Okta to centralize and improve their existing identity management infrastructure. To meet the needs and demands of their employees, customers, and partners, they built their solution with a multi-tenant configuration.
What is a tenant?
A tenant is a single instance of software and supporting infrastructure that supports a group of users. Tenant's can represent any entity that interfaces with the organization such as its employees, customers, or partners. A tenant supports both a business-to-customer (B2C) and business-to-business (B2B) model where users can be either be direct customers or another organization's customers.
A tenant within Identity Access Management
A tenant can also be considered as an isolated island of data that is separate and private from other tenants. In the context of identity management, each tenant has its own security policies, user registration settings, user groups, roles, and rules that determine application access. An illustration of these different types of data is shown below:
Why would you want more than one tenant
An organization can create a new tenant for a variety of reasons. For example they may want to:
- Separate user administration and application access for internal employees from outside customers
- Store customer data in a certain region due to regulations and data residency requirements
- Satisfy a unique set of requirements (for example, distinct branding emails, onboarding videos) for a business with their own set of users
- Increase isolation, performance, and scalability for an organization with a large user base
Types of tenants
Tenants can comprise one or more of the following entities:
- Individual customers
- A business entity
- Employees
- Contractors
- External partners
Examples of organizations and their tenants are shown below:
Acme Bank's tenants
Acme Bank defined their tenants as:
Okta multi-tenant configuration options
Before we begin
This doc assumes a basic knowledge of the Okta data model and uses Okta terminology such as "org" and "Universal Directory" when describing key concepts and configurations. For more information on these entities and how they relate to each another, see the following resources:
Overview
Okta has a highly adaptable and configurable solution for customers looking to implement multi-tenancy. Depending on the solution, a tenant can take the form of an org container, user groups within an org, or a customer-defined entity that is separate from the Okta platform. What form the tenant takes within Okta’s platform is ultimately decided by the customer. Okta offers four main configurations for multi-tenancy. They are:
- Configuration 1: Host tenants in a single org using Universal Directory (UD)
- Configuration 2: Host tenants in separate orgs (for example, hub-and-spoke
- Configuration 3: Mixed. Host tenants in both single and separate orgs
- Configuration 4: Host tenants in a single org not using UD
Configuration 1
Host tenants in a single org using Universal Directory (UD)
Summary
This configuration hosts all tenants in a single org. Customers can do this by rolling their own custom solution. Since a tenant doesn't exist as a separate entity within the org, this method requires abstracting tenants through the use of the org’s users and user groups.
When to choose this configuration
Okta customers should choose this configuration when:
- Cost is the driver.
- Their users use a single version of all applications.
- User self-registration is the same for all users in all tenants.
- All tenants have a relatively small number of password policies (>1000).
- None of their customers and users have data residency requirements.
- All branding communications and onboarding experiences are the same for all users.
- It's acceptable to support unique usernames for each tenant by storing them
in the Okta platform with custom naming conventions (for example,
app-1-johndoe,app-2-johndoe).
How tenants are built
In this configuration, there's one org for all tenants. For example, Acme Bank configures one org for all of their individual customers, business customers, and partners. Regardless of how this configuration is implemented, tenants are typically created using groups. A group or collection of groups represent the users in a tenant. Groups are assigned to applications that give application access to all users within that group.
Acme Bank offers products, website portals, and other wealth management apps to their customers and partners. The following diagram lays out how these products, users, and groups would be organized within the Okta org.
User types
A recommended strategy is to create user types that allow a hierarchy of users with increasing permissions. As shown in the above diagram, three types of users are defined:
User
These people are users of the tenant. They can be individual customers in a customer's tenant, customers of a financial technology company, or employees of the Okta customer. Users have the ability to access products and applications assigned to them. Depending on the setup, they can also manage their own profile settings including updating passwords and enrolling in multifactor authentication (MFA).
Admin user
Admin users manage users of a tenant. Their responsibilities include:
- Adding and updating users within the tenant
- Assigning admin roles to other users
- Configuring Identity Providers
- Verifying email domains
Super user
These users can create new tenants and tenant admins. They are used by the Okta customer to manage tenants in their org.
Configuration 2
Host tenants in separate orgs (for example, hub-and-spoke)
Summary
This configuration separates tenants into separate containers (orgs). The most popular architecture for this configuration is known as hub-and-spoke.
When to use this configuration
Reasons why organizations choose this configuration include:
- Data residency requirements: The data in tenants can more easily be isolated when placed into separate orgs. This isolation becomes relevant when user data is required to reside in a specific region (for example, government regulations).
- Strong delegated admin support: Splitting customers and partners into separate orgs offers the maximum level of delegated responsibility support.
- Out-of-the-box duplicate name support: This configuration offers native support for duplicate usernames, since duplicate usernames can exist in different orgs.
- Branding emails: Branding emails, onboarding videos, and other communications are set at the org level. As a result, this configuration supports unique forms of communications per tenant.
- Performance: For large enterprise customers, there are performance advantages to spreading tenant user authentications into multiple orgs.
- Analytics: Reading analytics and tracking user adoption for each tenant is exponentially easier when tenants are separated into orgs.
- Unique DNSs: Customers in each tenant may want to customize their DNS and "post sign-in" redirect page. In this case, a tenant per org natively supports this functionality.
Implementations
The Okta supported design for a multi-org, multi-tenant configuration is the hub-and-spoke setup.
Hub-and-spoke physical layout
The two main components of the hub-and-spoke layout are:
Spoke: Org that contains users, user groups, and applications specific to that tenant. Spokes are responsible for lifecycle management and the authentication of its users.
Hub: Org that contains shared users, user groups, and applications. Spokes access shared applications and platform services through the hub. Hubs provide shared directory services, authentication, sign-in policies, and authorization services to spokes in a centralized way. In addition, hubs can route users to different spokes for authentication access to other spoke’s specific applications.
Connect the spokes to the hub
Using the Org2Org app integration, spokes can add users and give access to shared applications and services through the hub.
Note: The Org2Org app integration isn't available in Okta Developer-Edition orgs, so you can't use a developer org as a spoke org. If you need to test this feature in your Developer-Edition org, contact your Okta account team.
Diagram
The following diagram illustrates the hub-and-spoke configuration:
More information
To discover more about the hub-and-spoke architecture visit the following links:
- Okta for Global, Distributed Organizations (opens new window)
- An Identity Framework for Higher Education Systems (opens new window)
Configuration 3
Hybrid - host tenants in both single and separate orgs
Summary
Okta supports a hybrid configuration that mixes the setups described in both the first and second configurations. How this configuration is set up varies from customer to customer. One example of this hybrid configuration lays out orgs in a hub-and-spoke pattern like configuration 2. A spoke on this configuration can be composed of single or multiple tenants. See the following diagram for an illustrated example of this setup:
When to use this option
Depending on the requirements, business customers may require the data isolation, customizations, and other features provided by a single org. Other customers may not have these demands and can be placed on a shared org with other customers. This hybrid configuration supports both types of customers.
Configuration 4
Host tenants in a single org not using Universal Directory
Summary
In this configuration, the customer assumes responsibility for managing users, groups, and application access outside of the Okta org. Okta’s Universal Directory (UD) isn't used to store the tenants’ users and groups. See the following illustrated example of this configuration:
Reference
Additional resources
Additional multi-tenancy resources are below:
Relevant terminology
Org
The Okta identity solution is centered on an org. An org is a private container of data that holds all the resources necessary to manage user authentication. It's composed of three main objects:
- Applications
- Groups
- People (Users)
The Okta org is also a place that stores lists of available Identity Providers (IdPs), factors (for MFAs), password policies, and other security-related features.
The following diagram illustrates a simplified view of the Okta org.
