What this is about
Once the address is verified and, if needed, the registration is approved, provisioning starts. Only now is everything created that the person needs to work: an enabled account, a tenant, a membership, roles. At the end comes the welcome email.
The steps
-
1CIASdetermines the initial roles from the rule set; after that, hooks may change them (
onAssignInitialRoles) -
2CIAS→Keycloakchecks that each of these roles existsone is missing:
FAILED -
3CIAS→Keycloakonly for a new account: mark the address as verified, enable the account, require “set password”
-
4CIAS→Keycloaktenant: create a new one or assign an existing one, see below
-
5CIAS→Keycloakgrants the initial roles, in the tenant or globally
-
6Hook
onCompleted: CIAS creates the user record and adds the person to default groups, plus your own hooks -
7CIASregistration →
COMPLETED -
8CIAS→Emailwelcome email, for a new account ideally with a link to set the passwordResult: The person can sign in
The welcome email is the last step. If only the email fails, the registration is still completed.
The tenant in the variants
When: Assignment CREATE_NEW, for example in self-registration.
-
1CIAS→Keycloakcreates the organization: alias = tenant key, name =
companyfield -
2CIAScreates the tenant, kind
DYNAMIC, with a reference to the organization. With MULTI, the tenant's database is also provisioned in this step -
3CIAS→Keycloakmakes the person a member of the organization
-
4CIAS→Keycloaksets the attributes
tenantandallowedTenantson the account
Result: The person is the founder of the new tenant. Roles of the TENANT_FOUNDER situation.
When: The tenant has no organization.
CIAS sets the attributes tenant and allowedTenants on the account. Nothing more is needed: for a static tenant, the attribute is the membership. The roles are granted globally.
Result: Roles of the TENANT_MEMBER situation.
When: The tenant has an organization in Keycloak.
CIAS sets the attributes and makes the person a member of the organization. The roles are granted in the organization and so end up in the token's organization claim.
Result: Roles of the TENANT_MEMBER situation.
When: Assignment NONE.
No tenant, no membership. The roles are granted globally.
Result: Roles of the TENANTLESS situation.
CIAS checks in this step whether an existing tenant exists. If it does not, the registration ends in FAILED.
When something goes wrong
| What fails? | Consequence |
|---|---|
| an initial role does not exist | FAILED. Create the role, then retry |
| Keycloak not reachable | FAILED, response 503. retry later |
| the named tenant does not exist | FAILED. Create the tenant or discard the registration |
| one of your own hooks throws an exception | FAILED. Fix the cause, then retry |
| a rule for the initial roles cannot be evaluated | FAILED. Repair the rule, then retry |
| the tenant key now belongs to another tenant | FAILED, response 422 cias.registration.tenant-key-taken. Discard the registration |
| only the welcome email | COMPLETED, the email is missing |
With FAILED, the request that triggered provisioning gets an error: the click on the link or the approval. The person themselves gets no email. A platform administrator finds the registration in the list with state=FAILED and can repeat it with retry or discard it with discard. See Approval by an administrator.
New tenant: retrying and taking back
Creating a new tenant (CREATE_NEW) produces things a second attempt already finds. So the registration remembers the organization it created in Keycloak as soon as it exists.
retrycontinues. It takes the remembered organization and the tenant attached to it instead of creating both a second time. If only the tenant’s provisioning failed, it starts that again.- Nothing foreign is adopted. The tenant key is checked at registration but not reserved. If an organization the registration did not create now sits under it,
retryrefuses. Otherwise the founder would become the owner of a stranger’s tenant. discardtakes things back. See Cleanup.