Je commencerai par dire que les technologies d'identité d'aujourd'hui peuvent être très déroutantes. 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 commencerai par comparer les deux principaux, qui sont peut-être les plus déroutants car 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 des lustres (enfin, 13 ans dans les ordinateurs semblent être des lustres) pour fournir des services d'authentification et d'autorisation (AuthN et AuthZ) au sein du centre de données de l'entreprise (l'environnement sur site). Il est assez populaire (87 % des entreprises du Fortune 1000 l'utilisent, d'après Gartner) et il s'est avéré assez solide pour fournir tous les services requis. (Clause de non-responsabilité : j'ai travaillé pour MSFT, donc j'aime bien le produit).

Mais dans le paysage changeant d'aujourd'hui, ce n'est plus vraiment suffisant, et la raison en est : Ze 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 est arrivé le "nuage" (et Facebook, qui a un lien très tangible).

Si l'on considère la manière dont AuthN et AuthZ sont gérés (ou ne sont pas gérés) dans le nuage, il est assez compréhensible que Kerberos ne soit pas tout à fait suffisant.

En effet, lorsque vous utilisez Kerberos, vous spécifiez les clés qui sont utilisées pour crypter les tickets Kerberos et qui sont fournies par une source unique faisant autorité. Cela n'est pas possible dans l'environnement en nuage (quelles clés utiliseriez-vous pour authentifier un compte Facebook auprès d'un service Google ? Il n'y a pas de magasin d'identité 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é ?).

La même chose s'applique à la couche d'accès aux données. Bien que LDAP puisse fonctionner, il y a quelque chose de plus logique pour gérer les connexions entre les personnes (qu'il s'agisse d'utilisateurs organisationnels ou de consommateurs avec des photos de profil et des murs), c'est le graphe !

L'utilisation de Graph pour un magasin de données (en particulier un magasin d'identité) est parfaitement logique car il n'est pas hiérarchique comme LDAP et peut réellement montrer les "connexions" entre les utilisateurs et les ressources de l'organisation, ce qui vous permet de gérer réellement une identité, plutôt qu'une hiérarchie entière utilisée pour organiser les identités dans des "dossiers" en fonction de ce que l'organisation a décidé comme étant logique pour elle.

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 N'offre pas la possibilité de gérer les rôles des services cloud detierces parties
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 de voir comment les deux peuvent être interconnectés pour obtenir une identité "hybride" (qui permet d'utiliser le même compte pour les ressources sur site et les services en nuage).