Les Workflows Keycloak : Automatisation intelligente de la gestion des comptes

Une réponse concrète aux enjeux de sécurité et de conformité

La fonctionnalité Workflows répond à un besoin critique exprimé par les organisations : automatiser la gestion du cycle de vie des comptes utilisateurs sans intervention manuelle.

Grâce à ces évolutions, Keycloak va désormais permettre d'automatiser certaines tâches administratives récurrentes, de mettre en place des mécanismes de gestion des cycles de vie de comptes (offboarding, onboarding, gestion de l'inactivité). Keycloak amorce ainsi une transition de son périmètre traditionnel centré sur l'authentification et l'autorisation.

Cette évolution reste cependant dans une phase initiale : les workflows sont actuellement limités aux objets utilisateurs (« users »), les autres objets n'ayant pour l'instant pas les fonctions de workflows avec des déclenchements par conditions et basés sur des évènements IAM. De plus, contrairement aux solutions IGA complètes (One Identity, Saviynt, etc.), Keycloak ne dispose pas encore de fonctionnalités de certification des accès, de gestion des séparations de tâches (SoD), de provisionnement multi-systèmes ou de workflows d'approbation complexes et ne sait pas modéliser les identités derrière les comptes.

Cette capacité d'automatisation de base peut en revanche commencer à se comparer à ce que proposent Okta Lifecycle Management ou Microsoft Entra ID dans leurs offres de gestion du cycle de vie utilisateur, et devient désormais accessible dans l'écosystème Open Source. Pour les organisations cherchant une solution IAM simple avec des fonctionnalités d'automatisation de base, Keycloak représente une alternative crédible aux solutions d'authentification et d'autorisation commerciales.

Comment s'organise les workflows de Keycloak 26.4

Le principe est simple : lorsqu'un évènement identifié dans un workflow est déclenché, celui-ci vérifie que sa condition d'exécution est bien validée et si c'est le cas, il déclenche une série de « steps » qui a été défini au préalable et que la « feature » déclenchera de façon séquentielle (pas de parallélisme). Chacune des étapes-steps est basée sur des éléments de configurations permettant de dire quelle action réaliser et les conditions de déclenchement de la dîte étape.

Les workflows s'articulent ainsi autour de trois piliers techniques :

1. Le déclenchement événementiel

Les workflows s'activent automatiquement en réponse à des événements spécifiques du système. Les événements disponibles sont les suivants :

• USER_LOGIN : connexion réussie d'un utilisateur
• USER_ADD : création ou enregistrement d'un nouvel utilisateur
• USER_GROUP_MEMBERSHIP_ADD : ajout d'un utilisateur à un groupe
• USER_ROLE_ADD : attribution d'un rôle à un utilisateur

D'autres évènements sont prévus mais pas encore mis en place pour le moment :

• USER_UPDATED : quand un utilisateur est mis à jour
• USER_GROUP_MEMBERSHIP_REMOVE : quand un utilisateur est retiré d'un groupe
• USER_ROLE_REMOVE : quand un utilisateur est retiré d'un rôle

Cette architecture événementielle permet une réactivité en temps réel, éliminant les délais inhérents aux processus batch traditionnels.

2. Les conditions granulaires et le ciblage

Chaque workflow peut être configuré avec des conditions fines permettant de cibler précisément les ressources concernées :

• is-member-of(group) : vérifie l'appartenance à un groupe spécifique
• has-role(role) : contrôle la présence d'un rôle
• has-user-attribute(key, value) : filtre sur des attributs utilisateurs personnalisés
• has-identity-provider-link(identity-provider) : détecte les utilisateurs provenant d'un fournisseur d'identité externe

Ces steps peuvent être appliqués immédiatement ou plus tard en fonction de la configuration.

Cette granularité permet de créer des politiques d'automatisation adaptées aux différents segments d'utilisateurs (employés, partenaires, clients) et aux exigences réglementaires sectorielles.

3. Les étapes programmables et différées

Les workflows supportent l'exécution séquentielle d'actions avec la possibilité de délais programmés :

• notify-user : envoi de notifications email automatisées
• disable-user : désactivation du compte utilisateur
• remove-user : suppression définitive du compte

D'autres actions prévues mais pas encore implantées :

• join/leave groups
• assign/unassign roles
• add/remove user attribtues

La capacité à planifier des actions différées transforme Keycloak en facilitant sa capacité à gérer et à automatiser des scénarios avancés, sur plusieurs jours ou semaines.

Cas d'usage concret : Gestion automatisée des comptes inactifs

Le défi de la gestion des comptes dormants

Les comptes utilisateurs inactifs représentent un risque sécuritaire majeur dans les environnements d'entreprise. Selon le rapport Verizon DBIR, 30% des incidents de sécurité impliquent des comptes compromis laissés actifs après le départ d'employés ou suite à une période d'inactivité prolongée. Les normes de conformité (SOC 2, ISO 27001, NIS 2) exigent des politiques strictes de revue et de désactivation des comptes inactifs.

Avant la version 26.4, la gestion des comptes inactifs dans Keycloak nécessitait des développements externes conséquents. Les administrateurs devaient :

• Développer des scripts personnalisés interrogeant régulièrement l'API REST Keycloak pour identifier les comptes inactifs
• Mettre en place des tâches planifiées (cron, Jenkins, schedulers applicatifs) pour exécuter ces scripts périodiquement
• Gérer manuellement la logique métier : calcul des périodes d'inactivité, gestion des notifications, suivi des états intermédiaires
• Maintenir une infrastructure supplémentaire : base de données externe pour tracker l'historique, système d'envoi d'emails, logs de traçabilité
• Assurer la fiabilité : gestion des erreurs, rejeux en cas d'échec, cohérence des données

Cette approche générait des coûts de développement importants (typiquement 5-10 jours/homme pour un processus simple), une maintenance continue, et des risques de désynchronisation entre le script externe et l'état réel des utilisateurs dans Keycloak.

 

Avec les Workflows de Keycloak 26.4, cette complexité disparaît :

 

Solution automatisée avec Keycloak Workflows

Voici un exemple d'implémentation qui illustre la puissance et l'intelligence des workflows natifs. Ce scénario gère automatiquement la désactivation progressive des comptes utilisateurs non-administrateurs après détection d'inactivité, sans aucune ligne de code externe, avec une configuration déclarative et une fiabilité garantie par le moteur Keycloak.

La définition du workflow suit une structure JSON déclarative et claire et un versionnement dans les systèmes de gestion de configuration :

Le mot-clé « uses » permet de déclarer la ressource a utiliser.

Le mot-clé « If » définit une condition d'exécution du workflow. La valeur de « uses » en root du workflow est définie sur « event-based-workflow » qui est la seule valeur possible pour le moment.

Le mot-clé « on » définit l'event pour l'exécution du workflow. « reset-on », lui, sert à réinitialiser le workflow (si celui-ci n'est pas terminé) sur évènement.

Les steps peuvent être déclenchés immédiatement ou après un délai. Ce comportement est caractérisé par le mot-clé « after » qui est évalué en ms.

La configuration supporte uniquement l'unité de temps `ms` (millisecondes). D'autres unités de temps standard sont dans la road-map et seront utiles voire nécessaires pour un usage en production.

Scénario détaillé du workflow

Déclencheur : Connexion d'un utilisateur (événement USER_LOGIN)

Étape 1 – Notification différée (T+30s) :

• Le workflow démarre automatiquement lors de la connexion
• 30 secondes après la connexion initiale, le système vérifie si l'utilisateur s'est reconnecté
• Si aucune nouvelle connexion n'a eu lieu : envoi automatique d'un email de notification avertissant l'utilisateur que son compte risque d'être désactivé
• Si l'utilisateur s'est reconnecté : la notification est annulée, le workflow s'arrête

Étape 2 – Désactivation conditionnelle (T+60s) :

• 30 secondes après l'envoi de la notification (soit 60 secondes après la connexion initiale), le système effectue une nouvelle vérification
• Si aucune nouvelle connexion n'a eu lieu : le compte utilisateur est automatiquement désactivé
• Si l'utilisateur s'est reconnecté : la désactivation est annulée, le workflow s'arrête

 

L'annulation automatique : un mécanisme de protection

Chaque étape différée vérifie l'état actuel de l'utilisateur avant de s'exécuter :

1. Détection des reconnexions : Le workflow surveille en permanence les événements USER_LOGIN pour le même utilisateur
2. Annulation automatique : Si une reconnexion est détectée, les étapes planifiées en attente sont automatiquement annulées
3. Protection des utilisateurs actifs : Un utilisateur qui reste actif ne sera jamais impacté par le workflow, quelle que soit la fréquence de ses connexions

Cette approche garantit qu'aucun utilisateur légitime et actif ne soit accidentellement désactivé, tout en assurant une réactivité maximale pour sécuriser les comptes réellement inactifs. Dans un contexte de production, les délais de 30 secondes seraient naturellement remplacés par des valeurs plus réalistes (par exemple : notification à J+30, désactivation à J+45).

Extensibilité via SPI (Service Provider Interface)

Les workflows Keycloak sont conçus avec une architecture extensible. Les étapes et conditions intègrent leur propre SPI, permettant aux organisations de développer des implémentations personnalisées répondant à des besoins métiers spécifiques :

• Intégration avec des systèmes SIEM externes
• Déclenchement de workflows RH (offboarding, rotation de postes)
• Synchronisation avec des systèmes de ticketing (ServiceNow, Jira)
• Notifications via des canaux alternatifs (SMS, Slack, Teams)

Cette approche modulaire garantirait que même les exigences les plus spécifiques peuvent être adressées sans modifier le cœur de Keycloak. Toutefois, il semblerait que ça n'impactera que les éléments des steps.

Autres cas d'usage pratiques des workflows

Au-delà de la gestion des comptes inactifs, les workflows Keycloak 26.4 ouvrent de nombreuses possibilités d'automatisation :

1. Onboarding automatisé

• Déclencheur : USER_ADD (création de compte)
• Actions : Envoi d'email de bienvenue, attribution automatique de rôles par défaut, ajout aux groupes selon attributs (département, localisation)
• Cas d'usage : Nouvel employé créé dans le système RH → provisioning automatique dans Keycloak avec droits de base

2. Offboarding sécurisé

• Déclencheur : USER_GROUP_MEMBERSHIP_ADD (ajout au groupe « Départs »)
• Actions : Notification aux gestionnaires (J+0), désactivation du compte (J+30), suppression définitive (J+90)
• Cas d'usage : Respect des obligations légales de conservation des données tout en sécurisant immédiatement les accès

3. Conformité réglementaire

• Déclencheur : USER_ROLE_ADD (attribution de rôles privilégiés)
• Actions : Notification aux équipes de sécurité, logging dans un SIEM externe, demande de justification
• Cas d'usage : Traçabilité des accès privilégiés pour audits SOC 2, ISO 27001, NIS 2

4. Gestion des comptes externes

• Déclencheur : USER_LOGIN avec condition `has-identity-provider-link`
• Actions : Synchronisation des attributs depuis le fournisseur externe, mise à jour des profils
• Cas d'usage : Maintien de la cohérence des données pour les utilisateurs fédérés (Entra ID, Google, LinkedIn)

Keycloak face aux solutions commerciales : un positionnement à affiner

Un périmètre fonctionnel encore limité

Les workflows automatisés de Keycloak 26.4 doivent être positionnés avec réalisme dans le paysage des solutions d'IAM.

Positionnement actuel pertinent :

• Okta Lifecycle Management (gestion basique du cycle de vie utilisateur)
• Microsoft Entra ID (automatisation des comptes, onboarding/offboarding simple)
• Toute solution IAM avec des fonctionnalités de lifecycle management de base

Positionnement non pertinent (pour le moment) :

• Memority, Saviynt, One Identity, Ping : solutions IGA complètes avec certification des accès, analytics, gestion des séparations de tâches, connecteurs de provisionnement multiples
• Solutions nécessitant des workflows d'approbation multi-niveaux, gestion des campagnes de recertification, ou provisionnement automatisé sur des dizaines d'applications

Les limites actuelles à considérer :

• Workflows limités aux comptes utilisateurs uniquement
• Absence de gestion native des groupes, rôles, clients dans les workflows
• Pas de moteur de provisionnement intégré vers des systèmes tiers
• Absence de fonctionnalités de certification des accès et de recertification
• Pas de gestion des séparations de tâches (SoD)
• Workflows d'approbation inexistants

 

Les avantages distinctifs de Keycloak (qui restent pertinents) :

1. Transparence et contrôle total

Le code source ouvert permet une inspection complète des mécanismes de sécurité, une exigence croissante dans les environnements régulés (secteur bancaire, santé, administrations publiques). Les organisations peuvent auditer, valider et certifier chaque composant selon leurs propres standards.

2. Souveraineté et conformité RGPD

Keycloak peut être déployé intégralement on-premise ou dans des clouds souverains européens, garantissant la localisation des données et la conformité avec les réglementations sur la souveraineté numérique. Cette maîtrise est impossible avec les solutions SaaS américaines.

3. Absence de vendor lock-in

L'architecture basée sur des standards (OAuth 2.0, OpenID Connect, SAML 2.0) et l'absence de formats propriétaires facilitent les migrations et permettent une stratégie multi-fournisseurs. Les workflows peuvent être exportés, versionnés et réutilisés entre différents environnements.

4. TCO attractif pour un périmètre IAM

Pas de licensing par utilisateur, pas de coûts cachés pour activer des fonctionnalités « premium ». Les investissements se concentrent sur les compétences internes et l'intégration, avec des coûts prévisibles dans le temps. Ce modèle est particulièrement pertinent pour les organisations cherchant une solution de gestion des accès (authentification et autorisation) avec des fonctionnalités de lifecycle management de base.

5. Écosystème et communauté

La communauté Keycloak est l'une des plus actives dans le domaine IAM Open Source, avec un rythme de release soutenu (versions trimestrielles) et un support commercial disponible via Red Hat (Red Hat build of Keycloak).

Perspectives et roadmap de Keycloak 26.4

Évolutions à venir des Workflows dans Keycloak

Bien que la fonctionnalité soit actuellement en mode expérimental (preview), la roadmap Keycloak annonce des enrichissements significatifs pour les prochaines versions et à terme le support d'autres type de workflows géré par les administrateurs :

• Actions de groupe : join/leave groups, permettant l'automatisation complète du provisioning organisationnel
• Gestion des rôles : assign/unassign roles de manière dynamique selon des conditions métier
• Manipulation des attributs : add/remove user attributes pour enrichir automatiquement les profils
• Intégration Organizations : join/leave organizations, particulièrement pertinent pour les déploiements CIAM multi-tenant
• Configuration : support du yaml, templates pour construire rapidement des workflows simples, « after » acceptant des formats de délai plus variés, évolution de l'ui, exécution à heure fixe, etc.

Il manque encore des éléments structurants pour considérer Keycloak comme une solution IAM : notamment l'intégration d'un moteur de provisionnement vers des systèmes tiers (annuaires LDAP/AD externes, applications SaaS, bases de données RH), des fonctionnalités de certification des accès, la gestion des séparations de tâches, et des workflows d'approbation multi-niveaux. Mais si le chemin reste long et incertain, il est toutefois possible d'utiliser Keycloak en combinaison avec un référentiel d'identités comme la solution Neo-ID d'Aduneo.

Autres innovations de Keycloak 26.4

Au-delà des workflows, la version 26.4 apporte des améliorations substantielles :

• Support MCP (Model Context Protocol) : intégration avec les applications IA via OAuth 2.0, répondant aux nouveaux enjeux de sécurisation des LLM
• Rotation automatique des certificats SAML : téléchargement et mise à jour automatique depuis les métadonnées SP, réduisant les risques d'interruption de service
• Workflow de mise à jour sécurisée des emails : processus renforcé avec ré-authentification et vérification, conforme aux meilleures pratiques de sécurité
• FAPI 2.0 Final et DPoP : support complet des spécifications finales, essentiel pour les cas d'usage financiers et open banking

Pour quels types de projets Keycloak 26.4 est-il pertinent ?

Cas d'usage adaptés :

Keycloak est particulièrement adapté si vous :

• Recherchez une solution AM robuste (authentification, autorisation, SSO) avec des premières capacités d'automatisation du cycle de vie utilisateur
• Avez des besoins simples de lifecycle management : onboarding/offboarding basique, gestion des comptes inactifs, notifications automatisées
• Privilégiez la souveraineté et la conformité RGPD avec déploiement on-premise ou cloud souverain
• Souhaitez maîtriser votre TCO en éliminant les licences par utilisateur pour un périmètre IAM
• Valorisez les standards ouverts (OpenID Connect, OAuth 2.0, SAML 2.0) et l'absence de vendor lock-in
• Disposez de compétences techniques internes ou d'un accompagnement expert pour l'exploitation
• N'avez pas besoin de fonctionnalités IGA avancées (certification des accès, SoD, provisionnement multi-systèmes)

Cas d'usage NON adaptés (à ce stade) :

Keycloak n'est pas recommandé si vous avez besoin :

• De certification des accès et campagnes de recertification périodiques
• D'un moteur de provisionnement robuste vers de multiples systèmes (applications SaaS, annuaires, bases RH)
• De workflows d'approbation complexes multi-niveaux avec délégation
• De gestion des séparations de tâches (SoD) et d'analytics de risque
• De gestion automatisée des groupes et rôles via workflows
• D'une solution IGA complète comparable à Saviynt ou One Identity

Pour ces besoins avancés de gouvernance des identités, les solutions IAM / IGA commerciales semblent incontournables.

Conclusion : Keycloak 26.4, une évolution prometteuse à positionner avec lucidité

L'introduction des Workflows automatisés dans Keycloak 26.4 représente indéniablement une amélioration fonctionnelle significative qui enrichit le périmètre traditionnel de cette solution IAM Open Source. Pour autant, il convient de rester réaliste sur son positionnement actuel : Keycloak demeure avant tout une excellente solution d'authentification et d'autorisation qui amorce son évolution vers des fonctionnalités de lifecycle management basique.

Cette première étape vers l'automatisation est encourageante et témoigne de la vitalité de l'écosystème Keycloak : une communauté active de plusieurs milliers de contributeurs, un rythme de release soutenu (versions trimestrielles), et un support commercial disponible via Red Hat. L'Open Source continue ainsi de progresser dans le domaine IAM, même si le chemin vers des capacités IGA complètes reste long.

L'approche que nous recommandons est pragmatique : considérer Keycloak pour ce qu'il offre aujourd'hui – une solution mature qui s'enrichit progressivement de fonctionnalités complémentaires – plutôt que de miser sur ce qu'il pourrait devenir à moyen terme. Les workflows de la version 26.4 constituent une brique supplémentaire intéressante, mais ne transforment pas Keycloak en solution IGA.

Pour les organisations ayant des besoins structurants en gestion des identités, une architecture hybride peut s'avérer particulièrement pertinente : combiner Keycloak pour les fonctions d'authentification et d'autorisation avec un référentiel d'identités centralisé assurant la gouvernance, le provisionnement et la réconciliation des comptes. Cette approche permet de bénéficier des avantages de l'Open Source sur le périmètre IAM tout en s'appuyant sur des solutions éprouvées pour les fonctions de gouvernance avancées.

Aduneo accompagne ses clients dans la conception et la mise en œuvre de ces architectures IAM/IGA hybrides, en intégrant Keycloak au sein d'écosystèmes plus larges. Notre expertise nous permet d'évaluer avec vous la pertinence de Keycloak dans votre contexte spécifique et de construire une architecture cible réaliste et pérenne.

 

Vous évaluez Keycloak pour votre organisation ?

Nos experts peuvent vous accompagner dans la définition de votre stratégie, la réalisation d'une preuve de concept (POC) comparative, ou l'implémentation complète de vos workflows d'automatisation.

Note technique : Les workflows de Keycloak 26.4 sont actuellement en mode expérimental (preview). Red Hat annonce leur passage en mode supporté dans la version 26.5. Les fonctionnalités décrites dans cet article sont basées sur la documentation officielle Keycloak accessible sur keycloak.org.

Ressources complémentaires

Documentation officielle Keycloak :

• Workflows automatisés – Guide complet
• Release Notes Keycloak 26.4
• Server Administration Guide

Communauté et support :

• Forum communautaire Keycloak
• Red Hat build of Keycloak
• Keycloak on GitHub