Modeling our hierarchy (Client Org -> Dept -> User)
Hello Identity,
I am willing to build a centralized Identity and Authorization Service (IdP) for a set of three B2B applications we developed internally in our small company.
My requirements:
1. We serve multiple external client companies (our "Clients").
2. Each Client has one or more Departments, and users belong to one Department.
3. Our internal team would manage all user and group administration via the IdP console. Clients are not allowed to administer their own users in the IdP.
How I plan to use Zitadel:
Since we are managing everything centrally, I plan to use a single Organization in the Zitadel instance (our instance's root organization). I will model the Client hierarchy using named groups or roles to maintain separation:
* Client Organization: Modeled as a Parent Group (e.g.,
* Department: Modeled as a Subgroup/Role (e.g.,
If we have 1,000 clients, this implies we will have at least 1,000 basic client separation Groups/Roles (
1. Is this approach (using thousands of resource-based Groups/Roles, e.g.,
2. Zitadel's native multi-tenancy focuses on creating one Organization per client. Since we cannot use this model due to our centralized administration requirement (at least based on my understanding), is the reliance on Groups and Roles the only viable alternative to model the Client hierarchy effectively?
Thank you for your insights!
I am willing to build a centralized Identity and Authorization Service (IdP) for a set of three B2B applications we developed internally in our small company.
My requirements:
1. We serve multiple external client companies (our "Clients").
2. Each Client has one or more Departments, and users belong to one Department.
3. Our internal team would manage all user and group administration via the IdP console. Clients are not allowed to administer their own users in the IdP.
How I plan to use Zitadel:
Since we are managing everything centrally, I plan to use a single Organization in the Zitadel instance (our instance's root organization). I will model the Client hierarchy using named groups or roles to maintain separation:
* Client Organization: Modeled as a Parent Group (e.g.,
ORG:CLIENT_AORG:CLIENT_A).* Department: Modeled as a Subgroup/Role (e.g.,
DEPT:CLIENT_A:FINANCEDEPT:CLIENT_A:FINANCE).If we have 1,000 clients, this implies we will have at least 1,000 basic client separation Groups/Roles (
ORG:CLIENT_1ORG:CLIENT_1 to ORG:CLIENT_1000ORG:CLIENT_1000), multiplied by the number of departments per client.1. Is this approach (using thousands of resource-based Groups/Roles, e.g.,
ORG:CLIENT_XORG:CLIENT_X) the standard and most scalable way to model a centrally-administered B2B hierarchy in Zitadel?2. Zitadel's native multi-tenancy focuses on creating one Organization per client. Since we cannot use this model due to our centralized administration requirement (at least based on my understanding), is the reliance on Groups and Roles the only viable alternative to model the Client hierarchy effectively?
Thank you for your insights!
