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

Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) を WebSphere® Application Server の Web 認証サービスとして使用することにより、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 要求で指定されている保護リソースへのアクセスの認証を処理します。

SPNEGO の操作を使用可能にするには、WebSphere Application Server セキュリティー・ランタイム・サービスに加えて、いくつかの外部コンポーネントが必要になります。これらの外部コンポーネントには、以下のものが含まれます。
  • For Windows platformsActive Directory ドメインおよび関連する Kerberos Key Distribution Center (KDC) を備えた Microsoft Windows サーバー。
  • クライアント・アプリケーション (例えば、Microsoft .NET、または IETF RFC 2478 で定義されている SPNEGO Web 認証メカニズムをサポートする Web サービスおよび J2EE クライアント)。ブラウザーの例としては、Microsoft Internet Explorer および Mozilla Firefox が挙げられます。使用するブラウザーは、SPNEGO Web 認証メカニズムを使用するように構成する必要があります。

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

SPNEGO Web 認証は、WebSphere Application Server のサーバー・サイドのソリューションです。クライアント・サイド・アプリケーションは、SPNEGO Web 認証が使用する SPNEGO トークンの生成を担当します。WebSphere Application Server セキュリティー・レジストリーにあるユーザー ID は、SPNEGO Web 認証が取得する ID と同一である必要があります。Microsoft Windows Active Directory サーバーが、WebSphere Application Server で使用される Lightweight Directory Access Protocol (LDAP) サーバーである場合、完全な一致になります。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 要求を Liberty サーバーに送信します。
  3. Liberty サーバー内の SPNEGO 認証が、Authenticate: Negotiate状況が含まれている HTTP 401 チャレンジ・ヘッダーでクライアント・ブラウザーに応答します。
  4. クライアント・ブラウザーは、統合 Windows 認証をサポートするように構成されているため、ネゴシエーション・ヘッダーを認識します。クライアントが、要求された URL を解析してホスト名を取得します。クライアントがそのホスト名を使用してターゲット Kerberos サービス・プリンシパル名 (SPN) HTTP/myLibertyMachine.example.com を生成し、Microsoft Kerberos KDC (TGS_REQ) 内の Kerberos チケット許可サービス (TGS) に対して Kerberos サービス・チケットを要求します。 その後、TGS が Kerberos サービス・チケット (TGS_REP) をクライアントに発行します。Kerberos サービス・チケット (SPNEGO トークン) は、ユーザーの ID と許可の両方をサービス (Liberty サーバー) に対して証明します。
  5. 次に、クライアント・ブラウザーが、要求 HTTP ヘッダーで前のステップで取得した SPNEGO トークンを使用して、Liberty サーバーからの Authenticate: Negotiate チャレンジに応答します。
  6. Liberty サーバーの SPNEGO 認証が、SPNEGO トークンが含まれた HTTP ヘッダーを認識し、SPNEGO トークンを検証し、ユーザーの ID (プリンシパル) を取得します。
  7. Liberty サーバーはユーザーの ID を取得した後に、ユーザー・レジストリーでユーザーを検証し、許可検査を実行します。
  8. アクセスが許可された場合、Liberty サーバーが HTTP 200 が含まれた応答を送信します。Liberty サーバーは、応答に LTPA Cookie も含めます。この 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 ドメイン・コントローラー MYDOMAIN.EXAMPLE.COM 内の Liberty サーバー上にホストされている保護 Web リソースを要求します。
  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 トークン) は、ユーザーの ID と許可をサービス (Liberty サーバー) に対して証明します。
  6. 次に、クライアント・ブラウザーが、要求 HTTP ヘッダーで前のステップで取得した SPNEGO トークンを使用して、Liberty サーバーからの Authenticate: Negotiate チャレンジに応答します。
  7. Liberty サーバーが要求を受信し、SPNEGO トークンが含まれている HTTP ヘッダーを検査します。次に、Kerberos サービス・チケットを抽出し、チケットを検証してから、ユーザーの ID (プリンシパル) を取得します。
  8. Liberty サーバーはユーザーの ID を取得した後に、ユーザー・レジストリーでユーザーを検証し、許可検査を実行します。
  9. アクセスが許可された場合、Liberty サーバーが HTTP 200 が含まれた応答を送信します。Liberty サーバーは、応答に LTPA Cookie も含めます。この LTPA Cookie は、後続の要求で使用されます。
注: 追加のトラステッド・レルムをサポートするために、Liberty サーバーで変更を加える必要はありません。SPNEGO がトラステッド・レルムと連携するための要件は、必要な Active Directory レルム間に信頼関係があることのみです。

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

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

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

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

Liberty サーバーでの SPNEGO の構成について詳しくは、『Liberty での SPNEGO 認証の構成』を参照してください。


トピックのタイプを示すアイコン 概念トピック

ファイル名: cwlp_spnego.html