Odbieranie dostępu przy SSO: testy przed wyborem dostawcy

Checklist odbierania dostępu przy SSO pozwala sprawdzić, co się dzieje po odebraniu komuś dostępu u dostawcy tożsamości. Przetestuj nowe logowania, aktywne sesje, tokeny API, podłączonych asystentów i ręcznie zaproszonych członków. Zapisz, kiedy dostęp do przestrzeni roboczej faktycznie ustaje, jakie wyjątki pozostają i kto może odebrać dostęp, gdy zawiedzie synchronizacja katalogu.

Prezentacja dostawcy zapewne obejmuje udane logowanie. Poproś też o pokaz odebrania dostępu osobie odchodzącej z firmy. Jeśli wybierasz system ATS, który przechowuje dane kandydatów, notatki z rozmów i prywatne dyskusje zespołu, oba wyniki powinny wpłynąć na decyzję zakupową.

Dlaczego podczas oceny SSO warto sprawdzić odbieranie dostępu?

Udany pokaz jednokrotnego logowania dowodzi, że działa sposób wejścia do aplikacji. Nie pokazuje jednak, co dzieje się z już przyznanym dostępem, gdy ktoś odchodzi.

Dobrym powodem, żeby zapytać o to teraz, jest trwająca dyskusja o SAML. W artykule z 21 września SAML: A fractal of bad design badacz Trail of Bits Matt Schwager krytykuje złożoność SAML i zaleca przechodzenie na OpenID Connect. Dyskusja na Hacker News ponownie zwraca uwagę zespołów programistycznych na wybór protokołu.

Warto zatem przyjrzeć się temu, jak dostawca zaprojektował obsługę tożsamości. Nie wynika z tego, że każde wdrożenie SAML zostało przełamane ani że wybór OpenID Connect rozwiązuje problem odbierania dostępu odchodzącym pracownikom. Ocena przed zakupem obejmuje więcej niż protokół używany na ekranie logowania.

Wyobraź sobie, że z firmy odchodzi osoba zajmująca się rekrutacją. Jej konto zostaje wyłączone w katalogu, ale wciąż ma ona otwartą kartę systemu ATS, token używany przez skrypt do raportowania i asystenta podłączonego do przestrzeni rekrutacyjnej.

Nowe logowanie może się nie udać, podczas gdy pozostałe sposoby dostępu wymagają osobnej obsługi. To scenariusz do przetestowania, a nie twierdzenie o konkretnym produkcie. Poproś dostawcę o pokaz działania faktycznej konfiguracji.

Włącz do oceny osoby odpowiedzialne za dostęp do danych rekrutacyjnych i osobę, która otrzyma alert o nieudanej synchronizacji. Nie zostawiaj całego przeglądu wyłącznie osobie, która uruchomiła SSO.

Zakończ przegląd krótkim protokołem odbioru: przetestowane sposoby dostępu, oczekiwany wynik, zaobserwowany wynik i zaakceptowane wyjątki. Dział zakupów oraz przyszła osoba odpowiedzialna za odbieranie dostępu otrzymają dzięki temu coś precyzyjniejszego niż deklaracja „obsługujemy SSO”.

Rozdziel logowanie, zarządzanie członkostwem i dostęp do aplikacji

Uwierzytelnianie, zarządzanie członkostwem i unieważnianie dostępu odpowiadają na różne pytania. Zapytaj, jak dostawca łączy je w konfiguracji, którą zamierzasz kupić.

OpenID Connect Core określa uwierzytelnianie oparte na OAuth 2.0 i przekazywanie informacji o użytkowniku. Same te możliwości nie definiują pełnej procedury odejścia pracownika z twojej firmy.

Aplikacja może wystawić własny token sesji i samodzielnie kontrolować uprawnienia. Microsoft wyraźnie opisuje tę granicę w zaleceniach dotyczących odbierania dostępu. Wyłączenie tożsamości w Microsoft Entra nie daje usłudze Entra bezpośredniej kontroli nad sesją utworzoną przez aplikację. Dalszy dostęp zależy od zachowania i konfiguracji samej aplikacji.

Równie uważnie sprawdź automatyczne zarządzanie kontami. SCIM, standard wymiany informacji dotyczących zarządzania tożsamościami, zawiera atrybut active. Jego podstawowy schemat pozostawia ostateczne znaczenie tego atrybutu dostawcy usługi.

Wartość active=false w poprawnie obsłużonym żądaniu sama w sobie nie dowodzi, że wszystkie poświadczenia aplikacji przestały działać.

Wylogowanie również ma określony zakres. Osobna specyfikacja OpenID Connect Back-Channel Logout opisuje powiadamianie aplikacji, by usunęły pasujące sesje. Jej obsługa jest opcjonalna, a tokeny odświeżania z dostępem offline są co do zasady traktowane inaczej niż tokeny odświeżania powiązane z sesją. Deklaracja „obsługujemy wylogowanie” nie oznacza „unieważniamy wszystkie poświadczenia”.

Żeby przeprowadzić tę ocenę, nie musisz umieć implementować protokołów. Poproś dostawcę o proste wyjaśnienie każdego wiersza tabeli, a potem o pokaz najważniejszych sposobów dostępu. Przydatna odpowiedź wskazuje zdarzenie wyzwalające, objęte nim rodzaje tożsamości, przewidywane opóźnienie i wyjątki.

Ustal zdarzenie wyzwalające i termin odebrania dostępu

Test odbierania dostępu wymaga określonego zdarzenia początkowego i jasnego wskazania, do czego dostęp ma ustać. Bez tego kupujący i dostawca mogą oglądać tę samą prezentację, ale inaczej ocenić jej wynik.

Najpierw zapisz konfigurację: plan produktu, dostawcę tożsamości, wymuszanie SSO, połączenie do automatycznego zarządzania członkostwem i sposób dołączenia użytkownika testowego.

Ręcznie zaproszony gość może podlegać innej procedurze usuwania niż pracownik dodany przez katalog. Testuj konfigurację, z której faktycznie będziesz korzystać.

Potem wybierz zdarzenie wyzwalające. Wyłączenie użytkownika w katalogu, usunięcie przypisania do aplikacji, usunięcie z grupy i usunięcie lokalnego członkostwa w przestrzeni roboczej to różne działania. Przetestuj to, którego używa firmowa procedura odejścia. Jeśli firma polega także na innych zdarzeniach, dodaj dla nich osobne testy.

Uzgodnij maksymalne dopuszczalne opóźnienie dla każdego istotnego sposobu dostępu. To twoje kryterium odbioru, a nie uniwersalne branżowe SLA. Zapytaj dostawcę, do czego się zobowiązuje, co jedynie uruchamia według harmonogramu i co ma zrobić administrator, gdy standardowa procedura zawiedzie.

Możesz na przykład wymagać, żeby w sytuacji awaryjnej wyznaczona osoba odbierała dostęp bezpośrednio w aplikacji, bez czekania na zaplanowaną synchronizację. Zapisz to jako procedurę, wskaż osobę odpowiedzialną i potrzebne uprawnienia. Sam fakt, że administrator zwykle może edytować użytkowników, nie dowodzi istnienia takiej procedury.

Oddzielnie zapisz trzy momenty: wykonanie działania w katalogu, odebranie lub przetworzenie go przez aplikację oraz odrzucenie żądania dostępu do chronionych danych.

Komunikat integracji o powodzeniu jest przydatnym dowodem dostarczenia zmiany. Nie zastępuje jednak dowodu w postaci odrzuconej próby odczytania chronionego rekordu.

Na koniec ustal, co oznacza „odebrany dostęp”. Utrata dostępu do firmowej przestrzeni roboczej nie musi oznaczać utraty niezwiązanej z nią przestrzeni osobistej ani wylogowania ze wszystkich usług dostawcy. Z drugiej strony samo przekierowanie przeglądarki nie wystarcza, jeśli token tej samej osoby nadal pozwala odczytywać dane kandydatów.

Sprawdź odbieranie dostępu przy SSO w teście odbiorczym

Użyj tymczasowej tożsamości przeznaczonej wyłącznie do testu i fikcyjnych rekordów w przestrzeni testowej zatwierdzonej przez dostawcę. Najpierw potwierdź, że dostęp działa, a po jego odebraniu powtórz te same nieszkodliwe operacje.

Drugi administrator powinien być dostępny, żeby w razie potrzeby przywrócić konfigurację. Do prezentacji nie używaj konta rzeczywistego pracownika ani prawdziwych danych kandydatów.

Poniższy arkusz to nasza propozycja testu. Nie jest certyfikacją ani raportem z testów wygenerowanym przez Kit.

Sprawdź stan początkowy

Utwórz fikcyjnego kandydata lub inny nieszkodliwy rekord objęty kontrolą dostępu. Potwierdź, że użytkownik testowy może go odczytać każdym obsługiwanym sposobem, który chcesz ocenić. Jeśli operacja nie działała przed odebraniem dostępu, jej późniejsze niepowodzenie niczego nie mówi o unieważnieniu uprawnień.

Użytkownik i administrator powinni korzystać z osobnych przeglądarek. Zapisz rolę użytkownika, sposób utworzenia członkostwa i istotne przypisania do grup.

Sporządź wykaz utworzonych poświadczeń, ale nie kopiuj ich tajnych wartości do arkusza. Następnie wykonaj uzgodnione działanie odbierające dostęp i zapisz godzinę. Pozostaw dotychczasową sesję przeglądarki otwartą. Test wyłącznie w nowej przeglądarce pominąłby zachowanie, które chcesz sprawdzić.

Ponownie sprawdź istotne sposoby dostępu

W przypadku klientów OAuth poproś dostawcę o rozróżnienie poświadczenia używanego do dostępu do zasobów i tokena odświeżania, który służy do uzyskania kolejnego poświadczenia. RFC 7009 osobno definiuje unieważnianie tokenów i omawia wpływ na tokeny powiązane.

W protokole odbioru zapisz, które poświadczenia zostały sprawdzone. Sam zapis „OAuth przetestowany” nie wystarczy.

Nie myl widoczności starej strony z dalszym dostępem. Tekst już wyświetlony w karcie może pozostać widoczny po wygaśnięciu uprawnień. Zażądaj nowych chronionych treści i sprawdź, czy serwer je zwraca. Tak samo nie akceptuj czysto wizualnego komunikatu „wylogowano”, jeśli żądania dostępu do chronionych danych nadal się udają.

Zachowaj dowody zrozumiałe dla kolejnej osoby

Dla każdego sposobu dostępu zapisz ostatnią zaobserwowaną odpowiedź zezwalającą na operację i pierwszą zaobserwowaną odmowę. Testy wyznaczają przedział między tymi obserwacjami, ale nie ustalają dokładnego momentu zmiany uprawnień. Jeden udany przebieg nie dowodzi też, jakie będzie największe możliwe opóźnienie u dostawcy.

Krótki protokół może zawierać takie pola:

Nie zapisuj w protokole tokenów ani prywatnej treści odpowiedzi. Osoba uprawniona do przeglądu potrzebuje dowodów pozwalających odtworzyć rozumowanie, a nie kolejnego zbioru poświadczeń czy danych kandydatów.

Jeśli któryś test się nie powiedzie, wskaż operację, która nadal działa. Zapis „Dotychczasowa przeglądarka odczytuje nowo utworzone notatki o kandydatach po upływie dopuszczalnego czasu” jest przydatniejszy niż „SSO nie działa”. Pokazuje dostawcy konkretny problem z dostępem, który trzeba naprawić.

Zapisz wyjątki przed zaakceptowaniem dostawcy

Decyzja o odbiorze musi uwzględniać wyjątki i obsługę awarii. Udany test pracownika zarządzanego przez katalog nie obejmuje wszystkich osób, poświadczeń ani przerw w działaniu.

Zacznij od sposobu utworzenia członkostwa. Dokumentacja dezaktywacji w Okta opisuje warunki odbierania dostępu do aplikacji i wyjątki. To kolejny powód, żeby przed zakupem zapytać: którymi aplikacjami i tożsamościami faktycznie zarządza skonfigurowane połączenie?

Wymień ręcznie zaproszonych członków, zewnętrznych współpracowników, konta usługowe i konta administratorów do użytku awaryjnego, jeśli takie istnieją. Dla każdego określ procedurę odebrania dostępu i osobę odpowiedzialną.

Celowo utworzone konto awaryjne nie może być niewidocznym wyjątkiem. Udokumentuj, kto je kontroluje i jak sprawdzane jest jego użycie.

Zaplanuj test awarii i przywracania działania

Zapytaj, jak osoba odpowiedzialna dowie się o zatrzymaniu synchronizacji katalogu lub odrzuceniu zmiany. Wczorajszy znacznik czasu może powiedzieć więcej niż zielona etykieta „połączono”. Poproś dostawcę o obsługiwany sposób symulacji awarii. Jeśli nie da się jej bezpiecznie zasymulować, przejrzyj udokumentowane dowody wcześniejszego niepowodzenia.

Wykonaj ręczną procedurę awaryjną i powtórz odpowiednie testy dostępu. Taka procedura jest przydatna tylko wtedy, gdy wyznaczona osoba może ją wykonać mimo niedostępności zwykłej integracji. Potwierdź wymagane uprawnienia administratora i miejsce przechowywania instrukcji.

Osobno przetestuj zmianę roli na taką z mniejszymi uprawnieniami i ponowne dołączenie. Po ograniczeniu uprawnień sprawdź chronioną operację, do której dana osoba powinna utracić uprawnienia. Po ponownym dołączeniu porównaj dostęp z nowo zatwierdzoną rolą.

Nie zakładaj ani automatycznego przywrócenia dawnych uprawnień, ani trwałej utraty wszelkiego dostępu.

Określ zakres decyzji

Poproś dostawcę o pisemne wyjaśnienie i zachowaj je razem z konfiguracją oraz wynikami obserwacji. Rozróżniaj możliwości produktu, zobowiązania umowne i wynik konkretnego pomiaru. Jeśli nierozwiązany wyjątek dotyczy wrażliwych danych kandydatów, zdecyduj, czy zmienić konfigurację, wprowadzić skuteczne zabezpieczenie czy odłożyć akceptację.

Odrzucenie kolejnego żądania nie odbierze komuś informacji, które już skopiował. Pobrane pliki, eksporty i zachowane kopie wymagają osobnych zasad postępowania z danymi. Ten przegląd skupia się na zatrzymaniu dalszego dostępu do przestrzeni roboczej.

Praca z dowodami przypomina zamykanie zgłoszenia o wycieku poświadczeń: trzeba wskazać objęty problemem sposób dostępu i zweryfikować wynik. Tutaj chodzi jednak o planowane odejście i odbiór rozwiązania dostawcy, a nie reagowanie na incydent.

Sprawdź Kit według tej samej listy kontrolnej

Oceniaj produkt w konfiguracji, której rzeczywiście będziesz używać, wraz z jej ograniczeniami. Przeprowadź w Kit taki sam test odebrania dostępu, jakiego oczekujesz od innych dostawców.

Kit obsługuje jednokrotne logowanie SAML i osobne połączenie synchronizujące katalog Google Workspace. Integracja cyklicznie odpytuje Google; nie jest ogólnym punktem końcowym SCIM. Zadanie synchronizujące członkostwa uruchamia się według harmonogramu co godzinę, a strona katalogu udostępnia przycisk Synchronizuj teraz.

Harmonogram nie gwarantuje terminu odebrania dostępu. Błędy po stronie usługi źródłowej, opóźnienia zadań i mechanizmy ochronne mogą uniemożliwić pomyślny przebieg synchronizacji.

Połączenie zarządza członkostwami, które samo utworzyło. Nie usuwa właściciela konta ani ręcznie zaproszonych członków. Odłączenie synchronizacji zatrzymuje kolejne przebiegi, ale nie usuwa obecnych członków. Zapisz te ograniczenia w arkuszu przed testem. Konfigurację i obsługiwane zachowania opisuje dokumentacja SSO i automatycznego zarządzania członkostwem przez katalog.

Działa też celowe zabezpieczenie przed masowym usuwaniem. Synchronizacja zostaje zatrzymana, jeśli miałaby usunąć wszystkich członków zarządzanych przez katalog, również wtedy, gdy jest to tylko jedna osoba. Usunięcie więcej niż połowy tej grupy również zostaje wstrzymane, jeśli liczy ona co najmniej czterech członków.

Jeżeli te zabezpieczenia zatrzymają prawidłowe usunięcia związane z odejściami, potrzebna jest weryfikacja przez osobę odpowiedzialną i ręczne odebranie dostępu.

Gdy usunięcie przez katalog skutecznie usuwa członkostwo, implementacja Kit usuwa tokeny API tego użytkownika dla danego konta, unieważnia poświadczenia OAuth/MCP przypisane do tego konta i rozłącza połączenia na żywo tego użytkownika z danym kontem. Działanie obejmuje przestrzeń roboczą, z której usunięto użytkownika. Nie usuwa jego globalnej tożsamości i nie gwarantuje wylogowania ze wszystkich pozostałych przestrzeni.

Przy ręcznym odbieraniu dostępu dokumentacja kontroli dostępu zespołu opisuje funkcję Usuń z konta i przegląd uprawnień. Jeśli chronione zadanie ma tylko jednego właściciela, przed usunięciem tej osoby wybierz następcę albo jawnie pozostaw zadanie bez przypisania.

Właściciel konta nadal jest chroniony przed usunięciem. Wymagane SSO również zachowuje wyjątek pozwalający właścicielowi na dostęp awaryjny. Sprawdź ten wyjątek razem z ustawieniami bezpieczeństwa logowania.

Są to zachowania opisane w dokumentacji i sprawdzone w kodzie źródłowym. Artykuł nie stanowi potwierdzenia testu odbiorczego wykonanego na działającym wdrożeniu w twojej firmie. Podczas własnego przeglądu nadal sprawdź odpowiednie wiersze arkusza, w tym ręcznie dodanych członków i nieudaną synchronizację.

Dobra decyzja dotycząca SSO opiera się na pokazanej procedurze odebrania dostępu, zapisanych pomiarach czasu i wskazanej osobie, która obsłuży wyjątki. Użyj arkusza podczas okresu próbnego Kit lub kolejnego przeglądu dostawcy. Odejście przetestuj równie starannie jak logowanie.