| title |
|---|
B2B |
import { B2B } from '../../../src/components/b2b';
B2B describes the situation where an organization interacts with another organization. This multiple organization architecture (Multitenancy) usually adds some complexity to an Identity and Access Management System. In ZITADEL an organization represents a group, business customer or partner who typically has its own branding and has different access settings like an additional federated login for its users.
As a B2B use case you could have a simple scenario where an organization only shares one of its projects with another organization or have a more complex case where an organization is offering a portal application to all its partners with included administration.
Octagon is a fictitious company which is 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 machine users only.
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 organization within Octagon or for Octagon itself. Some have enhanced features because they are supervisors of a team. Those can onboard new employees and manage their roles and features. Target groups of the application can be split into:
- Employes: 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: this users are able to grant additional organizations or departments and elect supervisors.
In order 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 in 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 certan features of the application?
You can decide whether a organization is preselected for the login or if the user is redirected to the default login screen. You can send the user to a specific organization by defining the organization in a custom scope. Settings to the branding or the login options of the organization can be made from the organization section in Console. The behaviour of the login branding can be set in your projects detail page. You can choose the branding of the selected organization, the user resource owner, or the projects resource owner.
A user in general can be isolated to an organization, or be shared across multiple organizations. Anyways, a user should be able to use the same identity to switch between organizations. If this feature is not desired, a seperate 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 adding a new user authorization (user grant). A user grant combines a user from any organization with a project and 0-N roles.
In our sample scenario, we assume to have the following users:
- Dimitri: a team leader who is employed by Hexagon, an Octagon department. Dimitri uses his Microsoft Account in combination with his one time password to access the portal. Hexagon therefore has set up Microsoft as Identity Provider. Hexagon also requires its users to secure their accounts with additional factor.
- Michael: a trainee of Hexagon only using the portal to access his workspace apps. Michael uses his Google Account in combination with is his laptops fingerprint.
- Bill: is employed at Octagon as Administrator of the Portal Application. Dimitri too 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 in our Example Repo.
To allow an other 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 projectroles.
In our scenario, Octagon creates a project grant for Hexagon. Hexagon is limited to use writer and reader role. The admin role is reserved for the Octagon organization itself.
In our scenario, Dimitri and Michael share the same organization Hexagon, where as Bill belongs to Octagon. Octagon is owner of the Portal project with its Web App, having Bill configured as user grant with admin role. Dimitri ownes the writer role, whereas Michael only is reader.
Note: Roles are meant for internal business logic and therefore need to be validated seperately, None of the users described are allowed to create user grants, at least if they do not own a ZITADEL manager role.
If you made a dashboard where some users are able to create user grants, the Management API to do such operations should be triggered with the personal access token of the users, not with a token of a machine user, to create a meaningful audit log. If you had such a usecase, ZITADEL manager roles must be assigned to those users.
Due to the fact that ZITADEL is unlimited in users, projects, and applications and comes with all security features in FREE tier, ZITADEL can be considered as better alternative to other SaaS IAM systems such as Auth0 or Keycloack. In such a use case with this high potential of scalability where user counts can grow explosively, ZITADEL does not become a bottleneck and therefore is the safer choice. You can learn more on ZITADELs benefits and the pricing here.