Notes de publication

Mise à jour : 19 juin 2015

S’applique à : Azure

Cette rubrique décrit les nouvelles fonctionnalités de chaque version de Microsoft Azure Active Directory Access Control (également appelée Access Control Service ou ACS), explique comment chaque version du produit diffère de ses prédécesseurs et met en évidence les modifications cassants susceptibles d’affecter le code écrit pour une version antérieure.

• Mars 2015 : Migration des espaces de noms ACS vers Google OpenID Connect

• Juin 2014 – Prise en charge du fournisseur d'identité Google

• Notes de publication de la mise à jour de juillet 2013

• Notes de mise à jour de décembre 2012

• Notes de la mise à jour de septembre 2012

• Notes de la mise à jour de juin 2012

• Notes de la mise à jour de mai 2012

• Notes de la mise à jour de janvier 2012

• Notes de la mise à jour de juillet 2011

Mars 2015 : Migration des espaces de noms ACS vers Google OpenID Connect

ACS a implémenté une fonctionnalité pour aider les propriétaires d'espaces de noms ACS à migrer leurs configurations de fournisseur d'identité Google d'OpenID 2.0 vers OpenID Connect. Les clients ont jusqu'au 1er juin 2015 pour migrer leurs espaces de noms ACS vers OpenID Connect et jusqu'au 1er janvier 2017 pour migrer leur code principal afin d'utiliser des identificateurs OpenID Connect. Le fait de ne pas effectuer l'action appropriée avant chaque échéance provoquera l'interruption de vos applications. Pour obtenir des instructions détaillées, consultez Migration d’espaces de noms ACS vers Google OpenID Connecter.

Juin 2014 – Prise en charge du fournisseur d'identité Google

Au 19 mai 2014, les nouveaux espaces de noms ACS ne peuvent pas utiliser Google comme fournisseur d'identité. Les espaces de noms ACS qui utilisaient déjà Google et qui étaient enregistrés avant le 19 mai 2014 ne sont pas affectés. Cette nouvelle limitation existe car Google supprime progressivement la prise en charge d'OpenID 2.0, dont dépend ACS, et a fermé les inscriptions pour les nouvelles applications. Les espaces de noms ACS existants qui utilisaient Google continueront à fonctionner jusqu'au 20 avril 2015. Si votre application nécessite la prise en charge des comptes Google, nous vous recommandons d'inscrire votre application directement auprès de Google.

Si un utilisateur essaie de se connecter à un nouvel espace de noms ACS à l'aide de son compte Google, il est redirigé vers une page d'erreur HTTP 400.

Notes de publication de la mise à jour de juillet 2013

Pour accroître la disponibilité et les performances d'ACS pour tous les utilisateurs, ACS a implémenté une limite de 30 demandes de jetons par seconde pour chaque espace de noms. Si un espace de noms dépasse cette limite pendant une période prolongée, ACS rejette les demandes de jetons en provenance de l'espace de noms pendant toute la durée de l'intervalle et renvoie une erreur HTTP 429 / ACS90055 « Trop de demandes ». Pour plus d’informations, consultez Limitations du service ACS et Codes d’erreur ACS.

Notes de mise à jour de décembre 2012

Nouvelles fonctionnalités

La mise à jour de décembre 2012 d’ACS inclut les nouvelles fonctionnalités suivantes :

Prise en charge de la déconnexion unique fédérée à l'aide du protocole WS-Federation

Les applications web qui utilisent ACS pour activer l’authentification unique (SSO) avec des fournisseurs d’identité à l’aide du protocole WS-Federation peuvent désormais tirer parti des fonctionnalités de déconnexion unique. Lorsqu’un utilisateur se déconnecte d’une application web, ACS peut automatiquement déconnecter l’utilisateur du fournisseur d’identité et des autres applications de partie de confiance qui utilisent le même fournisseur d’identité.

Cette fonctionnalité est activée pour les fournisseurs d’identité WS-Federation, notamment Services ADFS 2.0 et Windows ID en direct (compte Microsoft). Pour activer la déconnexion unique, ACS effectue les tâches suivantes pour les points de terminaison de protocole WS-Federation :

• ACS reconnaît les messages wsignoutcleanup1.0 des fournisseurs d’identité et répond en envoyant des messages wsignoutcleanup1.0 aux applications de partie de confiance.

• ACS reconnaît wsignout1.0 et génère des messages de partie de confiance et répond en envoyant des messages wsignout1.0 aux fournisseurs d’identité et aux messages wsignoutcleanup1.0 aux applications de partie de confiance.

Pour plus d’informations, consultez l’exemple de code : ASP.NET MVC 4 avec l’authentification fédérée et l’authentification passive pour ASP.NET dans WIF.

Fin de la prise en charge d'ACS 1.0

La prise en charge d'Access Control Service 1.0 n'est plus assurée dans cette version, y compris la prise en charge de la migration d'Access Control Service 1.0 vers Access Control Service 2.0.

Navigation dans Access Control espaces de noms dans le nouveau portail de gestion Azure

Le nouveau portail de gestion Azure (https://manage.WindowsAzure.com) inclut un itinéraire vers le portail de gestion ACS familier où vous créez et gérez des espaces de noms Access Control.

Pour accéder au portail de gestion ACS

1. Accédez au portail de gestion Microsoft Azure (https://manage.WindowsAzure.com), connectez-vous, puis cliquez sur Active Directory. (Conseil de résolution des problèmes : l’élément « Active Directory » est manquant ou non disponible)

2. Cliquez sur un espace de noms Access Control, puis sur Gérer.

Pour créer un espace de noms Access Control, cliquez sur Nouveau, Services d'application, Access Control, puis cliquez sur Création rapide. (Ou cliquez sur Espaces de noms Access Control avant de cliquer sur Nouveau.)

Pour obtenir de l'aide sur les tâches de gestion d'ACS dans le portail de gestion Microsoft Azure, cliquez sur Active Directory, puis cliquez sur Aide (?). (Ou cliquez sur Active Directory, cliquez sur Espaces de noms Access Control, puis cliquez sur Aide.)

Navigation dans l’espace de noms Access Control pour un service bus

Lorsque vous créez un espace de noms Service Bus dans le portail, le portail crée automatiquement un espace de noms Access Control pour service bus.

Pour configurer et gérer l’espace de noms Access Control pour un service bus :

1. Connectez-vous au Portail de gestion Azure.

2. Cliquez sur Service Bus, puis sélectionnez un bus des services.

3. Cliquez sur Clé d'accès, puis sur Ouvrir le portail de gestion ACS.

Pour vérifier que l’espace de noms Access Control est associé au service bus, consultez le champ Espace de noms de service en haut de la page Access Control service. Le nom de l'espace de noms est constitué du nom du bus des services et d'un suffixe « -sb ».

Pour plus d’informations, consultez Guide pratique pour gérer l’espace de noms Access Control pour un Service Bus.

Améliorations apportées au portail de gestion ACS pour l'affichage des clés de fournisseurs d'identité WS-Federation, avec masquage des mots de passe

Cette version contient deux améliorations liées à l'affichage et à l'utilisation des certificats, des clés et des mots de passe dans le portail de gestion ACS 2.0 :

• Les certificats de signatures sont désormais visibles dans la section Modifier le fournisseur d'identité WS-Federation : auparavant, les certificats importés à partir de métadonnées WS-Federation utilisées pour valider la signature des jetons émis par ce fournisseur d'identité n'étaient pas visibles dans le portail de gestion ACS. La section Modifier le fournisseur d'identité WS-Federation affiche maintenant des informations sur les certificats importés, notamment leur état et leur date d'expiration. Ces certificats peuvent maintenant être actualisés à l'aide de la case à cocher « Réimporter les données à partir de l'URL de métadonnées WS-Federation lors de l'enregistrement ».

• Les mots de passe et les clés de signature symétriques sont désormais masqués par défaut : pour empêcher toute divulgation accidentelle des mots de passe et des clés symétriques, ces valeurs sont maintenant masquées par défaut dans les écrans Modifier dans tout le portail. Pour afficher la valeur d'un mot de passe ou d'une clé symétrique (par exemple, pour pouvoir la copier dans une application), vous devez appuyer sur un bouton « Afficher le mot de passe » ou « Afficher la clé ».

Possibilité de fédérer des locataires d’annuaire avec des espaces de noms Access Control

Azure Active Directory locataires peuvent désormais être utilisés en tant que fournisseurs d’identité dans Access Control espaces de noms. Cela vous permet, par exemple, d'autoriser votre application web à accepter des identités d'entreprise provenant de clients d'annuaire et des identités de consommateur provenant de fournisseurs sociaux tels que Facebook, Google, Yahoo!, des comptes Microsoft ou tout autre fournisseur OpenID. Vous trouverez des instructions détaillées sur l’implémentation du scénario dans ce billet, l’approvisionnement d’un locataire Azure Active Directory en tant que fournisseur d’identité dans un espace de noms ACS.

Prise en charge du protocole SAML 2.0 pour les applications de partie de confiance (Developer Preview)

ACS prend désormais en charge le protocole SAML 2.0 pour l'émission de jetons à des applications de partie de confiance. La prise en charge du protocole SAML 2.0 a été publiée en tant que version préliminaire destinée aux développeurs, ce qui signifie que les détails de son implémentation sont encore sujets à modification. Pour plus d’informations, consultezDeveloper Preview : SAMLProtocol.

Problèmes connus

Dans la mise à jour Microsoft Azure Active Directory Access Control (également appelée service Access Control ou ACS) en décembre 2012, les problèmes connus suivants ont été identifiés :

Azure Co-Administrators peut désormais gérer les espaces de noms Access Control. Toutefois, une action est nécessaire pour propager les coadministrateurs préexistants à des espaces de noms Access Control existants.

Avant la mise à jour de novembre 2012, nous avons résolu un problème où, par défaut, seul l’administrateur de service Azure principal pouvait gérer Access Control espaces de noms créés dans l’abonnement. Si un coadministrateur Azure a tenté d’accéder au portail de gestion ACS pour un espace de noms Access Control, il reçoit l’un des codes d’erreur ACS suivants :

• ACS50000 : Une erreur a été générée lors de l’émission d’un jeton.

• ACS60000 : une erreur s’est produite lors du traitement des règles de traitement de la partie de confiance à l’aide de l’émetteur « uri:WindowsLiveID »

• ACS60001 : aucune revendication de sortie n’a été générée pendant le traitement des règles.

Ce problème est désormais résolu pour les nouveaux espaces de noms Access Control créés par n’importe quel administrateur de service Azure ou coadministrateur. Toutefois, les clients ayant des espaces de noms qui existaient avant le correctif doivent appliquer la solution de contournement suivante pour que les données des coadministrateurs soient propagées à ces espaces de noms :

1. Connectez-vous au Portail Azure (https://windows.azure.com/) à l’aide des informations d’identification de l’administrateur de service ou de l’administrateur de compte.

2. Supprimez et réinscrivez le coadministrateur à l’aide des instructions de la procédure d’ajout et de suppression d'Co-Administrators pour vos abonnements Azure (https://msdn.microsoft.com/library/windowsazure/gg456328.aspx)

3. Déconnectez-vous, puis connectez-vous au portail Azure à l'aide des informations d'identification du coadministrateur. Vous pourrez ensuite gérer les espaces de noms Access Control.

Notes de la mise à jour de septembre 2012

En septembre 2012, Microsoft Azure Active Directory Access Control (également appelé service Access Control ou ACS) a reçu une mise à jour qui contenait les modifications suivantes :

L'entityID publié dans les métadonnées WS-Federation émises par ACS est désormais toujours en minuscules

L’attribut « entityID » dans les métadonnées WS-Federation publiées par Access Control espaces de noms est désormais toujours en minuscules. Dans les versions précédentes, il utilisait la casse entrée lors de la création de l'espace de noms dans le portail Azure. L’attribut « entityID » identifie l’espace de noms Access Control aux applications de partie de confiance, et ci-dessous est un exemple de l’attribut :

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://lowercase-namespace.accesscontrol.windows.net/" ID="_e4a0006c-c23c-41c0-8f87-baa110afaf1d">

Cette modification a été nécessaire pour résoudre les problèmes de validation de jeton potentiels dans lesquels la lettre de l’espace de noms Access Control dans le jeton acS -émis (qui est toujours en minuscule) ne correspond pas à la lettre de l’espace de noms Access Control importé par la partie de confiance. Les parties de confiance qui utilisent Windows Identity Foundation ne sont pas concernées par les problèmes de respect de la casse.

Les certificats X.509 téléchargés vers ACS ont désormais une restriction de taille de clé publique de 4096 bits

Tous les certificats X.509 chargés dans un espace de noms Access Control via le portail de gestion ACS ou le service de gestion sont maintenant nécessaires pour avoir une taille de clé publique supérieure à 4096 bits. Cela comprend les certificats utilisés pour la signature de jetons, le chiffrement de jetons et le déchiffrement de jetons.

Dans Windows, vous pouvez vérifier la taille de clé publique d'un certificat en ouvrant le fichier de certificat (.CER), en sélectionnant l'onglet « Détails » et en vérifiant la valeur du champ « Clé publique ». Les certificats qui utilisent l'algorithme de signature sha256RSA sécurisé ont une clé publique de 2048 bits.

Tous les certificats existants ayant une taille de clé supérieure à 4096 bits continueront à fonctionner avec ACS, mais il ne pourront pas être réenregistrés dans ACS tant qu'ils n'auront pas été remplacés par un certificat conforme.

Modification mineure de l'algorithme de sélection de « clé primaire » utilisé quand ACS signe un jeton à l'aide d'un certificat X.509

Dans le service de gestion et le portail de gestion ACS figure un champ « Rendre primaire » pour les certificats de signature de jetons qui, quand vous le sélectionnez, oblige ACS à signer les jetons avec ce certificat. Avec cette version, si aucun certificat de signature de jeton configuré n’a vérifié le champ « Make Primary », l’espace de noms Access Control utilisera le certificat de signature de jeton non principal existant qui a la date de début valide la plus ancienne pour signer le jeton. ACS ne signe pas les jetons avec un certificat de signature de jetons non primaire s'il existe un certificat primaire qui n'est pas valide ou qui a expiré.

JWT Bêta : modification du comportement de signature lors de l'utilisation d'une clé ou d'un certificat d'espace de noms global pour signer un jeton JWT

Lors de la publication de la prise en charge bêta du format JWT (JSON Web Token) en juin 2012, ACS utilisait l'ordre de priorité suivant pour déterminer la clé à utiliser pour signer chaque jeton JWT délivré à chaque application de partie de confiance :

• Clé de signature symétrique attribuée à la partie prenante, si elle est disponible

• Certificat de signature X.509 attribué à la partie prenante, s'il est disponible

• Clé de signature symétrique affectée à l’espace de noms Access Control

• Certificat de signature X.509 affecté à l’espace de noms Access Control

À compter de cette version, les clés symétriques à l'échelle de l'espace de noms ne sont plus prises en charge pour la signature des jetons JWT. Voici le nouvel ordre de priorité pour la signature des jetons JWT :

• Clé de signature symétrique attribuée à la partie prenante, si elle est disponible

• Certificat de signature X.509 attribué à la partie prenante, s'il est disponible

• Certificat de signature X.509 affecté à l’espace de noms Access Control

Notes de la mise à jour de juin 2012

En juin 2012, ACS a reçu une mise à jour qui contenait la nouvelle fonctionnalité suivante :

Format JWT désormais disponible pour les applications de partie de confiance (Bêta)

Cette mise à jour introduit la prise en charge du format BÊTA JSON Web Token (JWT) dans ACS. JWT est un format de jeton codé JSON léger qui peut être signé à l’aide d’un certificat X.509 ou d’une clé symétrique, et peut être émis par ACS pour les applications de partie de confiance sur l’un des protocoles suivants :

• OAuth 2.0

• Un certificat de fournisseur d'identité WS-Federation

• WS-Trust

Le format de jeton JWT est désormais une option sélectionnable dans la section Applications de partie de confiance du portail de gestion ACS et est également configurable via le service de gestion ACS.

Pour en savoir plus sur le format de jeton JWT, consultez la spécification du jeton web JSON. Des exemples de code ACS avec des jetons JWT seront publiés ultérieurement.

Notes de la mise à jour de mai 2012

Au début du mois de mai 2012, ACS a reçu une mise à jour qui contenait le changement suivant :

Modification des propriétés d'ID d'entités exposées via le service de gestion

Le service de gestion ACS expose actuellement une propriété d’ID pour chacun des types d’entités qu’il prend en charge, comme décrit dans la référence de l’API du service de gestion ACS. Ces propriétés d’ID sont automatiquement définies et gérées par ACS.

Dans cette mise à jour de service, ACS est migré vers un schéma de base de données différent et, par conséquent, ces ID exposés via le service de gestion changeront pour tous les types d’entités.

Il est rare et généralement déconseillé que les applications stockent ou aient une dépendance codée en dur envers ces ID pour interroger des entités spécifiques via le service de gestion. Au lieu de cela, nous vous recommandons d'interroger les types d'entités RelyingParty, ServiceIdentity, RuleGroup et Issuer à l'aide de la propriété Name et d'interroger les autres types d'entités à l'aide d'un ID d'entité parente (par exemple RuleGroupId dans le cas de règles ou IssuerId dans le cas de fournisseurs d'identité).

Modification du classement de base de données pour le traitement des règles

Afin d’étendre la prise en charge des langues internationales et d’améliorer la sécurité, cette version d’ACS met à jour le classement de base de données SQL sous-jacent utilisé pour comparer les revendications d’entrée de SQL_Latin1_General_CP1_CI_AS à Latin1_General_100_BIN2. Cette modification permet à ACS de prendre en charge des jeux de caractères et des combinaisons de jeux de caractères supplémentaires. Les applications qui reposent sur des revendications d'entrée contenant des chaînes avec plusieurs jeux de caractères non pris en charge par SQL_Latin1_General_CP1_CI_AS peuvent observer des revendications différentes ou supplémentaires suite à ce nouveau classement. Nous encourageons les clients souhaitant tirer parti de cette nouvelle fonctionnalité à valider leurs applications quant à la compatibilité avec le nouveau classement SQL.

Notes de la mise à jour de janvier 2012

Le 25 janvier 2012, ACS 2.0 a reçu une mise à jour qui contenait les modifications suivantes :

• Modification des réponses d'erreur ACS pour les échecs de demande d'authentification

• Modification des réponses d'erreur OAuth 2.0 pour les échecs de demande d'authentification

Modification des réponses d'erreur ACS pour les échecs de demande d'authentification

Dans la version précédente, ACS a répondu avec différents codes d’erreur lorsqu’un client s’est authentifié auprès d’un émetteur non existant (code d’erreur : ACS50026) ou d’informations d’identification incorrectes (code d’erreur : ACS50006). Ces codes d'erreur étaient précédemment émis quand un client essayait de s'authentifier avec un nom d'identité de service non valide ou à l'aide d'un jeton SWT ou SAML émis par un fournisseur d'identité non valide.

ACS retourne les codes d’erreur ACS50008, ACS50009 ou ACS50012 pour une authentification ayant échoué dans les cas de SWT, SAML et nom d’utilisateur/mot de passe, respectivement. Reportez-vous au tableau ci-dessous pour plus d'informations :

Réponse d'authentification	Avant	Après
Émetteur inexistant	ACS50026 IssuerNotFound	ACS50008 InvalidSwt, ACS50009 InvalidSaml, OR ACS50012 AuthenticationFailed
Informations d'identification incorrectes	ACS50006 InvalidSignature

Modification des réponses d'erreur OAuth 2.0 pour les échecs de demande d'authentification

En outre dans la version précédente, ACS a répondu avec différents codes d’erreur OAuth 2.0 lorsqu’un client s’est authentifié auprès d’un émetteur non existant (invalid_client) ou d’informations d’identification incorrectes (invalid_grant). Ce comportement a également été mis à jour et ACS retourne invalid_request lorsque la requête OAuth 2.0 est mal formée, invalid_client si le client échoue à l’authentification ou si l’assertion fournie pour l’authentification est incorrecte ou non valide, et invalid_grant si le code d’autorisation est mal formé ou non valide. Reportez-vous au tableau ci-dessous pour plus d'informations :

Réponse d'authentification	Exemples	Avant	Après
Émetteur inexistant		invalid_client	invalid_client
Informations d'identification incorrectes	SWT est signé avec une clé incorrecte. L’ID client et les informations d’identification correspondent à celles configurées dans ACS.	invalid_grant
Échec de l’authentification	Échec de la validation de l'URI d'audience. Échec de la validation du certificat. L'assertion d'une identité de service contient des revendications auto-émises.	invalid_grant
Assertion mal formée	La signature est manquante dans SWT. L'assertion SAML n'est pas du code XML valide.	invalid_request
Code d'autorisation mal formé		invalid_grant	invalid_grant
Code d'autorisation non valide		invalid_grant
Demande OAuth2 mal formée		invalid_request	invalid_request

Notes de la mise à jour de juillet 2011

Les notes de publication de la mise à jour de juillet 2011 d’ACS 2.0 contiennent les éléments suivants :

• Prérequis

• Nouvelles fonctionnalités

• Modifications

• Problèmes connus

• Problèmes connus

Prérequis

Tous les espaces de noms Access Control reçoivent automatiquement la mise à jour de juillet 2011. Cette mise à jour ne contient aucune modification des prérequis ACS pour les clients nouveaux ou existants. Pour plus d’informations sur les prérequis ACS actuels, consultez Conditions préalables acs.

Nouvelles fonctionnalités

La mise à jour de juillet 2011 vers ACS contient les nouvelles fonctionnalités suivantes :

1. Les règles prennent désormais en charge jusqu'à deux revendications d'entrée

Le moteur de règles ACS prend désormais en charge un nouveau type de règle qui permet de configurer jusqu’à deux revendications d’entrée, au lieu d’une seule revendication d’entrée. Vous pouvez utiliser des règles avec deux revendications d'entrée pour réduire le nombre global de règles nécessaires pour effectuer des fonctions d'autorisation utilisateur complexes.

Dans le portail de gestion ACS, une deuxième revendication d’entrée peut être spécifiée dans une nouvelle règle en cliquant sur Ajouter une deuxième revendication d’entrée dans l’éditeur de règles. Dans le service de gestion, vous pouvez configurer des règles avec deux revendications d'entrée à l'aide du type d'entité ConditionalRule. Vous pouvez toujours configurer des règles avec une seule revendication d'entrée à l'aide du type d'entité Règle à des fins de compatibilité descendante.

Pour plus d’informations sur les règles avec deux revendications d’entrée, consultez Groupes de règles et Règles.

2. Localisation dans 11 langues

Le portail de gestion ACS et la page de connexion hébergée par ACS pour les applications de partie de confiance prennent désormais en charge la localisation dans onze langues écrites, y compris l’anglais, l’Français, l’allemand, l’italien, le japonais, le coréen, le russe, l’espagnol, le portugais (Brésil), le chinois simplifié et le chinois traditionnel. Une option « Anglais (International) » est également disponible ; elle utilise un autre format de date pour la définition et l'affichage des dates d'entrée en vigueur/d'expiration pour les clés. La langue affichée pour ces interfaces utilisateur peut être modifiée de trois façons :

• Sélecteur de langue : dans le portail de gestion ACS, la langue affichée peut être modifiée instantanément à l’aide d’un nouveau menu de sélecteur de langue qui s’affiche dans le coin supérieur droit du portail.

• URL : la langue affichée dans le portail de gestion ACS peut être modifiée en ajoutant un paramètre « lang » à la fin de l’URL de la requête. Les valeurs correctes pour ce paramètre sont les codes de langue ISO 639-1/3166 qui correspondent à une langue prise en charge. Exemples de valeur : en, de, es, fr, it, ja, ko, ru, pt-br, zh-cn, et zh-tw. Voici un exemple d’URL du portail de gestion ACS avec un paramètre définissant la langue affichée sur Français :

  https://your-namespace.accesscontrol.windows.net/?lang=fr

• Préférences du navigateur web : si le paramètre d’URL « lang » ou le sélecteur de langue n’a jamais été utilisé pour définir une préférence de langue, les pages de connexion hébergées par ACS et ACS déterminent la langue par défaut à afficher en fonction des préférences linguistiques définies dans les paramètres du navigateur web.

Modifications

Voici une liste des principales modifications de comportement de service dans cette version :

1. L'encodage est désormais UTF-8 pour toutes les réponses OAuth 2.0

Dans la version initiale d’ACS, le jeu d’encodage de caractères pour toutes les réponses HTTP du point de terminaison OAuth 2.0 était US-ASCII. Dans la mise à jour de juillet 2011, l'encodage de caractères de toutes les réponses HTTP est maintenant défini sur UTF-8 pour prendre en charge les jeux de caractères étendus.

Problèmes connus

Le problème suivant est connu dans cette version :

L'éditeur de règles ne peut pas afficher les émetteurs personnalisés qui ne sont pas associés à des fournisseurs d'identité

Actuellement, l’éditeur de règles dans le portail de gestion ACS ne peut afficher que les émetteurs de revendication associés à un fournisseur d’identité ou ACS. Si une règle chargée fait référence à un émetteur qui ne correspond pas à l'un de ces critères, l'erreur suivante est affichée :

• ACS80001 : Cette règle est configurée pour utiliser un type d’émetteur de revendication qui n’est pas pris en charge par le portail de gestion. Utilisez le service de gestion pour afficher et modifier cette règle.

Il existe deux scénarios pris en charge dans lesquels un émetteur peut exister sans fournisseur d’identité associé dans ACS :

• Dans un scénario de délégation OAuth 2.0, un enregistrement émetteur est créé dans l’espace de noms Access Control à l’aide du service de gestion ACS, et cet émetteur n’a pas de fournisseur d’identité associé.

• Lorsqu’un émetteur est créé à des fins d’assertion de revendications dans une demande de jeton sur le protocole OAuth WRAP, tout en utilisant une identité de service nommée identiquement pour s’authentifier auprès d’ACS.

Quotas

À compter de cette version, ACS n’impose pas de limites au nombre de fournisseurs d’identité, d’applications de partie de confiance, de groupes de règles, de règles, d’identités de service, de types de revendications, d’enregistrements de délégation, d’émetteurs, de clés et d’adresses qui peuvent être créés pour un espace de noms de Access Control donné.

Limitations de service

Pour plus d’informations sur les limitations de service, consultez Limitations du service ACS.