Typy identit a účtů pro jednoklientové a víceklientských aplikací

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 Microsoft Entra můžete nakonfigurovat, aby byla jedna tenantka nebo víceklientka. 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é umožňuje 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 registrovat 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ásit se k víceklientové aplikaci. 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 ve vašem 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 víceklientové aplikaci, použijte 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 jsme popsali dříve.

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 k ID Microsoft Entra ID zákazníka nebo libovolnému zprostředkovateli identity, který podporuje JAZYK SAML (Security Assertion Markup Language) k 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, kterou skupinu povolí aplikaci 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.

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 víceklientských aplikací, abyste mohli uživatelům adresáře organizace povolit. Jinými slovy, umožníte uživateli přihlásit se k vaší 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. Název druhého diagramu: Správce tenanta určuje, jak aplikace funguje ve svém tenantovi s aplikací Enterprise pro danou aplikaci.

Existuje pouze jedna registrace aplikace nebo objekt aplikace. V každém tenantovi je ale aplikace Enterprise nebo instanční objekt( SP), který uživatelům umožňuje 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ávaným uživatelem A z Adatum přistupuje k datům Adatum a uživatel B z Contosa přistupuje k datům společnosti Contoso.

Název diagramu: Víceklientová aplikace vs. Externí identity, označovaná také jako B 2 B.

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 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 vaší aplikaci a funguje 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, která tenant pozvání chrá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.

Uživatelé typu host se ověřují přihlášením ke svému domácímu tenantovi, osobnímu účtu Microsoft nebo jinému účtu Zprostředkovatele identity (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 liší 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í přístupu 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).
• Strategie vytváření oprávnění aplikací vám pomůže rozhodnout se o přístupu k oprávněním aplikace ke správě přihlašovacích údajů.