Multi-Tenancy Entity Model
Wristband's architecture enforces a strict hierarchical tenancy model.
To better leverage Wristband, it is important to understand the different types of entities you can interact with that represent the core of the platform. Those core entities are:
- Applications
- Tenants
- OAuth2 Clients
- Identity Providers
- Users
Entity Hierarchy
The backbone of the Wristband entity hierarchy consists of: Applications > Tenants > Users.
Each tenant in Wristband has a unique tenant identifier (tenantId). Users must always be assigned to a tenant, and a single user cannot belong to multiple tenants, ensuring complete isolation and tenant-specific control over users.
Tenants and User Uniqueness
There are 3 fields within User entities that must be unique within a tenant:
emailusernameexternalId
User Uniqueness in a Tenant
Users in the same tenant can have the same email, username, and externalId values as long as they are provisioned in different identity providers.
For example, if Tenant A has a user with email [email protected] in the Wristband identity provider, creating another user with the same email in the same provider will fail due to a uniqueness violation.
However, creating another user with the same email in the Google Workspace identity provider will succeed, as they are distinct entities.
User Uniqueness Across Tenants
Users with the same email can exist in different tenants, even within the same identity provider. For instance, creating a user with [email protected] in Tenant B's Wristband identity provider will succeed, even if it exists in Tenant A.
Updated about 1 month ago