У Jetty SPNEGO конфигурацији постоје три имена: URI који се користи за упаривање аутентификације, корисник који се пријављује преко JAAS-а и услуга за коју се тражи тикет. Имају различите сврхе.

За имплементацију Jetty 12.0.x фрагмент објекта аутентификације изгледа овако:

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

Овај фрагмент илуструје компоненту услуге, а не потпун рецепт за proxy аутентификацију. JAAS пријава, proxy усмеравање и размена аутентификације захтева остају одвојени.

У овој имплементацији Jetty гради GSS име засновано на хосту комбинујући getServiceName(), знак @ и хост за размену аутентификације. Ако као компоненту услуге наведете [email protected], додао би се још један хост. Прочитајте уговор овог setter-а уместо да претпостављате да прихвата потпуни Kerberos principal.

Добијено GSS име има концептуални облик HTTP@hostname. Одговарајући principal услуге у KDC-у обично се представља као HTTP/hostname. изабрано proxy име мора да одговара услузи која је стварно регистрована за тај налог; IP адреса или алијас могу изабрати другу мету тикета.

Проверите и путању 407

У Jetty 12.0.x authenticate() добија GSS име хоста из request.getHost() и гради резултат са подразумеваним заглављем Authorization. Упаривање објекта аутентификације по proxy URI-ју само по себи не мења те изборе у име хоста proxy-ја и Proxy-Authorization.

Proxy интеграција стога треба исправан хост захтева и резултат ограничен на proxy за ту размену. Захтев HTTPS CONNECT и обичан захтев према извору могу имати различите вредности хоста. Потврдите понашање инсталиране имплементације уместо да претпостављате да setter имена услуге пружа потпуни ток 407.

За 407 проверите proxy размену аутентификације и хост који је користио тај захтев. 401 припада аутентификацији извора. Само важећи кориснички тикет не доказује да је Jetty затражио исправан тикет услуге или да га је посредник прихватио.

Повезани чланци