One person in two tenants

What this is about

Clara consults for two customers: nordbau and suedlogistik. She has one account and one password. Still, none of her requests may mix the data of the two customers.

CIAS solves that by having every single request run under exactly one tenant. Which one it is, is decided afresh before every request – and the roles and the attribute values that apply to that one request hang off it.

The picture

flowchart TB
    K["One account in Keycloak<br/>clara@example.example"]
    K --> T["One token:<br/>organization: nordbau, suedlogistik<br/>roles per organization<br/>realm roles<br/>profile attributes"]
    T --> R{"Which tenant<br/>for this request?"}
    R -- "header tenant: nordbau" --> N["request in nordbau<br/>roles from nordbau<br/>values for nordbau"]
    R -- "header tenant: suedlogistik" --> S["request in suedlogistik<br/>roles from suedlogistik<br/>values for suedlogistik"]
    N --> ND[("database nordbau")]
    S --> SD[("database suedlogistik")]

How Clara ends up in two tenants

There are two shapes, and they behave differently:

The first is called selection, the second a privileged switch. The difference is not cosmetic: selection happens during tenant resolution, the switch only after it. And the roles are determined in between.

How the choice is made

The filter chain reads the header tenant before the token, because the chosen organization decides which roles apply. Then it works through the rules in order.

Every rule in detail: Determine the tenant of a request and Switch between tenants.

Which roles apply in each tenant

Roles can sit in two places in the token: globally and inside an organization. From those CIAS builds the effective roles on every request.

In Clara's token:

global (resource_access):      report-read
organization nordbau:          order-read, order-edit
organization suedlogistik:     order-read
realm_access:                  user

Effective in nordbau:          order-read, order-edit   (+ realm: user)
Effective in suedlogistik:     order-read               (+ realm: user)

report-read falls away in both tenants. That is deliberate: if Clara has any role in her active, dynamic tenant, the roles of that tenant replace the global client roles. Nobody granted a globally granted role for this one customer, so it does not apply there. Realm roles, by contrast, always apply, in every tenant.

With a privileged switch it works differently: there Clara carries her own roles into the target. Roles somebody has in the target tenant she does not get. Details: Effective roles: global or in the tenant.

Which attribute values apply in each tenant

An attribute is a fact about a person that reaches the token as a claim and that CDMS uses to filter rows. On declaration, every module says what the attribute is about:

For an attribute with USER_IN_TENANT, CIAS asks on every request for the values it holds for Clara in the active tenant.

On the account (token): region = nord, sued
In CIAS, nordbau:       region = nord
In CIAS, suedlogistik:  region = sued

Effective in nordbau:      region = nord
Effective in suedlogistik: region = sued

If CIAS cannot fetch the values and has no buffered value either, it refuses the request instead of falling back to the token’s value: 403 cias.authentication.tenant-not-served. CIAS keeps the answers per person and tenant for 30 seconds.

What does not differ per tenant

The home tenant in the CIAS user record is therefore no statement about which tenant a request runs in. That is always decided by the token. See The user record.

The path of a request, shortened

The full path is described by From login to the data.

Watch out

Next

• Determine the tenant of a request
• Switch between tenants
• One value per person or per tenant
• A colleague is invited