Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Den här artikeln innehåller stegvisa riktlinjer för utvecklare och administratörer för att konfigurera säker programautentisering och åtkomst till Microsoft Planetary Computer Pro. Genom att tillämpa Microsoft Entra-ID och hanterade identiteter kan program autentisera sömlöst utan att hantera autentiseringsuppgifter, vilket säkerställer säker interaktion med Planetary Computer Pro-resurser. Oavsett om ditt program körs i Azure eller andra miljöer beskriver den här guiden nödvändiga konfigurationer, inklusive rollbaserad åtkomstkontroll (RBAC) och tokenförvärv, för att möjliggöra säker åtkomst.
Anmärkning
För program som använder Azure AD B2C eller microsoft entra externt ID som stöder funktioner som sociala identitetsprovidrar måste programmen fortsätta att använda dessa identitetslösningar för proxyautentiseringstrafik eftersom Planetary Computer Pro inte stöder alternativ till Microsoft Entra-ID-autentisering.
Autentiseringsalternativ och rekommendationer
I följande tabell sammanfattas den rekommenderade autentiseringsmetoden baserat på var programmet körs och hur det kommer åt resurser:
| Programvärdmiljö | Åtkomsttyp krävs | Rekommenderad identitetstyp | Explanation |
|---|---|---|---|
| Körs på Azure (VM, App Service, Functions, Container Apps osv.) | App-Only (programmet agerar som sig självt) | Hanterad identitet (användartilldelad rekommenderas) | Säkerhet och hanterbarhet: Eliminerar behovet av att lagra och hantera autentiseringsuppgifter (hemligheter eller certifikat) i kod eller konfiguration. Azure hanterar rotation av autentiseringsuppgifter automatiskt. Användartilldelningar är att föredra för delning mellan de flera resurserna. |
| Körs på Azure (VM, App Service, Functions, Container Apps osv.) | Delegerad (programmet agerar för en användares räkning) | Hanterad identitet (användartilldelad rekommenderas) | Utnyttjar Azure-integrering: Kombinerar säkerhetsfördelarna med hanterad identitet för själva programmet med standardflöden för användarautentisering. Förenklar infrastrukturkonfigurationen i Azure. |
| Köra utanför Azure (på plats, annat moln, utvecklardator) | App-Only (programmet agerar som sig självt) | Tjänsthuvudman | Standard för externa appar: Den etablerade metoden för icke-Azure-program att autentisera med Microsoft Entra-ID. Kräver säker hantering av autentiseringsuppgifter (hemligheter eller certifikat). |
| Köra utanför Azure (på plats, annat moln, utvecklardator) | Delegerad (programmet agerar för en användares räkning) | Tjänsthuvudman | Standard för externa appar: Aktiverar OAuth 2.0-standardflöden för användarinloggning och medgivande för program utanför Azure med hjälp av programmets registrerade identitet i Entra-ID. |
| Körs utanför Azure (alternativ) | App-Only eller delegerad | Hanterad identitet | Medför Azure-fördelar: Genom att vara värd för programmet i en Azure-beräkningstjänst (t.ex. en virtuell dator eller containerapp) kan det använda förbättrad säkerhet och hanterbarhet för hanterade identiteter och undvika hantering av autentiseringsuppgifter även om ursprunget kan betraktas som icke-Azure. |
Förutsättningar
- Azure-konto med en aktiv prenumeration – skapa ett konto kostnadsfritt
- En befintlig GeoCatalog-resurs.
Program som körs i Azure
För program som körs i Azure rekommenderar vi att du skapar en typ av Microsoft Entra-identitet som kallas användartilldelad hanterad identitet för åtkomst till GeoCatalog-resursen. Programmen kan använda hanterade identiteter för att hämta Microsoft Entra-token (se avsnittet Hämta åtkomsttoken för att få åtkomst till Microsoft Planetary Computer Pro utan att behöva hantera några autentiseringsuppgifter. Mer information om hanterade identiteter och vilken typ du ska välja finns i Vad är hanterade identiteter för Azure-resurser. Om du vill skapa användartilldelade hanterade identiteter för ditt program som körs i Azure följer du Så här använder du hanterade identiteter för App Service och Azure Functions.
Program som inte körs i Azure
För program som inte körs i Azure, till exempel lokalt eller på andra molnleverantörer, rekommenderar vi att du registrerar programmet i Administrationscenter för Microsoft Entra, inklusive en omdirigerings-URI för att ta emot säkerhetstoken, för att upprätta en förtroenderelation mellan din app och Microsofts identitetsplattform. När du registrerar appen i Microsoft Entra skapas automatiskt ett tjänsthuvudnamn för appen, som du kan tilldela RBAC-roller senare. Om ditt program har en inställning för att konfigurera Microsoft Entra-ID-autentisering kan du använda den registrerade appens program-ID och katalog-ID för att göra det.
Om du inte kan registrera programmet i Microsoft Entra som vi rekommenderade tidigare har du ett annat alternativ för att köra programmet på en virtuell Azure-dator eller containerapp. Du kan skapa en användartilldelad hanterad identitet och tilldela den till den virtuella datorn (VM) eller containerappen enligt beskrivningen här – Konfigurera hanterade identiteter på virtuella Azure-datorer (VM) och hanterade identiteter i Azure Container Apps. Programmet skulle kunna logga in med den hanterade identiteten för att få åtkomst till GeoCatalog-resursen. Om programmet till exempel ska köras i en virtuell dator med hjälp av en användartilldelad hanterad identitet kan du använda:
!az login --identity --username <client_id|object_id|resource_id>
Du hittar klient-ID, objekt-ID eller resurs-ID för den hanterade identiteten från Azure-portalen. Som ett alternativ till CLI finns Python-exempelkoden under avsnittet Hämta åtkomsttoken för att få åtkomst till Microsoft Planetary Computer Pro.
azure.identity.DefaultAzureCredential(managed_identity_client_id=<client_id>)
När du har skapat en användartilldelad hanterad identitet eller ett tjänsthuvudnamn för ditt program enligt beskrivningen ovan, måste du bestämma vilken typ av programåtkomstscenario: endast appåtkomst, som endast fungerar som programmets egen identitet eller delegerade åtkomst, som agerar för en inloggad användares räkning.
Åtkomst endast för appar
I det här åtkomstscenariot fungerar programmet på egen hand utan att någon användare är inloggad som standardbeteende. Du kan gå vidare till avsnittet Microsoft Planetary Computer Pro RBAC-konfiguration för program för att tilldela lämpliga roller till programmet.
Delegerad åtkomst
I det här åtkomstscenariot loggade en användare in i ett klientprogram. Klientprogrammet kommer åt resursen för användarens räkning. Du måste se till att användarna av programmet tilldelas rätt RBAC-roller enligt beskrivningen i avsnittet Skapa och hantera användare. Du måste också konfigurera programmets API-behörigheter med delegerade behörigheter enligt följande steg:
- Logga in på Microsoft Entra administrationscenter
- Bläddra till Identitet>Applikationer>Appregistreringar, och välj sedan ditt klientprogram
- Under Hantera väljer du API-behörigheter
- Välj Lägg till en behörighet
- Välj fliken API:er som min organisation använder
- Skriv Azure Orbital Planetary Computer i sökfältet
- Välj matchande post (app-ID ska vara 6388acc4-795e-43a9-a320-33075c1eb83b). Den visas som Azure Orbital Microsoft Planetary Computer Pro.
- Välj i rutan Delegerade behörigheter . Markera kryssrutan bredvid user_impersonation.
- Välj Lägg till behörigheter
- Välj länken "Bevilja administratörsmedgivande" (förutsatt att din avsikt är att bevilja administratörsmedgivande i klientorganisationen för den här behörigheten)
Det delegerade autentiseringsmönstret används också vid anslutning från QGIS.
Microsoft Planetary Computer Pro RBAC-konfiguration för program
När du har skapat en hanterad identitet för ett program som körs på Azure, eller ett huvudnamn för tjänsten för ett program som inte körs i Azure men registrerats i Microsoft Entra, måste du bevilja rätt behörigheter till identiteterna för att få åtkomst till GeoCatalog-resursen via RBAC-konfigurationen.
Nedan visas ett steg-för-steg-exempel som visar hur du konfigurerar Role-Based åtkomstkontroll (RBAC) för att tilldela rollen "GeoCatalog Administrator" till ett programs användartilldelade hanterade identitet. Du kan följa samma steg i Azure-portalen för att konfigurera RBAC för ett programs tjänsthuvudnamn.
I Azure-portalen går du till fliken IAM för Microsoft Planetary Computer Pro-resursen till vänster.
Välj lägg till rolltilldelning och välj sedan GeoCatalog-administratör under "Jobbfunktionsroller"
Välj Nästa-knappen och sedan radio-knappen för Hanterad identitet
Välj på Välj medlemmar och välj prenumerationen och den användartilldelade hanterade identiteten i fönstret Välj hanterade identiteter till höger.
Skärmbild av panelen för valda medlemmar i Azure-portalen.
Välj nästa för att verifiera informationen och slutför granskning + tilldelning.
Hämta åtkomsttoken för att få åtkomst till Microsoft Planetary Computer Pro
När du har konfigurerat RBAC för att ge programmet rätt behörigheter måste programmet skaffa en åtkomsttoken för att autentisera begäranden. Python-exempelkod nedan:
import azure.identity
credential = azure.identity.DefaultAzureCredential()
token = credential.get_token("https://geocatalog.spatio.azure.com/")
headers = {"Authorization": f"Bearer {token.token}"}
Anmärkning
Om din applikation har flera tilldelade hanterade identiteter måste du uttryckligen ange den rätta: azure.identity.DefaultAzureCredential(managed_identity_client_id=<client_id>). Du kan också konfigurera miljövariabler för ditt program på Azure-portalen för att lägga "AZURE_CLIENT_ID" till med rätt hanterat identitetsklient-ID.
Anmärkning
Du kan lägga till .default eller user_impersonation som omfång till credential.get_token() baserat på ditt förväntade användarautentiseringsbeteende.
Anmärkning
Om ditt program är en webbapp, när du ändrar din kod eller appkonfiguration, måste du stänga och öppna webbläsaren igen för att undvika att cachelagrade autentiseringsuppgifter används.
Mer information om åtkomsttoken finns i Åtkomsttoken på Microsofts identitetsplattform . När du skapar åtkomsttoken genom att anropa DefaultAzureCredentials(), cachelagras de förvärvade token av autentiseringsinstansen. Tokens livslängd och uppdatering hanteras automatiskt. Du kan skicka DefaultAzureCredential-instansen runt och anropa GetToken() eller GetTokenAsync() direkt innan du behöver en token så att du alltid får en token som inte har upphört att gälla. Om du behöver ha en lång öppen session kan du hantera förfallodatum för token i en felhanterare för att fånga undantaget och hämta en ny token.
Om du inte kan använda DefaultAzureCredentials() och i stället använder andra metoder, till exempel AzureCliCredential() för att hämta åtkomsttoken, måste du hantera tokens livslängd och uppdatering. Mer information finns i Konfigurerbara tokenlivslängder i Microsofts identitetsplattform och Uppdateringstoken på Microsofts identitetsplattform .