Administrer Keycloak : realms, users, roles

Ce guide vous apprend à administrer Keycloak via la console web. Après l'installation Docker (K1-01), vous allez créer un realm, gérer des utilisateurs dans des groupes, assigner des rôles et configurer un client. Ces compétences sont le socle de tous les guides suivants.

Prérequis

• K1-01, Installation Docker terminée
• Keycloak accessible à http://localhost:8080
• Identifiants admin créés lors de l'installation

Ce que vous allez apprendre

À la fin de ce module, vous saurez :

• Naviguer efficacement dans l'admin console
• Créer et configurer des realms
• Gérer les utilisateurs et leurs credentials
• Organiser les utilisateurs en groupes hiérarchiques
• Créer et assigner des rôles (realm et client)
• Configurer un client basique
• Surveiller les sessions actives et les events

Accéder à la console d'administration

Ouvrez http://localhost:8080 et cliquez sur Administration Console.

Connectez-vous avec les identifiants créés lors de l'installation :

• Username : admin
• Password : celui défini dans KC_BOOTSTRAP_ADMIN_PASSWORD

Navigation dans la console

La zone qui compte le plus dans ce tableau est le realm selector. Toutes les autres sections affichent le contenu du realm actif sans le rappeler : créer un utilisateur en croyant travailler sur lab alors que le sélecteur affiche encore master est l'erreur la plus fréquente des premiers jours. Prenez le réflexe de vérifier le nom affiché en haut à gauche avant chaque création d'objet.

Zone	Description
Realm selector (en haut à gauche)	Bascule entre les realms disponibles
Menu latéral	Accès aux différentes sections (Clients, Users, Groups, etc.)
Zone principale	Formulaires de configuration et listes
Breadcrumb	Navigation hiérarchique dans la configuration

Glissez pour voir

Chercher dans une liste

La console d'administration n'a pas de recherche globale. Chaque écran de liste (Users, Clients, Groups, Realm roles) possède son propre champ de recherche en haut du tableau. Sur l'écran Users, la liste peut rester vide tant que vous n'avez pas lancé une recherche : saisissez * pour afficher tous les comptes.

Comprendre les Realms

Un realm est un espace isolé de gestion des identités. Chaque realm possède ses propres :

• Utilisateurs et groupes
• Rôles et permissions
• Clients (applications)
• Configurations de login
• Tokens et sessions

Realm master vs realms applicatifs

Le realm master est créé au premier démarrage et contient le compte d'administration de l'instance. Un compte de ce realm peut administrer tous les autres realms : y ajouter vos utilisateurs finaux revient à leur donner un pied dans la console d'administration. La séparation ci-dessous n'est donc pas une convention de nommage, c'est une frontière de privilèges.

Realm	Usage	Utilisateurs
master	Administration de Keycloak lui-même	Super-admins uniquement
Realms applicatifs	Applications et utilisateurs finaux	Utilisateurs de vos apps

Glissez pour voir

Bonne pratique

Ne jamais utiliser le realm master pour les applications. Le realm master est réservé aux super-admins de Keycloak.

Créer un realm applicatif

Le nom du realm apparaît dans toutes les URL publiques de Keycloak (/realms/<nom>/...) et vos applications le porteront dans leur configuration. Le renommer plus tard casse chaque client déjà configuré, choisissez-le donc au moment de la création, en minuscules et sans espace.

1. Connectez-vous à la console admin
2. Cliquez sur le realm selector (en haut à gauche, affiche "master")
3. Cliquez sur Create realm
4. Renseignez les informations :
   • Realm name : lab (en minuscules, sans espaces)
   • Enabled : On
5. Cliquez sur Create

Vous êtes automatiquement basculé sur le nouveau realm.

Configurer un realm

Les quatre onglets ci-dessous correspondent aux onglets réels de l'écran Realm settings. Les deux qui changent le comportement visible par vos utilisateurs sont Login (ce que la page de connexion propose) et Sessions (au bout de combien de temps ils sont déconnectés). Les valeurs indiquées sont celles d'un realm de formation : en production, la durée de vie des access tokens se raccourcit et Verify email passe à On.

General

Paramètre	Valeur recommandée	Description
Display name	Lab Formation	Nom affiché aux utilisateurs
HTML Display name	<b>Lab</b> Formation	Avec HTML pour le branding
Frontend URL	(vide en dev)	URL publique en production

Glissez pour voir

Login

Paramètre	Valeur Lab	Description
User registration	Off	Les admins créent les comptes
Forgot password	On	Permet la récupération de mot de passe
Remember me	On	Case "Se souvenir de moi"
Login with email	On	Email comme identifiant
Verify email	Off	Pas de vérification en dev

Glissez pour voir

Sessions

Paramètre	Valeur	Description
SSO Session Idle	30 minutes	Timeout d'inactivité SSO
SSO Session Max	10 hours	Durée max d'une session SSO
Access Token Lifespan	5 minutes	Validité du token d'accès
Refresh Token Lifespan	30 minutes	Validité du refresh token

Glissez pour voir

Tokens

Paramètre	Valeur	Description
Default Signature Algorithm	RS256	Algo de signature des tokens
Access Token Lifespan	5 minutes	Durée de vie des access tokens
Client login timeout	5 minutes	Timeout pendant le flow login

Glissez pour voir

Sauvegarde

Cliquez sur Save après chaque modification. Keycloak ne sauvegarde pas automatiquement.

Gérer les utilisateurs

Les utilisateurs sont des identités qui peuvent se connecter à vos applications.

Utilisateurs locaux vs fédération LDAP

Dans ce module, vous créez des utilisateurs locaux directement dans Keycloak. C'est approprié pour :

• Environnements de développement et formation
• Petites équipes sans annuaire existant
• Comptes admin ou techniques

En production avec un annuaire existant (LDAP, Active Directory), privilégiez la fédération, les utilisateurs restent dans l'annuaire, Keycloak les synchronise. Cette approche est détaillée dans Fédérer un annuaire LDAP ou AD avec Keycloak.

Créer un utilisateur

Le seul champ réellement obligatoire est Username, et il est unique dans le realm : deux realms peuvent héberger un alice sans conflit. Le compte créé ici n'a ni mot de passe ni rôle, il ne peut donc pas encore se connecter. C'est normal, la suite du guide comble ces deux manques.

1. Dans le menu, cliquez sur Users
2. Cliquez sur Add user
3. Renseignez les informations :
   • Username : alice (obligatoire, unique dans le realm)
   • Email : alice@example.com
   • First name : Alice
   • Last name : Martin
   • Enabled : On
4. Cliquez sur Create

Configurer les credentials

Un utilisateur créé n'a pas encore de mot de passe. L'interrupteur décisif de cet écran est Temporary : laissé sur On, Keycloak ajoute automatiquement l'action requise UPDATE_PASSWORD au compte, et l'utilisateur devra choisir son propre mot de passe à la première connexion. C'est le réglage à conserver dès que c'est un administrateur qui saisit le mot de passe d'un tiers, sinon vous connaissez le secret de votre utilisateur.

1. Après création, allez dans l'onglet Credentials
2. Cliquez sur Set password
3. Renseignez le mot de passe deux fois
4. Temporary :
   • On = l'utilisateur devra le changer à la première connexion
   • Off = mot de passe permanent
5. Cliquez sur Save

Attributs utilisateur

Les attributs permettent de stocker des métadonnées sur l'utilisateur, dans l'onglet Attributes, sous forme de paires clé/valeur. Retenez qu'un attribut ajouté ici ne sort pas tout seul de Keycloak : il reste dans la base tant qu'un mapper de client ne l'a pas explicitement recopié dans le token. Les exemples ci-dessous sont ceux que les applications réclament le plus souvent pour prendre une décision d'autorisation ou remplir un profil.

Attribut	Exemple	Usage
department	Engineering	Département de l'entreprise
employee_id	EMP-001	Identifiant RH
phone	+33612345678	Numéro de téléphone

Glissez pour voir

Ces attributs peuvent être inclus dans les tokens via les mappers (voir K2-01).

Required Actions

Les required actions forcent l'utilisateur à effectuer une action à la prochaine connexion. Elles se posent sur un compte précis depuis l'onglet Details, section Required User Actions, et Keycloak interrompt le flux de login tant que l'action n'est pas faite. C'est le levier à utiliser pour imposer le MFA à une poignée de comptes sensibles sans l'activer pour tout le realm, ou pour forcer la mise à jour d'un mot de passe après un incident.

Action	Description
UPDATE_PASSWORD	Changer le mot de passe
VERIFY_EMAIL	Vérifier l'adresse email
UPDATE_PROFILE	Compléter le profil
CONFIGURE_TOTP	Configurer le MFA (TOTP)

Glissez pour voir

VERIFY_EMAIL suppose qu'un serveur SMTP soit configuré dans Realm settings > Email : sans lui, l'utilisateur se retrouve bloqué devant un écran qui attend un courriel qui ne partira jamais.

Organiser avec les groupes

Les groupes permettent d'organiser les utilisateurs et de leur assigner des attributs et rôles de manière groupée.

Hiérarchie des groupes

Les groupes peuvent être imbriqués. Un utilisateur dans un sous-groupe hérite des attributs et des rôles du groupe parent, et l'héritage descend toujours dans ce sens : appartenir à Employees/Engineering/Backend donne aussi ce que porte Employees, jamais l'inverse. L'arborescence ci-dessous illustre ce que cela donne pour une organisation classique.

Employees/
├── Engineering/
│   ├── Backend/
│   └── Frontend/
├── Marketing/
└── Sales/

Placez donc les droits les plus larges au sommet (Employees) et n'ajoutez dans les feuilles que ce qui est réellement spécifique. Un droit posé trop haut se propage à toute l'entreprise sans que personne ne s'en aperçoive.

Créer une hiérarchie de groupes

Un sous-groupe ne se crée pas depuis l'écran racine : il faut d'abord ouvrir le groupe parent, puis relancer Create group depuis l'intérieur. C'est la seule subtilité de cette manipulation, et celle qui fait qu'on se retrouve avec Engineering à côté de Employees au lieu d'être dedans.

1. Dans le menu, cliquez sur Groups
2. Cliquez sur Create group
3. Name : Employees, puis Create
4. Cliquez sur le groupe Employees
5. Cliquez sur Create group (crée un sous-groupe)
6. Name : Engineering, puis Create
7. Répétez pour Marketing et Sales

Assigner un utilisateur à un groupe

L'adhésion se pose depuis la fiche de l'utilisateur, pas depuis le groupe. Sélectionnez toujours le chemin complet (Employees/Engineering) et non le nom court : deux sous-groupes portant le même nom sous des parents différents sont parfaitement légaux dans Keycloak, et la liste les affiche tous les deux.

1. Allez dans Users et sélectionnez un utilisateur
2. Cliquez sur l'onglet Groups
3. Cliquez sur Join group
4. Sélectionnez le groupe (ex: Employees/Engineering)
5. Cliquez sur Join

Après le Join, l'onglet Groups affiche l'adhésion directe. Les groupes hérités, eux, n'apparaissent que si vous cochez l'option Direct membership pour la décocher : c'est le moyen de vérifier ce que l'utilisateur reçoit réellement de la hiérarchie.

Attributs de groupe

Un attribut posé sur un groupe est hérité par tous ses membres, présents et futurs. C'est ce qui permet de ne plus saisir department compte par compte : le jour où une personne change d'équipe, changer son groupe met à jour toutes ses métadonnées d'un coup. Comme pour les attributs d'utilisateur, la valeur n'atteint le token que si un mapper est configuré côté client.

1. Allez dans Groups et sélectionnez un groupe
2. Cliquez sur l'onglet Attributes
3. Ajoutez un attribut : department = Engineering
4. Cliquez sur Save

Tous les membres du groupe auront cet attribut disponible dans leurs tokens (si un mapper est configuré).

Créer et assigner des rôles

Les rôles définissent les permissions des utilisateurs dans les applications.

Types de rôles

La distinction qui compte dans ce tableau est celle du scope. Un realm role décrit qui est la personne dans l'organisation (staff, manager), un client role décrit ce qu'elle a le droit de faire dans une application précise (app:read). Le composite role n'est pas un troisième type : c'est un realm role ou un client role auquel on a rattaché d'autres rôles.

Type	Scope	Exemple	Usage
Realm roles	Global au realm	admin, user	Permissions transverses
Client roles	Spécifique à un client	app:read, app:write	Permissions applicatives
Composite roles	Combine d'autres rôles	manager = user + app:read	Bundles de permissions

Glissez pour voir

Cette séparation évite le piège le plus courant : nommer un realm role facturation-admin alors qu'il ne concerne qu'une seule application. Le jour où une deuxième application arrive, plus personne ne sait à quoi le rôle donne accès.

Créer un realm role

Un nom de rôle est immuable en pratique : il finit dans les tokens et dans le code des applications qui le testent. Restez sur des minuscules sans espace, et remplissez la Description, c'est le seul endroit où vous pourrez expliquer dans six mois pourquoi ce rôle existe.

1. Dans le menu, cliquez sur Realm roles
2. Cliquez sur Create role
3. Role name : staff (minuscules, sans espaces)
4. Description : Employé de l'entreprise
5. Cliquez sur Save

Créez également les rôles manager et admin.

Créer un composite role

Un composite role regroupe plusieurs rôles pour n'en assigner qu'un seul. Il n'y a aucun interrupteur « Composite » à activer dans la console : un rôle devient composite au moment où vous lui rattachez un premier rôle associé, et la colonne Composite de la liste des rôles passe alors à True. Retirer tous les rôles associés le fait redevenir un rôle simple.

1. Ouvrez le rôle à transformer dans Realm roles (ex: manager)
2. Dans le menu Action en haut à droite, choisissez Add associated roles
3. Filtrez sur les rôles du realm ou d'un client selon ce que vous voulez inclure
4. Cochez les rôles à inclure (ex: staff)
5. Cliquez sur Assign

Un utilisateur avec le rôle manager aura automatiquement le rôle staff. L'imbrication est récursive : admin composite de manager, lui-même composite de staff, donne bien les trois rôles dans le token. Limitez-vous à deux ou trois niveaux, au-delà personne ne sait plus déduire les droits effectifs d'un compte.

Assigner un rôle à un utilisateur

Cette manipulation crée un lien direct entre une personne et un rôle. Elle se justifie pour un cas particulier (un remplacement, un compte technique), mais elle ne se voit pas depuis le groupe : réservez-la aux exceptions et passez par les groupes pour tout le reste.

1. Allez dans Users et sélectionnez un utilisateur
2. Cliquez sur l'onglet Role mapping
3. Cliquez sur Assign role
4. Sélectionnez le rôle (ex: staff)
5. Cliquez sur Assign

Assigner un rôle à un groupe

C'est la manière de travailler à privilégier. Le rôle est posé une seule fois, et l'arrivée comme le départ d'une personne se gèrent en la faisant entrer ou sortir du groupe, sans jamais retoucher aux rôles. Un rôle posé sur un groupe parent descend en plus dans tous ses sous-groupes.

1. Allez dans Groups et sélectionnez un groupe
2. Cliquez sur l'onglet Role mapping
3. Cliquez sur Assign role
4. Sélectionnez le rôle (ex: staff)
5. Cliquez sur Assign

Tous les membres du groupe héritent automatiquement du rôle. Pour contrôler ce qu'un compte reçoit vraiment, revenez sur sa fiche, onglet Role mapping, et décochez Hide inherited roles : la liste affiche alors les rôles directs, ceux venant des groupes et ceux venant des composites.

Default roles

Les default roles sont automatiquement assignés à tout nouvel utilisateur, y compris ceux créés par la fédération LDAP ou par une inscription en libre-service. Keycloak en crée un d'office par realm, nommé default-roles-<realm> : c'est un composite qui porte déjà les rôles clients account permettant d'accéder à l'Account Console. Ajoutez-y vos rôles plutôt que d'en créer un second.

1. Allez dans Realm settings > User registration
2. Dans Default roles, cliquez sur Assign role
3. Sélectionnez les rôles par défaut (ex: default-roles-lab)

Configurer les clients

Un client représente une application qui s'authentifie auprès de Keycloak.

Types de clients

Le critère de choix est simple : votre application peut-elle garder un secret ? Le code d'une application web monopage ou d'une application mobile est téléchargé sur le poste de l'utilisateur, donc lisible : elle doit être publique. Un backend qui tourne sur vos serveurs peut détenir un secret, il sera confidentiel. Un client public compense l'absence de secret par PKCE, activé dans l'onglet Advanced.

Type	Paramètre Client authentication	Usage
Public	Off	SPA, applications mobiles (pas de secret)
Confidential	On	Backend, API (avec secret client)

Glissez pour voir

Créer un client basique

Deux réglages de cet assistant méritent votre attention. Standard flow active l'Authorization Code Flow, celui qui redirige l'utilisateur vers la page de login Keycloak : c'est le seul flux recommandé pour une application web. Direct access grants laisse au contraire l'application collecter elle-même le mot de passe pour l'échanger contre un token, ce qui va à l'encontre de l'intérêt du SSO et est déconseillé par l'OAuth Security BCP : gardez-le sur Off.

1. Dans le menu, cliquez sur Clients
2. Cliquez sur Create client
3. General settings :
   • Client type : OpenID Connect
   • Client ID : my-app
4. Cliquez sur Next
5. Capability config :
   • Client authentication : Off (public client)
   • Authorization : Off
   • Standard flow : On
   • Direct access grants : Off (recommandé)
6. Cliquez sur Next
7. Login settings :
   • Root URL : http://localhost:3000
   • Valid redirect URIs : http://localhost:3000/*
   • Web origins : http://localhost:3000
8. Cliquez sur Save

Redirect URIs

En production, utilisez des URIs spécifiques. Évitez les wildcards * sauf pour le développement.

Client roles

Un client role vit dans le client : il n'apparaît pas dans la liste Realm roles et deux clients peuvent porter un rôle admin sans se marcher dessus. C'est ce qui permet de nommer les permissions du point de vue de l'application (app:admin, facture:valider) sans polluer l'espace de noms global du realm.

1. Sélectionnez votre client dans Clients
2. Allez dans l'onglet Roles
3. Cliquez sur Create role
4. Role name : app:admin
5. Cliquez sur Save

Ces rôles apparaissent dans les tokens si l'utilisateur les possède.

Surveiller les sessions

La section Sessions permet de voir qui est connecté et d'invalider les sessions.

Voir les sessions actives

Cet écran est votre première source d'information lors d'un incident : il répond à « qui est connecté en ce moment, et depuis quelle adresse ». La colonne Dernière activité est celle à surveiller, car c'est elle que Keycloak compare au SSO Session Idle configuré plus haut pour décider d'expirer la session.

1. Dans le menu, cliquez sur Sessions
2. Vous voyez la liste des sessions actives avec :
   • Utilisateur
   • IP
   • Début de session
   • Dernière activité

Invalider une session

Supprimer une session met fin au SSO côté Keycloak, mais les access tokens déjà émis restent valides jusqu'à leur expiration. C'est exactement pourquoi la durée de vie recommandée d'un access token est courte : elle borne le délai pendant lequel une déconnexion forcée n'a pas encore d'effet sur les API.

1. Dans Sessions, trouvez la session
2. Cliquez sur l'icône poubelle
3. Confirmez la déconnexion

Invalider toutes les sessions d'un utilisateur

C'est la manipulation à faire en cas de compte compromis, et elle vient toujours après le changement de mot de passe : sans cela, la personne qui détient encore un refresh token peut se reconnecter aussitôt. Un utilisateur connecté depuis plusieurs navigateurs a plusieurs sessions, d'où le bouton Sign out all sessions.

1. Allez dans Users et sélectionnez l'utilisateur
2. Cliquez sur l'onglet Sessions
3. Cliquez sur Sign out ou Sign out all sessions

Configurer les Events

Les events permettent d'auditer les actions dans Keycloak.

Types d'events

Keycloak sépare deux journaux qui ne répondent pas aux mêmes questions. Les login events disent ce que les utilisateurs finaux ont fait (se connecter, échouer, se déconnecter), les admin events disent ce que les administrateurs ont changé dans la configuration. Les deux s'activent séparément et sont désactivés par défaut : tant que vous ne les avez pas allumés, il n'y a rien à consulter, même rétroactivement.

Type	Exemples	Usage
Login events	LOGIN, LOGIN_ERROR, LOGOUT	Audit des authentifications
Admin events	CREATE_USER, UPDATE_ROLE	Audit des actions admin

Glissez pour voir

Activer les events

Deux réglages ont un coût qu'il faut mesurer avant de les pousser en production. L'Expiration définit combien de temps Keycloak conserve les lignes dans sa base : sans valeur, la table grossit indéfiniment. Include representation stocke le payload JSON complet de chaque modification, ce qui est précieux pour une enquête mais multiplie le volume, et peut faire entrer des données personnelles dans la base d'audit.

1. Allez dans Realm settings > Events
2. Onglet User events settings :
   • Save user events : On
   • Expiration : 30 jours
   • Event types : cochez les events à capturer
3. Onglet Admin events settings :
   • Save admin events : On
   • Include representation : On (stocke le payload)
4. Cliquez sur Save

Consulter les events

Le type d'event le plus utile au quotidien est LOGIN_ERROR : chaque ligne porte un champ error (invalid_user_credentials, user_disabled, invalid_client_credentials) qui donne la cause exacte du refus, là où l'utilisateur ne voit qu'un message générique. C'est le premier endroit à regarder quand quelqu'un dit « ça ne marche pas ».

1. Dans le menu, cliquez sur Events
2. Utilisez les filtres :
   • User events : par type, utilisateur, date
   • Admin events : par opération, ressource
3. Cliquez sur un event pour voir les détails

Intégration SIEM

En production, exportez les events vers un SIEM (Splunk, ELK) via les Event Listeners pour une analyse centralisée.

Account Console

L'Account Console est l'interface utilisateur final pour gérer son propre compte.

Accédez-y via : http://localhost:8080/realms/lab/account/

Les utilisateurs peuvent :

• Voir et modifier leur profil
• Changer leur mot de passe
• Gérer leurs sessions actives
• Configurer le MFA
• Voir les applications autorisées

À tester

Connectez-vous à l'Account Console avec l'utilisateur alice créé précédemment pour voir l'expérience utilisateur final.

Lab A2, Administration pratique

Mettez en pratique les concepts avec cet exercice guidé.

Objectif

Créer un realm complet avec des utilisateurs organisés en groupes et des rôles.

Étapes du lab

Suivez ces huit étapes dans l'ordre : chacune s'appuie sur la précédente. L'enchaînement reproduit celui d'une mise en place réelle, où l'on construit d'abord la structure (realm, groupes, rôles) avant d'y placer des personnes. L'étape 8 est celle qui compte : c'est la seule qui vérifie que l'ensemble fonctionne du point de vue d'un utilisateur.

1. Créer le realm :

   • Nom : lab
   • Configure les sessions : SSO Idle = 30 min, Access Token = 5 min

2. Créer la hiérarchie de groupes :

   Employees/
   ├── Engineering/
   └── Marketing/

3. Créer les rôles :

   • Realm roles : staff, manager, admin
   • manager est composite et inclut staff
   • admin est composite et inclut manager

4. Assigner les rôles aux groupes :

   • Employees → rôle staff
   • Employees/Engineering → aucun rôle supplémentaire (hérite de staff)

5. Créer les utilisateurs :

   User	Email	Groupe	Rôle direct
   alice	alice@example.com	Engineering	(hérite staff)
   bob	bob@example.com	Engineering	manager
   charlie	charlie@example.com	Marketing	(hérite staff)

   Glissez pour voir

6. Créer un client de test :

   • Client ID : test-app
   • Type : Public (OIDC)
   • Redirect URIs : http://localhost:3000/*

7. Activer les events :

   • Login events : On
   • Admin events : On

8. Valider :

   • Connectez-vous à l'Account Console avec alice
   • Vérifiez les events de login dans l'admin

Critères de réussite

Cochez cette liste dans la console, pas de mémoire. Le point le plus révélateur est le dernier : si les events de login n'apparaissent pas alors que la connexion a réussi, c'est que Save user events a été activé après le test, et les events déjà passés ne sont jamais rattrapés.

• Realm lab créé avec sessions configurées
• Groupes hiérarchiques créés (Employees/Engineering, Employees/Marketing)
• Rôles staff, manager (composite), admin (composite) créés
• Rôle staff assigné au groupe Employees
• Utilisateurs créés dans les bons groupes
• Client test-app configuré
• Events de login visibles après connexion utilisateur

À retenir

Concept	Point clé
Realm	Espace isolé d'identités, un par environnement/application
Master	Réservé aux super-admins, jamais pour les applications
Groupes	Organisent les utilisateurs avec héritage d'attributs et rôles
Realm roles	Permissions globales au realm
Client roles	Permissions spécifiques à une application
Composite roles	Regroupent plusieurs rôles pour simplifier l'admin
Sessions	Surveillez et invalidez les connexions actives
Events	Auditez toutes les actions pour la compliance

Glissez pour voir

Dépannage

L'utilisateur ne peut pas se connecter

Déroulez ces trois vérifications dans cet ordre : elles vont du plus visible au plus précis. La troisième est la seule qui donne la cause réelle, les deux premières écartent les explications les plus fréquentes en quelques secondes.

1. Vérifiez que le compte est Enabled dans l'admin
2. Vérifiez que les credentials sont configurés (onglet Credentials)
3. Vérifiez les events de type LOGIN_ERROR pour le message d'erreur

Si le compte affiche une required action en attente, la connexion aboutit mais l'utilisateur reste bloqué sur un écran intermédiaire, ce qui est souvent décrit comme « je n'arrive pas à me connecter ».

Les rôles n'apparaissent pas dans le token

Un rôle absent du token ne veut pas dire qu'il n'est pas assigné : entre l'assignation et le token, il y a le role mapping puis le scope du client. Décodez d'abord le token sur un outil hors ligne pour savoir si le rôle manque dans realm_access.roles ou dans resource_access, cela vous dira laquelle des trois étapes ci-dessous a lâché.

1. Vérifiez que le rôle est bien assigné (direct ou via groupe)
2. Vérifiez les mappers du client (voir K2-01 pour les détails)
3. Pour les client roles, vérifiez que le scope est inclus

L'Account Console affiche "Page not found"

Vérifiez l'URL : http://localhost:8080/realms/{realm-name}/account/

Remplacez {realm-name} par le nom exact de votre realm (ex: lab).

Prochaines étapes

Sécuriser une application (OIDC) Le realm est prêt : connectez-y une vraie application en OpenID Connect.

Fédérer un annuaire LDAP/AD Réutilisez les utilisateurs d'un annuaire existant plutôt que de les recréer.

OpenID Connect, Les fondamentaux La couche d'authentification au-dessus d'OAuth 2.x.

×

📖 Voir la documentation →