Principes de base de la gestion des identités Azure

La gestion des identités est tout aussi importante dans le cloud public que sur site. À cette fin, Azure prend en charge différentes technologies d’identité cloud, à savoir :

  • Vous pouvez exécuter Windows Server Active Directory (souvent appelé tout simplement AD) dans le cloud au moyen de machines virtuelles créées avec les machines virtuelles Azure. Cette méthode est pertinente lorsque vous utilisez Azure pour étendre votre centre de données local au cloud.
  • Vous pouvez utiliser Azure Active Directory pour fournir à vos utilisateurs une authentification unique aux applications SaaS (Software as a Service) . Microsoft Office 365 fait appel à cette technologie, par exemple, et les applications s’exécutant sous Azure ou d’autres plateformes sur le cloud peuvent également y recourir.
  • Les applications s’exécutant dans le cloud ou localement peuvent utiliser le contrôle d’accès Azure Active Directory pour permettre aux utilisateurs de se connecter au moyen d’identités provenant de Facebook, de Google, de Microsoft et d’autres fournisseurs d’identités.

Cet article décrit l’ensemble de ces trois options.

Sommaire

Exécution de Windows Server Active Directory sur les machines virtuelles

L’exécution de Windows Server AD dans les machines virtuelles Azure est fort similaire à une exécution locale. figure 1 illustre un exemple type.

Azure Active Directory sur la machine virtuelle

Figure 1 : Windows Server Active Directory peut s’exécuter sur des machines virtuelles Azure connectées au centre de données local d’une organisation au moyen du réseau virtuel Azure.

Dans l’exemple présenté ici, Windows Server AD s’exécute sur des machines virtuelles créées au moyen de machines virtuelles Azure, la technologie IaaS de la plateforme. Ces machines virtuelles et quelques autres sont regroupées en réseau virtuel connecté à un centre de données local au moyen du réseau virtuel Azure. Le réseau virtuel élabore un groupe de machines virtuelles dans le cloud qui interagissent avec le réseau local par le biais d’une connexion VPN (réseau privé virtuel). Ces machines virtuelles Azure ressemblent ainsi à un autre sous-réseau pour le centre de données local. Comme illustré dans la figure, deux de ces machines virtuelles exécutent des contrôleurs de domaine Windows Server AD. Les autres machines virtuelles du réseau virtuel exécutent peut-être des applications, telles que SharePoint, ou sont peut-être utilisées d’une autre façon, par exemple à des fins de développement et de test. Le centre de données local exécute également deux contrôleurs de domaine Windows Server AD.

Il y a plusieurs façons de connecter les contrôleurs de domaine du cloud à ceux s’exécutant en local :

  • les intégrer tous à un domaine Active Directory unique ;
  • créer des domaines AD distincts localement et dans le cloud faisant partie de la même forêt ;
  • créer des forêts AD distinctes dans le cloud et localement, puis les connecter à l’aide d’approbations inter-forêts ou de services ADFS (Active Directory Federation Services) Windows Server, s’exécutant également sur des machines virtuelles sous Azure.

Quel que soit le choix effectué, un administrateur doit s’assurer que les demandes d’authentification provenant d’utilisateurs locaux parviennent aux contrôleurs de domaine dans le cloud uniquement lorsque cela est nécessaire, car le lien vers le cloud est susceptible d’être plus lent que sur les réseaux locaux. Un autre facteur à prendre en compte lors de la connexion de contrôleurs de domaine dans le cloud et localement est le trafic généré par la réplication. Généralement, les contrôleurs de domaine du cloud se trouvent sur leur propre site AD, ce qui permet à un administrateur de planifier la fréquence des réplications. Azure facture en fonction du trafic sortant d’un centre de données Azure, mais pas pour les octets en entrée, ce qui peut affecter les choix de l’administrateur en matière de réplication. Il convient également de mentionner que bien qu’Azure fournisse sa propre prise en charge du système DNS (Domain Name System), ce service ne dispose pas des fonctionnalités requises par Active Directory (telles que la prise en charge des enregistrements DNS dynamiques et SRV). Pour cette raison, l’exécution de Windows Server AD sous Azure nécessite de configurer vos propres serveurs DNS dans le cloud.

L’exécution de Windows Server AD sur les machines virtuelles Azure peut être pertinente dans plusieurs cas. Voici quelques exemples :

  • Si vous utilisez les machines virtuelles Azure en tant qu’extension de votre propre centre de données, vous pouvez exécuter des applications dans le cloud nécessitant des contrôleurs de domaine locaux pour gérer des éléments tels que les demandes d’authentification intégrée de Windows ou les requêtes LDAP. SharePoint, par exemple, interagit fréquemment avec Active Directory. Par conséquent, bien qu’il soit possible d’exécuter une batterie de serveurs SharePoint sous Azure à l’aide d’un annuaire local, la configuration de contrôleurs de domaine dans le cloud permet d’augmenter considérablement les performances. (Notez toutefois que ce n’est pas nécessairement obligatoire ; de nombreuses applications s’exécutent correctement dans le cloud en utilisant uniquement des contrôleurs de domaine locaux.)
  • Supposons qu’une filiale distante ne dispose pas des ressources suffisantes pour faire fonctionner ses propres contrôleurs de domaine. Dans la situation actuelle, ses utilisateurs doivent s’authentifier auprès de contrôleurs de domaine situés à l’autre bout du monde, avec pour conséquence une lenteur des connexions. L’exécution d’Active Directory sous Azure dans un centre de données Microsoft plus proche permet d’accélérer ce processus sans nécessiter l’installation de serveurs supplémentaires dans les bureaux de la filiale.
  • Une organisation utilisant Azure pour les récupérations d’urgence peut conserver un petit jeu de machines virtuelles actives dans le cloud, y compris un contrôleur de domaine. Ce jeu peut ensuite être préparé pour étendre ce site si nécessaire et prendre le relais en cas de défaillances ailleurs.

D’autres possibilités existent également. Par exemple, vous n’êtes pas obligé de connecter Windows Server AD dans le cloud à un centre de données local. Si vous voulez exécuter une batterie de serveurs SharePoint desservant un ensemble particulier d’utilisateurs, par exemple, qui se connectent tous uniquement à l’aide d’identités basées sur le cloud, vous pouvez créer une forêt autonome sous Azure. La façon dont vous utilisez cette technologie dépend de vos objectifs. (Pour plus d’informations sur l’utilisation de Windows Server AD avec Azure, cliquez ici.)

Utilisation d’Azure Active Directory

Alors que les applications SaaS deviennent de plus en plus courantes, elles soulèvent une question évidente : quel type de service d’annuaire ces applications basées sur le cloud utilisent-elles ? La réponse de Microsoft à cette question est Azure Active Directory.

Ce service d’annuaire peut être utilisé de deux façons principales dans le cloud :

  • Les individus et organisations utilisant uniquement des applications SaaS peuvent avoir recours à Azure Active Directory en tant que service d’annuaire unique.
  • Les organisations exécutant Windows Server Active Directory peuvent connecter leur annuaire local à Azure Active Directory, puis l’utiliser pour fournir à leurs utilisateurs une authentification unique aux applications SaaS.

figure 2 illustre la première de ces deux possibilités, dans laquelle Azure Active Directory est tout ce qu’il faut.

Azure Active Directory sur la machine virtuelle

Figure 2 : Azure Active Directory fournit aux utilisateurs d’une organisation une authentification unique aux applications SaaS, y compris Office 365.

Comme illustré dans la figure, Azure AD est un service mutualisé. Cela signifie qu’il peut prendre en charge simultanément de nombreuses organisations différentes et stocker des informations d’annuaire sur les utilisateurs de chacune d’elles. Dans cet exemple, un utilisateur de l’organisation A tente d’accéder à une application SaaS. Celle-ci peut faire partie d’Office 365, par exemple SharePoint Online, ou il peut s’agir d’une application d’un autre éditeur (les applications non fournies par Microsoft peuvent également utiliser cette technologie). Étant donné qu’Azure AD prend en charge le protocole 2.0, tout ce qui est exigé d’une application est la possibilité d’interagir au moyen de cette norme du secteur d’activité. (En fait, les applications utilisant Azure AD peuvent s’exécuter à partir de n’importe quel centre de données, pas uniquement un centre de données Azure.)

Le processus commence lorsque l’utilisateur accède à une application SaaS (étape 1). Pour pouvoir utiliser cette application, l’utilisateur doit présenter un jeton émis par Azure AD.

Ce jeton contient des informations identifiant l’utilisateur et il est signé numériquement par Azure AD. Pour obtenir le jeton, l’utilisateur s’authentifie auprès d’Azure AD en fournissant un nom d’utilisateur et un mot de passe (étape 2). Azure AD renvoie ensuite le jeton requis (étape 3).

Ce jeton est ensuite envoyé à l’application SaaS (étape 4), qui valide la signature du jeton et utilise son contenu (étape 5). Généralement, l’application utilise les informations d’identité figurant dans le jeton, entre autres, pour déterminer les informations auxquelles l’utilisateur peut accéder.

Si l’application a besoin de plus d’informations sur l’utilisateur que celles figurant dans le jeton, elle peut en faire directement la demande auprès d’Azure AD en utilisant l’API Azure AD Graph (étape 6). Dans la version initiale d’Azure AD, le schéma d’annuaire est assez simple : il contient simplement les utilisateurs et les groupes, ainsi que les relations entre ceux-ci. Les applications peuvent utiliser ces informations pour en savoir plus sur les connexions entre les utilisateurs. Supposons par exemple qu’une application souhaite savoir qui est le responsable d’un utilisateur afin de décider s’il est autorisé à accéder à une partie des données. Pour ce faire, elle peut interroger Azure AD par le biais de l’API Graph.

L’API Graph utilise un protocole RESTful ordinaire, ce qui facilite son utilisation par la plupart des clients, y compris les appareils mobiles. L’API prend également en charge les extensions définies par OData, en ajoutant des éléments tels qu’un langage de requête pour permettre aux clients d’accéder aux données de façons plus utiles. (Pour plus d’informations sur OData, consultez la page Présentation d’OData.) Étant donné que l’API Graph peut être utilisée pour découvrir les relations entre les utilisateurs, elle permet aux applications de comprendre le graphique social incorporé dans le schéma Azure AD pour une organisation particulière (c’est la raison pour laquelle on parle d’API Graph). En outre, pour s’authentifier auprès d’Azure AD pour les demandes de l’API Graph, une application utilise OAuth 2.0.

Si une organisation n’utilise pas Windows Server Active Directory (elle ne dispose d’aucun domaine ou serveur local) et qu’elle s’appuie uniquement sur les applications de cloud utilisant Azure AD, l’utilisation seule de cet annuaire de cloud fournit aux utilisateurs de l’entreprise une authentification unique pour toutes celles-ci. Bien que ce scénario soit de plus en plus fréquent, la plupart des organisations utilisent toujours des domaines locaux créés au moyen de Windows Server Active Directory. Azure AD dispose d’un rôle utile à jouer ici également, comme illustré dans la figure 3 .

Azure Active Directory sur la machine virtuelle Figure 3 : une organisation peut fédérer Windows Server Active Directory avec Azure Active Directory pour fournir à ses utilisateurs une authentification unique sur les applications SaaS.

Dans ce scénario, un utilisateur de l’organisation B tente d’accéder à une application SaaS. Auparavant, les administrateurs de l’annuaire de l’organisation doivent établir une relation de fédération avec Azure AD à l’aide d’AD FS, comme illustré dans la figure. Ces administrateurs doivent également configurer la synchronisation des données entre les applications Windows Server AD et Azure AD locales de l’organisation. Les informations de l’utilisateur et du groupe sont alors automatiquement copiées de l’annuaire local vers Azure AD. Grâce à cela, l’organisation étend son annuaire local au cloud. La combinaison de Windows Server AD et d’Azure AD de cette façon procure à l’organisation un service d’annuaire pouvant être géré en tant qu’entité unique, tout en conservant une présence à la fois en local et dans le cloud.

Pour utiliser Azure AD, l’utilisateur se connecte d’abord à son domaine Active Directory local en procédant comme d’habitude (étape 1). Lorsqu’il tente d’accéder à l’application SaaS (étape 2), en raison du processus de fédération, Azure AD envoie à l’utilisateur un jeton pour cette application (étape 3). (Pour plus d’informations sur le fonctionnement de la fédération, consultez le document Claims-Based Identity for Windows: Technologies and Scenarios (Identité basée sur des demandes pour Windows : technologies et scénarios).) Comme auparavant, ce jeton contient des informations identifiant l’utilisateur et il est signé numériquement par Azure AD. Ce jeton est ensuite envoyé à l’application SaaS (étape 4), qui valide la signature du jeton et utilise son contenu (étape 5). Comme dans le scénario précédent, l’application SaaS peut utiliser l’API Graph pour en savoir plus sur cet utilisateur si nécessaire (étape 6).

Aujourd’hui, Azure AD n’a pas vocation à remplacer entièrement Windows Server AD en local. Comme mentionné plus haut, l’annuaire sur le cloud présente un schéma bien plus simple, et il lui manque des éléments tels que la stratégie de groupe, la possibilité de stocker des informations sur les machines et la prise en charge du protocole LDAP. (En fait, une machine Windows ne peut pas être configurée pour permettre aux utilisateurs de s’y connecter en utilisant uniquement Azure AD : ce scénario n’est pas pris en charge.) À la place, les objectifs initiaux d’Azure AD sont, entre autres, de permettre aux utilisateurs d’entreprise d’accéder aux applications dans le cloud sans avoir à conserver une connexion distincte et d’éviter aux administrateurs d’annuaire locaux d’avoir à synchroniser manuellement leur annuaire local avec chaque application SaaS utilisée par leur organisation. Toutefois, attendez-vous à ce que, à terme, ce service d’annuaire dans le cloud prenne en charge une gamme plus étendue de scénarios.

Utilisation du contrôle d’accès Azure Active Directory

Les technologies d’identité basées sur le cloud permettent de résoudre un certain nombre de problèmes. Azure Active Directory peut fournir aux utilisateurs d’une organisation une authentification unique pour plusieurs applications SaaS, par exemple. Mais, les technologies d’identité dans le cloud peuvent également être utilisées d’autres façons.

Supposons, par exemple, qu’une application souhaite permettre à ses utilisateurs de se connecter au moyen de jetons émis par plusieurs fournisseurs d’identité (IdP). Actuellement, il existe de nombreux fournisseurs d’identité, y compris Facebook, Google et Microsoft, et les applications permettent souvent aux utilisateurs de se connecter au moyen de l’une de ces identités. Pourquoi une application devrait-elle se préoccuper de conserver sa propre liste d’utilisateurs et de mots de passe alors qu’elle peut s’appuyer sur des identités existant déjà ? L’acceptation des identités existantes facilite à la fois la vie des utilisateurs, qui ont un nom d’utilisateur et un mot de passe en moins à retenir, et celle des créateurs de l’application, qui ne doivent plus conserver leurs propres listes de noms d’utilisateur et de mots de passe.

Cependant, alors que chaque fournisseur d’identité émet un type de jeton, ces jetons ne sont pas normalisés ; chaque IdP dispose de son propre format. En outre, les informations figurant dans ces jetons ne sont pas non plus normalisées. Une application qui souhaite accepter des jetons émis, par exemple, par Facebook, Google et Microsoft, a pour défi d’écrire un code unique permettant de gérer chacun de ces différents formats.

Mais pourquoi procéder ainsi ? Pourquoi ne pas créer plutôt un intermédiaire pouvant générer un format de jeton unique avec une représentation commune des informations d’identité ? Cette méthode faciliterait la vie des développeurs créant les applications, étant donné qu’ils n’auraient plus qu’un seul type de jeton à gérer. Le contrôle d’accès Azure Active Directory procède exactement de cette façon : il fournit un intermédiaire dans le cloud permettant d’utiliser divers jetons. figure 4 illustre la façon dont cela fonctionne.

Azure Active Directory sur la machine virtuelle Figure 4 : le contrôle d’accès Azure Active Directory permet aux applications d’accepter plus facilement les jetons d’identité émis par différents fournisseurs d’identité.

Le processus commence lorsqu’un utilisateur tente d’accéder à l’application à partir d’un navigateur. L’application redirige celui-ci vers un IdP de son choix (qui dispose également de l’approbation de l’application). L’utilisateur s’authentifie auprès de cet IdP, par exemple en entrant un nom d’utilisateur et un mot de passe (étape 1) et l’IdP renvoie un jeton contenant des informations sur l’utilisateur (étape 2).

Comme illustré dans la figure, le contrôle d’accès prend en charge un large éventail d’IdP basés sur le cloud, y compris les comptes créés par Google, Yahoo, Facebook, Microsoft (antérieurement connu sous le nom de Windows Live ID) et tout fournisseur OpenID. Il prend également en charge les identités créées à l’aide d’Azure Active Directory et, par l’intermédiaire de la fédération avec les services AD FS, Windows Server Active Directory. L’objectif est de couvrir les identités les plus fréquemment utilisées actuellement, qu’elles soient émises par des IdP dans le cloud ou en local.

Une fois que le navigateur de l’utilisateur dispose d’un jeton IdP fourni par l’IdP choisi, il l’envoie au contrôle d’accès (étape 3). Ce dernier valide le jeton (en s’assurant qu’il a réellement été émis par cet IdP), puis crée un jeton en fonction des règles qui ont été définies pour cette application. À l’instar d’Azure Active Directory, le contrôle d’accès est un service mutualisé, mais les locataires sont des applications plutôt que des organisations clientes. Chaque application peut avoir son propre espace de noms, comme illustré dans la figure, et peut notamment définir diverses règles relatives aux autorisations.

Ces règles permettent aux administrateurs de chaque application de définir la façon dont les jetons provenant de différents IdP doivent être convertis en jetons de contrôle d’accès. Par exemple, si différents IdP utilisent des types distincts pour la représentation des noms d’utilisateur, les règles de contrôle d’accès peuvent convertir tous ceux-ci en type de nom d’utilisateur commun. Le contrôle d’accès renvoie ensuite ce nouveau jeton au navigateur (étape 4), qui l’envoie à l’application (étape 5). Une fois qu’elle a reçu le jeton de contrôle d’accès, l’application vérifie que celui-ci a réellement été émis par le contrôle d’accès, puis elle utilise les informations qu’il contient (étape 6).

Bien que ce processus puisse sembler quelque peu compliqué, en fait, il facilite considérablement la vie du créateur de l’application. Au lieu de devoir gérer différents jetons contenant des informations différentes, l’application peut accepter les identités émises par plusieurs fournisseurs d’identité tout en recevant seulement un jeton unique avec des informations connues. En outre, au lieu d’avoir à configurer chaque application individuelle pour qu’elle fasse confiance à différents IdP, ces relations d’approbation sont gérées par le contrôle d’accès : une application ne doit dès lors faire confiance qu’à ce dernier.

Il est intéressant de signaler que rien dans le contrôle d’accès n’est lié à Windows : il pourrait tout aussi bien s’agir d’une application Linux acceptant uniquement des identités Google et Facebook. Et bien que le contrôle d’accès fasse partie intégrante de la famille Azure Active Directory, il peut être considéré comme étant un service entièrement différent de ce qui a été décrit dans la section précédente. Alors que les deux technologies utilisent les identités, elles prennent en charge des problèmes assez différents (bien que Microsoft prévoie d’intégrer les deux à terme).

L’utilisation des identités est importante dans pratiquement chaque application. L’objectif du contrôle d’accès est de permettre aux développeurs de créer plus facilement des applications acceptant les identités de différents fournisseurs d’identité. En proposant ce service dans le cloud, Microsoft le met à la disposition de toute application s’exécutant sur n’importe quelle plateforme.

À propos de l’auteur

David Chappell est directeur associé de Chappell & Associates www.davidchappell.com à San Francisco, en Californie.