dodany: 28.12.2012 | tagi: , ,

Autor:

SSO – ułatwienie czy przekleństwo?

4

Współczesne systemy operacyjne umożliwiają konfigurację wielu kont – profili użytkowników. Komputer przeciętnego śmiertelnika ma jednak skonfigurowane w systemie operacyjnym tylko jedno takie konto. Często włączone jest automatyczne logowanie na to konto po uruchomieniu systemu i nie myślimy o tym, że trzeba wpisać login i hasło. Wszystko po to, żeby można było rozpocząć używanie jak najszybciej i nie musieć pamiętać zbędnych danych (w końcu skoro sami korzystamy z komputera, to po co nam logowanie? :-))

Po uruchomieniu/wznowieniu systemu uruchamiamy aplikacje, otwieramy przeróżne strony internetowe i najczęściej pozwalamy przeglądarce zapamiętać dane logowania, żeby było szybciej, prościej i wygodniej. Całe szczęście większość usług czy aplikacji umożliwia zapamiętanie loginu i hasła albo nawet ich nie wymaga (z reguły dotyczy to programów instalowanych w systemie operacyjnym komputera). Zasada ta dotyczy komputerów prywatnych. Jak to wygląda w sprzęcie wykorzystywanym w pracy? Wielu z Was, pracujących w niedużych firmach, pewnie stwierdzi – „oczywiście wygląda tak samo, z tą różnicą że używam innych programów”. A jak ta sytuacja zmienia się w dużych firmach i korporacjach? Czy nadal jest to tak bezproblemowe?

Nie ma jednej odpowiedzi – wszystko zależy od infrastruktury IT w danej firmie, od wykorzystywanych aplikacji, systemów, polityki bezpieczeństwa i innych uwarunkowań. Może być tak, że korzysta się głównie z lokalnych programów, a systemy intranetowe są rzadko wykorzystywane. Może być odwrotnie – lokalne aplikacje są w mniejszości, a użytkownicy masowo muszą korzystać ze współdzielonych systemów lub portali intranetowych wymagających złożonych mechanizmów uwierzytelnienia i autoryzacji. Pierwszy wariant rzeczywiście mało różni się od użytku prywatnego. Drugi już wymaga dużo więcej zarówno od użytkowników, jak i działu IT w firmie.

Im więcej przeróżnych aplikacji i systemów dostępnych dla użytkowników, tym więcej może być odmiennych sposobów uzyskania uprawnionego dostępu do ich zasobów. Z reguły duże firmy i korporacje nie wykorzystują jednorodnych rozwiązań, a są one tworzone i dostarczane przez wielu dostawców na bazie rożnych technologii, a także mogą spełniać zupełnie rozbieżne oczekiwania poszczególnych działów organizacji. To powoduje, że nie jest łatwe (lub jest niemożliwe) opracowanie jednakowego sposobu logowania do wszystkich dostępnych systemów. Oczywiście, im więcej różnych systemów z odmiennymi metodami logowania, dopuszczalną składnią haseł, czy też częstotliwością wymuszenia zmiany hasła na nowe (co 30 dni, co 90 dni, a nawet wcale), tym więcej danych dostępowych do zapamiętania i tym większe ryzyko nieumyślnego ich ujawnienia, utraty, zapomnienia itd. Niektórzy użytkownicy w takiej sytuacji próbują sobie radzić z mnogością parametrów zapisywaniem wszystkich loginów i haseł na przysłowiowych żółtych karteczkach i dla ułatwienia trzymają je w pobliżu komputera. Jest to niewłaściwe zachowanie, ale jest wymuszone skomplikowaniem sposobów dostępu do aplikacji.

 

SSO jako kombajn do logowania

Jak poradzić sobie z takim zagmatwaniem dostępów i wdrożyć podejście ułatwiające życie użytkownikom? Nie zawsze można (i jest to bezpieczne) zrezygnować z wprowadzania danych dostępowych, a czasem spowodowałoby to jeszcze bardziej utrudnione korzystanie z systemów i aplikacji. Pomijając inne sposoby zmniejszania rygoru bezpieczeństwa, chciałbym szerzej wspomnieć o podejściu, które rozwiązuje wiele problemów opisanych powyżej, ale wymaga kompleksowej zmiany architektury i nie zawsze jest wykonalne w 100%. Rozwiązanie to zostało nazwane SSO – Single Sign-On („pojedyncze logowanie” lub też „jednokrotna rejestracja”) – czyli metoda uzyskiwania przez użytkowników dostępu do zasobów – aplikacji, systemów, które są odrębne i najczęściej mają różne mechanizmy logowania. Jest kilka rodzajów tego podejścia, ale chciałbym się skupić na jednym z nich wykorzystującym tickety do logowania. Jeżeli jesteście zainteresowani pozostałymi, zapraszam do Wikipedii, gdzie znajdziecie start do dalszych poszukiwań.

Rozwiązanie to polega na uruchomieniu centralnej usługi uwierzytelniającej (niektórzy zwą to „autentykacją” przenosząc zwrot wprost z języka angielskiego), która zostaje zintegrowana z najlepiej wszystkimi systemami, które są wykorzystywane. Użytkownik raz podaje login oraz hasło i dostaje się do każdej aplikacji zintegrowanej z SSO. Dzięki temu nie trzeba każdorazowo podawać najczęściej różnych loginów i haseł ani też pamiętać wielu kombinacji danych. W praktyce wygląda to tak, że po wejściu do aplikacji korzystającej z SSO użytkownik zostaje przekierowany do usługi uwierzytelniającej. Tam się loguje, a następnie zostaje mu przydzielony unikatowy identyfikator sesji (ticket), który następnie jest przekazywany do aplikacji. Na tej podstawie aplikacja jest w stanie stwierdzić, że osoba uzyskująca dostęp jest tym, za kogo się podaje, a także, że jej sesja nie wygasła i może być dopuszczona do zasobów systemu.

Powyższa ścieżka dostępu z wykorzystaniem tego podejścia może się wydawać prosta, jednak aby zadziałała, musi być przeprowadzona czasem trudna (lub nawet niemożliwa z różnych względów) integracja danego systemu czy aplikacji z usługą SSO. Usługa musi być świadoma istnienia systemu, do którego ma wpuszczać użytkowników, a dana aplikacja musi wiedzieć, że każde logowanie ma być uzgadniane z SSO. Trudność tu polega na tym, że w firmach często stosuje się naprawdę różnorakie rozwiązania i konieczność spięcia każdego z nich z osobna z centralną usługą może generować wysokie koszty i musi być mocno uzasadniona ekonomicznie. Pomimo oczywistej wygody rozwiązania może się okazać, że nakłady finansowe potrzebne na kompleksowe wdrożenie takiego rozwiązania są tak wysokie, że zarząd firmy lub dyrekcja działu IT nie podejmie się zmiany architektury. Dużo łatwiejsza jest integracja nowych planowanych i powstających aplikacji, które mogą już w założeniach przewidywać konieczność spięcia z SSO.

 

Zalety i wady stosowania w firmie

Pisząc o wygodzie użytkowników nie można zapomnieć o działach IT i wsparcia (Help Desk) – te grupy pracowników także dość mocno skorzystają z takiego rozwiązania. Nakład pracy konieczny na utrzymanie mechanizmów logowania jest dużo mniejszy, drastycznie spada liczba zgłoszeń użytkowników z prośbą o reset hasła, wygenerowanie nowego, pomoc przy dostępie do aplikacji itp. Obsługa interfejsów pomiędzy aplikacjami i usługą SSO można zautomatyzować, co nie wymaga wiele pracy już w trakcie utrzymania tych rozwiązań.

Trzeba pamiętać, że istnieje także zdecydowana wada takiego rozwiązania – jeden punkt dostępu do wszystkich możliwych (zintegrowanych) systemów i aplikacji – oznacza to, że potencjalny włamywacz musi pokonać tylko to jedyne zabezpieczenie, po czym ma dostęp do innych usług. Zadaniem poważnej usługi SSO jest oczywiście zapewnienie odpowiedniego poziomu bezpieczeństwa, ale jest to już większe wyzwanie i wymaga większej dbałości i monitoringu.

Nie chciałbym w tym artykule się odnosić do konkretnego rozwiązania SSO – istnieją zarówno komercyjne, jak i darmowe. Myślę, że najlepszym źródłem, z którego możecie zaczerpnąć sporo wiedzy na temat dostępnych opcji jest załączona tabela na Wikipedii – pomimo braku szczegółowych opisów z łatwością dotrzecie do szczegółów mając ten świetny zbiorczy materiał porównawczy.

To, czy wykorzystane może być rozwiązanie SSO płatne lub darmowe, zależy nie tylko od możliwości finansowych firmy – trzeba wziąć pod uwagę możliwości integracyjne, ograniczenia i współpracę z istniejącymi systemami i usługami. Może się okazać, że produkt komercyjny, kosztujący określoną kwotę, jest finalnie tańszy, niż pozornie darmowe rozwiązanie open source. Duży wpływ ma dostępna pula gotowych konektorów do rozwiązań, dzięki czemu nie ma konieczności ich tworzenia od podstaw. Wdrożenie SSO musi być poprzedzone analizą wszystkich rozwiązań, które mają być spięte, a dodatkowo testami. W zależności od firmy może się też okazać, że są kluczowe systemy, które są tak niesamowicie drogie w integracji z centralną usługą uwierzytelniającą, że nie będzie w ogóle fizycznej możliwości wdrożenia procesu logowania opisanego wcześniej.

W takiej sytuacji pomocne mogą być rozwiązania stosowane w dużych firmach i korporacjach, działające w nieco inny sposób niż powyższy. Nie wymagają integracji z systemami zastanymi, aplikacjami czy usługami, nie jest konieczne ich modyfikowanie i ponoszenie kosztów na dostosowanie do usługi SSO. Dla użytkownika są one dużo bardziej transparentne niż usługa wykorzystująca tickety i sprawiają wrażenie po wdrożeniu, jakby się prawie nic nie zmieniło – nadal używamy formularzy danej aplikacji czy usługi, nie ma osobnego i nowego ekranu logowania. W skrócie proces logowania działa następująco: użytkownik otwiera dany system czy aplikację, widzi formularz wprowadzania danych logowania, a w tym momencie rozwiązanie przechwytuje formularz i automatycznie wprowadza dane użytkownika, do którego należy jedynie zatwierdzenie ich i wejście do aplikacji. Rozwiązania takie wymagają utworzenia odpowiednich konfiguracji szablonów i definicji dla poszczególnych rozwiązań określających obsługę pól wprowadzania danych logowania. Oprócz automatycznego wprowadzania danych możliwa jest zmiana hasła po wygaśnięciu starego i wiele innych funkcji wymaganych przez procedury bezpieczeństwa w firmie.

W tym podejściu nie jest, co prawda, konieczna implementacja integracji z poszczególnymi systemami, ale trzeba skonfigurować samo rozwiązanie, aby wiedziało jak obsługiwać rozmaite formularze logowania w każdej usłudze i sposób działania może się wielu z Was wydawać nienaturalny – w końcu przechwytywanie wprowadzania danych przez użytkowników kojarzy się z keyloggerami i może sprawiać wrażenie rozwiązania „siłowego” a nie prawdziwej integracji. Takie systemy są jednak popularne z uwagi na właśnie brak ingerencji w istniejące usługi, które czasem zwyczajnie nie mogą być zmodyfikowane z uwagi na koszty lub fakt, że są mocno przestarzałe, ale nadal ważne i w użyciu.

Nie powinno raczej być problemu, aby zastosować łączone podejście – część systemów zintegrować z użyciem centralnej usługi uwierzytelnienia, część z wykorzystaniem innych sposobów zapewnienia jednokrotnego logowania. Wszystko zależy od aktualnej sytuacji i zastanych systemów – dlatego wspominałem o koniecznej analizie i testach – w ich trakcie można zidentyfikować najbardziej optymalne podejście. Z marszu można podjąć taką decyzję tylko w prostych sytuacjach i w małych firmach, gdzie jest niewiele systemów i z reguły od razu wiadomo, z czego warto skorzystać. Zachęcam jednak do poszukiwania nowych sposobów – jak wszystko w informatyce – także ta dziedzina zmienia się i trzeba być na bieżąco.

avatar

M S

4 odpowiedzi na “SSO – ułatwienie czy przekleństwo?”

  1. Tylko czy to nie jest pogoń za wygodą kosztem bezpieczeństwa?

    • avatar Michał Smereczyński pisze:

      Jeżeli system jest dobrze zaprojektowany i np. uwzględnia dwuetapowe uwierzytelnianie, to chyba nie ma się o co martwić. Google daje radę… albo po prostu nie wiemy o wpadkach ;)

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *