A new customer is set up

What this is about

Nordbau GmbH wants to use the application. Nobody sets anything up for them by hand: Anna Berg fills in a public form, and at the end there is a tenant nordbau-gmbh, an organization in Keycloak, a database and an account that can work in it.

This page plays the case through once, from front to back. For the details it links to the pages that describe each step on its own.

The parties

Who has which color is on The parties in a request.

The whole path

sequenceDiagram
    participant B as Anna
    participant C as CIAS
    participant K as Keycloak
    participant M as Email
    participant A as Platform admin
    participant P as Persistence
    B->>C: POST /cias/registration/self<br/>email, first name, last name, company "Nordbau GmbH"
    C->>C: throttle, validate fields, derive key nordbau-gmbh
    C->>K: create account disabled and unverified
    C->>M: confirmation mail with one-time link
    C-->>B: 202 accepted
    M-->>B: mail
    B->>C: clicks the link (POST /cias/registration/verify)
    C->>M: "your registration is being reviewed"
    Note over C,A: registration waits in PENDING_APPROVAL
    A->>C: POST /cias/admin/registrations/{id}/approve
    C->>K: mark address verified, enable account, require password
    C->>K: create organization nordbau-gmbh
    C->>P: create tenant, provision database
    P-->>C: done
    C->>K: Anna becomes a member of the organization
    C->>K: set attributes tenant and allowedTenants
    C->>K: grant initial roles in the organization
    C->>C: record the user, registration COMPLETED
    C->>M: welcome mail, with a password link where possible

Block 1: the person proves her address

Details: Self-registration, Verify the email, The tenant key.

Block 2: a human approves

A public form that creates tenants creates them at whatever rate it is called. That is why cias-runtime ships with approval switched on (CIAS_SELF_SERVICE_APPROVAL).

CIAS does not mail administrators when something is waiting for approval. The administration screen polls the list. Details: Approval by an administrator.

Block 3: everything comes into being at once

If one of these steps fails, the registration ends in FAILED. A platform administrator then repeats it with retry or discards it with discard. Details: What happens on completion.

The two state sequences side by side

Registration and tenant have their own states. They are connected, but they are not the same thing. A registration is a process that ends; a tenant is a customer that stays.

So the tenant comes into being only in the last block and is ACTIVE moments later. It is served as soon as its standing is ACTIVE and today’s date is inside its validity window. Every state on its own: The states of a registration and The lifecycle of a tenant.

The password and the first login

CIAS never sees a password. The welcome mail carries a link to Keycloak’s own password page; where no link can be issued, the mail points at the login instead and Anna uses “forgot password” there.

Details: Set the password, Sign in in the browser, Resend the password setup link.

The first request to CDMS

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

What the founder can do – and what the installation has to set up for it

The initial roles are not fixed code, they are a rule set. What the founder can do on day one therefore depends on what the installation wrote into that rule set.

So the founder can run her tenant on her own from day one. If she should also work with the data, the installation writes an installation rule for the situation TENANT_FOUNDER with the model roles and records the matching delegations in the role catalog. Both are deliberate decisions of the platform, not a side effect of the registration.

Details: Initial roles as a rule set, Grant a role, The role catalog, The ceiling.

The variants

Watch out

Next

• Self-registration
• What happens on completion
• Create and provision a tenant
• A colleague is invited