Jetty 12.0.x SPNEGO: 完全な principal ではなくサービス名を設定する

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");

この断片はサービスコンポーネントを示すもので、プロキシ認証の完全な手順ではありません。JAAS ログイン、プロキシのルーティング、リクエストの認証交換は別々に扱われます。

この実装では、Jetty は getServiceName()、@ 文字、認証交換に使うホストを組み合わせて GSS のホストベース名を構築します。[email protected] をサービスコンポーネントとして渡すと、さらに別のホストが付加されます。完全な Kerberos principal を受け取ると決めつけず、この setter の契約を読んでください。

得られる GSS 名は概念上 HTTP@hostname の形をとります。KDC 側の対応するサービス principal は通常 HTTP/hostname として表されます。選択したプロキシ名が実際に登録されたサービスと一致する必要があります はそのアカウントに対してです。IP アドレスや別名を使うと別のチケット対象が選ばれることがあります。

407 の経路も確認する

Jetty 12.0.x では、authenticate() は request.getHost() から GSS ホスト名を取得し、既定の Authorization ヘッダーで結果を構築します。認証オブジェクトをプロキシ URI で照合しても、それだけではこれらの選択がプロキシのホスト名と Proxy-Authorization に変わるわけではありません。

したがってプロキシ統合では、その交換に適した正しいリクエストホストとプロキシ向けの結果が必要です。HTTPS CONNECT リクエストと通常のオリジンリクエストではホストの値が異なる場合があります。サービス名 setter が 407 の流れ全体を提供すると決めつけず、導入済み実装の動作を確認してください。

407 の場合は、そのリクエストが使ったプロキシ認証の交換とホストを調べます。401 はオリジン認証に属します。有効なユーザーチケットだけでは、Jetty が正しいサービシチケットを要求したことや、中間装置がそれを受け入れたことを証明できません。