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 セキュリティー・ランタイム・サービスに加えて、いくつかの外部コンポーネントが必要です。 これらの外部コンポーネントには、以下のものが含まれます。
  • Windows プラットフォームの場合Microsoft Windows Active Directory ドメインおよび関連する Kerberos 鍵配布センター (KDC) を備えたサーバー。
  • 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 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 トークン) は、サービス (Liberty サーバー) に対するユーザーの ID と許可を証明します。
  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 管理者およびユーザーズ・ガイド」を参照してください。

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

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

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

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