Sdílet prostřednictvím

Přehled zprostředkovatelů identity pro Azure Stack Hub

  • Článek

Azure Stack Hub vyžaduje Microsoft Entra ID nebo Active Directory Federation Services (AD FS) (AD FS), které je podporováno službou Active Directory jako zprostředkovatelem identity. Volba poskytovatele je jednorázové rozhodnutí, které provedete při prvním nasazení služby Azure Stack Hub. Koncepty a podrobnosti autorizace v tomto článku vám můžou pomoct při výběru mezi zprostředkovateli identit.

Podle toho, ve kterém nasazujete Službu Azure Stack Hub, určuje váš výběr buď Microsoft Entra ID, nebo AD FS:

  • Když ho nasadíte v připojeném režimu, můžete použít Buď Microsoft Entra ID, nebo AD FS.
  • Když ho nasadíte v odpojeném režimu bez připojení k internetu, podporuje se jenom služba AD FS.

Další informace o možnostech, které závisí na prostředí služby Azure Stack Hub, najdete v následujících článcích:

Důležité

Azure AD Graph je zastaralý a bude vyřazen 30. června 2023. Další informace najdete v tomto oddílu.

Běžné koncepty zprostředkovatelů identit

V dalších částech najdete informace o běžných konceptech zprostředkovatelů identity a jejich použití ve službě Azure Stack Hub.

Terminologie pro zprostředkovatele identit

Tenanti adresáře a organizace

Adresář je kontejner, který obsahuje informace o uživatelích, aplikacích, skupinách a instančních objektech.

Tenant adresáře je organizace, například Microsoft nebo vaše vlastní společnost.

  • Microsoft Entra ID podporuje více tenantů a dokáže podporovat i více organizací ve vlastních adresářích. Pokud používáte ID Microsoft Entra a máte více tenantů, můžete aplikacím a uživatelům udělit přístup z jednoho tenanta k jiným tenantům stejného adresáře.
  • Služba AD FS podporuje pouze jednoho tenanta, a proto pouze jednu organizaci.

Uživatelé a skupiny

Uživatelské účty (identity) jsou standardní účty, které ověřují jednotlivce pomocí ID uživatele a hesla. Skupiny můžou zahrnovat uživatele nebo jiné skupiny.

Způsob vytváření a správy uživatelů a skupin závisí na používaném řešení identit.

Ve službě Azure Stack Hub uživatelské účty:

  • Jsou vytvořeny ve formátu username@domain . I když služba AD FS mapuje uživatelské účty na instanci služby Active Directory, služba AD FS nepodporuje použití formátu \<domain>\<alias> .
  • Lze nastavit tak, aby používalo vícefaktorové ověřování.
  • Jsou omezeny na adresář, do kterého se poprvé zaregistrují, což je adresář organizace.
  • Můžete importovat z místních adresářů. Další informace naleznete v tématu Integrace místních adresářů s Microsoft Entra ID.

Když se přihlásíte k portálu User Portal vaší organizace, použijete adresu https://portal.local.azurestack.external URL. Při přihlašování k portálu Azure Stack Hub z jiných domén, než které se používají k registraci služby Azure Stack Hub, musí být název domény použitý k registraci služby Azure Stack Hub připojen k adrese URL portálu. Pokud je například služba Azure Stack Hub zaregistrovaná v fabrikam.onmicrosoft.com a přihlášení k uživatelskému účtu je admin@contoso.com, adresa URL, která se má použít pro přihlášení k portálu User Portal, bude následující: https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

Uživatelé typu host

Uživatelé typu host jsou uživatelské účty z jiných tenantů adresáře, kterým byl udělen přístup k prostředkům ve vašem adresáři. Pokud chcete podporovat uživatele typu host, použijte ID Microsoft Entra a povolte podporu víceklientské architektury. Pokud je povolená podpora, můžete pozvat uživatele typu host, aby měli přístup k prostředkům ve vašem tenantovi adresáře, což zase umožňuje jejich spolupráci s externími organizacemi.

Pokud chcete pozvat uživatele typu host, můžou cloudoví operátoři a uživatelé používat spolupráci Microsoft Entra B2B. Pozvaní uživatelé získají přístup k dokumentům, prostředkům a aplikacím z vašeho adresáře a udržujete kontrolu nad vlastními prostředky a daty.

Jako uživatel typu host se můžete přihlásit k tenantovi adresáře jiné organizace. Uděláte to tak, že k adrese URL portálu připojíte název adresáře dané organizace. Pokud například patříte do organizace Contoso a chcete se přihlásit k adresáři Fabrikam, použijete https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

Aplikace

Aplikace můžete zaregistrovat do Microsoft Entra ID nebo AD FS a pak je nabídnout uživatelům ve vaší organizaci.

Mezi aplikace patří:

  • Webové aplikace: Mezi příklady patří Azure Portal a Azure Resource Manager. Podporují volání webového rozhraní API.
  • Nativní klient: Mezi příklady patří Azure PowerShell, Visual Studio a Azure CLI.

Aplikace můžou podporovat dva typy tenantů:

  • Jeden tenant: Podporuje uživatele a služby pouze ze stejného adresáře, ve kterém je aplikace zaregistrovaná.

    Poznámka:

    Vzhledem k tomu, že služba AD FS podporuje pouze jeden adresář, aplikace, které vytvoříte v topologii služby AD FS, jsou záměrně aplikace s jedním tenantem.

  • Víceklient: Podporuje použití uživateli a službami z adresáře, ve kterém je aplikace zaregistrovaná, i dalších adresářů tenantů. V případě aplikací s více tenanty se můžou uživatelé jiného adresáře tenanta (jiný tenant Microsoft Entra) přihlásit k vaší aplikaci.

    Další informace o víceklientské architektury naleznete v tématu Povolení víceklientské architektury.

    Další informace o vývoji aplikace s více tenanty najdete v tématu Víceklientština aplikace.

Při registraci aplikace vytvoříte dva objekty:

  • Objekt aplikace: Globální reprezentace aplikace ve všech tenantech. Tento vztah je 1:1 s softwarovou aplikací a existuje pouze v adresáři, kde je aplikace poprvé zaregistrována.

  • Instanční objekt: Přihlašovací údaje vytvořené pro aplikaci v adresáři, ve kterém je aplikace poprvé zaregistrovaná. Instanční objekt se také vytvoří v adresáři každého dalšího tenanta, ve kterém se tato aplikace používá. Tento vztah může být 1:N se softwarovou aplikací.

Další informace o objektech aplikace a instančního objektu najdete v tématu Objekty aplikace a instanční objekty v Microsoft Entra ID.

Instanční objekty

Instanční objekt je sada přihlašovacích údajů pro aplikaci nebo službu, která uděluje přístup k prostředkům ve službě Azure Stack Hub. Použití instančního objektu odděluje oprávnění aplikace od oprávnění uživatele aplikace.

Instanční objekt se vytvoří v každém tenantovi, ve kterém se aplikace používá. Instanční objekt vytvoří identitu pro přihlášení a přístup k prostředkům (například uživatelům), které jsou zabezpečené tímto tenantem.

  • Aplikace s jedním tenantem má pouze jeden instanční objekt, který je v adresáři, ve kterém je poprvé vytvořen. Tento instanční objekt se vytvoří a souhlasí s používáním během registrace aplikace.
  • Webová aplikace nebo rozhraní API s více tenanty má instanční objekt vytvořený v každém tenantovi, kde uživatel z tohoto tenanta souhlasí s používáním aplikace.

Přihlašovací údaje pro instanční objekty můžou být klíč vygenerovaný prostřednictvím webu Azure Portal nebo certifikátu. Použití certifikátu je vhodné pro automatizaci, protože certifikáty jsou považovány za bezpečnější než klíče.

Poznámka:

Pokud používáte službu AD FS se službou Azure Stack Hub, může instanční objekty vytvářet pouze správce. V případě služby AD FS vyžadují instanční objekty certifikáty a vytvářejí se prostřednictvím privilegovaného koncového bodu (PEP). Další informace najdete v tématu Použití identity aplikace pro přístup k prostředkům.

Další informace o instančních objektech pro Azure Stack Hub najdete v tématu Vytváření instančních objektů.

Služby

Služby ve službě Azure Stack Hub, které komunikují s zprostředkovatelem identity, se zaregistrují jako aplikace s zprostředkovatelem identity. Registrace podobně jako aplikace umožňuje službě ověřovat se systémem identit.

Všechny služby Azure k navázání identity používají protokoly OpenID Connect a webové tokeny JSON. Vzhledem k tomu, že Microsoft Entra ID a AD FS používají konzistentně protokoly, můžete pomocí knihovny MICROSOFT Authentication Library (MSAL) získat token zabezpečení pro ověřování v místním prostředí nebo v Azure (v připojeném scénáři). S MSAL můžete také použít nástroje, jako je Azure PowerShell a Azure CLI pro správu prostředků mezi cloudy a místními prostředky.

Identity a váš systém identit

Identity pro Azure Stack Hub zahrnují uživatelské účty, skupiny a instanční objekty.

Při instalaci služby Azure Stack Hub se několik předdefinovaných aplikací a služeb automaticky zaregistruje u svého zprostředkovatele identity v tenantovi adresáře. Některé služby, které se registrují, se používají pro správu. Pro uživatele jsou k dispozici další služby. Výchozí registrace poskytují základní služby identitám, které můžou vzájemně komunikovat i s identitami, které přidáte později.

Pokud nastavíte Microsoft Entra ID s více tenanty, některé aplikace se rozšíří do nových adresářů.

Ověřování a autorizace

Ověřování aplikacemi a uživateli

Identita mezi vrstvami služby Azure Stack Hub

Pro aplikace a uživatele je architektura služby Azure Stack Hub popsaná čtyřmi vrstvami. Interakce mezi jednotlivými vrstvami můžou používat různé typy ověřování.

Vrstva Ověřování mezi vrstvami
Nástroje a klienti, jako je portál pro správu Pokud chcete získat přístup k prostředku ve službě Azure Stack Hub nebo ho upravit, nástroje a klienti používají k volání Azure Resource Manageru webový token JSON.
Azure Resource Manager ověří webový token JSON a prohlédne si deklarace identity v vydaném tokenu a odhaduje úroveň autorizace, kterou má uživatel nebo instanční objekt ve službě Azure Stack Hub.
Azure Resource Manager a jeho základní služby Azure Resource Manager komunikuje s poskytovateli prostředků za účelem přenosu komunikace od uživatelů.
Přenosy používají přímé imperativní volání nebo deklarativní volání prostřednictvím šablon Azure Resource Manageru.
Poskytovatelé prostředků Volání předávaná poskytovatelům prostředků jsou zabezpečená pomocí ověřování založeného na certifikátech.
Azure Resource Manager a poskytovatel prostředků pak zůstávají ve komunikaci prostřednictvím rozhraní API. U každého volání přijatého z Azure Resource Manageru poskytovatel prostředků ověří volání s tímto certifikátem.
Infrastruktura a obchodní logika Poskytovatelé prostředků komunikují s obchodní logikou a infrastrukturou pomocí režimu ověřování podle svého výběru. Výchozí poskytovatelé prostředků, kteří se dodávají se službou Azure Stack Hub, k zabezpečení této komunikace používají ověřování systému Windows.

Informace potřebné k ověřování

Ověřování v Azure Resource Manageru

Pokud se chcete ověřit pomocí zprostředkovatele identity a získat webový token JSON, musíte mít následující informace:

  1. Adresa URL systému identit (autorita): Adresa URL, na které je možné dosáhnout vašeho zprostředkovatele identity. Například https://login.windows.net.
  2. Identifikátor URI ID aplikace pro Azure Resource Manager: Jedinečný identifikátor Azure Resource Manageru, který je zaregistrovaný u vašeho zprostředkovatele identity. Je také jedinečná pro každou instalaci služby Azure Stack Hub.
  3. Přihlašovací údaje: Přihlašovací údaje, které používáte k ověření u zprostředkovatele identity.
  4. Adresa URL pro Azure Resource Manager: Adresa URL je umístění služby Azure Resource Manager. Například https://management.azure.com nebo https://management.local.azurestack.external.

Když objekt zabezpečení (klient, aplikace nebo uživatel) vytvoří žádost o ověření pro přístup k prostředku, musí požadavek zahrnovat:

  • Přihlašovací údaje objektu zabezpečení.
  • Identifikátor URI ID aplikace prostředku, ke kterému chce objekt zabezpečení získat přístup.

Přihlašovací údaje ověřuje zprostředkovatel identity. Zprostředkovatel identity také ověří, že identifikátor URI ID aplikace je pro zaregistrovanou aplikaci a že objekt zabezpečení má správná oprávnění k získání tokenu pro daný prostředek. Pokud je požadavek platný, udělí se webový token JSON.

Token pak musí předat hlavičku požadavku do Azure Resource Manageru. Azure Resource Manager v žádném konkrétním pořadí:

  • Ověří deklaraci identity vystavitele (iss) a ověří, že token pochází od správného zprostředkovatele identity.
  • Ověří deklaraci identity cílové skupiny (aud) a ověří, že token byl vydán azure Resource Manageru.
  • Ověří, že je webový token JSON podepsaný certifikátem nakonfigurovaným prostřednictvím OpenID a známého pro Azure Resource Manager.
  • Zkontrolujte deklarace identity vydané při (iat) a vypršení platnosti (exp) a ověřte, že je token aktivní a lze ho přijmout.

Po dokončení všech ověření azure Resource Manager použije ID objektu (oid) a deklarace identity skupin k vytvoření seznamu prostředků, ke kterým má objekt zabezpečení přístup.

Diagram protokolu výměny tokenů

Použití řízení přístupu na základě role

Řízení přístupu na základě role (RBAC) ve službě Azure Stack Hub je konzistentní s implementací v Microsoft Azure. Přístup k prostředkům můžete spravovat přiřazením příslušné role RBAC uživatelům, skupinám a aplikacím. Informace o tom, jak používat RBAC se službou Azure Stack Hub, najdete v následujících článcích:

Ověřování s využitím Azure PowerShellu

Podrobnosti o použití Azure PowerShellu k ověření ve službě Azure Stack Hub najdete v tématu Konfigurace uživatelského prostředí PowerShellu služby Azure Stack Hub.

Ověřování pomocí Azure CLI

Informace o ověřování pomocí Azure PowerShellu ve službě Azure Stack Hub najdete v tématu Instalace a konfigurace Azure CLI pro použití se službou Azure Stack Hub.

Azure Policy

Azure Policy pomáhá vynucovat standardy organizace a vyhodnotit dodržování předpisů ve velkém měřítku. Prostřednictvím řídicího panelu dodržování předpisů poskytuje agregované zobrazení pro vyhodnocení celkového stavu prostředí s možností přejít k podrobnostem jednotlivých prostředků a podrobností zásad. Napomáhá tomu, aby prostředky dodržovaly předpisy, a sice prostřednictvím hromadné nápravy existujících prostředků a automatické nápravy nových prostředků.

Mezi běžné případy použití služby Azure Policy patří implementace zásad správného řízení v zájmu zajištění konzistence prostředků, dodržování legislativních předpisů, zabezpečení, řízení nákladů a správa. Definice zásad pro tyto běžné případy použití jsou už integrované ve vašem prostředí Azure, které vám pomůžou začít.

Poznámka:

Azure Policy se v současné době ve službě Azure Stack Hub nepodporuje.

Azure AD Graph

Microsoft Azure oznámil ukončení služby Azure AD Graph 30. června 2020 a datum vyřazení ze dne 30. června 2023. Microsoft informoval zákazníky e-mailem o této změně. Podrobnější informace najdete na blogu o vyřazení azure AD Graphu a vyřazení modulu PowerShellu.

Následující část popisuje, jak toto vyřazení ovlivňuje službu Azure Stack Hub.

Tým služby Azure Stack Hub úzce spolupracuje s týmem Azure Graphu, aby zajistil hladký přechod vašich systémů i po 30. červnu 2023. Nejdůležitější akcí je zajistit, abyste dodržovali zásady údržby služby Azure Stack Hub. Zákazníci obdrží upozornění na portálu pro správu služby Azure Stack Hub a budou muset aktualizovat domovský adresář a všechny onboardované adresáře hostů.

Většina samotné migrace bude provedena integrovaným prostředím aktualizace systému; Zákazníci musí provést ruční krok, který zákazníci vyžadují, aby těmto aplikacím udělili nová oprávnění, což bude vyžadovat oprávnění správce aplikací v každém adresáři Microsoft Entra používaném s prostředími služby Azure Stack Hub. Po dokončení instalace balíčku aktualizace s těmito změnami se na portálu pro správu vyvolá upozornění, které vás přesměruje na dokončení tohoto kroku pomocí víceklientského uživatelského rozhraní nebo skriptů PowerShellu. Jedná se o stejnou operaci, kterou provádíte při připojování dalších adresářů nebo poskytovatelů prostředků; Další informace najdete v tématu Konfigurace víceklientské architektury ve službě Azure Stack Hub.

Pokud jako systém identit ve službě Azure Stack Hub používáte službu AD FS, tyto změny grafu nebudou mít přímý vliv na váš systém. Nejnovější verze nástrojů, jako je Azure CLI, Azure PowerShell atd., ale vyžadují nová rozhraní Graph API a nebudou fungovat. Ujistěte se, že používáte pouze verze těchto nástrojů, které jsou explicitně podporované s vaším sestavením služby Azure Stack Hub.

Kromě upozornění na portálu pro správu budeme komunikovat změny prostřednictvím poznámek k vydání verze aktualizace a budeme komunikovat, který balíček aktualizací vyžaduje aktualizaci domovského adresáře a všech onboardovaných adresářů hostů.

Další kroky