Sdílet prostřednictvím

Aspekty architektury pro identitu ve víceklientských řešeních

  • Článek

Identita je důležitým aspektem každého víceklientských řešení. Komponenty identit vaší aplikace zodpovídají za obě z těchto věcí:

  • Ověření, kdo je uživatel (ověřování).
  • Vynucení oprávnění uživatele v rámci oboru tenanta (autorizace)

Vaši zákazníci také můžou chtít autorizovat externí aplikace pro přístup ke svým datům nebo integrovat do vašeho řešení. Identita uživatele určuje, k jakým informacím získá uživatel nebo služba přístup. Je důležité zvážit požadavky vaší identity, abyste mohli izolovat aplikaci a data mezi tenanty.

Upozornění

Ověřovací a autorizační služby v rámci víceklientských a saaS aplikací obvykle poskytuje zprostředkovatel identity třetí strany (IDP). Zprostředkovatel identity je obvykle nedílnou součástí platformy identity jako služby (IDaaS).

Vytvoření vlastního zprostředkovatele identity je složité, nákladné a obtížné bezpečně sestavovat. Vytvoření vlastního zprostředkovatele identity je antipattern. Nedoporučujeme ho.

Před definováním strategie víceklientských identit byste měli nejprve zvážit požadavky vaší služby na vysokou úroveň identit, včetně následujících požadavků:

  • Použije se identita uživatelů nebo úloh pro přístup k jedné aplikaci nebo více aplikacím v rámci produktové řady? Například řada maloobchodních produktů může mít jak aplikaci typu point-of-sale, tak i aplikaci pro správu zásob, která sdílí stejné řešení identity.
  • Plánujete implementovat moderní ověřování a autorizaci, jako je OAuth2 a OpenID Connect?
  • Poskytuje vaše řešení ověřování pouze aplikacím založeným na uživatelském rozhraní? Nebo také poskytujete přístup rozhraní API ke svým tenantům a třetím stranám?
  • Budou muset tenanti federovat do vlastního zprostředkovatele identity a budou muset být pro každého tenanta podporováno více různých zprostředkovatelů identity? Můžete mít například tenanty s Microsoft Entra ID, Auth0 a Active Directory Federation Services (AD FS) (ADFS), kde se každý z nich chce federovat s vaším řešením. Musíte také zjistit, které federační protokoly zprostředkovatele identity tenantů budete podporovat, protože tyto protokoly ovlivňují požadavky vašeho vlastního zprostředkovatele identity.
  • Musí splnit konkrétní požadavky na dodržování předpisů, jako je GDPR?
  • Vyžadují vaše tenanty, aby se informace o identitě nacházely v konkrétní geografické oblasti?
  • Vyžadují uživatelé vašeho řešení přístup k datům z jednoho tenanta nebo z více tenantů ve vaší aplikaci? Potřebují možnost rychle přepínat mezi tenanty nebo zobrazit konsolidované informace z více tenantů? Například uživatelé, kteří se přihlásili k webu Azure Portal, můžou snadno přepínat mezi různými adresáři ID Microsoft Entra a předplatnými, ke kterým mají přístup.

Po vytvoření požadavků vysoké úrovně můžete začít plánovat konkrétnější podrobnosti a požadavky, jako jsou zdroje adresářů uživatelů a toky registrace nebo přihlašování.

Adresář identit

Aby bylo možné ověřit a autorizovat uživatele nebo službu s více tenanty, potřebuje místo pro ukládání informací o identitě. Adresář může obsahovat autoritativní záznamy pro každou identitu nebo může obsahovat odkazy na externí identity uložené v adresáři jiného zprostředkovatele identity.

Při návrhu systému identit pro víceklientských řešení je potřeba zvážit, které z následujících typů zprostředkovatele identity můžou vaši tenanti a zákazníci potřebovat:

  • Místní zprostředkovatel identity. Místní zprostředkovatel identity umožňuje uživatelům zaregistrovat se k této službě. Uživatelé zadají uživatelské jméno, e-mailovou adresu nebo identifikátor, například číslo karty programu Rewards. Poskytují také přihlašovací údaje, jako je heslo. Zprostředkovatele identity ukládá identifikátor uživatele i přihlašovací údaje.
  • Zprostředkovatel sociální identity. Zprostředkovatel sociální identity umožňuje uživatelům používat identitu, kterou mají na sociální síti nebo jiném poskytovateli veřejné identity, jako je Facebook, Google nebo osobní účet Microsoft.
  • Použijte adresář Microsoft Entra ID tenanta. Tenanti už můžou mít svůj vlastní adresář Microsoft Entra ID a můžou chtít, aby vaše řešení používalo svůj adresář jako zprostředkovatele identity pro přístup k vašemu řešení. Tento přístup je možný, když je vaše řešení vytvořené jako víceklientová aplikace Microsoft Entra.
  • Federace se zprostředkovatelem identity tenanta Tenanti můžou mít vlastní zprostředkovatele identity kromě Microsoft Entra ID a můžou chtít, aby vaše řešení s ním bylo federované. Federace umožňuje používat jednotné přihlašování (SSO) a umožňuje tenantům spravovat životní cyklus a zásady zabezpečení uživatelů nezávisle na vašem řešení.

Měli byste zvážit, jestli vaši tenanti potřebují podporovat více zprostředkovatelů identity. Můžete například potřebovat podporovat místní identity, sociální identity a federované identity v rámci jednoho tenanta. Tento požadavek je běžný, když společnosti používají řešení, které je pro své zaměstnance i pro dodavatele. Federování můžou používat pro přístup svých zaměstnanců k řešení a zároveň povolit přístup k dodavatelům nebo uživatelům typu host, kteří nemají účet v federovaném federovaném zprostředkovatele identity.

Ukládání informací o ověřování a autorizaci tenanta

Ve víceklientských řešeních je potřeba zvážit, kam uložit několik typů informací o identitě, včetně následujících typů:

  • Podrobnosti o uživatelských a servisních účtech, včetně jejich jmen a dalších informací, které vyžadují vaši tenanti.
  • Informace potřebné k bezpečnému ověření uživatelů, včetně informací, které jsou potřeba k poskytování vícefaktorového ověřování (MFA).
  • Informace specifické pro tenanta, jako jsou role tenanta a oprávnění. Tyto informace slouží k autorizaci.

Upozornění

Nedoporučujeme vytvářet ověřovací procesy sami. Moderní zprostředkovatele identity poskytují těmto ověřovacím službám pro vaši aplikaci a zahrnují také další důležité funkce, jako je vícefaktorové ověřování a podmíněný přístup. Vytvoření vlastního zprostředkovatele identity je antipattern. Nedoporučujeme ho.

Zvažte následující možnosti ukládání informací o identitě:

  • Uložte všechny informace o identitě a autorizaci v adresáři zprostředkovatele identity a sdílejte je mezi více tenanty.
  • Uložte přihlašovací údaje uživatele do adresáře zprostředkovatele identity a uložte autorizační informace do aplikační vrstvy spolu s informacemi o tenantovi.

Určení počtu identit pro uživatele

U víceklientských řešení je běžné, že uživatelům nebo identitám úloh umožní přístup k aplikacím a datům více tenantů. Zvažte, jestli se tento přístup vyžaduje pro vaše řešení. Pokud ano, měli byste zvážit následující otázky:

  • Měli byste pro každou osobu vytvořit jednu identitu uživatele nebo vytvořit samostatné identity pro každou kombinaci tenanta a uživatele?
    • Nejlepší je použít jednu identitu pro každou osobu, kdykoli je to možné. Je obtížné spravovat více uživatelských účtů, a to jak pro vás, jako dodavatele řešení, tak i pro vaše uživatele. Řada inteligentních ochrany před hrozbami, které nabízí moderní zprostředkovatele identity, se navíc spoléhá na každou osobu, která má jeden uživatelský účet.
    • V některých situacích ale může být nutné, aby uživatel měl více různých identit. Pokud například lidé používají váš systém pro pracovní i osobní účely, můžou chtít své uživatelské účty oddělit. Nebo pokud mají vaši tenanti přísné zákonné nebo geografické požadavky na úložiště dat, můžou vyžadovat, aby osoba měla více identit, aby mohla dodržovat předpisy nebo zákony.
  • Pokud používáte identity pro jednotlivé tenanty, vyhněte se ukládání přihlašovacích údajů několikrát. Uživatelé by měli mít svoje přihlašovací údaje uložené proti jedné identitě a měli byste použít funkce, jako jsou identity hosta, aby odkazovaly na stejné přihlašovací údaje uživatele ze záznamů identit více tenantů.

Udělení přístupu uživatelům k datům tenanta

Zvažte, jak budou uživatelé mapováni na tenanta. Během procesu registrace můžete například použít jedinečný kód pozvánky, který zadá při prvním přístupu k tenantovi. V některých řešeních můžete jako způsob identifikace tenanta, ke kterému patří, použít název domény registračních e-mailových adres uživatelů. Nebo můžete použít jiný atribut záznamu identity uživatele k namapování uživatele na tenanta. Pak byste měli mapování uložit na základě základních neměnných jedinečných identifikátorů pro tenanta i uživatele.

Pokud je vaše řešení navržené tak, aby k datům jednoho tenanta přistupoval jen jeden uživatel, zvažte následující rozhodnutí:

  • Jak zprostředkovatele identity zjistí, ke kterému tenantovi uživatel přistupuje?
  • Jak zprostředkovatele identity sdělí identifikátor tenanta aplikaci? Do tokenu se obvykle přidá deklarace identity identifikátoru tenanta.

Pokud musí mít jeden uživatel udělený přístup k více tenantům, musíte zvážit následující rozhodnutí:

  • Jak vaše řešení identifikuje a uděluje oprávnění uživateli, který má přístup k více tenantům? Může být například uživatel správcem v trénovacím tenantovi a mít přístup jen pro čtení k produkčnímu tenantovi? Nebo můžete mít samostatné tenanty pro různá oddělení v organizaci, ale potřebujete udržovat konzistentní identity uživatelů ve všech tenantech?
  • Jak uživatel přepíná mezi tenanty?
  • Pokud používáte identity úloh, jak identita úlohy určuje tenanta, ke kterému potřebuje přístup?
  • Jsou v záznamu identity uživatele uložené informace specifické pro tenanty, které by mohly uniknout informacím mezi tenanty? Předpokládejme například, že se uživatel zaregistroval pomocí sociální identity a pak mu byl udělen přístup ke dvěma tenantům. Tenant A obohatil identitu uživatele o další informace. Má tenant B mít přístup k obohaceným informacím?

Proces registrace uživatele pro místní identity nebo sociální identity

Někteří tenanti můžou uživatelům umožnit, aby se zaregistrovali k identitě ve vašem řešení. Samoobslužná registrace se může vyžadovat, pokud nevyžadujete federaci u zprostředkovatele identity tenanta. Pokud je potřeba proces samoobslužné registrace, měli byste zvážit následující otázky:

  • Ze kterých zdrojů identit se uživatelé můžou zaregistrovat? Může například uživatel vytvořit místní identitu a také použít zprostředkovatele sociální identity?
  • Pokud jsou povolené jenom místní identity, budou povoleny jenom konkrétní e-mailové domény? Může například tenant určit, že se můžou zaregistrovat jenom uživatelé, kteří mají e-mailovou @contoso.com adresu?
  • Jaký je hlavní název uživatele (UPN), který by se měl použít k jedinečné identifikaci každé místní identity během procesu přihlašování? Například e-mailová adresa, uživatelské jméno, telefonní číslo a číslo karty programu Rewards jsou všechny běžné volby hlavních názvů uživatelů (UPN). Názvy UPN se ale můžou v průběhu času měnit. Pokud odkazujete na identitu v autorizačních pravidlech vaší aplikace nebo v protokolech auditu, je vhodné použít základní neměnný jedinečný identifikátor identity. Microsoft Entra ID poskytuje ID objektu (OID), což je neměnný identifikátor.
  • Bude se uživateli vyžadovat ověření hlavního názvu uživatele (UPN)? Pokud se například e-mailová adresa nebo telefonní číslo uživatele používá jako hlavní název uživatele (UPN), jak ověříte správnost informací?
  • Potřebují správci tenantů schvalovat registrace?
  • Vyžadují tenanti přihlašovací prostředí nebo adresu URL specifickou pro tenanta? Vyžadují například tenanti při registraci uživatelů značku? Vyžadují tenanti možnost zachytit žádost o registraci a provést další ověření, než bude pokračovat?

Přístup tenanta pro uživatele samoobslužné registrace

Když se uživatelé můžou zaregistrovat k identitě, obvykle je potřeba jim udělit přístup k tenantovi. Tok registrace může zahrnovat proces udělení přístupu nebo může být automatizovaný na základě informací o uživatelích, jako jsou jejich e-mailové adresy. Je důležité naplánovat tento proces a zvážit následující otázky:

  • Jak tok registrace určí, že má být uživateli udělen přístup ke konkrétnímu tenantovi?
  • Pokud by už uživatelé neměli mít přístup k tenantovi, vaše řešení automaticky odvolá přístup? Když například uživatelé opustí organizaci, musí existovat ruční nebo automatizovaný proces, který odebere jejich přístup z tenanta.
  • Potřebujete klientům poskytnout způsob, jak auditovat uživatele, kteří mají přístup ke svým tenantům a jejich oprávněním?

Automatizovaná správa životního cyklu účtů

Běžným požadavkem pro firemní nebo podnikové zákazníky řešení je sada funkcí, které jim umožňují automatizovat onboarding účtů a offboarding. Otevřené protokoly, například System for Cross-domain Identity Management (SCIM), poskytují standardní přístup k automatizaci. Tento automatizovaný proces obvykle zahrnuje nejen vytvoření a odebrání záznamů identit, ale také správu oprávnění tenanta. Při implementaci automatizované správy životního cyklu účtů ve víceklientských řešeních zvažte následující otázky:

  • Potřebují vaši zákazníci nakonfigurovat a spravovat automatizovaný proces životního cyklu na tenanta? Když je například uživatel onboardovaný, může být potřeba vytvořit identitu v rámci více tenantů ve vaší aplikaci, kde má každý tenant jinou sadu oprávnění.
  • Potřebujete implementovat SCIM, nebo můžete místo toho poskytnout federaci tenantů, abyste zachovali zdroj pravdy pro uživatele pod kontrolou tenanta místo správy místních uživatelů?

Proces ověřování uživatelů

Když se uživatel přihlásí k víceklientové aplikaci, váš systém identit uživatele ověří. Při plánování procesu ověřování byste měli zvážit následující otázky:

  • Potřebují vaši tenanti nakonfigurovat vlastní zásady vícefaktorového ověřování (MFA)? Pokud jsou například vaši tenanti v odvětví finančních služeb, musí implementovat přísné zásady vícefaktorového ověřování, zatímco malý online prodejce nemusí mít stejné požadavky.
  • Potřebují vaši tenanti nakonfigurovat vlastní pravidla podmíněného přístupu? Například různí tenanti můžou potřebovat blokovat pokusy o přihlášení z konkrétních geografických oblastí.
  • Potřebují vaši tenanti přizpůsobit proces přihlašování pro každého tenanta? Potřebujete například zobrazit logo zákazníka? Nebo musí být informace o každém uživateli extrahovány z jiného systému, například čísla odměn, a vrátit se zprostředkovateli identity, aby se přidal do profilu uživatele?
  • Potřebují vaši uživatelé zosobnit jiné uživatele? Člen týmu podpory může například chtít prošetřit problém, který má jiný uživatel, tím, že zosobní svůj uživatelský účet, aniž by se musel ověřovat jako uživatel.
  • Potřebují vaši uživatelé získat přístup k rozhraním API pro vaše řešení? Například uživatelé nebo aplikace třetích stran můžou potřebovat přímo volat vaše rozhraní API, aby vaše řešení rozšířili, aniž by uživatelské rozhraní poskytovalo tok ověřování.

Identity úloh

Ve většině řešení identita často představuje uživatele. Některé víceklientská systémy také umožňují, aby identity úloh používaly služby a aplikace, aby získaly přístup k prostředkům vaší aplikace. Například vaši tenanti můžou potřebovat přístup k rozhraní API, které poskytuje vaše řešení, aby mohli automatizovat některé úlohy správy.

Identity úloh jsou podobné identitám uživatelů, ale obvykle vyžadují různé metody ověřování, jako jsou klíče nebo certifikáty. Identity úloh nepoužívají vícefaktorové ověřování. Místo toho identity úloh obvykle vyžadují další kontrolní mechanismy zabezpečení, jako je pravidelné vracení klíčů a vypršení platnosti certifikátů.

Pokud vaši tenanti očekávají, že budou moct povolit přístup identit úloh k víceklientských řešení, měli byste zvážit následující otázky:

  • Jak se budou identity úloh vytvářet a spravovat v každém tenantovi?
  • Jak budou požadavky na identitu úloh vymezeny na tenanta?
  • Potřebujete omezit počet identit úloh vytvořených jednotlivými tenanty?
  • Potřebujete poskytnout řízení podmíněného přístupu pro identity úloh pro každého tenanta? Tenant může například chtít omezit identitu úlohy z ověření mimo konkrétní oblast.
  • Jaké bezpečnostní prvky poskytnete tenantům, aby byly identity úloh zabezpečené? Například automatizované řízení klíčů, vypršení platnosti klíče, vypršení platnosti certifikátu a monitorování rizik přihlašování jsou všechny metody snížení rizika, kdy může být identita úlohy zneužita.

Federování s zprostředkovatelem identity pro jednotné přihlašování

Tenanti, kteří už mají vlastní uživatelské adresáře, můžou chtít, aby vaše řešení federovaly do svých adresářů. Federace umožňuje vašemu řešení používat identity v jejich adresáři místo správy jiného adresáře s odlišnými identitami.

Federace je obzvláště důležitá v případě, že někteří tenanti chtějí zadat vlastní zásady identit nebo povolit prostředí jednotného přihlašování (SSO).

Pokud očekáváte, že se tenanti budou federovat s vaším řešením, měli byste zvážit následující otázky:

  • Jaký je proces konfigurace federace pro tenanta? Můžou si tenanti nakonfigurovat federaci sami, nebo vyžaduje proces ruční konfiguraci a údržbu vaším týmem?
  • Které federační protokoly budete podporovat?
  • Jaké procesy se používají, aby se zajistilo, že federace není chybně nakonfigurovaná, aby bylo možné udělit přístup k jinému tenantovi?
  • Bude ve vašem řešení potřeba zprostředkovatele identity jednoho tenanta federovat do více než jednoho tenanta? Pokud mají například zákazníci trénovací i produkčního tenanta, může být potřeba federovat stejného zprostředkovatele identity pro oba tenanty.

Modely autorizace

Rozhodněte se o autorizačním modelu, který dává pro vaše řešení největší smysl. Existují dva běžné přístupy k autorizaci:

  • Autorizace na základě rolí Uživatelé jsou přiřazeni k rolím. Některé funkce aplikace jsou omezené na konkrétní role. Uživatel v roli správce může například provádět jakoukoli akci, zatímco uživatel v nižší roli může mít v celém systému podmnožinu oprávnění.
  • Autorizace založená na prostředcích Vaše řešení poskytuje sadu jedinečných prostředků, z nichž každá má vlastní sadu oprávnění. Konkrétní uživatel může být správcem jednoho prostředku a nemá přístup k jinému prostředku.

Tyto modely jsou odlišné a vybraný přístup ovlivňuje vaši implementaci a složitost zásad autorizace, které můžete implementovat.

Nároky a licencování

V některých řešeních můžete jako součást komerčního cenového modelu použít licencování pro jednotlivé uživatele. Můžete poskytnout různé úrovně uživatelských licencí s různými možnostmi. Uživatelům s jednou licencí může být například povoleno používat podmnožinu funkcí aplikace. Možnosti, ke kterým mají konkrétní uživatelé přístup na základě jejich licencí, se někdy označují jako nároky.

I když se sledování a vynucování nároků podobá autorizaci, obvykle se zpracovává kódem aplikace nebo vyhrazeným systémem nároků, nikoli systémem identit.

Škálování identit a svazek ověřování

S rostoucím počtem víceklientských řešení se zvýší počet uživatelů a žádostí o přihlášení, které musí řešení zpracovat. Měli byste zvážit následující otázky:

  • Bude se uživatelský adresář škálovat na požadovaný počet uživatelů?
  • Bude proces ověřování zpracovávat očekávaný počet přihlášení a registrací?
  • Dojde ke špičkám, které ověřovací systém nedokáže zpracovat? Například v 9:00 PST můžou všichni v západní USA oblasti začít pracovat a přihlásit se k řešení, což způsobuje špičku v žádostech o přihlášení. Tyto situace se někdy označují jako bouře přihlášení.
  • Může vysoké zatížení v jiných částech vašeho řešení ovlivnit výkon procesu ověřování? Pokud například proces ověřování vyžaduje volání do rozhraní API aplikační vrstvy, způsobí vysoké množství žádostí o ověření problémy pro zbytek vašeho řešení?
  • Co se stane, když váš zprostředkovatele identity přestane být dostupný? Existuje služba ověřování zálohování, která může převzít zajištění kontinuity podnikových procesů, zatímco zprostředkovatele identity není k dispozici?

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 přístupy k architektuře pro identitu ve víceklientských řešeních.