Tenants
The tenant as the isolation boundary: static or dynamic, its business status, its technical rollout, how it is resolved and admitted on every request, and how you switch between tenants.
Topics in this subject area
- 1.Static and dynamic tenants
A static tenant hangs on a user attribute, a dynamic one on a Keycloak organization. When each one fits.
- 2.The lifecycle of a tenant
Two separate states: the business standing (PENDING to CLOSED) and the technical rollout (NOT_PROVISIONED to PROVISIONED). When a tenant is served.
- 3.Create and provision a tenant
Store the intent, create and migrate the database, store the result. What happens in SINGLE, in MULTI and with a standalone CIAS.
- 4.The tenant key
Why the key cannot change, which characters are allowed, and that it is also the database name. How it is built during a self-registration.
- 5.Suspend and close tenants, validity
What suspending, resuming, activating, closing and a validity window do, and why there is no deleting.
- 6.Determine the tenant of a request
The six rules CIAS uses to determine the tenant from the token and header, with the results RESOLVED, NONE, AMBIGUOUS and CONFLICT.
- 7.Admit the tenant (tenant gate)
Resolving and admitting are two steps. How the gate asks, remembers for 30 seconds, answers from memory during an outage, and why unknown and suspended look the same.
- 8.Switch between tenants
Selecting among your own organizations without a special role, privileged switch with a role, user switch, and the fact that the tenant is admitted again after every switch.
- 9.In SINGLE the tenant in the token does not count
In the operating mode SINGLE the tenant in the token is ignored: no gate, no switch. Why this is so and why one switch carries two meanings here.
- 10.Working for a tenant without a request
How background work (timers, jobs) runs for a tenant, through the same gate, and which three places may set a tenant.