Centraliser l’authentification avec Keycloak : SSO pour une infrastructure open source

Un fournisseur d’identité unique pour CKAN, Nextcloud, Gitea, Superset et toutes les briques de votre SI.

Quand une infrastructure open source grandit, chaque nouvelle brique apporte sa propre gestion des utilisateurs. CKAN a ses comptes locaux, Nextcloud les siens, Gitea encore d’autres. Les utilisateurs se retrouvent avec cinq mots de passe différents, les administrateurs doivent gérer autant de bases de comptes, et la moindre arrivée ou départ de collaborateur se transforme en parcours du combattant.

Keycloak résout ce problème en centralisant l’authentification et la gestion des identités dans un service unique. Chaque application se connecte à Keycloak via un protocole standard (OpenID Connect ou SAML), et l’utilisateur s’authentifie une seule fois pour accéder à l’ensemble du SI. C’est le Single Sign-On (SSO) appliqué à l’infrastructure open source.

Pourquoi Keycloak plutôt qu’un autre fournisseur d’identité ?

Critère	Keycloak	Alternatives (Authelia, Authentik, Dex)
Protocoles	OIDC, SAML 2.0, LDAP federation	Souvent OIDC uniquement, SAML partiel
Console d’administration	Interface web complète, gestion des realms, rôles, groupes, sessions	Variable, parfois minimaliste
Fédération d’identités	LDAP, Active Directory, social login, identity brokering	Support plus limité
Maturité	Projet Red Hat, large communauté, documentation abondante	Projets plus jeunes
Personnalisation	Thèmes, flux d’authentification configurables, extensions SPI	Moins extensible
Empreinte	Plus lourd (~512 Mo RAM minimum)	Plus léger pour les petites installations

Keycloak est le choix naturel quand l’infrastructure comprend des applications hétérogènes (certaines OIDC, d’autres SAML), quand on a besoin de fédérer un annuaire LDAP existant, ou quand la console d’administration doit être accessible à des non-développeurs. Pour une infrastructure avec deux ou trois services, Authelia ou Authentik peuvent suffire. Au-delà, Keycloak s’impose.

Architecture type

Dans une architecture typique, Keycloak fonctionne comme le point central d’authentification. Chaque application est enregistrée comme un client OIDC dans un realm Keycloak. L’utilisateur qui accède à CKAN est redirigé vers la page de connexion Keycloak, s’authentifie, puis est renvoyé vers CKAN avec un token JWT. S’il ouvre ensuite Nextcloud dans un autre onglet, la session Keycloak est déjà active : pas de nouveau mot de passe à saisir.

Les composants impliqués :

Keycloak : fournisseur d’identité, gère les utilisateurs, les sessions, les tokens
PostgreSQL : base de données de Keycloak (utilisateurs, realms, sessions)
Nginx : reverse proxy, TLS termination, routage des sous-domaines (auth.mondomaine.fr)
Applications clientes : CKAN, Nextcloud, Gitea, Superset, Drupal — chacune configurée en client OIDC

Déploiement Docker Compose

Voici un docker-compose.yml minimal pour déployer Keycloak en production :

version: "3.9"
services:
  keycloak-db:
    image: postgres:16-alpine
    volumes:
      - keycloak-db-data:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: keycloak
      POSTGRES_USER: keycloak
      POSTGRES_PASSWORD: ${KC_DB_PASSWORD}

  keycloak:
    image: quay.io/keycloak/keycloak:24.0
    command: start
    depends_on:
      - keycloak-db
    environment:
      KC_DB: postgres
      KC_DB_URL: jdbc:postgresql://keycloak-db:5432/keycloak
      KC_DB_USERNAME: keycloak
      KC_DB_PASSWORD: ${KC_DB_PASSWORD}
      KC_HOSTNAME: auth.mondomaine.fr
      KC_PROXY_HEADERS: xforwarded
      KC_HTTP_ENABLED: "true"
      KC_HEALTH_ENABLED: "true"
    ports:
      - "8080:8080"

volumes:
  keycloak-db-data:

En production, Keycloak tourne derrière Nginx qui gère le TLS. Le paramètre KC_PROXY_HEADERS: xforwarded indique à Keycloak de faire confiance aux en-têtes proxy pour reconstruire les URLs de redirection correctes.

Version 24+ et Quarkus : Depuis la version 17, Keycloak a migré de WildFly vers Quarkus. Les images Docker récentes utilisent cette nouvelle base. La commande de démarrage est désormais start (production) ou start-dev (développement). Le mode start-dev active le HTTP sans TLS et la console d’admin — ne l’utilisez jamais en production.

Configurer un realm et des clients OIDC

Une fois Keycloak démarré, la configuration se fait depuis la console d’administration (https://auth.mondomaine.fr/admin) :

1. Créer un realm

Un realm isole un ensemble d’utilisateurs et de clients. Créez un realm dédié (par exemple infrastructure) plutôt que d’utiliser le realm master, qui est réservé à l’administration de Keycloak lui-même.

2. Enregistrer les clients

Pour chaque application, créez un client OIDC avec les paramètres suivants :

Application	Client ID	Redirect URI	Particularité
CKAN	`ckan`	`https://data.mondomaine.fr/user/sso/callback`	Extension `ckanext-keycloak`
Nextcloud	`nextcloud`	`https://cloud.mondomaine.fr/apps/oidc/callback`	App « OpenID Connect Login »
Gitea	`gitea`	`https://git.mondomaine.fr/user/oauth2/keycloak/callback`	Source d’auth OIDC native
Superset	`superset`	`https://bi.mondomaine.fr/oauth-authorized/keycloak`	Provider Flask-OIDC
Drupal	`drupal`	`https://www.mondomaine.fr/openid-connect/keycloak`	Module `openid_connect`

3. Mapper les rôles

Keycloak permet de définir des rôles au niveau du realm (admin, editor, viewer) et de les mapper vers des attributs du token JWT. Chaque application peut ensuite lire ces rôles pour déterminer les permissions locales. Par exemple, un utilisateur avec le rôle ckan-admin dans Keycloak obtient automatiquement le rôle sysadmin dans CKAN, sans configuration côté CKAN.

Intégration CKAN avec ckanext-keycloak

CKAN s’intègre à Keycloak via l’extension ckanext-keycloak (ou plus génériquement ckanext-oauth2). La configuration dans ckan.ini :

# ckan.ini
ckan.plugins = ... keycloak

ckanext.keycloak.server_url = https://auth.mondomaine.fr
ckanext.keycloak.client_id = ckan
ckanext.keycloak.client_secret = ${CKAN_KEYCLOAK_SECRET}
ckanext.keycloak.realm_name = infrastructure
ckanext.keycloak.redirect_url = https://data.mondomaine.fr/user/sso/callback
ckanext.keycloak.sso_enabled = true
ckanext.keycloak.button_text = Se connecter via SSO

Après redémarrage de CKAN, un bouton « Se connecter via SSO » apparaît sur la page de login. L’extension crée automatiquement le compte CKAN au premier login si l’utilisateur n’existe pas encore, en récupérant le nom, l’email et les rôles depuis le token Keycloak.

Intégration Gitea

Gitea supporte nativement les sources d’authentification OIDC. La configuration se fait depuis l’interface d’administration (Administration du site > Sources d’authentification) ou via le fichier app.ini :

# Depuis l'interface admin de Gitea :
# Nom : Keycloak
# Type : OAuth2
# Provider : OpenID Connect
# Client ID : gitea
# Client Secret : ********
# OpenID Connect Auto Discovery URL :
#   https://auth.mondomaine.fr/realms/infrastructure/.well-known/openid-configuration

Gitea utilise l’endpoint de découverte (.well-known/openid-configuration) pour configurer automatiquement les URLs d’autorisation, de token et d’info utilisateur. L’utilisateur voit un bouton « Se connecter avec Keycloak » sur la page de login Gitea.

Gestion du cycle de vie des utilisateurs

L’un des avantages majeurs de Keycloak est la gestion centralisée du cycle de vie :

Arrivée : on crée le compte dans Keycloak, on assigne les rôles appropriés. L’utilisateur peut ensuite accéder à toutes les applications sans inscription supplémentaire.
Changement de rôle : on modifie les rôles dans Keycloak. Au prochain login, les permissions sont mises à jour dans chaque application.
Départ : on désactive ou supprime le compte Keycloak. L’accès est immédiatement coupé à toutes les applications. Les sessions actives sont invalidées via le backchannel logout.

Pour les organisations qui disposent déjà d’un annuaire LDAP ou Active Directory, Keycloak peut fédérer ces sources : les utilisateurs continuent de s’authentifier avec leurs identifiants existants, mais bénéficient du SSO et de la gestion de rôles centralisée.

Sécurisation et bonnes pratiques

MFA (authentification multifacteur) : Keycloak supporte nativement le TOTP (Google Authenticator, Authy) et le WebAuthn (clés FIDO2). Activez-le au minimum pour les comptes administrateurs.
Politique de mots de passe : configurez des règles de complexité, d’expiration et d’historique dans les paramètres du realm.
Brute force protection : Keycloak intègre un mécanisme de verrouillage temporaire après plusieurs tentatives échouées. Activez-le et ajustez les seuils.
Sessions : définissez des durées de session raisonnables (30 minutes d’inactivité, 10 heures maximum) et activez le backchannel logout pour que la déconnexion d’une application se propage aux autres.
Sauvegarde : la base PostgreSQL de Keycloak contient les utilisateurs, les realms et les sessions. Intégrez-la dans votre stratégie de backup avec pg_dump quotidien.

Export/Import de configuration : Keycloak permet d’exporter la configuration d’un realm en JSON (kc.sh export --realm infrastructure --file realm-export.json). Versionnez ce fichier dans Git pour tracer les changements de configuration et faciliter la restauration ou la réplication de l’environnement.

Supervision et monitoring

Keycloak expose des métriques Prometheus via l’option KC_METRICS_ENABLED=true. Les indicateurs essentiels à surveiller sont le nombre de sessions actives, le taux d’échecs d’authentification, la latence des réponses token, et l’utilisation mémoire de la JVM. Un dashboard Grafana dédié permet de détecter rapidement les anomalies — pic d’échecs d’authentification (attaque brute force ?), explosion du nombre de sessions (fuite de tokens ?), ou dégradation des temps de réponse.

Points de vigilance

Performance : Keycloak basé sur Quarkus est plus léger que l’ancien WildFly, mais reste gourmand en mémoire. Prévoyez au minimum 512 Mo de heap, idéalement 1 Go pour une centaine d’utilisateurs actifs.
Mises à jour : les montées de version majeures nécessitent parfois des migrations de base. Testez systématiquement sur un environnement de staging avant la production.
Disponibilité : si Keycloak tombe, plus personne ne peut se connecter. En production critique, envisagez un déploiement en cluster (Keycloak supporte nativement le mode HA avec Infinispan).
Tokens et cache : les applications qui cachent les tokens JWT côté client doivent gérer correctement le refresh token. Un token expiré avec un refresh échoué doit déclencher une re-authentification transparente.

Récapitulatif

Keycloak transforme une collection d’applications indépendantes en un SI unifié du point de vue de l’identité. Un seul compte, un seul mot de passe, une seule console d’administration des accès. Pour les infrastructures qui combinent CKAN, Nextcloud, Gitea, Superset et Drupal, c’est la brique qui rend le tout cohérent et administrable. Le coût d’entrée est un déploiement Docker et quelques heures de configuration par client — un investissement largement rentabilisé dès le deuxième utilisateur ajouté.

KeycloakSSOOIDCauthentificationopen sourceCKANNextcloudGiteasécuritéDocker