Typy identit a účtů pro aplikace s jedním a více tenanty

Tento článek vysvětluje, jak se jako vývojáři můžete rozhodnout, jestli vaše aplikace povoluje jenom uživatele z vašeho tenanta Azure Active Directory (Azure AD), Azure AD tenanta nebo uživatele s osobními účty Microsoft. Během registrace aplikace v Azure můžete nakonfigurovat aplikaci tak, aby byla s jedním tenantem nebo více tenanty. Ujistěte se, že nulová důvěra (Zero Trust) princip nejnižšího oprávnění přístupu, aby vaše aplikace požaduje jenom oprávnění, která potřebuje.

Microsoft identity platform poskytuje podporu pro konkrétní typy identit:

• Pracovní nebo školní účty, pokud má entita účet v Azure Active Directory (AD)
• Osobní účty Microsoft (MSA) pro každého, kdo má účet v Outlook.com, Hotmail, Live, Skype, Xbox atd.
• Externí identity v Azure AD pro partnery (uživatele mimo vaši organizaci)
• Azure AD B2C (Business to Customer), která umožňuje vytvořit řešení, které zákazníkům umožní přivést další zprostředkovatele identity. Aplikace, které používají Azure AD B2C nebo jsou přihlášené k odběru Microsoft Dynamics 365 Fraud Protection s Azure Active Directory B2C, můžou vyhodnotit potenciálně podvodné aktivity po pokusu o vytvoření nových účtů nebo přihlášení k ekosystému klienta.

Požadovaná část registrace aplikace v Azure AD je výběr podporovaných typů účtů. Zatímco IT specialisté v rolích správce rozhodují o tom, kdo může udělit souhlas s aplikacemi ve svém tenantovi, vy jako vývojář určíte, kdo může vaši aplikaci používat na základě typu účtu. Pokud vám tenant nedovolí zaregistrovat aplikaci v Azure AD, správci vám poskytnou způsob, jak jim tyto podrobnosti sdělit jiným mechanismem.

Při registraci aplikace si vyberete z následujících možností podporovaného typu účtu.

• Accounts in this organizational directory only (O365 only - Single tenant)
• Accounts in any organizational directory (Any Azure AD directory - Multitenant)
• Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
• Personal Microsoft accounts only

Pouze účty v tomto organizačním adresáři – jeden tenant

Když vyberete Účty jenom v tomto organizačním adresáři (jenom O365 – jeden tenant), povolíte to jenom uživatelům a hostům z tenanta, ve kterém vývojář zaregistroval svoji aplikaci. Tato možnost je nejběžnější u obchodních aplikací.

Pouze účty v libovolném adresáři organizace – víceklient

Když vyberete Účty v libovolném adresáři organizace (Libovolný adresář Azure AD – Víceklient), povolíte všem uživatelům z libovolného adresáře Azure AD přihlášení k vaší aplikaci s více tenanty. Pokud chcete povolit jenom uživatele z konkrétních tenantů, vyfiltrujete tyto uživatele ve svém kódu tak, že zkontrolujete, že se deklarace identity v id_token nachází ve vašem seznamu povolených tenantů. Vaše aplikace může k přihlašování uživatelů v domovském tenantovi uživatele používat koncový bod organizace nebo společný koncový bod. Pokud chcete podporovat uživatele typu host, kteří se přihlašují k vaší aplikaci s více tenanty, použijete k přihlášení uživatele konkrétní koncový bod tenanta pro tenanta, ve kterém je uživatel hostem.

Účty v jakémkoli účtu organizace a osobních účtech Microsoft

Když vyberete Účty v libovolném účtu organizace a osobních účtech Microsoft (libovolný Azure AD adresář – Víceklient) a osobních účtech Microsoft (např. Skype, Xbox), umožníte uživateli přihlásit se k vaší aplikaci pomocí své nativní identity z libovolného Azure AD tenanta nebo spotřebitelského účtu. Pro tyto aplikace platí stejné filtrování tenantů a využití koncových bodů jako u víceklientských aplikací, jak je popsáno výše.

Jenom osobní účty Microsoft

Když vyberete Jenom osobní účty Microsoft, povolíte používání vaší aplikace jenom uživatelům s uživatelskými účty.

Aplikace pro zákazníky

Když vytváříte řešení v Microsoft identity platform, které osloví vaše zákazníky, obvykle nechcete používat firemní adresář. Místo toho chcete, aby zákazníci byli v samostatném adresáři, aby neměli přístup k žádným firemním prostředkům vaší společnosti. Za účelem splnění této potřeby Microsoft nabízí Azure AD Business to Customer (B2C).

Azure AD B2C poskytuje identitu mezi podniky a zákazníky jako službu. Uživatelům můžete povolit, aby měli uživatelské jméno a heslo jenom pro vaši aplikaci. B2C podporuje zákazníky se sociálními identitami a snižuje tak počet hesel. Podnikové zákazníky můžete podporovat tím, že federujete adresář Azure AD B2C do Azure AD zákazníků (nebo libovolného zprostředkovatele identity, který podporuje SAML) na OpenID Connect. Na rozdíl od víceklientské aplikace vaše aplikace nepoužívá podnikový adresář zákazníka, ve kterém chrání své firemní prostředky. Vaši zákazníci mají přístup k vaší službě nebo funkcím, aniž by vaší aplikaci udělili přístup ke svým firemním prostředkům.

Není to jen na vývojáři.

Zatímco v registraci aplikace definujete, kdo se může přihlásit k vaší aplikaci, poslední slovo přichází od jednotlivých uživatelů nebo správců domovského tenanta uživatele. Správci tenanta často chtějí mít větší kontrolu nad aplikací než jen s tím, kdo se může přihlásit. Může například chtít použít zásadu podmíněného přístupu na aplikaci nebo řídit, kterou skupinu povolí používat aplikaci. Aby správci tenanta mohli mít tento ovládací prvek, je v Microsoft identity platform druhý objekt: aplikace Enterprise. Podnikové aplikace se také označují jako instanční objekty.

Pro aplikace s uživateli v jiných tenantech nebo jiných uživatelských účtech

Jak je znázorněno v následujícím diagramu na příkladu dvou tenantů (pro fiktivní organizace, Adatum a Contoso), podporované typy účtů zahrnují možnost Účty v libovolném adresáři organizace pro aplikaci s více tenanty, abyste mohli povolit uživatelům adresáře organizace. Jinými slovy, umožníte uživateli přihlásit se k vaší aplikaci pomocí své nativní identity z libovolného Azure AD. Instanční objekt se v tenantovi automaticky vytvoří, když se v aplikaci ověří první uživatel z tenanta.

Animovaný obrázek GIF zobrazuje dva diagramy s pohybovým přechodem mezi prvním a druhým diagramem. Název prvního diagramu: Instanční objekt se automaticky vytvoří v tenantovi, když se první uživatel z tenanta ověří v aplikaci. Pod prvním názvem diagramu vlevo jsou dvě odrážky: Pouze jedna registrace aplikace nebo objekt aplikace. Podniková aplikace, instanční objekt, v každém tenantovi, který uživateli umožňuje přihlásit se k aplikaci. Nalevo od odrážek obrazec mraku představuje tenanta Adatum, kde Adatum je název fiktivní organizace. Uvnitř obrazce cloud tenanta Adatum ikona představuje aplikaci a další ikona představuje Adatum SP. Šipka připojí ikonu aplikace k ikoně SP. Druhý název diagramu: Správce tenanta řídí, jak aplikace funguje v tenantovi s aplikací Enterprise pro danou aplikaci. Pod druhým názvem diagramu vlevo je obrazec cloudu, který představuje tenanta Adatum, kde Adatum je název fiktivní organizace. Napravo od obrazce mraku Adatum jiný obrazec cloudu představuje tenanta Contoso, kde Contoso je název fiktivní organizace. Uvnitř obrazce cloudu Contoso představuje ikona Contoso SP. Šipka propojí aplikaci Adatum uvnitř obrazce cloudu Adatum s objektem Contoso SP uvnitř obrazce cloudu Contoso.

Existuje pouze jeden objekt registrace aplikace nebo aplikace. Podniková aplikace nebo instanční objekt (SP) však v každém tenantovi umožňuje uživatelům přihlásit se k aplikaci. Správce tenanta může řídit, jak aplikace funguje v jeho tenantovi.

Aspekty víceklientských aplikací

Víceklientské aplikace přihlašují uživatele z domovského tenanta uživatele, když aplikace používá společný koncový bod nebo koncový bod organizace. Aplikace má jednu registraci aplikace, jak je znázorněno na následujícím diagramu. V tomto příkladu je aplikace zaregistrovaná v tenantovi Adatum. Uživatel A z Adatum a uživatel B ze společnosti Contoso se můžou přihlásit k aplikaci s očekáváním, že uživatel A z Adatum bude přistupovat k datům Adatum a uživatel B ze společnosti Contoso bude přistupovat k datům společnosti Contoso.

Název diagramu: Víceklientová aplikace vs. externí identity, označované také jako B 2 B. Vlevo se nad budovou zobrazí "Adatum", které představuje organizaci Adatum, kde Adatum je název fiktivní organizace. Na pravé straně se nad budovou zobrazí text Contoso, který představuje organizaci Contoso, kde contoso je název fiktivní organizace. Napravo od budovy Adatum je pole s názvem Registrace aplikace Adatum. Obsahuje ikonu, která představuje data Adatum na levé straně, a ikonu, která představuje data Contoso na pravé straně. Šipka propojí budovu Adatum s polem Registrace aplikace Adatum. Uvnitř budovy Adatum představuje kruh uživatele A. Šipka připojí uživatele A k poli Registrace aplikace Adatum. Uvnitř budovy Contoso představuje kruh uživatele B. Šipka připojí uživatele B k poli Registrace aplikace Adatum. Text v dolní části diagramu mezi dvěma budovami: Aplikace s více tenanty K přihlášení se používá společný koncový bod. Není potřeba žádná pozvánka ani externí účet.

Jako vývojáři je vaší zodpovědností uchovávat informace o tenantovi odděleně. Pokud jsou například data Společnosti Contoso z Microsoft Graphu, uživatel B z Contoso uvidí jenom data Microsoft Graphu společnosti Contoso. Uživatel B ze společnosti Contoso nemá možnost přistupovat k datům Microsoft Graphu v tenantovi Adatum, protože Microsoft 365 má skutečné oddělení dat.

Ve výše uvedeném diagramu se uživatel B ze společnosti Contoso může přihlásit k aplikaci a může přistupovat k datům společnosti Contoso ve vaší aplikaci. Vaše aplikace může používat naše společné koncové body (nebo koncové body organizace), takže se uživatel přihlašuje nativně ke svému tenantovi a nevyžaduje žádný proces pozvání. Uživatel může aplikaci spustit a přihlásit se k ní a bude fungovat poté, co správce uživatele nebo tenanta udělí souhlas.

Spolupráce s externími uživateli

Pokud podniky chtějí uživatelům, kteří nejsou členy podniku, povolit přístup k datům z podniku, používají funkci Azure AD B2B (Business to Business). Jak je znázorněno na následujícím diagramu, podniky můžou pozvat uživatele, aby se stali uživateli typu host ve svém tenantovi. Jakmile uživatel pozvánku přijme, bude mít přístup k datům, která pozvaný tenant chrání. Uživatel v tenantovi nevytvoří samostatné přihlašovací údaje.

Název diagramu: Víceklientová aplikace vs. externí identity, označované také jako B 2 B. Na levé straně se nad budovou zobrazí objekt Adatum, který představuje organizaci Adatum. Na pravé straně se nad budovou zobrazí text Contoso, který představuje organizaci Contoso. Uvnitř budovy Contoso je kruh, který představuje uživatele B. Napravo od budovy Adatum je pole obsahující ikonu představující data Adatum a registraci aplikace. Šipka propojí budovu Adatum s datovým a registračním polem. Uvnitř budovy Adatum představuje kruh uživatele A. Šipka připojí uživatele A k datovému a registračnímu poli. Menší kruh uvnitř budovy Adatum se spojuje se šipkou uživatele B a další šipkou k datovému a registračnímu poli. Text v dolní části diagramu mezi dvěma budovami: Externí identity Přihlaste se pomocí koncového bodu Adatum. Nelze použít společný koncový bod. Vyžaduje se pozvánka nebo externí účet.

Uživatelé typu host se ověřují přihlášením ke svému domovskému tenantovi, osobnímu účtu Microsoft nebo jinému účtu IDP. Hosté se také můžou ověřit pomocí jednorázového hesla pomocí libovolného e-mailu. Po ověření hostů poskytuje Azure AD zvoucí tenanta token pro přístup k datům zvaní tenanta.

Jako vývojář mějte na paměti tyto aspekty, když vaše aplikace podporuje uživatele typu host:

• Při přihlašování uživatele typu host musíte použít koncový bod specifický pro tenanta. Nemůžete použít běžné koncové body, koncové body organizace ani koncové body uživatelů.
• Identita uživatele typu host se liší od identity uživatele v jeho domovském tenantovi nebo jiném IDP. Deklarace oid identity v tokenu pro uživatele typu host se bude lišit od stejné osoby v jeho domovském oid tenantovi.

Další kroky

• Jak a proč se aplikace přidávají do Azure AD vysvětluje, jak objekty aplikací popisují aplikaci, aby Azure AD.
• Osvědčené postupy zabezpečení pro vlastnosti aplikace v Azure Active Directory se týkají vlastností, jako jsou identifikátor URI pro přesměrování, přístupové tokeny, certifikáty a tajné kódy, identifikátor URI ID aplikace a vlastnictví aplikace.
• Vytváření aplikací s nulová důvěra (Zero Trust) přístupem k identitě poskytuje přehled o oprávněních a osvědčených postupech přístupu.
• Získání autorizace pro přístup k prostředkům vám pomůže pochopit, jak nejlépe zajistit nulová důvěra (Zero Trust) při získávání přístupových oprávnění k prostředkům pro vaši aplikaci.
• Vývoj strategie delegovaných oprávnění vám pomůže implementovat nejlepší přístup ke správě oprávnění ve vaší aplikaci a vývoj s využitím nulová důvěra (Zero Trust) principů.
• Vývoj strategie oprávnění aplikací vám pomůže rozhodnout se o přístupu ke správě přihlašovacích údajů pomocí oprávnění aplikace.