Keycloak - Déploiement Docker & Intégration SSO¶
Gérer les identités de plusieurs applications à la main, c'est multiplier les mots de passe, les oublis et les failles. Keycloak règle le problème d'un coup : une seule porte d'entrée, un seul login, et toutes vos applications qui délèguent leur authentification. C'est le poids lourd open-source de la gestion d'identité (IAM) — soutenu par Red Hat, taillé pour l'entreprise, et gratuit.
Une fois en place, il parle tous les dialectes qui comptent :
- l’authentification unique (SSO)
- LDAP/Active Directory
- OpenID Connect
- OAuth2
- SAML 2.0
Le mode start-dev n'est pas fait pour la production
Keycloak démarré sans base externe ni configuration de hostname est parfait pour tester, mais ne tient pas la route en production : données volatiles, hostname permissif. Pour une vraie mise en service, prévoyez une base PostgreSQL dédiée, un hostname fixe et un reverse proxy TLS devant (--proxy-headers=xforwarded, comme dans l'exemple). C'est le piège n°1 des premières mises en prod.
Prérequis¶
Avant de commencer, assurez-vous d’avoir :
- Docker et Docker Compose installés — voir Installation Docker
- Un accès à Internet
- Le port 9400 disponible sur votre machine
Configuration du projet¶
Le fichier docker-compose.yml utilise l’image officielle Keycloak disponible sur :
Composants¶
| Élément | Description |
|---|---|
| Service | keycloak |
| Image | quay.io/keycloak/keycloak:latest |
| Port | Conteneur 8080 exposé sur hôte 9400 |
| Commandes | Démarrage en mode HTTP, avec proxy headers (--proxy-headers=xforwarded) |
| Hostname | keycloak.votre-domaine.tld |
| Volumes | keycloak_data prévu pour une future persistance des données |
Variables d'environnement¶
| Variable | Description |
|---|---|
KC_BOOTSTRAP_ADMIN_USERNAME |
Nom d’utilisateur admin |
KC_BOOTSTRAP_ADMIN_PASSWORD |
Mot de passe admin (défini via .env) |
KC_HOSTNAME_STRICT |
Désactive la vérification stricte |
KC_HOSTNAME_STRICT_HTTPS |
Désactive la vérification HTTPS stricte |
Extrait du fichier .env :
KEYCLOAK_PASSWORD=PASSWORD
▶ Lancer Keycloak¶
Depuis le dossier du projet :
docker-compose up -d
Cela va :
- Télécharger l’image
- Créer les volumes nécessaires
- Démarrer le conteneur en arrière-plan
Commandes utiles¶
docker-compose ps # Vérifie l’état du conteneur
docker-compose logs -f # Affiche les logs en temps réel
docker-compose restart # Redémarre le conteneur
docker-compose down # Arrête et supprime les ressources
Accès à l’interface Web¶
URL : http://localhost:9400
Identifiants : définis dans .env
| Champ | Valeur |
|---|---|
| Utilisateur | admin |
| Mot de passe | KEYCLOAK_PASSWORD |
Sécurité¶
- Le fichier
.envne doit pas être versionné → ajoutez-le au.gitignore. -
Pour un usage en production :
-
Activez HTTPS
- Placez Keycloak derrière un proxy inverse (ex. : Nginx, Traefik)
Exemple minimal de docker-compose.yml¶
version: '3.8'
services:
keycloak:
image: quay.io/keycloak/keycloak:latest
container_name: Keycloak
environment:
KC_BOOTSTRAP_ADMIN_USERNAME: admin
KC_BOOTSTRAP_ADMIN_PASSWORD: ${KEYCLOAK_PASSWORD}
KC_HOSTNAME_STRICT: "false"
KC_HOSTNAME_STRICT_HTTPS: "false"
ports:
- "9400:8080"
restart: always
command:
- "start"
- "--http-enabled=true"
- "--http-port=8080"
- "--hostname=keycloak.votre-domaine.tld"
- "--proxy-headers=xforwarded"
volumes:
keycloak_data:
name: keycloak_data
Ajouter une application cliente à Keycloak (SSO OpenID Connect)¶
Cette section décrit comment intégrer une application à Keycloak via OpenID Connect (ex. : Portainer).
Création du client¶
Depuis l’interface Keycloak :
- Accédez à votre realm
- Menu Clients > Create client
- Renseignez les champs suivants :
| Champ | Valeur d’exemple |
|---|---|
| Client ID | portainer |
| Name | Portainer |
| Client type | OpenID Connect |
| Root URL | https://app.exemple.fr |
✅ Cliquez sur Save
Paramètres du client¶
Access Settings¶
| Champ | Valeur |
|---|---|
| Root URL | https://app.exemple.fr |
| Home URL | https://app.exemple.fr |
| Valid Redirect URIs | https://app.exemple.fr/* |
| Valid Post Logout Redirect URIs | https://app.exemple.fr |
| Web Origins | https://app.exemple.fr |
| Admin URL | https://app.exemple.fr |
Capability Settings¶
| Option | État |
|---|---|
| Client authentication | ✅ Activé |
| Authorization | ❌ Désactivé |
Authentication Flow¶
| Option | État |
|---|---|
| Standard flow | ✅ |
| Direct access grants | ✅ |
| Implicit flow | ❌ |
| Service accounts | ❌ |
| Token Exchange / CIBA / Device Grant | ❌ |
Login Settings¶
| Champ | Valeur |
|---|---|
| Login theme | keycloak.v2 |
| Consent required | ❌ |
| Display client in UI | ❌ |
Logout Settings¶
| Champ | Valeur |
|---|---|
| Front-channel logout | ✅ |
| Front-channel logout URL | https://app.exemple.fr |
| Session required | ❌ |
Création d’un utilisateur¶
Depuis l’interface Keycloak :
- Menu Users > Add user
- Renseignez les champs :
| Champ | Exemple |
|---|---|
| Username | utilisateur1 |
utilisateur1@domaine.fr |
|
| First name | Prénom |
| Last name | (optionnel) |
-
Une fois créé :
-
Onglet Credentials → définir un mot de passe
- Onglet Role Mappings → attribuer un rôle
Gestion des rôles¶
- Menu Clients > [nom-client] > Roles
- Créez un rôle (ex. :
connect-app) - Associez ce rôle à un utilisateur via Role Mappings
Modèle réutilisable¶
# 🔐 CONFIGURATION CLIENT KEYCLOAK (TEMPLATE)
Client ID: <nom-client>
Name: <Nom de l'application>
Client type: OpenID Connect
Root URL: https://<app>.domaine.fr
Valid Redirect URIs: https://<app>.domaine.fr/*
Web Origins: https://<app>.domaine.fr
Client Authentication: On
Standard Flow: On
Direct Access Grants: On
Implicit Flow: Off
Login Theme: keycloak.v2
# 🔐 RÔLE
Client Role: connect-<app>
# 👤 UTILISATEUR
Username: utilisateur1
Email: utilisateur1@domaine.fr
Rôle attribué: connect-<app>
Tester la connexion¶
Configurez votre application pour utiliser Keycloak comme fournisseur d'identité.
| Clé | Valeur |
|---|---|
| Issuer URL | https://keycloak.exemple.fr/realms/mon-realm |
| Client ID | nom-client |
| Client Secret | (si Client authentication est activé) |
En résumé¶
Keycloak demande un peu plus d'investissement à la mise en place qu'un simple conteneur — base dédiée, hostname, proxy TLS — mais ce qu'il rend en retour est considérable : une identité unique pour tout votre parc applicatif, des rôles centralisés, et la fin des mots de passe éparpillés. Une fois le premier client OIDC branché et testé, les suivants se configurent en quelques minutes sur le même modèle.