Je commencerai par dire que les technologies d'identité actuelles peuvent prêter à confusion. Il existe de nombreux services (à l'ère du cloud, tout est un service), protocoles, solutions, SDK, technologies et produits visant à résoudre le problème de l'identité.

Je vais commencer par comparer les deux principaux, qui sont sans doute ceux qui prêtent le plus à confusion puisqu'ils portent le même nom : le bon vieux Active Directory Domain Services (ADDS en abrégé) et Windows Azure Active Directory (AAD en abrégé).

ADDS est utilisé depuis une éternité (enfin, 13 ans en informatique, ça semble une éternité) pour fournir des services d’authentification et d’autorisation (AuthN et AuthZ) au sein du centre de données d’entreprise (l’environnement sur site). Il est très populaire (87 % des entreprises du classement Fortune 1 000 l’utilisent, selon Gartner) et s’est révélé très fiable pour fournir tous les services requis. (Avertissement : j’ai assuré son support lorsque je travaillais chez Microsoft, j’ai donc une certaine affection pour ce produit).

Mais dans le contexte actuel en pleine évolution, cela ne suffit plus vraiment, et la raison en est simple : le cloud !

Si l'on considère le centre de données local et l'environnement en nuage, il existe de nombreuses différences dans les protocoles et les solutions utilisés, et ce pour plusieurs raisons, mais les trois principales sont les suivantes : la sécurité, la confidentialité et l'interopérabilité : la sécurité, la confidentialité et l'interopérabilité.

Si l'on considère les protocoles utilisés au sein du centre de données local pour l'authentification et l'autorisation, on peut dire sans risque que Kerberos est le protocole le plus courant aujourd'hui, et si l'on considère l'accès aux données utilisé dans les centres de données aujourd'hui pour accéder au magasin d'identité, je dirais que LDAP est le protocole le plus courant, pris en charge par presque tous les fournisseurs d'annuaires disponibles sur le marché.

C'est donc exactement ce que fait ADDS : Il authentifie les utilisateurs et autorise l'accès aux ressources en utilisant Kerberos, et fournit un accès au magasin de données en utilisant le protocole LDAP.

« Mais ensuite, le « cloud » est arrivé » (et Facebook, qui a un lien très concret avec ce phénomène)

Quand on observe la manière dont l'AuthN et l'AuthZ sont gérées (ou non) dans le cloud, on comprend assez bien pourquoi Kerberos n'est pas tout à fait à la hauteur.

En effet, lorsque l'on utilise Kerberos, on spécifie des clés qui servent à chiffrer les tickets Kerberos et qui sont fournies par une seule source faisant autorité. Cela n'est pas possible dans un environnement cloud (quelles clés utiliseriez-vous si vous vouliez authentifier un compte Facebook auprès d'un service Google ? Il n'y a pas de référentiel d'identités central, ni de fournisseur de clés central !).

C'est alors que SAML, OAuth, OpenID et plusieurs autres sont venus à la rescousse. Toutes ces technologies permettent une connexion fédérée. (En gros, comment puis-je me connecter de Facebook à Google sans avoir à saisir deux fois mes informations d'identification). Chacune a sa propre spécification, mais l'objectif principal est de permettre l'authentification à travers différents services par différents fournisseurs de services/cloud (ai-je mentionné l'interopérabilité ?).

En ce qui concerne la couche d'accès aux données, le même principe s'applique. Même si LDAP pourrait fonctionner, il existe une solution plus pertinente pour gérer les relations entre les utilisateurs (qu'il s'agisse d'utilisateurs au sein d'une organisation ou de consommateurs disposant de photos de profil et de murs) : le Graph !

L'utilisation de Graph comme base de données (en particulier comme base d'identités) est tout à fait logique, car contrairement au LDAP, il n'est pas hiérarchique et permet de mettre en évidence les « liens » entre les utilisateurs et les ressources au sein de l'organisation. Cela vous permet ainsi de gérer véritablement une identité, plutôt que de vous contenter d'une hiérarchie globale utilisée pour organiser les identités dans des « dossiers » selon les critères jugés pertinents par l'organisation.

C'est là que l'Azure Active Directory entre en jeu. AAD est un IDaaS (Identity as a Service) basé sur le cloud et fourni par Microsoft qui utilise des normes ouvertes (SAML par exemple) afin d'authentifier les utilisateurs et de permettre la fédération d'identité entre les services cloud, ainsi que le modèle de données Graph afin d'interroger et de gérer les objets.

Voici un petit tableau comparatif des deux :

Azure Active Directory Services de domaine Active Directory
Fournit le SSO et le référentiel des utilisateurs pour les services en nuage. Fournit la gestion du SSO et de l'identité pour les services sur site.
Fournir une plateforme extensible pour la gestion des rôles destiers Ne permet pas la gestion des rôles pour les services cloudtiers
Fournit une plateforme d'identité en nuage multi-tenant S'appuie sur une plate-forme à locataire unique sur site
Utilisation de normes industrielles pour l'authentification dans le nuage Utilisation de normes industrielles pour l'authentification sur site
Utilise l'API graphique pour l'accès aux données Utilise le protocole LDAP pour l'accès aux données

En conclusion, ADDS nous permet de nous connecter à notre réseau d'entreprise, d'accéder aux ressources situées dans le réseau d'entreprise et permet aux services d'interroger des informations sur des objets tels que les utilisateurs, les groupes et les ressources.

L'AAD permet de se connecter à nos services en nuage, d'accéder aux ressources situées dans le nuage et de permettre aux services en nuage d'interroger des informations sur les objets.

J'espère que cela a permis de mieux comprendre les deux.

Dans le prochain article, j'essaierai d'expliquer comment ces deux éléments peuvent être reliés entre eux pour former une identité « hybride » (qui permet d'utiliser le même compte aussi bien pour les ressources sur site que pour les services cloud).