Sable fin – pourquoi de nombreuses installations CIAM nécessitent une autorisation plus fine

Ces dernières années, de nombreuses entreprises ont modernisé avec succès leurs systèmes internes de gestion des accès (AM) pour les collaborateurs et leur accès à partir d’applications web et de services SaaS, ainsi que leurs systèmes de gestion des identités et des accès (CIAM) pour sécuriser l’accès des clients aux e-services et prestations proposés. Dans ce cadre, la saisie multiple et fastidieuse des identifiants tels que les noms d’utilisateur/courriels et les mots de passe a été remplacée par des normes de fédération et d’authentification unique (comme SAML et OpenID/OAuth).

Cela a déjà apporté des avantages considérables pour la mise à disposition de nouveaux eServices ainsi que pour la sécurisation de l’utilisation du cloud et, surtout, a considérablement amélioré l’expérience utilisateur. La centralisation de l’identification des utilisateurs ainsi que de leur authentification est incontestablement, grâce à Sinlge Sign-On, un jalon dans l’utilisation de telles infrastructures, dont découlent un certain nombre d’avantages, comme notamment :

• La transmission ouverte de mots de passe non cryptés est empêchée
• Les utilisateurs ne doivent plus enregistrer de nouvelles données d’accès pour chaque application
• L’expérience utilisateur lors de l’enregistrement, du login et de la réinitialisation du mot de passe est uniformisée – des valeurs de reconnaissance et des processus uniformes créent une confiance et une sécurité supplémentaires.
• Les attaques contre les comptes utilisateurs peuvent être détectées et stoppées de manière centralisée au niveau du fournisseur d’identité.
• L’utilisation de solutions SaaS – CIAM prêtes à l’emploi permet de réduire le coût total de possession (TCO) par rapport aux solutions alternatives qui doivent être développées et exploitées en interne à n reprises.

Il y a cependant un moment où les limites de ces technologies apparaissent lentement mais sûrement à la surface. Alors qu’elles permettent de prendre une simple décision OUI/NON pour l’accès à des ressources ou à des services tels que des portails clients, des boutiques ou des plateformes de collaboration, une distinction à un niveau plus fin de ce que l’utilisateur peut ensuite faire reste souvent inexpliquée et doit être gérée dans le cadre de l’application ou du service concerné.

Dans le contexte des fédérations interentreprises (généralement basées sur SAML), il est certes possible d’opérer une distinction plus poussée par le biais de l’appartenance à un groupe et des mentions correspondantes dans le jeton, mais cela se limite généralement à quelques options, faute de quoi les appartenances à des groupes se multiplient du côté des infrastructures des clients.

Mais revenons tout d’abord brièvement sur les avantages de l’utilisation d’une solution CIAM, comme celle proposée par cidaas.
Correctement planifié et mis en œuvre, un CIAM offre bien plus qu’une simple « gestion des accès », car il offre des fonctions pour

• l’inscription de nouveaux utilisateurs (finaux), manuellement ou via un fournisseur d’identité sociale
• la validation des identités des utilisateurs, par exemple via le « ID validator » de cidaas
• l’identification et l’authentification des utilisateurs pendant l’accès, soit localement, soit par fédération au fournisseur d’identité
• la mise en œuvre d’une simple décision OUI/NON (autorisation) pour l’accès

Mais que se passe-t-il ensuite?

Une délimitation plus fine de ce qu’un utilisateur peut ou ne peut pas faire dans le système cible n’est pas du tout prise en compte (clé du royaume), ou alors les décisions à granularité fine concernant l’accès sont gérées dans l’application cible elle-même. Cela se fait généralement sans possibilité de contrôle central, car chaque application est programmée individuellement par ses développeurs. Cette « fine grained authorization » (FGA) ou sa gestion abstraite et centralisée devient toutefois de plus en plus pertinente dans les architectures plus complexes et certains fabricants, comme Axiomatics, ont déjà essayé il y a une dizaine d’années de promouvoir une telle centralisation avec des normes comme XACML (eXtensible Access Control Markup Language). Bien que XACML ne soit pas considéré comme un échec total, son adoption est restée bien en deçà des attentes élevées.

D’autres projets (open source) tels que l' »Open Policy Agent » (OPA) et son langage de description « REGO » ont reçu beaucoup plus d’attention depuis leur première version en 2016, et depuis environ deux ans, toute une série de projets « FGA », de solutions et surtout de langages de description (comme CEDAR d’AWS) ont été développés pour servir le thème de l' »autorisation à granularité fine ».

Il est donc grand temps de se consacrer à ce thème et de mettre à disposition les fonctions correspondantes du principal fournisseur européen d’outils CIAM !

Qu’est-ce qui nous attend dans les mois à venir et quels sont les thèmes qui doivent être abordés?

1. L’accès à granularité fine dépend toujours de l’application et n’est guère uniformisé.
2. Le besoin n’existe pas seulement pour l’utilisateur, mais aussi pour les auditeurs et le service d’audit – car le suivi des concepts d’autorisation locaux et la compréhension de leur logique et de leurs messages de log entraînent un travail supplémentaire.
3. Une solution centralisée ou centralisable durable n’est pas encore en vue – il s’agit surtout de soutenir les propriétaires et les développeurs d’applications.
4. Bien que de nouveaux composants d’outils tels que l’OPA et d’autres soient disponibles, les développeurs doivent effectuer un refactoring complet pour adapter la logique d’autorisation interne à de nouveaux langages et concepts.
5. Ce n’est qu’après le passage de plusieurs applications à cette logique et à ce langage de description uniformes que les politiques et leur gestion ainsi que la journalisation et l’audit peuvent être améliorés de manière significative.

L’effort d’une autorisation plus fine en vaut-il la peine ?

Il n’est pas possible de répondre à cette question de manière générale, car il convient d’examiner pour chaque application, chaque usage et chaque service si un changement semble judicieux. Toutefois, dans le cas de nouveaux projets logiciels, services électroniques et services, il convient de mener une discussion très bienveillante sur l’adoption de langages de description standardisés, en particulier si des infrastructures centrales pour la gestion des politiques, l’administration des politiques et l’évaluation commune peuvent être mises à disposition en parallèle par le fournisseur de CIAM. Il faut néanmoins garder à l’esprit que pour les applications plus anciennes, l’effort sera probablement difficile à justifier, d’autant plus que des adaptations correspondantes devront également être effectuées du côté du CIAM. Dans ce cas, il est conseillé de comparer la stratégie à long terme de l’entreprise pour savoir si l’alternance ou la migration de telles applications « héritées » sont prévues et quelles sont les possibilités qui en découlent.

Ce qui est clair, c’est que le rôle et l’importance des solutions CIAM et AM vont s’élargir, passant d’un simple « gatekeeper » et d’un décideur OUI/NON à une instance adaptative et dynamique, capable justement de gérer des droits d’accès à granularité fine et de garantir leur mise en œuvre et leur respect.

Il est également clair que beaucoup de choses vont changer du côté des applications : de même que les fonctions d' »identification » et d' »authentification » ont été transférées de l’application vers des services externes avec le SSO, les décisions d’accès à granularité fine ne seront plus décidées par l’application elle-même, mais confiées à des services externes (PDP – Policy Decision Points). L’application se contente alors d’appliquer « bêtement » la décision du PDP et d’autoriser ou de refuser l’accès à une ressource donnée.

L’effort n’en vaut pas la peine pour chaque application, mais uniquement pour les services particulièrement critiques avec une durée de vie résiduelle correspondante. Les nouveaux projets de développement peuvent toutefois profiter de la modularisation supplémentaire, surtout si l’utilisation de composants externes pour une autorisation à granularité fine est pensée et implémentée dès le départ dans l’architecture de l’application.

Les avantages pour les entreprises et les utilisateurs sont évidents :

• Les règles d’accès (policies) peuvent être formulées plus facilement et indépendamment du langage de programmation de l’application – en partie même par des utilisateurs spécialisés.
• Journalisation uniforme et centralisée des accès
• Contrôle d’accès cohérent et auditable sur l’ensemble de l’environnement applicatif, grâce à des politiques centralisées et standardisées
• Découplage de la logique applicative de la logique métier en ce qui concerne les contrôles d’accès à granularité fine

Une « fine grained authorization » centralisée est entrée dans la réalité et nous ferions bien de préparer et d’adapter nos services et nos infrastructures en conséquence.