Sdílet prostřednictvím

Přístupy k architektuře pro identitu ve víceklientských řešeních

  • Článek

Téměř všechna víceklientová řešení vyžadují systém identit. V tomto článku probereme společné komponenty identity, včetně ověřování i autorizace, a probereme, jak se tyto komponenty dají použít ve víceklientských řešeních.

Poznámka:

Než začnete sestavovat systém identit pro víceklientské řešení, projděte si aspekty architektury pro víceklientské řešení a přečtěte si další informace o klíčových požadavcích a rozhodnutích, které potřebujete udělat.

Ověřování

Ověřování je proces, pomocí kterého je vytvořena identita uživatele. Při vytváření víceklientského řešení existují zvláštní aspekty a přístupy pro několik aspektů procesu ověřování.

Federace

Možná budete muset federovat s jinými zprostředkovateli identity (IDP). Federaci je možné použít k povolení následujících scénářů:

  • Přihlášení k sociální síti, například tím, že uživatelům umožníte používat svůj účet Google, Facebook, GitHub nebo osobní účet Microsoft.
  • Adresáře specifické pro tenanty, například povolením tenantů federovat vaši aplikaci s vlastními zprostředkovateli identity, aby nemuseli spravovat účty na více místech.

Obecné informace o federaci najdete v modelu federované identity.

Pokud se rozhodnete podporovat zprostředkovatele identity specifické pro tenanta, ujistěte se, které služby a protokoly potřebujete podporovat. Budete například podporovat protokol OpenID Connect a protokol SAML (Security Assertion Markup Language)? Nebo budete podporovat jenom federaci s instancemi Microsoft Entra?

Při implementaci libovolného zprostředkovatele identity zvažte jakékoli škálování a omezení, která by mohla platit. Pokud například jako vlastního zprostředkovatele identity používáte Azure Active Directory (Azure AD) B2C, budete možná muset nasadit vlastní zásady pro federaci s určitými typy zprostředkovatelů identity tenanta. Azure AD B2C omezuje počet vlastních zásad , které můžete nasadit, což může omezit počet zprostředkovatelů identity specifických pro tenanta, se kterými se můžete federovat.

Můžete také zvážit poskytnutí federace jako funkce, která se vztahuje jenom na zákazníky na vyšší úrovni produktu.

Jednotné přihlášení

Funkce jednotného přihlašování umožňují uživatelům bezproblémově přepínat mezi aplikacemi, aniž by se v každém okamžiku zobrazovaly výzvy k opětovnému ověření.

Když uživatelé navštíví aplikaci, aplikace je přesměruje na zprostředkovatele identity. Pokud poskytovatel identity uvidí, že má existující relaci, vydá nový token, aniž by uživatelé museli komunikovat s procesem přihlášení. Model federované identity podporuje prostředí jednotného přihlašování tím, že uživatelům umožňuje používat jednu identitu napříč více aplikacemi.

V řešení s více tenanty můžete také povolit jinou formu jednotného přihlašování. Pokud mají uživatelé oprávnění pracovat s daty pro více tenantů, může být potřeba zajistit bezproblémové prostředí, když uživatelé změní jejich kontext z jednoho tenanta na jiný. Zvažte, jestli potřebujete podporovat bezproblémové přechody mezi tenanty, a pokud ano, jestli váš poskytovatel identity potřebuje znovu vytvořit tokeny s konkrétními deklaracemi identity. Uživatel, který se přihlásil k webu Azure Portal, může například přepínat mezi různými adresáři Microsoft Entra, což způsobí opětovné ověření a znovu ho vyvolá z nově vybrané instance Microsoft Entra.

Vyhodnocení rizik přihlašování

Moderní platformy identit podporují vyhodnocování rizik během procesu přihlašování. Pokud se například uživatel přihlásí z neobvyklého umístění nebo zařízení, může ověřovací systém vyžadovat další kontroly identit, jako je vícefaktorové ověřování (MFA), než umožní pokračovat v žádosti o přihlášení.

Zvažte, jestli vaši tenanti můžou mít různé zásady rizik, které je potřeba použít během procesu ověřování. Pokud máte například některé tenanty v vysoce regulovaných odvětvích, můžou mít různé rizikové profily a požadavky na tenanty, kteří pracují v méně regulovaných prostředích. Nebo se můžete rozhodnout povolit tenantům na vyšších cenových úrovních zadat více omezující zásady přihlašování než tenanti, kteří si kupují nižší úroveň vaší služby.

Pokud potřebujete podporovat různé zásady rizik pro každého tenanta, musí váš ověřovací systém vědět, ke kterému tenantovi se uživatel přihlašuje, aby mohl použít správné zásady.

Pokud váš zprostředkovatele identity tyto funkce zahrnuje, zvažte použití nativních funkcí vyhodnocení rizik přihlašování zprostředkovatele identity. Tyto funkce můžou být složité a náchylné k chybám, aby se implementovaly sami.

Případně pokud federujete vlastní zprostředkovatele identity tenantů, můžete použít vlastní rizikové zásady pro zmírnění rizik přihlašování a můžou řídit zásady a ovládací prvky, které by se měly vynucovat. Je ale důležité se vyhnout neúmyslnému přidání zbytečné zátěže uživateli, například vyžadováním dvou výzev vícefaktorového ověřování – jednoho od zprostředkovatele domovské identity uživatele a jednoho z vašich vlastních. Ujistěte se, že rozumíte tomu, jak federace komunikuje s jednotlivými zprostředkovateli identit tenantů a zásadami, které použili.

Zosobnění

Zosobnění umožňuje uživateli předpokládat identitu jiného uživatele bez použití přihlašovacích údajů daného uživatele.

Obecně platí, že zosobnění je nebezpečné a může být obtížné implementovat a řídit. V některých scénářích je ale zosobnění požadavkem. Pokud například provozujete software jako službu (SaaS), pracovníci helpdesku můžou potřebovat předpokládat identitu uživatele, aby se mohli přihlásit jako uživatel a vyřešit problém.

Pokud se rozhodnete implementovat zosobnění, zvažte, jak auditujete jeho použití. Ujistěte se, že vaše protokoly obsahují skutečného uživatele, který akci provedl, i identifikátor uživatele, kterého zosobněl.

Některé platformy identit podporují zosobnění, a to buď jako předdefinovaná funkce, nebo pomocí vlastního kódu. Například v Azure AD B2C můžete přidat vlastní deklaraci identity pro zosobněné ID uživatele nebo můžete nahradit deklaraci identity identifikátoru subjektu v tokenech, které jsou vystaveny.

Autorizace

Autorizace je proces určení toho, co uživatel může dělat.

Autorizační data se dají ukládat na několika místech, včetně následujících umístění:

  • Ve zprostředkovateli identity. Pokud jako zprostředkovatele identity používáte například ID Microsoft Entra, můžete k ukládání autorizačních informací použít funkce, jako jsou role aplikací a skupiny . Aplikace pak může použít deklarace identity přidružených tokenů k vynucení autorizačních pravidel.
  • Ve vaší aplikaci. Můžete vytvořit vlastní autorizační logiku a pak uložit informace o tom, co může každý uživatel dělat v databázi nebo podobném systému úložiště. Pak můžete navrhnout jemně odstupňované ovládací prvky pro autorizaci na základě role nebo na úrovni prostředků.

Ve většině víceklientských řešení jsou přiřazení rolí a oprávnění spravována tenantem nebo zákazníkem, nikoli vámi jako dodavatelem systému s více tenanty.

Další informace naleznete v tématu Role aplikace.

Přidání identity tenanta a informací o rolích do tokenů

Zvažte, která část nebo části vašeho řešení by měla provádět žádosti o autorizaci, včetně určení, jestli má uživatel povoleno pracovat s daty z konkrétního tenanta.

Běžným přístupem je, že váš systém identit vloží deklaraci identity identifikátoru tenanta do tokenu. Tento přístup umožňuje vaší aplikaci zkontrolovat deklaraci identity a ověřit, že uživatelé pracují s tenantem, ke kterému mají povolený přístup. Pokud používáte model zabezpečení na základě role, můžete se rozhodnout token rozšířit o informace o roli, kterou uživatel má v rámci tenanta.

Pokud ale má jeden uživatel povolený přístup k více tenantům, možná budete potřebovat způsob, jak uživatelům signalizovat, se kterým tenantem budou během procesu přihlášení pracovat. Jakmile vyberou svého aktivního tenanta, může zprostředkovatele identity zahrnout správnou deklaraci identity identifikátoru tenanta a roli pro daného tenanta v rámci tokenu, který problémuje. Musíte také zvážit, jak můžou uživatelé přepínat mezi tenanty, což vyžaduje vydání nového tokenu.

Autorizace na základě aplikace

Alternativním přístupem je, aby systém identit byl nezávislý na identifikátorech a rolích tenanta. Uživatelé se identifikují pomocí svých přihlašovacích údajů nebo vztahu federace a tokeny neobsahují deklaraci identifikátoru tenanta. Samostatný seznam nebo databáze obsahuje uživatele, kterým byl udělen přístup ke každému tenantovi. Potom může aplikační vrstva ověřit, jestli má zadaný uživatel mít povolený přístup k datům pro konkrétního tenanta, na základě vyhledávání v tomto seznamu.

Použití ID Microsoft Entra nebo Azure AD B2C

Microsoft poskytuje Microsoft Entra ID, Microsoft Entra Externí ID a Azure AD B2C, což jsou platformy spravovaných identit, které můžete použít ve vlastním víceklientských řešeních.

Řada víceklientských řešení je software jako služba (SaaS). Volba, jestli se má používat MICROSOFT Entra ID, Microsoft Entra Externí ID nebo Azure AD B2C, závisí částečně na tom, jak definujete tenanty nebo zákaznickou základnu.

  • Pokud jsou vaši tenanti nebo zákazníci organizace, můžou už používat ID Microsoft Entra pro služby, jako je Office 365, Microsoft Teams nebo pro vlastní prostředí Azure. Aplikaci s více tenanty můžete vytvořit ve svém vlastním adresáři Microsoft Entra, aby bylo řešení dostupné pro ostatní adresáře Microsoft Entra. Řešení můžete dokonce vypsat na Azure Marketplace a snadno ho zpřístupnit organizacím, které používají ID Microsoft Entra.
  • Pokud vaši tenanti nebo zákazníci nepoužívají ID Microsoft Entra nebo pokud nejsou jednotlivci, zvažte použití Microsoft Entra Externí ID nebo Azure AD B2C. Microsoft Entra Externí ID i Azure AD B2C poskytují sadu funkcí pro řízení způsobu registrace a přihlašování uživatelů. Přístup k řešení můžete například omezit jenom na uživatele, které jste už pozvali, nebo můžete povolit samoobslužnou registraci. Pomocí vlastních zásad v Azure AD B2C můžete plně řídit, jak uživatelé komunikují s platformou identity. Můžete použít vlastní branding a federovat Azure AD B2C s vlastním tenantem Microsoft Entra, abyste svým zaměstnancům umožnili přihlášení. Azure AD B2C také umožňuje federaci s jinými zprostředkovateli identit.
  • Některá víceklientských řešení jsou určená pro obě výše uvedené situace. Někteří tenanti můžou mít vlastní tenanty Microsoft Entra a jiní ne. Pro tento scénář můžete také použít Azure AD B2C a pomocí vlastních zásad povolit přihlašování uživatelů z adresáře Microsoft Entra tenanta. Pokud ale k vytvoření federace mezi tenanty používáte vlastní zásady, ujistěte se, že zvažujete omezení počtu vlastních zásad , které může používat jeden adresář Azure AD B2C.

Další informace najdete v tématu Důležité informace o používání Azure Active Directory B2C v architektuře s více tenanty.

Antipatterny, aby se zabránilo

Sestavení nebo spuštění vlastního systému identit

Vytvoření moderní platformy identit je složité. Existuje řada protokolů a standardů, které je možné podporovat, a je snadné nesprávně implementovat protokol a vystavit ohrožení zabezpečení. Standardy a protokoly se mění a také potřebujete průběžně aktualizovat systém identit, aby se zmírňovaly útoky a podporovaly nedávné funkce zabezpečení. Je také důležité zajistit odolnost systému identit, protože případné výpadky můžou mít vážné důsledky pro zbytek vašeho řešení. Ve většině situací navíc implementace zprostředkovatele identity nepřidá výhodu pro firmu a je to jednoduše nezbytná součást implementace víceklientské služby. Je lepší místo toho použít specializovaný systém identit, který je sestavený, provozovaný a zabezpečený odborníky.

Při spuštění vlastního systému identit musíte uložit hodnoty hash hesel nebo jiné formy přihlašovacích údajů, které se stanou lákavým cílem útočníků. I hashování a slaňování hesel je často nedostatečná ochrana, protože výpočetní výkon, který je k dispozici útočníkům, může zneškodnit tyto formy přihlašovacích údajů.

Při spuštění systému identit zodpovídáte také za generování a distribuci kódů vícefaktorového ověřování nebo jednorázového hesla (OTP). Tyto požadavky pak znamenají, že potřebujete mechanismus distribuce těchto kódů pomocí SMS nebo e-mailu. Kromě toho zodpovídáte za detekci cílených i útoků hrubou silou, omezování pokusů o přihlášení, auditování atd.

Místo sestavování nebo spouštění vlastního systému identit je vhodné použít službu nebo komponentu mimo plán. Zvažte například použití Microsoft Entra ID nebo Azure AD B2C, což jsou platformy spravovaných identit. Dodavatelé platformy spravovaných identit zodpovídají za provoz infrastruktury pro své platformy a obvykle za podporu aktuálních standardů identit a ověřování.

Nepodařilo se vzít v úvahu požadavky vašich tenantů

Tenanti často mají silné názory na to, jak by se měla identita spravovat pro řešení, která používají. Mnoho podnikových zákazníků například vyžaduje federaci s vlastními zprostředkovateli identit, aby bylo možné povolit jednotné přihlašování a vyhnout se správě více sad přihlašovacích údajů. Jiní tenanti můžou vyžadovat vícefaktorové ověřování nebo jiné formy ochrany v rámci přihlašovacích procesů. Pokud jste tyto požadavky nenavrhovali, může být později náročné je zpětně přizpůsobit.

Než dokončíte návrh systému identit, ujistěte se, že rozumíte požadavkům vašich tenantů na identitu. Projděte si aspekty architektury pro identitu ve víceklientské řešení a seznamte se s některými konkrétními požadavky, které se často objevují.

Nafouknutí uživatelů a tenantů

Je důležité jasně zvážit, jak vaše řešení definuje uživatele a tenanta. V mnoha situacích může být vztah složitý. Tenant může například obsahovat více uživatelů a jeden uživatel se může připojit k více tenantům.

Ujistěte se, že máte jasný proces sledování kontextu tenanta v rámci vaší aplikace a požadavků. V některých situacích může tento proces vyžadovat zahrnutí identifikátoru tenanta do každého přístupového tokenu a ověření identifikátoru tenanta na každém požadavku. V jiných situacích uložíte informace o autorizaci tenanta odděleně od identit uživatelů a použijete složitější systém autorizace ke správě uživatelů, kteří můžou provádět operace, se kterými tenanty.

Sledování kontextu tenanta uživatele nebo tokenu se vztahuje na jakýkoli model tenanta, protože identita uživatele má vždy kontext tenanta v rámci víceklientských řešení. Je dokonce vhodné sledovat kontext tenanta, když nasadíte nezávislé razítka pro jednoho tenanta, což budoucí testování základu kódu pro jiné formy víceklientské architektury.

Přifouknutí role a autorizace prostředků

Je důležité vybrat vhodný autorizační model pro vaše řešení. Přístupy k zabezpečení na základě rolí se dají jednoduše implementovat, ale autorizace založená na prostředcích poskytuje jemněji odstupňované řízení. Zvažte požadavky vašich tenantů a to, jestli vaši tenanti potřebují autorizovat některé uživatele, aby měli přístup ke konkrétním částem vašeho řešení, a ne k jiným částem.

Selhání zápisu protokolů auditu

Protokoly auditu jsou důležitým nástrojem pro pochopení vašeho prostředí a způsobu implementace systému uživateli. Auditováním každé události související s identitou můžete často určit, jestli je váš systém identit napadený, a můžete zkontrolovat, jak se systém používá. Ujistěte se, že do systému identit zapisujete a ukládáte protokoly auditu. Zvažte, jestli by se protokoly auditu identit vašeho řešení měly zpřístupnit tenantům ke kontrole.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

Další přispěvatelé:

Další kroky

Projděte si aspekty architektury pro identitu ve víceklientských řešeních.