Tenant, organization, group

What this is about

Three words come up again and again when talking about the structure of customers: tenant, organization and group. They sound like three things. In CIAS there are only two:

• The tenant separates data. What is in tenant A, nobody from tenant B can see.
• The group bundles roles. Whoever is a member gets all roles of the group.
• The organization is not a thing of its own. It is Keycloak’s name for a dynamic tenant.

The one question that decides

When someone says “we need an organization for X”, a single question helps:

flowchart TB
    Q{"Should these people be unable<br/>to see the others' data?"}
    Q -- "yes" --> T["Own tenant<br/>data separated"]
    Q -- "no" --> Q2{"Should they get<br/>the same roles together?"}
    Q2 -- "yes" --> G["Group<br/>a bundle of roles"]
    Q2 -- "no" --> N["individual<br/>role grants"]

Only a “yes” to the first question costs a tenant. A tenant is heavy: it gets its own data, often its own database, and every request runs under exactly one tenant. A group is light: it is only a list of roles and members.

The three terms side by side

The tenant

A tenant is a customer unit with its own, separated data. CIAS keeps it as its own record and is the only system that creates tenants. There are two types:

The type is set on the tenant, not on the installation. More under Static and dynamic tenants.

The organization

Keycloak has its own feature called “Organizations”. CIAS uses it to represent a dynamic tenant in Keycloak. That means:

• An organization is created when a company registers itself: CIAS then creates the organization and the dynamic tenant together. When a dynamic tenant is created through the admin API, the call names an organization that already exists. It has no life cycle of its own; it follows the tenant.
• There is no organization administration in CIAS, no table of its own and no endpoint of its own for organizations.
• In CIAS screens and APIs it is always called tenant. You only see the word “organization” in the Keycloak console, in the adapter and in the token, there as the claim organization.

The group

A group is a bundle of roles. Instead of giving every new colleague in support ten roles one by one, you create the group support once and make the colleague a member.

• A group may carry roles of several modules at once, such as CDMS and CRMS roles.
• A group applies platform wide. It is not assigned to a tenant.
• A group can be the default group: every new account joins it.
• Being a member means: you get the roles. It does not mean that you see the data of other members.

More under What a group is. How client roles from a group behave under a dynamic tenant is described under Group roles under dynamic tenants.

No parents and children

A tenant has no parent tenant, and an organization has no sub-organization. This is on purpose. A tenant is a line of separation. If it had children, each of these three questions would need a fixed answer:

1. If the parent tenant is suspended, are the children suspended too?
2. Do the roles from the parent tenant also apply in the children?
3. Does the parent tenant see the children’s data?

Every answer would be a security decision. That is why there is no tenant hierarchy. Every tenant stands on its own.

Scenario: two companies, one application

Two customers use the same application: Nordbau GmbH and Südlogistik AG. Neither may see the other’s data.

What applies now:

The group gave Anna and Ben the same permissions. The tenant makes sure they use these permissions on different data. The shared group does not connect the two.