Keycloak : Sécuriser et Auditer votre IAM Open Source

Qu'est-ce que Keycloak et pourquoi l'auditer ?

Keycloak est une solution d'Identity and Access Management (IAM) open source développée par Red Hat. Elle implémente les protocoles OAuth 2.0, OpenID Connect (OIDC) et SAML 2.0, et gère l'authentification centralisée pour des dizaines d'applications d'entreprise simultanément.

Son adoption a explosé depuis 2022 : selon la base de données Shodan, plus de 85 000 instances Keycloak sont exposées sur Internet en mai 2026, dont 30 % sans authentification forcée sur l'interface d'administration. Cette surface d'attaque en fait une cible de premier choix pour les APT et les ransomwares.

La compromission d'un serveur Keycloak est catastrophique : un attaquant obtient un contrôle total sur l'identité de tous les utilisateurs de toutes les applications fédérées. C'est l'équivalent d'un Golden Ticket Active Directory, mais pour l'ensemble du patrimoine applicatif cloud.

Architecture et composants clés

Comprendre l'architecture Keycloak est indispensable avant tout audit :

Realms — Les realms sont les unités d'isolation. Chaque realm a ses propres utilisateurs, rôles, clients et paramètres de sécurité. Le realm master est le realm d'administration global : sa compromission donne accès à tous les autres realms.

Clients — Un client Keycloak représente une application qui délègue son authentification. Chaque client a un type (public ou confidential), un flux d'authentification autorisé, et des URI de redirection. Les clients publics ne disposent pas de secret client et sont vulnérables aux attaques de type authorization code interception.

Utilisateurs et fédération — Keycloak peut fédérer un Active Directory via LDAP, un autre IdP via SAML/OIDC, ou maintenir sa propre base d'utilisateurs. La fédération LDAP est le vecteur d'attaque LDAP injection le plus courant.

Flux d'authentification — Les flux déterminent comment les utilisateurs s'authentifient. Le flux par défaut est insuffisamment restrictif pour des environnements exposés sur Internet.

Configurations dangereuses par défaut

Voici les 8 erreurs de configuration les plus fréquentes, classées par criticité :

1. Console d'administration exposée sur Internet (Critique)
Par défaut, Keycloak expose /auth/admin/ sur le même port que l'application. Cette console doit être accessible uniquement depuis le réseau interne ou via VPN. Ajoutez un bloc nginx restrictif ou configurez http.management.port sur un port dédié non exposé.

2. Realm master utilisé pour les applications (Critique)
Le realm master ne doit servir qu'à l'administration de Keycloak. Créer des applications dans ce realm permet à un attaquant ayant compromis un client d'escalader vers l'administration globale. Chaque environnement applicatif doit avoir son propre realm dédié.

3. Clients publics avec flux implicites activés (Élevé)
Le flux implicite OAuth 2.0 est déprécié (RFC 9700) et expose les tokens dans l'URL. Désactivez-le systématiquement et forcez le flux Authorization Code avec PKCE pour tous les clients publics.

4. Durée de session excessive (Élevé)
Les valeurs par défaut (SSO session max = 10 heures, offline session = 5 jours) sont trop permissives. Réduisez à 1-4 heures pour les sessions SSO et désactivez les sessions offline sauf besoin explicite.

5. Absence de brute-force protection (Élevé)
La protection contre le brute-force est désactivée par défaut. Activez-la dans Realm Settings → Security Defenses : détection après 5 tentatives, délai croissant, lock après 10 échecs.

6. Mots de passe faibles autorisés (Moyen)
La politique de mot de passe par défaut est vide. Configurez : minimum 12 caractères, majuscule, minuscule, chiffre, symbole, et interdiction des 5 derniers mots de passe.

7. Logs d'audit non configurés (Moyen)
Les événements d'audit (LOGIN_ERROR, ADMIN_EVENT) ne sont pas envoyés par défaut vers un SIEM. Configurez la remontée vers votre Elastic/Splunk via le provider d'événements Keycloak.

8. TLS interne désactivé (Moyen)
Les communications inter-nœuds Keycloak (Infinispan clustering) circulent souvent en clair sur le réseau interne. Activez le chiffrement JGroups pour les clusters multi-nœuds.

CVE actifs en 2026

Trois vulnérabilités critiques affectent les versions Keycloak déployées en production :

CVE-2026-1274 — RCE via template injection dans la console admin (CVSS 9.1)
Versions affectées : Keycloak 22.x à 25.0.3. Un attaquant authentifié sur la console d'administration peut injecter des templates FreeMarker malveillants via le champ "Hostname verification policy" de la configuration SMTP. L'exécution de code arbitraire s'effectue avec les privilèges du processus Keycloak. Patch : mettre à jour vers 25.0.4 ou appliquer le workaround (désactiver l'accès SMTP config pour les admins de realm).

CVE-2025-0604 — SSRF via broker identity provider (CVSS 8.1)
Keycloak < 24.0.5. Lors de la configuration d'un Identity Provider externe, l'URL du discovery endpoint n'est pas suffisamment validée. Un administrateur realm malveillant peut forcer des requêtes vers des services internes (metadata AWS, Kubernetes API server). Patch : 24.0.5+.

CVE-2024-8698 — Bypass de signature SAML (CVSS 7.7)
Versions Keycloak < 24.0.7. La validation des signatures SAML est contournable via une modification de la structure XML (XML Signature Wrapping). Affecte les installations utilisant Keycloak comme Service Provider SAML. Patch : 24.0.7+.

Méthodologie d'audit Keycloak

Un audit de sécurité Keycloak couvre trois couches distinctes :

Couche 1 : Reconnaissance et cartographie
Identifiez les endpoints exposés : /auth/realms/{realm}/.well-known/openid-configuration révèle la configuration complète du realm (endpoints, algorithmes de signature, claims supportés). Listez les realms accessibles via /auth/admin/realms (retourne 401 si non authentifié, mais confirme l'existence). Utilisez l'outil keycloak-auditor (disponible sur GitHub) pour automatiser la détection des configurations exposées.

Couche 2 : Test des flux d'authentification
Testez le brute-force sur l'endpoint /auth/realms/{realm}/protocol/openid-connect/token. Vérifiez si le flux Resource Owner Password Credentials (ROPC) est activé — il doit être désactivé sur les applications publiques. Testez les redirections ouvertes en modifiant le paramètre redirect_uri.

Couche 3 : Audit de la configuration admin
Si vous avez un compte admin de test, exportez la configuration complète du realm (Realm Settings → Export) et analysez : durées de session, politiques de mot de passe, flux actifs, clients publics, scopes autorisés. Cherchez les client secrets codés en dur dans les applications avec grep -r "client_secret" /app/ --include="*.properties" --include="*.yaml" --include="*.env".

Intégration Active Directory / LDAP

La fédération LDAP avec Active Directory est la configuration la plus répandue en entreprise et la plus risquée. Points d'audit critiques :

Compte de service LDAP — Le compte utilisé par Keycloak pour interroger l'AD doit être un compte dédié avec uniquement les droits de lecture (Read sur l'OU cible). Refusez impérativement l'utilisation d'un compte admin AD ou Domain Admin. Vérifiez via dsacls "OU=Users,DC=corp,DC=local".

Synchronisation périodique — La synchronisation complète des utilisateurs LDAP peut exposer des attributs sensibles (numéros de téléphone, attributs extensionAttribute). Auditez les attributs synchronisés dans User Federation → Edit → Mapper et supprimez ceux non nécessaires.

LDAP injection — Testez les champs de login avec des caractères spéciaux LDAP : admin*)(|(uid=*. Les versions Keycloak récentes filtrent correctement, mais des configurations custom non-patchées peuvent être vulnérables.

Hardening : checklist prioritaire

Appliquez ces mesures dans l'ordre pour sécuriser une instance Keycloak existante :

• Restreindre l'accès à /auth/admin/ par IP ou VPN (nginx allow 10.0.0.0/8; deny all;)
• Mettre à jour vers Keycloak 25.0.4+ (patch CVE-2026-1274)
• Activer la brute-force protection (5 tentatives max, lock 15 min)
• Désactiver le flux implicite et ROPC sur tous les clients
• Configurer la politique de mot de passe (12 chars, complexité, historique)
• Réduire les durées de session SSO (1-4h selon contexte)
• Activer HTTPS sur toutes les communications (TLS 1.2+ minimum)
• Configurer l'export des événements vers votre SIEM
• Séparer realm master et realms applicatifs
• Désactiver la création de compte utilisateur public si non nécessaire

Surveillance et détection

Les événements Keycloak à surveiller en priorité dans votre SIEM :

Événements d'authentification critiques : LOGIN_ERROR (échec de connexion), BRUTE_FORCE (lock déclenché), CODE_TO_TOKEN_ERROR (flux OAuth échoué), REFRESH_TOKEN_ERROR.

Événements administratifs suspects : CLIENT_UPDATE (modification d'un client — vérifier les URI ajoutées), IDENTITY_PROVIDER_CREATE (nouvel IdP — vecteur SSRF), USER_FEDERATED_IDENTITY_ADD (association de comptes), REALM_UPDATE.

Règle Sigma recommandée pour détecter une reconnaissance du realm master :

title: Keycloak Master Realm Access Attempt
logsource: category=webserver
detection:
  keywords:
    - '/auth/admin/master/console'
    - '/auth/realms/master/.well-known'
  condition: keywords
level: medium