Novinky

Při kombinaci různých přihlašovacích jmen, různých heslových politik či požadavků na nutnost měnit heslo v pravidelných intervalech, je pro zaměstnance téměř nemožné si přihlašovací údaje do jednotlivých aplikací pamatovat. Existují však řešení, která uživatelům pomáhají výše uvedené problémy překonat. Pojďme se podívat na dvě z nich a popišme si jejich základní vlastnosti. Z hlediska běžného uživatele nabízejí podobnou funkci, avšak každý ji řeší po svém.

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 provádí 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). Tam uživatel provede 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é není autentizovaný. Aplikace B se dotáže poskytovatele identit, zda se u něj již uživatel dříve autentizoval. Poskytovatel identit zjistí, že ano a vrátí Aplikaci B zpět potřebnou informaci. Aplikace B převezme autentizační informace a umožní uživateli vstup do aplikace.

Některá řešení SSO obsahují také tlustého klienta SSO pro koncové stanice. Klienta je třeba nainstalovat na všechny koncové stanice a ten 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 od poskytovatele identit.

Nevýhody

Zkušenější z vás již jistě tuší, že ú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 provedla 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í negativní vlastností, třebaže se nejedná 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é firmy je použít některý s opensource produktů.

Známá SSO řešení, se kterými se můžete 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 Google nebo pomocí účtu 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. Nové heslo je pak distribuováno 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 se jedná o produkty správy identit – identity managementu (dále také IdM). Dnes již de facto každý vyspělý produkt pro správu identit podporuje synchronizaci hesel, některé z nich i obousměrnou. Jmenujme alespoň ty nejznámější:

CA Identity Manager, Oracle IdM, NetIQ IdM, IBM IdM, Microsoft Forefront Identity Manager, z opensource systémů je to 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 politice a pokud je vše v pořádku, provede distribuci hesla i do dalších aplikací.

Třetí výhodou je jednodušší nasazení v IT prostředí. Většinou ani 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 chceme synchronizovat hesla z cílové aplikace do centrálního bodu IdM (typickým příkladem budiž Active Directory), ale jak jsme zmínili již dříve, všechny „dospělé“ produkty správy identit si dokážou elegantně poradit i s tímto požadavkem.

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 synchronizováno. Některé firmy proto volí kompromis, kdy jsou například hesla synchronizována pouze v těch 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 je uplatňována v aplikaci, ve které si uživatel mění heslo (nejčastěji je to IdM) a v ostatních aplikacích je politika hesel stejná nebo mírnější. Ovšem ne vždy je možné politiky sladit tak, aby tomuto pravidlu vyhovovaly.

Závěr

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í ve vaší firmě. Někdy je dokonce vhodné obě řešení kombinovat. Ať už se rozhodnete implementovat jedno či druhé, uvědomte si, že základním kamenem pro vaše správné rozhodnutí je důkladná analýza.

Autor: Roman Pudil pracuje jako solution architect v oblasti IdM ve společnosti AMI Praha.

Článek byl pubikován v časopise Computerworld 19/2014.