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

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

Platforma Microsoft Identity Platform poskytuje podporu pro konkrétní typy identit:

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

Požadovaná část registrace aplikace v Microsoft Entra ID je váš výběr podporovaných typů účtů. I když IT specialisté v rolích správce rozhodují, kdo může udělit souhlas s aplikacemi ve svém tenantovi, vy jako vývojář určíte, kdo může aplikaci používat na základě typu účtu. Pokud vám tenant neumožňuje zaregistrovat aplikaci v Microsoft Entra ID, správci vám poskytnou způsob, jak tyto podrobnosti sdělit prostřednictvím jiného mechanismu.

Při registraci aplikace si můžete vybrat z následujících podporovaných možností 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

Účty pouze v tomto organizačním adresáři – jeden tenant

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

Účty pouze v libovolném organizačním adresáři – víceklient

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

Účty v libovolném účtu organizace a osobních účtech Microsoft

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

Pouze osobní účty Microsoft

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

Zákaznické aplikace

Když vytvoříte řešení na platformě 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 firemním prostředkům vaší společnosti. Pro splnění této potřeby microsoft nabízí Microsoft Entra Business zákazníkům (B2C).

Azure AD B2C poskytuje identitu mezi firmami 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, aby se omezila hesla. Podnikoví zákazníci můžete podporovat tak, že federujete adresář Azure AD B2C s ID Microsoft Entra ID microsoftu (nebo libovolného zprostředkovatele identity, který podporuje SAML) na OpenID Připojení. Na rozdíl od víceklientské aplikace vaše aplikace nepoužívá firemní adresář zákazníka, ve kterém chrání firemní prostředky. Vaši zákazníci mají přístup k vaší službě nebo možnostem bez udělení přístupu k firemním prostředkům vaší aplikace.

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

I když definujete registraci aplikace, která se může přihlásit k vaší aplikaci, konečné sdělení pochází od jednotlivých uživatelů nebo správců domovského tenanta uživatele. Správci tenantů často chtějí mít větší kontrolu nad aplikací, než jen kdo se může přihlásit. Mohou například chtít použít zásadu podmíněného přístupu pro aplikaci nebo určit skupinu, kterou aplikaci povolí používat. Pokud chcete správcům tenantů povolit, aby tento ovládací prvek měli, existuje druhý objekt na platformě Microsoft Identity Platform: 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 s použitím příkladu dvou tenantů (pro fiktivní organizace, Adatum a Contoso), podporované typy účtů zahrnují účty v libovolné možnosti adresáře organizace pro aplikaci s více tenanty, abyste mohli uživatelům adresáře organizace povolit. Jinými slovy, umožníte uživateli přihlásit se k aplikaci pomocí své nativní identity z libovolného ID Microsoft Entra. Instanční objekt se automaticky vytvoří v tenantovi, když se první uživatel z tenanta ověří v aplikaci.

Animovaný obrázek GIF ukazuje dva diagramy s přechodem pohybu mezi prvním diagramem a druhým diagramem. První název diagramu: Instanční objekt se automaticky vytvoří v tenantovi, když se první uživatel z tenanta ověří v aplikaci. Pod názvem prvního diagramu vlevo jsou dva 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 představuje cloudový obrazec tenanta Adatum, kde Adatum je název fiktivní organizace. Uvnitř cloudového obrazce tenanta Adatum představuje ikona Aplikaci a další ikona představuje Adatum SP. Šipka připojí ikonu aplikace k ikoně SP. Název druhého diagramu: Správce tenanta určuje, jak aplikace funguje ve svém tenantovi s aplikací Enterprise pro danou aplikaci. Pod názvem druhého diagramu na levé straně představuje cloudový obrazec tenanta Adatum, kde Adatum je název fiktivní organizace. Napravo od tvaru cloudu Adatum představuje jiný cloudový obrazec tenanta Contoso, kde contoso je název fiktivní organizace. Uvnitř cloudového obrazce Contoso představuje ikona contoso SP. Šipka spojuje aplikaci Adatum uvnitř cloudového obrazce Adatum s objektem CONTOSO SP uvnitř cloudového obrazce Contoso.

Existuje pouze jedna registrace aplikace nebo objekt 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 fungování aplikace ve svém tenantovi.

Aspekty víceklientských aplikací

Víceklientské aplikace se 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 v následujícím diagramu. V tomto příkladu je aplikace zaregistrovaná v tenantovi Adatum. Uživatel A z Adatumu i uživatele B ze společnosti Contoso se může 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. Na levé straně se nad budovou objeví "Adatum", která představuje organizaci Adatum, kde Adatum je název fiktivní organizace. Na pravé straně se nad budovou objeví "Contoso", která představuje organizaci Contoso, kde contoso je název fiktivní organizace. Napravo od budovy Adatum je pole s názvem Adatum App Registration. Obsahuje ikonu, která představuje data Adatum na levé straně a ikonu, která představuje data společnosti Contoso vpravo. Šipka spojuje 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 A. 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: Víceklientová aplikace Používá k přihlášení běžný koncový bod. Není potřeba žádný účet s pozvánkou nebo externím účtem.

Jako vývojář je vaší zodpovědností udržovat informace o tenantovi oddělené. Pokud jsou například data Společnosti Contoso z Microsoft Graphu, uživatel B ze společnosti 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 běžné koncové body (nebo koncové body organizace), aby se uživatel nativně přihlašuje ke svému tenantovi a nevyžaduje žádný proces pozvání. Uživatel může spustit a přihlásit se k aplikaci a bude fungovat po udělení souhlasu uživatele nebo správce tenanta.

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 Microsoft Entra Business to Business (B2B ). Jak je znázorněno v následujícím diagramu, mohou podniky 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 chráněným tenantem pozvání. Uživatel nevytvoří v tenantovi 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 objeví "Adatum", která představuje organizaci Adatum. Na pravé straně se nad budovou zobrazí "Contoso", která bude představovat organizaci Contoso. Uvnitř budovy Contoso je kruh, který představuje uživatele B. Napravo od budovy Adatum představuje pole obsahující ikonu Adatum Data a Registrace aplikace. Šipka spojuje budovu Adatum s daty a registračním polem. Uvnitř budovy Adatum představuje kruh uživatele A. Šipka připojí uživatele A k datům a poli registrace. Menší kruh uvnitř budovy Adatum se spojí se šipkou k uživateli B a další šipkou k datům a registračnímu poli. Text v dolní části diagramu mezi dvěma budovami: Externí identity Přihlaste se pomocí koncového bodu Adatum. Nejde použít běžný koncový bod. Je potřeba pozvání 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 zvaní ID Microsoft Entra tenanta token pro přístup k pozvání dat 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žívat běžné koncové body, organizace ani koncové body uživatelů.
• Identita uživatele typu host se liší od identity uživatele ve svém domovském tenantovi nebo jiném ZDP. Deklarace oid identity v tokenu pro uživatele typu host se bude lišit od identity stejného jednotlivce oid ve svém domovském tenantovi.

Další kroky

• Jak a proč jsou aplikace přidány do Microsoft Entra ID vysvětluje, jak objekty aplikace popisují aplikaci do Microsoft Entra ID.
• Osvědčené postupy zabezpečení pro vlastnosti aplikace v Microsoft Entra ID zahrnují vlastnosti, jako je identifikátor URI přesměrování, přístupové tokeny, certifikáty a tajné kódy, identifikátor URI aplikace a vlastnictví aplikace.
• Vytváření aplikací s přístupem k identitě nulová důvěra (Zero Trust) 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í oprávnění pro přístup 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í v aplikaci a vyvíjet pomocí principů nulová důvěra (Zero Trust).
• Vývoj strategie oprávnění aplikací vám pomůže při rozhodování o přístupu k oprávněním aplikace ke správě přihlašovacích údajů.