У канфігурацыі 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] як кампанент службы, дадасца яшчэ адзін хост. Чытайце кантракт гэтага сэтэра, а не меркавайце, што ён прымае поўны principal Kerberos.

Атрыманае 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 і звычайны запыт да крыніцы могуць мець розныя значэнні хоста. Пацвердзіце паводзіны ўсталяванай рэалізацыі, а не меркавайце, што сэтэр імя службы забяспечвае поўны працэс 407.

Для 407 праверце абмен аўтэнтыфікацыі proxy і хост, які выкарыстоўваў гэты запыт. 401 адносіцца да аўтэнтыфікацыі крыніцы. Адзін сапраўдны білет карыстальніка не даказвае, што Jetty запытаў правільны білет службы ці што пасярэднік яго прыняў.

Падобныя артыкулы