Apache Syncope est un outil de gestion des accès complet, aussi bien sur l'autorisation que l'authentification. Comme de nombreux projets openSource le développement et le support est de qualité, mais quand on passe à l'intégration, on est vite à court d'information. D'autant que l'IAM est un domaine complexe plein de spécificité ce qui rend l'outillage extrêmement versatile et donc plus complexe à intégrer.
Bien entendu il existe deux versions d'exemple, mais qui au vue de mon expérience, sont des travaux de développeurs plus ou moins aboutis.
Je souhaiterai à travers ce site mettre à profit mon expérience de plus de 20 ans sur des projets IAM en entreprise et une mise en pratique avec cet outillage. Les accès aux travaux au fil de l'eau:
Dans Test bed mon premier environnement de bricolage
Dans source d'identité une première intégration d'un fichier portant des personnes et des données d'activité (pas concluant)
Première analyse de la version d'exemple complète et son service de connecteurs qui nous amène à une impasse avec le Test Bed 😮💨
Conclusion seule la version Embedded permet une exploration de la solution d'exemple
Un petit tour dans la source de la configuration d'une instance Syncope en mode Embedded, pour se faire peur 😱
Suite de l'exploration de la configuration et parallèle avec les API, ce qui oriente la configuration d'une instance par les APIs
Comment lier au mieux les identités et les comptes dans Syncope, enfin comprendre les interactions au travers des connecteurs ?
Un travail pour mettre au point une source d'identité depuis un service REST (annule et remplace source d'identité) et en plus la démo en moins de 10mn
FIT = Full Integration Test, c'est le projet qui permet de charger des classes et propriétés pour une configuration spécifique. C'est la prochaine étape dans mon étude de Syncope. Une partie des types d'implémentation sont dans cette classe
Les instructions curl pour fabriquer la source d'identité et le repo avec le projet Java REST de la source d'identité. Attention faire un logout / login pour rafraichir la console et voir l'objet PERSON
Comme suggérer par Francesco Chicchiriccò, le retour d'expérience d'un utilisateur sur la liaison d'un OBJET et d'un USER et son implémentation
En fait Francesco Chicchiriccò m'a donné un nouveau design pour résoudre "simplement" mon cas d'usage. Il me propose de garder USER comme support de l'identité et de faire avec des groupes et des ressources le provisioning des comptes. Pas si simple de mettre en oeuvre cette logique avec mon niveau de connaissance, mais la démonstration pourra vous sembler assez facile.
Suite et fin de l'intégration Identité et Groupe avec la version 4.0.4 suivant le design de Francesco Chicchiriccò 👍
La doc de démarrage qui rappelle les fondamentaux de l'IAM et rentre assez vite dans la technique de l'outil sans vraiment donner les clés d'une intégration
Le git avec les sources
Si vous souhaitez directement vous lancer depuis une machine locale et la configuration d'exemple, je recommande l'approche maven qui permet soit un mode serveur applicatif (Embedded), soit un mode docker
La documentation de référence qui me pose un vrai problème concernant l'intégration, mais c'est l'objet de ce site ;-)
l'API Java
L'API Rest officielle de la version 4.0.2 (ou ce que j'ai extrait du Core)
Pour Syncope il n'existe en interne que des "utilisateurs qui représentent les identités virtuelles constituées d'informations de compte fragmentées à travers les ressources externes associées." Les utilisateurs sont des objets pivots entre des sources de données d'identité et de compte. Je trouve cette conception ambiguë, car pour moi identité et compte sont des objets distincts. Ce sera un des premiers challenge de jongler entre une identité unique, mais multiple dans ces fonctions et attributions et ses comptes dans différents contextes d'utilisation et d'environnement.
Au fil de mes investigations je me forge l'opinion que le projet Syncope est dans l'héritage des premiers outils de synchronisation, comme l'était Novell Identity Manager. De fait la prise en compte de l'identité, son contexte, son cycle de vie, est mal isolée des besoins d'accès, ce qui engendre une surcharge d'attribut sur un seul objet. Les concepteurs utilisent la notion d'identité virtuelle pour l'objet USER ("Users represent the virtual identities build up of account information fragmented across the associated external resources"), c'est un point d'agrégation qui mélange tout.
Par exemple une identité n'a pas un secret, serait un faute, mais elle peut avoir un dispositif d'authentification personnel pour plusieurs comptes. C'est pour cela qu'il faut distinguer identité et compte.
De plus le projet ne tient pas compte du RGPD qui nous oblige maintenant à déclarer l'usage des données personnelles, justifier de leur utilisation, leur protection, le consentement des propriétaires, la possibilité de réviser ces données, définir une durée de rétention et s'assurer de la destruction en fin de vie.
Comme cet outil synchronise de la données et n'est pas seulement un fournisseur d'accès on imagine la panique quand il faut répondre au DPO sur tous les points précédents et en prenant en compte les cascades d'une application à une autre.
Avec la containérisation et leurs gestionnaires, le déploiement d'application est devenu plus fluide grâce aux techniques DevSecOps. De ce point de vue la documentation et ce que l'on trouve sur le git est assez décevant. Il faudra donc un gros effort pour faire rentrer le code source et sa configuration / spécialisation dans une chaine CI/CD et sa projection dans des environnements de production.
Il faudra aussi tenir compte du fait que l'IAM est utile partout où des personnes accèdent et exploitent des systèmes et des applications et ce dans tous les environnements possibles. Donc décider s'il faut un IAM pour tous ou des IAM spécialisés par environnements, mais alors comment les réconciliés ?
Cela veut dire que la configuration de l'IAM, ces règles de fonctionnement seront variables par environnement tout comme les données et les moyens d'accès aux ressources nécessaires à l'IAM.
Syncope est un outillage qui permet la gestion des autorisations, donc qui permet de répondre à la question: qui fait quoi pourquoi ? Mais qui répond aussi à la question: qui accède à quoi comment ? L'autorisation est un préalable à un accès, mais ce dernier met en œuvre des techniques et des règles qui lui sont propres. Le point commun c'est le compte qui porte l'identification, l'autorisation et les secrets d'accès d'une ou plusieurs cibles. Du côté services et applications (le quoi) ce qui est nécessaire c'est la capacité à déléguer l'autorisation et / ou l'authentification.
S'authentifier, obtenir un moyen d'accès est la seule chose qui motive une personne et ce quelque soit les moyens (utilisation de compte commun, système / applicatif, usurpation d'identité ...) L'IAM c'est l'empêcheur d'obtenir ces accès sans avoir répondu aux deux règles de sécurité:
Le besoin d'en connaitre (en quoi je suis légitime à disposer de cette visibilité)
Le principe de moindre privilège (en quoi ces pouvoirs sont cohérents avec mon niveau d'action)
Pour cela il faut un modèle / une politique d'accès. Syncope semble de ce point de vue limité au RBAC, il faudra cherche ailleurs un outillage moderne de calcul des permissions et le réinjecter.
Mon expérience de ChatGPT est la parfaite démonstration des réalités parallèles ou alternatives, un savant mélange d'information contradictoires et sans efficacités enrobées dans une présentation soignée. En fait l'IA ne tient pas compte des versions et mélange tout. Le simple déploiement d'un connecteur source CSV est impossible en suivant les instructions proposées. En particulier le mapping des attributs de la ressources sur les attributs de l'objet interne.