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

V tomto článku se dozvíte, jak můžete jako vývojář zvolit, jestli vaše aplikace umožňuje jenom uživatelům z vašeho tenanta Azure Active Directory (Azure AD), libovolnému Azure AD tenantovi nebo uživatelům s osobními účty Microsoft tím, že aplikaci nakonfigurujete tak, aby byla během registrace aplikace v Azure jednoklientská nebo víceklientská a zajistila se nulová důvěra (Zero Trust) princip nejnižšího přístupu k oprávněním, 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, Hotmailu, Live, Skypu, Xboxu atd.

  • Externí identity v Azure AD pro partnery (uživatelé mimo vaši organizaci)

  • Azure AD 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 a které se přihlašují k odběru služby Microsoft Dynamics 365 Fraud Protection se službou Azure Active Directory B2C, mohou posoudit, jestli se pokusí vytvořit nové účty a pokusy o přihlášení k ekosystému klienta jsou podvodné.

Požadovaná část registrace aplikace v Azure AD je výběr podporovaných typů účtů. It specialisté v rolích správce se rozhodnou, kdo může vyjádřit souhlas s aplikacemi ve svém tenantovi, ale 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 tyto podrobnosti sdělit prostřednictvím jiného mechanismu.

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

  • Účty jenom v tomto organizačním adresáři (jenom O365 – jeden tenant)

  • Účty v libovolném adresáři organizace (libovolný adresář Azure AD – víceklient)

  • Účty v libovolném adresáři organizace (jakýkoli adresář Azure AD – víceklient) a osobní účty Microsoft (např. Skype, Xbox)

  • Pouze osobní účty Microsoft

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

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

Účty jenom v libovolném organizačním adresáři – 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 aplikaci s více tenanty. Pokud chcete povolit pouze uživatele z konkrétních tenantů, vyfiltrujete tyto uživatele ve svém kódu tak, že zkontrolujete, jestli je v seznamu povolených tenantů deklarace identity v id_token . Aplikace může používat 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ář Azure AD – 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 Azure AD tenanta nebo účtu příjemce. Stejné filtrování tenantů a využití koncových bodů se vztahuje na 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.

Aplikace orientované na zákazníky

Při vytváření ř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 firemním prostředkům vaší společnosti. Pro splnění této potřeby microsoft nabízí zákazníkům Azure AD Business (B2C).

Azure Active Directory B2C nabízí identitu B2C jako službu. Kromě toho, že uživatelům aplikace povolíte, aby měli uživatelské jméno a heslo jenom pro vaši aplikaci, vám B2C umožňuje podporovat zákazníky pomocí sociální identity, kterou jim umožní přinést, aby si nemuseli pamatovat více hesel. Můžete například uživatelům povolit, aby používali svoje ID Facebooku nebo Twitteru. Podnikové zákazníky můžete také podporovat tak, že federujete adresář Azure AD B2C do Azure AD vašich zákazníků (nebo libovolného zprostředkovatele identity (IDP), který podporuje SAML) pro 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. B2C umožňuje zákazníkům 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.

Vy, jako vývojář, definujete v registraci vaší aplikace, kdo budete moct přihlásit k aplikaci, nemáte konečné slovo o tom, jestli se ke své aplikaci může přihlásit některý konkrétní uživatel nebo uživatelé z konkrétního tenanta. Poslední řekněme, že 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 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 pro aplikaci nebo určit, kterou skupinu povolí aplikaci používat. Pokud chcete správcům tenanta povolit, aby tento ovládací prvek měli, existuje 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 pomocí příkladu dvou tenantů (pro fiktivní organizace, Adatum a Contoso), podporované typy účtů zahrnují účty do 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 Azure AD. Instanční objekt se automaticky vytvoří v tenantovi, když se první uživatel z tenanta ověří v aplikaci.

Diagram znázorňuje víceklientní aplikaci, která umožňuje uživatelům adresáře organizace

V každém tenantovi existuje jenom jedna registrace aplikace nebo objekt aplikace, ale v každém tenantovi existuje aplikace Enterprise nebo instanční objekt (SP), který uživateli umožňuje přihlásit se k aplikaci. Správce tenanta může řídit, jak aplikace funguje ve svém tenantovi s aplikací Enterprise pro danou aplikaci.

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 na následujícím diagramu. V tomto příkladu je aplikace zaregistrovaná v tenantovi Adatum. Uživatel A od Adatum a Uživatele B od společnosti Contoso se může přihlásit k aplikaci s očekávaným uživatelem A z Adatum přistupovat k datům Adatum a uživatel B ze společnosti Contoso bude přistupovat k datům společnosti Contoso.

Diagram znázorňuje víceklientské aplikace, kteří se přihlašují uživatele z domácího tenanta uživatele, když aplikace používá běžný koncový bod organizace nebo koncový bod organizace

Jako vývojář zodpovídáte za oddělení informací o tenantovi. Pokud jsou například data Společnosti Contoso z Microsoft Graphu, uživatel B od společnosti Contoso uvidí jenom data Microsoft Graphu společnosti Contoso. Uživatel B od 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řihlásí nativně ke svému tenantovi, ať je kdekoli, a nevyžaduje se žádný proces pozvání. Uživatel může jednoduše spustit a přihlásit se k aplikaci a bude fungovat po udělení souhlasu správce uživatele nebo 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, umožní to funkce Azure AD Business to Business (B2B). Jak je znázorněno na následujícím diagramu, můžou podniky pozvat uživatele, aby se stali uživateli typu host ve svém tenantovi. Jakmile uživatel pozvánku přijme, může získat přístup k datům, která má pozvaný tenant chráněný. Uživatel v tenantovi nevytvoří samostatné přihlašovací údaje.

Diagram znázorňuje podniky, které zvou uživatele typu host ke svému tenantovi

Když se uživatel typu host potřebuje ověřit, přihlásí se ke svému domácímu tenantovi, k osobnímu účtu Microsoft, účtu z jiného IDP nebo pomocí jednorázového hesla pomocí libovolného e-mailového účtu. Jakmile se ověří pomocí svého IDP, Azure AD pozvaných tenantů poskytne aplikaci token, který je identifikuje jako uživatele typu host v tenantovi. Tento uživatel typu host pak může získat přístup k datům v 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 konkrétního tenanta. Nemůžete použít běžné koncové body, organizace ani koncové body příjemce.

  • Identita uživatele typu host se liší od identity uživatele v jeho domovském tenantovi nebo jiném protokolu IDP. To znamená, že oid deklarace identity v tokenu pro uživatele typu host se bude lišit od id stejného jednotlivce ve svém domovském tenantovi.

Další kroky