Skip to content

Users

You want a person to be able to sign in to the applications registered against your domain. On AWS that is an IAM user, or a Cognito user in a pool. Here it is a user in your identity domain.

Creating a user is quick. Two fields on the form have consequences that outlast the first day, and this page is about those two.

Prerequisites

The step-by-step guide and the console walkthrough cover the operations. The rest of this page explains how it fits together.

How it fits together

flowchart TB
    subgraph P["your project"]
        direction TB
        RE["KeycloakRealm<br/>your domain"]
        U["KeycloakRealmUser"]
        G1["group: support"]
        G2["group: engineering"]
        SEC["Secret<br/>&lt;user&gt;-initial-password<br/>only if you set one"]
        RE --> U
        U -->|groups| G1
        U -->|groups| G2
        U -.->|passwordSecret| SEC
    end
    U -->|signs in to| APP["your applications"]

The user object carries its group membership. That is why groups are what decide access, and why they are worth creating first.

Decision one: groups

A user in no groups can sign in and reach nothing. That is a reasonable starting point but rarely what was meant.

Tick every group the person belongs to on the create form - it is one tick each there, and a separate edit per person afterwards.

Decision two: the first password

flowchart TB
    Q{"set an initial<br/>password?"}
    Q -->|no, the default| R["account created without one<br/>they use the domain's recovery route<br/>no password passes through you"]
    Q -->|yes| S["Secret in the project<br/>named after the user"]
    S --> T{"require change<br/>on first login?"}
    T -->|yes, the default| OK["your password stops working<br/>as soon as they use it"]
    T -->|no| RISK["a permanent password<br/>readable by anyone who can<br/>read secrets in the project"]

Leaving it off is the better choice: no password ever passes through you.

If you do set one, keep the change-on-first-login box ticked

The password is stored in a Secret in the project either way. It is not shown again on the page, but anyone who can read secrets there can read it - which is exactly why a short-lived one is safer than a permanent one.

Delete the Secret once they have signed in and changed it. It has no further use, and it is one more place the password exists.

Email is asserted, not verified

Setting an email here marks it as verified, because you are asserting it rather than asking the person to confirm it. Only enter an address you know is theirs.

Prefer disabling to deleting

When someone leaves, clearing enabled stops sign-in immediately while keeping their history and group membership intact. Deleting erases them. The username cannot be changed either way.