Vytvoření víceklienta aplikace

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

U stávajících aplikací s vlastním systémem účtů (nebo jinými přihlašovacími zprostředkovateli od jiných poskytovatelů cloudu) byste měli přidat přihlašovací kód prostřednictvím OAuth2, OpenID Connect nebo SAML a do 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 aplikaci s více tenanty Azure AD:

  1. Aktualizace registrace aplikace tak, aby byla víceklientská
  2. Aktualizace kódu pro odesílání požadavků do koncového /common bodu
  3. Aktualizace kódu pro zpracování více hodnot vystavitele
  4. Vysvětlení souhlasu uživatele a správce a provedení vhodných změn kódu

Můžete také odkazovat na ukázku; Vytvořte webovou aplikaci SaaS s více tenanty, která volá Microsoft Graph pomocí Azure AD a OpenID Connect. Tento postup předpokládá znalost vytváření aplikace s jedním tenantem pro Azure AD. Pokud ne, začněte jedním z rychlých startů na domovské stránce příručky pro vývojáře.

Aktualizace registrace pro více tenantů

Ve výchozím nastavení jsou registrace webové aplikace nebo rozhraní API v Azure AD při vytváření jednoklientské. Pokud chcete provést registraci s více tenanty, vyhledejte část Podporované typy účtů v podokně Ověřování registrace aplikace v Azure Portal. Změňte nastavení na Účty v libovolném adresáři organizace.

Když se aplikace s jedním tenantem vytvoří prostřednictvím Azure Portal, jedna z položek uvedených na stránce Přehled je identifikátor URI ID aplikace. Jedná se o jeden ze způsobů, jak je aplikace identifikována v protokolových zprávách 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 pro aplikace s více tenanty musí být globálně jedinečné pro všechny tenanty, což zajišťuje, že Azure AD dokáže aplikaci najít 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 nepoužívá tento vzor, nastavení aplikace jako aplikace s více tenanty se nezdaří.

Aktualizace kódu tak, aby odesílala žádosti na /common

U aplikace s více tenanty, protože aplikace nemůže okamžitě zjistit, ze kterého tenanta uživatel pochází, nejde žádosti odeslat do koncového bodu tenanta. Místo toho se požadavky posílají do koncového bodu, který multiplexuje ve všech tenantech Azure AD: https://login.microsoftonline.com/common.

Upravte kód a změňte hodnotu tenanta na /common. Je důležité si uvědomit, že tento koncový bod není tenantem ani samotným vystavitelem. Když Microsoft identity platform obdrží požadavek na /common koncový bod, přihlásí se uživatel, čímž zjistí, ze kterého tenanta uživatel pochází. Tento koncový bod funguje se všemi ověřovacími protokoly podporovanými Azure AD (OpenID Connect, 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 řekne 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.

Aktualizace kódu pro zpracování více hodnot vystavitele

Webové aplikace a webová rozhraní API přijímají a ověřují tokeny z Microsoft identity platform. Nativní klientské aplikace neověřují přístupové tokeny a musí s nimi zacházet jako s neprůhlhlou. Místo toho požadují a přijímají tokeny z Microsoft identity platform a odesílají je do rozhraní API, kde se pak ověřují. Aplikace s více tenanty nemůžou ověřit tokeny tak, že odpovídají hodnotě vystavitele v metadatech s issuer hodnotou v tokenu. Aplikace s více tenanty potřebuje logiku pro rozhodnutí, které hodnoty vystavitele jsou platné a které nejsou založené na části ID tenanta hodnoty vystavitele.

Pokud například aplikace s více tenanty povolí přihlášení jenom od konkrétních tenantů, kteří se zaregistrovali ke své službě, musí zkontrolovat issuer hodnotu nebo tid hodnotu deklarace identity v tokenu, aby se zajistilo, že je tenant v seznamu odběratelů. Pokud se aplikace s více tenanty zabývá pouze jednotlivci a nevyužívá žádná rozhodnutí o přístupu na základě tenantů, může hodnotu vystavitele úplně ignorovat.

V ukázkách s více tenanty je ověření vystavitele zakázané, aby se mohl přihlásit jakýkoli Azure AD tenant. /common Vzhledem k tomu, že koncový bod neodpovídá tenantovi a není vystavitelem, při zkoumání hodnoty vystavitele v metadatech /commonmá místo skutečné hodnoty šablonu URL:

https://sts.windows.net/{tenantid}/

Pokud chcete zajistit, aby vaše aplikace podporovala více tenantů, upravte příslušnou část kódu a ujistěte se, že je hodnota vystavitele nastavená na {tenantid}.

Naproti tomu aplikace s jedním tenantem obvykle zabírají hodnoty koncových bodů k vytváření adres URL metadat, jako jsou:

https://login.microsoftonline.com/contoso.onmicrosoft.com/.well-known/openid-configuration

ke stažení dvou důležitých informací, které se používají k ověření tokenů: podpisové klíče tenanta a hodnota vystavitele.

Každý tenant Azure AD má jedinečnou hodnotu vystavitele formuláře:

https://sts.windows.net/31537af4-6d77-4bb9-a681-d2394888ea26/

... kde hodnota GUID je verze ID tenanta tenanta v bezpečném přejmenování.

Když aplikace s jedním tenantem ověří token, zkontroluje podpis tokenu proti podpisovým klíčům z dokumentu metadat. Tento test umožňuje zajistit, aby hodnota vystavitele v tokenu odpovídala hodnotě, která byla nalezena v dokumentu metadat.

Aby se uživatel přihlásil k aplikaci v Azure AD, musí být aplikace reprezentována v tenantovi uživatele. Díky tomu může organizace dělat věci, jako je použití jedinečných zásad, když se uživatelé ze svého tenanta přihlásí k aplikaci. Pro aplikaci s jedním tenantem můžete registraci použít prostřednictvím Azure Portal.

Pro aplikaci s více tenanty se počáteční registrace aplikace nachází v Azure AD tenantovi používaném vývojářem. Když se uživatel z jiného tenanta poprvé přihlásí k aplikaci, Azure AD 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 aplikacích a objektech ServicePrincipal aplikace 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í. Microsoft identity platform podporuje dva druhy oprávnění, pouze aplikace a delegované.

  • Delegovaná 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.
  • Oprávnění jen pro aplikaci 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í mohou 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 aplikace 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 oznámením, že uživatel nemůže souhlasit.

Určitá delegovaná oprávnění také vyžadují souhlas správce tenanta. Například možnost zápisu zpět do Azure AD jako přihlášený uživatel vyžaduje souhlas správce tenanta. Podobně jako oprávnění jen pro aplikaci se běžný uživatel pokusí přihlásit k aplikaci, která požaduje delegovaná oprávnění, která vyžaduje souhlas správce, aplikace obdrží chybu. Zda 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 Microsoft Graph API označuje, 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 akci zahájit. Požadavek, který vaše aplikace odešle pro tuto akci, je obvyklým požadavkem na autorizaci OAuth2/OpenID Connect, který obsahuje prompt=consent také parametr řetězce dotazu. Jakmile správce souhlasí a instanční objekt se vytvoří v tenantovi zákazníka, následné žádosti o přihlášení nepotřebují prompt=consent parametr. 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í jiní uživatelé v tenantovi.

Správce tenanta může zakázat možnost, aby běžní uživatelé souhlasili s aplikacemi. Pokud je tato funkce zakázaná, souhlas správce se vždy vyžaduje, aby se aplikace používala v tenantovi. Pokud chcete aplikaci otestovat se zakázaným souhlasem koncového uživatele, najdete přepínač konfigurace v Azure Portal částiNastavení uživatele v části Podnikové aplikace.

Parametr prompt=consent může také používat 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 od tohoto okamžiku se nezobrazí výzva 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 vaši aplikaci před povolením přístupu jiných uživatelů.

Vaše aplikace může mít více vrstev, které jsou reprezentované vlastní registrací v Azure AD. 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á, Azure AD vrátí chybu, kterou musí být prostředek přidán jako první.

Více vrstev v jednom tenantovi

To může 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 nejprve získáte prostředek do tenanta zákazníka? Azure AD tento případ řeší 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 knownClientApplicationsmanifest aplikace. Příklad:

"knownClientApplications": ["94da0930-763f-45c7-8d26-04d5938baab2"]

To je znázorněno v ukázce webového rozhraní API pro vícevrstvé nativní klienty, kteří volají webové rozhraní API v části Související obsah na konci tohoto článku. Následující diagram poskytuje přehled souhlasu pro vícevrstvou aplikaci zaregistrovanou v jednom tenantovi.

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

Více vrstev ve více tenantech

Podobný případ se stane, pokud jsou různé vrstvy aplikace zaregistrované v různých tenantech. Představte si například případ vytvoření nativní klientské aplikace, která volá rozhraní API Exchange Online. Pokud chcete vyvíjet nativní aplikaci a později pro spuštění nativní aplikace 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 zakoupit 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í do tenantů 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 k implementaci registrace. Použijte následující postup:

  1. Postupujte podle předchozích částí a ujistěte se, že rozhraní API implementuje požadavky na registraci nebo kód aplikace s více tenanty.
  2. Kromě zveřejnění rozsahů a rolí rozhraní API se ujistěte, že registrace obsahuje oprávnění Přihlásit se a číst profil uživatele (ve výchozím nastavení).
  3. Implementujte přihlašovací nebo registrační stránku ve webovém klientovi a postupujte podle pokynů pro vyjádření souhlasu správce .
  4. Jakmile uživatel souhlasí s aplikací, vytvoří se v tenantovi odkazy pro 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ícevrstvou aplikaci zaregistrovanou v různých tenantech.

Diagram znázorňující souhlas s vícevrstvé vícevrstvé aplikace

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

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

Aplikace s více tenanty a ukládání přístupových tokenů do mezipaměti

Aplikace s více tenanty můžou také získat přístupové tokeny pro volání rozhraní API, která jsou chráněná Azure AD. Běžnou chybou při použití knihovny MSAL (Microsoft Authentication Library) s aplikací s více tenanty je počáteční vyžádání tokenu pro uživatele, který používá /common, přijetí odpovědi a následného tokenu pro stejného uživatele také pomocí /common. Vzhledem k tomu, že odpověď z Azure AD 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 zmeš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 vytvoří následná volání již přihlášeného uživatele.

Další kroky

V tomto článku jste zjistili, jak převést jednu aplikaci tenanta na aplikaci s více tenanty. Po povolení jednotného přihlašování mezi vaší aplikací a Azure AD aktualizujte aplikaci tak, aby přistupovala k rozhraním API vystaveným prostředky Microsoftu, jako je Microsoft 365. Díky tomu můžete uživatelům nabídnout přizpůsobené prostředí, například zobrazení kontextových informací uživatelům, například profilování obrázků a událostí kalendáře.

Další informace o volání rozhraní API pro Azure AD a služby Microsoft 365, jako jsou Exchange, SharePoint, OneDrive, OneNote a další, najdete v Microsoft Graph API.