SPNEGO のシングル・サインオン
WebSphere Application Serverの Web 認証サービスとして Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) を使用することにより、 WebSphere® Application Server で保護されたリソースに対する HTTP 要求を安全にネゴシエーションし、認証することができます。
- 管理コンソールを使用して、 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 要求内で識別される保護されたリソースへのアクセスの認証を担当します。
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 のカスタム・マッピングをサポートするプラグインとして、カスタム・ログイン・モジュールを使用できます。
このカスタム・ログイン・モジュールの使用について詳しくは、「
クライアント 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 システム・プロパティーへのアクセス権を持っています。

SPNEGO Web 認証の利点
WebSphere Application Server が WebSphere Application Server の Web 認証サービスとして SPNEGO を使用する利点には、以下のものがあります。
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 レルムでサポートされます。 以下の図に、チャレンジ応答ハンドシェーク・プロセスを示します。

上の図では、以下のイベントが発生します。
- クライアントは、HTTP/Post/Get/Web-Service 要求を WebSphere Application Serverに送信します。
- WebSphere Application Server は HTTP 401 Authenticate/Negotiate を返します。
- クライアントは、チケット許可チケット (TGT) を取得します。
- クライアントは、サービス・チケット (TGS_REQ) を要求します。
- クライアントは、サービス・チケット (TGS_REP) を取得します。
- クライアントは、HTTP/Post/Get/Web-Service と許可 SPNEGO トークンを WebSphere Application Serverに送信します。
- WebSphere Application Server は、SPNEGO トークンを検証します。 妥当性検査が成功した場合、ユーザー ID と GSS 代行クレデンシャルが
SPNEGO トークンから取得されます。 クライアント Kerberos 資格情報を持つ
KRBAuthnTokenが作成されます。 - WebSphere Application Server は、 WebSphere ユーザー・レジストリーを使用してユーザー ID を検証し、LTPA トークンを作成します。
- WebSphere Application Server は、 HTTP 200、コンテンツ、および LTPA トークンをクライアントに返します。
トラステッド Kerberos レルム内での SPNEGO Web 認証
SPNEGO Web 認証は、トラステッド Kerberos レルムでもサポートされます。 以下の図に、チャレンジ応答ハンドシェーク・プロセスを示します。

上の図では、以下のイベントが発生します。
- クライアントは、HTTP/Post/Get/Web-Service 要求を WebSphere Application Serverに送信します。
- WebSphere Application Server は HTTP 401 Authenticate/Negotiate を返します。
- クライアントは、チケット許可チケット (TGT) を取得します。
- クライアントは、REALM1 KDC から REALM2 の相互レルム・チケット (TGS_REQ) を要求します。
- クライアントは、ステップ 4 の相互レルム・チケットを使用して、REALM2 KDC からサービス・チケットを要求します。
- クライアントは、HTTP/Post/Get/Web-Service と許可 SPNEGO トークンを WebSphere Application Serverに送信します。
- WebSphere Application Server は、SPNEGO トークンを検証します。 妥当性検査が成功した場合、ユーザー ID と GSS 代行クレデンシャルが
SPNEGO トークンから取得されます。 クライアント Kerberos 資格情報を持つ
KRBAuthnTokenが作成されます。 - WebSphere Application Server は、 WebSphere ユーザー・レジストリーを使用してユーザー ID を検証し、LTPA トークンを作成します。
- WebSphere Application Server は、 HTTP 200、コンテンツ、および LTPA トークンをクライアントに返します。
トラステッド Kerberos レルム環境では、以下の点に注意してください。
- Kerberos トラステッド・レルムのセットアップは、各 Kerberos KDC で実行する必要があります。 Kerberos トラステッド・レルムのセットアップ方法について詳しくは、「Kerberos 管理者およびユーザーズ・ガイド」を参照してください。
- SPNEGO トークンの Kerberos クライアント・プリンシパル名が WebSphere ユーザー・レジストリーに存在しない可能性があります。 WebSphere ユーザー・レジストリーへの Kerberos プリンシパル・マッピングで必要になる場合があります。
詳しくは、「 WebSphere ユーザー・レジストリー ID へのクライアント Kerberos プリンシパル名のマッピング 」を参照してください。
HTTP プロトコルを使用する Java™ クライアントでの SPNEGO Web 認証のサポート情報
- 同じフォレスト内のドメイン信頼
- 異なるフォレスト内のドメイン間での外部ドメイン直接信頼
- Kerberos レルム信頼
- クロス・フォレスト・トラスト
- フォレストの外部信頼
ブラウザー・クライアントを使用した SPNEGO Web 認証のサポート情報
- 双方向のフォレスト信頼
- 同じフォレスト内のドメイン信頼
- Kerberos レルム信頼
- フォレストの外部信頼
- ドメイン外部信頼