Při kombinaci různých přihlašovacích jmen, rozličných heslových politik či požadavků na nutnost měnit heslo v pravidelných intervalech je pak pro zaměstnance téměř nemožné si všechny odpovídající údaje zapamatovat.

Naštěstí existuje několik řešení, jež mohou uživatelům výše uvedené problémy pomoci překonat. Níže uvádíme dvě velmi významné – single sign-on a synchronizaci hesel. Z hlediska samotného uživatele sice nabízejí podobnou funkci, avšak každé ji řeší jinak.

Single sign-on (SSO)

Single sign-on, nebo zkráceně SSO, centralizuje autentizační proces uživatele do jednoho místa nazývaného také poskytovatel identity. Poskytovatel identity dělá autentizaci uživatele a tyto údaje pak poskytuje ostatním aplikacím (nazývaným též poskytovatelé služeb), které uživatel běžně používá.

Zjednodušeně lze základní fungování SSO popsat následovně: Uživatel chce pracovat v aplikaci A, ale není autentizovaný. Aplikace ho tedy přesměruje na poskytovatele identit (SSO), kde vykoná příslušnou autentizaci. Pokud je úspěšná, je přesměrován zpět do aplikace A, s níž může pracovat.

Později chce uživatel použít aplikaci B, do které se zatím neautentizoval. Ta se poskytovatele identit dotáže, zda se u něj uživatel již dříve autentizoval. Pokud se zjistí, že ano, vrátí aplikaci B zpět potřebnou informaci s tím, že si tato aplikace převezme autentizační informace a umožní uživateli vstup.

Některá řešení SSO obsahují také tlustého klienta SSO pro koncové stanice (je jej třeba nainstalovat na všechny koncové stanice), který pak komunikuje s poskytovatelem identit i s cílovou aplikací a zajišťuje předávání autentizačních údajů. Rozšiřuje se tak okruh aplikací, které lze k SSO připojit.

·        Výhody

Cíl SSO je zřejmý: Uživatel se na začátku své práce autentizuje pouze jedenkrát k poskytovateli identit (SSO). Ostatní aplikace pak již uživatel může běžně používat bez nutnosti se k nim znovu zvlášť autentizovat.

U cílových aplikací dokonce nemusí uživatel v některých případech ani znát své uživatelské heslo, protože aplikace sama o sobě důvěřuje údajům dodaným poskytovatelem identit.

·        Nevýhody

Úzkým místem SSO je silná vazba na centrální bod – poskytovatele identit. Stane-li se poskytovatel identit nedostupným, stanou se nedostupnými i aplikace na něj napojené.

Za další „problémovou“ vlastnost lze považovat i to, že je nutné upravit každou aplikaci napojovanou na SSO, tak aby při procesu autentizace uživatele místo standardního přihlašovacího dialogu vykonala přesměrování na poskytovatele identit a dále aby dokázala přijímat a zpracovávat autentizační informace od poskytovatele identit.

Třetí nevýhodou, třebaže nejde přímo o vlastnost SSO, je nutnost pořídit SSO jako samostatný produkt. To samozřejmě zatěžuje rozpočty firem, které tak v mnoha případech nechtějí do SSO investovat a snaží se problém řešit jiným způsobem. Alternativním řešením pro mnohé organizace může být použití některého z open source produktů.

Známá SSO řešení, se kterými se ve zdejších končinách lze potkat, jsou například OpenAM, CA SiteMinder, NetIQ SecureLogin a mnoho dalších. Další SSO řešení známá spíše mimo podnikové sítě jsou OpenID, MojeID, přihlašování pomocí účtu na Googlu nebo na Facebooku.

Synchronizace hesel

Ačkoliv z pohledu uživatele nabízí synchronizace hesel podobný komfort jako SSO (uživatel si nemusí pamatovat spousty různých hesel), funguje zcela odlišně. Velmi jednoduchý scénář použití lze popsat následovně: V síti existuje centrální bod, kam se uživatel přihlásí a jednoduchým způsobem si změní heslo.

To se pak distribuuje do ostatních aplikací napojených na centrální bod. Uživatel sice musí při práci s koncovou aplikací znovu zadat autentizační údaje, ale použije jedno a totéž heslo, které si nastavil v předchozím kroku.

Synchronizaci hesel nelze koupit jako samostatný produkt, ale je vždy součástí nějakého jiného produktu jako jedna z jeho služeb. Nejčastěji jde o produkty správy identit – identity managementu (IdM). Přitom dnes už de facto jakýkoliv vyspělý produkt pro správu identit podporuje synchronizaci hesel, některé z nich dokonce i obousměrnou.

Tady jsou nejznámější: CA IdentityMinder, Oracle IdM, NetIQ IdM, IBM IdM, Microsoft Forefront Identity Manager, z open source systémů jde například o Evolveum MidPoint  či ForgeRock OpenIDM.

·        Výhody

Hlavní výhoda synchronizace hesel oproti SSO je zřejmá – není tak silná vazba koncových aplikací na centrální bod. Uživatelé mohou s koncovými aplikacemi pracovat i v případě, že se centrální bod stane nedostupným. Problém nastává pouze v případě, že uživatel potřebuje změnit heslo a nemůže se na centrální bod připojit.

Další výhodou, naznačenou již v předchozích odstavcích, je skutečnost, že synchronizace hesel je v drtivé většině případů součástí systémů pro správu identit. Pokud tedy firma správu identit nasazuje nebo používá, může spolu s tím využívat i synchronizaci hesel jako „bonus“ navíc.

Také lze tímto způsobem vyřešit i požadavek na dodržování politiky hesel v aplikacích, které tuto funkcionalitu jinak nemají. Uživatel si změní heslo v centrálním bodě, který ověří heslo proti příslušné politice, a pokud je vše v pořádku, vykoná distribuci hesla i do dalších aplikací.

Třetí výhodou je jednodušší nasazení v IT prostředí. Většinou totiž není třeba nijak upravovat cílové aplikace, neboť se využívá jejich přirozeného API rozhraní. Menší problémy mohou nastat pouze v případě, že je nutné synchronizovat hesla z cílové aplikace do centrálního bodu IdM (typickým příkladem budiž Active Directory), ale všechny „dospělé“ produkty správy identit si i s tímto požadavkem dokážou elegantně poradit.

·        Nevýhody

Třebaže nejsou nevýhody na první pohled vidět, je třeba si uvědomit, že nasazení synchronizace hesel může snížit bezpečnost. Útočníkovi stačí uhodnout heslo uživatele do jedné aplikace a rázem má přístup i ke všem dalším, do kterých je heslo synchronizované. Některé firmy proto volí kompromis, kdy jsou například hesla synchronizované pouze v  aplikacích, které nejsou dostupné z internetu.

Dalším problémem může být sladění politik hesel napříč aplikacemi. Obecně platí, že nejpřísnější politika se uplatňuje v aplikaci, ve které si uživatel mění heslo (tedy nejčastěji je to IdM), a v ostatních je politika hesel stejná nebo mírnější. Ovšem ne vždy lze politiky sladit tak, aby tomuto pravidlu vyhovovaly.

Volba podle potřeb

Nelze jednoznačně říci, které z výše popsaných řešení je lepší a které horší, vždy záleží na konkrétní situaci a IT prostředí v konkrétní firmě. Někdy je dokonce vhodné obě řešení kombinovat.

Ať už se firma rozhodne implementovat jedno či druhé, měla by si ale uvědomit, že základním kamenem pro vaše správné rozhodnutí je důkladná analýza.

Autor pracuje jako solution architect v oblasti IDM ve společnosti AMI Praha