V konfiguraci Jetty SPNEGO existují tři názvy: URI pro párování ověřování, uživatel přihlašovaný přes JAAS a služba, pro kterou je vyžadován lístek. Mají odlišné účely.

Pro implementaci Jetty 12.0.x vypadá fragment autentizačního objektu takto:

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

Tento fragment ukazuje komponentu služby, nikoli úplný postup ověřování přes proxy. Přihlášení JAAS, směrování proxy a výměna ověřování požadavku zůstávají oddělené.

V této implementaci Jetty sestavuje jméno GSS založené na hostiteli spojením getServiceName(), znaku @ a hostitele pro výměnu ověřování. Když jako komponentu služby zadáte [email protected], přidá se další hostitel. Čtěte smlouvu tohoto setteru místo předpokladu, že přijímá úplný principal Kerberos.

Výsledné jméno GSS má konceptuální podobu HTTP@hostname. Odpovídající principal služby v KDC se obvykle zapisuje jako HTTP/hostname. vybrané jméno proxy musí odpovídat skutečně registrované službě pro tento účet; IP adresa nebo alias může zvolit jiný cíl lístku.

Prověřte i cestu 407

V Jetty 12.0.x získává authenticate() jméno hostitele GSS z request.getHost() a sestavuje výsledek s výchozí hlavičkou Authorization. Párování autentizačního objektu podle proxy URI samo o sobě nezmění tyto volby na jméno hostitele proxy a Proxy-Authorization.

Integrace proxy proto potřebuje správného hostitele požadavku a výsledek v rozsahu proxy pro danou výměnu. Požadavek HTTPS CONNECT a běžný požadavek na původ mohou mít různé hodnoty hostitele. Ověřte chování nainstalované implementace místo předpokladu, že setter názvu služby poskytuje celý tok 407.

U 407 prozkoumejte výměnu ověřování proxy a hostitele, který tento požadavek použil. 401 patří ověřování původu. Samotný platný uživatelský lístek nedokazuje, že Jetty vyžádal správný servisní lístek nebo že jej zprostředkovatel přijal.

Související články