User Management: Designing for Security

At Okta, we see our customers deploy and build a broad range of customer-facing apps. Commonly, these apps support differing audiences, often reflected as segments within a single company, identities across customer companies, or users that span into partner organizations.

Which begs the question: how to centrally manage these diverse users while ensuring the proper level of security and data privacy?

When working with such different entities, one must consider several variables, such as customer data access, data separation, and user experience. Each of these variables can be the driving force behind a multiple Okta tenant structure.

Why multiple Okta tenants?

If your organization is faced with a diverse set of user types, consider the Okta tenant segregation model. This model separates each Okta tenant with its own data, network performance, and feature set, making each tenant its own entity. It also serves to add an additional layer of security to your infrastructure. To learn more about Okta’s tennant segregation, check out the Okta Security whitepaper.

Okta architecture types

There are several techniques we can use to design an effective Okta user structure. These techniques vary per implementation, but share similar characteristics. The following is a detailed look at the different scenerios and options you should consider.

Employee and Customer

An Employee and Customer configuration consists of two Okta tenants, one for the employee workforce and another for the customer user base. Keeping these two types seperate allows you to add your employees to Okta via legacy integrations such as Active Directory or LDAP. Doing so gives your employees their own set of password policies, and the use of the Okta Home page to access their applications.

For your customers, a separate Okta tenant is created and dedicated to them. By integrating Okta authentication into your customer-facing app, your customers login through Okta, but never see the Okta Home page, and in most cases are unaware they’re even using Okta.

This model allows you to use the single Okta platform, but securely segregate your internal workforce and external customer use base.

Employee and Partner

With an Employee and Partner configuration, your internal employees reside in one Okta tennant with the before mentioned legacy integrations. In this scenario, the second Okta tenant is created with inbound federation enabled. This allows partners to bring their existing identities and federate into Okta, gaining immediate access to your Okta protected apps.

This configuration allows your partner identities to live in a separate entity, while preserving and isolating your internal employee identities.

Multiple Customer

In a Multiple Customer environment, rather than dividing a user base by employees, customers or partners, the user base is divided by each customer. This configuration allows you to create an individual Okta tenant per customer, each of whom can then federate with your parent Okta tenant for resources.

In this scenario, each of your customers have their own Okta tenant, which can be branded to fit your needs. All feature sets, data stores, and network performance metrics are fully segregated. Companies are currently using this model, allowing them to focus their engineering resources on their core products rather than a proprietary identity stack.

Designed for security

Retaining a single platform gives an organization deployment agility and standardization, which ultimately increases cohesion and revenue. The Okta tenant segregation model, and its set of choices, provide the benefits of this single platform, while internal and externally securing your user’s data.

Whether you are creating an infrastructure for your employees and customers, employees and partners, or a larger per-customer architecture, Okta is ready to handle your scenario. Interested in figuring out your best tenant segregation model? Reach out to an Okta representative!