Model Federovaná identita

Deleguje ověřování na externího zprostředkovatele identity. To může zjednodušit vývoj, minimalizovat nároky na správu uživatelů a zlepšit komfort uživatelů aplikace.

Kontext a problém

Uživatelé obvykle potřebují pracovat s více aplikacemi poskytovanými a hostovanými různými organizacemi, se kterými mají obchodní vztah. Tito uživatelé musí pravděpodobně pro každou aplikaci používat konkrétní (a odlišné) přihlašovací údaje. To může:

• Zhoršovat uživatelský komfort. Když mají uživatelé mnoho různých přihlašovacích údajů, často je zapomínají.

• Způsobit ohrožení zabezpečení. Když uživatel odejde ze společnosti, musí se jeho účet okamžitě zrušit. Ve velkých organizacích se to může snadno přehlédnout.

• Komplikovat správu uživatelů. Správci musí spravovat přihlašovací údaje pro všechny uživatele a provádět další úlohy, jako je připomínání zapomenutého hesla.

Uživatelé obvykle raději pro všechny tyto aplikace používají stejné přihlašovací údaje.

Řešení

Implementujte mechanismus ověřování, který může používat federovanou identitu. Oddělte ověřování uživatelů od kódu aplikace a delegujte ověřování na důvěryhodného zprostředkovatele identity. To může zjednodušit vývoj, uživatelům umožnit ověřování pomocí širší škály zprostředkovatelů identity a současně minimalizovat nároky na správu. Také to umožňuje jasně oddělit ověřování od autorizace.

Mezi důvěryhodné zprostředkovatele identity patří podnikové adresáře, místní federační služby, jiné služby tokenů zabezpečení poskytované obchodními partnery nebo zprostředkovatelé sociálních identit, kteří můžou ověřovat uživatele třeba s účtem Microsoft, Google, Yahoo! nebo Facebook.

Na obrázku je znázorněný model Federovaná identita, když klientská aplikace potřebuje přístup ke službě, která vyžaduje ověření. Ověřování provádí zprostředkovatel identity, který spolupracuje se službou tokenů zabezpečení. Zprostředkovatel identity vydává tokeny zabezpečení, které obsahují informace o ověřeném uživateli. Tyto informace, označované jako deklarace identity, zahrnují identitu uživatele a mohou také zahrnovat další informace, jako je členství v rolích a podrobnější přístupová práva.

Tento model se často nazývá řízením přístupu na základě deklarací identity. Aplikace a služby autorizují přístup k vlastnostem a funkcím na základě deklarací identity obsažených v tokenu. Služba, která vyžaduje ověření, musí zprostředkovateli identity důvěřovat. Klientská aplikace kontaktuje zprostředkovatele identity, který provede ověření. Pokud je ověření úspěšné, zprostředkovatel identity vrátí token obsahující deklarace identity, které uživatele identifikují, službě tokenů zabezpečení (přičemž zprostředkovatel identity a služba tokenů zabezpečení můžou být stejnou službu). Před vrácením tokenu klientovi může služba tokenů zabezpečení deklarace identity v tokenu na základě předdefinovaných pravidel transformovat a rozšířit. Klientská aplikace pak může tento token předat službě jako potvrzení identity.

V řetězu důvěryhodnosti můžou existovat další služby tokenů zabezpečení. Třeba ve scénáři popsaném dál místní služba tokenů zabezpečení důvěřuje jiné službě tokenů zabezpečení, která je zodpovědná za přístup k zprostředkovateli identity kvůli ověření uživatele. Tento přístup je běžný v podnikových scénářích, kde se nachází místní služba tokenů zabezpečení a adresář.

Federované ověřování představuje řešení problému důvěřování identitám mezi různými doménami založené na standardech a může podporovat jednotné přihlašování. Tento typ ověřování je stále častější u všech typů aplikací, zejména aplikací hostovaných v cloudu, protože podporuje jednotné přihlašování bez nutnosti přímého síťového připojení k zprostředkovatelům identity. Uživatel nemusí zadávat přihlašovací údaje pro každou aplikaci. Tím se zvyšuje zabezpečení, protože brání vytvoření přihlašovacích údajů potřebných pro přístup k mnoha různým aplikacím a zároveň skryje přihlašovací údaje uživatele před všemi kromě původního zprostředkovatele identity. Aplikace vidí jenom informace o ověřené identitě obsažené v tokenu.

Federovaná identita má také hlavní výhodu v tom, že správu identity a přihlašovacích údajů má na starosti zprostředkovatel identity. Aplikace nebo služba nemusí poskytovat funkce správy identity. Kromě toho v podnikových scénářích podnikový adresář nepotřebuje o uživateli vědět, pokud důvěřuje zprostředkovateli identity. Tím se odstraňují všechny administrativní nároky na správu identity uživatelů v adresáři.

Problémy a důležité informace

Při navrhování aplikací, které implementují federované ověřování, berte v úvahu tohle:

• Ověřování může být kritickým prvkem způsobujícím selhání. Pokud aplikaci nasazujete do více datacenter, zvažte nasazení mechanismu správy identit do stejných datacenter, aby se zachovala dostupnost a spolehlivost aplikace.

• Nástroje pro ověřování umožňují konfigurovat řízení přístupu na základě deklarací identity rolí obsažených v ověřovacím tokenu. To se často označuje jako řízení přístupu na základě role a může umožňovat podrobnější úroveň řízení přístupu k funkcím a prostředkům.

• Ověřování založené na deklaracích identity pomocí zprostředkovatelů sociálních identit na rozdíl od podnikového adresáře obvykle neposkytuje jiné informace o ověřeném uživateli než e-mailovou adresu a případně jméno. Někteří poskytovatelé sociálních identit, jako je účet Microsoft, poskytují jenom jedinečný identifikátor. Aplikace obvykle musí uchovávat některé informace o registrovaných uživatelích a být schopná tyto informace porovnat s identifikátorem obsaženým v deklaracích identity v tokenu. Obvykle se to provádí prostřednictvím registrace při prvním přístupu uživatele k aplikaci a informace se pak po každém ověření vloží do tokenu jako další deklarace identity.

• Pokud je pro službu tokenů zabezpečení nakonfigurovaných více než jeden zprostředkovatel identity, musí služba STS určit, na kterého zprostředkovatele identity by se měl uživatel přesměrovat k ověření. Tento proces se nazývá zjišťování domovské sféry. Služba TOKENS to může provést automaticky na základě e-mailové adresy nebo uživatelského jména, které uživatel poskytuje, subdomény aplikace, ke které uživatel přistupuje, rozsahu IP adres uživatele nebo obsahu souboru cookie uloženého v prohlížeči uživatele. Pokud třeba uživatel zadal e-mailovou adresu v doméně Microsoft, například user@live.com, služba tokenů zabezpečení uživatele přesměruje na přihlašovací stránku účtu Microsoft. Při pozdějších návštěvách může služba tokenů zabezpečení pomocí souboru cookie informovat, že poslední přihlášení proběhlo pomocí účtu Microsoft. Pokud automatické zjišťování nedokáže domovskou sféru určit, služba tokenů zabezpečení zobrazí stránku zjišťování domovské sféry obsahující seznam důvěryhodných zprostředkovatelů identity a uživatel musí vybrat, kterého chce použít.

Kdy se má tento model použít

Tento model je vhodný pro podobné scénáře:

• Jednotné přihlašování v podnikové síti. V tomto scénáři musíte ověřovat zaměstnance pro podnikové aplikace, které jsou hostované v cloudu mimo hranice podnikového zabezpečení, aniž by se museli přihlásit pokaždé, když některou aplikaci navštíví. Pro uživatele to funguje stejně jako při používání místních aplikací, kdy je ověřen při přihlášení k podnikové síti a od té chvíle má přístup ke všem příslušným aplikacím, aniž by se musel znovu přihlašovat.

• Federovaná identita s více partnery. V tomto scénáři musíte ověřovat zaměstnance společnosti i obchodní partnery, kteří nemají účty v podnikovém adresáři. To je běžné v aplikacích business-to-business, aplikacích, které se integrují do služeb třetích stran, a tam, kde mají společnosti s různými systémy IT sloučené nebo sdílené prostředky.

• Federovaná identita v aplikacích SaaS. V tomto scénáři nezávislí dodavatelé softwaru poskytují službu připravenou k použití více klientům nebo tenantům. Každý tenant se ověřuje pomocí vhodného zprostředkovatele identity. Třeba firemní uživatelé budou používat své podnikové přihlašovací údaje, zatímco uživatelé a klienti tenanta budou používat své přihlašovací údaje sociální identity.

Tento model nemusí být vhodný v následujících situacích:

• Všichni uživatelé aplikace můžou být ověřováni jedním zprostředkovatelem identity a není nutné ověřovat pomocí žádného dalšího zprostředkovatele identity. To je typické u obchodních aplikací, které k ověřování používají podnikový adresář (dostupný v aplikaci) pomocí sítě VPN nebo (v případě hostování v cloudu) prostřednictvím připojení ve virtuální síti mezi místním adresářem a aplikací.

• Aplikace byla původně vytvořena prostřednictvím jiného mechanismu ověřování, možná s vlastními úložišti uživatelů, nebo nemá schopnost zpracovávat vyjednávací standardy používané technologiemi založenými na deklaracích identity. Zpětné přidání ověřování založeného na deklaracích identity a řízení přístupu do stávajících aplikací může být složité a pravděpodobně není nákladově efektivní.

Návrh úloh

Architekt by měl vyhodnotit způsob použití vzoru federované identity v návrhu úloh k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

Příklad

Organizace hostuje aplikaci SaaS (Multitenant software as a service) v Microsoft Azure. Aplikace zahrnuje web, který tenanti můžou využívat ke správě aplikace pro své vlastní uživatele. Aplikace umožňuje tenantům přístup k webu pomocí federované identity vygenerované službou Active Directory Federation Services (AD FS) (AD FS), když je uživatel ověřen vlastní službou Active Directory dané organizace.

Obrázek znázorňuje, jak se tenanti ověřují pomocí vlastního zprostředkovatele identity (krok 1), v tomto případě AD FS. Po úspěšném ověření tenanta služba AD FS vydá token. Prohlížeč klienta předá tento token federačnímu poskytovateli aplikace SaaS, který důvěřuje tokenům vydaným službou AD FS tenanta, aby získal token platný pro zprostředkovatele federace SaaS (krok 2). Pokud je potřeba, federační zprostředkovatel SaaS před vrácením tokenu klientskému prohlížeči provede transformaci deklarací identity v tokenu na deklarace identity, které aplikace rozpozná (krok 3). Aplikace důvěřuje tokenům vydaným federačním zprostředkovatelem SaaS a pomocí deklarací identity v tokenu aplikuje autorizační pravidla (krok 4).

Tenanti si nebudou muset pamatovat samostatné přihlašovací údaje pro přístup k aplikaci a správce ve společnosti tenanta může nakonfigurovat ve své vlastní službě AD FS seznam uživatelů, kteří mají přístup k aplikaci.

Další kroky

• Microsoft Entra ID
• Active Directory Domain Services
• Active Directory Federation Services (AD FS)
• Multitenantové aplikace v Azure

Související prostředky

• Správa identit pro víceklientské aplikace v Microsoft Azure
• Vzor vrátného
• Model konfigurace úloh Edge
• Model konsolidace výpočetních prostředků
• Model Snižování zátěže pomocí brány