One value per person or per tenant

What this is about

Anna works for two tenants: nordbau and suedlogistik. In nordbau she is responsible for the region North, in suedlogistik for South. A single value region on the account cannot express that. Which value should it have?

That is why every attribute states at registration what it says something about:

How an attribute becomes per tenant

The module says so at registration, see Registering attributes:

Attribute.optional("region").asMultivalued().perTenant()

Only the registering module knows what it means: CIAS sees that an attribute is called region, but not whether an installation gives a person different regions in two tenants. What CDMS generates from the model is always USER, see Two origins of attributes. A module writes an attribute per tenant into its registration itself.

You write the values via POST /cias/admin/users/{id}/tenant-attributes?tenantKey=…, checked by delegation and ceiling, see Who may write an attribute. This works only for attributes the catalog lists per tenant. CIAS refuses a USER attribute such as locale there, even for a platform administrator.

The scenario

Before and after

flowchart LR
    subgraph T["In Anna's token"]
      TR["region: nord, sued<br/>(one value for the whole account)"]
      TL["locale: de"]
    end
    subgraph C["In CIAS, tenant suedlogistik"]
      CR["region: sued"]
    end
    subgraph E["Effective in suedlogistik"]
      ER["region: sued"]
      EL["locale: de"]
    end
    CR -- "replaces" --> ER
    TL -- "unchanged" --> EL
    TR -. "is replaced" .-> ER

The value from CIAS replaces the value from the token for this key. All other attributes, such as locale, come unchanged from the token. That holds even if CIAS does keep a row for such a key in the tenant: only what the application itself registers with perTenant() is replaced. If CIAS mixed them, the filter in one tenant would be wider than in either one alone, which is exactly what this prevents.

The variants

Where the values come from

CIAS caches the answer per person and tenant for 30 seconds, configurable with codamai.cias.attribute-lookup.ttl. The number of cached pairs is limited by codamai.cias.attribute-lookup.max-entries. So the lookup costs at most one call per person, tenant and half minute. An installation without an attribute per tenant never asks.

A request without a tenant, for example in operating mode SINGLE, has no values per tenant. There the value from the token applies.

Pitfalls

Next

• Who may write an attribute
• Attribute filter
• Effective roles: global or in the tenant