Udostępnij za pośrednictwem

Szyfrowane protokoły dostępu

Protokół access szyfrowany określony przez RFC 2617 jest implementowany przezdostawcę pomocy technicznej zabezpieczeń microsoft Digest(SSP). Implementacja składa się z zestawu funkcji kontekstu zabezpieczeń interfejsu (SSPI) interfejsu dostawcy zabezpieczeń firmy Microsoft, do których są wywoływane aplikacje klienckie/serwerowe:

  • Ustanów kontekst zabezpieczeń na potrzeby wymiany komunikatów.
  • Uzyskaj obiekty danych wymagane przez dostawcę SSP skrótu, takie jak poświadczenia i dojścia kontekstu.
  • Dostęp do integralności wiadomości i mechanizmów poufności.

Uwierzytelnianie dostępu szyfrowanego odbywa się w ramach sparowanych transakcji żądań/odpowiedzi z żądaniami pochodzącymi z klienta i odpowiedziami pochodzącymi z serwera. Pomyślne uwierzytelnianie szyfrowane dostępu wymaga dwóch par żądań/odpowiedzi.

Gdy dostawca SSP skrótu jest używany do uwierzytelniania HTTP, nie ma połączenia między pierwszą a drugą parą żądań/odpowiedzi. Innymi słowy, serwer nie czeka na drugie żądanie po wysłaniu pierwszej odpowiedzi.

Poniższa ilustracja przedstawia kroki wykonywane na ścieżce HTTP przez klienta i serwer w celu ukończenia uwierzytelniania przy użyciu dostawcy SSP skrótu. Mechanizm SASL korzysta z wzajemnego uwierzytelniania, dlatego dane uwierzytelniania są wysyłane z powrotem do końcowego wywołania serwera USŁUGI ASC do klienta, który sprawdza, czy klient komunikuje się z poprawnym serwerem.

szyfrowane protokołu dostępu

Proces rozpoczyna się od klienta żądającego zasobu chronionego dostępem z serwera przez wysłanie żądania HTTP 1.

Serwer odbiera żądanie HTTP 1 i określa, że zasób wymaga informacji uwierzytelniania, które nie zostały uwzględnione w żądaniu. Serwer generuje wyzwanie dla klienta w następujący sposób:

  1. Serwer uzyskuje poświadczenia przez wywołanie funkcji AcquireCredentialsHandle.
  2. Serwer generuje wyzwanie szyfrowane przez wywołanie funkcjiAcceptSecurityContext (General).
  3. Serwer wysyła nagłówek WWW-Authenticate jako odpowiedź na żądanie klienta (wyświetlana jako odpowiedź HTTP 1). Nagłówek zawiera wyzwanie szyfrowane i nieprzezroczystą dyrektywę zawierającą odwołanie do kontekstu zabezpieczeń częściowego ustanowionego dla klienta. Nagłówek jest wysyłany z kodem stanu 401 wskazującym, że żądanie klienta wygenerowało nieautoryzowany błąd dostępu. Aby uzyskać więcej informacji na temat wyzwania szyfrującego, zobacz Zawartość wyzwania skrótu i Generowanie wyzwania skrótu.
  4. Klient otrzymuje odpowiedź HTTP 1, wyodrębnia wyzwanie szyfrowane wysyłane przez serwer i generuje odpowiedź wyzwania Skrót w następujący sposób:
    1. Poświadczenia użytkownika są uzyskiwane przez wywołanie funkcji AcquireCredentialsHandle lub interakcyjne monitowanie użytkownika o poświadczenia.
    2. Informacje o wyzwaniu i poświadczeniach są przekazywane do funkcjiinitializeSecurityContext (General), która generuje odpowiedź na żądanie Skrót.
  5. Klient wysyła nagłówek autoryzacji zawierający odpowiedź wyzwania na serwer (pokazany jako żądanie HTTP 2). Aby uzyskać więcej informacji na temat odpowiedzi na wyzwanie szyfrowane, zobacz Zawartość odpowiedzi na wyzwanie szyfrowane i Generowanie odpowiedzi na wyzwanie szyfrowane.
  6. Serwer odbiera żądanie HTTP 2, wyodrębnia odpowiedź na żądanie wysłane przez klienta i uwierzytelnia informacje przez wywołanie funkcji AcceptSecurityContext (ogólne). Aby uzyskać szczegółowe informacje na temat procesu uwierzytelniania, zobacz initial authentication using Microsoft Digest.
  7. Serwer wysyła odpowiedź HTTP 2 z powrotem do klienta jako drugą i ostateczną odpowiedź wymaganą przez protokół Szyfrowany dostęp. Jeśli uwierzytelnianie zakończy się pomyślnie, ta odpowiedź zawiera żądany zasób.

zawartość odpowiedzi na wyzwanie szyfrowane