Authentification et autorisation pour l’API Azure Time Series Insights

Selon vos besoins métier, votre solution peut inclure une ou plusieurs applications clientes que vous utilisez pour interagir avec les API de votre environnement Azure Time Series Insights. Azure Time Series Insights effectue l’authentification à l’aide de Jetons de sécurité Microsoft Entra basés sur OAUTH 2.0. Pour authentifier votre ou vos clients, vous devez obtenir un jeton du porteur avec les autorisations appropriées et le transmettre avec vos appels d’API. Ce document décrit plusieurs méthodes pour obtenir des informations d'identification que vous pouvez utiliser pour obtenir un jeton d’accès et vous authentifier, notamment à l'aide de l'identité gérée et de l’enregistrement d'application Microsoft Entra.

Identités managées

Les sections suivantes décrivent comment utiliser une identité managée à partir de Microsoft Entra ID pour accéder à l’API Azure Time Series Insights. Sur Azure, les identités managées éliminent la nécessité pour les développeurs de gérer les informations d’identification en fournissant une identité pour la ressource Azure dans Microsoft Entra ID et en l’utilisant pour obtenir des jetons Microsoft Entra. Voici quelques-uns des avantages de l’utilisation d’identités managées :

• Vous n’avez pas besoin de gérer les informations d’identification. Les identifiants ne vous sont même pas accessibles.
• Vous pouvez utiliser des identités managées pour vous authentifier auprès de n’importe quel service Azure prenant en charge l’authentification Microsoft Entra, y compris Azure Key Vault.
• Les identités managées peuvent être utilisées sans coût supplémentaire.

Pour plus d’informations sur les deux types d’identités managées, lisez Qu’est-ce que les identités managées pour les ressources Azure ?

Vous pouvez utiliser des identités managées à partir de vos :

• Machines virtuelles Azure
• Azure App Services
• Azure Functions
• Instances de conteneur Azure
• et bien plus ...

Consultez services Azure qui prennent en charge les identités managées pour les ressources Azure pour obtenir la liste complète.

Inscription de l’application Microsoft Entra

Nous vous recommandons d’utiliser des identités managées dans la mesure du possible afin que vous n’ayez pas besoin de gérer les informations d’identification. Si votre application cliente n’est pas hébergée sur un service Azure qui prend en charge les identités managées, vous pouvez inscrire votre application auprès d’un locataire Microsoft Entra. Lorsque vous inscrivez votre application avec l’ID Microsoft Entra, vous créez une configuration d’identité pour votre application qui lui permet de s’intégrer à l’ID Microsoft Entra. Lorsque vous inscrivez une application dans le portail Azure , vous choisissez s’il s’agit d’un seul locataire (accessible uniquement dans votre locataire) ou multilocataire (accessible dans d’autres locataires) et pouvez éventuellement définir un URI de redirection (où le jeton d’accès est envoyé).

Lorsque vous avez terminé l’inscription de l’application, vous disposez d’une instance unique au niveau mondial de l’application (l’objet d’application) qui se trouve dans votre client ou répertoire domestique. Vous disposez également d’un ID global unique pour votre application (l’application ou l’ID client). Dans le portail, vous pouvez ensuite ajouter des secrets ou des certificats et des autorisations pour que votre application fonctionne, personnaliser l'apparence de votre application dans la boîte de dialogue de connexion, etc.

Si vous inscrivez une application dans le portail, un objet d’application ainsi qu’un objet principal de service sont automatiquement créés dans votre locataire d’accueil. Si vous inscrivez/créez une application à l’aide des API Microsoft Graph, la création de l’objet principal de service est une étape distincte. Un objet principal de service est requis pour demander des jetons.

Veillez à consulter la liste de contrôle de sécurité pour votre application. Comme meilleure pratique, vous devez utiliser informations d'identification de certificat, et non des mots de passe (secrets client).

Pour plus d’informations, consultez objets application et principal de service dans Microsoft Entra ID.

Étape 1 : Créer votre identité managée ou votre inscription d’application

Une fois que vous avez identifié si vous utiliserez une identité managée ou une inscription d’application, l’étape suivante consiste à en provisionner une.

Identité managée

Les étapes que vous allez utiliser pour créer une identité managée varient selon l’emplacement de votre code et si vous créez ou non une identité affectée par le système ou l’utilisateur. Lisez types d’identité managée pour comprendre la différence. Une fois que vous avez sélectionné votre type d’identité, recherchez et suivez le tutoriel approprié dans la documentation Microsoft Entra Managed Identities . Vous trouverez des instructions pour configurer des identités managées pour :

• machines virtuelles Azure
• App Service et Azure Functions
• Instances de conteneurs Azure
• et bien plus ...

Inscription d’application

Suivez les étapes répertoriées dans Inscrire une application.

• Après avoir sélectionné la plateforme appropriée à l'étape 4 de Configurer les paramètres de plateforme, configurez vos URI de redirection et vos jetons d'accès dans le volet latéral à droite de l'interface utilisateur.

  • URI de redirection doivent correspondre à l’adresse fournie par la demande d’authentification :

    • Pour les applications hébergées dans un environnement de développement local, sélectionnez client public (mobile & bureau). Veillez à définir client public à Oui.
    • Pour les applications Single-Page hébergées sur Azure App Service, sélectionnez Web.

  • Déterminez si une URL de déconnexion convient.

  • Activez le flux d’octroi implicite en vérifiant jetons d’accès ou jetons d'identification.

  

  Cliquez sur Configurer, puis Enregistrer.

• Associez votre application Microsoft Entra Azure Time Series Insights. Sélectionnez autorisations d’API>Ajouter une autorisation>API que mon organisation utilise.

  

  Tapez Azure Time Series Insights dans la barre de recherche, puis sélectionnez Azure Time Series Insights.

• Ensuite, spécifiez l’autorisation d’API de type requise par votre application. Par défaut, autorisations déléguées seront mises en surbrillance. Choisissez un type d’autorisation, puis sélectionnez Ajouter des autorisations.

  

• Ajouter des informations d’identification si l’application appelle les API de votre environnement comme elle-même. Les informations d’identification permettent à votre application de s’authentifier comme elle-même, sans aucune interaction d’un utilisateur au moment de l’exécution.

Étape 2 : Accorder l’accès

Lorsque votre environnement Azure Time Series Insights reçoit une demande, le jeton de sécurité de l’appelant est d’abord validé. Si la validation réussit, l’appelant a été authentifié, puis une autre vérification est effectuée pour s’assurer que l’appelant est autorisé à effectuer l’action demandée. Pour autoriser un utilisateur ou un principal de service, vous devez d’abord leur accorder l’accès à l’environnement en leur attribuant le rôle Lecteur ou Contributeur.

• Pour accorder l’accès via l'interface utilisateur du portail Azure , suivez les instructions répertoriées dans l'article Accorder l’accès aux données à un environnement. Lorsque vous sélectionnez l’utilisateur, vous pouvez rechercher l’identité managée ou l’inscription de l’application par son nom ou par ID.

• Pour accorder l’accès à l’aide d’Azure CLI, exécutez la commande suivante. Consultez la documentation ici pour obtenir la liste complète des commandes disponibles pour gérer l’accès.

  az tsi access-policy create --name "ap1" --environment-name "env1" --description "some description" --principal-object-id "aGuid" --roles Reader Contributor --resource-group "rg1"
  

Étape 3 : Demande de jetons

Une fois que votre identité gérée ou votre inscription d’application a été provisionnée et affectée à un rôle, vous êtes prêt à commencer à l’utiliser pour demander des jetons porteurs OAuth 2.0. La méthode que vous utilisez pour obtenir un jeton varie en fonction de l’emplacement d’hébergement de votre code et de votre langue de choix. Lorsque vous spécifiez la ressource (également appelée « audience » du jeton), vous pouvez identifier Azure Time Series Insights par son URL ou son GUID :

• https://api.timeseries.azure.com/
• 120d688d-1518-4cf7-bd38-182f158850b6

• Si vous utilisez Postman votre AuthURL sera donc : https://login.microsoftonline.com/microsoft.onmicrosoft.com/oauth2/authorize?scope=https://api.timeseries.azure.com//.default
• https://api.timeseries.azure.com/ est valide, mais https://api.timeseries.azure.com n’est pas.

Identités managées

Lors de l’accès à partir d’Azure App Service ou Functions, suivez les consignes dans Obtenir des jetons pour les ressources Azure.

Pour les applications et fonctions .NET, le moyen le plus simple d’utiliser une identité managée consiste à utiliser la bibliothèque de client Azure Identity pour .NET. Cette bibliothèque cliente est populaire en raison de sa simplicité et de ses avantages en matière de sécurité. Les développeurs peuvent écrire du code une seule fois et permettre à la bibliothèque cliente de déterminer comment s’authentifier en fonction de l’environnement d’application , qu’il s’agisse d’une station de travail de développeur à l’aide d’un compte de développeur ou déployé dans Azure à l’aide d’une identité de service managée. Pour obtenir des conseils de migration de la bibliothèque AppAuthentication prédécesseure, lisez AppAuthentication vers Azure.Identity Migration Guidance.

Demandez un jeton pour Azure Time Series Insights à l’aide de C# et de la bibliothèque cliente Azure Identity pour .NET :

using Azure.Identity;
// ...
var credential = new DefaultAzureCredential();
var token = credential.GetToken(
new Azure.Core.TokenRequestContext(
    new[] { "https://api.timeseries.azure.com/" }));
var accessToken = token.Token;

Inscription d’application

• Utilisez la bibliothèque d’authentification Microsoft (MSAL) pour obtenir des jetons pour les enregistrements d’applications.

MSAL peut être utilisé dans de nombreux scénarios d’application, notamment, mais pas limité à :

• Applications à page unique (JavaScript)
• application web qui se connecte à un utilisateur et appelle une API web pour le compte de l’utilisateur
• API web appelant une autre API web en aval pour le compte de l’utilisateur connecté
• application de bureau appelant une API web pour le compte de l’utilisateur connecté
• application mobile appelant une API web pour le compte de l’utilisateur connecté de manière interactive.
• application démon Desktop/service appelant l’API web pour le compte de lui-même

Pour obtenir un exemple de code C# montrant comment acquérir un jeton en tant qu’inscription d’application et interroger des données à partir d’un environnement Gen2, affichez l’exemple d’application sur GitHub

En-têtes et paramètres courants

Cette section décrit les en-têtes et paramètres de requête HTTP courants utilisés pour effectuer des requêtes sur les API Azure Time Series Insights Gen1 et Gen2. Les exigences spécifiques à l’API sont abordées plus en détail dans la documentation de référence de l’API REST d’Azure Time Series Insights .

En-têtes HTTP

Les en-têtes de requête requis sont décrits ci-dessous.

Les en-têtes de requête facultatifs sont décrits ci-dessous.

Les en-têtes de réponse facultatifs mais recommandés sont décrits ci-dessous.

Paramètres HTTP

Les paramètres de chaîne de requête d’URL requis dépendent de la version de l’API.

Les paramètres de chaîne de requête d’URL facultatifs incluent la définition d’un délai d’expiration pour les temps d’exécution des requêtes HTTP.

Étapes suivantes

• Pour obtenir un exemple de code qui appelle l’API Azure Time Series Insights Gen1, lisez Interroger des données Gen1 à l’aide de C#.

• Pour obtenir un exemple de code appelant l'API Azure Time Series Insights Gen2, consultez les exemples expliquant comment interroger les données Gen2 à l'aide de C# sous .

• Pour obtenir des informations de référence sur l’API, lisez la documentation de référence de l’API de requête .