SPNEGO のシングル・サインオン

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

注: WebSphere Application Server バージョン 6.1では、Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) を使用して、保護されたリソースに対する HTTP 要求を安全にネゴシエーションし、認証するトラスト・アソシエーション・インターセプター (TAI) が導入されました。 この機能は、 WebSphere Application Server バージョン 7.0では推奨されません。 代わりに SPNEGO Web 認証が導入され、以下の機能拡張が提供されるようになりました。
  • 管理コンソールを使用して、 WebSphere Application Server 上で SPNEGO Web 認証およびフィルターを構成し、使用可能にすることができます。
  • SPNEGO の動的再ロードは、 WebSphere Application Serverを停止して再始動することなく提供されます。
  • SPNEGO Web 認証に失敗した場合は、アプリケーション・ログイン・メソッドへのフォールバックが行われます。
  • SPNEGO は、 WebSphere セキュリティー・ドメイン・レベルでカスタマイズできます。 詳しくは、 複数のセキュリティー・ドメイン を参照してください。

SPNEGO TAI または SPNEGO Web 認証のいずれかを使用可能にすることはできますが、両方を使用可能にすることはできません。

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

SPNEGO とは

SPNEGO は、 The Simple and Protected GSS-API Negotiation Mechanism (IETF RFC 2478)で定義された標準仕様です。

WebSphere Application Server のグローバル・セキュリティーとアプリケーション・セキュリティーが有効になっていて、SPNEGO Web 認証が有効になっている場合、最初のインバウンド HTTP 要求の処理時に SPNEGO が初期化されます。 次に、Web オーセンティケーター・コンポーネントが SPNEGO と対話します。これは、セキュリティー構成リポジトリーで定義されて使用可能になります。 フィルター基準が満たされると、 SPNEGO は、HTTP 要求内で識別される保護されたリソースへのアクセスの認証を担当します。

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

HTTP 要求の認証は、要求側 (クライアント・サイド) によって起動され、SPNEGO トークンを生成します。 WebSphere Application Server は、このトークンを受け取ります。 特に、SPNEGO Web 認証は、要求元 ID をデコードし、SPNEGO トークンから取得します。 この 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 のカスタム・マッピングをサポートするプラグインとして、カスタム・ログイン・モジュールを使用できます。

[AIX Solaris HP-UX Linux Windows][IBM i]このカスタム・ログイン・モジュールの使用について詳しくは、「 [AIX Solaris HP-UX Linux Windows][IBM i]クライアント Kerberos プリンシパル名の WebSphere ユーザー・レジストリー ID へのマッピング 」を参照してください。

WebSphere Application Server は、セキュリティー・レジストリーに照らして ID を検証します。 妥当性検査が成功した場合、 クライアント Kerberos チケットおよび GSS 代行認証が取得され、クライアント・サブジェクト内に 配置されます。これにより、Lightweight Third Party Authentication (LTPA) セキュリティー・トークンが作成されます。 これにより、 HTTP 応答内に要求者に対する Cookie が配置され戻されます。 この同じリクエスターから WebSphere Application Server 内の追加の保護されたリソースにアクセスするための後続の HTTP 要求は、以前に作成された LTPA セキュリティー・トークンを使用して、ログイン・チャレンジの繰り返しを回避します。

以下の図で、Web 管理者は、SPNEGO セキュリティー・コンポーネントおよび関連付けられた構成データである、Web 認証モジュール、SPNEGO トラスト・アソシエーション・インターセプター、JGSS および SPNEGO セキュリティー・プロバイダー、Kerberos 構成と Kerberos キータブ・ファイル、SPNEGO TAI 構成プロパティー、および JVM システム・プロパティーへのアクセス権を持っています。

図1: SPNEGO Web 認証およびセキュリティー構成要素
SPNEGO とセキュリティー構成要素との関係を示す図

SPNEGO Web 認証の利点

WebSphere Application ServerWebSphere Application Server の Web 認証サービスとして SPNEGO を使用する利点には、以下のものがあります。

  • [Windows] Active Directory ドメインを使用する Microsoft Windows サーバーとの統合シングル・サインオン環境が確立されます。
  • 多数の ID およびパスワードの管理コストが削減されます。
  • Web ブラウザーまたは Microsoft .NET クライアントからのセキュリティー資格情報のセキュアで相互認証された伝送が確立されます。
  • トランスポート・レベルで SPNEGO 認証を使用する Web サービスおよび Microsoft .NET、または Web サービス・アプリケーションとのインターオペラビリティーを実現します。
  • Kerberos 認証サポートを使用すると、SPNEGO Web 認証で Kerberos ソリューションへのエンドツーエンド SPNEGO が提供され、クライアントからの Kerberos クレデンシャルを保存することができます。

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

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

図2: 単一 Kerberos レルム内での SPNEGO Web 認証
SPNEGO Web 認証は、単一 Kerberos レルムでサポートされます。 チャレンジ応答ハンドシェーク・プロセスが示されています。

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

  1. クライアントは、HTTP/Post/Get/Web-Service 要求を WebSphere Application Serverに送信します。
  2. WebSphere Application ServerHTTP 401 Authenticate/Negotiate を返します。
  3. クライアントは、チケット許可チケット (TGT) を取得します。
  4. クライアントは、サービス・チケット (TGS_REQ) を要求します。
  5. クライアントは、サービス・チケット (TGS_REP) を取得します。
  6. クライアントは、HTTP/Post/Get/Web-Service と許可 SPNEGO トークンを WebSphere Application Serverに送信します。
  7. WebSphere Application Server は、SPNEGO トークンを検証します。 妥当性検査が成功した場合、ユーザー ID と GSS 代行クレデンシャルが SPNEGO トークンから取得されます。 クライアント Kerberos 資格情報を持つ KRBAuthnToken が作成されます。
  8. WebSphere Application Server は、 WebSphere ユーザー・レジストリーを使用してユーザー ID を検証し、LTPA トークンを作成します。
  9. WebSphere Application Server は、 HTTP 200、コンテンツ、および LTPA トークンをクライアントに返します。
注: SPNEGO をサポートする他のクライアント (例えば、Web サービス、.NET、および J2EE) は、前述のチャレンジ応答ハンドシェーク・プロセスに従う必要はありません。 これらのクライアントは、ターゲット・サーバーのチケット許可チケット (TGT) および Kerberos サービス・チケットを取得して、SPNEGO トークンを作成し、 そのトークンを HTTP ヘッダーに挿入し、次に HTTP 要求を作成する標準プロセスを実行することができます。

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

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

図3: トラステッド Kerberos レルム内での SPNEGO Web 認証
SPNEGO Web 認証は、トラステッド Kerberos レルムでもサポートされます。 チャレンジ応答ハンドシェーク・プロセスが示されています。

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

  1. クライアントは、HTTP/Post/Get/Web-Service 要求を WebSphere Application Serverに送信します。
  2. WebSphere Application ServerHTTP 401 Authenticate/Negotiate を返します。
  3. クライアントは、チケット許可チケット (TGT) を取得します。
  4. クライアントは、REALM1 KDC から REALM2 の相互レルム・チケット (TGS_REQ) を要求します。
  5. クライアントは、ステップ 4 の相互レルム・チケットを使用して、REALM2 KDC からサービス・チケットを要求します。
  6. クライアントは、HTTP/Post/Get/Web-Service と許可 SPNEGO トークンを WebSphere Application Serverに送信します。
  7. WebSphere Application Server は、SPNEGO トークンを検証します。 妥当性検査が成功した場合、ユーザー ID と GSS 代行クレデンシャルが SPNEGO トークンから取得されます。 クライアント Kerberos 資格情報を持つ KRBAuthnToken が作成されます。
  8. WebSphere Application Server は、 WebSphere ユーザー・レジストリーを使用してユーザー ID を検証し、LTPA トークンを作成します。
  9. WebSphere Application Server は、 HTTP 200、コンテンツ、および LTPA トークンをクライアントに返します。

トラステッド Kerberos レルム環境では、以下の点に注意してください。

  • Kerberos トラステッド・レルムのセットアップは、各 Kerberos KDC で実行する必要があります。 Kerberos トラステッド・レルムのセットアップ方法について詳しくは、「Kerberos 管理者およびユーザーズ・ガイド」を参照してください。
  • SPNEGO トークンの Kerberos クライアント・プリンシパル名が WebSphere ユーザー・レジストリーに存在しない可能性があります。 WebSphere ユーザー・レジストリーへの Kerberos プリンシパル・マッピングで必要になる場合があります。

    [AIX Solaris HP-UX Linux Windows][IBM i]詳しくは、「 WebSphere ユーザー・レジストリー ID へのクライアント Kerberos プリンシパル名のマッピング 」を参照してください。

HTTP プロトコルを使用する Java™ クライアントでの SPNEGO Web 認証のサポート情報

以下のシナリオがサポートされています。
  • 同じフォレスト内のドメイン信頼
  • 異なるフォレスト内のドメイン間での外部ドメイン直接信頼
  • Kerberos レルム信頼
以下のシナリオはサポートされません。
  • クロス・フォレスト・トラスト
  • フォレストの外部信頼

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

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

WebSphere Application Server の Web 認証メカニズムとして SPNEGO をセットアップ

管理コンソールまたは wsadmin コマンドを使用して SPNEGO Web 認証をセットアップする前に、「 SPNEGO Web 認証を使用した HTTP 要求のシングル・サインオンの作成 」にリストされているステップを実行して、 WebSphere Application Server用に SPNEGO Web 認証をセットアップする必要があります。
注: サーバー・サイドでの SPNEGO Web 認証は、システム管理者が行う必要があります。 Kerberos キータブ・ファイルは、保護される必要があります。