Inicjowanie kontekstu klienta

Aby ustanowić bezpieczne połączenie, klient uzyskuje poświadczenia wychodzące dojścia przed wysłaniem żądania uwierzytelniania do serwera. Serwer tworzy kontekst zabezpieczeń klienta na podstawie żądania uwierzytelniania. Istnieją dwie funkcje SSPI po stronie klienta związane z konfiguracją uwierzytelniania:

Kod tego procesu można zobaczyć w funkcji GenClientContext w using SSPI with a Windows Sockets Client.

Jeśli program kliencki musi używać poświadczeń oprócz własnych poświadczeń logowania, takich jak inna nazwa użytkownika, nazwa domeny i hasło, udostępnia je w AcquireCredentialsHandle wywołanie z SEC_WINNT_AUTH_IDENTITY struktury określającej dodatkowe poświadczenia. Aby uzyskać więcej informacji na temat funkcji poświadczeń, zobacz Credential Management.

Nuta

Flagi składowej struktury SEC_WINNT_AUTH_IDENTITY można ustawić tak, aby SEC_WINNT_AUTH_IDENTITY_ANSI, gdy ciągi w strukturze to ASCI lub OEM. Ciągi ANSI mogą być używane z Flags elementu członkowskiego struktury SEC_WINNT_AUTH_IDENTITY ustawionej na SEC_WINNT_AUTH_IDENTITY_UNICODE, jeśli są one najpierw konwertowane na unicode za pomocą funkcji MultiByteToWideChar.

 

Aby zainicjować pierwszą część uwierzytelniania, klient wywołuje InitializeSecurityContext (ogólne) w celu uzyskania początkowego tokenu zabezpieczającego, który ma zostać wysłany w komunikacie żądania połączenia do serwera.

Klient używa informacji o tokenie zabezpieczającym odebranych w deskryptorze buforu wyjściowego, aby wygenerować komunikat do wysłania na serwer. Budowa komunikatu, pod względem umieszczania różnych i tak dalej, jest częścią protokołu aplikacji i musi być rozumiana przez obie strony.

Klient sprawdza stan powrotu z InitializeSecurityContext (ogólne), aby sprawdzić, czy uwierzytelnianie zostanie zakończone w jednym wywołaniu. Stan powrotu SEC_I_CONTINUE_NEEDED wskazuje, że protokół zabezpieczeń wymaga wielu komunikatów uwierzytelniania. Aby uzyskać więcej informacji na temat funkcji kontekstowych, zobacz Context Management.