Cel i granica przykładu#
Przykład pokazuje logowanie do aplikacji internetowej: użytkownik podaje identyfikator i hasło, system weryfikuje dane oraz tworzy sesję przy powodzeniu. Model koncentruje się na interakcji między przeglądarką, usługą uwierzytelniania, magazynem danych i usługą sesji. Nie opisuje całego procesu rejestracji, odzyskiwania hasła, MFA, federacji tożsamości ani szczegółów protokołu.
Uwierzytelnianie (authentication) sprawdza, czy przedstawiona tożsamość jest wiarygodna. Nie jest tym samym co autoryzacja, która rozstrzyga, do jakich zasobów uwierzytelniona osoba ma dostęp. Diagram logowania nie powinien sugerować, że samo utworzenie sesji przyznaje nieograniczone uprawnienia.
Aktor, cel i warunki#
Głównym aktorem jest Użytkownik, który chce uzyskać uwierzytelnioną sesję. Zewnętrzny dostawca tożsamości może być dodatkowym aktorem w innym wariancie. Przegląd funkcji można opisać przypadkiem użycia Zalogować się; poniższy diagram sekwencji rozwija przebieg tego celu.
Warunkiem wstępnym jest dostęp do formularza i możliwość przesłania żądania. W podstawowym wariancie użytkownik ma konto i podaje dane logowania. Rezultatem sukcesu jest sesja powiązana z kontem. Rezultatem niepowodzenia jest brak nowej sesji i komunikat, który nie ujawnia, czy konto istnieje.
W prawdziwym systemie wymagania powinny również określać MFA, odzyskiwanie dostępu, czas życia i unieważnianie sesji, ochronę przed automatycznymi próbami oraz obsługę niedostępności usług. Przykład nie zastępuje przeglądu bezpieczeństwa.
Przebieg podstawowy#
- Użytkownik otwiera formularz i wpisuje identyfikator oraz hasło.
- Interfejs przekazuje żądanie usłudze uwierzytelniania przez bezpieczny kanał.
- Usługa stosuje ograniczenia liczby prób, weryfikuje dane i obsługuje błędne lub zablokowane konto.
- Po poprawnej weryfikacji usługa tworzy nową sesję i zwraca potwierdzenie.
- Interfejs pokazuje stan zalogowania; późniejsze sprawdzanie uprawnień jest osobnym zachowaniem.
Diagram pokazuje celowo ogólną odpowiedź dla kilku przyczyn odmowy. To ogranicza ujawnianie, czy konto istnieje lub jest zablokowane. Jednocześnie system może zapisać szczegółową przyczynę w kontrolowanych logach bezpieczeństwa, z ochroną danych i bez rejestrowania hasła. Sam komunikat nie wystarczy, jeśli kod odpowiedzi, treść strony lub czas odpowiedzi zdradzają inne informacje.
Warianty i decyzje projektowe#
Błędny identyfikator lub hasło. Użytkownik otrzymuje komunikat ogólny. System powinien rejestrować nieudaną próbę zgodnie z zasadami bezpieczeństwa, ale nie zapisywać sekretów.
Konto nieaktywne lub czasowo zablokowane. Z perspektywy zewnętrznej odpowiedź może pozostać ogólna; pomocne instrukcje odzyskiwania dostępu można przedstawić w osobnym przebiegu, który nie ujawnia stanu konta osobie postronnej.
Przekroczenie limitu prób. Zastosuj ograniczanie żądań i przemyślane opóźnienia. Prosta blokada konta może sama stać się narzędziem odmowy usługi, jeśli napastnik może blokować konta innych osób. Strategię należy dopasować do ryzyka i UX.
Wymagane dodatkowe uwierzytelnienie. Po poprawnym haśle system może rozpocząć weryfikację drugim składnikiem, a sesję pełną utworzyć dopiero po jej sukcesie. To odrębna gałąź interakcji, którą warto pokazać, jeśli MFA należy do zakresu.
Niedostępność repozytorium lub usługi sesji. To błąd techniczny, a nie błędne dane użytkownika. Komunikat dla użytkownika może być bezpieczny i ogólny, lecz logika operacyjna, monitoring i testy powinny odróżniać awarię od odmowy uwierzytelnienia.
Model danych i stany#
Diagram klas może rozdzielić Konto, dane weryfikacyjne i Sesję. Nie przechowuj jawnego hasła jako atrybutu. Szczegóły przechowywania poświadczeń, rotacji sekretów, algorytmów i konfiguracji należą do projektu bezpieczeństwa i powinny być zgodne z aktualnymi, sprawdzonymi wytycznymi.
Maszyna stanów sesji może opisywać stany Utworzona, Aktywna, Wygasła i Unieważniona. Diagram stanów konta może osobno modelować aktywację lub blokadę. Rozdzielenie tych cykli zapobiega utożsamianiu statusu konta z istnieniem aktywnej sesji.
Testowanie modelu#
Z diagramu można wyprowadzić przypadki testowe:
- poprawne dane aktywnego konta tworzą sesję;
- błędne hasło nie tworzy sesji i zwiększa licznik prób;
- nieistniejące konto i błędne hasło dają równoważną odpowiedź zewnętrzną;
- konto zablokowane nie uzyskuje sesji;
- przekroczenie limitu nie pozwala na nieograniczone próby;
- błąd repozytorium nie jest raportowany jako poprawne logowanie;
- użytkownik bez pełnego uwierzytelnienia nie otrzymuje uprawnień wymagających sesji;
- ponowne logowanie i istniejąca sesja mają zdefiniowane zachowanie.
Testuj nie tylko widok strony, ale też kody odpowiedzi, nagłówki, różnice czasu, logi oraz skutki w sesji. Wymagania bezpieczeństwa warto przeglądać z osobą odpowiedzialną za bezpieczeństwo.
Typowe błędy#
- Mylenie uwierzytelniania z autoryzacją. Potwierdzenie tożsamości nie rozstrzyga wszystkich uprawnień.
- Ujawnianie przyczyny logowania. Różne komunikaty mogą ułatwiać enumerację kont.
- Brak ograniczania prób. Umożliwia automatyzację zgadywania poświadczeń.
- Blokada bez rozważenia odmowy usługi. Napastnik może celowo blokować cudze konta.
- Jawne hasło w danych lub logach. Sekrety wymagają ochrony i nie mogą pojawiać się w diagnostyce.
- Pominięcie tworzenia i unieważniania sesji. Samo sprawdzenie hasła nie opisuje ukończonego logowania.
- Traktowanie awarii jako błędnego hasła. Utrudnia diagnostykę i może prowadzić do mylących blokad.
- Uznanie diagramu za pełną specyfikację bezpieczeństwa. Wymagane są szczegółowe wymagania, testy i przegląd implementacji.
Co przykład pokazuje, a czego nie#
Przykład pokazuje główne uczestniki logowania, kolejność sprawdzeń, utworzenie sesji oraz alternatywną odpowiedź przy niepowodzeniu. Rozdziela cel użytkownika od odpowiedzialności usługi i wskazuje istotne decyzje do uzgodnienia.
Nie specyfikuje protokołu, kryptografii, całej obsługi sesji, MFA ani pełnego modelu zagrożeń. Uzupełnij go wymaganiami bezpieczeństwa, diagramem stanów sesji lub konta i testami właściwymi dla konkretnej aplikacji.