In a B2B product, identity is shared across a platform but administration is not. A tenant administrator may need to manage their own members and groups without gaining platform-wide authority. A central administrator may configure identity infrastructure while still respecting the tenant boundaries applied to customer data and access.
- Resolve identity
- Resolve tenant context
- Authorise resource + action
- Record tenant-scoped outcome
Define the boundary in several places
Start with membership, groups and domains. Then ask how the boundary affects authentication, application assignments, resource authorization, provisioning and network policy. If a tenant can manage identity through SCIM or an integration, decide which credentials can perform those operations and which networks may call them.
Separate the roles
Customer users, tenant administrators, employees and platform administrators do not share the same trust level. The interface can make those differences visible, but authorization needs to enforce them on the operations and resources themselves.
Plan for change, not just onboarding
Map the normal lifecycle: a member joins, changes team, gains access, loses access or leaves. Also test exceptions such as an email-domain change, a tenant move or an administrator who should no longer control the tenant. Document which actions are automatic and which require review.
Evaluation prompt: Can you demonstrate that one tenant's administrator can manage the intended tenant resources without crossing into another tenant or platform-wide settings?
What to validate in a technical review
- Tenant ownership and membership rules.
- Groups, role assignments, scopes and resource-level access.
- SCIM and integration credentials, including network restrictions.
- Tenant-specific policy, custom attributes and domain-based mapping.
- Auditable changes to access and membership.
WebFrolic's documented product model includes tenant members, groups, domains, SCIM settings and network controls. The best next step is to choose one real tenant boundary and prove it end to end.
What a tenant administrator should be able to do alone
The test of a tenant model is how much your team has to do on a customer’s behalf. If every domain verification, SSO connection or role change needs a support ticket, the model is multi-customer rather than multi-tenant, and your operational cost grows with every account you win.
A workable boundary lets the customer’s own administrator manage members, configure SCIM, connect SAML or OAuth2, verify domains for automatic assignment, manage tenant groups and scopes, set assurance requirements, and apply network rules for their own users — without seeing anything belonging to another tenant.
Where isolation should be enforced
Isolation implemented in application code is isolation that has to be re-implemented correctly in every new endpoint. The safer position is that the identity model itself knows which tenant a record belongs to, so a query cannot accidentally cross the boundary because someone forgot a filter.
The same applies to administration. If a tenant administrator’s role is scoped at the platform level, there is no path through the interface that exposes another organisation’s data, regardless of what the request asks for.
What this comes down to
Document tenant-scoped and platform-wide operations.
Test cross-tenant access with each relevant persona.
Restrict provisioning and integration paths.
Audit membership, role and policy changes.