La fédération d’identité


Qu’est-ce que la fédération d’identités ?

En quoi centraliser les données est essentiel pour les entreprises ? Décryptage avec notre expert cybersécurité.

Partager l’article :

Principe de base

La fédération d’identités est un concept qui vise à mettre en place une centralisation des données, et notamment des données d’identité, au sein d’un domaine informatique. Ainsi un utilisateur ne se connectera qu’une unique fois par session auprès d’une structure reconnue qui lui fournira la preuve de son identité (sous forme de jeton). L’utilisateur le présentera aux autres ressources qui souhaitent s’assurer de son identité, sans qu’il n’ait à dérouler une nouvelle procédure d’authentification. Qui dit une seule authentification (dite primaire), dit un seul mot de passe. Il est alors plus facile d’appliquer une politique de renouvellement et complexité sans se confronter aux utilisateurs récalcitrants. La fédération d’identités permet également de centraliser les données d’un utilisateur (comme son adresse mail de contact, un nom, une langue). Ces données sont appelées « attributs » et leur centralisation permet, entre autres, de les modifier plus facilement.

Les acteurs

Dans un schéma en fédération d’identités, il est nécessaire de reconnaître trois acteurs et d’identifier les différents flux entre eux :

  • L’utilisateur : il s’agît de la personne qui interagit via son navigateur web. Il a une unique identité numérique associée à plusieurs attributs et souhaite accéder à une application protégée.
  • Le fournisseur d’identité : il est l’élément central de l’architecture. Il est chargé d’authentifier les utilisateurs. Il vérifie les facteurs d’authentification de l’utilisateur et fournit la preuve de son identité. Il est aussi en charge des autorisations d’accès aux attributs. On parle également d’Identity Provider – IdP.
  • Le fournisseur de service : il s’assure de l’identité de l’utilisateur et peut avoir besoin des attributs de l’utilisateur. On parle également de Service Provider – SP.

Les flux

Ces différents acteurs interagissent entre eux pour, in fine, autoriser l’accès à l’utilisateur. Requête client, réponse avec jeton… Voici les étapes clés :

1. Requête client : l’utilisateur demande l’accès à un service protégé par une authentification ;
2. Redirection : le fournisseur de service redirige l’utilisateur vers le fournisseur d’identité pour qu’il puisse s’authentifier ;
3. Authentification : l’utilisateur s’authentifie (il justifie de son identité) à l’aide des facteurs d’authentification compatibles avec la méthode en place (login/mot de passe, clé, OTP …) ;
4. Réponse avec jeton : le fournisseur d’identité redirige l’utilisateur vers le fournisseur de service accompagné du jeton attestant de son identité ;
5. Accès à l’application : le fournisseur de service évalue le jeton et autorise l’accès de l’utilisateur.

Schéma de la fédération d'identité par Orange Cyberdefense

Focus sur la vulnérabilité « CovertRedirect »

Présentation

Ces redirections rendent les flux transparents pour l’utilisateur. Or une redirection mal gérée peut être exploitée par un attaquant pour lui permettre de rediriger l’utilisateur vers un site malveillant (phishing ou téléchargement de malware). CovertRedirect n’est pas une vulnérabilité protocolaire mais bien une vulnérabilité touchant l’implémentation des protocoles qui est faite sur certains services.

L’exploitation de redirection est un problème bien connu : OpenRedirect1, vulnérabilité des redirections est classé dans le top 10 OWASP depuis 2010.

Cette faille vise les sites qui comportent des liens de cette forme :

siteWeb.com/Other/Path?redirectionVers=UneAutrePageOuUnAutreSite

Ces liens permettent aux applications d’effectuer un traitement (côté serveur) avant de rediriger l’utilisateur vers la ressource souhaitée définie en tant que paramètre dans l’URL (comme une destruction de session avant une redirection vers la page d’accueil sur un bouton « log off » par exemple).

Dans la majorité des cas, ces liens proviennent d’une mauvaise conception, et leur implémentation est fortement déconseillée. SiteWeb.com peut alors servir de relais pour un phishing. par exemple, un attaquant peut forger un lien de type :

siteWeb.com/Other/Path?redirectionVers=UnSiteCorrompu.com

CoverRedirect : historique

CovertRedirect est apparu au printemps 2014, mise en évidence par Wang Jing, doctorant à l’université de nouvelles technologies de Nanyang à Singapour. L’impact de cette vulnérabilité est d’abord estimé comme important car une grande partie des géants du web seraient impliqués (GAFA, LinkedIn, Yahoo, Live, GitHub). Puis dans un second temps les spécialistes se rétractent pour finalement minimiser son impact [2].

CovertRedirect qui exploite la présence d’OpenRedirect sur des sites impliqués dans la fédération d’identités. Comment opère-t-elle ? Pour mieux la comprendre, mettons nous en situation. Un utilisateur souhaite s’authentifier sur un site monSiteWeb.com à l’aide de son identité gérée par le site myGreatIdP.com

La fédération d'identité par Orange Cyberdefense

L’utilisateur se connecte au client monSiteWeb.com [1] qui va envoyer l’utilisateur faire la demande d’authentification sur le serveur cible. Pour cela il redirige l’utilisateur [2] sur une URL de type :

myGreatIdP.com/dialog/authen?redirect=monSiteWeb.com/UserProfile?scope=DroitsDuJeton&client_id=11

monSiteWeb.com/UserProfile est l’adresse sur laquelle le serveur attend la réponse d’authentification.

L’utilisateur s’authentifie sur myGreatIdP.com [3] qui le redirige [4] vers :

monSiteWeb.com/UserProfile?token=ValeurDuJeton

monSiteWeb.com peut maintenant utiliser ce jeton pour identifier l’utilisateur et lui fournir l’accès demandé [5].

Maintenant dans le cas où monSiteWeb.com contient une redirection sur

monSiteWeb.com/LogOff?GoTo=HomePage.html

Un attaquant peut exploiter CovertRedirect en faisant cliquer un utilisateur sur un lien de ce type :

myGreatIdP.com/dialog/authen?redirect=monSiteWeb.com/LogOff?GoTo=MyEvilWebsite.fr/Input/CovertRedirect&response_type=token?scope= DroitsDuJeton&client_id=11

On y retrouve :

  • l’application,
  • le fournisseur d’identité,
  • un serveur malveillant.

C’est l’étape 1 de l’attaque.

L’utilisateur se retrouve alors sur myGreatIdP.com qui lui demande de s’authentifier pour le site monSiteWeb.com [2].
Il est alors redirigé par l’IdP vers la page de redirection monSiteWeb.com [3]

monSiteWeb.com/LogOff?GoTo=MyEvilWebsite.fr/Input/CovertRedirect?token=ValeurDuJeton

Le site fera les traitements de LogOff (destruction de session par exemple) et rédigera l’utilisateur (à cause de sa vulnérabilité OpenRedirect) vers

MyEvilWebsite.fr/Input/CovertRedirect?token=ValeurDuJeton

L’attaquant aura alors dans les logs du serveur la valeur du jeton. Il peut sous certaines conditions réutiliser ce jeton pour accéder en lecture (ou écriture parfois) aux données de l’utilisateur.

La fédération d’identités : un facteur multiplicateur d’impact ?

Dans un schéma en fédération d’identités, les murs internes au SI peuvent être vus comme plus fins, et le poids portée par l’authentification plus lourd. Ainsi, la fédération d’identités peut être vue comme un facteur multipliant les impacts d’une possible attaque. Si l’identité d’un des utilisateurs est compromise, ses accès à l’ensemble des applications du périmètre seront affectés. Si un incident intervient sur la brique d’authentification, l’ensemble de mes utilisateurs seront concernés. Il est donc essentiel de pouvoir gérer ces potentiels incidents en intégrant des mécanismes de hautes disponibilités et en renforçant la sécurité de l’authentification.

En réalité, la fédération d’identités doit plutôt être vue comme un simplificateur du SI, et les vulnérabilités structurelles ou protocolaires y sont plutôt rares. Les identités et habilitations seront administrées centralement, et les utilisateurs ne seront plus obligés de manipuler une multitude d’identifiants et de mots de passe (parfois auto-synchronisés). Ces projets nécessitent une grande implication de l’ensemble des métiers de l’entreprise, mais simplifiera l’expérience utilisateurs et pourra permettre de faire appliquer certaines contraintes de sécurité propres aux secteurs et métiers.

Références
[1] https://www.owasp.org/index.php/Open_redirect
[2] http://www.theregister.co.uk/2014/05/05/covert_redirect_is_overt_hype_more_heartbleat_than_heartbleed/

A propos du blogueur

 Baptiste David est consultant cybersécurité chez Orange Cyberdefense.

Suivez-nous sur Twitter :
Orange Cyberdefense @OrangeCyberdef

@VanDenBergheOCD CEO @orangecyberdef inaugure en compagnie des députés @JeanMichelMIS & @tgassilloud et du Général de @gendarmerie Ph. Guimbert Commandant de la Région #Auvergne #RhôneAlpes le Campus de #Lyon d'@orangecyberdef https://t.co/rT2TtrjnjV

Orange Cyberdefense @OrangeCyberdef

Ce vendredi 19/10 @VanDenBergheOCD CEO @OrangeCyberdef inaugurera avec les députés @tgassilloud & @JeanMichelMIS et le Général Philippe Guimbert Commandant la Région #Auvergne #RhôneAlpes de @Gendarmerie le Campus @orangecyberdef de Lyon dédié à la #cybersécurité industrielle. https://t.co/Acww0hyTHM

Orange Cyberdefense @OrangeCyberdef

"Hello jobs - Interview de Bertrand, consultant en sécurité" : https://t.co/Vaop63eZUp via @YouTube

Orange Cyberdefense @OrangeCyberdef

Bon anniversaire 🎂 @cybervictimes ! @orangecyberdef est fier d'être parmi les partenaires fondateurs de ce GIP public/privé qui œuvre à une meilleure cyberrésilience des particuliers et des PME-PMI visés par des cyberattaques. https://t.co/fVW3fe8xrQ https://t.co/Hg5PyrGSJG

Orange Cyberdefense @OrangeCyberdef

Dans @Annonce_Legales @VanDenBergheOCD CEO @OrangeCyberdef insiste au @MEDEF_I @medefNUM sûr l’importance des prestataires de confiance dans le domaine de la cybersécurité @orangebusiness @MarcRennard https://t.co/yjjhMHpVk5