Kerberos チケットを使用して実行しているときに、すべての Firefox 要求の HTTP ヘッダーに異なる Authorization 行があることに気付きました。単純なページを読み込んでから、リロード ボタンを数回押しましたが、まったく同じではありませんでした。この動作の原因は何ですか? Kerberos クレデンシャルの期間中、Authorization ラインは一定のままであると考えていたでしょう。(Firefox を起動する前に、kinit コマンドを使用して資格情報を取得したことに注意してください。)
認証方法が Basic の場合、Firefox は毎回同じ base64 文字列の「user:password」を送信し続けます。これは私が期待した動作です。
何か案は？
うーん、それは奇妙です。Wireshark 出力の抜粋を投稿できる可能性があります。1 つの可能性として、取得したサービス チケットがキャッシュされておらず、FF がサービス チケットを取得している可能性があります。クライアントがサービスを取得するがそれをキャッシュせず、代わりに必要なたびにサービス チケットを取得する実装がありました。場合によっては、プロセスに書き込み権限がない可能性があり、比較的安価な操作 (単一のラウンド トリップと対称暗号化データ) が原因である場合があります。
これは、HTTP と Negotiate-Auth の動作の両方におけるさまざまな制限によるものです。
HTTP はもともとステートレス プロトコルとして設計されており、HTTP の認証システムはそのモデルを前提としています。各リクエストで完全な認証交換を行うように設計されています。たとえば、Basic では、各リクエストに完全な資格情報が含まれています。Negotiate-Auth と SPNEGO の場合も同じことが当てはまります。まったく新しい GSS-API コンテキストが作成され、要求ごとに新しい認証が実行されます。
はい、これは非常に無駄です。しかし、(現在) 一度認証し、セッションを確立し、その後のすべての要求をそのセッションにバインドする標準化された方法はありません (たとえば、IMAP、POP、または ssh が行う方法)。この方向で IETF の作業がいくつかありますが、これは非常に予備的なものです。
チケットはキャッシュされます。毎回それほど多くの作業を行っているわけではありません。しかし、サーバーとクライアントは、毎回 GSS-API セッション ダンス全体を経験します。