Traktuj udostępnianie jako umowę cyklu życia
SCIM może ujednolicić sposób wymiany informacji o tożsamości, ale stwierdzenie, że platforma obsługuje SCIM, nie oznacza pełnego cyklu życia dostępu. Wymagania muszą określać, które zasoby i atrybuty są obsługiwane, w jaki sposób użytkownicy są powiązani z dzierżawcami, co oznaczają zmiany ról i jak wyłączenie wpływa na istniejący dostęp. Odpowiedź na udostępnienie nie jest automatycznie dowodem na to, że każda sesja, zezwolenie na eksport lub dane uwierzytelniające API zostały unieważnione.
RFC 7643 definiuje podstawowy schemat SCIM, w tym zasoby użytkowników i grup. RFC 7644 definiuje operacje protokołu i rozważania dotyczące udostępniania. Te podstawowe specyfikacje stanowią słownik wymagań, a nie dowód, że EmailAuth implementuje jakiś konkretny punkt końcowy lub zachowanie w cyklu życia. Podczas przygotowywania tego manuskryptu nie utworzono, nie zmieniono, nie wyłączono ani nie usunięto żadnego użytkownika.
Ustal identyfikatory i powiązanie dzierżawy
Zapisz identyfikator zasobu dostawcy usług, identyfikator korelacji klienta udostępniającego, jeśli jest używany, oraz dzierżawcę, którego dotyczy operacja. RFC 7643 odróżnia identyfikator od externalId; nie należy ich przypadkowo zastępować zmiennym adresem e-mail. Adres użytkownika lub nazwa wyświetlana mogą ulec zmianie bez sugerowania, że nowa osoba powinna odziedziczyć stare konto. Zdefiniuj, w jaki sposób aplikacja identyfikuje istniejący zasób i zapobiega skierowaniu aktualizacji do użytkownika innego dzierżawcy.
RFC 7644 omawia wielodostępność i stowarzyszanie klientów z dzierżawcami, nie zalecając jednej uniwersalnej implementacji dzierżawy. Wymagaj od rzeczywistego dostawcy wyjaśnienia swojego obowiązującego modelu: który uwierzytelniony klient udostępniania może działać na którym dzierżawcy i zestawie zasobów. Identyfikator dzierżawy podany w żądaniu sam w sobie nie jest wystarczającą autoryzacją. Implementacja musi ustanowić relację między uwierzytelnionym klientem a żądanym zakresem, w tym operacjami list, wyszukiwania i cyklu życia.
Określ obsługiwane zasoby i zachowanie aktualizacji
Zapytaj, które atrybuty użytkownika i grupy są akceptowane, zwracane, niezmienne, wymagane lub ignorowane. Rozszerzenia dokumentów i wszelkie mapowania od członkostwa w grupie do uprawnień aplikacji. Pomyślna aktualizacja obiektu grupy nie oznacza sama w sobie, że zmieniła się odpowiednia rola aplikacji. Zachowanie dostępu należy potwierdzić osobno. Unikaj zakładania, że każda platforma obsługująca standard SCIM obsługuje te same filtry, operacje PATCH lub punkty końcowe wykrywania.
RFC 7644 definiuje operacje takie jak odzyskiwanie, tworzenie, zastępowanie, modyfikacja i usuwanie oraz opisuje wykrywanie konfiguracji dostawcy usług. Użyj tych mechanizmów, aby zadawać precyzyjne pytania dotyczące obsługiwanych możliwości. W stosownych przypadkach zachowaj udokumentowane zachowanie w przypadku błędów i obsługę współbieżności. Jeśli operacja nie jest obsługiwana, zapisz obsługiwaną alternatywę, zamiast traktować ogólną etykietę SCIM jako pozwolenie na jej użycie. W tej pracy nie doszło do wykrycia punktu końcowego ani wykonania żądania.
Zdefiniuj wyłączenie bez wymyślania odwołania
RFC 7643 opisuje atrybut Aktywny użytkownik jako wskaźnik stanu administracyjnego, którego ostateczne znaczenie określa dostawca usług. To kluczowa kwalifikacja. Nie można założyć, że ustawienie wartości active na false unieważni każdą aktywną sesję, token API lub delegowaną integrację we wszystkich implementacjach. Wymaganie powinno określać zamierzony wynik dostępu i wymagać dowodów na aktualną platformę pokazujących, co faktycznie się zmienia.
Odróżnij niepełnosprawnych użytkowników od usuniętych zasobów i od usunięcia członkostwa w grupie. Każde z nich może mieć różne konsekwencje dla dostępu, zachowanych zapisów audytu i późniejszej ponownej aktywacji. Wymagaj od dostawcy wyjaśnienia, jak zachowują się istniejące sesje, w jaki sposób przeprowadzane jest pilne unieważnianie i które nieinteraktywne poświadczenia znajdują się poza cyklem życia SCIM. Jeśli platforma wymaga osobnego działania powstrzymującego, udokumentuj to działanie i jego autoryzację, zamiast ukrywać je za statusem „wyłączenie zakończone”.
Sprawdź zmiany ról i zachowany dostęp
Redukcja roli jest szczególnie przydatnym testem, ponieważ może ujawnić buforowane lub niekompletne aktualizacje autoryzacji. Zdefiniuj początkową dozwoloną akcję, zastosuj autoryzowaną zmianę cyklu życia w środowisku urządzenia i sprawdź, czy obecnie niedozwolona akcja jest zabroniona zgodnie z udokumentowanym harmonogramem platformy. Trzymaj opis testu oddzielnie od twierdzenia, że został on uruchomiony. Nie oceniaj tylko tego, czy zmieniła się etykieta interfejsu użytkownika.
Wskazówki dotyczące tożsamości wielodostępnej platformy Azure oddziela tożsamość, uprawnienia i uprawnienia. Zastosuj tę separację do wymagań: SCIM może przenosić dane użytkownika lub grupy, podczas gdy aplikacja podejmuje decyzje dotyczące autoryzacji zasobów i uprawnień komercyjnych. Usunięta licencja, wyłączone konto i usunięta rola administracyjna niekoniecznie są tą samą operacją. Zapisz, który system jest właścicielem każdej decyzji i w jaki sposób wykrywane są niespójne stany.
Arkusz macierzy dostępu
Utwórz macierz zawierającą klienta udostępniającego, powiązanego dzierżawcę, zasób docelowy, operację, zamierzoną rolę lub stan cyklu życia, oczekiwany wynik autoryzacji i lokalizację dowodów. Uwzględnij przypadki odczytu, wyszukiwania, dostępu do aplikacji związanego z eksportem, zapisu i cyklu życia użytkownika. Użyj co najmniej dwóch izolowanych urządzeń najemców z rozróżnialnymi danymi syntetycznymi, aby wycieki między różnymi najemcami nie mogły ukryć się za identycznymi wynikami. Do proponowanego projektu nie są potrzebne żadne dane prawdziwego najemcy.
Dodaj negatywne przypadki dla klienta próbującego skontaktować się z użytkownikiem innego dzierżawcy, wyszukiwania zwracającego rekordy innego dzierżawcy, redukcji roli pozostawiającej dostępne zapisy administracyjne oraz wyłączonej tożsamości zachowującej nieobsługiwany dostęp. Są to przypadki akceptacji defensywnej, a nie instrukcje sprawdzania działającej usługi bez autoryzacji. Zarejestruj oddzielnie obsługiwany interfejs API i zachowanie aplikacji, ponieważ odpowiedź na aktualizację SCIM i decyzja o autoryzacji aplikacji to różne elementy dowodów.
Fikcyjna diagnoza: wyłączony rekord z aktywną sesją
Fikcyjny oceniający widzi pomyślną odpowiedź po oznaczeniu zasobu użytkownika testowego jako nieaktywnego. Osoba oceniająca początkowo uznaje, że wycofanie się zostało zakończone. Osoba przeglądająca wymagania pyta, czy sesja aplikacji, która istniała przed aktualizacją, może nadal czytać raporty lub inicjować eksport. Zespół zdaje sobie sprawę, że demonstracja udowodniła jedynie zaakceptowanie operacji udostępniania, a nie pełny wynik dostępu.
Proponowanym następnym krokiem jest sprawdzenie bieżącego zachowania sesji dostawcy i przeprowadzenie zatwierdzonych kontroli opartych na urządzeniach. Jeśli wymagane jest osobne unieważnienie, procedura cyklu życia musi obejmować upoważnionego właściciela i weryfikację. Ten scenariusz jest fikcyjny: nie zaobserwowano żadnego nieaktywnego użytkownika, aktywnej sesji ani nieudanego odwołania. Zamiast stwierdzać wadę jakiejkolwiek rzeczywistej platformy, ilustruje brak kryterium akceptacji.
Uzgadnianie planów i obsługa wyjątków
Zdefiniuj, w jaki sposób błędy udostępniania są ujawniane, ponawiane i uzgadniane bez duplikowania użytkowników i poszerzania dostępu. Rejestruj, czy klient korzysta z obsługiwanych kontroli współbieżności i jak obsługiwane są sprzeczne zmiany. Tymczasowa awaria synchronizacji nie powinna po cichu przekształcić się w trwały wyjątek uprawnień. Podobnie ponownych prób nie należy opisywać jako bezpiecznych bez zrozumienia operacji i zachowania dostawcy.
Katalog wymaga macierzy dostępu i testów negatywnych obejmujących odczyty, eksporty, zapisy i zmiany cyklu życia użytkowników między dzierżawcami. Te pierwotne testy pozostają otwarte. Ten manuskrypt dostarcza proponowaną matrycę i wymagania, a nie dowody wdrożenia. Otwarte pozostają także przegląd specjalistów, możliwość zastosowania źródeł, trasy produkcji, dostępność i zezwolenie właściciela. Oświadczenie o możliwościach, które można opublikować, wymaga aktualnie obsługiwanego zachowania i autoryzowanych wyników z rzeczywistej platformy, bez ujawniania prawdziwych sekretów użytkowników ani danych dzierżawy.