Protokół OpenID - budowa i zastosowanie
Jedną z bardziej irytujących cech znacznej części dostępnych w Sieci serwisów internetowych jest konieczność ciągłego rejestrowania się w nich i pamiętania odpowiednich loginów i haseł. Jest to bardzo uciążliwe dla użytkownika. Co więcej, stanowi potencjalne zagrożenie bezpieczeństwa - internauci mają bowiem tendencję do stosowania we wszystkich serwisach internetowych tego samego hasła, wystarczy więc zbudować stronę wymagającą logowania, by łatwo uzyskać znaczną ilość haseł dostępu. Jedną z prób rozwiązania tego problemu jest zbudowanie infrastruktury pojedynczego logowania (ang. Single Sign On - SSO). Jednym z mechanizmów tego typu, zdobywających ostatnio coraz większą popularność, jest protokół OpenID. Artykuł ma na celu ogólne opisanie tego protokołu; bardziej szczegółowy opis znajduje się w odpowiedniej specyfikacji technicznej.
Wprowadzenie
Idea mechanizmów Single Sign On (SSO) jest bardzo prosta. Klient, po wejściu na stronę wymagającą uwierzytelnienia (RP - Relying Party), jest przekierowywany ns stronę logowania umieszczoną na serwerze SSO (zwany dalej IDP - Identity Provider). Tam podaje nazwę użytkownika i hasło. IDP weryfikuje hasło, po czym przekierowuje użytkownika z powrotem do RP, przy czym przekierowaniu temu towarzyszy przekazanie informacji o poprawnym uwierzytelnieniu użytkownika. Oczywiście cały proces jest zabezpieczony z wykorzystaniem kryptografii, co stanowi zabezpieczenie przed różnego rodzaju atakami.
Zastosowanie SSO
Opisany schemat SSO umożliwia budowanie rozproszonych, niezależnych od siebie aplikacji webowych, korzystających ze wspólnej bazy użytkowników. Daje to olbrzymie możliwości integracji różnych rozwiązań informatycznych. Co więcej, można sobie wyobrazić rozwiązanie, w którym jeden centralny dostawca tożsamości (np. rządowy) odpowiada za udostępnienie w sieci Internet mechanizmów SSO i zapewnienie, że dane użytkowników w nim zarejestrowanych są prawdziwe. Taki mechanizm uwierzytelniający mógłby z powodzeniem zapewnić zidentyfikowanie użytkowników i dotarcie do nich w przypadku jakiegokolwiek sporu, jednocześnie zapewniając pewną dozę anonimowości (SSO nie musi przekazywać w swej odpowiedzi prawdziwych danych użytkownika - wystarczy jedynie jego wewnętrzny identyfikator, umożliwiający administratorowi SSO jego jednoznaczną identyfikację w przypadku sporu). Można do tego wykorzystać na przykład mechanizmy "zaufanego profilu"
Jeśli władze centralne udostępniłyby SSO, mogłoby ono być wykorzystywane przez e-biznes. Taki mechanizm daje bowiem pewność, że internetowy kontrahent nie jest anonimowy, a więc i że można pociągnąć go do ewentualnej odpowiedzialności. O ile banki mogą mieć pewne obiekcje przed korzystaniem z "cudzych" SSO (będą zapewne chciały się zabezpieczyć poprzez podpisanie właściwych porozumień z dostawcą usługi SSO), to już sklepy internetowe czy serwisy aukcyjne przyjęłyby to zapewne ze znacznym entuzjazmem. Niskim kosztem dostałyby bowiem świetny mechanizm uwiarygodniania swoich Klientów, co obniżyłoby znacznie ryzyko realizacji nieprawdziwych zamówień. Jednocześnie wokół tak zbudowanego mechanizmu można by zbudować nowe, innowacyjne usługi, jak na przykład rozproszony system komentarzy wystawianych dla osób kupujących w sklepach internetowych.
Oczywiście powyższe rozważania są mocno abstrakcyjne; w praktyce zrealizowanie takiego projektu byłoby na pewno bardzo skomplikowane i ryzykowne (choćby ze względów bezpieczeństwa). Nie ma jednak powodu, by podmioty (zarówno publiczne, jak i prywatne), które i tak wdrażają rozwiązania klasy SSO, udostępniały je światu jako serwerów uwierzytelniania IDP - z zastrzeżeniem jednak, że nie ponoszą za ich wykorzystanie odpowiedzialności.
OpenID
Ze względu na olbrzymią różnorodność Internetu i jego ogólnoświatowy zasięg nie można niestety założyć, że będzie istniała jedna, centralna instytucja potwierdzająca tożsamość. Dlatego też pojawiła się koncepcja, która umożliwia każdej domenie internetowej pełnienie roli ośrodka uwierzytelniania użytkowników. Kontrola bezpieczeństwa sprowadza się do zaufania światowemu systemowi DNS. Użytkownik wpisuje jako swój login adres odpowiedniego serwera uwierzytelniania IDP, co uruchamia mechanizm logowania. Na takim założeniu opiera się protokół OpenID
Protokół OpenID jest rozwijany przez fundację OpenID
- IBM
- Microsoft
- PayPal
- VeriSign
- Yahoo!
Wiele organizacji nie tylko wspiera rozwój protokołu, ale też implementuje go we własnych rozwiązaniach. Należy tu wyliczyć między innymi
- Microsoft Live
Windows Live ID Becomes an OpenID Provider - Google
Moving another step closer to single-sign on - Orange.FR
Accédez facilement à des sites web avec votre compte utilisateur Orange
Protokół OpenID
Protokół OpenID wpisuje się w ramowy schemat działania SSO, opisany powyżej. Jego przebieg przedstawiono na załączonym rysunku. Składa się z następujących etapów
1. Użytkownik podaje na stronie, na którą chce się zalogować (RP), identyfikator OpenID. W praktyce jest to często adres domenowy serwisu, który pełni funkcję serwera uwierzytelniania (IDP).
2, 3. RP analizuje otrzymany identyfikator OpenID. Na jego podstawie odnajduje fizyczny adres serwera IDP. RP nawiązuje z IDP połączenie, w ramach którego uzgadnia wspólny dla obu stron klucz kryptograficzny, wykorzystując algorytm Diffiego-Hellmana
4. RP przekierowuje przeglądarkę użytkownika na strony logowania, udostępnionej w ramach serwera IDP. W tle przekierowania przesyłane są informacje, do jakiego zasobu użytkownik próbuje uzyskać dostęp.
5. Przeglądarka użytkownika przechodzi na stronę serwisu, przesyłając w tle żądanie logowania otrzymane od RP.
6. Jeśli użytkownik nie logował się w ramach tej sesji do IDP, to IDP wyświetla mu formularz logowania.
7. Użytkownik loguje się, podając swój login i hasło (lub w inny sposób potwierdzając swoją tożsamość).
8. Po stwierdzeniu, że użytkownik jest zalogowany, IDP przekierowuje jego przeglądarkę z powrotem do RP, które rozpoczęło cały proces. W tle przesyłane jest, podpisane za pomocą ustalonego klucza kryptograficznego, potwierdzenie uwierzytelnienia lub informacja o błędzie.
9. Przeglądarka użytkownika przesyła otrzymane potwierdzenie do RP, które weryfikuje otrzymaną odpowiedź. Od tej chwili użytkownik jest zalogowany i może kontynuować pracę z systemem.
Szczegółowy opis protokołu OpenID można znaleźć w specyfikacji tego protokołu, dostępnej na stronie OpenID.Net.
Podsumowanie i dalsze prace
Protokół OpenID stanowi środek techniczny do realizacji idei, jaką jest zorientowane na użytkownika, centralne zarządzanie tożsamością w Internecie. Z jednej strony jest to bardzo wygodne, z drugiej jednak może stanowić istotne ryzyko dla prywatności. Każda operacja wykonywana przez użytkownika OpenID, wymagająca uwierzytelniania, powoduje konieczność skontaktowania się z IDP. W ten sposób IDP otrzymuje bardzo dokładne informacje na temat aktywności sieciowej użytkownika, które może wykorzystywać choćby w celach marketingowych (budowa profilu użytkownika w zależności od rodzaju i częstotliwości korzystania z różnych serwisów, występujących w roli RP). Co więcej, dane takie mogą być wykorzystywane przez totalitarne kraje do podwyższenia stopnia kontroli nad obywatelem. Wskazane byłoby zatem przeprowadzenie analizy wpływu ewentualnego masowego wdrożenia rozwiązań klasy OpenID na prywatność użytkownika i szukanie rozwiązań, które mogłyby zwiększyć ochronę prywatności.
OpenID to protokół służący jedynie do uwierzytelniania użytkownika. Można wyobrazić sobie jednak jego rozszerzenia, mające na celu przesyłanie informacji o jego uprawnieniach. Jednocześnie dość proste wydaje się zbudowanie w oparciu o ten protokół mechanizmów delegacji uprawnień przez ich właścicieli innym użytkownikom. Te dwa tematy zostały poruszone między innymi przez twórców rozszerzenia protokołu OpenID o nazwie SimplePermissions
Osobnym tematem jest budowa usług złożonych, korzystających z infrastruktury OpenID. Dotyczy to zarówno implementacji tego protokołu w ramach istniejących serwisów, jak na przykład Onet.pl czy Wirtualna Polska, jak i tworzenia usług dedykowanych - choćby wspomnianej wcześniej usługi rozproszonych komentarzy dla klientów sklepów internetowych, działającej podobnie do systemów komentarzy na platformach aukcyjnych.
Inną, bardzo ważną pracą do wykonania, jest zbudowanie sieci zaufanych dostawców tożsamości (IDP). Jest to zadanie zarówno dla administracji publicznej, jak i innych instytucji zaufania publicznego (np. banki). W tym aspekcie obiecująco wygląda lista podmiotów wspierających fundację OpenID - jeśli zdecydują się one na pełnienie roli dostawcy tożsamości, będzie to bardzo duży krok w kierunku wcielenia w życie idei, stojących za OpenID.
Add new comment