Ce que permet la plateforme hébergée

Avec un Keycloak hébergé par un tiers comme Cloud-IAM, une partie des décisions d’architecture ne vous appartient plus : elle dépend de ce que l’hébergeur gère, autorise ou facture. Sa documentation interne n’est pas publique, et ce cours ne prétend pas la décrire. Il fournit une grille de questions à dérouler en séance avec l’hébergeur. Pour chaque point, il explique pourquoi la réponse change l’architecture et ce que Keycloak permet de base quand on l’héberge soi-même, pour savoir ce qui est une limite du produit et ce qui est une limite de l’offre.

Le périmètre géré

Un hébergeur managé prend en charge l’infrastructure. La question est où s’arrête cette prise en charge.

Question	Pourquoi elle compte	En auto-hébergé
Qui opère l’infrastructure (calcul, base de données, réseau, répartition de charge) et dans quelle région ?	Localisation des données, exigences de souveraineté et de qualification	Tout est à votre charge ; Keycloak a besoin d’une base relationnelle et de ses caches distribués
Quelle disponibilité est garantie, avec quelles pénalités ? Y a-t-il un mode multi-site ?	L’IdP est un point de passage unique pour toutes les applications	Keycloak sait fonctionner en cluster et propose une architecture multi-site documentée, au prix d’une exploitation exigeante
Comment se passent les montées de version : calendrier, préavis, recette, possibilité de différer ?	Une nouvelle version peut casser une extension ou un thème	La branche 26 a reçu plusieurs versions mineures et de nombreux correctifs ; en pratique, la communauté ne corrige que la dernière version
Quelle supervision est en place, et vous donne-t-on accès aux métriques et à l’état de santé ?	Diagnostiquer une lenteur de connexion sans accès aux métriques est difficile	Endpoints de santé et métriques Prometheus activables (`--health-enabled`, `--metrics-enabled`), exposés sur le port de management (9000 par défaut)
Quelles sauvegardes : fréquence, rétention, RPO, RTO, test de restauration ? Peut-on restaurer un seul realm ?	Une erreur d’administration (realm supprimé) doit être réparable	Sauvegarde de la base ; l’export de realm ne remplace pas une sauvegarde, il ne couvre pas tout l’état
Qui détient les droits d’administration, notamment sur le realm `master` ?	Le compte le plus privilégié doit être connu et tracé	Vous détenez tout

Les extensions

Le projet aura probablement besoin d’au moins un thème, et peut-être d’extensions Java : authenticator, protocol mapper, event listener, user storage (voir le cours sur les points d’extension).

En auto-hébergé, une extension est un JAR déposé dans le dossier providers/ de Keycloak, suivi d’une reconstruction (kc.sh build) pour une image optimisée. Un thème se livre de la même façon ou dans le dossier themes/. Rien n’est limité par le produit.

Sur une plateforme managée, l’hébergeur doit accepter du code tiers dans son infrastructure. Questions à poser :

Existe-t-il un catalogue d’extensions fournies et maintenues par l’hébergeur ? Lesquelles, et qui les maintient à chaque version ?
Peut-on déployer ses propres extensions et ses thèmes ? Par quel canal (dépôt, pipeline, ticket) ? Avec quelle revue de code ou de sécurité ?
Qui reteste les extensions lors d’une montée de version, et que se passe-t-il si l’une d’elles casse ?
Les features désactivées par défaut ou en preview (par exemple certaines fonctions d’échange de jetons) peuvent-elles être activées ?
Peut-on modifier les flux d’authentification librement, y compris avec des authenticators fournis par extension ?

Réponse de l’hébergeur	Conséquence pour l’architecture
Extensions du projet acceptées, déploiement outillé	Paramétrage et extension sont tous deux possibles ; arbitrer sur le coût de maintenance
Catalogue fermé de l’hébergeur	Tout besoin hors catalogue doit être couvert par paramétrage ou porté par l’hébergeur ; à identifier tôt
Thèmes seulement	Les besoins de mappers ou d’authenticators spécifiques deviennent des contraintes de conception

Joindre un annuaire interne

La fédération LDAP ou Active Directory (voir le cours sur les sources d’utilisateurs) fonctionne ainsi : Keycloak ouvre la connexion vers l’annuaire, s’y authentifie avec un compte de service, cherche l’utilisateur et vérifie son mot de passe par un bind. Le flux va donc de la plateforme vers le réseau du client. Avec Keycloak hébergé hors de ce réseau, ce flux entrant est souvent refusé par la sécurité.

Trois familles de réponses existent en général : un VPN ou un lien privé entre la plateforme et le réseau du client ; un agent installé dans le réseau du client, qui ouvre une connexion sortante vers la plateforme et relaie les requêtes LDAP ; ou l’absence de fédération directe (import, synchronisation poussée par le client, ou brokering vers un IdP interne). Questions :

L’hébergeur propose-t-il un agent ? N’ouvre-t-il que des connexions sortantes, vers quelles adresses et quels ports ?
Comment l’agent se met-il à jour, qui le supervise, peut-on en installer plusieurs pour la haute disponibilité ?
Que se passe-t-il si l’agent est coupé ? En mode avec import, Keycloak garde une copie des comptes, mais la vérification du mot de passe passe toujours par l’annuaire ; en mode sans import, l’utilisateur est inconnu tant que l’annuaire est injoignable. Dans les deux cas, les connexions par mot de passe LDAP échouent.
Quelle latence ajoute le relais ? Elle s’ajoute à chaque connexion.
Le LDAPS est-il de bout en bout ? Où sont les certificats ?
L’écriture vers l’annuaire (mode d’édition « WRITABLE ») et la synchronisation périodique passent-elles par l’agent ?

En auto-hébergé dans le réseau du client, aucune de ces questions ne se pose : Keycloak joint l’annuaire directement, avec les délais de connexion et le pool de connexions réglables dans le provider LDAP.

Les environnements

Question	Pourquoi elle compte	En auto-hébergé
Combien d’environnements (développement, recette, préproduction, production), à quel coût ?	Les tests d’intégration et la recette des applications ont besoin d’un environnement stable hors production	Autant que vous voulez opérer
Sont-ils isolés (instances, bases, réseaux) ou partagent-ils une instance avec des realms distincts ?	Un realm de recette dans l’instance de production partage ses ressources et ses montées de version	À vous de choisir
Les versions sont-elles alignées ? La montée de version passe-t-elle d’abord par la préproduction ?	Recetter une montée de version avant la production	À vous d’organiser
Comment promouvoir une configuration d’un environnement à l’autre : export et import, Admin REST API, Terraform ?	Le choix d’outillage de configuration en code en dépend	Admin REST API, `kcadm.sh`, export et import de realm, outils tiers
Les données de production peuvent-elles être copiées en recette ?	Données personnelles, empreintes de mots de passe	Votre politique

Le domaine personnalisé

L’URL de Keycloak devient l’issuer des jetons (https://sso.example.org/realms/agents) et l’adresse des métadonnées SAML. Les applications la valident. La changer après le raccordement des applications oblige à reconfigurer chacune d’elles : c’est une décision à prendre avant la première mise en production.

En auto-hébergé, l’option --hostname fixe l’URL publique, et --hostname-admin permet de servir la console d’administration sur une autre adresse, par exemple uniquement sur le réseau interne. Questions :

Peut-on utiliser un domaine du client (sso.client.fr) plutôt qu’un sous-domaine de l’hébergeur ? Qui gère le DNS et le certificat, et son renouvellement ?
Peut-on avoir un domaine distinct par environnement ?
La console d’administration est-elle exposée sur Internet ? Peut-on la restreindre (adresse distincte, filtrage IP) ?
Les en-têtes de sécurité et le pare-feu applicatif sont-ils configurables ?

Les journaux et le SOC

Keycloak produit deux familles de traces.

Les événements : connexions réussies et échouées, déconnexions, changements de mot de passe, enrôlements MFA (événements utilisateur), et actions dans la console ou l’API (événements d’administration). On les active par realm, ils sont stockés en base avec une durée d’expiration, et consultables dans la console ou par l’API.
Les journaux serveur : activité technique de Keycloak. Le handler console peut écrire en JSON (--log-console-output=json), et un handler syslog existe (--log=syslog). L’event listener jboss-logging, actif par défaut, recopie les événements utilisateur dans ces journaux : les erreurs au niveau WARN, les succès au niveau DEBUG (donc invisibles avec le niveau de log par défaut).

Pour alimenter un SIEM, on s’appuie soit sur les journaux serveur (en JSON ou en syslog), soit sur un event listener spécifique développé en extension. Le détail est traité dans le cours sur les événements et le SOC. Questions à l’hébergeur :

Quels flux pouvez-vous exporter : événements utilisateur, événements d’administration, journaux serveur, journaux d’accès HTTP du proxy ?
Par quel transport (syslog, HTTPS, connecteur vers un SIEM précis), dans quel format, avec quel délai ?
Avec quelle rétention côté hébergeur, et avez-vous vous-mêmes accès aux journaux serveur en cas d’incident ?
Peut-on activer les événements d’administration avec le détail des représentations (attention aux données personnelles) ?
Qui investigue un incident de sécurité sur la plateforme, et sous quel délai êtes-vous notifiés ?

Les limites et la réversibilité

Les limites se découvrent souvent trop tard. Demandez-les explicitement :

Limite à demander	Pourquoi
Nombre de realms par instance	Le découpage en realms en dépend (voir le cours sur les realms)
Volumétrie : comptes, sessions simultanées, connexions par seconde, pics	Dimensionnement, campagnes de connexion massives (rentrée, bascule)
Limitation de débit sur l’API d’administration et les endpoints de jetons	Provisionnement en masse, batchs en client credentials
Accès à l’Admin REST API et à `kcadm.sh`	Configuration en code, automatisation
Durées de session et sessions persistantes	Keycloak 26 conserve par défaut les sessions utilisateur en base ; l’hébergeur peut l’avoir modifié
Envoi des e-mails (serveur SMTP, domaine expéditeur)	Vérification d’adresse, réinitialisation de mot de passe, codes par e-mail

Et la réversibilité : si vous quittez l’hébergeur, que récupérez-vous ? La configuration des realms s’exporte. Les comptes avec leurs empreintes de mots de passe, leurs facteurs MFA enrôlés (secrets TOTP, clés WebAuthn) et leurs liens vers les fournisseurs d’identité externes sont une autre affaire. Sans eux, chaque usager devra réinitialiser son mot de passe et réenrôler son facteur. En auto-hébergé, l’export complet (kc.sh export avec les utilisateurs) inclut ces données.

Le tableau « qui fait quoi »

À l’issue de la séance, remplissez un tableau de ce type. Les colonnes sont des responsabilités, pas des hypothèses : toute case non confirmée reste marquée « à vérifier ».

Activité	Hébergeur	Équipe projet IAM	Équipes applicatives
Infrastructure, disponibilité, sauvegardes	à vérifier
Montées de version Keycloak	à vérifier	recette des extensions et thèmes	recette des applications
Configuration des realms, flux, clients	à vérifier
Extensions et thèmes	déploiement : à vérifier	développement, maintenance
Agent ou lien vers l’annuaire	à vérifier
Export des journaux vers le SOC	à vérifier
Raccordement d’une application		validation	configuration côté application

Relisez les grilles de ce cours et marquez les questions qui changent une décision déjà prise ou à prendre (découpage en realms, sources d’utilisateurs, MFA). Ce sont les questions à poser en premier.
Sur le Keycloak du lab, listez ce qui est configurable au niveau serveur, pour savoir quelles options vous demanderez à l’hébergeur d’activer :

docker compose exec keycloak /opt/keycloak/bin/kc.sh start --help | grep -E -- '--(hostname|log|metrics|health|features)'

Dans la console du lab, realm de votre choix, ouvrez Realm settings, onglet Events. Activez « Save events » pour les événements utilisateur et les événements d’administration, connectez-vous avec un utilisateur, puis consultez Events. Notez les champs disponibles : ce sont ceux que le SOC voudra recevoir.
Regardez les journaux du conteneur Keycloak après une connexion échouée (docker compose logs keycloak | grep -i LOGIN_ERROR) et notez si l’événement y apparaît, et sous quelle forme.
Vérifiez que le dossier des extensions est vide sur une image de base (docker compose exec keycloak ls /opt/keycloak/providers). Listez les extensions et thèmes que le projet risque de demander, avec la raison de chacun.
Décrivez en trois lignes la situation réseau de l’annuaire du client : où il est, quels flux sont autorisés, qui les accorde. Préparez la question de l’agent à partir de cette description.
Préparez le tableau « qui fait quoi » avec toutes les cases à « à vérifier » et envoyez la liste de questions à l’hébergeur avant la séance, pour qu’il vienne avec les bonnes personnes.
Après la séance, remplacez chaque « à vérifier » par la réponse obtenue et sa source (compte rendu, contrat, documentation fournie), et reportez les limites dans les entrées « plateforme » des autres cours.

À retenir

Tout ce que dit ce cours sur l’hébergeur est une question, pas une réponse : les réponses viennent de la séance.
Distinguez ce que Keycloak ne sait pas faire de ce que l’offre ne permet pas : la seconde catégorie se négocie.
Quatre sujets changent l’architecture : extensions acceptées ou non, accès à l’annuaire interne, domaine définitif, export des journaux.
Posez la question de la réversibilité, empreintes et facteurs MFA compris, avant de signer.

Capacité	Verdict	Précision
Hébergement, montées de version, supervision et sauvegardes	Hébergeur	Périmètre, calendrier de montée de version et objectifs de restauration à obtenir de l'hébergeur.
Déploiement d'extensions (providers, thèmes) développées par l'équipe projet	Hébergeur	Keycloak les accepte nativement (dossier providers) ; l'hébergeur décide si, comment et à quelles conditions.
Accès à un annuaire LDAP ou AD situé dans le réseau du client	Hébergeur	Keycloak ouvre lui-même la connexion LDAP ; un agent à connexion sortante, un VPN ou un lien privé dépend de l'offre de l'hébergeur.
Environnements (développement, recette, préproduction, production)	Hébergeur	Nombre, isolation, alignement des versions et coût à confirmer.
Domaine personnalisé et certificat	Hébergeur	Keycloak le permet (option hostname) ; la gestion du DNS et du certificat dépend de l'hébergeur.
Export des journaux et des événements vers un SOC	Hébergeur	Formats, transport, délai et rétention à obtenir de l'hébergeur ; un event listener spécifique serait une extension.
Événements de connexion et d'administration	Natif	Enregistrés par realm et consultables dans la console ou par l'Admin REST API, quelle que soit la plateforme.