Sdílet prostřednictvím

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

Identita je důležitým aspektem každého víceklientských řešení. Komponenty identit vaší aplikace zodpovídají za následující úlohy:

  • Ověření identity uživatele, označované jako ověřování

  • Vynucení oprávnění uživatele v rámci oboru tenanta, označovaného jako autorizace

Vaši zákazníci také můžou chtít autorizovat externí aplikace pro přístup ke svým datům nebo integraci s vaším řešením. Identita uživatele určuje, k jakým informacím má uživatel nebo služba přístup. Je důležité zvážit vaše požadavky na identitu, aby byla zajištěna izolace vaší aplikace a dat mezi tenanty.

Upozornění

Ověřovací a autorizační služby v rámci víceklientských a softwarových aplikací (SaaS) obvykle poskytují externí zprostředkovatel identity (IdP). IdP (zprostředkovatel identity) je obvykle nedílnou součástí platformy spravovaných identit.

Vytvoření vlastního zprostředkovatele identity je složité, nákladné a náročné na zabezpečení. Považuje se za antipattern a nedoporučujeme ho.

Před definováním strategie víceklientských identit nejprve zvažte následující požadavky na identitu vysoké úrovně pro vaši službu:

  • Určete, jestli uživatelé nebo identity úloh přistupují k jedné aplikaci nebo více aplikacím v rámci produktové řady. Některé řady produktů můžou zahrnovat různé aplikace, které sdílejí stejnou infrastrukturu identit, jako jsou systémy prodeje a platformy pro správu inventáře.

  • Zvažte, jestli vaše řešení implementuje moderní standardy ověřování a autorizace, jako jsou OAuth2 a OpenID Connect.

  • Vyhodnoťte, jestli je ověřování omezené na aplikace založené na uživatelském rozhraní nebo jestli se přístup rozhraní API vztahuje také na tenanty a systémy třetích stran.

  • Určete, jestli se tenanti potřebují propojit s vlastními zprostředkovateli identity a jestli je potřeba, aby bylo pro každý tenant podporováno více zprostředkovatelů identity. Můžete mít například tenanty s Microsoft Entra ID, Auth0 a Active Directory Federation Services, kde se každý tenant federuje s vaším řešením. Určete, které federační protokoly používají jejich zprostředkovatele identity, protože tyto protokoly určují, co váš poskytovatel identity musí podporovat.

  • Zkontrolujte všechny příslušné požadavky na dodržování předpisů, které potřebují splnit, například obecné nařízení o ochraně osobních údajů (GDPR), které utvářejí strategii vaší identity.

  • Určete, jestli tenanti vyžadují, aby data identit byla uložená v konkrétních geografických oblastech, aby splňovala právní požadavky, dodržování předpisů nebo provozní potřeby.

  • Vyhodnoťte, jestli uživatelé přistupují k datům z více tenantů v rámci aplikace. Pokud ano, možná budete muset podporovat bezproblémové přepínání tenantů nebo poskytovat konsolidovaná zobrazení napříč tenanty pro konkrétní uživatele. Uživatelé, kteří se přihlašují k webu Azure Portal, můžou například snadno přepínat mezi různými adresáři ID Microsoft Entra a předplatnými, ke kterým mají přístup.

Při vytváření požadavků na vysokou úroveň můžete začít plánovat konkrétnější podrobnosti a požadavky, jako jsou zdroje adresářů uživatelů a toky registrace a přihlašování.

Adresář totožnosti

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, které jsou uložené v adresáři jiného poskytovatele identity.

Při návrhu systému identit pro vaše víceklientní řešení je potřeba zvážit, které z následujících typů poskytovatelů identity mohou vaši nájemci a zákazníci potřebovat.

  • Místní poskytovatel identity: Místní poskytovatel identity umožňuje uživatelům registrovat 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ředkovatel identity ukládá jak identifikátor uživatele, tak přihlašovací údaje.

  • Sociální IdP: Zprostředkovatel sociální identity umožňuje uživatelům používat identitu, kterou mají na sociální síti nebo jiném veřejném zprostředkovateli identity, jako je Facebook, Google nebo osobní účet Microsoft. Sociální poskytovatelé identit se běžně používají v řešeních SaaS (business-to-consumer).

  • Adresář Microsoft Entra ID tenanta: V mnoha řešeních SaaS (business-to-business) (B2B) už můžou mít tenanti 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 s IdP tenanta: V některých řešeních B2B SaaS mohou mít tenanty vlastní zprostředkovatele identity, jiného než Microsoft Entra ID, a mohou chtít, aby se s ním vaše řešení federovalo. Federace umožňuje jednotné přihlašování (SSO). Umožňuje také tenantům spravovat životní cyklus a zásady zabezpečení uživatelů nezávisle na vašem řešení.

Měli byste zvážit, zda vaši tenanti potřebují podporovat více poskytovatelů identity. Jeden tenant může například potřebovat podporu místních identit, sociálních identit a federovaných identit. Tento požadavek je typický, když společnosti používají řešení určené pro zaměstnance i dodavatele. Pomocí federace mohou zaměstnancům udělit přístup, a zároveň umožnit přístup dodavatelům nebo uživatelům, kteří nemají účty ve federovaném zprostředkovateli 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 účtech uživatelů a služeb, včetně jejich jmen a dalších informací, které vaši tenanti vyžadují.

  • Informace potřebné k bezpečnému ověření uživatelů, včetně informací pro vícefaktorové ověřování (MFA).

  • Informace specifické pro tenanta, jako jsou role tenanta a oprávnění, pro 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. Ukládejte autorizační data v aplikační vrstvě spolu s informacemi o tenantovi.

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

Víceklientová řešení často umožňují identitě uživatele nebo úlohy přistupovat k prostředkům a datům aplikací napříč více tenanty. Pokud je tento přístup nutný, zvažte následující faktory:

  • Rozhodněte se, jestli chcete pro každou osobu vytvořit jednu identitu uživatele, nebo vytvořit samostatné identity pro každou kombinaci tenanta a uživatele.

    • Pokud je to možné, použijte jednu identitu pro každou osobu. Zjednodušuje správu účtů pro poskytovatele řešení i uživatele. Mnoho inteligentních ochran před hrozbami, poskytovaných moderními zprostředkovateli identity, rovněž spoléhá na to, že každý člověk má jeden uživatelský účet.

    • V některých scénářích používejte více jedinečný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, nepoužívejte přihlašovací údaje 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 plánujete přiřazovat uživatele k nájemci. Během procesu registrace můžete například uživatelům poskytnout jedinečný kód pozvánky, který se má zadat při prvním přístupu k tenantovi. V některých řešeních může název domény registrační e-mailové adresy uživatele identifikovat přidruženého tenanta. Případně můžete k určení mapování tenanta použít jiný atribut ze záznamu identity uživatele. Toto přidružení by se pak mělo uložit na základě neměnných jedinečných identifikátorů pro tenanta i uživatele.

Pokud vaše řešení omezuje přístup jednotlivých uživatelů k datům pro jednoho tenanta, zvažte následující rozhodnutí:

  • Určete, jak zprostředkovatele identity zjistí, ke kterému tenantovi uživatel přistupuje.

  • Vysvětlete, jakým způsobem zprostředkovatel identity zprostředkovává aplikaci identifikátor nájemce. Do tokenu se obvykle přidá deklarace identity identifikátoru tenanta.

Pokud je potřeba jednomu uživateli udělit přístup k více tenantům, zvažte následující rozhodnutí:

  • Řešení musí podporovat logiku pro identifikaci uživatelů a udělení odpovídajících oprávnění napříč tenanty. Uživatel může mít například práva správce v jednom tenantovi, ale omezený přístup v jiném tenantovi. 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?

  • Jasný mechanismus by měl uživatelům umožnit přepínání mezi tenanty. Tento přístup zajišťuje bezproblémové uživatelské prostředí a zabraňuje náhodnému přístupu mezi tenanty.

  • Identity úloh, pokud je použijete, musí určit tenanta, ke kterému se pokouší získat přístup. Tento požadavek může zahrnovat vložení kontextu specifického pro tenanta do žádostí o ověření.

  • Zvažte, jestli by informace specifické pro tenanty uložené v záznamu identity uživatele mohly neúmyslně uniknout mezi tenanty. Pokud se například uživatel zaregistruje se sociální identitou a získá přístup ke dvěma tenantům a tenant A rozšiřuje profil uživatele, určete, jestli má mít tenant B přístup k této rozšířené informace.

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

Někteří nájemníci mohou uživatelům umožnit, aby se zaregistrovali k identitě v rámci vašeho řešení. Samoobslužná registrace může být požadována, pokud nevyžadujete federaci s identitním poskytovatelem tenanta. Pokud je potřeba proces samoobslužné registrace, měli byste zvážit následující faktory:

  • Definujte, ze kterých zdrojů identit se uživatelé můžou zaregistrovat. Určete například, jestli uživatelé můžou vytvořit místní identitu a také používat sociálního zprostředkovatele identity.

  • Určete, jestli vaše řešení povoluje jenom konkrétní e-mailové domény, pokud se používají místní identity. Určete například, jestli může tenant omezit registraci uživatelům s e-mailovou @contoso.com adresou.

  • Hlavní název uživatele (UPN) používaný k identifikaci místních identit musí být jasně stanoven. Mezi běžné upN patří e-mailové adresy, uživatelská jména, telefonní čísla nebo identifikátory členství. Vzhledem k tomu, že uživatelské hlavní názvy (UPN) se můžou měnit, doporučujeme odkazovat na základní neměnný jedinečný identifikátor pro autorizaci a audit. Příkladem je ID objektu (OID) v Microsoft Entra ID.

  • K ověření přesnosti UPN může být nutné jejich ověření. Tento proces může zahrnovat ověření vlastnictví e-mailové adresy nebo telefonního čísla před udělením přístupu.

  • Některá řešení můžou vyžadovat, aby správci klienta schválili registrace uživatelů. Tento schvalovací proces umožňuje správu nad tím, kdo se připojí k tenantovi.

  • Rozhodněte se, jestli tenanti vyžadují prostředí pro registraci konkrétního tenanta nebo adresu URL. Určete například, jestli vaši tenanti při registraci uživatelů vyžadují značkový zážitek z registrace nebo možnost zachytit žádost o registraci a provést další ověření před pokračováním.

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

Pokud se mohou uživatelé sami zaregistrovat k identitě, definujte proces, kterým jim bude udělen přístup ke klientovi. Tok registrace může zahrnovat proces ručního udělení přístupu nebo automatizovaný proces 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í faktory:

  • Definujte, jak tok registrace určuje, že má uživatel udělený přístup ke konkrétnímu tenantovi.

  • Definujte, jestli vaše řešení automaticky odvolá přístup uživatelů k tenantovi, pokud je to vhodné. Když například uživatelé opustí organizaci, měli byste mít k dispozici ruční nebo automatizovaný proces, který jim umožní přístup odebrat.

  • Poskytněte možnost auditování uživatelů, aby tenanti mohli zkontrolovat, kteří uživatelé mají přístup ke svému prostředí, a pochopit jejich přiřazená oprávnění.

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

Běžným požadavkem u firemních nebo podnikových zákazníků řešení je sada funkcí, která jim umožňuje automatizovat zapojování a vyřazování účtů. Otevřené protokoly, například System for Cross-Domain Identity Management (SCIM), poskytují standardní přístup k automatizaci. Tento automatizovaný proces obvykle zahrnuje vytvoření a odebrání záznamů identit a 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í faktory:

  • Určete, jestli vaši zákazníci potřebují nakonfigurovat a spravovat automatizovaný proces životního cyklu pro každého 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í.

  • Určete, jestli potřebujete implementovat SCIM nebo nabízet federaci. Federace umožňuje tenantům zachovat kontrolu nad správou uživatelů tím, že uchovává zdroj pravdy ve svých vlastních systémech místo správy místních uživatelů ve vašem řešení.

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í zvažte následující faktory:

  • Někteří tenanti můžou vyžadovat možnost konfigurovat vlastní zásady vícefaktorového ověřování. 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.

  • Pro tenanty může být důležitá možnost definovat 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í.

  • Určete, jestli tenanti potřebují přizpůsobit proces přihlašování jednotlivě. Vaše řešení může například potřebovat zobrazit logo zákazníka. Nebo může být potřeba načíst informace o uživateli, jako je odměnové číslo, z jiného systému a vrátit je zpět ke zprostředkovateli identity, aby bylo možné profil uživatele obohatit.

  • Někteří uživatelé můžou potřebovat zosobnit jiné uživatele. Člen týmu podpory může například chtít prošetřit problém, který má jiný uživatel zosobněním svého uživatelského účtu, aniž by se musel ověřit jako uživatel.

  • Přístup k rozhraní API může být vyžadován pro některé uživatele nebo externí aplikace. Tyto scénáře můžou zahrnovat přímé volání rozhraní API řešení, které obchází standardní toky ověřování uživatelů.

Identity úloh

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

Microsoft Entra podporuje identity úloh a další zprostředkovatele identity je také běžně podporují.

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 pracovního zatížení 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 nájemníci mohou povolit přístup identity úloh k vašemu víceklientskému řešení, měli byste zvážit následující faktory:

  • Určete, jak se v každém tenantu vytvářejí a spravují identity úloh.

  • Rozhodněte, jak jsou požadavky na identitu pracovních úloh vymezeny vůči tenantovi.

  • Vyhodnoťte, jestli potřebujete omezit počet identit úloh, které každý tenant vytvoří.

  • Určete, jestli jsou pro identity pracovního zatížení v každém tenantovi vyžadovány ovládací prvky podmíněného přístupu. Nájemce může například chtít omezit ověřování identity úlohy z vnějšku konkrétní oblasti.

  • Určete, které kontrolní mechanismy zabezpečení poskytujete tenantům, abyste zajistili, že identity úloh zůstanou 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í pomáhá snížit riziko zneužití identity úloh.

Propojení se zprostředkovatelem identity pro jednotné přihlašování

Tenanti, kteří už mají své vlastní uživatelské adresáře, možná budou chtít, aby vaše řešení umožnilo federovat do jejich 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 zvláště významná v případech, kdy někteří nájemci chtějí zadat vlastní zásady identit nebo povolit zážitky SSO.

Pokud očekáváte, že se tenanti budou federovat s vaším řešením, zvažte následující faktory:

  • Zvažte proces konfigurace federace pro tenanta. Určete, jestli tenanti nakonfigurují federaci sami nebo jestli proces vyžaduje ruční konfiguraci a údržbu vašeho týmu.

  • Definujte, které federační protokoly vaše řešení podporuje.

  • Vytvořte procesy, které brání chybné konfiguraci federace, aby udělovala přístup k nezamýšleným tenantům.

  • Naplánujte, zda je potřeba federovat zprostředkovatele identity jednoho klienta do více než jednoho klienta ve vašem řešení. Pokud mají například zákazníci testovací i produkční tenant, možná budou muset federovat stejného zprostředkovatele identity s každým tenantem.

Modely autorizace

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

  • Autorizace na základě role: 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 vámi 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. V tomto scénáři zadáte různé úrovně uživatelských licencí, které mají různé možnosti. 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.

Doporučujeme sledovat a vynucovat nároky v rámci kódu aplikace nebo vyhrazeného systému nároků, a nespoléhat se na systém identit. Tento proces se podobá autorizaci, ale dochází mimo vrstvu správy identit.

Toto oddělení má několik důvodů:

  • Složitost modelů licencování: Pravidla licencování jsou často složitá a specifická pro obchodní model. Licence můžou být například časově založené (denní nebo měsíční přiřazení), omezující současné používání nebo mají určitá pravidla pro opětovné přiřazení. Zprostředkovatelé identit jsou obecně navržení pro ověřování uživatelů a základní autorizaci, ne pro složitou obchodní licenční logiku.

  • Nezávislost: Spoléhání na funkce zprostředkovatele identity pro správu licencí může vaše řešení uzamknout do daného zprostředkovatele nebo jeho omezení. Pokud podporujete zákazníky, kteří používají jiné zprostředkovatele identity, musíte pro ně přesto vytvořit vlastní řešení.

Běžným vzorem je správa licencí v databázi aplikace nebo vyhrazené službě. Když se uživatel přihlásí, zprostředkovatel identity načte svá oprávnění a vloží je do autorizačního tokenu jako vlastní deklarace identity, které je možné zkontrolovat komponentami aplikace za běhu.

Škálování identity a objem ověřování

S rostoucím počtem víceklientských řešení se zvyšuje počet uživatelů a žádostí o přihlášení, které řešení potřebuje zpracovat. Vyhodnoťte tyto aspekty škálovatelnosti:

  • Vyhodnoťte, jestli se uživatelský adresář škáluje tak, aby podporoval požadovaný počet uživatelů.

  • Vyhodnoťte, jestli proces ověřování zpracovává očekávaný počet přihlášení a registrací.

  • Zjistěte, zda systém ověřování nedokáže zvládnout špičky. Například v 9:00 pacifického času mohou všichni na západě Spojených států začít pracovat a přihlásit se k vašemu řešení, což vytvoří nápor žádostí o přihlášení. Tyto scénáře se někdy označují jako bouře přihlášení.

  • Určete, jestli vysoké zatížení v částech vašeho řešení ovlivňuje výkon procesu ověřování. Pokud například ověřování vyžaduje volání do rozhraní API aplikační vrstvy, může nárůst požadavků na ověřování ovlivnit celkový výkon systému.

  • Definujte, jak se vaše řešení chová, pokud je zprostředkovatel identity nedostupný. Zvažte, jestli by měla být zahrnuta služba ověřování zálohování, aby se zachovala kontinuita podnikových procesů.

Přispěvatelé

Microsoft udržuje tento článek. Tento článek napsali následující přispěvatelé.

Hlavní autoři:

Další přispěvatelé:

Pokud chcete zobrazit nepublikované profily LinkedIn, přihlaste se na LinkedIn.

Další krok

Přečtěte si o aspektech při práci s názvy domén ve víceklientských aplikacích.

  • Last updated on