VENTES: 1-800-867-1389

Autorisation et authentification Service Bus avec le service de contrôle d'accès

Le Windows Azure Service Bus prend en charge l'utilisation de Active Directory Access Control de Windows Azure (également appelé Access Control Service ou ACS) pour autoriser les opérations du Service Bus.

Active Directory Access Control de Windows Azure (également appelé Access Control Service ou ACS)

Le ACS facilite l'authentification, c'est-à-dire qu'il définit l'identité d'un appelant. ACS peut définir l'identité de l'appelant de deux façons. Soit il définit l'identité à partir de la liste délimitée par l'espace de noms des identités de service (ou comptes) à l'aide d'un nom d'utilisateur classique et d'un schéma de mot de passe, soit il délègue la définition de l'identité à un fournisseur d'identité externe, tel qu'ADFS (Active Directory Federation Services), Windows Live ID, Facebook, Google ID, Yahoo ID ou OpenID.

Une fois l'identité établie, ACS a (ou reçoit) un nombre de revendications concernant l'identité. Ces revendications fournissent des affirmations concernant la personne (ou le compte), et sont signées numériquement par le fournisseur d'identité qui les a émises, ce qui assure à ACS que les revendications sont correctes ou, du moins, conformes aux règles de gestion de l'émetteur. En d'autres termes, un ensemble de revendications indiquant que l'identité représentée est celle de « Bill Gates, président de Microsoft Corporation » est probablement plus digne de confiance quand il est émis via la passerelle Microsoft ADFS, et moins quand il provient d'une tierce partie. Les revendications qui sont constamment disponibles pour tous les fournisseurs d'identité et aussi pour les identités de service intégrées à ACS sont la revendication du fournisseur (identifiant le fournisseur lui-même) et la revendication « nameidentifier », qui est l'identificateur propre et unique au fournisseur de l'identité donnée.

Deuxièmement, ACS facilite l'autorisation en autorisant les revendications émises par les fournisseurs d'identité à être mappées vers des revendications qui sont comprises par une « partie de confiance ». Service Bus est cette partie de confiance, ce qui signifie qu'il repose sur ACS pour gérer l'authentification et l'autorisation. Le mappage des revendications remplit deux fonctions : Premièrement, il normalise les revendications provenant d'une multitude de « langues » de revendication différentes en un seul jeu de revendications comprises par le service, et, deuxièmement, le mappage agit comme un ensemble de règles d'autorisation. À défaut de mappage pour une identité donnée à une série de revendications comprises par le service, l'identité n'a pas accès au service.

L'authentification et l'autorisation passent toujours par le client, et le client est le seul composant qui nécessite une visibilité de réseau directe pour toutes les parties. Il est, par exemple, possible d'utiliser un service ADFS qui n'est pas exposé à l'extérieur du pare-feu d'entreprise conjointement avec ACS puisque ACS et ADFS ne se contactent jamais directement. Lorsqu'un client souhaite effectuer une opération sur une ressource protégée, tel que l'envoi d'un message à une file d'attente Service Bus, il doit obtenir la preuve qu'il est autorisé à le faire. Cette preuve s'obtient, dans ACS, sous forme d'un « jeton ». Le jeton est simplement un conteneur pour un ensemble de revendications et il est signé numériquement par l'émetteur. Si ACS est configuré pour établir l'identité à l'aide d'un fournisseur d'identité externe tel qu'ADFS, il y a au moins deux jetons en jeu. Le premier jeton est acquis à partir d'un fournisseur d'identité tels qu'ADFS, fournissant l'un des nombreux types de preuve de l'identité de l'utilisateur en tant que données d'entrée. Ce jeton est ensuite remis à ACS, qui l'évalue, exécute les règles et émet le jeton pour la partie de confiance.

Service Bus et ACS

Le Service Bus et ACS ont une relation particulière dans le sens où chaque Service Bus espace de noms de service est jumelé à un ACS espace de noms de service correspondant du même nom, avec le suffixe « –sb ». La raison de cette relation particulière réside dans la façon dont Service Bus et ACS gèrent leur relation d'approbation mutuelle et les secrets de chiffrement associés.

Le Service Bus peut créer une fédération avec ACS V1 ainsi qu'avec ACS V2. Tous les espace de noms de service qui ont été créés avant la version de septembre 2011 du Service Bus créent une fédération avec ACS V1, et tous les espace de noms de service créés après la mise à jour du service créent une fédération avec ACS V2. Cette rubrique porte uniquement sur ACS V2, qui est la version actuelle du service ACS.

À l'intérieur de espace de noms de service ACS « -sb », que vous pouvez explorer du portail Windows Azure en sélectionnant le Service Bus espace de noms de service et en cliquant sur l'icône ACS dans le ruban, se trouve une définition de partie de confiance « ServiceBus » suivant la navigation « Applications de partie de confiance ». La définition de partie de confiance a une valeur de « domaine » mappant vers la racine des espace de noms de service Service Bus correspondants (utilisant le schéma « http W) et définit le type de jeton sur « SWT » et le délai d'expiration des jetons à 1 200 secondes. De plus, les clés de signature ne sont pas gérables ni accessibles via le portail ou l'API.

Associé à la définition de partie de confiance « ServiceBus » se trouve un « Groupe de règles par défaut pour Service Bus » contenant le mappage de base qui permet au « propriétaire » d'un espace de noms de service d'agir en tant que super utilisateur sur le espace de noms de service. Le groupe de règles contient, par défaut, trois règles simples qui mappent la revendication d'entrée « nameidentifier » pour l'identité du service du « propriétaire » vers les trois revendications d'autorisations comprises par Service Bus: « Envoyer » pour toutes les opérations d'envoi, « Écouter » pour écouter ou recevoir des messages et « Gérer » pour observer ou gérer l'état du locataire de Service Bus. Le Service Bus ne tient pas compte des autres revendications figurant dans les jetons. L'identité du service du « propriétaire » est une identité de service classique dans le espace de noms de service ACS. Il est possible, et conseillé, d'en créer davantage. En fait, l'utilisation de l'identité du « propriétaire » doit être limitée à l'exécution des tâches administratives.

Définitions et portée de la partie de confiance

Lorsqu'un client demande un jeton d'autorisation pour envoyer un message à une file d'attente située, par exemple, à l'adresse https://tenant.servicebus.windows.net/my/test, la demande de jeton inclura une forme normalisée de l'adresse cible en tant que domaine cible. Cette « normalisation » utilise simplement un schéma d'URI commun à tous les protocoles. Par conséquent, la demande de jeton permettant d'interagir avec une entité Service Bus résidant à l'adresse https://tenant.servicebus.windows.net/my/test ou sb://tenant.servicebus.windows.net/my/test sera toujours effectuée à l'aide d'un URI de domaine à l'aide du schéma « http » http://tenant.servicebus.windows.net/foo/bar. Par conséquent, toutes les définitions de partie de confiance doivent également utiliser le schéma « http » de l'URI « normalisé » pour l'URI de domaine.

Lorsque la demande arrive à ACS, ACS fera correspondre l'URI de domaine aux définitions de partie de confiance au moyen de la « plus longue correspondance de préfixe », ce qui signifie que la partie de confiance dont l'adresse « URI de domaine » est le plus long préfixe disponible de l'adresse pour laquelle le jeton est demandé, la définition de la partie de confiance, et ses définitions de règles associées sont sélectionnées et exécutées. La définition de partie de confiance « ServiceBus » par défaut est étendue à tous les espace de noms de service Service Bus correspondants, ce qui signifie que son URI de domaine, correspondant à l'adresse racine espace de noms de service Service Bus, est un préfixe de toutes les adresses possibles sur un espace de noms de service Service Bus. En tant que telles, les définitions de règles activées sur cette définition de partie de confiance accordent un accès total à l'intégralité de espace de noms de service Service Bus.

Pour créer un ensemble étendu de règles d'autorisation pour une file d'attente située, par exemple, à l'adresse https://tenant.servicebus.windows.net/my/test, vous pouvez créer une nouvelle définition de partie de confiance, en fournissant l'adresse de la file d'attente ou un préfixe de cette adresse en tant qu'URI de domaine de cette nouvelle définition soit via le portail ACS soit via l'API de gestion ACS. Sur le portail, les étapes sont les suivantes :

  • Dans Applications de partie de confiance, cliquez surAjouter.

  • Entrez un nom d'affichage, par exemple MyTest.

  • Entrez http://tenant.servicebus.windows.net/MyTest comme URI de domaine pour l'étendue.

  • Choisissez SWT comme format de jeton.

  • Définissez Stratégie de chiffrement sur Aucun.

  • Définissez Durée de vie des jetons sur 1 200 secondes.

  • Cliquez sur Enregistrer.

Le résultat est une définition de partie de confiance exclusive à cette adresse. Parce que son URI de domaine est un suffixe de la définition de partie de confiance de « ServiceBus » intégrée, la définition hérite automatiquement des clés de signature correctes pour que le Service Bus fasse confiance aux jetons émis qui sont basés sur cette nouvelle définition. Toutefois, comme il n'y a pas de règles associées à la nouvelle définition de partie de confiance jusqu'ici, personne ne sera en mesure d'accéder à la file d'attente, pas même le « propriétaire », parce qu'il n'y a pas d'héritage implicite automatique de règles entre les définitions de partie de confiance, même si elles forment une hiérarchie.

Après la création de la nouvelle définition, il y aura un « Groupe de règles par défaut pour <nom_d'affichage> » dans la section de groupes de règles du portail ACS. Ce nouveau groupe est vide par défaut. Afin de permettre l'accès à la file d'attente, des règles doivent être ajoutées au groupe, comme l'explique la section suivante. Autrement, un groupe de règles existant avec des règles peut être activé pour la définition de la partie de confiance. Chaque groupe de règles peut être être vu comme une liste de contrôle d'accès distincte pouvant être activée n'importe où dans la hiérarchie de la partie de confiance. Pour activer le système de fichiers comme un héritage, par exemple pour hériter des règles par défaut de la racine du espace de noms de service Service Bus, le groupe correspondant « Groupe de règles par défaut pour ServiceBus » et n'importe quel autre groupe de règles peuvent être simplement activés sur la définition de la partie de confiance, ce qui nécessite de cocher la case dans la section « Groupes de règles » de la définition de partie de confiance sur le portail. Dans les cas où un ensemble commun de règles d'accès devrait être appliqué à un nombre de ressources, par exemple des règles fréquentes pour un ensemble de ressources parallèles telles que des files d'attente jumelles à l'adresse http://tenant.servicebus.windows.net/my/test et http://tenant.servicebus.windows.net/my/zoo, la définition de partie de confiance peut aussi être étendue à la branche espace de noms de service partagée, telle que http://tenant.servicebus.windows.net/my.

Dans d'autres cas, des scénarios peuvent appeler pour gérer le contrôle d'accès différemment pour certains aspects de la même entité Service Bus, tels que différentes autorisations sur différents abonnements d'une rubrique. Dans ces cas, il est possible de créer une définition de partie de confiance étendue à un nom d'abonnement particulier, tel que http://tenant.servicebus.windows.net/my/test/subscriptions/sub1/, et faire en sorte que cette définition garde les règles s'appliquant uniquement à l'abonnement de ce nom particulier.

Définition des règles

Les règles sont définies dans des groupes de règles et mappent généralement une revendication d'entrée à une revendication de sortie. Toutes les règles d'un groupe offrent un seul résultat combiné. Ainsi, si trois règles correspondantes sont définies pour un ensemble de revendications d'entrée qui fournissent trois revendications de sortie distinctes, le jeton d'autorisation émis contiendra les trois revendications. Pour le Service Bus, les trois revendications d'autorisation sont « Envoyer » pour toutes les opérations d'envoi, « Écouter » pour ouvrir des écouteurs ou recevoir des messages, et « Gérer » pour observer ou gérer l'état du locataire de Service Bus. Pour être précis, « Envoyer », « Écouter » et « Gérer » sont les valeurs autorisées du type de revendication « net.windows.servicebus.action ». La création d'une règle pour le Service Bus nécessite de mapper une revendication d'entrée, telle que le nameidentifier d'une identité de service, à la revendication d'autorisation souhaitée. Pour accorder à l'identité de service « contoso » l'autorisation d'« Envoyer » vers une file d'attente, la définition de la règle mappera alors la revendication de l'identificateur de nom de l'émetteur ayant la valeur « contoso » à une revendication de sortie personnalisée de type « net.windows.servicebus.action » avec une valeur « Envoyer ». Accorder à l'identité de service les trois revendications d'autorisation nécessite trois règles distinctes. La possession de seulement trois revendications d'autorisations a pour objectif de limiter la complexité des règles de définition.

Utilisation des fournisseurs de jetons

Un fournisseur de jeton est un générique construit dans l'API géré par .NET pour le Service Bus qui autorise le changement de certaines formes d'informations d'identification en un jeton d'autorisation émis par le service ACS, qui peut être transmis à Service Bus pour exécuter l'opération souhaitée. TokenProvider est une classe de base abstraite avec trois implémentations concrète accessibles via des méthodes d'usine pour les scénarios les plus basiques :

  • Secret partagé – permet d'obtenir un jeton basé sur une identité de service (et la clé partagée associée avec cette identité) qui a été définie dans l'espace de noms « -sb » espace de noms de service Service Bus associé dans ACS. L'identité de service pré-configurée créée lorsque le espace de noms de service est créé est nommée « propriétaire » et son secret partagé est disponible via le portail de gestion.

  • Jeton Web simple (SWT) – permet l'obtention d'un jeton basé sur un jeton SWT précédemment acquis transmis à ACS via le fournisseur de jetons. Le jeton est transmis à ACS en tant que jeton binaire à l'aide d'une requête WS-Trust/WS-Federation RST/RSTR. Rapportez-vous à la documentation ACS pour plus d'informations sur la configuration des fournisseurs WS-Federation.

  • SAML – permet l'obtention d'un jeton basé sur un jeton SAML précédemment acquis transmis à ACS via le fournisseur de jetons. Le jeton est transmis à ACS à l'aide d'une requête WS-Trust/WS-Federation RST/RSTR. Rapportez-vous à la documentation ACS pour plus d'informations sur la configuration des fournisseurs WS-Federation.

Les API Service Bus MessagingFactory, NamespaceManager et TransportClientEndpointBehavior acceptent les instances TokenProvider. Le fournisseur de jeton est appelé lorsque des jetons sont requis, ce qui inclut des scénarios où une connexion de longue durée nécessite l'obtention d'un nouveau jeton une fois que le jeton existant a dépassé son délai d'expiration (qui est, par défaut, 1200 secondes). Les scénarios de fédération qui nécessitent l'interaction de l'utilisateur nécessitent l'implémentation d'un fournisseur de jetons personnalisé.

Par exemple, un fournisseur de jeton personnalisé pour permettre à un utilisateur Facebook particulier d'envoyer des messages à une file d'attente particulière devra présenter l'utilisateur, via ACS, avec l'interface utilisateur Facebook appropriée pour établir l'identité Facebook, rediriger via ACS pour échanger le jeton Facebook avec un jeton ACS pour le Service Bus, puis extraire le jeton ACS lorsque la requête est redirigée vers l'application locale. Le site Codeplex Service Bus contiendra une collection croissante d'exemples de fournisseurs de jetons pour personnalisation.

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

Afficher:
© 2015 Microsoft