Zeptejte se kteréhokoli IT oddělení, jestli chce spravovat další sadu hesel pro další firemní aplikaci, a odpověď bude unavené, důrazné ne. Každé samostatné přihlašovací údaje znamenají jeden účet navíc k založení, jeden navíc ke zrušení, jeden lístek na helpdesk, když se zapomenou, a jednu nejistotu, když zaměstnanec odejde. Firmy to řeší centralizací identit: jeden firemní účet, jedny přihlašovací údaje, jedno místo, kde se přístup zapíná a vypíná, jedna politika platná všude. Platforma, která se do téhle centralizované správy identit neumí zapojit, je platforma, proti které IT staví odpor. Proto platforma mluví protokoly federace identit, které IT už používá, propojí se s centrálním adresářem a chová se tak, jak se od slušně vychované firemní aplikace čeká.
Propojení s poskytovatelem identity je základ. Prostředí se napojí na centrální adresář organizace; uživatelé, kteří přijdou na platformu, jsou k ověření přesměrováni k poskytovateli identity; ten se za ně zaručí a vrátí podepsané potvrzení; platforma pak odpovídající účet vytvoří nebo dohledá a spustí relaci. Zážitek uživatele je přesně takový, jaký firemní uživatelé očekávají: kliknou na přihlášení, přesměruje je to na známou firemní přihlašovací stránku, tam se ověří (často jakýmkoli druhým faktorem, na který je organizace zvyklá) a vrátí se na platformu už přihlášení.
Mapování rolí podle skupin je místo, kde se propojení stává pro administrátory opravdu užitečným. Poskytovatel identity už ví, do kterých skupin uživatel patří — Obchod, Vývoj, Finance, Regionální manažeři, Auditoři jen pro čtení. Členství v těchto skupinách lze automaticky mapovat na role platformy: členství ve skupině Obchod udělí roli Obchodní uživatel, členství ve skupině Finance udělí roli Finance a tak dále. Mapování se nastaví jednou v konfiguraci prostředí; přiřazení rolí novým i stávajícím uživatelům se pak řídí adresářem, takže správa oprávnění zůstává centralizovaná tam, kde už je, místo aby se opakovala v každé aplikaci.
Zakládání účtů při prvním přihlášení zaceluje poslední mezeru v zavádění uživatelů. Když na platformu přijde uživatel, který se dosud nikdy nepřihlásil, poskytovatel identity se za něj přesto zaručí a platforma účet založí rovnou na místě — vyplní základní údaje z potvrzení, přiřadí role podle mapování skupin a uživatele pustí dovnitř. Žádný ruční krok pro zřízení účtu, žádný administrátor, který by musel předem zakládat účet každému nováčkovi, žádné čekání, než někdo nastaví přístup. Uživatel přijde, ověří se a platforma ho přijme, protože jeho zaměstnavatel to už udělal. Tak by mělo zavádění uživatelů ve velkém vypadat.
Smíšený režim umožňuje provozovat SSO vedle lokálních účtů s heslem v témže prostředí. Většina firemních uživatelů se přihlašuje přes poskytovatele identity; hrstka servisních účtů, integračních uživatelů nebo záložních administrátorských účtů si ponechá lokální přihlašovací údaje. V praxi to má význam, protože svět není černobílý: implementační partner pracující na daném prostředí může potřebovat lokální účet, který není svázaný s adresářem zákazníka; konkrétní integrace se může ověřovat vlastním lokálním účtem. Smíšený režim tyto případy zachová funkční, aniž by je nutil do SSO, kam přirozeně nepatří.
Délka relace a opětovné ověření respektují politiky poskytovatele identity. Organizace, která vyžaduje opětovné ověření každých osm hodin, si to může vynutit odpovídajícím nastavením poskytovatele; platforma respektuje délku relace, kterou poskytovatel vrátí. Když poskytovatel oznámí, že relace uživatele skončila, skončí i relace na platformě. Díky tomuto souladu není platforma slabým článkem přísné politiky relací.
Šíření odhlášení je doprovodný mechanismus při odhlašování. Když se uživatel odhlásí z jedné federované aplikace, poskytovatel může upozornit ostatní a platforma odpovídající relaci ukončí. Tam, kde více aplikací sdílí jednu identitu, znamená odhlášení z jedné odhlášení ze všech — což přesně odpovídá tomu, co má "odhlásit se" ve federovaném prostředí znamenat.
Směrování mezi prostředími umožňuje, aby se různá prostředí napojila na různé poskytovatele identity. Služba provozující desítky zákaznických prostředí může každého zákazníka napojit na jeho vlastní adresář, aniž by se volby poskytovatelů mezi prostředími míchaly. Každé prostředí vidí přihlašování sladěné s vlastní organizací; administrátoři spravují své vlastní mapování; platforma každý příchozí požadavek na ověření nasměruje ke správnému poskytovateli podle toho, o které prostředí jde. Pro provozovatele, kteří obsluhují více zákazníků, je právě tahle izolace mezi prostředími tím, co federaci vůbec dělá použitelnou.
Nouzové lokální přihlášení je pojistka, která je nejcennější právě ve chvíli, kdy je nejvíc potřeba. Špatně nastavené SSO — překlep v adrese poskytovatele, prošlý certifikát, poskytovatel odstavený kvůli údržbě — nemá natrvalo zamknout všechny uživatele venku. Platforma proto pro určené administrátorské účty zachovává cestu lokálního přihlášení, aby se v nejhorším případě administrátor mohl přihlásit lokálními údaji a chybu opravit. Bez téhle pojistky by špatná změna SSO byla z platformy neopravitelná; s ní je selhání "nepříjemné" místo "katastrofického".
Audit SSO událostí je napojený na protokol událostí. Každá výměna v rámci federace — každý pokus o přihlášení, každé úspěšné ověření, každé vyhodnocení mapování skupiny na roli, každé založení účtu — se zaznamená s dostatkem souvislostí, aby to šlo později prošetřit. Pro organizace, kde jsou přístupové záznamy požadavkem shody s předpisy, je toto pokrytí auditem tím, co propojení dělá skutečně přijatelným. Poskytovatel identity má vlastní záznamy, platforma má vlastní záznamy; dohromady vyprávějí celý příběh o tom, kdo měl k čemu přístup a kdy.
Pro firmy, které platformu zvažují, je podpora SSO často podmínkou, bez níž se nejde dál: dřív než začnou uvažovat o zbytku možností, řeší otázku, zda platforma zapadá do jejich strategie identit. S plnou integrací SSO, smíšeným režimem s lokálními účty a auditem i nouzovým přihlášením zní odpověď ano. K okolním tématům: článek o přihlašování popisuje cestu přes heslo pro uživatele mimo federaci, článek o rolích a oprávněních popisuje, co příchozí členství ve skupinách vlastně uděluje, a článek o pozvánkách pro uživatele popisuje zavádění uživatelů, kteří nepřicházejí přes adresář.