SPNEGO Web 認証を使用した HTTP 要求のシングル・サインオン

WebSphere Application Server の Web 認証サービスとして Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) を使用することで、 WebSphere® Application Server の保護されたリソースに対する HTTP リクエストを安全にネゴシエートし、認証することができます。

以下のセクションでは、SPNEGO Web 認証について詳しく説明されています。

SPNEGO とは

SPNEGOは、 The Simple and Protected GSS-API Negotiation Mechanism（IETF RFC 2478 ）で定義されている標準仕様である。

Liberty サーバーのセキュリティが有効で、SPNEGO Web認証が有効な場合、最初の受信リクエスト（ HTTP ）を処理するときにSPNEGOが初期化される。 認証フィルターが指定されていないか、認証フィルターが指定されていて基準が満たされている場合、SPNEGO が、HTTP 要求で指定されている保護リソースへのアクセスの認証を処理します。

WebSphere Application Server セキュリティ・ランタイム・サービスに加え、SPNEGOの運用を可能にするためにいくつかの外部コンポーネントが必要となる。 これらの外部コンポーネントには、以下のものが含まれます。
  • Windows プラットフォームの場合Microsoft Windows Active Directory ドメインと関連する 鍵配布センター（KDC）を持つサーバー。 Kerberos
  • IETF RFC 2478で定義されているSPNEGO Web認証メカニズムをサポートする、Microsoft.NETなどのクライアント・アプリケーション、またはWebサービスや J2EE クライアント。 Microsoft Internet Explorer や はブラウザの例である。 Mozilla Firefox 使用するブラウザーは、SPNEGO Web 認証メカニズムを使用するように構成する必要があります。

HTTP 要求の認証はユーザー (クライアント・サイド) によって起動され、この際に SPNEGO トークンが生成されます。 WebSphere Application Server はこのトークンを受け取る。 特に、SPNEGO Web 認証は、SPNEGO トークンからユーザー ID をデコードして取得します。 その後、この ID は、許可の決定に使用されます。

SPNEGO ウェブ認証は、 WebSphere Application Server のサーバーサイド・ソリューションです。 クライアント・サイド・アプリケーションは、SPNEGO Web 認証が使用する SPNEGO トークンの生成を担当します。 WebSphere Application Server セキュリティ・レジストリのユーザー ID は、SPNEGO Web 認証が取得する ID と同一でなければならない。 Microsoft Windows Active Directory サーバーが、 WebSphere Application Server で使用されているLDAP（Lightweight Directory Access Protocol）サーバーである場合、同一の一致が起こる。 カスタムログインモジュールは、 Active Directory から WebSphere Application Server セキュリティレジストリへの ID のカスタムマッピングをサポートするプラグインとして利用できる。

WebSphere Application Server は、セキュリティ・レジストリと照合して ID を検証する。 検証が成功した場合、クライアント GSS 代行資格情報が取得され、クライアント・サブジェクト内に配置され、Lightweight Third Party Authentication (LTPA) セキュリティー・トークンが作成されます。 その後、HTTP 応答でユーザーに LTPA Cookie を返します。 WebSphere Application Server、より保護されたリソースにアクセスするための、この同じユーザーからのその後の HTTP リクエストは、繰り返されるログインチャレンジを避けるために、以前に作成されたLTPAセキュリティトークンを使用する。

単一 Kerberos レルム内での SPNEGO Web 認証

SPNEGO Web 認証は、単一 Kerberos レルム (ドメイン) でサポートされます。 以下の図に、ユーザー確認のための質問への応答ハンドシェーク・プロセスを示します。

図1： 単一 Kerberos レルム内での SPNEGO Web 認証

SPNEGO Web 認証は、単一 Kerberos レルムでサポートされます。 チャレンジ・レスポンス・ハンドシェイクのプロセスを示す。

上の図では、以下のイベントが発生します。

  1. 始めに、ユーザーはワークステーションからMicrosoftドメインコントローラー MYDOMAIN.EXAMPLE.COM にログオンする。
  2. 次に、ユーザーが、Web アプリケーションにアクセスしようとします。 ユーザーは、クライアントブラウザを使って保護されたWebリソースを要求し、ブラウザはリバティサーバーに HTTP GET 。
  3. Liberty サーバーのSPNEGO認証は、 Authenticate: Negotiate ステータスを含む HTTP 401 チャレンジヘッダでクライアントブラウザに答える。
  4. クライアントブラウザがnegotiateヘッダを認識するのは、クライアントブラウザが統合Windows認証をサポートするように設定されているからである。 クライアントが、要求された URL を解析してホスト名を取得します。 クライアントはホスト名を使用してターゲット Kerberos サービスプリンシパル名(SPN) HTTP/myLibertyMachine.example.com を形成し、マイクロソフト Kerberos KDC(TGS_REQ)内の Kerberos チケット付与サービス(TGS)に Kerberos サービスチケットを要求する。その後、 TGS は、 Kerberos サービスチケット(TGS_REP)をクライアントに発行する。 Kerberos サービスチケット（SPNEGOトークン）は、ユーザーの身元とサービス （Liberty サーバー）に対する権限の両方を証明する。
  5. その後、クライアントブラウザは Liberty サーバのAuthenticate：リクエスト HTTP ヘッダーで、前のステップで取得したSPNEGOトークンと チャレンジをネゴシエートする。
  6. Liberty サーバーのSPNEGO認証は、SPNEGOトークンを持つ HTTP ヘッダーを見て、SPNEGOトークンを検証し、ユーザーのID（プリンシパル）を取得する。
  7. Liberty サーバーは、ユーザーのIDを取得した後、ユーザーレジストリでユーザーを検証し、認可チェックを実行する。
  8. アクセスが許可された場合、 Liberty サーバーはレスポンスを HTTP 200 で送信する。 Liberty サーバーは、レスポンスにLTPAクッキーも含める。 この LTPA Cookie は、後続の要求で使用されます。
注： SPNEGOをサポートする他のクライアント（例えば、Webサービス、.NET、 J2EE ）は、先に示したようなチャレンジ-レスポンス・ハンドシェーク・プロセスに従う必要はない。 これらのクライアントは、ターゲット・サーバーのチケット許可チケット (TGT) および Kerberos サービス・チケットを取得して、SPNEGO トークンを作成し、そのトークンを HTTP ヘッダーに挿入してから HTTP 要求を作成する標準プロセスを実行することができます。

トラステッド Kerberos レルム内での SPNEGO Web 認証

SPNEGO Web 認証は、トラステッド Kerberos レルムでもサポートされます。 以下の図に、ユーザー確認のための質問への応答ハンドシェーク・プロセスを示します。

図2： トラステッド Kerberos レルム内での SPNEGO Web 認証

SPNEGO Web 認証は、トラステッド Kerberos レルムでもサポートされます。 チャレンジ・レスポンス・ハンドシェイクのプロセスを示す。

上の図では、以下のイベントが発生します。

  1. ユーザーはMicrosoftドメインコントローラー TRUSTEDREALM.ACME.COM にログインする。
  2. クライアントのブラウザーから、ユーザーは、元のMicrosoftドメインコントローラーの Liberty サーバーでホストされている保護されたWebリソースへのリクエストを行う MYDOMAIN.EXAMPLE.COM。
  3. Liberty サーバーは、 Authenticate: Negotiate ステータスを含む HTTP 401チャレンジヘッダでクライアントブラウザに応答する。
  4. クライアント・ブラウザは、統合Windows認証をサポートするように設定されている。 クライアント・ブラウザは、 Liberty サーバー・アプリケーションをホストしているワークステーションのホスト名を使用して、 URL を解析します。 クライアント・ブラウザーが、ホスト名を属性として使用して、レルム TRUSTEDREALM.ACME.COM に対して MYDOMAIN.EXAMPLE.COM の Kerberos クロス・レルム・チケット (TGS_REQ) を要求します。
  5. クライアント・ブラウザーが、ステップ 4 で取得した Kerberos クロス・レルム・チケットを使用して、レルム MYDOMAIN.EXAMPLE.COM に対して Kerberos サービス・チケットを要求します。 Kerberos サービスチケット（SPNEGOトークン）は、サービス （Liberty サーバー）に対するユーザーの身元と権限を証明する。
  6. その後、クライアントブラウザは Liberty サーバのAuthenticate：リクエスト HTTP ヘッダーで、前のステップで取得したSPNEGOトークンと チャレンジをネゴシエートする。
  7. Liberty サーバーはリクエストを受信し、 HTTP ヘッダーとSPNEGOトークンをチェックする。 次に、Kerberos サービス・チケットを抽出し、チケットを検証してから、ユーザーの ID (プリンシパル) を取得します。
  8. Liberty サーバーは、ユーザーのIDを取得した後、ユーザーレジストリでユーザーを検証し、認可チェックを実行する。
  9. アクセスが許可された場合、 Liberty サーバーはレスポンスを HTTP 200 で送信する。 Liberty サーバーは、レスポンスにLTPAクッキーも含める。 この LTPA Cookie は、後続の要求で使用されます。
注： Liberty サーバーに、より多くの信頼された領域をサポートするための変更は必要ない。 SPNEGO がトラステッド・レルムと連携するための要件は、必要な Active Directory レルム間に信頼関係があることのみです。

トラステッド Kerberos レルム環境では、各 Kerberos KDC で Kerberos トラステッド・レルムのセットアップを実行する必要があることに注意してください。 Kerberos トラステッド・レルムのセットアップ方法について詳しくは、「Kerberos 管理者およびユーザーズ・ガイド」を参照してください。

ブラウザー・クライアントまたは非ブラウザー・クライアントを使用した SPNEGO Web 認証のサポート情報

以下のシナリオがサポートされています。
  • 双方向のフォレスト信頼
  • 同じフォレスト内のドメイン信頼
  • Kerberos レルム信頼
以下のシナリオはサポートされません。
  • フォレストの外部信頼
  • ドメイン外部信頼

SPNEGO 認証は、SPNEGO トークンまたは Kerberos サービス・チケット (Kerberos トークン) のいずれかで認証できます。

Liberty サーバでの SPNEGO の設定については、 Liberty での SPNEGO 認証の設定 を参照してください。