TsgcWSAPIServer_WebAuthn

Komponent TsgcWSAPIServer_WebAuthn zapewnia proste, lecz wydajne rozwiązanie do implementacji serwera Relying Party WebAuthn, umożliwiając uwierzytelnianie bez hasła w aplikacji internetowej. Aplikacja WebAuthn składa się z serwera WebAuthn obsługującego rejestrację i uwierzytelnianie po stronie serwera oraz aplikacji klienckiej, która zazwyczaj jest aplikacją JavaScript.

 

WebAuthn wymaga stosowania bezpiecznych połączeń (SSL/TLS), dlatego biblioteki OpenSSL muszą zostać wdrożone i skonfigurowane na serwerze.

 

Obsługiwane jest wyłącznie API OpenSSL w wersji 3.0.0 lub nowszej, starsze wersje OpenSSL mogą nie działać.

 

Konfiguracja

 

Komponent TsgcWSAPIServer_WebAuthn musi być dołączony do serwera HTTP, TsgcWebSocketHTTP_Server lub TsgcWebSocketServer_HTTPAPI, za pomocą właściwości Server. Możliwa jest konfiguracja punktów końcowych serwera obsługujących opcje rejestracji i uwierzytelniania oraz opcje WebAuthn, takich jak obsługiwane algorytmy, źródła i inne.

 

Opcje punktów końcowych

W tym miejscu można skonfigurować punkty końcowe serwera, które będą obsługiwać żądania HTTP/JavaScript w celu użycia WebAuthn jako uwierzytelniacza. Komponent jest już skonfigurowany z domyślnymi punktami końcowymi, ale można je wszystkie zmienić według własnych potrzeb.

 

• AuthenticationOptions: domyślnie /sgcWebAuthn/Authentication/Options
• AuthenticationVerify: domyślnie /sgcWebAuthn/Authentication/Verify
• RegistrationOptions: domyślnie jest /sgcWebAuthn/Registration/Options
• RegistrationVerify: domyślnie /sgcWebAuthn/Registration/Verify
• Webauthn: zawiera bibliotekę JavaScript używaną domyślnie. Tę właściwość można wyłączyć i użyć własnej biblioteki WebAuthn.
• Test: domyślnie wyłączone, należy używać wyłącznie do testowania funkcjonalności WebAuthn.

 

Przykład: jeśli serwer nasłuchuje pod domeną www.test.com, żądanie opcji uwierzytelniania domyślnie będzie kierowane na adres http://www.test.com/sgcWebAuthn/Authentication/Options

 

Opcje WebAuthn

W tej właściwości można skonfigurować główne opcje komponentu serwera WebAuthn.

 

• RelyingParty: właściwość obowiązkowa, w której należy zdefiniować nazwę DNS serwera. Przykład: jeśli serwer działa pod domeną www.test.com, należy ustawić tę właściwość na "www.test.com".

 

WebAuthn używa źródeł (origins) do wymuszania ograniczeń zasady tego samego źródła, co jest niezbędne do zapobiegania phishingowi i atakom cross-site. Podczas procesów rejestracji i uwierzytelniania WebAuthn źródło jest ściśle weryfikowane przez przeglądarkę i uwierzytelniacz.

 

• Origins: Jeśli żądania mogą pochodzić z różnych źródeł, użyj właściwości Origin, aby ustawić dodatkowe źródła. Przykład: jeśli żądania mogą pochodzić z login.test.com i www.test.co.uk, skonfiguruj właściwość Origins z wartościami: https://login.test.com i https://www.test.co.uk

 

• TopOrigins: Zazwyczaj WebAuthn opiera się na źródle ramki wywołującej (tj. tej, która wywołuje navigator.credentials.create() lub navigator.credentials.get()). Jednak strony internetowe mogą być osadzane w ramkach iframe, które mogą pochodzić z innego źródła niż strona najwyższego poziomu. Stwarza to potencjał do nadużyć lub ataków typu clickjacking. Aby temu zaradzić, specyfikacja WebAuthn Level 2 wprowadza TopOrigin, gdzie można zdefiniować TopOrigins.

 

W WebAuthn parametr crossOrigin to wartość logiczna wskazująca, czy operacja WebAuthn jest wykonywana z kontekstu cross-origin, na przykład z elementu iframe osadzonego z innego źródła niż kontekst przeglądania najwyższego poziomu.

Ten parametr został wprowadzony, aby pomóc przeglądarkom i urządzeniom uwierzytelniającym bezpiecznie obsługiwać żądania uwierzytelniania w środowiskach osadzonych, co jest częstym scenariuszem w nowoczesnych aplikacjach internetowych.

 

• AllowCrossOrigins: jeśli ustawione na true, wskazuje, że żądania z ramki iframe z innego źródła (np. iframe pod adresem https://auth.example.com osadzony na stronie pod adresem https://app.example.org) są dozwolone. Domyślnie jest wyłączone.

 

WebAuthn obsługuje wiele algorytmów kryptograficznych do generowania i weryfikacji poświadczeń klucza publicznego. Algorytmy te są stosowane podczas rejestracji poświadczeń (za pomocą navigator.credentials.create()) i uwierzytelniania (za pomocą navigator.credentials.get()), zapewniając bezpieczne podpisywanie i walidację wyzwań przy użyciu asymetrycznych par kluczy. Serwer jest domyślnie skonfigurowany z algorytmami ES256 i RS256, które są najczęściej stosowane. W dowolnym momencie można zmienić obsługiwane algorytmy za pomocą właściwości Algorithms. Obsługiwane są następujące algorytmy:

 

• ES256
• ES384
• ES512
• RS256
• RS384
• RS512
• PS256
• PS384
• PS512
• RS1
• EdDSA

 

W WebAuthn atestacja jest opcjonalnym mechanizmem umożliwiającym uwierzytelniaczowi (np. urządzeniu lub kluczowi bezpieczeństwa) dostarczenie informacji o producencie, modelu i charakterystykach bezpieczeństwa podczas tworzenia poświadczeń. Informacje te pomagają Relying Party (RP) zdecydować, czy ufać uwierzytelniaczowi.

 

Różne formaty atestacji definiują sposób strukturyzowania i weryfikowania tych danych. Trzy najczęściej stosowane formaty to android-key, packed oraz inne, takie jak fido-u2f, apple lub none. Domyślnie wszystkie formaty atestacji są włączone. Poniżej znajduje się lista obsługiwanych formatów atestacji:

 

• NoneAttestation: w tym przypadku nie są zwracane żadne dane atestacyjne. Daje pierwszeństwo prywatności użytkownika poprzez unikanie ujawniania identyfikatorów urządzenia. Powszechnie stosowane w aplikacjach, które nie potrzebują informacji o pochodzeniu urządzenia.

 

• PackedAttestation: to elastyczny, kompaktowy format używany przez wiele uwierzytelniających. Uwierzytelniający zwraca certyfikat atestacji i podpis. Może być: Pełna atestacja: podpisana kluczem i certyfikatem dostarczonym przez producenta, lub Samopodpisana atestacja: podpisana za pomocą prywatnego klucza poświadczenia. Najszerzej stosowana na różnych platformach (np. YubiKey, Windows Hello).

 

• TPMAttestation: Używane przez urządzenia z modułem Trusted Platform Module (TPM). Potwierdzenie jest podpisywane kluczami z TPM i zawiera łańcuch certyfikatów. Stosowane w komputerach stacjonarnych i laptopach klasy korporacyjnej z układami TPM (np. maszyny z systemem Windows).

 

• AndroidKeyAttestation: Używane przez urządzenia z systemem Android z magazynem kluczy Android Keystore. Klucz jest generowany sprzętowo, a atestacja zawiera informacje podpisane przez łańcuch certyfikatów wydany przez producenta urządzenia. Używane przez telefony z systemem Android z magazynami kluczy wspieranymi sprzętowo (TEE lub StrongBox).

 

• AppleAttestation: Używane przez urządzenia uwierzytelniające platformy Apple, takie jak Touch ID i Face ID. Atestacja jest generowana przez wewnętrzne API Apple i zawiera specjalny format certyfikatu. Stosowane w przeglądarce Safari z użyciem biometrii Apple.

 

• FidoU2FAttestation: Starszy format atestacji używany przez uwierzytelniniki FIDO U2F. Zwraca certyfikat i podpis zgodny z U2F. Stosowany przez starsze klucze bezpieczeństwa (np. wczesne YubiKey) obsługujące FIDO U2F.

 

W API WebAuthn pole AllowCredentials jest polem opcjonalnym używanym podczas procesu uwierzytelniania (przez navigator.credentials.get()). Określa listę identyfikatorów poświadczeń, które są uprawnione do uwierzytelnienia użytkownika dla konkretnej jednostki zależnej (RP). Mechanizm ten umożliwia RP kontrolowanie, które poświadczenia są uznawane za prawidłowe przy próbie logowania. Właściwość credentials zawiera następujące pola:

 

• AllowCredentials: jeśli włączone (domyślnie false), określa listę identyfikatorów danych uwierzytelniających, które mogą uwierzytelniać użytkownika

 

• ExcludeCredentials: dla podanej nazwy użytkownika wyświetla wszystkie istniejące poświadczenia już zapisane w składniku serwera.

 

• Limit: maksymalna liczba poświadczeń, które zostaną wysłane, gdy ExcludeCredentials ma wartość true.

 

Protokół WebAuthn

 

• Rejestracja WebAuthn: Serwer generuje wyzwanie i wysyła je do klienta, który używa uwierzytelniacza (np. klucza bezpieczeństwa lub urządzenia biometrycznego) do utworzenia pary kluczy. Klucz publiczny jest odsyłany i przechowywany przez serwer do przyszłego uwierzytelniania. Poniżej znajdują się dodatkowe informacje o zdarzeniach przepływu rejestracji:
  • Żądanie rejestracji WebAuthn
  • Odpowiedź rejestracji WebAuthn
  • Wynik rejestracji WebAuthn

 

• Uwierzytelnianie WebAuthn: Serwer wysyła wyzwanie do klienta, który podpisuje je przy użyciu wcześniej zarejestrowanego klucza prywatnego przechowywanego w urządzeniu uwierzytelniającym. Podpisana odpowiedź jest weryfikowana przez serwer przy użyciu przechowywanego klucza publicznego w celu potwierdzenia tożsamości użytkownika. Poniżej znajdują się dodatkowe informacje o zdarzeniach przepływu uwierzytelniania:
  • Żądanie uwierzytelniania WebAuthn
  • Odpowiedź uwierzytelniania WebAuthn
  • Wynik uwierzytelniania WebAuthn

 

• MDS: FIDO Alliance Metadata Service (MDS) to centralne repozytorium instrukcji metadanych używane przez strony ufające do weryfikacji poświadczenia uwierzytelniacza i potwierdzenia autentyczności modelu urządzenia.

 

 

• Autoryzacja: Klient może żądać od serwera tokenu Bearer podczas przepływu uwierzytelniania. Token ten może być następnie używany do otwierania nowego połączenia WebSocket lub HTTP bez konieczności logowania się za pomocą kluczy dostępu.
  • Autoryzacja WebAuthn WebSocket
  • Autoryzacja WebAuthn HTTP