Ariovis
Conseil d'expert — Access Management, CIAM et autorisation fine

Votre métier n'a pas déployé Keycloak pour refaire votre SSO

Il cherchait à décider ce que l'utilisateur pouvait faire après sa connexion. Retour d'expérience d'un architecte IAM senior Ariovis sur les Keycloak, serveurs OAuth et bases d'habilitations que l'on découvre en marge du SSO d'entreprise — non pour les condamner, mais pour comprendre le besoin d'autorisation qu'ils révèlent.

La réunion d'architecture qui ne parlait pas d'authentification

En réunion d'architecture, l'équipe IAM découvre un Keycloak déployé par une équipe produit. La première question, presque réflexe, aurait pu être : « Qui vous a autorisés à installer un second fournisseur d'identité ? » Le consultant Ariovis pose autre chose : « Quelle décision votre application devait-elle prendre ? »

L'équipe explique alors que le SSO central authentifie déjà correctement les utilisateurs ; que l'annuaire fournit leur identité et leur organisation ; que l'application doit aussi connaître leurs produits, leurs rayons ou leurs périmètres ; que ces informations n'existent pas dans le LDAP ; et qu'aucun service central ne permettait de les utiliser dans une politique. Keycloak a été choisi pour enrichir le jeton et livrer l'application à temps.

Le consultant reconnaît d'abord la légitimité du besoin. Il examine ensuite les conséquences : la taille et la fraîcheur des jetons, la duplication des données, les règles locales, la révocation, l'exploitation, l'audit et la multiplication possible de la même architecture. La discussion ne cherche pas à opposer le métier à l'IAM. Elle cherche à construire une meilleure réponse commune.

Le métier avait résolu son problème de livraison. Notre rôle était désormais de l'aider à transformer cette solution locale en une capacité durablement sécurisée.

Le SSO sait qui, l'application cherche encore quoi

Une entreprise fonctionne parce que ses métiers vendent, produisent, soignent, transportent, conseillent, financent, construisent, administrent et servent leurs clients et leurs usagers. La cybersécurité et l'IAM ne constituent pas une finalité autonome : ils doivent permettre à ces activités de fonctionner avec un niveau de risque maîtrisé. C'est le sens que nous donnons, chez Ariovis, à Security Meets Business.

Lorsqu'une équipe métier déploie son propre Keycloak, enrichit un jeton ou développe une logique locale d'habilitation, notre première réaction n'est donc pas de dire qu'elle n'a pas respecté notre architecture. Nous demandons d'abord : quelle opération métier devait-elle rendre possible, et quelle réponse le dispositif IAM central ne lui apportait-il pas ? Security Meets Business signifie que nous ne sécurisons pas une architecture contre les métiers. Nous construisons avec les métiers une architecture qui leur permet d'agir en sécurité.

Le SSO central sait établir, souvent très bien, une série d'informations solides : l'identité de la personne, son employeur, sa structure, son adresse électronique, quelques groupes, quelques rôles globaux, le niveau d'authentification et le contexte de session. L'audience et les scopes du jeton donnent à l'application des repères stables. Ces informations peuvent suffire à ouvrir une session, appliquer une politique d'accès générale et transmettre quelques claims d'identité utiles.

L'application, elle, a souvent besoin d'une décision plus précise. Cette personne peut-elle réaliser cette action précise sur cette ressource métier ? Pour répondre, il faut connaître les produits qu'elle gère, les rayons auxquels elle est affectée, les magasins dans lesquels elle peut intervenir, les clients de son portefeuille, les contrats dont elle est responsable, les montants qu'elle peut valider, la classification des données qu'elle consulte, le projet auquel une ressource est rattachée, la finalité de l'action. Ces informations ne sont pas des données d'identité. Elles appartiennent au métier.

Introduire cette distinction, à ce moment de l'atelier, change souvent le ton. Le SSO sait généralement nous dire qui se présente. L'application cherche encore à savoir ce que cette personne peut faire avec ses propres objets métier. Tant que cette phrase n'est pas partagée, l'équipe IAM et l'équipe produit parlent de deux problèmes différents en croyant parler du même.

Il faut alors résister à une seconde tentation, symétrique de la première : présenter le Shadow IAM comme la faute exclusive de l'équipe applicative. Lorsqu'un métier contourne le dispositif central, plusieurs causes coexistent presque toujours. Le service IAM ne répond pas assez vite. Le catalogue de services ne couvre que l'authentification. Le modèle de rôles est trop grossier pour la décision attendue. Les données métier ne sont pas accessibles au moteur de décision. Aucun mécanisme d'autorisation fine n'est proposé. L'équipe IAM n'a pas été associée assez tôt. Le métier ne sait pas à qui présenter son besoin. Et l'application doit tenir une date de livraison.

Le contournement crée bien une dette, une duplication, une difficulté d'audit et une surface supplémentaire à maintenir. Mais il révèle en même temps que le besoin était réel. Le Shadow IAM est rarement le signe qu'un métier ne veut pas de sécurité. Il est souvent le signe qu'il n'a pas trouvé, dans le dispositif existant, une sécurité compatible avec son activité. Nous n'excusons pas pour autant toutes les architectures locales : certaines doivent être corrigées. La correction commence simplement par la compréhension du besoin, pas par la suppression autoritaire du composant.

La sécurité ne doit pas devenir une administration parallèle du métier

Pour éviter les Keycloak locaux, une organisation peut être tentée de faire remonter dans l'annuaire central tous les produits, tous les rayons, tous les magasins, tous les contrats, tous les clients, toutes les délégations, toutes les classifications et toutes les limites de validation. Cette solution semble redonner le contrôle à l'IAM. Elle transforme surtout l'équipe IAM en administratrice d'un ensemble de données qu'elle ne possède pas et qu'elle ne peut pas maintenir correctement.

Les référentiels métier doivent rester placés sous la responsabilité de ceux qui connaissent leur signification, leur cycle de vie, leur qualité, leur fréquence d'évolution et leurs règles de confidentialité. Le rôle de l'IAM consiste à permettre à une politique d'autorisation de consommer ces informations de manière maîtrisée, sans les déplacer ni les réécrire à la place du métier.

Security Meets Business ne signifie pas absorber le métier dans l'IAM. Cela signifie permettre à l'IAM et au métier de prendre ensemble une décision sans confondre leurs responsabilités.

Le rôle d'Ariovis dans cette rencontre

Ariovis intervient comme traductrice entre plusieurs mondes. Avec les métiers, nous cherchons à comprendre l'action à réaliser, la ressource concernée, les conséquences d'une mauvaise décision, les exceptions légitimes, la fréquence des changements, les besoins de délégation et les exigences de délai. Nous ne demandons pas aux équipes métier de formuler leur besoin en vocabulaire IAM ; nous leur demandons de décrire l'opération qu'elles veulent rendre possible.

Avec l'équipe IAM, nous identifions ce qui relève de l'identité, de l'IGA, de l'authentification, du jeton, des rôles durables, du cycle de vie et de la revue d'accès. Nous clarifions ce que le dispositif central peut déjà fournir et ce qui dépasse naturellement son périmètre.

Avec les architectes et les développeurs, nous déterminons où la décision doit être prise, quelles données sont nécessaires, où placer le Policy Enforcement Point, comment interroger les référentiels, comment gérer la latence, comment tracer la décision et comment traiter l'indisponibilité d'une source.

Avec la sécurité, nous vérifions que la règle ne peut pas être contournée, que les données exposées restent limitées, que les droits sont révocables, que les décisions sont auditables et que l'architecture reste exploitable.

Notre valeur n'est pas de demander au métier de parler le langage de l'IAM. Elle est de transformer son besoin en une architecture que la sécurité, les applications et l'exploitation peuvent réellement porter.

L'autorisation fine comme service rendu au métier

L'autorisation fine et le PBAC ne sont pas une sophistication imposée par les architectes. Ils deviennent pertinents lorsqu'ils permettent d'exprimer directement une règle métier comme : « Cette responsable peut modifier le prix de ce produit parce qu'il appartient à son rayon, dans le magasin qu'elle gère, pendant la période où sa délégation est active et dans la limite du montant qui lui est accordé. » Cette règle est plus proche du besoin réel que l'ajout de centaines de groupes, la copie du catalogue dans LDAP, un jeton contenant toute la liste des produits ou une règle différente codée dans chaque application.

L'IGA continue de gouverner les rôles et délégations durables. Le SSO continue d'authentifier et d'émettre les jetons. Les référentiels métier continuent de décrire les produits, les magasins et les contrats. Le moteur PBAC assemble ces informations lorsque l'action est demandée, sans les déplacer ni les réécrire.

L'autorisation fine n'est pas là pour rendre l'architecture plus élégante. Elle est là pour permettre au métier d'exprimer sa règle sans devoir reconstruire lui-même une plateforme IAM.

Ce que le Shadow IAM prend en charge lorsqu'on le regarde de près

Nous décrivons ici les formes concrètes que nous rencontrons sur le terrain. Chacune est une réponse locale à un besoin réel. Aucune, prise isolément, ne mérite d'être condamnée. Toutes finissent par poser une question de gouvernance et de coût dès qu'elles se multiplient dans le paysage applicatif.

  1. 01

    Un Keycloak qui fédère plus qu'il n'authentifie

    L'équipe applicative déploie un realm Keycloak dédié. Le SSO central authentifie l'utilisateur. Keycloak agit comme Identity Broker, reçoit l'identité, complète le jeton avec des claims applicatifs : store_ids, department_ids, product_categories, approval_limit, business_roles, legal_entities. C'est un usage parfaitement légitime des Protocol Mappers et de l'enrichissement de tokens. Ping Identity, Okta ou Entra ID savent également faire cela. La question n'est pas l'éditeur. La question est de savoir pourquoi l'équipe a estimé devoir posséder sa propre couche de calcul.

  2. 02

    Un jeton qui devient un référentiel portatif

    Un cas d'usage supplémentaire arrive, puis un autre. Le jeton grossit. Il ne transporte plus seulement une identité, une audience et quelques scopes. Il transporte une représentation détaillée de la relation entre la personne et les ressources métier. Le Token Bloat se manifeste dans les proxys, les journaux, parfois les navigateurs. Une information utile à une API n'a pas nécessairement à être communiquée à toutes les applications recevant le même token. La fraîcheur devient délicate : un produit qui change de rayon, une délégation retirée, un montant révisé — les jetons déjà émis ne se réécrivent pas. À partir d'un certain point, le jeton ne transporte plus une autorisation. Il transporte une copie temporaire du modèle métier nécessaire pour la recalculer.

  3. 03

    Des règles codées à l'intérieur de l'application

    Toutes les équipes ne déploient pas Keycloak. Certaines reçoivent l'identité, puis reconstituent seules la décision. L'application appelle l'annuaire, le CRM, l'ERP, un référentiel de magasins, une base de délégations, un service de classification. Elle code alors une règle du type : autoriser la modification si l'utilisateur est responsable, si le produit appartient à son rayon, si le magasin correspond à son périmètre et si la remise reste inférieure à son plafond. La règle fonctionne. Mais chaque application développe son propre moteur, ses propres connecteurs, son propre cache, sa propre interprétation. La politique d'entreprise devient la somme d'implémentations qui ne se connaissent pas.

  4. 04

    Une table locale d'habilitations qui devient un mini-IGA

    Une autre équipe crée une base locale : un utilisateur, une application, une ressource, un rôle, une date de début, une date de fin. L'intention est modeste. Puis il faut gérer les arrivées, les mobilités, les départs, les délégations, les demandes, les validations, les retraits, les audits, les comptes sans propriétaire, les droits historiques. Le Shadow IAM apparaît souvent lorsque l'équipe applicative commence par ajouter un claim et finit par gérer un cycle de vie complet qu'elle n'avait jamais prévu d'exploiter. Ce qui devait être une table devient un composant d'Identity Governance non gouverné.

  5. 05

    Un annuaire à qui l'on demande d'être le jumeau de l'entreprise

    Face à ces difficultés, une tentation apparaît : élargir le contenu du LDAP ou de l'Active Directory. Ajouter les magasins, les rayons, les catégories de produits, les contrats, les portefeuilles clients, les délégations. Un annuaire d'identité n'est pas le jumeau numérique de toute l'entreprise. Nous ne rendons pas l'autorisation plus simple en transformant le LDAP en immense puits de données métier. Nous déplaçons seulement la complexité vers un référentiel qui n'a pas été conçu pour la porter, avec des cycles de synchronisation, des logiques de nommage et une exposition inadaptés à des Business Data changeantes.

  6. 06

    Des coûts diffus, difficiles à chiffrer, faciles à observer

    Nous n'inventons pas de nombre d'instances ni de montants. Nous constatons des postes concrets : infrastructure, haute disponibilité, mises à jour, correctifs, supervision, sauvegardes, secrets, certificats, pipelines, expertise, documentation, support, procédure de reprise, migration lors d'un changement de version. À cela s'ajoutent les coûts moins visibles : compréhension des règles, maintenance des protocol mappers, correction des divergences, revue des claims, investigation des décisions, réconciliation avec les sources, audit, explication des refus. Le problème n'est pas le coût d'une instance isolée. Il vient du nombre d'endroits dans lesquels l'organisation doit comprendre, corriger et prouver la même politique.

  7. 07

    Une gouvernance qui s'arrête à l'écran de connexion

    Le point qui revient le plus souvent n'est pas technique. Le métier ne bypass pas toujours la gouvernance parce qu'il la refuse. Il la bypass parfois parce que la gouvernance s'est arrêtée à l'écran de connexion. Le catalogue de services IAM propose l'authentification, la fédération, le MFA, quelques rôles globaux. Il ne dit pas comment exprimer un besoin d'autorisation fine, comment intégrer une donnée métier, comment obtenir un Policy Decision Point mutualisé, comment placer un Policy Enforcement Point dans une API existante. L'équipe applicative répond avec ce qu'elle a. Elle a Keycloak et du code.

N'en voulons pas au métier d'avoir un cas d'usage. S'il a contourné le service IAM, il faut d'abord vérifier si ce service lui offrait réellement une réponse. Changer l'éditeur du serveur de jetons ne résout pas un besoin d'autorisation qui n'a jamais été pris en charge comme un service d'entreprise.

Quatre responsabilités qu'il faut distinguer sans les opposer

Le Shadow IAM se dissout rarement par une décision de suppression. Il se dissout lorsque chaque acteur retrouve sa responsabilité et cesse de porter celle des autres. Nous décrivons ici les quatre domaines à séparer clairement, avec les composants sur lesquels Ariovis intervient au quotidien.

Identity Governance
L'IGA gouverne dans la durée : l'existence de l'identité, son cycle de vie, ses rôles structurels, ses habilitations, les demandes, les validations, les revues d'accès, les retraits, les preuves. Netwrix Identity Manager porte cette fonction dans plusieurs de nos clients. C'est là que se traitent les Entitlements durables et les rôles gouvernés, pas dans un protocol mapper.
Access Management et fédération
La plateforme d'Access Management authentifie, fédère, gère les sessions, applique le MFA, émet les jetons, transmet les Identity Claims utiles et gère les audiences et scopes. Ping Identity est notre partenaire technologique de référence dans ce domaine. Nous intervenons également sur Microsoft Entra ID, Okta ou Keycloak lorsque le contexte le justifie, sans chercher à imposer un éditeur unique.
Référentiels métier
Le catalogue produit, le référentiel de magasins, la base clients, la gestion des contrats, la classification documentaire, le catalogue de données, la gestion des projets, les délégations opérationnelles restent propriétaires de leurs propres données. Ils n'ont pas vocation à être copiés durablement dans le LDAP ou empaquetés dans un jeton. Ils exposent ces données via des API pilotables au moment de la décision, comme Policy Information Points.
Autorisation fine — PBAC
La couche d'autorisation détermine, au moment de l'action, quel sujet agit, quelle action est demandée, sur quelle ressource, dans quel contexte, selon quelle politique. Une architecture PBAC comporte typiquement un Policy Decision Point pour évaluer la politique, plusieurs Policy Information Points pour fournir les attributs, un Policy Enforcement Point situé dans l'application, l'API ou l'API Gateway pour appliquer la décision. Notre partenariat avec Axiomatics nous permet de traiter le problème que le Shadow IAM révèle : non pas seulement émettre un meilleur jeton, mais construire un service d'autorisation que les applications peuvent réellement consommer.
L'application métier elle-même
L'application connaît des choses que les autres composants ignorent : l'objet touché, l'action précise, le contexte immédiat, l'endroit où le refus doit être appliqué. Elle n'est pas une cible passive de l'autorisation. Elle en est un acteur. Une architecture réussie prévoit un point d'application clair côté application, et n'espère pas qu'un composant externe devine ce que seul le code applicatif sait.
Le rôle du programme IAM interne
L'objectif du programme IAM n'est pas de posséder toutes les règles. Il est d'offrir un cadre dans lequel une règle métier peut être exprimée, appliquée et maintenue sans reconstruire une nouvelle chaîne d'identité. Selon le besoin, la bonne réponse peut être un claim standard, un rôle gouverné par l'IGA, un scope OAuth, une intégration avec un référentiel, un service d'enrichissement, une politique PBAC, un PDP mutualisé, un modèle de PEP, une architecture de délégation ou une simple recommandation applicative.

Un jeton limité n'est pas un jeton pauvre

Le débat ne consiste pas à retirer tous les claims d'un access token. Un jeton peut légitimement contenir le sujet, l'émetteur, l'audience, la durée de validité, les scopes, certains rôles, le niveau d'authentification et quelques attributs stables nécessaires à la ressource. Un bon jeton donne à l'API les informations dont elle a besoin pour reconnaître la capacité présentée. Il n'a pas nécessairement à contenir toutes les données permettant de recalculer chaque décision métier. L'ID token et l'access token n'ont d'ailleurs pas la même vocation : le premier renseigne le client sur l'authentification de l'utilisateur, le second est destiné à la ressource protégée. Ne pas encourager les applications à utiliser indistinctement l'ID token comme matrice universelle d'habilitations.

L'enrichissement du jeton reste une bonne réponse dans un ensemble de cas très concrets : lorsque les informations sont peu nombreuses, relativement stables, peu sensibles, avec une durée de validité compatible avec celle du token, et lorsque la règle concerne une seule application. Un jeton indiquant qu'un collaborateur est rattaché au magasin 013 avec le rôle store_manager suffit souvent à ouvrir un espace de gestion. Tous les claims ne sont pas du Shadow IAM. Le problème commence lorsque le token devient le seul endroit capable d'expliquer une politique métier complexe.

L'autorisation fine devient pertinente lorsque la décision dépend de la ressource précise, de l'action précise, d'un contexte dynamique, de plusieurs référentiels, de données changeant plus vite que la durée du token, d'une délégation temporaire, d'un montant, d'une classification, d'une finalité, ou lorsqu'une révocation doit être rapidement effective et qu'une preuve de décision est attendue lors d'un audit. Nous ne remplaçons pas un protocol mapper par un moteur PBAC pour moderniser le schéma. Nous le faisons lorsque la règle ne tient plus proprement dans le cycle de vie d'un jeton.

Faut-il pour autant supprimer le Keycloak local ? La réponse n'est jamais automatique. Il peut rester utile comme broker d'identité, façade compatible avec une application, serveur d'autorisation local, mécanisme de transformation protocolaire, point de migration, couche de compatibilité, composant maîtrisé par un produit autonome. L'objectif peut simplement consister à déplacer, dans le temps, la donnée métier hors de ses claims, les règles complexes hors de ses protocol mappers, les décisions partagées vers un PDP, la gouvernance des rôles vers l'IGA, et l'authentification vers le service central. Rationaliser le Shadow IAM ne signifie pas supprimer tous les Keycloak. Cela signifie rendre explicite la responsabilité que chacun exerce.

Revenir à la réunion d'architecture, avec les bonnes questions

Cette manière de reprendre la conversation prolonge, très concrètement, la conviction qui structure notre travail : Security Meets Business. La question posée à l'équipe applicative n'est pas de justifier son architecture. Elle est de nommer l'opération métier qu'elle devait rendre possible. C'est à partir de cette opération, et non de l'organigramme de l'IAM, que se dessine ensuite l'architecture cible.

Lorsqu'un Keycloak local est découvert, nous ne commençons pas par inventorier les serveurs. Nous commençons par inventorier les décisions qu'ils prennent. Quelle identité reçoit-il du SSO central ? Authentifie-t-il réellement l'utilisateur ou agit-il comme broker ? Quels claims ajoute-t-il ? Quelles sources utilise-t-il, qui les possède, les données sont-elles copiées ou consultées, à quelle fréquence sont-elles actualisées ? Quelle est la durée de vie des tokens, et que se passe-t-il lorsqu'un droit est retiré pendant une session ? Où la règle est-elle documentée, qui peut la modifier, comment est-elle testée, comment est-elle auditée, existe-t-il une revue des droits ? D'autres applications implémentent-elles la même règle sans le savoir ?

Le Shadow IAM n'est pas uniquement une dette à supprimer. Il est aussi un outil de diagnostic. Il révèle des besoins qui n'étaient pas visibles, des règles métier absentes de la gouvernance, des référentiels essentiels, des applications ayant besoin d'une décision dynamique, des limites dans le catalogue de services IAM, et des équipes capables d'exprimer des cas d'usage précis. Le Shadow IAM est parfois la meilleure cartographie disponible des besoins d'autorisation que le programme central n'a jamais collectés.

Ariovis ne défend ni la centralisation absolue, ni l'autonomie totale des applications. Une plateforme entièrement centralisée peut devenir lente à faire évoluer, éloignée des données métier, dépendante d'une seule équipe. Une architecture entièrement locale produit des duplications, des règles divergentes, des coûts de RUN, des difficultés d'audit et une gouvernance fragmentée. Nous cherchons une répartition claire : gouvernance centrale de l'identité, authentification et fédération cohérentes, propriété métier des données, politiques d'autorisation partagées lorsqu'elles doivent l'être, application locale de la décision au plus près de la ressource. Centraliser l'autorisation ne signifie pas centraliser toutes les données ni toutes les équipes. Cela signifie rendre la politique cohérente et la décision consommable.

Lorsque vos métiers déploient Keycloak derrière votre SSO, ne commencez pas par leur demander pourquoi ils ont recréé de l'IAM. Demandez-leur quelle décision d'autorisation ils ne pouvaient obtenir autrement. Leur architecture locale n'est peut-être pas la solution cible, mais elle vous montre très précisément le service qui manque à votre programme IAM.

Parlons de votre projet IAMNous écrire

Conclusion

L'équipe IAM avait découvert un Keycloak supplémentaire et pensait d'abord devoir rationaliser une duplication du SSO. L'échange avec le métier révèle autre chose. Le SSO central authentifiait correctement les utilisateurs. L'annuaire fournissait les informations nécessaires pour les reconnaître. Mais l'application devait prendre des décisions sur des produits, des rayons, des magasins, des contrats, des délégations, des ressources que le dispositif IAM central ne connaissait pas.

L'équipe produit avait donc construit la réponse qu'elle pouvait livrer. Cette réponse comportait des limites : enrichissement croissant des jetons, dépendances envers plusieurs référentiels, règles locales, difficulté de révocation, nouvelle infrastructure à exploiter.

Ariovis ne commence pas par reprocher au métier ce contournement. Nous reconnaissons que l'entreprise fonctionne parce que ce métier sait vendre, gérer ses produits, servir ses clients, prendre des décisions opérationnelles. Notre rôle consiste à sécuriser cette capacité, pas à l'empêcher.

Nous aidons alors l'organisation à distinguer ce qui doit rester dans l'annuaire, ce qui doit être gouverné dans l'IGA, ce qui peut être transporté dans le jeton, ce qui appartient aux référentiels métier, ce qui nécessite une décision PBAC au runtime. Le Keycloak local peut être conservé, simplifié, repositionné ou progressivement remplacé selon son rôle réel. L'objectif n'est pas de faire gagner l'architecture centrale contre l'architecture locale. L'objectif est que le métier dispose enfin d'un service d'autorisation adapté à son besoin, gouverné, sécurisé, maintenable, exploitable.

Security Meets Business commence par une forme d'humilité : reconnaître que la sécurité n'est pas ce qui fait vivre l'entreprise, mais qu'elle doit permettre à ceux qui la font vivre d'exercer leur métier avec confiance. Lorsque les métiers contournent l'IAM, notre première responsabilité n'est pas de défendre notre architecture. Elle est de comprendre ce qui leur manquait et de construire avec eux une réponse plus sûre.