Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Tento článek obsahuje podrobné pokyny pro vývojáře a správce k nastavení zabezpečeného ověřování aplikací a přístupu k aplikaci Microsoft Planety Computer Pro. Použitím Microsoft Entra ID a spravovaných identit můžou aplikace bezproblémově ověřovat bez správy přihlašovacích údajů a zajistit bezpečnou interakci s prostředky Planety Computer Pro. Bez ohledu na to, jestli vaše aplikace běží v Azure nebo v jiných prostředích, popisuje tato příručka potřebné konfigurace, včetně řízení přístupu na základě role (RBAC) a získání tokenu, aby bylo možné povolit zabezpečený přístup.
Poznámka:
U aplikací, které používají Azure AD B2C nebo Microsoft Entra External ID podporující funkce, jako jsou zprostředkovatelé sociálních identit, musí aplikace dál používat tato řešení identit k proxy ověřovacímu provozu, protože planetární počítač Pro nepodporuje alternativy k ověřování Microsoft Entra ID.
Možnosti a doporučení pro ověřování
Následující tabulka shrnuje doporučený přístup ověřování na základě toho, kde vaše aplikace běží a jak přistupuje k prostředkům:
| Hostitelské prostředí aplikace | Požadovaný typ přístupu | Doporučený typ identity | Explanation |
|---|---|---|---|
| Běží na Azure (virtuální počítač, App Service, Funkce, kontejnerové aplikace atd.) | App-Only (aplikace funguje sama o sobě) | Spravovaná identita (doporučeno přiřazená uživatelem) | Možnosti zabezpečení a správy: Eliminuje potřebu ukládat a spravovat přihlašovací údaje (tajné kódy nebo certifikáty) v kódu nebo konfiguraci. Azure zpracovává obměnu přihlašovacích údajů automaticky. Přiřazení uživatelem se upřednostňuje pro sdílení napříč více prostředky. |
| Běží na Azure (virtuální počítač, App Service, Funkce, kontejnerové aplikace atd.) | Delegovaná (aplikace působí jménem uživatele) | Spravovaná identita (doporučeno přiřazená uživatelem) | Využívá integraci Azure: Kombinuje výhody zabezpečení spravované identity pro samotnou aplikaci se standardními toky ověřování uživatelů. Zjednodušuje nastavení infrastruktury v Rámci Azure. |
| Spuštění mimo Azure (lokálně, v jiném cloudu, na vývojářském počítači) | App-Only (aplikace funguje sama o sobě) | Servisní principal | Standard pro externí aplikace: Zavedená metoda pro aplikace mimo Azure k ověření pomocí ID Microsoft Entra. Vyžaduje zabezpečenou správu přihlašovacích údajů (tajných kódů nebo certifikátů). |
| Spuštění mimo Azure (lokálně, v jiném cloudu, na vývojářském počítači) | Delegovaná (aplikace působí jménem uživatele) | Servisní principal | Standard pro externí aplikace: Umožňuje standardní toky OAuth 2.0 pro přihlašování uživatelů a vyjádření souhlasu pro aplikace mimo Azure pomocí registrované identity aplikace v Entra ID. |
| Spuštění mimo Azure (alternativa) | App-Only nebo delegováno | Spravovaná identita | Přináší výhody Azure: Hostováním aplikace ve výpočetní službě Azure (jako je virtuální počítač nebo kontejnerová aplikace) může využívat rozšířené zabezpečení a spravovatelnost spravovaných identit, vyhnout se správě přihlašovacích údajů, i když se původ může považovat za jiný než Azure. |
Požadavky
- Účet Azure s aktivním předplatným – bezplatné vytvoření účtu
- Existující prostředek GeoCatalog.
Aplikace spuštěné v Azure
Pro aplikace spuštěné v Azure doporučujeme vytvořit typ identity Microsoft Entra označované jako spravovaná identita přiřazená uživatelem pro přístup k prostředku GeoCatalog. Aplikace můžou používat spravované identity k získání tokenů Microsoft Entra (viz část Získání přístupového tokenu pro přístup k Microsoft Planety Computer Pro bez nutnosti spravovat přihlašovací údaje. Další informace o spravovaných identitách a o tom, jaký typ zvolit, najdete v tématu Co jsou spravované identity pro prostředky Azure. Pokud chcete vytvořit spravované identity přiřazené uživatelem pro vaši aplikaci spuštěnou v Azure, postupujte podle pokynů k používání spravovaných identit pro App Service a Azure Functions.
Aplikace, které nejsou spuštěné v Azure
Pro aplikace, které nejsou spuštěné v Azure, ať už jako místní nebo hostované u jiných poskytovatelů cloudových služeb, doporučujeme zaregistrovat aplikaci v centru pro správu Microsoft Entra, zahrnout identifikátor URI přesměrování pro příjem bezpečnostních tokenů a vytvořit důvěryhodný vztah mezi vaší aplikací a platformou Microsoft Identity. Registrace aplikace v Microsoft Entra automaticky vytvoří Servisní Principál pro aplikaci, kterému můžete později přiřadit role RBAC. Pokud má vaše aplikace nastavení pro konfiguraci ověřování Microsoft Entra ID, můžete k tomu použít ID registrované aplikace "Application (client) ID" a "Directory (tenant) ID".
Pokud nemůžete aplikaci zaregistrovat v Microsoft Entra podle předchozího doporučení, máte jinou možnost spustit aplikaci na virtuálním počítači Azure nebo v aplikaci typu Kontejner. Spravovanou identitu přiřazenou uživatelem můžete vytvořit a přiřadit ji k aplikaci virtuálního počítače nebo kontejneru, jak je popsáno tady: Konfigurace spravovaných identit na virtuálních počítačích Azure a spravovaných identitách v Azure Container Apps. Aplikace by se mohla přihlásit pomocí spravované identity pro přístup k prostředku GeoCatalog. Například pokud chcete, aby aplikace běžela uvnitř virtuálního počítače (VM) s využitím spravované identity přiřazené uživatelem, můžete použít:
!az login --identity --username <client_id|object_id|resource_id>
ID klienta, ID objektu nebo ID prostředku spravované identity najdete na webu Azure Portal. Jako alternativu k rozhraní příkazového řádku je ukázkový kód Pythonu v části Získání přístupového tokenu pro přístup k Microsoft Planety Computer Pro.
azure.identity.DefaultAzureCredential(managed_identity_client_id=<client_id>)
Po vytvoření spravované identity přiřazené uživatelem nebo instančního objektu pro vaši aplikaci, jak je popsáno výše, musíte rozhodnout o typu scénáře přístupu k aplikacím: přístup jen pro aplikaci, který funguje jenom jako vlastní identita nebo delegovaný přístup, a to jménem přihlášeného uživatele.
Přístup jen pro aplikace
V tomto scénáři přístupu aplikace funguje samostatně bez přihlášení uživatele jako výchozího chování. Můžete přejít k části Microsoft Planetary Computer Pro konfigurace RBAC pro aplikace, abyste přiřadili příslušné role k aplikaci.
Delegovaný přístup
V tomto scénáři přístupu se uživatel přihlásil k klientské aplikaci. Klientská aplikace přistupuje k prostředku jménem uživatele. Musíte zajistit, aby uživatelé aplikace měli přiřazené správné role RBAC, jak je popsáno v části Vytvoření a správa uživatelů. Musíte také nakonfigurovat oprávnění rozhraní API aplikace s delegovanými oprávněními pomocí následujících kroků:
- Přihlaste se do Centra pro správu Microsoft Entra
- Přejděte do Identity>Applications>registrací aplikací, a pak vyberte klientskou aplikaci.
- V části Spravovat vyberte oprávnění rozhraní API.
- Vyberte Přidat oprávnění.
- Vyberte kartu rozhraní API, která moje organizace používá
- Do vyhledávacího pole zadejte Planetární počítač Azure Orbital
- Vyberte odpovídající položku (ID aplikace by mělo být 6388acc4-795e-43a9-a320-33075c1eb83b). Zobrazuje se jako Azure Orbital Microsoft Planetární počítač Pro.
- Zaškrtněte políčko Delegovaná oprávnění . Zaškrtněte políčko vedle user_impersonation.
- Vyberte Přidat oprávnění
- Vyberte odkaz Udělit souhlas správce (za předpokladu, že vaším záměrem je udělit souhlas správce v tenantovi pro toto oprávnění).
Model delegovaného ověřování se používá také při připojování z QGIS.
Konfigurace RBAC planetárního počítače Společnosti Microsoft pro aplikace
Jakmile vytvoříte spravovanou identitu pro aplikaci spuštěnou v Azure nebo instanční objekt pro aplikaci, která není spuštěná v Azure, ale zaregistrovaná v Microsoft Entra, musíte identitám udělit správná oprávnění pro přístup k prostředku GeoCatalog prostřednictvím konfigurace RBAC.
Níže je podrobný příklad, který ukazuje, jak nakonfigurovat řízení přístupu Role-Based (RBAC) tak, aby přiřadil roli "Správce GeoCatalogu" spravované identitě přiřazené uživatelem aplikace. Stejným postupem na webu Azure Portal můžete nakonfigurovat RBAC pro instanční objekt aplikace.
Na webu Azure Portal přejděte na kartu IAM prostředku Microsoft Planety Computer Pro na levé straně.
Vyberte možnost Přidat přiřazení role a poté vyberte Správce GeoCatalogu v části "Role pracovních funkcí".
Vyberte tlačítko Další a poté vyberte přepínač Spravovaná identita.
Vyberte členy a poté vyberte předplatné a spravovanou identitu přiřazenou uživatelem v podokně Vybrat spravované identity na pravé straně.
Výběrem možnosti Další ověřte informace a dokončete kontrolu a přiřazení.
Získání přístupového tokenu pro přístup k microsoft planetárnímu počítači Pro
Jakmile nakonfigurujete RBAC tak, aby udělila aplikaci správná oprávnění, musí aplikace získat přístupový token pro ověření požadavků. Níže uvedený ukázkový kód Pythonu:
import azure.identity
credential = azure.identity.DefaultAzureCredential()
token = credential.get_token("https://geocatalog.spatio.azure.com/")
headers = {"Authorization": f"Bearer {token.token}"}
Poznámka:
Pokud má vaše aplikace přiřazených více spravovaných identit, musíte explicitně předat správnou identitu: azure.identity.DefaultAzureCredential(managed_identity_client_id=<client_id>). Případně můžete nakonfigurovat proměnné prostředí své aplikace v Azure portálu, abyste přidali "AZURE_CLIENT_ID" se správným ID klienta spravované identity.
Poznámka:
Můžete přidat .default nebo user_impersonation jako rozsah k credential.get_token() podle očekávaného chování ověřování uživatelů.
Poznámka:
Pokud je vaše aplikace webová aplikace, kdykoli provedete změnu kódu nebo konfigurace aplikace, nezapomeňte zavřít a znovu otevřít webový prohlížeč, aby se zabránilo použití přihlašovacích údajů uložených v mezipaměti.
Další informace o přístupových tokenech najdete v tématu Přístupové tokeny na platformě Microsoft Identity Platform . Když získáváte přístupové tokeny prostřednictvím volání DefaultAzureCredentials(), získané tokeny se ukládají do mezipaměti instance přihlašovacích údajů. Doba života a aktualizace tokenů se zpracovává automaticky. Instanci DefaultAzureCredential můžete předat kolem a vyvolat GetToken() nebo GetTokenAsync() přímo před tím, než potřebujete token, abyste vždy získali token, jehož platnost nevypršela. Pokud potřebujete zachovat dlouhou otevřenou relaci, můžete zpracovat vypršení platnosti tokenu v obslužné rutině chyby, která zachytí výjimku a získá nový token.
Pokud nemůžete použít DefaultAzureCredentials() a místo toho použijete jiné metody, jako například AzureCliCredential() ke získání přístupových tokenů, musíte spravovat životnost a obnovu tokenu. Další informace najdete v tématu Konfigurovatelné životnosti tokenů na platformě Microsoft Identity Platform a obnovovacích tokenech na platformě Microsoft Identity Platform .