SPNEGO認証はカスタムJavaクライアントからは機能しますが、Webブラウザーからは機能しません

素早い回答

2つの修正が必要でした：

1）Internet Explorer（IE）は、URLに基​​づいてサービスプリンシパル名（SPN）を作成します。たとえば、https：//appserver.example.com/fooはSPN "HTTP / APPSERVER.example.com"になります。

したがって、適切なサービスプリンシパル名を、アプリケーションサーバーで使用されるユーザープリンシパル名（UPN）のエイリアスとして、上記の形式でActive Directoryに設定する必要がありました。

そして

2）Internet Explorerからのトークンは有効なSPNEGOトークンですが、サーバー上のGSS APIでは受け入れられません。

ただし、着信トークンのいくつかの単純な文字列操作で、GSSが受け入れて正常に認証するKerbeosトークンを抽出できます。

より長い答え

1）サービスプリンシパル名...

この問題をここに投稿した後、サーバーのUPN [email protected]のエイリアスとして2つのSPN HTTP / APPSERVER.example.comとHTTP / APPSERVERを設定しました。

サーバーは引き続きUPN [email protected]を使用して実行されます。（サーバーが新しいSPNの1つで実行する必要があるという私の最初の仮定は間違っていました。）

これでJavaクライアントは、新しいSPNを使用してKerberosサービスチケットを取得し、サーバーによって認証されるトークンを作成できるようになりました。

ただし、Internet Explorerからのトークンは引き続き拒否されます。

2）Internet Explorerと私のJavaクライアントのトークン...

Javaクライアントからのトークンは次のように始まります。

YIIMdwYGKwYBBQUCoI ....を交渉する

Base64デコードされ、16進バイトとして表されます。

60 82 0C 77 06 06 2B 06 01 05 05 02 A0………

このうち06 06 2B 06 01 05 05 02はSPNEGO OID 1.3.6.1.5.5.2です。

Internet Explorerからのトークンは次のように始まります。

oYIMPjCCDDqgAwoBAaKCDDEEggwtYIIMKQYJKoZIhvcSAQICを交渉する

Base64デコードされ、16進バイトとして表されます。

A1 82 0C 3E 30 82 0C 3A A0 03 0A 01 01 A2 82 0C 31 04 82 0C 2D 60 82 0C 29 06 09 2A 86 48 86 F7 12 01 02 02…。

これは「A1」で始まるSpnego NegTokenTargです。ただし、Javaクラスsun.security.jgss.GSSHeaderは、「60」で始まらないGSSトークンを拒否します。

バイトごとにIE NegTokenTargを調べると、最初の21バイトの後に、一連のバイトがアプリのトークンのバイトに非常に近いことがわかります。

60 82 0C 29 06 09 2A 86 48 86 F7 12 01 02 02 ...

そのうち06 09 2A 86 48 86 F7 12 01 02 02はKerberos OID 1.2.840.113554.1.2.2です

元のトークンの最初の21バイトを破棄してこのトークンを抽出した場合（またはgssContext.acceptSecContext（gssapiData、offset、gssapiData.length）にオフセット21を指定した場合）、GSS APIは新しいトークンを読み取って抽出できますユーザープリンシパル、つまりInternet Explorerからの要求を認証します。

以下のコード例は、base64でエンドコード化された認証文字列の文字列操作を使用して同じことを実現しています。

String auth =req.headers("Authorization");
if ( auth != null && auth.startsWith("Negotiate ")) {
    //smells like an SPNEGO request, so get the token from the http headers
    String authBody = auth.substring("Negotiate ".length());
    if (authBody.startsWith("oY")) {
        // This is a NegTokenTarg from IE, which GSS API does not properly handle.
        // However if we chop of the first (28) chars, we find a Kerberos Token starting with "60 82 0C" that GSS can handle.            
        authBody=authBody.substring(authBody.indexOf("YI", 2));
     }

     try {                 
         byte gssapiData[] = Base64.getDecoder().decode(authBody);               
         gssContext = initGSSContext(MyUtils.SPNEGOOID, MyUtils.KRB5OID);
         byte token[] = gssContext.acceptSecContext(gssapiData, offset, gssapiData.length);


         ..etc.

結論としては、

a）Java GSS APIの弱点：GSSは、NegTokenTargであるSPNEGOトークンを直接受け入れません。

または

b）Internet Explorerと私のサーバー間の相互作用。IEがNSSを送信しますが、これはGSS APIでは予期されていません。

IE-サーバーの相互作用は次のとおりです。

1）IEからの要求（ネゴシエートなし）

2）Negotiateを使用してサーバーから拒否する

3）Kerberosではなく、NTLMのように見えるネゴシエートヘッダー+トークンを使用したIEからの2番目の要求。->これが問題のルートの原因である可能性があります。

4）ネゴシエート+ SPNEGOトークンを使用してサーバーから拒否する

5）IEからの3番目の要求、Negotiateヘッダー+ SPNEGO NegTokenTarg

背景情報：

私のApplication Serverは、Kerberos / Spnego機能にJava JAAS + GSSを使用しています。私のカスタムクライアントは、Java JAAS + GSS、またはMicrosoft SSPI + Waffleのいずれかを使用できます。

このMicrosoftドキュメントは、SPNEGOトークンの形式を理解するのに非常に役立ちました。

https://msdn.microsoft.com/en-us/library/ms995330.aspx

また、このブログでは、負の10進数バイトを「処理」する方法を理解しています。（-128から-1の数値は、128から255に変換されます）。

http://sketchytech.blogspot.com/2015/11/bytes-for-beginners-representation-of.html

私のターゲットエンドユーザーの企業標準ブラウザーはInternet Explorerであり、「より良い」ものを使用する現実的なオプションがないため、グーグルでChromiumとFirefoxのSPN処理コードに出くわしました。リンクは以下のとおりです。Chromiumコードには、広範なコメントと、ナレッジベースの記事およびSMEブログへのリンクがあります。

Chromiumnコード

https://cs.chromium.org/chromium/src/net/http/http_auth_handler_negotiate.cc?type=cs&l=142

FireFoxコード

https://dxr.mozilla.org/mozilla-central/source/extensions/auth/nsAuthSSPI.cpp#98