Wyprzedzające uwierzytelnianie Basic w pośredniku dla znanego punktu końcowego
Zdecyduj, kiedy wyprzedzające uwierzytelnianie Basic w pośredniku pasuje do stałego punktu końcowego, i nie pozwól, by ta decyzja stała się regułą poświadczeń dla dowolnych tras.
Klient czekający najpierw na wyzwanie czeka, aż pośrednik zapyta. Klient wyprzedzającego Basic już zna wybrany punkt końcowy i wysyła poświadczenie w pierwszym odpowiednim żądaniu. Usunięcie tej wymiany może być przydatne. To nadal decyzja o tym, dokąd trafia hasło.
Poznaj punkt końcowy przed optymalizacją
Stały prywatny pośrednik ze znaną polityką uwierzytelniania to jaśniejszy przypadek niż warstwa routingu, która może wybrać nieznanego pośrednika. Powiąż konto z oczekiwaną tożsamością i protokołem pośrednika. Nie buduj ogólnego callbacku, który odpowiada na każde wyzwanie jednym hasłem firmowym.
Basic przenosi reprezentację base64 konta, nie zaszyfrowany dowód. TLS do nasłuchu pośrednika to odrębny wybór połączenia od sesji HTTPS witryny. Tunel HTTPS witryny nie chroni wstecznie poświadczenia Basic wysłanego przez niezaszyfrowane połączenie klient–pośrednik. Prywatny LAN to lokalizacja, a nie cecha szyfrowania.
Zachowaj mechanizm konkretny
Wyprzedzający Basic nie jest uniwersalnym skrótem dla Digest, NTLM ani Negotiate. Te mechanizmy mają własne wymagania wymiany. Klient, który odkryje obsługiwane schematy, może legalnie wykonać dodatkowe transakcje.
Użyj interfejsu uwierzytelniania pośrednika wybranej biblioteki, a następnie sprawdź faktyczny schemat i zakres. Ustawienie wstępnego uwierzytelniania miejsca docelowego może nie sterować uzgadnianiem z pośrednikiem. Istniejące uwierzytelnione połączenie może też ukryć, czy nowe połączenie wykonałoby wyzwanie.
Porównaj całą operację: liczbę wymian, czas zakończenia, wymaganą ochronę transportu i zachowanie przy zmianie pośrednika. Czystszy dziennik jest przydatny tylko wtedy, gdy aplikacja nadal uwierzytelnia się u zamierzonego pośrednika i zatrzymuje się, gdy tego układu nie da się ustanowić.