Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article fournit des instructions pas à pas pour les développeurs et les administrateurs afin de configurer l’authentification d’application sécurisée et l’accès à Microsoft Planetary Computer Pro. En appliquant l’ID Microsoft Entra et les identités managées, les applications peuvent s’authentifier en toute transparence sans gérer les informations d’identification, ce qui garantit une interaction sécurisée avec les ressources Planetary Computer Pro. Que votre application s’exécute sur Azure ou dans d’autres environnements, ce guide décrit les configurations nécessaires, notamment le contrôle d’accès en fonction du rôle (RBAC) et l’acquisition de jetons, pour activer l’accès sécurisé.
Remarque
Pour les applications qui utilisent Azure AD B2C ou Microsoft Entra External ID prenant en charge des fonctionnalités telles que les fournisseurs d’identité sociale, les applications doivent continuer à utiliser ces solutions d’identité pour proxy du trafic d’authentification, car Planetary Computer Pro ne prend pas en charge les alternatives à l’authentification Microsoft Entra ID.
Options et recommandations d’authentification
Le tableau suivant récapitule l’approche d’authentification recommandée en fonction de l’endroit où votre application s’exécute et de la façon dont elle accède aux ressources :
| Environnement d’hébergement d’applications | Type d’accès obligatoire | Type d’identité recommandé | Explanation |
|---|---|---|---|
| Exécution sur Azure (machine virtuelle, App Service, Functions, Container Apps, etc.) | App-Only (l’application agit de manière autonome) | Identité managée affectée par l’utilisateur (recommandée) | Sécurité et facilité de gestion : Élimine la nécessité de stocker et de gérer les informations d’identification (secrets ou certificats) dans le code ou la configuration. Azure gère automatiquement la rotation des informations d’identification. L’affectation par l’utilisateur est préférée pour le partage entre plusieurs ressources. |
| Exécution sur Azure (machine virtuelle, App Service, Functions, Container Apps, etc.) | Délégué (l’application agit pour le compte d’un utilisateur) | Identité managée affectée par l’utilisateur (recommandée) | Tire parti de l’intégration Azure : Combine les avantages de sécurité de Managed Identity pour l’application elle-même avec les flux d’authentification utilisateur standard. Simplifie la configuration de l’infrastructure dans Azure. |
| Exécution en dehors d’Azure (local, autre cloud, ordinateur développeur) | App-Only (l’application agit de manière autonome) | Principal de service | Standard pour les applications externes : Méthode établie pour les applications non-Azure à s’authentifier avec l’ID Microsoft Entra. Nécessite la gestion sécurisée des informations d’identification (secrets ou certificats). |
| Exécution en dehors d’Azure (local, autre cloud, ordinateur développeur) | Délégué (l’application agit pour le compte d’un utilisateur) | Principal de service | Standard pour les applications externes : Active les flux OAuth 2.0 standard pour la connexion utilisateur et le consentement des applications en dehors d’Azure, à l’aide de l’identité inscrite de l’application dans l’ID Entra. |
| Exécution en dehors d’Azure (alternative) | App-Only ou délégué | Identité managée | Apporte des avantages Azure : En hébergeant l’application dans un service de calcul Azure (comme une machine virtuelle ou une application conteneur), elle peut utiliser la sécurité et la facilité de gestion améliorées des identités managées, ce qui évite la gestion des informations d’identification, même si l’origine peut être considérée comme non-Azure. |
Conditions préalables
- Compte Azure avec un abonnement actif : créez gratuitement un compte.
- Ressource GeoCatalog existante.
Applications s’exécutant sur Azure
Pour les applications qui s’exécutent sur Azure, nous vous recommandons de créer un type d’identité Microsoft Entra appelée identité managée affectée par l’utilisateur pour accéder à la ressource GeoCatalog. Les applications peuvent utiliser les identités managées pour obtenir des jetons Microsoft Entra (voir la section Acquérir le jeton d’accès pour accéder à Microsoft Planetary Computer Pro sans avoir à gérer les informations d’identification. Pour plus d’informations sur les identités managées et le type à choisir, consultez Présentation des identités managées pour les ressources Azure. Pour créer des identités managées affectées par l’utilisateur pour votre application s’exécutant sur Azure, suivez comment utiliser des identités managées pour App Service et Azure Functions.
Applications qui ne s’exécutent pas sur Azure
Pour les applications qui ne s’exécutent pas sur Azure, telles que localement ou hébergées sur d’autres fournisseurs de cloud, nous vous recommandons d’inscrire l’application dans le Centre d’administration Microsoft Entra, y compris un URI de redirection pour recevoir des jetons de sécurité, pour établir une relation d’approbation entre votre application et la plateforme d’identités Microsoft. L’inscription de l’application dans Microsoft Entra crée automatiquement un principal de service pour l’application, que vous pouvez attribuer des rôles RBAC ultérieurement. Si votre application dispose d'un paramètre pour configurer l'authentification Microsoft Entra ID, vous pouvez utiliser l'ID d'application (client) et l'ID de répertoire (locataire) de l'application enregistrée à cette fin.
Si vous ne pouvez pas inscrire l’application dans Microsoft Entra comme recommandé précédemment, vous avez une autre option d’exécution de l’application dans une machine virtuelle Azure ou une application conteneur. Vous pouvez créer une identité managée affectée par l’utilisateur et l’affecter à l’application de machine virtuelle ou de conteneur, comme décrit ici : configurer des identités managées sur des machines virtuelles Azure et des identités managées dans Azure Container Apps. L’application peut se connecter avec l’identité managée pour accéder à la ressource GeoCatalog. Par exemple, pour que l’application s’exécute à l’intérieur d’une machine virtuelle à l’aide d’une identité managée affectée par l’utilisateur, vous pouvez utiliser :
!az login --identity --username <client_id|object_id|resource_id>
Vous trouverez l’ID client, l’ID d’objet ou l’ID de ressource de l’identité managée à partir du portail Azure. En guise d’alternative à l’interface CLI, l’exemple de code Python se trouve sous la section Acquérir le jeton d’accès pour accéder à Microsoft Planetary Computer Pro.
azure.identity.DefaultAzureCredential(managed_identity_client_id=<client_id>)
Après avoir créé une identité managée affectée par l’utilisateur ou un principal de service pour votre application comme décrit précédemment, vous devez décider du type de scénario d’accès à l’application : accès à l’application uniquement, agissant uniquement en tant qu’identité ou accès délégué de l’application, agissant au nom d’un utilisateur connecté.
Accès uniquement par application
Dans ce scénario d’accès, l’application agit seul sans utilisateur connecté comme comportement par défaut. Vous pouvez passer à la section Configuration RBAC de Microsoft Planetary Computer Pro pour applications pour attribuer les rôles appropriés à l'application.
Accès délégué
Dans ce scénario d’accès, un utilisateur s’est connecté à une application cliente. L’application cliente accède à la ressource pour le compte de l’utilisateur. Vous devez vous assurer que les utilisateurs de l’application reçoivent des rôles RBAC appropriés, comme décrit dans la section Créer et gérer des utilisateurs. Vous devez également configurer les autorisations d’API de l’application avec des autorisations déléguées en procédant comme suit :
- Connectez-vous au Centre d’administration Microsoft Entra
- Accédez à Identité>Applications>Inscriptions d'applications, puis sélectionnez votre application cliente
- Sous Gérer, sélectionnez autorisations d’API
- Sélectionner Ajouter une autorisation
- Sélectionnez l'onglet API que mon organisation utilise
- Tapez Azure Orbital Planetary Computer dans le champ de recherche
- Sélectionnez l’entrée correspondante (l’ID d’application doit être 6388acc4-795e-43a9-a320-33075c1eb83b). Il s’affiche sous la forme d’Azure Orbital Microsoft Planetary Computer Pro.
- Sélectionnez la zone Autorisations déléguées . Cochez la case en regard de user_impersonation.
- Sélectionner Ajouter des autorisations
- Sélectionnez le lien « Accorder le consentement administrateur » (en supposant que votre intention est d'accorder le consentement administrateur dans le domaine pour cette permission)
Le modèle d’authentification déléguée est également utilisé lors de la connexion à partir de QGIS.
Configuration RBAC de Microsoft Planetary Computer Pro pour les applications
Une fois que vous avez créé une identité managée pour une application s’exécutant sur Azure ou un principal de service pour une application non exécutée sur Azure, mais inscrite dans Microsoft Entra, vous devez accorder des autorisations appropriées aux identités pour accéder à la ressource GeoCatalog via la configuration RBAC.
Vous trouverez ci-dessous un exemple pas à pas montrant comment configurer le contrôle d’accès en fonction du rôle (RBAC) pour affecter le rôle « Administrateur GeoCatalog » à l’identité managée affectée par l’utilisateur d’une application. Vous pouvez suivre ces mêmes étapes dans le portail Azure pour configurer RBAC pour le principal de service d’une application.
Sur le portail Azure, accédez à l’onglet IAM de la ressource Microsoft Planetary Computer Pro sur la gauche.
Sélectionnez Ajouter une attribution de rôle , puis sélectionnez Administrateur GeoCatalog sous « Rôles de fonction de travail »
Sélectionnez le bouton Suivant, puis sélectionnez le bouton radio de l'identité managée
Sélectionnez les membres , puis sélectionnez l’abonnement et l’identité managée affectée par l’utilisateur dans le volet Sélectionner des identités managées sur le côté droit.
Sélectionnez Suivant pour vérifier les informations et terminer la révision et l'affectation.
Acquérir un jeton d’accès pour accéder à Microsoft Planetary Computer Pro
Après avoir configuré RBAC pour accorder à votre application des autorisations appropriées, l’application doit acquérir un jeton d’accès pour authentifier les demandes. Exemple de code Python ci-dessous :
import azure.identity
credential = azure.identity.DefaultAzureCredential()
token = credential.get_token("https://geocatalog.spatio.azure.com/")
headers = {"Authorization": f"Bearer {token.token}"}
Remarque
Si votre application a plusieurs identités managées qui lui sont affectées, vous devez transmettre explicitement la bonne identité : azure.identity.DefaultAzureCredential(managed_identity_client_id=<client_id>). Vous pouvez également configurer des variables d’environnement de votre application sur le portail Azure pour ajouter "AZURE_CLIENT_ID" avec l’ID client de l’identité managée correspondant.
Remarque
Vous pouvez ajouter .default ou user_impersonation comme étendue à credential.get_token() en fonction de votre comportement prévu d'authentification de l'utilisateur.
Remarque
Si votre application est une application web, chaque fois que vous apportez une modification à votre code ou configuration d’application, veillez à fermer et rouvrir le navigateur web pour éviter d’utiliser les informations d’identification mises en cache.
Pour plus d’informations sur les jetons d’accès , consultez les jetons d’accès dans la plateforme d’identités Microsoft . Lorsque vous obtenez des jetons d’accès via l’appel de DefaultAzureCredentials(), les jetons acquis sont mis en cache par l’instance d’informations d’identification. La durée de vie des jetons et l’actualisation sont gérées automatiquement. Vous pouvez passer l’instance DefaultAzureCredential autour et appeler GetToken() ou GetTokenAsync() juste avant d’avoir besoin d’un jeton afin que vous obteniez toujours un jeton qui n’a pas expiré. Si vous devez conserver une session ouverte longue, vous pouvez gérer l’expiration du jeton dans un gestionnaire d’erreurs pour intercepter l’exception et acquérir un nouveau jeton.
Si vous ne pouvez pas utiliser DefaultAzureCredentials() et que vous utilisez d'autres méthodes telles que AzureCliCredential() pour l'acquisition de jetons d'accès, vous devez gérer la durée de vie du jeton et son actualisation. Consultez les durées de vie des jetons configurables dans la plateforme d’identités Microsoft et les jetons d’actualisation dans la plateforme d’identités Microsoft pour plus d’informations.