Převod aplikace s jedním tenantem na víceklient v MICROSOFT Entra ID

  • Článek

Pokud nabízíte aplikaci SaaS (Software jako služba) mnoha organizacím, můžete aplikaci nakonfigurovat tak, aby přijímala přihlášení z libovolného tenanta Microsoft Entra tím, že ji převedete na víceklientské. Uživatelé v libovolném tenantovi Microsoft Entra se budou moct přihlásit k vaší aplikaci po vyjádření souhlasu s používáním svého účtu s vaší aplikací.

Pro stávající aplikace s vlastním systémem účtů (nebo jinými přihlašovacími přihlášeními od jiných poskytovatelů cloudu) byste měli přidat přihlašovací kód prostřednictvím OAuth2, OpenID Připojení nebo SAML a do své aplikace vložit tlačítko Přihlásit se pomocí Microsoftu.

V tomto průvodci postupy provedete čtyři kroky potřebné k převodu jedné aplikace tenanta na víceklientských aplikací Microsoft Entra:

  1. Aktualizace registrace aplikace na víceklientských
  2. Aktualizujte kód tak, aby odesílal požadavky do koncového /common bodu.
  3. Aktualizace kódu tak, aby zpracovával více hodnot vystavitelů
  4. Vysvětlení souhlasu uživatele a správce a provedení příslušných změn kódu

Pokud se chcete pokusit použít některou z našich ukázek, přečtěte si článek o vytvoření víceklientské webové aplikace SaaS, která volá Microsoft Graph pomocí Microsoft Entra ID a OpenID Připojení

Požadavky

Aktualizace registrace na víceklientských

Ve výchozím nastavení jsou registrace webových aplikací a rozhraní API v ID Microsoft Entra při vytváření jednoklientské. Pokud chcete provést registraci s více tenanty, přihlaste se do Centra pro správu Microsoft Entra a vyberte registraci aplikace, kterou chcete aktualizovat. Po otevření registrace aplikace vyberte podokno Ověřování a přejděte do části Podporované typy účtů. Změňte nastavení na Účty v libovolném adresáři organizace.

Při vytvoření aplikace s jedním tenantem v Centru pro správu Microsoft Entra je jednou z položek uvedených na stránce Přehled identifikátor URI ID aplikace. Jedná se o jeden ze způsobů, jak je aplikace identifikována ve zprávách protokolu a je možné ji kdykoli přidat. Identifikátor URI ID aplikace pro aplikace s jedním tenantem může být globálně jedinečný v rámci daného tenanta. Naproti tomu u víceklientských aplikací musí být globálně jedinečný ve všech tenantech, což zajišťuje, že ID Microsoft Entra najde aplikaci ve všech tenantech.

Pokud by například název vašeho tenanta byl contoso.onmicrosoft.com platný identifikátor URI https://contoso.onmicrosoft.com/myappID aplikace. Pokud identifikátor URI ID aplikace nevyhovuje tomuto vzoru, nastavení aplikace jako víceklientů selže.

Aktualizujte kód tak, aby odesílal požadavky na /common

U víceklientské aplikace nemůže aplikace okamžitě zjistit, ze kterého tenanta uživatel pochází, takže žádosti se nedají odeslat do koncového bodu tenanta. Místo toho se požadavky posílají do společného koncového bodu (https://login.microsoftonline.com/common), který slouží napříč všemi tenanty Microsoft Entra, jako centrální centrum, které zpracovává požadavky.

Otevřete aplikaci v integrovaném vývojovém prostředí (IDE) a upravte kód a změňte hodnotu ID tenanta na /common. Tento koncový bod není tenant ani samotný vystavitel. Když platforma Microsoft Identity Platform obdrží požadavek na /common koncový bod, přihlásí uživatele a zjistí, ze kterého tenanta uživatel pochází. Tento koncový bod funguje se všemi ověřovacími protokoly podporovanými ID Microsoft Entra (OpenID Připojení, OAuth 2.0, SAML 2.0, WS-Federation).

Odpověď na přihlášení k aplikaci pak obsahuje token představující uživatele. Hodnota vystavitele v tokenu říká aplikaci, z jakého tenanta uživatel pochází. Když se odpověď vrátí z koncového /common bodu, hodnota vystavitele v tokenu odpovídá tenantovi uživatele.

Poznámka:

Ve skutečnosti existují 2 autority pro víceklientských aplikací:

  • https://login.microsoftonline.com/common pro aplikace, které zpracovávají účty v libovolném organizačním adresáři (jakýkoli adresář Microsoft Entra) a osobní účty Microsoft (např. Skype, XBox).
  • https://login.microsoftonline.com/organizations pro aplikace, které zpracovávají účty v libovolném organizačním adresáři (jakýkoli adresář Microsoft Entra):

Vysvětlení v tomto dokumentu se používají common. Pokud ale vaše aplikace nepodporuje osobní účty Microsoft, můžete ho organizations nahradit.

Aktualizace kódu tak, aby zpracovával více hodnot vystavitelů

Webové aplikace a webová rozhraní API přijímají a ověřují tokeny z platformy Microsoft Identity Platform. Nativní klientské aplikace neověřují přístupové tokeny a musí je považovat za neprůhlené. Místo toho požadují a přijímají tokeny z platformy Microsoft Identity Platform a odesílají je do rozhraní API, kde se pak ověří.

Víceklientských aplikací musí při ověřování tokenu provádět více kontrol. Víceklientová aplikace je nakonfigurovaná tak, aby z adres URL klíčů spotřebovávala metadata /organizations klíčů./common Aplikace musí ověřit, že issuer vlastnost v publikovaných metadatech odpovídá iss deklaraci identity v tokenu, kromě obvyklé kontroly, že iss deklarace identity v tokenu obsahuje deklaraci IDENTITY tenanta (tid). Další informace najdete v tématu Ověření tokenů.

Aby se uživatel přihlásil k aplikaci v MICROSOFT Entra ID, musí být aplikace reprezentována v tenantovi uživatele. Organizace tak může dělat věci, jako je použití jedinečných zásad, když se uživatelé z tenanta přihlásí k aplikaci. Pro aplikaci s jedním tenantem můžete registraci použít prostřednictvím Centra pro správu Microsoft Entra.

U víceklientské aplikace se počáteční registrace aplikace nachází v tenantovi Microsoft Entra, který používá vývojář. Když se uživatel z jiného tenanta poprvé přihlásí k aplikaci, Microsoft Entra ID ho požádá o souhlas s oprávněními požadovanými aplikací. Pokud souhlasí, vytvoří se reprezentace aplikace označované jako instanční objekt v tenantovi uživatele a přihlášení může pokračovat. Delegování se také vytvoří v adresáři, který zaznamenává souhlas uživatele s aplikací. Podrobnosti o aplikačních objektech a objektech ServicePrincipal a jejich vzájemné souvislosti najdete v tématu Objekty aplikace a instanční objekty.

Diagram znázorňující souhlas uživatele s jednovrstvou aplikací

Toto prostředí souhlasu má vliv na oprávnění požadovaná aplikací. Platforma Microsoft Identity Platform podporuje dva druhy oprávnění;

  • Delegováno: Toto oprávnění uděluje aplikaci možnost jednat jako přihlášený uživatel pro podmnožinu věcí, které může uživatel dělat. Můžete například aplikaci udělit delegovaná oprávnění ke čtení přihlášeného kalendáře uživatele.
  • Pouze aplikace: Toto oprávnění je uděleno přímo identitě aplikace. Aplikaci můžete například udělit oprávnění jen pro čtení seznamu uživatelů v tenantovi bez ohledu na to, kdo je přihlášený k aplikaci.

Některá oprávnění můžou být udělena běžným uživatelem, zatímco jiné vyžadují souhlas správce tenanta.

Další informace o souhlasu uživatele a správce najdete v tématu Konfigurace pracovního postupu souhlasu správce.

Oprávnění jen pro aplikaci vždy vyžadují souhlas správce tenanta. Pokud vaše aplikace požádá o oprávnění jen pro aplikaci a uživatel se pokusí přihlásit k aplikaci, zobrazí se chybová zpráva s informací, že uživatel nemůže souhlasit.

Určitá delegovaná oprávnění také vyžadují souhlas správce tenanta. Například možnost zapisovat zpět na ID Microsoft Entra jako přihlášený uživatel vyžaduje souhlas správce tenanta. Podobně jako u oprávnění jen pro aplikace se běžný uživatel pokusí přihlásit k aplikaci, která požaduje delegované oprávnění vyžadující souhlas správce, aplikace obdrží chybu. Jestli oprávnění vyžaduje souhlas správce, určuje vývojář, který prostředek publikoval, a najdete ho v dokumentaci k prostředku. Dokumentace k oprávněním pro rozhraní Microsoft Graph API indikuje, která oprávnění vyžadují souhlas správce.

Pokud vaše aplikace používá oprávnění, která vyžadují souhlas správce, zvažte přidání tlačítka nebo odkazu, kde může správce zahájit akci. Požadavek, který aplikace odešle pro tuto akci, je obvyklým požadavkem na autorizaci OAuth2/OpenID Připojení, který obsahuje prompt=consent také parametr řetězce dotazu. Jakmile správce odsouhlasí a instanční objekt se vytvoří v tenantovi zákazníka, následné žádosti o přihlášení tento parametr nepotřebují prompt=consent . Vzhledem k tomu, že správce rozhodl, že požadovaná oprávnění jsou přijatelná, nebudou od tohoto okamžiku vyzváni k vyjádření souhlasu žádní další uživatelé v tenantovi.

Správce tenanta může zakázat možnost, aby běžní uživatelé udělili souhlas s aplikacemi. Pokud je tato funkce zakázaná, souhlas správce se vždy vyžaduje, aby se aplikace používala v tenantovi. Aplikaci můžete otestovat se zakázaným souhlasem koncového uživatele v Centru pro správu Microsoft Entra. V podnikovýchaplikacích>

Tento prompt=consent parametr můžou používat také aplikace, které vyžadují oprávnění, která nevyžadují souhlas správce. Příkladem toho, kdy se použije, je, že aplikace vyžaduje prostředí, kdy se správce tenanta jednou zaregistruje a žádní jiní uživatelé od tohoto okamžiku nebudou vyzváni k vyjádření souhlasu.

Pokud aplikace vyžaduje souhlas správce a správce se přihlásí bez odeslání parametru prompt=consent , když správce úspěšně souhlasí s aplikací, bude platit pouze pro jeho uživatelský účet. Běžní uživatelé se stále nebudou moct přihlásit nebo udělit souhlas s aplikací. Tato funkce je užitečná, pokud chcete správci tenanta dát možnost prozkoumat aplikaci před povolením přístupu k jiným uživatelům.

Vaše aplikace může mít více vrstev, přičemž každá je reprezentovaná vlastní registrací v Microsoft Entra ID. Například nativní aplikace, která volá webové rozhraní API, nebo webovou aplikaci, která volá webové rozhraní API. V obou těchto případech klient (nativní aplikace nebo webová aplikace) požaduje oprávnění k volání prostředku (webového rozhraní API). Aby klient úspěšně souhlasil s tenantem zákazníka, musí všechny prostředky, na které požaduje oprávnění, již existovat v tenantovi zákazníka. Pokud tato podmínka není splněná, vrátí ID Microsoft Entra chybu, že prostředek musí být přidán jako první.

Více vrstev v jednom tenantovi

Může to být problém, pokud se vaše logická aplikace skládá ze dvou nebo více registrací aplikací, například samostatného klienta a prostředku. Jak se prostředek nejprve dostane do externího tenanta? Microsoft Entra ID se zabývá tímto případem povolením souhlasu klienta a prostředku v jednom kroku. Uživatel uvidí celkový součet oprávnění požadovaných klientem i prostředkem na stránce souhlasu. Aby bylo možné toto chování povolit, musí registrace aplikace prostředku obsahovat ID aplikace klienta jako id aplikace v manifestu knownClientApplicationsaplikace. Příklad:

"knownClientApplications": ["12ab34cd-56ef-78gh-90ij11kl12mn"]

To je znázorněno v ukázce víceklientských aplikací. Následující diagram poskytuje přehled souhlasu pro vícevrstvé aplikace zaregistrované v jednom tenantovi.

Diagram znázorňující souhlas s vícevrstvou známou klientskou aplikací

Více vrstev ve více tenantech

K podobnému případu dochází v případě, že jsou různé úrovně aplikace zaregistrované v různých tenantech. Představte si například případ vytvoření nativní klientské aplikace, která volá rozhraní Exchange Online API. Pokud chcete vyvinout nativní aplikaci a později, aby nativní aplikace běžela v tenantovi zákazníka, musí být k dispozici instanční objekt Exchange Online. V takovém případě musí vývojář a zákazník koupit Exchange Online, aby se instanční objekt vytvořil ve svých tenantech.

Pokud se jedná o rozhraní API vytvořené jinou organizací než Microsoft, musí vývojář rozhraní API poskytnout zákazníkům způsob, jak udělit souhlas s aplikací v tenantech svých zákazníků. Doporučeným návrhem je, aby vývojář třetí strany vytvořil rozhraní API tak, aby mohl fungovat také jako webový klient pro implementaci registrace. Akce:

  1. Postupujte podle předchozích částí a ujistěte se, že rozhraní API implementuje požadavky na registraci a kód víceklientské aplikace.
  2. Kromě zveřejnění oborů a rolí rozhraní API se ujistěte, že registrace zahrnuje oprávnění Přihlásit se a číst profil uživatele (ve výchozím nastavení je k dispozici).
  3. Implementujte přihlašovací nebo registrační stránku ve webovém klientovi a postupujte podle pokynů k vyjádření souhlasu správce.
  4. Jakmile uživatel souhlasí s aplikací, vytvoří se v tenantovi odkazy na delegování instančního objektu a souhlasu a nativní aplikace může získat tokeny pro rozhraní API.

Následující diagram poskytuje přehled souhlasu pro vícevrstvé aplikace zaregistrované v různých tenantech.

Diagram znázorňující souhlas s vícevrstvovou vícevrstvou aplikací

Uživatelé a správci můžou kdykoli odvolat souhlas s vaší aplikací:

  • Uživatelé odvolají přístup k jednotlivým aplikacím odebráním ze seznamu Přístupový panel Aplikace.
  • Správa istrátory odvolají přístup k aplikacím tak, že je odeberou pomocí Část Podnikové aplikace v Centru pro správu Microsoft Entra Vyberte aplikaci a přejděte na kartu Oprávnění pro odvolání přístupu.

Pokud správce souhlasí s aplikací pro všechny uživatele v tenantovi, uživatelé nemůžou přístup odvolat jednotlivě. Přístup může odvolat pouze správce a pouze pro celou aplikaci.

Víceklientských aplikací a ukládání přístupových tokenů do mezipaměti

Víceklientské aplikace můžou také získat přístupové tokeny pro volání rozhraní API, která jsou chráněná id Microsoft Entra. Běžnou chybou při použití knihovny MICROSOFT Authentication Library (MSAL) s víceklientská aplikace je počáteční požadavek na token pro uživatele, který používá /common, přijmout odpověď a potom požádat o další token pro stejného uživatele také pomocí /common. Vzhledem k tomu, že odpověď z ID Microsoft Entra pochází z tenanta, ne /common, MSAL ukládá token do mezipaměti jako z tenanta. Následující volání k /common získání přístupového tokenu pro uživatele nezmešká položku mezipaměti a uživateli se zobrazí výzva k opětovnému přihlášení. Abyste se vyhnuli chybějící mezipaměti, ujistěte se, že se do koncového bodu tenanta provedou následná volání již přihlášeného uživatele.

Viz také