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 un démonstrateur, mais qui au vue de mon expérience, il repose sur 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 environnement de bricolage
Suite et fin de l'intégration Identité et Groupe avec la version 4.0.4 suivant le design de Francesco Chicchiriccò 👍. Ce qui signe définitivement pour moi une faiblesse du produit au regard d'une gestion des identités.
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.1.0
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.