Keycloak en cluster pour un GHT : fédération d'identité multi-établissements sans modifier les Active Directory

Dans un Groupement Hospitalier de Territoire, la gestion des identités est un défi structurant : chaque établissement membre dispose de son propre Active Directory, de ses propres utilisateurs, et souvent de ses propres applications métier. Mettre en place un fournisseur d'identité commun sans perturber l'organisation en place de chaque site - c'est exactement le défi que nous avons relevé avec Keycloak.

Le défi du GHT : plusieurs Active Directory, zéro collision

Dans un GHT multi-établissements, la tentation est parfois de fusionner les annuaires Active Directory en un seul. C'est une approche risquée : elle impose des migrations lourdes, crée des risques de collision entre comptes utilisateurs portant les mêmes identifiants sur des établissements différents, et touche à l'organisation de chaque site.

Nous avons fait le choix inverse : fédérer les Active Directory existants dans Keycloak sans les modifier. Chaque établissement conserve son propre annuaire, son organisation, ses comptes. Keycloak agrège ces identités et résout les collisions potentielles en les traitant à son niveau, sans aucun impact sur les AD en place.

Pas une seule modification des Active Directory existants. Chaque établissement conserve son annuaire, son organisation, ses habitudes. Keycloak fédère, sans imposer.

Le raccordement OIDC de toutes les applications compatibles

Une fois Keycloak positionné comme fournisseur d'identité du GHT, toutes les applications prenant en charge le protocole OIDC (OpenID Connect) ont été raccordées à la plateforme. Chaque application délègue désormais l'authentification à Keycloak : les utilisateurs se connectent avec leurs identifiants habituels, quel que soit le site, et accèdent à l'ensemble des applications autorisées via un fournisseur d'identité unique.

Ce raccordement unifié simplifie la gestion des accès : une révocation dans l'Active Directory d'un établissement se répercute immédiatement sur l'ensemble des applications raccordées, sans avoir à gérer chaque application séparément.

Un cluster Keycloak pour la haute disponibilité

Pour un GHT, la disponibilité de la plateforme d'identité est non négociable : si Keycloak est indisponible, l'authentification de l'ensemble des applications raccordées est bloquée. Nous avons déployé Keycloak en mode cluster : plusieurs nœuds actifs assurent la continuité du service même en cas de défaillance d'un nœud. La charge est répartie entre les nœuds, et la session d'un utilisateur est maintenue quelle que soit l'instance qui la traite.

Déploiement et mises à jour par Ansible, sans interruption de service

L'ensemble du déploiement du cluster Keycloak a été réalisé avec Ansible, via des playbooks reproductibles et documentés. Ce choix apporte plusieurs garanties :

• le déploiement est reproductible à l'identique sur chaque nœud du cluster ;
• la configuration est versionnée et traçable ;
• les mises à jour de Keycloak sont appliquées nœud par nœud via Ansible, en maintenant le cluster en service - aucune interruption de connexion pour les utilisateurs pendant la mise à jour.

Cette dernière capacité est particulièrement précieuse en milieu hospitalier : une mise à jour de la plateforme d'identité peut être réalisée en journée, sans fenêtre de maintenance, sans impact sur les soignants connectés.

Une mise à jour de Keycloak sans que les utilisateurs connectés ne s'en aperçoivent - nœud par nœud, sans interruption de service. C'est ce que permet la combinaison cluster + Ansible.

Ce que cette architecture apporte au GHT

Cette plateforme constitue le socle d'identité du GHT. Elle apporte :

• un fournisseur d'identité unique pour l'ensemble des établissements et applications du groupement ;
• une authentification uniforme pour les utilisateurs, quel que soit leur établissement d'appartenance ;
• une base pour la conformité RIE / HospiConnect : Keycloak peut être raccordé à Pro Santé Connect pour l'authentification forte des professionnels de santé ;
• une gouvernance centralisée des accès : révocations, délégations et règles de sécurité appliquées depuis un point unique.

Une expertise construite depuis 2020, une fiabilité prouvée dans la durée

Nous avons commencé à travailler sur Keycloak dès 2020, bien avant que la plateforme ne devienne le standard de facto de l'IAM hospitalier. Cette antériorité nous a permis de construire une expertise solide : les cas limites, les subtilités de configuration, les pièges de la montée en charge - nous les avons rencontrés et résolus.

Depuis la mise en production des plateformes que nous avons déployées, aucun incident n'a été enregistré. Ce n'est pas un hasard : la stabilité est le produit d'une architecture soignée, d'un déploiement maîtrisé et d'une politique de maintenance active. Nous appliquons les mises à jour dès que de nouvelles versions de Keycloak sont disponibles, via Ansible, sans interruption de service - ce qui maintient les plateformes à jour et sécurisées en permanence.

Depuis 2020, zéro incident sur les plateformes Keycloak que nous opérons. Des mises à jour régulières, sans coupure, et une architecture qui tient dans la durée.