Tożsamość nieujarzmiona

Identity Metasystem Microsoftu, projekt Higgins i mechanizm i-names to pomysły na rozwiązanie tego samego problemu - uniwersalnego zarządzania tożsamością.

Identity Metasystem Microsoftu, projekt Higgins i mechanizm i-names to pomysły na rozwiązanie tego samego problemu - uniwersalnego zarządzania tożsamością.

Zastosowanie centralnego uwierzytelnienia i kontroli uprawnień od dawna sprawiało kłopoty, nawet pomimo standardów. Obecnie mamy do czynienia z kolejną falą standaryzacji, które prawdopodobnie będą znacznie lepsze od dotychczasowych, co jednak nie oznacza, że przełoży się to automatycznie na większą liczbę wdrożeń. Kontrola dostępu to dziedzina, która przenika wszystko i wprowadzanie w niej zmian jest w praktyce bardzo trudne i kosztowne. Także dlatego, że zarządzanie tożsamością przestało być wyłącznie wewnętrzną sprawą firm, a stało się sprawą społeczną, związaną z prywatnością, mobilnością itp.

Ideałem byłoby opracowanie takiego mechanizmu uwierzytelnia użytkownika, który byłby możliwy do użycia nie tylko w jego miejscu pracy, ale także poza nim. Obecnie takiej możliwości brak. Jednak to tylko wierzchołek góry lodowej. Obecnie wykorzystywane systemy uwierzytelnia mają mnóstwo wad, pośród których jest rzeczywista niekompatybilność pomimo deklarowanej zgodności z otwartymi standardami.

Z tej niekompatybilności, która ma miejsce na wielu płaszczyznach, bierze się kolejny problem, polegający na "wyspowości" mechanizmów do zarządzania tożsamością. Konkretne systemy obsługują maksymalnie kilka usług lub aplikacji. Dopóki mamy do czynienia z homogenicznym środowiskiem, zazwyczaj wszystko działa dobrze. Gdy do tego środowiska trzeba dołączyć usługę o całkowicie innej konstrukcji, pojawiają się "schody". Droga do unifikacji jest daleka, choć nowe propozycje budzą nadzieje.

Identity Metasystem - obietnica prostoty

Microsoft kilkakrotnie próbował dostarczyć system uwierzytelnienia zapewniający jednokrotne logowanie do serwisów WWW (Passport) i poniósł sromotną klęskę. Obecnie firma szykuje nową ofensywę w dziedzinie zarządzania tożsamością pod nazwą Identity Metasystem (szerzej pisaliśmy na ten temat w CW 23/2005). Tym razem koncern wyciąga wnioski ze swoich błędów - po pierwsze dostarcza rozwiązanie działające w oparciu o otwarty protokół SAML, a po drugie jest ono rozwojowe. Jego esencją jest podzielenie zarządzania tożsamością na dwie części.

Na kliencie ma działać aplikacja CardSpace (do niedawna nazywana InfoCard) odpowiedzialna za uwierzytelnienie, która ma zostać dołączona do Windows Vista zarówno w wersji korporacyjnej, jak i domowej. Część serwerowa będzie niezależna, dzięki czemu użytkownik przyzwyczajony do CardSpace w pracy, będzie mógł tak samo uwierzytelniać się w domu.

Microsoft chce się także zmierzyć z niezwykle dużym stopniem skomplikowania rozwiązań do zarządzania tożsamością. Na tym polu jest naprawdę wiele do zrobienia - kto nie wierzy, niech przyjrzy się konsoli do zarządzania usługą Active Directory czy narzędziom do zarządzania tokenami RSA SecurID. Jeśli Microsoft zrealizuje tę obietnicę, z pewnością może liczyć na zainteresowanie.

Identity Metasystem ma ułatwić zarządzanie tożsamościami w sieci dzięki mechanizmom upraszczającym i automatyzującym typowe zadania. Oczywiście nie obejdzie się bez scalenia Identity Metasystem z istniejącą i przygotowywaną infrastrukturą Active Directory. Gdy uda mu się przy okazji skutecznie zintegrować Identity Metasystem, część klientów uzna, że jest to propozycja atrakcyjna. Microsoft jest świadom obietnicy, którą złożył i dlatego już teraz zleca firmom zewnętrznym wykonanie odpowiedniego oprogramowania obsługującego produkty firm trzecich.

Firma Ping Identity przygotowuje narzędzie będące czymś w rodzaju łącznika między Identity Metasystem a innymi produktami. Java InfoCard Server w założeniach ma być wieloplatformowy, ułatwiając scalenie istniejących technologii (takich jak choćby niezwykle popularna platforma LAMP (Linux, Apache, MySQL, PHP) z uwierzytelnieniem za pomocą technologii Microsoftu. Produkt ten zostanie zaprezentowany niebawem po premierze systemu Windows Vista.

Koncern z Redmond postanowił opublikować specyfikację wielu protokołów sieciowych związanych z uwierzytelnieniem, a niektóre z nich zostały przyjęte przez organizację OASIS. Niedawno Microsoft poszedł dalej - wydał dokument Open Specification Promise, w którym firma zrzeka się praw patentowych do tych protokołów.

Jest jednak pewien haczyk: dokument OSP dotyczy konkretnych, aktualnych wersji protokołów, jeśli więc powstaną kolejne wersje, potrzebne będzie nowe oświadczenie, lub... prawa będą obowiązywać. Niemniej jest to poważny krok w stronę współpracy ze środowiskami, takimi jak open source. Oczywiście same protokoły nie dają automatycznie możliwości rozwoju funkcjonalnych odpowiedników - potrzebne będą jeszcze metamodele, schematy XML dla komunikatów oraz dużo pracy.

Higgins - szanujemy standardy, dbamy o prywatność

Zupełnie inne podejście zakłada projekt Higgins. Jest to przedsięwzięcie open source, od początku nastawione na rozwiązanie zadania przy użyciu standardów. Żywotnie zainteresowane rozwojem projektu Higgins są firmy, takie jak IBM czy Novell, które sponsorują projekt licząc, że standaryzacja będzie dobrą przeciwwagą dla potęgi i sprytu Microsoftu. Żadna z nich oficjalnie się do tego nie przyznaje, ale biznes ma swoje prawa. Szczególnie dotyczy to Novella, który z usług katalogowych czerpie poważną część swoich przychodów.

W ramach Higgins opracowywane są metody opisu uprawnień i ról użytkowników w różnych kontekstach. Kontekstem może być np. zasób, aplikacja (także przeglądarka czy system ERP), rodzaj zdarzenia (logowanie, transakcja), grupa klientów lub użytkowników bądź dowolna kombinacja powyższych. Do każdego z tych elementów można przypisać uprawnienia i atrybuty, przez co powstaje bardzo pojemna matryca opcji, dająca elastyczność niespotykaną w dotychczasowych systemach do zarządzania tożsamością.

Typowym przykładem jest zastosowanie tych samych reguł przy logowaniu do różnych systemów - jedna osoba może w jednym systemie mieć uprawnienia administracyjne, zaś w kontekście komunikatora internetowego jest zwykłym użytkownikiem, dla serwisu transakcyjnego w banku jest klientem, zaś w innym systemie może w ogóle nie mieć praw.

W poważnych systemach występuje jeszcze gradacja uprawnień dotycząca tej samej osoby - administrator czasami loguje się z uprawnieniami systemowymi, częściej korzysta z tylko nieco wyższych od standardu uprawnień, nieraz musi też wykonać czynności, przy których lepiej mieć ograniczone uprawnienia. W typowych systemach do tego celu stosuje się logowanie na różne konta, tymczasem Higgins daje możliwość nie tylko wyboru uprawnień, ale także zmiany uprawnień bez konieczności logowania na inne konto.

Nic dziwnego, że Novell i IBM widzą w Higgins przyszłość zarządzania tożsamością - tego Microsoft nie oferuje, przynajmniej na razie.

Higgins jest bardzo obiecujący także z innego powodu - jako jeden z niewielu projektów zajmujących się uwierzytelnieniem, poświęca uwagę ochronie prywatności. Gdy użytkownik będzie posiadał dane uwierzytelniające w pracy, w tym samym standardzie będzie mógł przechować uwierzytelnienie do usług spoza firmy, np. w księgarni internetowej. W systemie zgodnym z Higgins do każdego kontekstu można przypisać atrybuty, dzięki którym użytkownik zadecyduje, które dane może udostępniać, komu i w jakim celu.

Dzięki temu będzie można ograniczyć dostępność danych, np. uniemożliwiając firmie zapoznanie się z prywatnym numerem telefonu, podczas gdy bank internetowy lub kolega (formalnie: członek grupy "znajomi") będzie mógł te dane uzyskać. Sztandarowym przykładem jest fakt, że administrator w przedsiębiorstwie będzie mógł przeczytać wiele atrybutów, ale hasła oraz wszelkie dane do serwisów zewnętrznych, np. do bankowości elektronicznej, będą dlań niedostępne.

Passport miał podobne założenia, ale Higgins idzie dalej, proponując stworzenie w pełni otwartego standardu (a nie rezygnacji ze ścigania naruszeń patentów), jak również decentralizację i rozszerzanie. Każda wtyczka rozszerzająca zgodna z Higgins będzie mogła definiować własne atrybuty do kontekstu związanego z określoną aplikacją. Naturalnym klientem takiego systemu uwierzytelnienia wydają się strony transakcyjne serwisów, takich jak Allegro czy banków internetowych. Dzięki standardom do każdego systemu i aplikacji będzie można stworzyć wtyczkę kompatybilną z aplikacją, a jednocześnie zgodną z Higgins.

I-names - tożsamość niezależna od infrastruktury Internetu

Na świecie powstają obecnie inicjatywy próbujące naśladować dawne usługi Passport, unikając przy okazji jego niedomagań i błędnych założeń. Operator systemów jednokrotnego uwierzytelnienia o nazwie i-names - firma Cordance, udostępnia usługi, dzięki którym użytkownik może za 20 USD wykupić internetową tożsamość. Sam wpis w rejestrach i-names niewiele by znaczył, gdyby nie to, że równolegle dostępny jest protokół OpenID, opierający się na zatwierdzonym przez OASIS otwartym standardzie dla identyfikatorów cyfrowych wykorzystujących ścieżki (tzw. XRI - eXtensible Resource Identifier).

Przyczyna jest łatwa do zauważenia - rozwiązanie to jest bardzo proste w użyciu, cechuje się skierowanym na użytkownika podejściem do cyfrowej tożsamości. Użytkownik, który będzie miał do wyboru pamiętanie wielu różnych loginów i haseł oraz centralne uwierzytelnienie zapewniające dostateczny poziom bezpieczeństwa, wybierze bez wątpienia to drugie. Użytkownik może się już teraz zalogować do wielu stron, podając swoją nazwę i-name oraz tajne hasło rejestrowane u i-brokera - instytucji rejestrującej i-nazwy. Nie jest do tego potrzebny ani nowy system operacyjny, ani żadne inne oprogramowanie po stronie klienta. Kluczem do sukcesu było połączenie OpenID z funkcjonalnością, jaką daje cyfrowe uwierzytelnienie zgodne z OASIS XRI.

W przeciwieństwie do powszechnie używanego protokołu LDAP (binarne wywołania RPC), OpenID wykorzystuje komunikację tekstową. Ma też dodatkową warstwę abstrakcji nadającą się do rozszerzania, czego w LDAP brakuje. Dzięki takim założeniom można na jego fundamencie zbudować prosty, acz bardzo elastyczny system trwale utrzymujący więzy między obiektami. Łatwo też uzyskać przenośność nazw między systemami. Koncepcja i-names jest analogiczna do nazw w serwisach DNS. Podobnie jak w DNS, i-names mogą być delegowane; można też wskazać częściową nazwę, a więc coś na kształt subdomeny.

Użytkownicy korzystający z systemu pojedynczego logowania do serwisów dostają od i-brokerów (firm zarządzających tożsamościami elektronicznymi) dodatkowo dwie usługi. Pierwsza z nich to strona kontaktowa - polega na dostarczeniu użytkownikowi personalnej, prostej strony kontaktowej, gdzie wyświetlane są internetowe informacje kontaktowe w taki sposób, by nie pokazywać adresu e-mail.

Druga usługa to permanentne linki - dają możliwość utworzenia odnośników do zasobów, takich jak strona WWW, blog, album zdjęć itd. Niby nic wielkiego, a jednak... Linki są związane z i-nazwą, a nie z domeną DNS. Dzięki temu rozwiązaniu nie problemu przy zmianie usługodawcy czy adresu DNS strony WWW. Jeśli zajdzie taka potrzeba, wystarczy zmienić przypisanie między adresem w serwisie i-names i serwisie DNS - tak jak robi to choćby prv.pl. Można mieć jeden adres przez wiele lat - związany ze wszystkim co się robi w Internecie.

Nie nadużyć zaufania

Centralne uwierzytelnienie ma z punktu widzenia użytkowników także istotne wady. Jedną z nich jest to, że operator obsługujący system wie doskonale do jakich stron się dany użytkownik loguje, jakich przywilejów używa itd. To jest ogrom wiedzy dotyczącej często sfery prywatności, dlatego szczególnie ważne jest zaufanie użytkownika do instytucji operatora systemów uwierzytelnienia. Gdy to zaufanie zostanie nadszarpnięte, nic już nie pomoże - tak było z usługami Passport Microsoftu. Oby twórcy standardów i implementacji mieli to na uwadze.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200