オプションのケルベロス認証を行うことは可能ですか?
私が望むのは、クライアント (ブラウザー) がドメイン上にない場合、ユーザー名/パスワードの Web ログインにリダイレクトされることです。それ以外の場合、SPNEGO は Kerberos 認証を行います。
WWW-Authenticate: Negotiate ヘッダーを非ドメイン ブラウザに送信しただけでは、それ以上何もしません。
認証方法がわからない場合にブラウザに別のことを試すように指示するオプションはありますか? または、「WWW-Authenticate」ヘッダーを送信する前に、ユーザーがドメインの一部であるかどうかを判断する必要がありますか?
これを公に標準的な方法で解決した人は誰もいません。はい、前述のように、フォールバックすることはできBasicますが、CGI フォームからユーザー名とパスワードを要求することを含む認証スキームでは機能しません。ブラウザーが物事を見る限り、失敗した場合は認証なしNegotiateにフォールバックします。 . 多分それは認証方式が壊れていることを示唆していますか? 知らない。
私が知っていることを最初にお伝えします。私たちのサイトは効果的に Cosign で保護されているため、同様の問題があります。特別に構成されたマシンのみがWWW-Authenticateヘッダーに応答するため、デフォルトではすべてのユーザーを Cosign ログイン ページに送信する必要があります。秘訣は、Cosign サーバーは、認証された GSSAPI/Kerberos ホストがログインの詳細を入力せずに認証プロセスを完了できるようにすることです。
HEADこの回避策は、SPNEGO で保護されたリソースを試行するログイン ページ内の JavaScript ブロックで構成されています。成功した場合、スクリプトはブラウザーを同じページの SPNEGO で保護されたバージョンにリダイレクトします。これにより、適切な Cosign Cookie が許可され、パスワードを入力せずにプロセスが完了します。ブラウザーに JavaScript、Kerberos サポート、または適切な資格情報のいずれかが欠けている場合、ユーザーには通常どおり cosign ログイン ページが表示されます。
したがって、上記だけでもあなたの質問に対する答えとして数えられるかもしれません。個人的には、これで十分だとは思いませんが、以下はより多くの議論です...
上記は、接続するすべてのユーザー エージェントが JavaScript (テキストベースのブラウザーや HTTP クライアント ライブラリの場合はそうではありません) をサポートするか、Kerberos 対応ユーザーをリダイレクトする任意のパスの知識をサポートすることを主張しているため、満足のいくものではないようです。サイト用にハードコーディングされていません)。私は、より良い回避策があるかもしれないという結論に達しました。そうでない場合は、標準があるべき場所にギャップがあります。私が持っている最も実用的な提案は次のとおりです。
401SPNEGO プロセスの通常の部分では、クライアントは、最初の応答が HTTPであるがヘッダーを含むページを取得しようとしますWWW-Authenticate: Negotiate。これは、GSSAPI/Kerberos 化されたクライアントが適切に応答するための合図です。「通常の」クライアントは単にエラー ページを表示します。おそらく解決策は、Cosign サーバーを変更して、このエラー応答の一部として人間に優しいログイン ページを提供することでしょうか?
市販の Apache とモジュールでは技術的に困難であり、さまざまな標準 (または少なくとも原則) に反する可能性があります。私は関連するシステムの専門家ではないので、試してみる機会がない限り (または得るまで) 推測することしかできません...
WWW-Authenticate: Basicユーザー名/パスワードのチャレンジのために追加で送信します。