Authentication and authorization in multi-tenancy B2B scenarios

Business to Business

B2B describes the situation where an organization interacts with other organizations. This multi-tenancy architecture usually adds some form of complexity to an Identity and Access Management System. In ZITADEL an organization can represent a business partner or partner who typically has its own branding and has different access settings like an additional federated login for its users.

B2B can be a simple scenario where an organization only shares one of its projects with another organization or has a more complex case where an organization is offering a portal application to all its partners with included (self)administration.

Sample scenario

Octagon is a fictitious company used throughout this guide to explain the details and key concepts of such a B2B scenario. Octagon tries to solve multiple tasks in the banking field. Its portfolio includes several applications for their employees, customers, and partners. Some of which are web-based, some of which are used by service accounts only.

Portal Application

Octagon has a Portal application where its employees can access their account and list all applications they are allowed to use. Employees work for a department within Octagon or for Octagon itself. Some users have enhanced features because they supervise certain teams. Those can onboard new employees and manage their roles and features. Target groups of the application can be split into:

Employees: users who are using the application as a starting point for their work.
Supervisors: users who are mainly using the application to manage users and their access of their department.
Administrators: users who can grant additional organizations or departments and elect supervisors.

Planning considerations

To define the need of the Portal Application, some planning considerations about organizations have to be made:

Login and Access: Does a user have a preset organization to login? Does the application show the default login page, or does each organization use its own branding?
Organizations: Does a user have access to multiple organizations? Is a user required to use a different federated login for those organizations?
Roles Does the application need users to have specific roles assigned within their organizations? Which roles are needed to enable certain features of the application?

You can decide whether an organization is preselected for the login or if the user is redirected to the default login screen. Using OpenID Connect, you can send the user to a specific organization by defining the organization in a reserved scope (Organization Domain). Settings to the branding or the login options of the organization can be made from the organization section in Console. The behavior of the login branding can be set in your project detail page. You can choose the branding of the selected organization, the user's organization, or the project's organization.

Organizations

Generally a user belongs to and is managed by one organization, however, a user can be authorized to access projects in other organizations via role assignments. A user should be able to use the same identity to switch between organizations. If this feature is not desired, a separate user for each organization should be created.

Adding a user from a different organization to the audience of a project can be as easy as assigning a new role to a user. A role assignment combines a user from any organization with a project and 0-N roles.

Our sample scenario includes the following users:

Dimitri: a team leader who is employed by the Pentagon, an Octagon department. Dimitri uses his Microsoft Account in combination with a One Time Password to access the portal. Pentagon therefore has set up Microsoft as their Identity Provider. Pentagon also requires its users to secure their accounts with additional factors.
Michael: a trainee of the Pentagon who uses the portal to access his workspace apps. Michael uses his Google Account in combination with biometrics (e.g., his fingerprint on his Laptop).
Bill: is employed at Octagon as an Administrator of the Portal Application. Bill also uses a Microsoft Account in combination with a Security Key to secure his account.

After having determined the constellation of the organizations and its users, all the necessary data (Portal project with roles and app, users, login requirements, identity providers, branding) should be set up in Console. A B2B sample application for NextJS can be found here.

To allow another organization to use a project, a project grant has to be created. Upon creation, roles for a grant can be limited to a subset of the total project roles.

In our scenario, the Octagon creates a project grant for the Pentagon. Pentagon is limited to use writer and reader role. The admin role is reserved for the Octagon organization itself.

Octagon (owner)

Portal Project

WEBAPP

reader, writer, admin

Bill (admin)

Pentagon

Portal Project (grant)

WEBAPP

reader, writer

Dimitri (writer)

Michael (reader)

Roles

This scenario involves two organizations: Octagon and Pentagon. Bill, a user from the Octagon organization, is assigned the admin role for the Portal project. Dimitri and Michael are both part of the Pentagon organization and have been assigned the writer and reader roles, respectively.

Note: Roles are intended for your application's internal business logic and require separate validation. The users in this example cannot manage role assignments for other users unless they have an appropriate ZITADEL administrator role.

If you build a dashboard for users to assign roles, you must use the Management API with the user's personal access token and not with a machine user's token. This ensures that all actions are properly recorded in the audit log. To enable this, the users performing these actions must be granted a ZITADEL manager role.

Noteworthy

As ZITADEL includes unlimited users, projects, and applications and comes with all security features in the FREE tier, ZITADEL can be considered a great alternative to other SaaS IAM systems such as Auth0 or Okta. In such a case with this high potential of scalability where user counts can grow explosively, ZITADEL does not become the bottleneck and therefore is the valid choice. You can learn more on ZITADELs benefits and the pricing here.