Přejít k navigační liště

Zdroják » Různé » Moderní internetové autentizační metody

Moderní internetové autentizační metody

Články Různé

V tomto úvodním článku miniseriálu o moderních autentizačních metodách (OpenID, LiveID a OpenAuth) si stručně představíme jejich historii, vlastnosti, výhody, nevýhody a oblasti, v nichž lze tyto metody nasadit. Soustředíme se na oblast webu a webových aplikací.

Jednou z oblastí, s nimiž se setká na internetu snad každý, ať už jako vývojář nebo jako uživatel, je uživatelská autentizace, tedy způsob, jakým uživatel prokáže serveru – či obecně poskytovateli nějaké služby – svou identitu. Možná by se mohlo zdát, že zde není moc co vymýšlet, když koncept „jméno + heslo“ přece funguje univerzálně. V následujících řádcích se vás pokusím přesvědčit o opaku.

Jak autentizace probíhá dnes

Autentizace uživatele vypadá v 99 % případů takto: Uživatel požádá o přístup k nějaké službě. Služba jej vyzve, aby se identifikoval. Uživatel zadá (do nějakého formuláře či jiným způsobem) svůj jednoznačný identifikátor (uživatelské jméno) a jako potvrzení, že se tímto jménem prokazuje oprávněně, přidá smluvenou informaci, která by měla být známa jen jemu a poskytovateli služby (heslo). Služba si údaje ověří a na základě srovnání se svými záznamy rozhodne o tom, zda uživateli povolí přístup.

Klasický web, a tedy naprostá většina v současnosti fungujících služeb, tento přístup implementuje nejjednodušším možným způsobem, a to tak, že si udržují vlastní databázi uživatelských účtů. Uživatel se před prvním přístupem ke službě musí zaregistrovat. Během registrace je mu vytvořen účet a je dohodnuto jméno a heslo. Tento proces znají snad všichni uživatelé internetu, a velká část internetových vývojářů jistě někdy stála před úkolem navrhnout či vytvořit správu uživatelských účtů.

Koláž loginů

Výhody tohoto přístupu jsou zřejmé: Správa uživatelských účtů může být přizpůsobena do posledního detailu potřebám konkrétní služby, služba má nad svými uživateli naprostou kontrolu a celý mechanismus je, při dobrém návrhu, relativně odolný proti kompromitaci. Z hlediska provozovatele je takový přístup téměř ideální.

Nevýhody a omezení klasického řešení

Pro uživatele ale má tento přístup i některé nezanedbatelné nevýhody. Asi nejviditelnější je, že člověk, který využívá víc služeb, se za čas ztratí v záplavě různých jmen a hesel. Pamatovat si, kde jsem „maly“, kde „mmaly“, kde „martinm“ a kde „martin.maly“ (nebo snad „martinmaly“?) je nad lidské síly. Nastupují proto všelijaké pomůcky, které si tyto údaje pamatují za vás, nebo vám rovnou ke každé službě a jménu vygenerují i silné heslo… Pokud ale chceme ke službám přistupovat z různých počítačů, je potřeba nějak tyto pomůcky synchronizovat, což přináší další komplikace.

Další nevýhodou je nepřenositelnost identity a její nejednoznačnost. Tato nevýhoda je například u mailových schránek naprosto zanedbatelná, ale jakmile vstoupíme do světa Web2.0, kde uživatelé vytvářejí obsah (třeba diskusní fóra či komentáře), tak se může projevit. Uživatelská identita (uživatelské jméno) je totiž unikátní jen v rámci jedné služby nebo rodiny služeb – jako příklad si můžeme uvést „Seznam mail“, který lze použít na všech službách z „rodiny Seznamu“. Na jiném serveru může v diskusi pod stejným jménem vystupovat někdo jiný (a vice versa – ten samý člověk bude mít na jiném serveru jiné uživatelské jméno).

Hledá se lepší řešení

A právě s větším rozmachem uživatelsky vytvářeného obsahu se tyto nevýhody klasického přístupu ukázaly jako natolik nepříjemné, že bylo načase hledat nějaký alternativní postup.

Zde dovolte malou osobní odbočku: V roce 2003 jsme po spuštění Bloguje.cz s dalšími blogery přemýšleli nad tím, jak jednoznačně identifikovat komentátory na různých blozích. Stávalo se totiž, že člověk dostal neprávem vynadáno za to, jaké nesmysly píše tam či onde – a ve skutečnosti to byl někdo jiný, kdo si, buď nevědomky nebo záměrně, zvolil stejnou přezdívku. Nebo na různých blozích psali dva různí komentátoři pod stejnou přezdívkou, což bylo matoucí. Hledali jsme tedy způsob, který by šlo snadno implementovat, který by umožnil komentátorům vystupovat na různých blozích pod stejnou přezdívkou a zároveň zabraňoval tomu, aby pod stejnou přezdívkou vystupoval někdo jiný. Nakonec jsme se shodli na tom, že řešení spočívá v nějakém nezávislém správci, který by ověřoval identity jednotlivých komentátorů (pokud by o to měli zájem, samo sebou). Myšlenka pěkná, ale přišla příliš brzo a nebyla síla (ani vůle) ji prosadit.

Koláž OID

Nezávislá autentizační autorita

Myšlenka nezávislé autority, která by spravovala uživatelské identity, byla logickým vyústěním úvah nad tím, jak udělat autentizaci tak, aby uživatelská identita byla univerzální, jednotná, unikátní a nezávislá. Univerzální, tedy nikoli omezená na jednu službu či rodinu služeb, ale použitelná pro jakoukoli webovou (a nejen webovou) službu. Jednotná, tedy pro všechny služby stejná, a zároveň unikátní, tedy aby se s ní nemohl prokazovat nikdo jiný než oprávněný uživatel. A konečně nezávislá, ať už si pod tímto slovem představíme „bezplatná“, „otevřená“, „nepropojená s poskytovatelem služby“ nebo „bez licenčních poplatků“.

Správa identit třetí stranou („providerem“) přináší některé zásadní výhody: Uživatel nepotřebuje heslo ke každé službě, stačí mu znát jen heslo k účtu u správce identity. S touto identitou se pak přihlašuje na různé služby. Taková identita pak jednoznačně identifikuje konkrétního člověka, a to i na různých službách. Provozovatel služby se pak nemusí starat o autentizaci a všechny problémy s ní spojené (zabezpečený přenos údajů, obnova zapomenutých hesel, zabezpečení přihlašovacích dat), pouze implementuje komunikaci s autentifikační autoritou.

Samo sebou, ruku v ruce jdou nevýhody. Pro uživatele nejzásadnější nevýhodou je „efekt kroužku na klíče“ – pokud je jeho identita kompromitována (prozrazení hesla apod.), tak je kompromitována na všech službách, kam se s touto identitou přihlašuje. Provozovatelé zase ztrácí část kontroly nad informacemi o uživatelích – v tom nejextrémnějším případě dostanou pouze jakýsi číselný identifikátor, z něhož nelze o uživateli zjistit nic. Ono to v zásadě nevadí, ale někteří provozovatelé takovou ztrátu mohou nést těžce.

V posledních třech letech bylo navrženo několik univerzálních metod, které implementují tento přístup. Nejznámějšími představiteli jsou OpenID a LiveID, ale existují i další.

Pokračování příště

V tomto úvodním seznámení jsme se věnovali obecně distribuovaným autentizačním metodám, jejich smyslu a účelu, pro které byly navrženy. V dalších dílech si představíme jednotlivé metody podrobněji a nakonec si ukážeme i praktický příklad implementace takové metody.

Používáte moderní autentizační metody?

Komentáře

Subscribe
Upozornit na
guest
17 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
v6ak

Proč se omezovat na jednoho poskytovatele a dělat sluhu jedné firmě? Ať jde o Google, Microsoft, Seznam, nebo kohokoli, přijde mi to postavené na hlavu. Zvlášť když tu máme lepší řešení jako OpenID.

Petr

Třeba proto, že OpenID musí někdo vydat – windows LiveID je jedním z poskytovatelů OpenID.

v6ak

LiveID je taky OpenID? To jsem nevěděl. A je tu ale nějaký důvod, proč by se měl programátor zabývat konkrétními poskytovateli?

Petr

Proto je právě OpenID aby nemusel.

Jen tak

Jako nic proti, ale pokud budeme porovnavat v danem kontextu vyhody live id a open id, tak jste docela dost mimo. i kdyz vemu open id, tak jsem prece vazan na konkretniho poskytovatele open id (napr. seznam). pokud se seznam rozhodne to zabalit, tak o danou identitu bez nahrady prijdu. tak v cem je ta vyhoda open id oproti treba live id (v kontextu zavislosti na firme)?

WiFi

To nie je tak uplne pravda. Nevie sa totiz jedna vec. Vy mozete mat OpenID login pokojne aj http://mojserver/vy a pritom vam tam nemusi bezat ziaden SW na spravu openID identit. Jedina podmienka je, aby na danej adrese bol dostupny XML subor kde je popisane, kto je vasim realnym providerom. V takom pripade pride k presmerovaniu na daneho providera, co uz moze byt seznam. Ako uz mozno tusite, vyhoda je ta, ze pri zmene providera nepridete o login resp. jednoznacny identifikacny udaj.

v6ak

No představ si, že na jednom webu se budeš identifikovat pomocí Live ID, na druhém pomocí Google účtu, na třetím pomocí Yahoo účtu apod. A teď aby se v tom … vyznalo.
Navíc by tvůrci webu mohli paradoxně způsobit potíže, kdyby přidali další službu (službu B). Představ si, že ses tam přihlašoval pomocí služby A, ale preferuješ službu B. A když príjdeš, logickou (ale mylnou) úvahou dojdeš k tomu, že přece se identifikuješ službou B a ne nějakým nepříjemným Áčkem. 'Tak proč to doháje nejede?!!'
Dalo by se toho samozřejmě najít mnohem víc. Nedávno jsem se k jedné službě mohl přihlásit pomocí Yahoo a Google účtu. Samozřejmě že jsem agitovat za OpenID, přestože v OBOU mám účet.
Jde taky o mírně podobný princip jako u mailu. Nikdo mě nenutí je konkrétnímu poskytovateli. Stejně tak u Jabberu. I don't CQ.

Anonymní

A co takhle Facebook? Vsadím boty, že FB ovládne autentizační trh.

Honza Sládek

Rozhodne bude zajimave sledovat, jak Facebook Connect zamicha prihlasovanim na internetu. Mozna ze skutecne nakonec OpenID bude pouzivat pouze par geeku a pro bezne uzivatele bude daleko srozumitelnejsi a jasnejsi Facebook Connect. Idealni pripad by vsak pochopitelne byl, kdyby Facebook zacal podporovat OpenID :)

Doufam, ze se Martin Maly bude v nejakem pristim clanku venovat prave i technologii Facebook Connect.

František Kučera

OpenID jako takové je dostatečně přívětivé i pro obyčejné uživatele (navíc od Seznamu ho má každý). Rezervy jsou spíš v implementaci u jednotlivých aplikací – např. pro vložení komentáře často nestačí zadat OpenID* ale uživatel musí projít normální registrací na daném serveru, vytváří si na něm účet, uvádí e-mail a pohodlnější je to jen o to, že při příštím přihlášení/komentování nemusí zadávat jméno a heslo, ale jen OpenID.

Jasně, že na cílovém serveru (blog, diskuse…) bude mít pravděpodobně uživatel nějaký svůj účet, záznam v DB. Ale proces vytváření tohoto účtu by měl být co nejvíce transparntní a uživatel by o něm pokud možno neměl vůbec vědět. A tenhle problém není až tak závislý na tom, jestli se použije OpenID nebo něco jiného.

*) nechat se přesměrovat na stránku poskytovatele OpenID, zadat heslo (nebo už může být přihlášen) a skočit zpátky a je odesláno.

fgh

"(navíc od Seznamu ho má každý)." každý zoufalec jako Vy? Dost možná, ale ten kdo jednou zažije ten mrdel v seznamu – již nikdy více!

Mazarik

Staci mi, ze moj poskytovatel netu vie, na ake stranky chodim a moze si veselo robit statistiky, takze vyuzivat rozne agregovane prihlasovania nebudem a povazujem to za celkom skodlive.

zcg

Mno od toho právě ty systémy jsou, aby se to nedalo poznat. Teda nevím jestli konkrétně OpenID, ale všechno se dá.

fashia

ti lide co ridi svet nemaji radi to kam se dnes internet dostal, maji radi centralizovanou statni moc ( google : fashia, google : fashia US congress, google : fashia musolini vatican roman empire ) WEB 2.0 ma znicit svobodu slova tak ja ji dnes zname na internetu a samozrejmne dostat pod kontrolu pyramidalni struktury to co se momentalne vymika kontrole hierarchicke pavucine po tisicileti budovane na tomhle svete. Zavest vysokorychlostni, ale korproatni filtrovaci firewally, centralizovany zpravovani identit (tento clanek) Momentalne se to testuje v Cine a Australii, pak to pride sem.

mekele

To vam muselo dat hodne prace nez jste tohle vymyslel ;)

humlik

Říká vám něco slovo "ALUCID"? Trvalá společná vystopovatelná identita může být opravdu průšvih. To, co jednou do Internetu vložíte, už nikdy nedostanete pryč. ALUCID je autentizační metoda, která jde jiným konceptem – anonymní identita … zní to jako blbost co ? Alespoň mě, do té doby, než jsem pochopil princip. Začíná to podobně – máte "token", kde se udržují seznamy identit. Kazda jedna identita (proste jen číslo bez další identifikace) pro každou nezávislou autentizací doménu.
U každého providera je server zodpovědný za komunikaci s vaším tokenem. V serveru se spáruje číslo s vaší identitou, záleží na vás , co providerovi řeknete. Vtip je v tom, ze identita (tedy jen číslo), se v čase mění – náhodně, ale synchronně mezi vaším tokenem (je to vlastně malé PC) a serverem provideru. Takto se mění nezávisle identity mezi všemi vašimi providery a vaším tokenem – nezávisle, a přece každý provider vás dokáže identifikovat. Zatímco u klasického způsobu jednotného ID vás každý dokáže vystopovat třeba 10 let dozadu, a to u každého providera, protože máte JEDNO STEJNE ID, tak u ALUCIDu to z principu nejde.
Je to zatím stále ve vývoji, pochází to dokonce z Cech, otcem je kolega Libor Neumann. A ti ,kdo neomdlí z M$ formátu, tak více třeba tady – http://events.oasis-open.org/home/sites/events.oasis-open.org.home/files/ALUCIDv1.8_0.ppt

trmselb

…kdyz uz asi 20 let mame k dispozici mnohem lepsi autentizacni metody, proc nekdo porad vymysli dalsi? (a nefunkcni)

openid-cokoliv bohuzel nikdy duveryhodne byt nemuze, jsme na internetu, zpusobu utoku&zneuziti mame k dispozici miliony. Zarazi me kolik lidi takhle hodi klice do kapsy nekomu dalsimu (kteremu mam neodbytne nutkani rikat „sberatel“). Nevim jestli existuje nejaky dobry duvod ktery by takovemu serveru branil zneuziti udaju. Vyse polozeny prispevek o vseobecne skodlivosti centralizace ma taky pravdu – je to postavene na hlavu a jeste proti obecnym zvyklostem spravne funkcniho internetu.

Kdyz jsem se uz zminil o existujicim reseni – to si kazdy nemuze proste vygenerovat dost bezpecny GPG klic (coz je DOSTkrat jednodussi nez vymysleni stejne bezpecneho hesla), a veci ktere chce autentizovat jim proste podepsat?

  • heslo ma vsude stejne
  • identita je zlomitelna _mnohem_ hure nez hesla
  • identitu si drzi sam, muze s ni delat co chce, nedava ji nekomu jinemu

A jestli mi nekdo zacne tvrdit ze GPG ma zname bezpecnostni nedostatky, necht se zvedne z blogisku, porovna to s OpenID a zamysli se nad sebou.

PS. Alucid je _zajimave_ reseni, bohuzel nedostatky centralni spravy atp. mu zustavaji. Treba to nekdo doupravi ;)

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.