SSO (Single Sing-On) i synchronizacja haseł

0

Dla wielu SSO oznacza tyle, że każdy użytkownik w danej organizacji ma tylko jeden identyfikator (login) i hasło umożliwiające mu dostęp również do innych aplikacji. Inni twierdzą, że SSO wdrożone jest , jeśli gdziekolwiek dany użytkownik się loguje, wyświetlany jest mu interfejs i zestaw narzędzi specjalnie pod jego potrzeby. Inną interpretacją jest w końcu ta, że SSO ma na celu uwierzytelnianie i autoryzację użytkownika za pomocą pojedynczego uwierzytelnienia w ramach każdej sesji pracy.

Nie jest tajemnicą, że praktycznie w każdej organizacji większość użytkowników systemów informatycznych zmuszonych jest, poza samym logowaniem do domeny, logować się też przynajmniej do kilku aplikacji dziennie. Aplikacje te zwykle nie są ani zintegrowane, ani oparte na identycznej architekturze, naturalne więc, że zapewniają też różne poziomy bezpieczeństwa. Jak się domyślamy, jednym ze sposobów zapobiegania temu zjawisku jest właśnie SSO.

Idea SSO opiera się na zintegrowaniu procesu uwierzytelniania i autoryzacji różnych aplikacji oraz systemów w taki sposób, by dostęp do nich wszystkich przyznawany był jednokrotnie, czyli po pojedynczym logowaniu.

image001

Rysunek1. Zakres SSO

Autoryzacja
Przyjrzyjmy się rysunkowi 1. Zgodnie z nim, SSO łączy w sobie zadania zarówno procesów zarządzania tożsamością, jak i zarządzania dostępem. Precyzując, SSO integruje dwa główne procesy: autentykacji i autoryzacji. Poniżej przedstawiono kolejność zdarzeń mających miejsce w standardowym procesie logowania.

SSO_02

Rysunek 2. Kolejność zdarzeń w procesie logowania

Cały proces rozpoczyna się od zaufania ze strony użytkownika do danej aplikacji bądź systemu. Wobec jego braku nie poda on ani swojego loginu, ani hasła. Dlatego logując się do internetowego banku, po HTTPS sprawdzamy zwykle, czy jest ona autentyczna i ma aktualny certyfikat. W dalszej kolejności następuje identyfikacja.

Jako identyfikację rozumiemy tu początkowy etap procesu określania tożsamości (autentykacji) użytkownika, aczkolwiek autentykacji mogą też dokonywać aplikacje, systemy operacyjne bądź sprzęt sieciowy. W praktyce polega on na podaniu identyfikatora, który jednoznacznie określa jego posiadacza w ramach całego systemu. W przypadku użytkownika będzie to najczęściej jego login. Z pojęciem tym wiąże się również termin „zarządzanie tożsamością” (IM, Identity Management), który coraz częściej oznacza procesy, zasady i technologie umożliwiające danej organizacji kontrolę nad dostępem jej użytkowników do krytycznych zasobów i aplikacji dostępnych online.

Po podaniu loginu zwykle wymagane jest potwierdzenie, że osoba go wpisująca jest rzeczywiście tą, za którą się podaje. Dzieje się to właśnie w procesie autentykacji. Autentykacja często mylona jest z autoryzacją, warto więc dobrze zrozumieć różnicę pomiędzy nimi.

Przykładowymi metodami uwierzytelniania są: hasła jedno- i wielorazowe, PIN-y, tokeny, karty magnetyczne i chipowe, infrastruktura PKI (klucz prywatny), cyfrowe podpisy, czytniki biometryczne itp. Autoryzacja polega natomiast na przyznaniu uwierzytelnionemu w procesie autentykacji użytkownikowi dostępu do zasobów zgodnych z jego uprawnieniami. Autoryzacja jest więc naturalnym następstwem uwierzytelniania.

Resetowanie haseł
Resetowanie haseł jest zagadnieniem powiązanym zarówno z SSO, jak i z synchronizacją haseł, opisanymi dokładniej poniżej. W rozległych systemach stanowi ono jeden z problemów, który najprościej rozwiązać właśnie przy okazji wdrażania jednego z dwóch powyższych rozwiązań. Najbardziej pożądane jest tzw. samodzielne resetowanie haseł.

Samodzielne resetowanie zwykle zdefiniowane jest jako proces lub technologia, która umożliwia użytkownikowi samodzielne zdefiniowanie nowego hasła (najlepiej bez angażowania w ten proces Help Desku), jeśli stare zostało zapomniane lub wykradzione.

W takiej sytuacji użytkownik powinien móc skorzystać np. ze specjalnej funkcjonalności okna logowania na swojej stacji roboczej, korzystając z przeglądarki internetowej swojej lub na innej stacji roboczej lub skontaktować się z Help Deskiem telefonicznie. W procesie tym użytkownik potwierdza swoją tożsamość w inny sposób niż za pomocą hasła, np. odpowiadając na serię pytań, korzystając ze sprzętowego tokenu lub czytnika danych biometrycznych. Po pozytywnej weryfikacji tożsamości użytkownik definiuje nowe hasło lub generuje losowe hasło tymczasowe, które będzie musiał zmienić po pierwszym pomyślnym zalogowaniu się na stację roboczą.

Takie rozwiązanie problemu przenosi ciężar związany z resetowaniem haseł z Help Desku na użytkowników. Ponadto, eliminuje też jedno z większych zagrożeń występujących w sytuacji, gdy za czynność tę odpowiedzialny jest Help Desk. Chodzi tu oczywiście o ataki z wykorzystaniem socjotechnik mających na celu podszycie się pod użytkownika i wymuszenie w jego imieniu zmiany hasła.

Samodzielne resetowanie haseł daje też możliwość autentykacji użytkownika przy użyciu silnych mechanizmów, zanim zostanie on uprawniony do zmiany hasła. Wymaga to jednak wcześniejszego wydania tokenów, kart albo zgromadzenia danych biometrycznych. W przypadku scenariusza autentykacji opartego na serii pytań i odpowiedzi udzielanych w trakcie rozmowy telefonicznej wymagane jest również wcześniejsze zgromadzenie dodatkowych informacji o użytkowniku.

Niektóre systemy resetowania haseł opierają się na bibliotekach DLL GINA-wrapper, ułatwiających użytkownikom zmianę hasła zapomnianego lub zablokowanego. Wiąże się to jednak z instalacją oprogramowania klienckiego, co może być pracochłonne i kosztowne. Istnieją też rozwiązania umożliwiające stworzenie w celu awaryjnej autentykacji specjalnego konta domenowego, np. nazwanego „reset”. Pojawiły się też produkty umożliwiające zautomatyzowaną autentykację telefoniczną.

Funkcjonalność samodzielnego resetowania haseł może współpracować zarówno z SSO, jak i z rozwiązaniami opartymi na synchronizacji haseł. Jako samodzielne rozwiązanie jest ona stosunkowo prosta we wdrażaniu, wymaga jednak nieco czasu zaraz po nim, aby zacząć w pełni funkcjonować. Jest tak dlatego, że gromadzenie kompletnych danych o użytkownikach, umożliwiających ich awaryjną telefoniczną autentykację lub wydanie dodatkowych kart czy tokenów, może być czasochłonne i generować dodatkowe koszty.

Przegląd istniejących architektur SSO
SSO nie oznacza pojedynczego rozwiązania, które jest powielane przez kolejnych producentów tego typu narzędzi. Istnieje kilka architektur SSO. Są to m.in. E-SSO, Web SSO, J2EE SSO i JOSSO, SSO federacyjne oraz SSO transakcyjne. Pomimo wspólnego celu wszystkie one prezentują nieco inne podejście.

I tak na przykład, do obsługi użytkowników z wewnątrz danej organizacji, co do których mamy pewną kontrolę choćby w kwestii oprogramowania i zabezpieczeń instalowanych na ich stacjach roboczych, bardziej odpowiednie będzie podejście prezentowane przez E-SSO, dające dostęp do WWW i aplikacji danej organizacji wszystkim ich użytkownikom. Rozwiązania typu Web, J2EE czy federacyjne SSO będą z kolei bardziej odpowiednie do obsługi użytkowników zewnętrznych, tzn. z dostępem do zasobów organizacji np. za pośrednictwem stron przeglądarki WWW.

Oczywiście rozwiązania E-SSO i Web SSO nie wykluczają się wzajemnie i mogą być implementowane jednocześnie. Ma to szczególnie uzasadnione zastosowanie w przypadku użytkowników mobilnych.

Istnieje też konkurencyjna technologia oparta na synchronizacji haseł, niezaliczana do kategorii SSO i dlatego opisana osobno. Przyjrzyjmy się teraz dokładniej poszczególnym architekturom SSO.

E-SSO
Rozwiązania w technologii E-SSO (Enterprise Single Sign-On), po pierwszym zalogowaniu się przez użytkownika, przechwytują obsługę kolejnych logowań do aplikacji i automatycznie wypełniają pola typu login i hasło. Użytkownik ma zatem pojedyncze hasło tylko do klienta E-SSO, który zarządza dalszymi logowaniami, jednak w ramach poszczególnych aplikacji zarówno hasła, jak i loginy mogą się różnić. W kierunku ujednolicenia wszystkich haseł użytkownika zmierza natomiast opisana poniżej synchronizacja haseł.

Hasła do poszczególnych aplikacji mogą więc pozostać niezmienione, co jest dla użytkownika E-SSO niewidoczne, gdyż po jego uwierzytelnieniu logowaniem do pozostałych zasobów zajmuje się już główny serwer autentykujący. Technologia ta pozwala zatem na współpracę np. z aplikacjami starszej daty, które nie są w stanie powierzyć procesu autentykacji aplikacji zewnętrznej. Aplikacje te nie muszą nawet „wiedzieć”, że użytkownicy logują się do ich zasobów za pośrednictwem E-SSO, a administrujący dostępem do nich nadal zarządzać mogą hasłami i loginami tak, jak to robili dotychczas.

E-SSO wyręcza użytkownika od żmudnego wpisywania loginów i haseł. Użytkownik nadal ma ich wiele, ale nie musi ich już pamiętać. Dzięki E-SSO użytkownik korzysta tylko z jednej lub dwóch par login–hasło:

  • jednej, jeśli E-SSO przechwytuje hasło już w trakcie logowania do systemu operacyjnego,
  • dwóch, jeśli po logowaniu do systemu użytkownik musi najpierw zalogować się do klienta E-SSO.

SSO umożliwia też centralne zarządzanie procesem autentykacji i autoryzacji użytkowników oraz uproszczenie śledzenia ich aktywności i jej audytowanie. Minusem tego rozwiązania jest jednak konieczność integracji wszystkich aplikacji z serwerem autentykującym E-SSO, co czasami pociąga za sobą zmiany w ich kodzie lub konfiguracji. E-SSO wymaga też instalacji i konfiguracji oprogramowania klienckiego na każdej stacji roboczej. Przy dużej ich liczbie może to oczywiście stanowić pewne utrudnienie i generować dodatkowe koszty. Z powyższych przyczyn E-SSO jest znacznie trudniejsze w implementacji niż sama synchronizacja haseł.

Jak już wspomnieliśmy, E-SSO wymaga stworzenia repozytorium loginów i haseł do aplikacji, z których korzystają użytkownicy. Stanowi to pewną różnicę w stosunku do rozwiązań opartych na synchronizacji haseł, wymagających składowania samych loginów, co jest pewnym ułatwieniem. W przypadku SSO konieczność gromadzenia tych danych wydłuża cały proces wdrażania. Baza taka może też powstać np. poprzez rozbudowę już istniejącej struktury katalogowej, opartej na Active Directory, LDAP czy NDS. Korzystanie w tym przypadku z istniejących już struktur zawsze będzie rozwiązaniem korzystniejszym.

Pamiętajmy, że do tak utworzonej bazy musi być szybki i łatwy dostęp, gdyż jej awaria uniemożliwi użytkownikom dostęp do wszystkich aplikacji. Powinna też być bezpieczna, gdyż nieuprawniony do niej dostęp skompromituje dostęp wszystkich użytkowników do wszystkich zasobów.

Niektóre systemy E-SSO wspierają bardziej zaawansowane mechanizmy uwierzytelniania niż tylko hasła, a dokładniej: karty magnetyczne i chipowe, sprzętowe tokeny i czytniki biometryczne. Pary login–hasło do poszczególnych aplikacji, zamiast na stacjach roboczych lub serwerze, mogą też być przechowywane na kartach typu Smart Card.

Istnieje wielu dostawców E-SSO. Do najbardziej znanych produktów należą: Passlogix, Citrix password manager, EMC/RSA Signon Manager, ActivIdentity, Version3, IBM/Tivoli, CA/eTrust czy Imprivata.

Resetowanie hasła w E-SSO
Ponieważ E-SSO wymaga bezpiecznego składowania wielu loginów i haseł użytkowników, informacje te muszą być należycie zaszyfrowane w stworzonej w tym celu bazie. Generalnie, dane każdego użytkownika szyfrowane są kluczem stowarzyszonym z podstawowym jego hasłem dostępu do E-SSO. Może to być hasło windowsowe, Active Directory lub NDS lub całkiem odrębne hasło.

Co jednak zrobić, gdy użytkownik zapomni podstawowego hasła do E-SSO? Niestety, w takiej sytuacji wszystkie jego dotychczasowe loginy i hasła do aplikacji mogłyby zostać utracone. Nawet jeśli hasło E-SSO zostanie zresetowane, dane te pozostałyby niedostępne, gdyż zaszyfrowane zostały kluczem powiązanym ze starym – zapomnianym hasłem. Zresetowanie hasła E-SSO użytkownika oznaczałoby więc, że jego profil zostanie utracony i będzie on musiał na nowo wyrobić hasła do wszystkich aplikacji, a następnie wprowadzić je do bazy E-SSO.

Aby rozwiązać ten problem, wiele produktów E-SSO zapewnia tylną furtkę umożliwiającą odzyskiwanie danych użytkownika po resecie jego hasła. Najprostszą wykorzystywaną tu metodą jest składowanie aktualnego hasła do E-SSO w bezpiecznej lokalizacji i używanie go właśnie w sytuacjach, gdy zostanie ono zapomniane lub zgubione i przez to skompromitowane.

Idealnym rozwiązaniem byłaby jednak integracja mechanizmu odpowiedzialnego za reset hasłem z „tylną furtką” w taki sposób, że zaraz po zmianie przez użytkownika hasła E-SSO na nowe wszystkie dane zaszyfrowane starym kluczem są deszyfrowane i szyfrowane nowym. Proces ten powinien być przezroczysty dla użytkownika, gdyż po zmianie hasła nadal będzie mógł się on logować do swoich aplikacji. Istnieją już nawet tego typu wdrożenia, np. na bazie technologii firmy P-Synch.

Web-SSO
Technologia Web-SSO zwana jest też Web-AM (Web Access Management) i opiera się na ścisłej współpracy z aplikacjami i zasobami, do których dostęp uzyskiwany jest za pośrednictwem przeglądarki internetowej. Działa to tak, że każda próba dostępu do zasobów sieciowych jest przechwytywana albo przez serwer proxy, albo przez specjalne oprogramowanie zainstalowane na każdym z docelowych serwerów. Każdy niezalogowany użytkownik, który spróbuje uzyskać do nich dostęp, przekierowany zostanie do serwisu dokonującego autentykacji i autoryzacji. Dopiero jeśli się one powiodą, przyznany zostaje mu dostęp do żądanych zasobów.

W technologii tej do śledzenia stanu autoryzacji danego użytkownika najczęściej używane są popularne ciasteczka (cookies). Właśnie z nich wydobywane są dane identyfikujące logującego się.

J2EE SSO i JOSSO
J2EE SSO (Java 2 Platform, Enterprise Edition) i JOSSO (Java Open Single Sign On) stanowią rozwiązania SSO przeznaczone do aplikacji sieciowych. Opierają się one na oprogramowaniu typu Open Source (z licencją Apache/BSD) umożliwiającym autentykację i autoryzację użytkowników w ramach wielu aplikacji i serwerów sieciowych, jak np. Apache HTTP Server, Apache Tomcat, JBOSS, ASP, PHP itd., na podstawie danych zgromadzonych w repozytoriach. Komunikacja pomiędzy JOSSO a bazami (zawierającymi informacje umożliwiające uwierzytelnienie) odbywa się po protokole LDAP (Lightweight Directory Access Protocol) lub za pomocą połączeń JDBC. Ponadto, w celu autentykacji i kontroli uprawnień, JOSSO implementuje JAAS (Java Authentication and Authorization Service), natomiast sama funkcjonalność SSO udostępniana jest dzięki technologii SOAP i HTTP, co umożliwia prostą integrację z aplikacjami nienapisanymi w Javie.

SOAP (Simple Object Access Protocol, później znany też jako Service Oriented Architecture Protocol) jest natomiast protokołem wymiany wiadomości opartych na języku XML, korzystającym z HTTP/HTTPS. SOAP tworzy podstawową warstwę stosu serwisów WWW, dostarczając prosty mechanizm komunikacji wykorzystywany przez warstwy działające na wyższym poziomie abstrakcji.

SSO federacyjne Federacje to stosunkowo nowe odkrycie w dziedzinie SSO. Technologia ta korzysta z istniejących standardowych protokołów komunikacyjnych w celu przekazania z jednej aplikacji tożsamości danego użytkownika do drugiej aplikacji. Rozwiązanie to ma oczywiście za zadanie wyeliminowanie nadmiarowej autoryzacji, a opiera się na języku SAML (Security Assertion Markup Language) i protokole komunikacyjnym WS-Security (Web Services Security).

SAML to język oparty na standardzie XML i umożliwiający wymianę danych, za pomocą których dokonywana jest autentykacja i autoryzacja. Wymiana ta ma najczęściej miejsce pomiędzy różnymi domenami zabezpieczeń, np. pomiędzy dostawcą usługi a „dostawcą” tożsamości (usługą udostępniającą dane o tożsamości danego użytkownika).

WS-Security (Web Services Security) jest protokołem komunikacyjnym dostarczającym mechanizmy umożliwiające implementację zabezpieczeń serwisów sieciowych. Zawiera on specyfikację, jak w ich ramach wdrożyć integralność i poufność, czyli jak korzystać z SAML, Kerberos, certyfikatów w formacie X.509, jak dołączać nagłówki z podpisem elektronicznym, nagłówki szyfrowane do wiadomości SOAP, a także tokeny i bilety Kerberos. WS-Security działa więc w warstwie aplikacji i zapewnia tzw. end-to-end security.

W kontekście SSO federacyjnych powstał też termin tożsamości federacyjnej, czyli takiej, która jest w pełni przenośna pomiędzy różnymi domenami bezpieczeństwa. Celem jest tu zapewnienie użytkownikom jednej domeny bezpiecznego i niezakłóconego dostępu do zasobów innej domeny, bez potrzeby wykonywania nadmiarowych czynności ze strony ich administratorów. Idea tożsamości federacyjnej uwzględnia komunikację w obrębie środowisk kontrolowanych tylko przez użytkowników, jak też korporacyjnych. Tożsamość federacyjna umożliwia więc zarówno komunikację typu u2u (user-to-user), u2a (user-to-application), jak i a2a (application-to-application) i to w warstwie przeglądarki internetowej, jak również serwisów sieciowych czy SOA (Service-Oriented Architecture). Komunikacja ta może też przebiegać według różnych scenariuszy i uwzględniać różne poziomy zaufania i zabezpieczeń. Wdrożenie podejścia federacyjnego umożliwia np. popularne rozwiązanie typu Open Source – OpenID.

SSO transakcyjne
SSO transakcyjne zwane jest również transakcyjnym zarządzaniem dostępu. Technologia ta współpracuje głównie z serwisami sieciowymi, do których mogą mieć dostęp tylko użytkownicy końcowi lub aplikacje.

Synchronizacja haseł
Konkurencyjną do SSO technologią jest synchronizacja haseł. Pod tą nazwą kryje się każdy proces lub technologia, która ułatwia użytkownikowi utrzymanie pojedynczego hasła, objętego pojedynczą polisą bezpieczeństwa, w obrębie wielu systemów i aplikacji. Tym właśnie różni się ona od SSO, przy którym hasła i loginy do poszczególnych aplikacji i systemów pozostają w rzeczywistości takie same, jednak nie jest to widoczne dla użytkownika uwierzytelnianego pojedynczym hasłem przez oprogramowanie klienckie (E-SSO).

Synchronizacja haseł stanowi bardzo efektywny sposób na rozwiązanie problemów z zarządzaniem hasłami w sieciach korporacyjnych.

Istnieją dwie metody implementacji synchronizacji haseł:

  • Synchronizacja przezroczysta, gdzie każda zmiana w którymś z systemów lub aplikacji jest automatycznie propagowana za pośrednictwem systemu zarządzającego hasłami do innych aplikacji i systemów.
  • Synchronizacja z wykorzystaniem aplikacji sieciowej, w której użytkownik proszony jest o zmianę wszystkich swoich haseł jednocześnie. Eliminuje to korzystanie z narzędzi i interfejsów charakterystycznych dla poszczególnych systemów czy aplikacji, których zmiana ta dotyczy.

Systemy zarządzające hasłami wymagają do bezproblemowej pracy wcześniejszego zdefiniowania i utrzymywania aktualnego rejestru loginów każdego użytkownika w ramach każdej aplikacji czy systemu (a nie jak w przypadku E-SSO loginów i haseł). Jeśli loginy są identyczne w całym środowisku, stworzenie takiego rejestru jest oczywiście najprostsze. Jeśli loginy danego użytkownika różnią się, administrator albo poszczególni użytkownicy definiują, który użytkownik ma jaki login i do której aplikacji i zostaje to zapisane w repozytorium.

W dobrym narzędziu do synchronizacji haseł wyodrębnić można zwykle kilka modułów:

  • synchronizacji zmian haseł – wykorzystywany przez użytkowników do zmiany ich własnych haseł ze starych na nowe. Oprogramowanie zapewnia, że zmiana rozpropagowana zostanie na wszystkie systemy, do których użytkownik ma dostęp;
  • synchronizacji resetowania haseł – wykorzystywany przez administratorów lub pracowników Help Desku w celu zdefiniowania nowego hasła użytkownika bez względu na jego obecną wartość. Podobnie jak powyżej oprogramowanie to zapewnia spójność zmiany w obrębie wszystkich aplikacji i systemów;
  • synchronizacji autoresetu haseł – wykorzystywany przez użytkowników do zmiany własnego hasła na nowe bez względu na jego obecną wartość. Aby móc tego dokonać, użytkownik musi dostarczyć jakiś inny dowód swojej tożsamości. Funkcjonalność ta wykorzystywana jest, gdy użytkownik zapomni swojego dotychczasowego hasła lub zostanie ono zablokowane;
  • propagacji hasła – odpowiedzialny za przechwytywanie lokalnych zmian haseł (w obrębie stacji roboczej) i przekazywanie innym hostom polecenia ich zmiany.

Pewną przewagą synchronizacji haseł nad rozwiązaniami SSO jest brak konieczności instalacji oprogramowania klienckiego, znacznych zmian konfiguracyjnych systemu czy jego pracochłonnego utrzymania. W szczególnych przypadkach dodatkowe oprogramowanie i rekonfiguracja będą jednak i tu konieczne.

Na rynku pojawiło się wiele rozwiązań tego typu. Wystarczy wymienić np. takie, jak P-Synch firmy MTech, SecurPass firmy Proginet i SAM Password Synchronization firmy Systor. Przyjrzyjmy się teraz dokładniej wspomnianym wcześniej dwóm rodzajom synchronizacji haseł: przezroczystej synchronizacji i synchronizacji z wykorzystaniem aplikacji sieciowej.

Synchronizacja przezroczysta
Przezroczysta synchronizacja haseł wyzwalana jest przez każdą zmianę hasła z poziomu systemu, a nawet czasami i aplikacji. Nowe hasło jest automatycznie przekazywane do innych obiektów należących do tego samego użytkownika w tym lub innym systemie czy aplikacji. Jeśli więc użytkownik zmieni swoje hasło, poddawane jest ono kontroli na zgodność z polisą lokalną (charakterystyczną dla systemu, w którym następuje zmiana), a następnie z polisą globalną (charakterystyczną dla całej organizacji i wszystkich działających w niej systemów). Jeśli zostanie ono zaakceptowane, zostaje uaktualnione jako obowiązujące zarówno w systemie, gdzie zmiana jest bezpośrednio dokonywana, jak i we wszystkich pozostałych systemach i aplikacjach, gdzie użytkownik ma swoje konto. Przykładowy proces zmiany hasła w większości rozwiązań w tej technologii wygląda następująco:

  1. Użytkownik zmienia hasło, podając login, hasło aktualne i nowe.
  2. Serwer odpowiedzialny za autentykację i autoryzację użytkowników (np. Windows, Unix, OS/390, OS/400, Active Directory, Sun LDAP, IBM LDAP lub Oracle Internet Directory) przeprowadza walidację i ocenę jakości hasła nowego, a następnie przekazuje je do walidacji globalnej, dokonywanej przez serwer.
  3. W tym celu nawiązywane jest szyfrowane połączenie i hasło przekazane zostaje do walidacji z globalnymi polisami ustanowionymi w danej organizacji.
  4. W przypadku gdy nowe hasło narusza ustanowioną globalną polisę, użytkownik jest powiadamiany o konieczności jego modyfikacji, a całe zdarzenie jest logowane. W przeciwnym razie host, na którym zainicjowana została zmiana hasła, zmienia je i powiadamia o tym serwer główny.
  5. W tym celu zestawiane jest kolejne szyfrowane połączenie z serwerem, za pomocą którego przekazane zostaje żądanie synchronizacji hasła.
  6. Nowe hasło uaktualniane jest przez serwer w każdym systemie i aplikacji, do którego użytkownik ma konto. Każdy przypadek niepowodzenia jest logowany, a użytkownik jest o nim informowany.

W powyższym przypadku często niedocenianą zaletą jest fakt, że użytkownik dokonuje zamiany hasła poprzez znany sobie od dawna interfejs. Może się to z pozoru wydawać błahostką, weźmy jednak pod uwagę, ile dobrze zarządzanych projektów upadło przez powszechnie znaną niechęć użytkowników do wszelkich zmian i innowacji.

Synchronizacja haseł z wykorzystaniem aplikacji sieciowej
W odróżnieniu od przezroczystej synchronizacji, gdzie zmiana hasła może nastąpić na poziomie systemu operacyjnego, technologia ta wymaga skorzystania z aplikacji sieciowej dostępnej za pośrednictwem przeglądarki WWW. Dzięki niej zestawiana jest komunikacja z głównym serwerem, który waliduje nowe hasło i później propaguje je we wszystkich systemach, w których dany użytkownik ma założone konta.

Metoda ta ma zasadniczą przewagę nad tą wykorzystującą wbudowane mechanizmy systemu operacyjnego. Dzięki użyciu odrębnej aplikacji użytkownik może sprecyzować, które z systemów dana zmiana hasła obejmie. Nie każda zmiana musi więc być propagowana do wszystkich systemów. Pominięte w aktualizacji systemy można skonfigurować w taki sposób, aby historia wykorzystywanych w nich haseł i historia haseł w grupie systemów, którą aktualizacja obejmuje, składowane były w jednej bazie. Umożliwi to uniknięcie powtarzania haseł w obrębie wszystkich systemów. Niektóre systemy można też całkowicie wyłączyć spod synchronizacji.

SSO a synchronizacja haseł
Dwie opisane powyżej technologie różnią się od siebie zasadniczo zarówno pod kątem funkcjonalnym, jak i wdrożeniowym. Co ciekawe, możliwe jest ich zintegrowanie. Przyjrzyjmy się jednak najpierw krótkiemu porównaniu ich cech charakterystycznych.

Zarówno SSO, jak i synchronizacja haseł mają swoje wady i zalety.

Synchronizacja haseł
Zalety:

  • Mniej haseł do zapamiętania,
  • Mniejsze obciążenie Help Desku,
  • Proste wdrożenie,
  • Brak konieczności instalacji oprogramowania klienckiego,
  • Duża automatyzacja (brak ingerencji ze strony użytkownika),
  • Wzmocnienie siły haseł,
  • Brak pojedynczego punktu awarii,
  • Systemy z wieloma kanałami dostępu pozostają dostępne z dowolnego miejsca i za pomocą różnych technologii, jak np. WWW czy telefon

Wady:

  • Użytkownicy nadal muszą logować się do każdej aplikacji z osobna,
  • Hasła do wszystkich aplikacji są identyczne – kompromitacja jednego kompromituje pozostałe,
  • Nieuwzględnienie aplikacji zarządzanych przez strony trzecie, czyli np. partnerów i klientów oraz zwykle – aplikacji z niewielką liczbą użytkowników

Single Sign-On
Zalety:

  • Eliminacja konieczności logowania się do każdej aplikacji z osobna,
  • Różne hasła do różnych aplikacji,
  • W większości przypadków kompromitacja pojedynczego hasła do aplikacji nie prowadzi do kompromitacji pozostałych haseł,
  • Nie wymaga instalacji oprogramowania na serwerach aplikacyjnych,
  • Nie wymaga szczegółowej wiedzy na temat aplikacji, które podlegają integracji,
  • Możliwość wspierania logowania zarówno do lokalnych, jak i zewnętrznych aplikacji (np. tych należących do partnerów i klientów),
  • Możliwość wzmocnienia autentykacji przy użyciu sprzętowych tokenów, autentykacji wielopoziomowej, kart lub czytników biometrycznych

Wady:

  • Pracochłonna i kosztowna instalacja oprogramowania klienckiego na stacjach roboczych wszystkich użytkowników,
  • Brak wsparcia dla aplikacji z wieloma interfejsami logowania, typu strona WWW lub połączenie telefoniczne,
  • Pojedynczy punkt awarii – jeśli SSO zawiedzie, użytkownicy stracą dostęp do wszystkich aplikacji,
  • Kompromitacja hasła do SSO kompromituje wszystkie hasła użytkownika,
  • Wymaga pracochłonnej rejestracji loginów i haseł wszystkich użytkowników do wszystkich aplikacji,
  • Polega na technologii „screen scraping” (przy wypełnianiu okien logowania), która może być kosztowna we wdrożeniu i utrzymaniu szczególnie przy obsłudze wielu typów stacji roboczych i niestandardowych platform systemowych

Podsumowując, synchronizacja haseł i SSO próbują rozwiązywać te same problemy: złożoność zarządzania hasłami prowadzącą do wzrostu kosztów, spadku produktywności i bezpieczeństwa zasobów informatycznych.

Obydwa podejścia mają mocne i słabe strony. Synchronizacja haseł jest w miarę tania we wdrażaniu, gdyż nie wymaga instalacji dodatkowego oprogramowania na stacjach roboczych, wymaga też gromadzenia niewielkiej ilości danych, ale użytkownicy nadal logują się do każdej aplikacji oddzielnie. Z drugiej strony, SSO jako technologia bardziej kosztowna wymaga instalacji oprogramowania klienckiego i stworzenia repozytorium danych. Korzystający z niej użytkownicy nie muszą się jednak logować do każdej aplikacji osobno.

Decydując się na SSO, należy pamiętać, że technologia ta sama z siebie źle współgra z niezależnymi rozwiązaniami umożliwiający resetowanie haseł, gdyż zawartość centralnej bazy SSO szyfrowana jest kluczem powiązanym z aktualnym hasłem. Podobnie wygląda też współpraca z niezależnymi narzędziami do synchronizacji haseł, gdyż nowe hasła nie są automatycznie uaktualniane w bazie SSO. Dopiero integracja z narzędziami do samodzielnego resetowania haseł i ich synchronizowania eliminuje te konflikty.

Integracja SSO i synchronizacji haseł
Jeśli użytkownik zmieni hasło z poziomu danej aplikacji (do której loguje się, wykorzystując SSO) lub zrobi to system synchronizacji haseł, logowanie za pomocą SSO stanie się niemożliwe, gdyż hasło istniejące w bazie SSO będzie już przestarzałe. W takiej sytuacji SSO zawiedzie lub spróbuje wymusić na użytkowniku zmianę hasła. Dokonywanie takich zmian za każdym razem, gdy tylko zmienione zostanie hasło w którejś z aplikacji, może być jednak uciążliwe. Rozwiązaniem będzie zastosowanie takiego systemu SSO, który będzie w stanie automatycznie uaktualnić swoją bazę po każdej zmianie hasła.

Wskazana jest więc integracja synchronizacji haseł z rozwiązaniami SSO, która dodatkowo umożliwia skuteczniejsze wykorzystanie samodzielnego resetowania głównego hasła SSO. Zaletą integracji jest więc automatyczne uaktualnianie bazy SSO, co znacznie upraszcza jej utrzymanie. Ponadto użytkownicy mogą logować się do aplikacji z kilkoma interfejsami logowania (np. za pośrednictwem przeglądarki WWW). Niestety, wdrożenie zintegrowanego podejścia wymaga większej znajomości poszczególnych aplikacji, a często też ich odrębnej konfiguracji.

PODZIEL SIĘ

BRAK KOMENTARZY

ZOSTAW ODPOWIEDŹ