Dans un groupement hospitalier de territoire (GHT), le déploiement d'un dossier patient informatisé partagé pose des défis d'authentification spécifiques. Le DPI Easily, édité par Hopsis, en est un bon exemple : il exige, pour l'authentification, un format d'identifiant particulier que les briques d'authentification standard ne produisent pas nativement.
L'exigence d'Easily en contexte GHT
Easily attend que l'identifiant transmis lors de l'authentification soit préfixé par le domaine du site d'appartenance de l'utilisateur. Concrètement, un même identifiant de connexion ne suffit pas : il doit être présenté sous une forme qualifiée par le site.
- Pour un utilisateur du site A, l'identifiant attendu est de la forme A\login.
- Pour un utilisateur du site B, l'identifiant attendu est de la forme B\login.
Autrement dit, le même compte doit être présenté à Easily avec un préfixe de domaine différent selon le site auquel l'utilisateur est rattaché. Cette contrainte, indispensable au bon fonctionnement d'Easily dans un GHT multi-sites, n'est pas prise en charge telle quelle par le flux OIDC standard de Keycloak.
Le défi technique
Keycloak, en tant que fournisseur d'identité OIDC, émet des jetons dont les attributs proviennent du référentiel d'identités. Par défaut, il ne construit pas dynamiquement un identifiant préfixé par le domaine du site en fonction du rattachement de chaque utilisateur. Répondre à l'exigence d'Easily supposait donc d'intervenir dans la chaîne d'authentification pour produire, au bon moment, l'identifiant attendu dans le format domaine\login.
Notre réponse : un plugin Keycloak dédié
Nous avons développé une extension Keycloak qui répond précisément à cette méthode d'authentification OIDC exigée par Easily. Le plugin détermine le domaine du site associé à l'utilisateur et compose l'identifiant qualifié attendu par le DPI, de sorte que chaque professionnel soit authentifié avec le préfixe correspondant à son site - A\login, B\login, et ainsi de suite - sans intervention manuelle et sans multiplier les comptes.
Le résultat : un GHT multi-sites qui s'authentifie sur Easily via Keycloak en OIDC, chaque site conservant son préfixe de domaine, dans un flux d'authentification unifié et transparent pour l'utilisateur.
Ce que cela apporte à l'établissement
Cette réalisation permet à un GHT de bénéficier d'une authentification centralisée sur Keycloak tout en respectant les contraintes propres au DPI Easily, sans compromis. Elle s'inscrit dans une démarche plus large de gestion des identités et des accès (IAM) à l'échelle du territoire, où un fournisseur d'identité unique dessert l'ensemble des applications métier, chacune avec ses exigences spécifiques.
Un socle qui s'inscrit dans la conformité RIE / HospiConnect
Au-delà du cas Easily, ce travail conforte le socle d'authentification centralisée du GHT - précisément la brique sur laquelle s'appuie la démarche de conformité au RIE portée par le programme HospiConnect. En consolidant Keycloak comme fournisseur d'identité unique du territoire, capable de desservir même les applications aux exigences les plus spécifiques, on prépare le terrain pour les briques de conformité : authentification forte des professionnels, fédération à Pro Santé Connect et gestion unifiée des identités.
Autrement dit, résoudre l'intégration d'Easily n'est pas un chantier isolé : c'est une étape qui renforce l'architecture IAM sur laquelle repose, in fine, la mise en conformité RIE de l'établissement. Pour approfondir ce cadre réglementaire, consultez notre FAQ HospiConnect & RIE.
Un besoin d'intégration Keycloak ou DPI ?
Nous développons des extensions sur mesure pour répondre aux exigences des logiciels métier de santé.
Demander un diagnostic de 30 min →