OIDC πͺͺΒΆ
This page describes how application roles consume the platformβs OIDC provider, Keycloak.
The variable tree lives in 11_oidc.yml under defaults_oidc.
For the cross-cutting IAM principles, including the paired identifier rule shared with LDAP, see common.md.
For LDAP-side details see ldap.md.
Variable Tree π³ΒΆ
The OIDC tree is a lazy group_var: it resolves in the consuming roleβs
context, so the issuer family-aligns to that consumer (clearnet page β
clearnet issuer, onion page β onion issuer). Inventory overrides therefore
live under OIDC_OVERRIDE: β an inventory-level OIDC: block would shadow
the lazy resolution and is rejected by a constructor assert.
The keys consumers care about:
Key |
Meaning |
|---|---|
|
Base URL of the Keycloak instance |
|
Client identifier, defaults to |
|
Client secret, MUST come from the inventory ( |
|
Realm the client is registered in |
|
Issuer URL, equal to discovery |
|
|
|
Authorization endpoint |
|
Token endpoint |
|
Userinfo endpoint |
|
RP-initiated logout endpoint |
|
JWKS endpoint, equal to discovery |
|
User self-service console root |
|
Personal-info section deep link |
|
Login and security section deep link |
|
Direct link to the credentials editor |
|
Public password-reset entry point |
|
Default label for SSO login buttons |
When a role needs an OIDC endpoint, it MUST template the corresponding OIDC.CLIENT.* value rather than build the URL from OIDC.URL itself.
The URL builders in 11_oidc.yml already handle realm and protocol concerns.
Claim Attributes π·οΈΒΆ
OIDC.ATTRIBUTES lists the claim names that downstream applications read out of the userinfo response and ID token:
Key |
Default value |
Meaning |
|---|---|---|
|
|
Stable user identifier |
|
|
First name |
|
|
Last name |
|
|
Email address |
Rules:
Application roles MUST identify users via
OIDC.ATTRIBUTES.USERNAME. They MUST NOT introduce a private claim name (for exampleuser_id,uid, oroauth_uid) whenpreferred_usernamealready satisfies the requirement.Roles MUST NOT hardcode the literal value
preferred_username. Always template{{ OIDC.ATTRIBUTES.USERNAME }}.The standard OIDC
subclaim is permitted as an alternative when the application explicitly requires a UUID-shaped identifier and stores its own mapping table. In that case the role MUST document the deviation in its README.The OIDC username claim is paired with the LDAP login attribute by design. See ldap.md for the LDAP-side rule.
Keycloak Client Templates π¦ΒΆ
Keycloak client definitions are imported from clients. The default template in default.json.j2 is shared by every application client.
Rules:
The shared
default.json.j2MUST stay generic. App-specific protocol mappers, claims, or scopes MUST NOT be added there because the change affects every other client.An app that needs an extra mapper MUST add it through a per-client scope. See nextcloud.json.j2 for the precedent: a dedicated scope holds the Nextcloud-specific UID and quota mappers and is attached only to the Nextcloud client.
New scope files MUST be referenced from the consuming app via its
KEYCLOAK_RBAC_GROUP_CLAIMstyle configuration or via theoptionalClientScopeslist in the client template.
Consumer Pattern π§©ΒΆ
A typical OIDC-consuming role wires the values into its environment template, for example env.j2:
OIDC_ISSUER={{ OIDC.CLIENT.ISSUER_URL }}
OIDC_DISCOVERY=true
OIDC_SCOPE=openid,profile,email
OIDC_UID_FIELD={{ OIDC.ATTRIBUTES.USERNAME }}
OIDC_CLIENT_ID={{ OIDC.CLIENT.ID }}
OIDC_CLIENT_SECRET={{ OIDC.CLIENT.SECRET }}
Every application role SHOULD follow the same shape: discovery on, the OIDC.CLIENT.* endpoints templated, the user identifier read from OIDC.ATTRIBUTES.USERNAME, and the scopes limited to what the app actually consumes.