Parlons d’IAM
Concepts généraux
Aujourd’hui, j’aimerais vous parler d’un sujet sur lequel j’ai beaucoup travaillé en tant que membre d’une équipe IAM.
Cette équipe est responsable, comme son nom l’indique, de l’IAM de l’entreprise.
D’accord, mais qu’est-ce qu’une IAM ?
IAM est l’acronyme de « Identity and Access Management » (gestion des identités et des accès). Il s’agit d’un système qui gère en toute sécurité les identités numériques et les droits d’accès des utilisateurs aux ressources d’une organisation. En termes plus simples, c’est ce qui se cache derrière les systèmes d’authentification et d’autorisation en ligne.
Une identité numérique est l’ensemble des informations qui permettent de reconnaître et d’authentifier une personne ou un appareil en ligne, comme un nom d’utilisateur, un mot de passe ou des certificats.
On parle souvent de trois éléments clés dans l’authentification :
-
Ce que je sais
Il s’agit de l’authentification classique par mot de passe. L’utilisateur fournit un justificatif (un nom d’utilisateur et un mot de passe) pour prouver son identité. Bien qu’il s’agisse de la méthode la plus couramment utilisée, le fait de s’appuyer sur ce que l’on connaît rend les systèmes vulnérables au vol de mot de passe, à l’hameçonnage ou aux attaques par force brute. -
Ce que j’ai
Il s’agit de méthodes telles que l’authentification à deux facteurs (2FA) ou l’authentification multifacteur (MFA). En plus de votre mot de passe (ce que vous savez), vous fournissez quelque chose que vous possédez, comme un téléphone ou une clé de sécurité matérielle. Ces méthodes garantissent que même si votre mot de passe est compromis, l’attaquant doit toujours avoir accès à votre appareil physique. -
Ce que je suis
Il s’agit de l’authentification biométrique, qui repose sur des caractéristiques physiques uniques telles que les empreintes digitales, la reconnaissance faciale ou la voix. Ces caractéristiques sont beaucoup plus difficiles à falsifier, ce qui ajoute une forte couche de sécurité basée sur quelque chose d’intrinsèque à vous.
Chaque méthode d’authentification offre différents degrés de sécurité et de facilité d’utilisation, et est souvent utilisée en combinaison pour obtenir un système plus robuste.
Un peu plus loin : les Passkeys
L’une des évolutions les plus récentes dans le domaine de l’authentification est la montée en puissance des passkeys. Celles-ci font partie d’un effort visant à dépasser les mots de passe en les remplaçant par des clés cryptographiques résidant sur vos appareils (tels que votre téléphone ou votre ordinateur portable). L’idée est d’utiliser l’appareil lui-même comme justificatif d’identité, souvent en combinaison avec des données biométriques. Les passkeys étant résistants au phishing et ne pouvant être facilement volées, elles constituent une alternative plus sûre et plus conviviale aux mots de passe.
En résumé, les différents types d’authentification varient en complexité et en niveau de sécurité, chaque méthode étant adaptée à des contextes spécifiques en fonction des besoins de protection et de la facilité d’accès. Ceci nous amène à un type d’authentification qui nous intéresse particulièrement aujourd’hui.
Identités fédérées : Simplifier l’accès
Un autre concept important est celui de l’authentification par identité fédérée. Cette méthode permet à un utilisateur d’accéder à plusieurs services à l’aide d’un seul jeu d’identifiants, souvent géré par un tiers de confiance. Plutôt que de devoir créer et gérer des identifiants distincts pour chaque service, l’utilisateur se connecte une seule fois et accède à plusieurs systèmes. Cela simplifie non seulement l’expérience de l’utilisateur, mais allège également la charge des administrateurs en centralisant la gestion des identités.
La fédération d’identité : pourquoi ?
Authentification par mot de passe
Plutôt que de décrire directement à quoi correspond la fédération d’identité, je voudrais d’abord expliquer comment nous en sommes venus à introduire ce concept.
Pour ce faire, parlons de l’authentification par mot de passe.
Celle-ci, vous la connaissez bien, vous l’utilisez tous les jours. Que ce soit pour les applications que vous utilisez dans vos loisirs (jeux vidéo, forums, musique), ou les outils d’entreprise si vous travaillez dans une société.
Vous avez un identifiant et un mot de passe. Si les deux correspondent, vous accédez à votre compte. Sinon, vous n’y avez pas accès. C’est tout.
Cette méthode est simple et efficace, à condition que le mot de passe soit suffisamment fort.
Les avantages sont principalement sa facilité de mise en œuvre et sa compatibilité universelle.
Mais ce principe implique aussi que pour chaque application sur laquelle vous avez un compte, vous avez une identité différente. C’est toujours vous à chaque fois, mais chaque identité est distincte.
S’il peut sembler logique de devoir créer des comptes différents pour jouer à Dofus, écouter de la musique sur Spotify et aller sur Reddit, ne serait-il pas illogique de devoir créer un compte pour chaque logiciel que vous utilisez dans le cadre de votre travail au sein d’une entreprise ?
Lorsque vous entrez dans une entreprise, le premier jour, on vous donne un compte, et vous avez accès à tout ce dont vous avez besoin avec : votre email, votre outil de gestion des congés et absences, votre plateforme de communication, votre portail intranet, etc…
Vous imaginez si nous devions créer un compte pour chaque application ?
Cela ressemblerait à ceci :

Une identité par application (c’est ce que j’ai voulu représenter en dessinant des cartes d’identité de couleurs différentes). Cela présente quelques inconvénients :
-
Expérience utilisateur
Voulez-vous vous souvenir de 40 paires de login/mot de passe ? Moi non plus. -
Expérience de l’administrateur
Si vous ne voulez pas vous souvenir d’autant d’informations d’identification, vous pouvez imaginer le cauchemar que cela représenterait pour les administrateurs qui devraient gérer chacun de vos comptes. -
Surface d’attaque
Plus le système d’authentification de votre entreprise est hétérogène, plus la surface d’attaque est grande. Cela augmente également de manière significative la vulnérabilité au problème du « nouvel ennemi » : le problème de la protection contre les anciens employés mécontents dont nous aurions oublié de désactiver certains comptes. -
Fonctionnalités de sécurité
Toutes les couches de sécurité (comme l’authentification multifacteur) dont vous souhaiteriez bénéficier pour votre système d’information devraient être mises en œuvre pour chaque système d’authentification, donc pour chaque application.
Ces inconvénients ont tous un point commun : le fait que le même utilisateur possède une identité pour chaque application qu’il utilise. Ne serait-il pas plus pratique que toutes ces applications délèguent leurs identités, et leur IAM par la même occasion, à une entité dédiée à cette tâche ?
C’est précisément le rôle de ce que nous appelons un Identity Provider (IdP).
Identités fédérées et fournisseur d’identité
Un fournisseur d’identité (identity provider) est un service qui gère l’authentification et l’autorisation des utilisateurs en vérifiant leur identité et en leur permettant d’accéder aux ressources numériques en toute sécurité.
Il agit en tant que gardien des identités pour tous les services qui lui délèguent leurs identités. Il joue un rôle central dans les IAM des entreprises.

En mettant en œuvre un fournisseur d’identité, l’utilisateur ne doit s’authentifier qu’une seule fois, et son identité sera propagée dans les applications auxquelles il souhaite accéder. Il sera authentifié pendant un certain temps dans toutes les applications qui ont délégué son identité (cela peut aller d’une heure à une journée entière). Dans le domaine de la fédération, ces applications sont souvent appelées fournisseurs de services (service provider, SP).
Comme l’utilisateur ne doit s’authentifier qu’une seule fois pour plusieurs applications, on parle de Single Sign-On (SSO). Ce terme est généralement utilisé dans les entreprises où les applications tournent autour du même écosystème.
Pour vous donner une meilleure idée de ce à quoi cela correspond, voici à quoi ressemble un flux de connexion classique :

Voici à quoi ressemble le flux de connexion via une identité fédérée :

Il s’agit d’un exemple de SSO dans une entreprise où le fournisseur d’identité est un Active Directory (AD).
Mais la logique est exactement la même pour les logins sociaux.
Oui, en effet ! Lorsque vous vous connectez à une application, par exemple Spotify, et que vous cliquez sur « Continuer avec Google », c’est exactement le même principe :

Ici, Google joue le rôle de fournisseur d’identité, et Spotify est le fournisseur de services. Spotify dispose de sa propre IAM si vous souhaitez y créer un compte, mais il propose également de déléguer votre identité à celle que vous possédez déjà chez Google.
Et voilà !
Mais, comment cela fonctionne-t-il ?
Comme tout système de communication, il existe des protocoles dédiés à la fédération d’identité. Principalement deux : SAML et OIDC.
Bien qu’ils suivent le même principe, ils ne fonctionnent pas tout à fait de la même manière et sont généralement utilisés dans des contextes différents.
Sans entrer dans les détails techniques, je décrirai plus en détail le protocole SAML pour expliquer le principe de la fédération avant de parler d’OIDC.
Security Assertion Markup Language (SAML)
Le protocole SAML en quelques mots
SAML est le protocole le plus utilisé pour la mise en œuvre du SSO dans les entreprises, principalement pour des raisons historiques.
Les données sont décrites en XML et transmises selon certaines règles.
La chose la plus importante à retenir est sans doute que tout passe systématiquement par le navigateur web, qui joue le rôle d’intermédiaire dans tous les échanges.
Via le navigateur, l’utilisateur tente d’accéder à un fournisseur de services (une application). Cette application est configurée pour déléguer ses identités, elle redirige donc immédiatement la demande d’authentification vers le fournisseur d’identité via une Requête SAML. Le fournisseur d’identité revient vers l’utilisateur via le navigateur pour lui demander de s’authentifier en utilisant son nom d’utilisateur et son mot de passe SSO. C’est à ce moment-là que l’utilisateur rencontre la page Active Directory vue dans le diagramme précédent. Cette interface s’appelle la mire de login.
Une fois authentifié par le fournisseur d’identité, celui-ci envoie une Assertion SAML (contenue dans une Réponse SAML). Il s’agit d’une sorte de laissez-passer délivré au fournisseur de services, disant « Je connais cet utilisateur et il s’est correctement authentifié auprès de moi, vous pouvez le laisser passer ». L’utilisateur accède alors au service demandé.
Ce qui est intéressant, c’est que maintenant que le fournisseur d’identité a accepté l’authentification de cet utilisateur, toute demande SAML envoyée par l’intermédiaire de cet utilisateur, quel que soit le fournisseur de services (tant qu’il se réfère au même fournisseur d’identité), sera automatiquement acceptée. Lorsque le fournisseur d’identité recevra la prochaine demande SAML, il enverra directement une assertion SAML sans passer à nouveau par la mire de login, du moins tant que le token de session est encore valide.
Il est important de noter que cela ne fonctionne que tant que la session de l’utilisateur est active. Si la session expire, l’utilisateur devra s’authentifier à nouveau (les entreprises fixent généralement une durée de vie d’environ 8 heures pour ce token de session, mais ça peut varier).
Remarque : l’authentification par identité fédérée dans SAML peut être IdP-initiated ou SP-initiated. Dans le premier cas, vous vous connectez directement à l’IdP pour effectuer le SSO. Dans le second cas, l’authentification se fait à partir d’un des fournisseurs de services liés au fournisseur d’identité. Ce deuxième cas, initié par le fournisseur de services, est le plus courant et est illustré dans ce diagramme.
La première application d’entreprise à laquelle l’utilisateur aura dû se connecter au cours de la journée est la seule qui lui ait demandé d’effectuer une authentification SSO.

- Ce qui définit un Fournisseur de service ici, c’est sa capacité à générer et à envoyer des Requêtes SAML et à consommer les Assertions reçues par l’intermédiaire d’un endpoint dédié. Cet endpoint est appelé Assertion Consumer Service (ACS).
- Ce qui définit un Fournisseur d’identité ici est sa capacité à consommer des Demandes SAML via un endpoint dédié appelé endpoint de Sign-In et à générer et envoyer des Assertions SAML.
La confiance en SAML
Vous ne remarquez pas qu’il manque quelque chose dans cette explication ?
Lorsque l’utilisateur veut accéder au fournisseur de services, comment ce dernier sait-il quel fournisseur d’identité contacter, et vice versa ? De plus, ils ne communiquent jamais directement, mais toujours par l’intermédiaire du navigateur. Alors, comment peuvent-ils se faire confiance ?
La réponse à la première question est très simple : il est possible de configurer un fournisseur d’identité pour qu’il spécifie les fournisseurs de services auxquels il peut faire confiance, et vice versa.
En ce qui concerne la confiance, elle est basée sur le même principe que TLS : via des certificats.
Le fournisseur de services doit donc connaître le certificat du fournisseur d’identité auquel il a délégué ses identités. Ainsi, lorsque le fournisseur d’identité enverra une assertion, celle-ci sera signée, et le fournisseur de service pourra vérifier la signature à l’aide de la clé publique contenue dans le certificat qu’il connaissait déjà.
Un fournisseur d’identité est tenu de signer sa réponse, soit au niveau de la réponse SAML, soit au niveau de l’assertion SAML.
De son côté, le fournisseur d’identité peut détenir les certificats des fournisseurs de services avec lesquels il communique, bien que cela ne soit pas obligatoire car il est assez rare de signer une Requête SAML, contrairement aux assertions.
En résumé, le fournisseur de services doit disposer des informations suivantes sur le fournisseur d’identité :
- IdP Issuer : l’identifiant du fournisseur d’identité.
- IdP Sign-In URL : pour que le fournisseur de services sache où envoyer ses demandes SAML.
- Certificat IdP : pour que le fournisseur de services puisse vérifier la signature du fournisseur d’identité lorsqu’il reçoit l’assertion.
Le fournisseur d’identité doit avoir pour chaque fournisseur de services :
- SP Issuer : l’identifiant du fournisseur de services.
- SP ACS URL : pour que le fournisseur d’identité sache où envoyer son assertion.
- Certificat SP : optionnel, pour que le fournisseur d’identité puisse vérifier la signature du fournisseur de service lorsqu’il reçoit la requête SAML (si elle est signée).
J’ai expliqué plus haut qu’il est possible de configurer ces informations d’un côté ou de l’autre, mais il est intéressant de savoir qu’un standard de fichier a été établi en SAML pour éviter d’avoir à tout configurer manuellement à chaque fois. Il s’agit des fichiers de métadonnées, contenant les informations utiles que l’on souhaite transmettre à l’autre partie avant de commencer les échanges.

Si vous souhaitez en savoir plus sur SAML, je vous recommande l’excellent article suivant Everything you should know about SAML and how to exploit it par Thibz, avec qui j’ai travaillé sur ce sujet.
Mais comme je l’ai mentionné, SAML n’est pas le seul protocole permettant la fédération d’identité. Mais pourquoi ? Pourquoi un autre standard a-t-il émergé si SAML fonctionne si bien ? Il y a plusieurs raisons à cela, et au lieu de les expliquer directement, jetons un rapide coup d’œil historique.
Historique de quelques méthodes de délégation
L’histoire de SAML
-
En 2002, SAML 1.0 a été lancé. Il permet la fédération des identités en fournissant une norme pour l’échange d’informations d’authentification entre plusieurs domaines de sécurité.
-
En 2005, SAML 2.0 a été publié. Il a étendu ces capacités en améliorant l’interopérabilité, en simplifiant le processus de fédération d’identité et en introduisant des fonctionnalités telles que Single Logout (SLO).
Mentionnons brièvement le SLO, qui permet une déconnexion unique chez tous les fournisseurs de services, mais je ne m’y attarderai pas, d’autant plus qu’il est très rarement mis en œuvre par les fournisseurs de services.
Maintenant, bien que cet article soit consacré à l’authentification, je vais parler rapidement de l’autorisation. Bien que cela puisse sembler hors sujet, vous verrez très vite que cela a une grande importance dans notre histoire.
La naissance d’OAuth
Parallèlement, c’est à cette époque que sont apparus toutes sortes de services qui se sont progressivement intégrés à notre vie quotidienne :
- les réseaux sociaux comme LinkedIn (2003) ou Facebook (2004)
- Les plateformes de partage de vidéos comme YouTube (2005)
Plus tard : - Les plateformes de partage de musique comme Spotify (2008)
- La diffusion de vidéos en direct comme Twitch (2011)
Et bien d’autres encore, pour ne citer que les plus connus.
Vous vous demandez peut-être pourquoi je parle de tout cela ? Parce que l’essor de tous ces services s’est accompagné de la nécessité de déléguer des autorisations. Pourquoi ? Prenons un exemple simple pour vous rafraîchir la mémoire : Facebook.
Lors de son lancement, pour accélérer sa croissance, Facebook voulait que chaque membre se connecte le plus rapidement possible avec ses connaissances, et s’ils n’étaient pas encore sur Facebook, leur proposer de rejoindre le réseau social par email.
Dans ce cas, Facebook avait besoin d’accéder aux contacts de messagerie de l’utilisateur, comme ceux de Gmail, le service le plus utilisé.
Voici comment ils ont procédé :

Oui, ils vous ont demandé votre nom d’utilisateur et votre mot de passe Gmail pour vous dire : « Ne vous inquiétez pas, je vais regarder vos contacts pour vous. Mais je vous promets qu’après ça, je ne regarderai plus rien d’autre, d’accord ? »
Vous vous en souvenez ? Aujourd’hui, cela semble absurde, n’est-ce pas ?
Le protocole OAuth 2.0 est apparu en 2012 (après Oauth 1.0 en 2010).
Le protocole OAuth permet à un utilisateur de déléguer à une application tierce l’accès à ses ressources sur un autre service sans partager ses informations d’identification, grâce à l’utilisation de tokens d’autorisation sécurisés.
Ces tokens contiennent des scopes qui limitent leur accès, par exemple « accéder aux contacts et à rien d’autre », ils ont des durées qui peuvent être limitées dans le temps et peuvent être révoqués à tout moment.
Dès que ce protocole a été mis en service, il a été rapidement adopté par Facebook, et la page web que vous voyez maintenant ressemble à ceci :

C’est mieux, non ? En tout cas, cela inspire beaucoup plus de confiance.
D’accord, mais j’entends déjà certains d’entre vous dire : « Hé, je lis déjà un long article sur la fédération d’identité, et maintenant vous parlez d’un protocole de délégation d’autorisation. C’est bien, mais ça n’a rien à voir ».
Et je vous comprends parfaitement, mais en fait, ça a plus à voir que vous ne le pensez. Car ce protocole, qui n’a pas été conçu à l’origine pour répondre aux besoins de fédération d’identité comme SAML, a fini par devenir la base du protocole de fédération d’identité le plus utilisé aujourd’hui : OIDC.
Avez-vous remarqué un point commun crucial entre SAML et OAuth ? Même si SAML concerne les identités et OAuth les permissions, les deux ont pour but de déléguer quelque chose.
Si vous l’avez remarqué, vous n’êtes pas le seul.
OpenID Connect (OIDC)
Le fonctionnement d’OIDC
La transition de SAML à OIDC découle principalement de l’évolution des besoins technologiques et des limites inhérentes à SAML, notamment sa complexité et sa dépendance à l’égard du format XML.
SAML, conçu en 2005, était largement utilisé pour la fédération d’identité dans les environnements d’entreprise, mais avec l’essor des applications web et mobiles, il était nécessaire de disposer de protocoles plus légers basés sur JSON et adaptés aux API REST.
Remarque: Cela ne signifie pas qu’il est impossible de gérer les autorisations avec SAML, mais seulement pas directement. SAML envoie dans ses assertions toute un mapping d’attributs contenant un ou plusieurs rôles, ce qui permet au fournisseur de services de gérer les autorisations basées sur du RBAC (Role-Based Access Control).
OAuth 2.0 a répondu à ce besoin en fournissant un cadre pour la délégation d’autorisation, mais il manquait une couche d’authentification robuste. OpenID Connect (OIDC), conçu en 2014, s’est appuyé sur OAuth 2 pour fournir cette couche d’authentification tout en conservant la simplicité et la flexibilité du modèle. OIDC a également adopté les JSON Web Tokens (JWT), qui sont beaucoup plus légers que les assertions XML utilisées par SAML, ce qui rend OIDC plus adapté aux environnements modernes.
L’OIDC a donc vu le jour pour répondre à la demande croissante d’un protocole d’authentification plus souple et plus facile à intégrer dans les architectures modernes, tout en s’appuyant sur les fondements d’OAuth.
Le passage de XML à JWT n’est évidemment pas la seule différence entre SAML et OIDC. Cette fois, les étapes sont divisées en deux flux :
Autorisation
Tout commence comme dans SAML : l’utilisateur essaie d’accéder à l’application. Ensuite, cette application envoie un nonce et les scopes demandés au fournisseur d’identité par l’intermédiaire du navigateur (via une redirection). Le nonce est un token aléatoire utilisé pour se protéger contre les attaques par replay en garantissant que la réponse d’authentification correspond à la demande originale envoyée par l’application.
Vient ensuite l’étape de l’authentification et du consentement. L’étape d’authentification est similaire à ce qui existe dans SAML, c’est-à-dire une page de connexion, mais avec une étape supplémentaire qui montre à l’utilisateur les scopes auxquels le fournisseur d’identité aura accès et lui demande son consentement pour ceux-ci.
Il existe deux scopes standard dans OIDC :
- Le scope profil : représente le droit de consulter les informations relatives à l’utilisateur (name, first name, email, email_verified).
- Le scope openid : représente le droit de recevoir un token d’identité comme preuve de connexion.
Le fournisseur d’identité envoie ensuite un code d’autorisation au navigateur, une fois encore par l’intermédiaire du navigateur.

La deuxième étape consiste à obtenir le token d’accès.
Obtention de l’access token
Le gros du travail a déjà été fait, cette étape sera extrêmement simple et brève. L’application dispose maintenant d’un code d’autorisation et communiquera directement avec le fournisseur d’identité, cette fois sans passer par le navigateur, pour communiquer ce code et le nonce. Le fournisseur d’identité répondra alors avec un token d’accès ainsi qu’un token d’identification.
Le token d’identification joue le même rôle qu’une assertion SAML, tandis que le token d’accès gère les permissions.
Ainsi, l’application peut renvoyer le service au navigateur.

C’est ainsi que se termine (presque) cette introduction à la fédération d’identité. J’espère que ce concept, ainsi que le fonctionnement de SAML et d’OIDC, sont maintenant plus clairs pour vous.
J’ai voulu vous parler de l’histoire de cette méthode, de son utilité et de son bien-fondé, mais j’ai aussi voulu conclure par une dernière section montrant ses limites actuelles.
Au-delà de la fédération
Points d’attention
Aussi pratique et innovante soit-elle, la fédération d’identité, comme toute méthode, a ses avantages mais aussi ses inconvénients. Il est important de les considérer et de les mentionner.
Point unique de défaillance
Tout d’abord, parlons du cas du SSO. Si la centralisation des données est au cœur de ses avantages, elle peut aussi représenter des risques.
L’accès à plusieurs applications étant lié à un seul fournisseur d’identité, si ce dernier subit des interruptions de service ou si le compte de l’utilisateur est bloqué, cela peut paralyser l’accès à toutes les applications liées.
Cependant, des solutions peuvent être mises en place, comme des systèmes de redondance, mais il est crucial d’être très conscient que la centralisation de la gestion des identités dans un seul système nécessite une attention particulière à ce système, que ce soit en termes de sécurité ou de haute disponibilité.
Confidentialité des données
Il y a également des réflexions importantes à se faire avec les logins sociaux. En choisissant un fournisseur d’identité par lequel vous vous authentifierez auprès de différents services, vous lui accordez votre confiance. Si vous utilisez le bouton « Se connecter avec Google », n’oubliez pas que vous faites confiance à Google. Je ne dis pas que c’est une mauvaise chose, mais il est important de garder cette information à l’esprit. Qu’il s’agisse de Google, de Facebook ou de tout autre fournisseur d’identité, posez-vous toujours la question suivante : « Suis-je prêt à faire confiance à cette entreprise pour déléguer mon identité au service auquel je veux accéder ? »
Personnellement, je l’évalue au cas par cas. Je trouve cela très pratique pour les outils quotidiens, mais je n’utiliserais pas la fédération d’identité pour accéder à des systèmes contenant des données très sensibles.
La bonne approche consiste donc simplement à être conscient de ce que l’on fait lorsqu’on s’engage dans la fédération d’identité et à se poser les bonnes questions pour prendre une décision éclairée.
Compromission de données
Que ce soit dans le cas d’un SSO ou d’un login social, si un pirate parvient à accéder au fournisseur d’identité, il peut potentiellement accéder à tous les services qui y sont liés. Je dirais que les meilleures pratiques pour éviter cela sont les mêmes que pour toute méthode d’authentification : activer l’authentification multifacteur (MFA) lorsque c’est possible et opter pour des mots de passe forts. Personnellement, j’active la MFA sur tous les services qui le proposent, et tous mes mots de passe sont très complexes et gérés par un gestionnaire de mots de passe.
Limitation technique
Il existe actuellement un certain nombre de limitations à la fédération d’identité. Je n’en décrirai qu’un seul, celui qui m’a de loin le plus marqué au cours de mon travail sur la fédération d’identité.
La délégation d’autorisations ne concerne que le fournisseur d’identité (impossible entre deux fournisseurs de services).
Dans les systèmes actuels de fédération d’identité tels que SAML ou OIDC, les autorisations sont centralisées par le fournisseur d’identité (IdP), qui délègue l’accès aux ressources aux fournisseurs de services (SP). Il n’est pas possible pour deux fournisseurs de services de transférer directement des autorisations entre eux sans passer par le fournisseur d’identité.
Cette absence de délégation inter-SP peut théoriquement être résolue par l’introduction d’une gestion normalisée des politiques, permettant une gestion unifiée des autorisations entre les différents fournisseurs de services.
Cette gestion est typiquement mise en place au sein des systèmes IAM des cloud providers.
Implémenter ce type de politique d’accès IAM au sein d’un cloud provider qui développe ses propres produits qu’il propose semble simplement concevable si on part du principe que ces politiques peuvent être intégrées directement au sein des produits.
Cependant, faire de même au sein cloud provider qui n’a pas accès au code source des produits qu’il a intégrés pour vendre des services peut s’avérer particulièrement difficile.
Il n’existe à l’heure actuelle aucun standard de délégation d’autorisation entre services providers, d’où la nécessité dans ce cas de créer sa propre norme de politiques d’accès unifiées inter-SP.
Merci d’avoir lu cet article. Si vous souhaitez approfondir les sujets que j’ai abordés, vous trouverez des sources dans la section ci-dessous.
Sources
Fédération d’identité
- https://www.okta.com/identity-101/why-your-company-needs-an-identity-provider/
- https://www.okta.com/blog/2022/08/exploration-of-open-identity-standards/
- https://www.descope.com/blog/post/saml-vs-oidc
- https://securityintelligence.com/posts/identity-and-access-management-evolution/
SAML
- https://developer.okta.com/docs/concepts/saml/
- https://blog.thibz.xyz/p/everything-you-should-know-about-saml-and-how-to-exploit-it/
- https://www.youtube.com/watch?v=l-6QSEqDJPo
- https://github.com/crewjam/saml
- https://kantarainitiative.github.io/SAMLprofiles/saml2int.html
- https://blog.thibz.xyz/p/everything-you-should-know-about-saml-and-how-to-exploit-it/
- http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
- http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
- http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
- http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf
OIDC
- https://developer.okta.com/docs/concepts/oauth-openid
- https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc
- https://www.rfc-editor.org/rfc/rfc6749
- https://openid.net/specs/openid-connect-core-1_0.html
Crédits
Tous les dessins et icônes des diagrammes ont été réalisés par Elissakarminakria: Linktree – Instagram - DeviantArt