Authentification et Autorisation: la fédération d'identités

La fédération d’identités on en parlait déjà il y a dix ans. Le besoin et le contexte était différent : les applications étaient principalement hébergées en interne. Celles non compatibles avec des protocoles tels que LDAP et Kerberos avaient leur propre base de comptes utilisateurs. On déployait alors des solutions de Single Sign-On pour synchroniser ces bases de comptes entre-elles. Le problème de ces solutions, c’est que rien n’est normalisé. Il n’y a pas un protocole, pas de RFC. Et dans le monde informatique, ce fonctionnement n’est pas viable dans le temps. L’autre particularité, c’est le contexte qui évolue. Pour de nombreuses raisons, le SI de l’entreprise s’étend sur Internet ou bien c’est les applications qui sortent du SI pour être remplacées par des offres SaaS. La problématique autour de l’authentification reste néanmoins la même. [caption id="attachment_14548" align="aligncenter" width="598"]

Oauth protocole[/caption]

Comment se connecter avec ses identifiants du domaine sur une application externe ?

L’utilisation du protocole Kerberos n’est pas envisageable dans ce contexte pour de multiples raisons. La méthode fréquemment utilisée consiste à faire communiquer l’application avec le référentiel des identités (Active Directory, …) en LDAPS pour transporter les données d’authentification (nom d’utilisateur, mot de passe, …). D’un point de vue sécurité, cette solution n’est pas acceptable pour plusieurs raisons. La protocole SAML a donc été défini pour répondre au même besoin sans transporter ces données d’authentification de l’application vers le référentiel des identités. D’un point de vue sécurité, les objectifs semblent atteints. D’un point de vue fonctionnel, des contraintes existent, principalement dans un contexte B2C (Applications mobiles, …). Le protocole Oauth a donc été défini pour répondre à ces problématiques d’interopérabilité et de protection des données d’authentification. Le protocole a par la suite évolué vers une version 2 incompatible avec la version 1 normalisée par le RFC 6749.

Dans ce RFC, quatre rôles sont définis :

• Resource owner : le serveur Web par exemple qui héberge l’application
• Resource server : le reverse proxy qui va publier et protéger l’accès à l’application
• Client : client à l’origine de la demande d’un jeton d’accès
• Authorization server : le serveur qui vérifie les identités et fournis les jetons d’accès

Il faut ajouter dans cette liste l’utilisateur (le « user agent » en d’autres termes) qui souhaite accéder à l’application.

Quatre méthodes d’implémentation sont également proposées :

• Authorization Code
• Implicit
• Resource Owner Password Credentials
• Client credentiels

Deux types de jetons d’accès sont définis :

• Access token : jeton d’accès contenant les détails de l’accès autorisé
• Token refresh (optionnel): jeton permettant d’obtenir un nouvel access token dans un schéma raccourci

Mode password En mode password, le client Oauth envoie une requête POST à l’authorization server contenant les credentiels à vérifier, son client ID et son client secret.

Mode authorization code

En mode authorization code, on fait intervenir le user agent. Ce dernier est redirigé par le client Oauth vers l’authorization server avec l’URL de retour (callback) et le client ID en paramètre. L’authorization server va vérifier dans un premier temps l’identité de l’utilisateur. L’authorization server peut également demander au user agent s’il approuve l’accès à l’application et l’utilisation de ses données personnelles fournis dans la réponse. En cas de succès, l’authorization répond par un code 302 avec un “authorization code” pour rediriger le user agent vers l’URL de retour (callback). Le client Oauth peut ensuite obtenir un token en envoyant une requête POST à l’authorization server contenant l’ “authorization code”, le client ID et le client secret.

Le fonctionnement de Mode authorization code est présenté dans le schéma suivant :

[caption id="attachment_14546" align="aligncenter" width="525"]

Authentification par fédération d'identités[/caption] Chaque mode d’implémentation du protocole Oauth présente ses avantages et ses inconvénients. Notre rôle dans ce contexte est de vous accompagner dans l’expression de vos besoins et le choix de cette méthode. L’experience acquise dans le cadre de nos déploiements et notre expertise sont nos alliés pour vous accompagner sereinement dans la réalisation de ce type de projet.