Tenants and brands

Some organizations own multiple market identities or brands. The OneWelcome Identity Platform (OIP) supports these organizations with a single identity infrastructure for multiple brands, while maintaining each brand's identity, including the look and feel.

The OneWelcome Identity Platform provides the flexibility to support your organization's size, user population, and online strategy:

• Tenants allow you to partition the identity store and separate your users according to your needs, such as employees, partners, customers, user types, and so on. A tenant is a logical partition. You can have one or more tenants. Tenants share the infrastructure, such as the microservices, databases, email providers, SMS providers, and so on. Each tenant has a different domain name and URL. Within a tenant, you can have multiple brands.

• Brands define the look and feel, policies, and processes to engage users for specific purposes or market propositions. Each tenant has one or more brands.

In general, the relationship between tenant and brand is one-to-many. This means that one tenant can have multiple brands. Every tenant must have at least one brand.

Differences between tenant and brand

The following table summarizes the differences between the tenant and brand.

Who creates them

Any authorized person can create a tenant, such as an administrator or a partner who is responsible for the configuration.

Similarly, anybody with the required authorization can create a brand.

SSO for tenants and brands

Each tenant has a different domain name and URL, which means there is no single sign-on (SSO) between tenants.

However, there is SSO between brands. If a user has an account in brand A, they can easily log in to brand B and brand C in the same session.

Tenant and brand configuration

Tenants have their own configurations. For example, you can configure different password policies for each tenant.

Some configurations are brand specific. For example, you can define the workflows and the activation at the brand level, and have three different registration journeys for brand A, brand B, and brand C.

Schemas

A tenant includes two data model schemas: the SCIM core schema and the OneWelcome schema.

You can also have an extension for a tenant, and define a data model for that tenant in a custom schema that includes your custom attributes.

When to use a multi-tenant approach

In a multi-tenant approach, every tenant is an independent logical partition.

An example of when to use a multi-tenant approach is when you have business-to-consumer (B2C) and business-to-business (B2B) identities. In this scenario, the consumers and business identities are logically separated, because they are two different groups of identities with no relationship between them.

Consider using a multi-tenant approach in the following scenario:

• There are different user groups, such as business-to-business (B2B) or business-to-consumer (B2C) users.

• There is no interaction whatsoever between different user constituencies, such as no SSO, different password policies, and so on

• There are different data model requirements.

Brands

Some configurations are tied to specific brands, such as workflows, activation processes, and others. Configuring these at the brand level allows for distinct registration journeys for each brand. This means you can have separate user journeys for brand A, brand B, and brand C, as required.