Jedno logowanie do kilku aplikacji firmy: co trzeba ustalić przed wdrożeniem SSO

Pracowniczka otwiera firmowy portal, a chwilę później aplikację do obsługi zleceń. W obu widzi ten sam ekran logowania organizacji. Nie musi zapamiętywać osobnego hasła do każdego narzędzia. Administrator nadal musi jednak wiedzieć, kto może otworzyć dane klienta, co stanie się po odejściu pracownika i jak zespół odzyska dostęp, gdy dostawca logowania będzie niedostępny.

SSO, czyli pojedyncze logowanie, pozwala aplikacjom korzystać ze wspólnego procesu potwierdzania tożsamości. Przed wdrożeniem trzeba uzgodnić granice tej współpracy: które aplikacje uczestniczą w logowaniu, kto zarządza kontem i jak każda z nich nadaje uprawnienia. Wygodne przejście między narzędziami jest tylko jednym z elementów projektu.

Jeśli rozważasz wspólne logowanie, wyślij brief z listą typów aplikacji, grup użytkowników i obecnym sposobem nadawania dostępu. Wystarczy opis bez haseł, tokenów i danych pracowników.

Kto potwierdza tożsamość, a kto udostępnia dane

Wyobraźmy sobie firmę korzystającą z portalu pracowniczego, panelu zamówień i osobnej aplikacji serwisowej. Każde narzędzie ma własne zadania oraz innych właścicieli. Firma chce, żeby pracownik po potwierdzeniu tożsamości u organizacji mógł przejść do uprawnionych aplikacji bez kolejnego niezależnego logowania. To przykład projektowy, nie opis konkretnego wdrożenia.

W takim układzie dostawca tożsamości obsługuje proces potwierdzania użytkownika. Aplikacja korzystająca z tego potwierdzenia sprawdza otrzymane informacje i tworzy własną sesję zgodnie ze swoją konfiguracją. Konkretne zachowanie zależy od wybranego standardu, narzędzia i zasad organizacji. Tożsamość odpowiada na pytanie, kto korzysta z systemu. Uprawnienia określają, co może w nim zrobić.

Wytyczne NIST dotyczące federacji tożsamości opisują role dostawcy oraz aplikacji korzystającej z potwierdzenia, a także potrzebę jego weryfikacji. Jest to źródło techniczne, nie automatyczne potwierdzenie zgodności dowolnej konfiguracji z wymaganiami organizacji.

W artykule o rolach i uprawnieniach opisujemy, jak przełożyć obowiązki na dostęp do konkretnych funkcji. Wspólne logowanie nie zmienia faktu, że koordynator serwisu i osoba rozliczająca faktury mogą potrzebować innych informacji.

Sprawdź aplikacje przed wyborem rozwiązania

Sporządźcie listę narzędzi, które mają uczestniczyć we wspólnym logowaniu. Przy każdym zapiszcie właściciela, grupy użytkowników, obecny sposób zakładania kont i dokumentację integracji. Sprawdźcie również aplikacje używane poza biurem, na urządzeniach współdzielonych oraz przez osoby spoza firmy. Lista na slajdzie często wygląda krócej niż lista po rozmowie z działami.

Nie zakładajcie, że każda aplikacja obsługuje tę samą metodę integracji w każdej wersji lub planie. Właściciel systemu powinien potwierdzić dostępne możliwości i ograniczenia dla używanej konfiguracji. Zależnie od rozwiązania może pojawić się potrzeba dodatkowej pracy po stronie dostawcy, zmiany sposobu zarządzania kontem lub pozostawienia części użytkowników na innej ścieżce.

OpenID Connect jest jednym ze standardów używanych do uwierzytelniania. OpenID Foundation opisuje go jako protokół zbudowany na OAuth 2.0. Sama nazwa standardu nie wystarczy do wdrożenia: trzeba sprawdzić dokumentację obu stron, obsługiwany przepływ, konfigurację i sposób weryfikacji otrzymanych danych.

Przy integracji przydatna jest lista pytań: kto zarządza konfiguracją, gdzie rejestrowana jest zmiana, kto odpowiada za odnowienie wymaganych danych oraz w jaki sposób aplikacja rozpoznaje właściwego użytkownika. W artykule o przejęciu kodu i kont opisujemy potrzebę zachowania dostępu i dokumentacji po zmianie wykonawcy.

Sprawdźcie również, jakie atrybuty użytkownika są potrzebne każdej aplikacji. Panel może wymagać identyfikatora i nazwy wyświetlanej, a nie pełnego profilu pracownika. Ograniczenie przekazywanych informacji wymaga uzgodnienia celu, możliwości dostawcy oraz sposobu aktualizacji. Jeśli aplikacja używa grup do przydzielania ról, osoba odpowiedzialna powinna wiedzieć, kto zarządza tymi grupami i jak wyjaśnia błędne przypisanie.

Uzgodnij konta, role i identyfikatory

Istniejące konta w aplikacji trzeba powiązać z właściwymi osobami. Adres e-mail bywa użyteczny podczas zaproszenia, ale samodzielne łączenie rekordów wyłącznie po adresie może być ryzykowne, gdy skrzynka zmieni właściciela, zostanie przemianowana albo jest współdzielona. Zespół powinien ustalić stabilny identyfikator dostępny w danej integracji i sprawdzić przypadki niejednoznaczne.

Przeanalizujcie osobę, która zmieniła nazwisko lub adres, oraz pracownika mającego konta w dwóch organizacjach. Sprawdźcie także konto zewnętrznego konsultanta, którego zakres współpracy ogranicza się do jednego projektu. Po zalogowaniu do organizacji każda z tych osób musi nadal otrzymać właściwy zakres danych w konkretnej aplikacji.

Role mogą pochodzić z centralnego katalogu, z samej aplikacji albo z uzgodnionego połączenia obu źródeł. Niezależnie od modelu trzeba wskazać osobę odpowiedzialną za zmianę i sprawdzić, jak szybko aktualizacja dociera do systemu. Ukrycie przycisku nie zastępuje kontroli uprawnień przy odczycie lub zmianie danych.

Warto uzgodnić sposób zakładania konta i pierwszego dostępu. Czy konto powstaje po zatwierdzonym zaproszeniu, po pierwszym logowaniu, czy w osobnym procesie? Co zobaczy osoba rozpoznana przez dostawcę tożsamości, która nie ma jeszcze uprawnień do danej aplikacji? Jasny komunikat i właściciel decyzji pomagają uniknąć ręcznego nadawania zbyt szerokiego dostępu tylko po to, żeby ekran przestał wyświetlać błąd.

Przy zmianie nazwy organizacji lub łączeniu zespołów przygotujcie osobny plan. Użytkownik może zachować zadania w pierwszej aplikacji, a w drugiej potrzebować nowej roli. Przed automatycznym powiązaniem kont porównajcie identyfikatory i historię przypisań na danych testowych. Niejednoznaczny przypadek powinien trafić do osoby uprawnionej do jego rozstrzygnięcia. Nie wystarczy, że dwie nazwy są do siebie podobne.

Zaplanuj sesję, wylogowanie i zmianę dostępu

Wspólne logowanie nie oznacza, że każda aplikacja ma identyczną sesję. Systemy mogą różnić się sposobem jej utrzymania, ponownego potwierdzania tożsamości oraz obsługą wylogowania. Ustalcie oczekiwane zachowanie dla każdego narzędzia i sprawdźcie je w dokumentacji oraz podczas prób. Nie zakładajcie, że zamknięcie jednego okna kończy wszystkie istniejące połączenia.

Przy zmianie stanowiska pracownik może stracić dostęp do jednego obszaru, zachowując inne zadania. Przy zakończeniu współpracy potrzebne jest szersze sprawdzenie konta, sesji oraz integracji. Odpowiednie kroki zależą od architektury i zasad organizacji. Sama zmiana roli w katalogu nie dowodzi jeszcze, że każde narzędzie otrzymało i zastosowało aktualizację.

Przetestujcie użytkownika, który ma otwarty formularz, gdy sesja wygasa. Czy widzi wyjaśnienie? Czy może wrócić do zapisanej wersji po ponownym zalogowaniu? Nie należy obiecywać zachowania niezapisanych danych, jeśli aplikacja nie ma takiej funkcji. Komunikat powinien oddzielić zapisany szkic od operacji, której system nie potwierdził.

Na stanowisku współdzielonym sprawdźcie przejście między pracownikami. Kolejna osoba nie może zostać przypadkowo wprowadzona do sesji poprzednika. Organizacja powinna uzgodnić sposób zakończenia pracy i postępowanie z urządzeniem, a projekt aplikacji musi odpowiadać temu sposobowi zamiast opierać się na założeniu, że przy komputerze zawsze siedzi ten sam użytkownik.

Sprawdźcie również, czy aplikacja rozpoznaje zmianę uprawnień podczas trwającej pracy. Przykładowo osoba otwiera sprawę, a następnie zostaje przeniesiona do innego zespołu. To, czy może nadal zapisać formularz albo zobaczyć szczegóły, powinno wynikać z ustalonych zasad oraz rzeczywistej implementacji. Test musi objąć nie tylko ekran, ale również żądanie odczytu i zapisu. Przy odmowie użytkownik potrzebuje zrozumiałej informacji, bez ujawniania danych, do których utracił dostęp.

Przygotuj awarię przed pierwszym wdrożeniem

Jeżeli wiele aplikacji korzysta z jednego dostawcy tożsamości, jego niedostępność może utrudnić rozpoczęcie pracy w kilku miejscach naraz. To nie przesądza, co stanie się z już otwartą sesją. Zachowanie zależy od aplikacji i rodzaju awarii. Dlatego potrzebny jest scenariusz obejmujący zarówno nowe logowanie, jak i osoby pracujące w aktywnej sesji.

Ustalcie, kto rozpoznaje problem i jak informuje użytkowników. Komunikat „nieprawidłowe hasło” przy awarii usługi kieruje ludzi w złą stronę i może prowokować niepotrzebne próby odzyskania konta. Lepiej pokazać stan, który system potrafi ustalić, oraz wskazać kanał wsparcia bez ujawniania szczegółów technicznych niepotrzebnych odbiorcy.

Niektóre organizacje potrzebują awaryjnej ścieżki administracyjnej. Jej zakres, przechowywanie danych dostępowych, kontrola użycia i regularna próba powinny wynikać z oceny ryzyka oraz dokumentacji danego rozwiązania. Konto awaryjne bez właściciela i testu może okazać się nieskuteczne dokładnie wtedy, gdy będzie potrzebne. Nie należy udostępniać go wszystkim użytkownikom jako wygodnego obejścia.

O planowaniu reakcji i odpowiedzialności piszemy w artykule o awarii integracji. Przy SSO instrukcja powinna wskazywać, kto kontaktuje się z dostawcą tożsamości, kto sprawdza poszczególne aplikacje i gdzie zespół zapisuje potwierdzony stan.

Przed próbą awaryjnego dostępu określcie także, kto może ją zatwierdzić i gdzie zapisuje się wynik. Test wykonany wyłącznie przez autora konfiguracji nie pokaże, czy zastępca odnajdzie potrzebną instrukcję. Przy zmianie dostawcy lub właściciela aplikacji należy sprawdzić, czy opis nadal odpowiada faktycznym kontom i uprawnieniom. Nie przechowujcie w instrukcji jawnych haseł ani kluczy.

Po próbie sprawdźcie również, czy przywrócono zwykły tryb pracy i zamknięto dostęp użyty awaryjnie.

Sprawdź scenariusze przed zmianą dla całej firmy

Zacznijcie od środowiska testowego i kont o różnych rolach. Sprawdźcie poprawne logowanie, brak uprawnień do aplikacji, zmianę adresu oraz przypadek osoby posiadającej więcej niż jedno konto. Następnie przetestujcie wylogowanie, wygaśnięcie sesji i odebranie roli w czasie pracy. Do prób nie są potrzebne rzeczywiste hasła ani dane klientów.

W środowisku testowym integracji możecie uzgodnić oczekiwany wynik każdej próby przed jej wykonaniem. Warto zapisać, które systemy zostały sprawdzone i w jakiej konfiguracji. Poprawne logowanie jednego użytkownika nie dowodzi, że prawidłowo działają wszystkie role, urządzenia i wyjątki.

Poproście przyszłych użytkowników o przejście typowej drogi: otwarcie aplikacji z linku, zalogowanie, powrót do zadania i zakończenie pracy. Osoba testująca powinna rozumieć, którego konta używa i do kogo zgłosić problem. Przy zaproszeniach zewnętrznych sprawdźcie także sytuację, w której przeglądarka ma już aktywne inne konto.

Przed udostępnieniem całej organizacji uzgodnijcie kolejność obejmowania aplikacji, właścicieli zgłoszeń i warunki zatrzymania zmiany. Zachowajcie sprawdzoną drogę przywrócenia dostępu zgodną z możliwościami dostawców. Nie każde połączenie da się cofnąć jednym ustawieniem, zwłaszcza jeśli w międzyczasie zmieniono konta lub role.

Po uruchomieniu obserwujcie problemy zgłaszane przez użytkowników i wyniki prób administracyjnych. Powtarzający się wybór niewłaściwego konta może wymagać czytelniejszego ekranu, a brak dostępu po zmianie działu - poprawy procesu aktualizacji ról. W integracjach systemów wspólne logowanie powinno ułatwiać pracę i pozostawiać jasną odpowiedzialność za każde konto oraz każdą aplikację.

W kryteriach odbioru aplikacji zapiszcie także wynik próby awaryjnej oraz osobę potwierdzającą dostęp administracyjny. Jeżeli ćwiczenie ujawni brak właściciela konta lub nieaktualną dokumentację, poprawcie proces przed rozszerzeniem wdrożenia. Potem powtórzcie tę samą próbę w uzgodnionych warunkach. Zapis wyników pomaga odróżnić realnie sprawdzoną procedurę od instrukcji, którą ktoś przygotował, ale nikt jeszcze nie wykonał.