Registration
How a person becomes a user: one flow with four variants, email verification, password at Keycloak, approval, tenant assignment, initial roles, hooks and emails.
Topics in this subject area
- 1.One flow, four variants
Self-registration, creation by the platform administrator, invitation by the tenant administrator, and redeeming the invitation: what stays the same and what differs.
- 2.The states of a registration
From INITIATED to COMPLETED: every state, every transition, and where EXPIRED and FAILED come from.
- 3.Self-registration
A person registers without signing in, through the public form. The full flow with approval and a new tenant.
- 4.Creation by the platform administrator
The platform administrator creates a person and is the only one allowed to name the tenant in the payload.
- 5.Invitation by the tenant administrator
A tenant administrator invites a person into their own tenant. The tenant always comes from their token, never from the payload.
- 6.Redeem an invitation
What the invited person sees and does: fetch the open fields, redeem the link, membership.
- 7.The email is the account
One account per address, any number of tenants. What happens when a known address registers, and why nobody is added to a tenant without consent.
- 8.Verify the email
CIAS creates the account disabled, sends its own email with a one-time link, and enables the account only after the click. How the link is protected.
- 9.Set the password
CIAS never sees a password. How the person sets their password at Keycloak after verification, and what happens without a password setup link.
- 10.Approval by an administrator
When a registration needs approval: approve, reject, retry, discard.
- 11.Where the tenant comes from
The six kinds of tenant assignment and the order in which policy and hook decide.
- 12.What happens on completion
Provisioning in a fixed order: determine initial roles, enable the account, create or assign the tenant, grant roles, welcome email.
- 13.Initial roles as a rule set
Which roles a new person gets is decided by a rule set per situation (founder, member, without tenant). Who may write rules and why the tenant rule replaces instead of adds.
- 14.Your own logic: hooks and events
Hooks run inside the registration and may reject it, events follow afterwards. All hook points and what a hook must not do.
- 15.Protecting the public endpoints
Why self-registration always returns the same answer, why invalid links look the same, and how throttling works.
- 16.Clean up abandoned registrations
How waiting registrations are set to EXPIRED after their deadline, unused accounts are deleted, and old registrations are removed.