W konfiguracji SPNEGO Jetty występują trzy nazwy: URI służący do dopasowania uwierzytelniania, użytkownik logujący się przez JAAS oraz usługa, dla której żądany jest bilet. Mają różne przeznaczenie.

Dla implementacji Jetty 12.0.x fragment obiektu uwierzytelniania wygląda tak:

var auth = new org.eclipse.jetty.client.SPNEGOAuthentication(
    java.net.URI.create("http://proxy.example:8080"));
auth.setServiceName("HTTP");

Ten fragment ilustruje komponent usługi, a nie pełny przepis na uwierzytelnianie proxy. Logowanie JAAS, routing proxy i wymiana uwierzytelniania żądania pozostają rozdzielone.

W tej implementacji Jetty buduje nazwę GSS opartą na hoście, łącząc getServiceName(), znak @ i host wymiany uwierzytelniania. Podanie [email protected] jako komponentu usługi dodałoby kolejny host. Przeczytaj kontrakt tego settera, zamiast zakładać, że przyjmuje pełny principal Kerberos.

Wynikowa nazwa GSS ma koncepcyjną postać HTTP@hostname. Odpowiedni principal usługi w KDC jest zwykle przedstawiany jako HTTP/hostname. wybrana nazwa proxy musi odpowiadać usłudze faktycznie zarejestrowanej dla tego konta; adres IP lub alias może wybrać inny cel biletu.

Sprawdź także ścieżkę 407

W Jetty 12.0.x authenticate() pobiera nazwę hosta GSS z request.getHost() i buduje wynik z domyślnym nagłówkiem Authorization. Dopasowanie obiektu uwierzytelniania po URI proxy samo w sobie nie zmienia tych wyborów na nazwę hosta proxy i Proxy-Authorization.

Integracja proxy potrzebuje więc właściwego hosta żądania i wyniku ograniczonego do proxy dla tej wymiany. Żądanie HTTPS CONNECT i zwykłe żądanie do źródła mogą mieć różne wartości hosta. Potwierdź zachowanie zainstalowanej implementacji, zamiast zakładać, że setter nazwy usługi zapewnia pełny przepływ 407.

W przypadku 407 sprawdź wymianę uwierzytelniania proxy i host używany przez to żądanie. 401 należy do uwierzytelniania źródła. Sam ważny bilet użytkownika nie dowodzi, że Jetty zażądał właściwego biletu usługi ani że pośrednik go zaakceptował.

Powiązane artykuły