Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Dit artikel bevat stapsgewijze richtlijnen voor ontwikkelaars en beheerders voor het instellen van veilige toepassingsverificatie en toegang tot Microsoft Planetary Computer Pro. Door Microsoft Entra ID en beheerde identiteiten toe te passen, kunnen toepassingen naadloos worden geverifieerd zonder referenties te beheren, waardoor veilige interactie met Planetary Computer Pro-resources wordt gewaarborgd. Ongeacht of uw toepassing wordt uitgevoerd in Azure of andere omgevingen, bevat deze handleiding een overzicht van de benodigde configuraties, waaronder op rollen gebaseerd toegangsbeheer (RBAC) en het verkrijgen van tokens, om veilige toegang in te schakelen.
Opmerking
Voor toepassingen die gebruikmaken van Azure AD B2C of Externe Id van Microsoft Entra, moeten de toepassingen deze identiteitsoplossingen blijven gebruiken voor het proxyverificatieverkeer, omdat Planetary Computer Pro geen alternatieven biedt voor Microsoft Entra ID-verificatie.
Verificatieopties en aanbevelingen
De volgende tabel bevat een overzicht van de aanbevolen verificatiemethode op basis van waar uw toepassing wordt uitgevoerd en hoe deze toegang heeft tot resources:
| Omgeving voor toepassingshosting | Toegangstype vereist | Aanbevolen identiteitstype | Explanation |
|---|---|---|---|
| Wordt uitgevoerd in Azure (VM, App Service, Functions, Container Apps, enzovoort) | App-Only (toepassing fungeert als zichzelf) | Beheerde identiteit (door de gebruiker toegewezen aanbevolen) | Beveiliging en beheerbaarheid: Elimineert de noodzaak om referenties (geheimen of certificaten) op te slaan en te beheren in code of configuratie. Azure verwerkt referentierotatie automatisch. Het gebruik van door de gebruiker toegewezen is de voorkeur voor het delen van meerdere hulpbronnen. |
| Wordt uitgevoerd in Azure (VM, App Service, Functions, Container Apps, enzovoort) | Gedelegeerd (toepassing handelt namens een gebruiker) | Beheerde identiteit (door de gebruiker toegewezen aanbevolen) | Maakt gebruik van Azure-integratie: Combineert de beveiligingsvoordelen van Managed Identity voor de toepassing zelf met standaardgebruikersverificatiestromen. Vereenvoudigt het instellen van de infrastructuur in Azure. |
| Buiten Azure uitvoeren (on-premises, andere cloud, ontwikkelcomputer) | App-Only (toepassing fungeert als zichzelf) | Service principal | Standard voor externe apps: De tot stand gebrachte methode voor niet-Azure-toepassingen voor verificatie met Microsoft Entra-id. Vereist het veilig beheren van inloggegevens (geheimen of certificaten). |
| Buiten Azure uitvoeren (on-premises, andere cloud, ontwikkelcomputer) | Gedelegeerd (toepassing handelt namens een gebruiker) | Service principal | Standard voor externe apps: Hiermee schakelt u standaard OAuth 2.0-stromen in voor aanmelding van gebruikers en toestemming voor toepassingen buiten Azure, met behulp van de geregistreerde identiteit van de toepassing in Entra-id. |
| Uitvoeren buiten Azure (alternatief) | App-Only of gedelegeerd | Beheerde identiteit | Biedt Azure-voordelen: Door de toepassing te hosten in een Azure-rekenservice (zoals een VM of container-app), kan deze de verbeterde beveiliging en beheerbaarheid van beheerde identiteiten gebruiken, waardoor referentiebeheer wordt vermeden, ook al kan de oorsprong als niet-Azure worden beschouwd. |
Vereiste voorwaarden
- Azure-account met een actief abonnement - gratis een account maken
- Een bestaande GeoCatalog-resource.
Toepassingen die worden uitgevoerd in Azure
Voor toepassingen die worden uitgevoerd in Azure, raden we aan om een type Microsoft Entra-identity met de naam gebruikers-toegewezen Managed Identity te maken voor toegang tot de GeoCatalog-resource. De toepassingen kunnen de beheerde identiteiten gebruiken om Microsoft Entra-tokens te verkrijgen (zie de sectie Toegangstoken verkrijgen voor toegang tot Microsoft Planetary Computer Pro zonder referenties te hoeven beheren. Zie Wat zijn beheerde identiteiten voor Azure-resources voor meer informatie over beheerde identiteiten en welk type u wilt kiezen. Als u door de gebruiker toegewezen beheerde identiteiten wilt maken voor uw toepassing die wordt uitgevoerd in Azure, volgt u Beheerde identiteiten gebruiken voor App Service en Azure Functions.
Toepassingen die niet worden uitgevoerd in Azure
Voor toepassingen die niet worden uitgevoerd in Azure, zoals on-premises of gehost op andere cloudproviders, raden we u aan de toepassing te registreren in het Microsoft Entra-beheercentrum, inclusief een omleidings-URI voor het ontvangen van beveiligingstokens, om een vertrouwensrelatie tot stand te brengen tussen uw app en Microsoft Identity Platform. Als u de app registreert in Microsoft Entra, wordt automatisch een service-principal voor de app gemaakt, die u later RBAC-rollen kunt toewijzen. Als uw toepassing een instelling heeft voor het configureren van Microsoft Entra ID-verificatie, kunt u hiervoor de toepassings-id (client- en directory-id) van de geregistreerde app gebruiken.
Als u de toepassing niet kunt registreren in Microsoft Entra zoals eerder is aanbevolen, hebt u een andere optie om de toepassing uit te voeren in een Azure-VM of container-app. U kunt een door de gebruiker toegewezen beheerde identiteit maken en deze toewijzen aan de virtuele machine (VM) of container-app, zoals hier wordt beschreven: beheerde identiteiten configureren op virtuele Azure-machines (VM's) en beheerde identiteiten in Azure Container Apps. De toepassing kan zich aanmelden met de beheerde identiteit om toegang te krijgen tot de GeoCatalog-resource. Als u de toepassing bijvoorbeeld wilt uitvoeren in een VIRTUELE machine met behulp van een door de gebruiker toegewezen beheerde identiteit, kunt u het volgende gebruiken:
!az login --identity --username <client_id|object_id|resource_id>
U vindt de client-id, object-id of resource-id van de beheerde identiteit in Azure Portal. Als alternatief voor de CLI bevindt de python-voorbeeldcode zich onder de sectie Toegangstoken verkrijgen voor toegang tot Microsoft Planetary Computer Pro.
azure.identity.DefaultAzureCredential(managed_identity_client_id=<client_id>)
Nadat u een door de gebruiker toegewezen beheerde identiteit of een service-principal voor uw toepassing hebt gemaakt zoals eerder beschreven, moet u het type toepassingstoegangsscenario bepalen: alleen app-toegang, alleen fungeren als de eigen identiteit of gedelegeerde toegang van de toepassing, die namens een aangemelde gebruiker fungeert.
Alleen-app-toegang
In dit toegangsscenario fungeert de toepassing zelfstandig zonder dat een gebruiker zich heeft aangemeld als het standaardgedrag. U kunt doorgaan met de sectie Microsoft Planetary Computer Pro RBAC-configuratie voor toepassingen om de juiste rollen toe te wijzen aan de toepassing.
Gedelegeerde toegang
In dit toegangsscenario heeft een gebruiker zich aangemeld bij een clienttoepassing. De clienttoepassing heeft namens de gebruiker toegang tot de resource. U moet ervoor zorgen dat de gebruikers van de toepassing de juiste RBAC-rollen krijgen, zoals beschreven in het gedeelte Gebruikers maken en beheren. U moet ook de API-machtigingen van de toepassing configureren met gedelegeerde machtigingen door de volgende stappen uit te voeren:
- Meld u aan bij het Microsoft Entra-beheercentrum
- Blader naar Identiteit>Toepassingen>App-registraties en selecteer vervolgens uw clienttoepassing
- Selecteer api-machtigingen onder Beheren
- Selecteer Een machtiging toevoegen
- Selecteer de API's die mijn organisatie gebruikt op het tabblad
- Typ Azure Orbital Planetary Computer in het zoekveld
- Selecteer de overeenkomende vermelding (app-id moet 6388acc4-795e-43a9-a320-33075c1eb83b zijn). Het wordt weergegeven als Azure Orbital Microsoft Planetary Computer Pro.
- Selecteer het vak Gedelegeerde machtigingen . Schakel het selectievakje naast user_impersonation in.
- Selecteer Machtigingen toevoegen
- Selecteer de koppeling 'Beheerderstoestemming verlenen' (ervan uitgaande dat u beheerderstoestemming wilt verlenen in de tenant voor deze machtiging)
Het gedelegeerde verificatiepatroon wordt ook gebruikt bij het verbinden vanuit QGIS.
Microsoft Planetary Computer Pro RBAC-configuratie voor toepassingen
Zodra u een beheerde identiteit hebt gemaakt voor een toepassing die wordt uitgevoerd in Azure of een service-principal voor een toepassing die niet wordt uitgevoerd in Azure, maar is geregistreerd in Microsoft Entra, moet u de juiste machtigingen verlenen aan de identiteiten voor toegang tot de GeoCatalog-resource via RBAC-configuratie.
Hieronder ziet u een stapsgewijs voorbeeld waarin wordt getoond hoe u Role-Based Toegangsbeheer (RBAC) configureert om de rol GeoCatalog-beheerder toe te wijzen aan de door de gebruiker toegewezen beheerde identiteit van een toepassing. U kunt dezelfde stappen in Azure Portal volgen om RBAC te configureren voor de service-principal van een toepassing.
Navigeer in Azure Portal naar het IAM-tabblad van de Microsoft Planetary Computer Pro-resource aan de linkerkant.
Selecteer Roltoewijzing toevoegen en selecteer vervolgens GeoCatalog-beheerder onder 'Functierollen'
Selecteer de knop Volgende en selecteer vervolgens de radioknop Beheerde identiteit
Selecteer Selecteer leden en selecteer het abonnement en de door de gebruiker toegewezen beheerde identiteit in het deelvenster Selecteer beheerde identiteiten aan de rechterkant.
Selecteer Volgende om de informatie te controleren en beoordeling en toewijzen te voltooien.
Toegangstoken verkrijgen voor toegang tot Microsoft Planetary Computer Pro
Nadat u RBAC hebt geconfigureerd om de juiste machtigingen voor uw toepassing te verlenen, moet de toepassing een toegangstoken verkrijgen om aanvragen te verifiëren. Python-voorbeeldcode hieronder:
import azure.identity
credential = azure.identity.DefaultAzureCredential()
token = credential.get_token("https://geocatalog.spatio.azure.com/")
headers = {"Authorization": f"Bearer {token.token}"}
Opmerking
Als aan uw toepassing meerdere beheerde identiteiten zijn toegewezen, moet u de juiste identiteit expliciet doorgeven: azure.identity.DefaultAzureCredential(managed_identity_client_id=<client_id>) U kunt ook omgevingsvariabelen van uw toepassing configureren in de Azure Portal om "AZURE_CLIENT_ID" toe te voegen met de juiste managed identity-client-id.
Opmerking
U kunt .default of user_impersonation als bereik toevoegen aan credential.get_token() op basis van uw verwachte gebruikersverificatiegedrag.
Opmerking
Als uw toepassing een web-app is, moet u, wanneer u een wijziging aanbrengt in de code of app-configuratie, de webbrowser sluiten en opnieuw openen om te voorkomen dat referenties in de cache worden gebruikt.
Zie Toegangstokens in het Microsoft Identity Platform voor meer informatie over toegangstokens. Wanneer u toegangstokens verkrijgt via het aanroepen van DefaultAzureCredentials(), worden de verkregen tokens in de cache opgeslagen door het referentie-exemplaar. De levensduur en het vernieuwen van tokens worden automatisch verwerkt. U kunt de DefaultAzureCredential-instantie doorgeven en GetToken() of GetTokenAsync() aanroepen, net voordat u een token nodig heeft, zodat u altijd een token krijgt dat niet is verlopen. Als u een lange open sessie wilt onderhouden, kunt u het verloop van tokens afhandelen in een foutafhandelaar om de uitzondering te ondervangen en een nieuw token te verkrijgen.
Als u DefaultAzureCredentials() niet kunt gebruiken en in plaats daarvan andere methoden, zoals AzureCliCredential(), toepast om toegangstokens te verkrijgen, moet u de levensduur en vernieuwing van het token beheren. Zie Configureerbare tokenlevensduur in het Microsoft Identity Platform en Vernieuwingstokens in het Microsoft Identity Platform voor meer informatie.