Branchassist : migrer un SSO propriétaire vers Keycloak sans déléguer les droits métier

1. Branchet et Branchassist : une identité au service de droits très concrets

L’accès n’a de valeur que s’il respecte l’organisation métier

Branchet intervient dans l’assurance des professionnels de santé. Branchassist est l’application métier qui organise une partie du traitement opérationnel : dossiers de sinistre, missions, tâches, documents et espaces de travail adaptés aux fonctions présentes dans l’organisation.

Cette diversité se retrouve dans le modèle d’accès. Un assistant-conseil, un responsable, un gestionnaire ou un membre du support ne parcourt pas les mêmes écrans et ne manipule pas les mêmes ressources. L’application porte donc une hiérarchie de rôles et des contrôles dédiés aux dossiers, documents, missions, tâches et utilisateurs.

Le SSO historique était relié à cet univers. Une personne arrivait avec un jeton externe ; Branchassist interrogeait le service de jetons, récupérait un identifiant client, retrouvait le partenaire correspondant dans Oracle et déterminait un rôle par défaut à partir des données métier. Cette chaîne fonctionnelle explique pourquoi la migration ne pouvait pas se limiter à brancher une nouvelle URL.

La fiche générale consacrée à l’application Branchassist raconte la plateforme, ses workflows et ses intégrations. Ici, le cadrage est plus étroit : suivre l’identité depuis la redirection vers Keycloak jusqu’à l’ouverture d’une session locale, puis montrer comment les autorisations restent protégées côté métier.

2. Une migration lisible dans la durée

Coexistence, reprise sur Symfony 6, puis durcissement du parcours

La chronologie commence les 31 janvier et 1er février 2022 avec l’intégration du SSO historique. Les étapes sont explicites : authentifier l’application auprès du service externe, contrôler le jeton reçu, rapprocher son identifiant d’un partenaire Oracle, créer ou actualiser l’utilisateur local, puis ouvrir la session avec le rôle calculé.

En septembre 2023, une branche dédiée introduit Keycloak sans supprimer immédiatement l’entrée historique. Le contrôleur accepte alors deux retours distincts : le couple « session_state + code » pour Keycloak et le paramètre « token » pour l’ancien parcours. Cette coexistence observable montre une transition progressive au niveau applicatif, sans permettre d’affirmer une date de bascule globale ou une absence totale d’incident.

Une nouvelle génération de Branchassist démarre en mars 2024. Le SSO fonctionne localement en mai, l’authentification des API est séparée en juin, puis l’entrée applicative redirige directement vers Keycloak en décembre. En avril 2025, la connexion reçoit une trace plus détaillée. Cette progression fournit un récit de réalisation concret sans attribuer au projet un pilotage ou un calendrier contractuel qui ne sont pas établis.

3. Le SSO historique faisait déjà du métier

Derrière le jeton, un partenaire Oracle et un rôle à déterminer

Dans la première génération, Branchassist recevait un jeton de l’utilisateur depuis le SSO de Branchet. L’application commençait par demander son propre jeton d’accès au service externe, puis appelait un point d’information sur le jeton utilisateur. La réponse fournissait notamment l’identifiant client nécessaire à la suite du parcours.

Cet identifiant ne suffisait pas à autoriser la session. Branchassist recherchait le partenaire correspondant dans Oracle. Une absence déclenchait un refus explicite, car une identité connue du SSO ne garantissait pas qu’elle possédait un rattachement valide dans le système métier.

Le rôle par défaut dépendait ensuite de la situation du partenaire. Un gestionnaire recevait le rôle associé ; un autre profil pouvait devenir assistant-conseil ou responsable selon les relations actives présentes dans Oracle. L’utilisateur local était créé ou actualisé avec ses coordonnées, son dernier accès et son jeton. Le SSO et Oracle contribuaient donc chacun à une décision différente.

4. Le vrai risque d’une migration d’identité

Ne pas confondre compte reconnu et action autorisée

Keycloak pouvait remplacer l’étape d’identification, mais pas les règles qui reliaient une personne à l’organisation Branchet. Copier tous les droits dans le fournisseur d’identité aurait créé une deuxième source de vérité, exposée aux décalages avec Oracle et l’état réel des utilisateurs dans Branchassist.

L’arbitrage a consisté à séparer deux plans. Le fournisseur d’identité assure le parcours externe et délivre les jetons. L’application conserve son utilisateur, son état actif, ses rôles, sa hiérarchie et ses décisions d’accès aux ressources. Le retour Keycloak ne devient jamais, à lui seul, un passe-partout.

Cette frontière facilite aussi le diagnostic. Un échec de dialogue avec le fournisseur, un identifiant absent, un compte interne inconnu et un compte désactivé ne racontent pas le même problème. Les traiter séparément évite de masquer toutes les erreurs derrière un générique « identifiants incorrects ».

5. Faire coexister deux chemins d’entrée

La transition Keycloak apparaît avant la disparition du parcours historique

La première intégration Keycloak de septembre 2023 ne supprime pas brutalement l’ancien chemin. Sur le même point d’entrée, Branchassist reconnaît le retour Keycloak à la présence d’un état de session et d’un code d’autorisation. Le retour historique reste, lui, associé à un jeton transmis à l’application.

Le nouveau chemin échange le code, appelle les services associés à Keycloak, retrouve le partenaire puis construit l’utilisateur applicatif. L’ancien continue de passer par le service SSO propriétaire. Cette coexistence permet au produit d’intégrer le nouveau protocole sans réécrire au même instant toutes les règles de rattachement et de rôle.

Il serait excessif d’en déduire une bascule sans incident ou une durée contractuelle. Ce que cette étape établit, c’est une stratégie de compatibilité dans l’application : deux formats d’entrée clairement distingués et une destination commune, la session Branchassist.

6. Le parcours Keycloak en quatre étapes

Rediriger, échanger, contrôler, ouvrir la session

Dans la génération Symfony 6, un visiteur sans retour d’authentification est redirigé vers l’URL Keycloak configurée avec l’identifiant client, un type de réponse par code et l’URL de retour. Branchassist n’affiche plus d’étape de saisie intermédiaire sur ce chemin.

Au retour, l’application attend l’état de session et le code. Elle envoie ensuite ce code au point de jeton avec le type d’autorisation correspondant, l’identifiant client, son secret et l’URL de redirection. L’accès et le renouvellement reviennent dans la réponse du fournisseur.

Branchassist contrôle alors les informations nécessaires au rattachement, recherche l’utilisateur interne et vérifie son activation. Seulement après ces contrôles, l’application crée le jeton de sécurité Symfony, l’enregistre dans la session et dirige l’utilisateur vers son tableau de bord.

7. Échanger un code, pas un mot de passe

Le secret utilisateur reste hors de l’application métier

Le parcours navigateur utilise le mécanisme du code d’autorisation. L’utilisateur se présente auprès de Keycloak ; Branchassist reçoit un code temporaire ; le serveur applicatif l’échange contre les jetons avec ses propres paramètres client. Le mot de passe de la personne n’est pas collecté par le formulaire Branchassist.

Cette organisation réduit la responsabilité de l’application métier sur la saisie des identifiants. Elle ne dispense pas de sécuriser le client, son secret, l’URL de retour, les jetons ou la session, mais elle évite de recréer localement une authentification que le fournisseur d’identité doit porter.

Pour comprendre la répartition entre identité et autorisation, la page intégration OpenID Connect détaille les notions de fournisseur, client, retour et informations d’identité. Branchassist illustre leur raccordement à une application existante.

8. Retrouver l’utilisateur interne

Une identité Keycloak ne crée pas automatiquement un droit Branchassist

La génération la plus récente récupère l’identifiant préféré porté par le jeton et cherche l’utilisateur correspondant dans Branchassist. Si aucun compte n’existe, le parcours s’arrête. Il s’arrête également si ce compte est présent mais désactivé.

Ce choix est important : le fournisseur d’identité émet les informations d’identité, tandis que Branchassist maîtrise la population réellement admise dans l’outil. Une création de compte ou une désactivation peut ainsi suivre les règles internes sans dépendre d’un rôle générique transmis par le SSO.

Les premières itérations Keycloak étaient davantage orientées vers le rapprochement dynamique avec le partenaire et pouvaient créer l’utilisateur local à partir des informations métier. La version plus récente privilégie l’existence préalable d’un compte actif. Cette évolution durcit la frontière : une identité reconnue ne déclenche pas automatiquement l’ouverture d’un compte Branchassist.

9. Conserver les rôles dans Branchassist

L’identité vient de l’extérieur, la hiérarchie reste applicative

Branchassist conserve les rôles utilisés par Symfony. Le rôle de responsable hérite de celui d’assistant-conseil ; les rôles d’assistant-conseil, de gestionnaire et de support héritent de l’accès utilisateur ; le super-administrateur rassemble plusieurs capacités supplémentaires.

Cette hiérarchie dirige les grandes zones de l’application. Les chemins destinés aux assistants-conseils, aux gestionnaires, à l’administration et aux API possèdent leurs exigences propres. Le même succès Keycloak peut donc mener à des expériences différentes selon le compte interne.

L’avantage observable est la cohérence : les contrôleurs, menus, espaces de travail et règles de ressource s’appuient sur le même modèle applicatif. Modifier le fournisseur d’identité ne force pas à réinterpréter tous les droits métier sous forme de groupes externes.

10. Protéger chaque ressource métier

Cinq contrôles spécialisés prolongent les rôles généraux

Un rôle de zone ne suffit pas pour une application de dossiers. Branchassist possède cinq contrôles spécialisés pour les dossiers, documents, missions, tâches et utilisateurs. Ils permettent de décider l’accès au niveau de la ressource manipulée, au-delà du simple droit d’ouvrir une rubrique.

Cette deuxième ligne de défense est structurante. Une personne peut avoir le bon rôle général sans être autorisée à consulter n’importe quel dossier ou document. L’autorisation reste donc liée au contexte métier, là où l’application connaît les relations entre utilisateur, mission et objet demandé.

C’est aussi pourquoi une architecture d’authentification et de sécurité doit être pensée avec le produit. Le SSO ouvre un parcours ; les règles applicatives en contrôlent chaque étape sensible.

11. Refuser proprement les accès incohérents

Chaque rupture du parcours possède une issue explicite

L’échange du code peut échouer. L’émetteur attendu peut ne pas correspondre. L’identifiant utilisateur peut manquer. Le compte local peut être introuvable ou inactif. Branchassist distingue ces familles d’échec avant de créer la session Symfony.

Lorsqu’un jeton a déjà été obtenu mais que le rattachement échoue, l’application appelle la déconnexion Keycloak avant de présenter l’erreur. Elle évite ainsi de conserver volontairement une session externe après avoir refusé la session métier.

L’utilisateur est dirigé vers une page d’erreur plutôt que vers un espace partiellement initialisé. Cette logique ne prouve pas qu’aucun incident ne peut survenir ; elle montre que les états d’échec principaux ont une sortie prévue et qu’un refus n’est pas transformé en session dégradée.

12. Gérer les jetons jusqu’à la déconnexion

Accès, renouvellement, révocation et nettoyage local

Après une connexion admise, Branchassist associe à l’utilisateur le jeton d’accès, le jeton de renouvellement et leur date d’enregistrement. Le jeton d’accès accompagne ensuite certains échanges avec le système métier connecté.

Lorsque ce jeton doit être renouvelé, le service Keycloak appelle le point de jeton avec le type de renouvellement, l’identifiant client, son secret et le jeton prévu à cet effet. Les nouvelles valeurs remplacent les précédentes avant la poursuite de l’appel distant.

La déconnexion appelle le point prévu par Keycloak avec le jeton de renouvellement, efface les jetons et leur date dans Branchassist, retire le jeton de sécurité local puis redirige vers l’entrée. La session externe et l’état applicatif sont traités dans le même parcours.

13. Séparer la session web et l’accès API

Deux canaux, deux mécanismes et une même base d’utilisateurs

L’application ne réutilise pas indistinctement le parcours navigateur pour ses API. Le pare-feu principal gère la session web. Un pare-feu sans état protège séparément les chemins API et s’appuie sur un gestionnaire de jeton d’accès dédié.

Ce gestionnaire recherche un jeton porteur enregistré pour un utilisateur et refuse les identifiants inconnus. Les routes API exigent ensuite le rôle utilisateur. Cette voie est distincte du code d’autorisation Keycloak reçu par le navigateur.

La séparation évite un raccourci fréquent : croire qu’un SSO web résout automatiquement l’authentification de toutes les intégrations machine à machine. Dans Branchassist, chaque canal possède son point d’entrée et son mode de contrôle, même s’ils convergent vers le modèle local d’utilisateur.

Cette répartition combine OpenID Connect pour l’identité et OAuth 2.0 pour l’autorisation des API, tout en laissant à Branchassist la décision finale sur les droits métier.

14. Supprimer la fausse étape de connexion locale

Décembre 2024 : l’entrée devient une redirection directe

La première version Symfony 6 conservait encore une page de connexion avec un lien vers le fournisseur. Le 9 décembre 2024, l’entrée est remaniée pour rediriger directement vers Keycloak lorsqu’elle ne traite pas déjà un retour d’autorisation.

Ce changement simplifie le chemin mental de l’utilisateur : il n’a plus à comprendre pourquoi une application affiche une page qui ne fait que l’envoyer vers une autre page. Branchassist assume clairement que l’authentification interactive commence chez le fournisseur d’identité.

Une page d’erreur distincte reste disponible lorsque l’échange ou le rattachement ne peut pas aboutir. La simplification de l’entrée n’efface donc pas les cas d’échec ; elle retire seulement une étape qui n’ajoutait aucune décision métier.

15. Tracer connexion et déconnexion

Donner au support un contexte exploitable sans promettre une supervision totale

Une connexion réussie produit un événement applicatif. La version enrichie en avril 2025 associe l’utilisateur, la date, l’adresse réseau, l’agent utilisateur, le navigateur et sa version, le système d’exploitation ainsi que le type d’appareil détecté.

Le parcours général enregistre également les réussites de connexion et de déconnexion dans le suivi applicatif. Ces traces permettent de replacer un accès dans son contexte et d’explorer l’activité depuis les écrans de suivi prévus à cet effet.

La présence de ces informations ne vaut ni détection automatique de toutes les menaces ni engagement de conservation. Elle apporte toutefois une base concrète pour répondre à des questions opérationnelles : quel compte, à quel moment, depuis quel environnement déclaré et avec quelle issue.

16. Une évolution en deux générations

Les étapes techniques racontent mieux le projet qu’un planning inventé

La première génération établit le parcours SSO historique au début de 2022. En septembre 2023, Keycloak arrive par étapes : adaptation de l’authentification des utilisateurs, travail sur le SSO, appels au système Compassur et déconnexion externe finalisée le 25 septembre.

La deuxième génération repart sur Symfony 6 en mars 2024. Les jalons visibles sont le fonctionnement du SSO les 14 et 16 mai, l’ajout d’un canal d’authentification API le 17 juin, la redirection directe vers Keycloak et l’ajustement des règles du pare-feu les 9 et 12 décembre.

En avril 2025, les événements de connexion sont enrichis pour le suivi. La version suivie jusqu’au 13 juin 2025 conserve l’échange du code, le contrôle de l’utilisateur actif, les jetons, les rôles, les cinq contrôles de ressource et la révocation. Cette chronologie montre un socle maintenu, sans transformer les dates en durée de prestation.

17. Ce que le projet permet aujourd’hui

Des gains observables dans le parcours et dans la maintenance

Le premier gain est la lisibilité du parcours. L’utilisateur entre par Keycloak, Branchassist traite le retour, contrôle son compte interne puis ouvre son espace. L’application métier ne demande plus un mot de passe qu’elle n’a pas vocation à vérifier sur cette entrée.

Le deuxième gain est la maîtrise des autorisations. Un compte externe valide ne contourne ni l’activation locale, ni la hiérarchie de rôles, ni les contrôles portant sur les dossiers, documents, missions, tâches et utilisateurs. L’identité centralisée n’efface pas les règles spécifiques à Branchet.

Le troisième gain est opérationnel : les refus ont des catégories distinctes, les jetons peuvent être renouvelés et révoqués, et les connexions laissent un contexte exploitable. Aucun chiffre public ne permet d’en déduire une baisse d’incidents ou un temps de support économisé ; la capacité à comprendre et gérer ces états, elle, est directement présente.

18. Les limites qui restent à cadrer

Une intégration IAM ne remplace pas une revue de sécurité

Cette réalisation ne doit pas être présentée comme une certification Keycloak ou OpenID Connect. Elle décrit une intégration applicative précise, avec ses contrôles et son cycle de session. Une revue de sécurité dédiée devrait évaluer séparément la configuration du fournisseur, la validation cryptographique, les audiences, les secrets, les durées de jeton et les politiques d’exploitation.

La coexistence de deux chemins en 2023 établit une transition applicative, pas une continuité absolue à l’échelle de toute l’organisation. Une migration réelle doit aussi suivre la population basculée, l’extinction de l’ancien fournisseur, les erreurs de connexion et les procédures de retour arrière.

La prochaine étape de qualité consiste à rendre automatiques les scénarios propres au fournisseur d’identité : retour valide, émetteur inattendu, compte absent, compte inactif, révocation et renouvellement. Ces contrôles compléteraient utilement les garde-fous déjà présents sans les confondre avec une garantie d’absence d’incident.

19. Quand reproduire cette architecture

Un modèle utile lorsque l’application possède déjà sa propre vérité métier

Cette séparation convient aux applications où l’annuaire sait identifier les personnes mais où les permissions dépendent de données locales : portefeuille de dossiers, rattachement à une équipe, mandat, statut du compte, rôle temporaire ou relation avec une entité métier.

Le cadrage doit alors distinguer le parcours interactif, les appels API, les comptes techniques, la création des utilisateurs, les règles de désactivation, la hiérarchie des rôles, les contrôles par ressource, le renouvellement, la révocation et les traces nécessaires au support.

Dawap aborde ces sujets comme une intégration Keycloak dans un système existant, pas comme l’ajout isolé d’un logiciel. Lorsque les règles d’accès sont indissociables des dossiers et workflows, le chantier rejoint naturellement le développement d’application métier.