セキュリティーのための Kerberos (KRB5) 認証メカニズムのサポート
Kerberos 認証メカニズムにより、Kerberos 認証をサポートする他のアプリケーション (例えば、.NET や DB2® など) とのインターオペラビリティーが可能になります。 Kerberos 認証メカニズムは、シングル・サインオン (SSO) エンドツーエンドの相互運用可能なソリューションを提供し、元の要求元 ID を保持します。
- Kerberos とは
- Kerberos を認証メカニズムとして持つことの利点
- 単一の Kerberos レルム環境における Kerberos 認証
- 相互またはトラステッド Kerberos レルム環境における Kerberos 認証
- Kerberos を WebSphere Application Server 用の認証メカニズムとしてセットアップする前の考慮事項
- Kerberos 認証のサポート情報
- WebSphere Application Server 用の認証メカニズムとしての Kerberos のセットアップ
- ピュア Java クライアント用の認証メカニズムとしての Kerberos のセットアップ
Kerberos とは
Kerberos の歴史は長く、現在はバージョン 5.0 になっています。Kerberos は、各種のプラットフォームでサポートされています (例えば、Windows、Linux、Solaris、AIX®、および z/OS®)。この理由の 1 つには、Kerberos のソース・コードが、最初に開発されたマサチューセッツ工科大学 (MIT) から自由にダウンロードできるという点にあります。
Kerberos は、クライアント、サーバー、および Kerberos 鍵配布センター (KDC) と呼ばれる信頼のおける第三者機関という 3 つのパーツで構成されます。KDC は、認証サービスとチケット許可サービスを提供します。
KDC は、そのレルム内のすべてのセキュリティー・プリンシパルのユーザー・アカウントを格納するデータベースまたはリポジトリーを保守しています。多くの Kerberos 配布は、Kerberos プリンシパルとポリシー DB にはファイル・ベース・リポジトリーを使用していますが、Lightweight Directory Access Protocol (LDAP) をリポジトリーとして使用している配布もあります。
Kerberos は、グループ (すなわち、iKeys グループ、あるいはユーザーまたはプリンシパルのグループ) という概念をサポートしていません。KDC は、長期使用鍵をプリンシパルごとにそのアカウント・データベースで保守します。この長期使用鍵は、プリンシパルのパスワードから導出されます。長期使用鍵またはパスワードを知っているのは、KDC、およびプリンシパルが表しているユーザーだけでなければなりません。
Kerberos を認証メカニズムとして持つことの利点
Kerberos を WebSphere Application Server の認証メカニズムとして持つことの利点は以下のとおりです。
- Kerberos プロトコルは標準規格です。このため、Kerberos 認証をサポートする他のアプリケーション (例えば、.NET や DB2 など) とのインターオペラビリティーが可能になります。 Kerberos 認証メカニズムは、シングル・サインオン (SSO) エンドツーエンドの相互運用可能なソリューションを提供し、元の要求元 ID を保持します。
- Kerberos 認証を使用すると、ユーザーの平文のパスワードは、決してユーザー・マシンから出ることはありません。 ユーザーは、ユーザー・パスワードの片方向ハッシュ値を使用することによって、認証を行い、KDC から Kerberos チケット許可チケット (TGT) を取得します。 ユーザーはまた、TGT を使用することによって、KDC から Kerberos サービス・チケットも取得します。 クライアント ID を表す Kerberos サービス・チケットは、認証のために WebSphere Application Server に送信されます。
- Java クライアントは、Kerberos クレデンシャル・キャッシュを使用して Kerberos SSO に参加し、WebSphere Application Server による認証を受けることができます。
- HTTP プロトコルを使用する J2EE クライアント、Web サービス・クライアント、.NET クライアント、および Web ブラウザー・クライアントは、SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) トークンを使用して WebSphere Application Server による認証を受け、SPNEGO Web 認証を使用して SSO に参加できます。Web 認証サービスとしての SPNEGO のサポートは、このリリースの WebSphere Application Server の新機能です。
詳しくは、SPNEGO Web 認証を使用した HTTP 要求のシングル・サインオンを参照してください。
- WebSphere Application Server は、Kerberos 認証メカニズムと LTPA (Lightweight Third-Party Authentication) 認証メカニズムを同時にサポートできます。
- Kerberos 認証を使用するサーバー間通信が提供されています。
単一の Kerberos レルム環境における Kerberos 認証
WebSphere Application Server は、下図に示しているように、単一の Kerberos レルム環境で Kerberos 認証をサポートしています。

WebSphere Application Server は、認証用の Kerberos トークンまたは SPNEGO トークンを受信すると、Kerberos サービス・プリンシパル (SPN) を使用して要求側とのセキュリティー・コンテキストを確立します。 セキュリティー・コンテキストが確立されると、WebSphere Kerberos ログイン・モジュールは、クライアントの GSS 代行クレデンシャルを抽出し、Kerberos クレデンシャルに関する Kerberos 認証トークン・ベースを作成し、それらを他のトークンと一緒にクライアント・サブジェクトに配置します。
サーバーは、ダウンストリーム・サーバーまたはバックエンド・リソースを使用する必要がある場合には、このクライアント GSS 代行クレデンシャルを使用します。 ダウンストリーム・サーバーが Kerberos 認証をサポートしていない場合、サーバーは Kerberos トークンの代わりに LTPA トークンを使用します。クライアントが GSS 代行クレデンシャルを要求に含めていない場合、サーバーはダウンストリーム・サーバーに対して LTPA トークンを使用します。 Kerberos 認証トークンおよびプリンシパルは、セキュリティー属性伝搬フィーチャーのパーツとしてダウンストリーム・サーバーに伝搬されます。
WebSphere Application Server および KDC が同一のユーザー・レジストリーを使用していない場合は、Kerberos プリンシパル名を WebSphere ユーザー名にマップするために JAAS カスタム・ログイン・モジュールが必要になることがあります。
相互またはトラステッド Kerberos レルム環境における Kerberos 認証
WebSphere Application Server は、下図に示しているように、相互またはトラステッド Kerberos レルム環境においても Kerberos 認証をサポートします。

WebSphere Application Server は、認証用の Kerberos トークンまたは SPNEGO トークンを受信すると、Kerberos サービス・プリンシパル (SPN) を使用して要求側とのセキュリティー・コンテキストを確立します。セキュリティー・コンテキストが確立されると、WebSphere Kerberos ログイン・モジュールは、常にクライアントの GSS 代行クレデンシャルと Kerberos チケットを抽出して、それらを他のトークンと一緒にクライアント・サブジェクトに配置します。
サーバーは、ダウンストリーム・サーバーまたはバックエンド・リソースを使用する必要がある場合には、このクライアント GSS 代行クレデンシャルを使用します。 ダウンストリーム・サーバーが Kerberos 認証をサポートしていない場合、サーバーは Kerberos トークンの代わりに LTPA トークンを使用します。クライアントが GSS 代行クレデンシャルを要求に含めていない場合、サーバーはダウンストリーム・サーバーに対して LTPA トークンを使用します。 Kerberos 認証トークンおよびプリンシパルは、セキュリティー属性伝搬フィーチャーのパーツとしてダウンストリーム・サーバーに伝搬されます。
WebSphere Application Server および KDC が同一のユーザー・レジストリーを使用していない場合は、Kerberos プリンシパル名を WebSphere ユーザー名にマップするために JAAS カスタム・ログイン・モジュールが必要になることがあります。
このリリースの WebSphere Application Server では、新しい複数のセキュリティー・ドメインは、Kerberos をセル・レベルでのみサポートします。すべての WebSphere Application Server が、同一の Kerberos レルムによって使用される必要があります。ただし、Kerberos 認証をサポートするクライアント・リソースやバックエンド・リソース (例えば、DB2 や .NET サーバーなど) は、独自の Kerberos レルムを持つことができます。ピアツーピアおよび推移的なレルム間トラスト認証のみがサポートされます。トラステッド Kerberos レルムに対しては、以下の手順を実行する必要があります。
- Kerberos トラステッド・レルムのセットアップは、各 Kerberos KDC で実行する必要があります。Kerberos トラステッド・レルムのセットアップ方法について詳しくは、「Kerberos Administrator and User's guide」を参照してください。
- Kerberos 構成ファイルでトラステッド・レルムをリストする必要がある場合があります。
- 管理コンソールで、 をクリックして、Kerberos トラステッド・レルムを追加します。
下図は、Kerberos クレデンシャル・キャッシュを使用して、トラステッド Kerberos レルムに Kerberos トークンを持つ WebSphere Application Server に対する認証を受ける Java および管理クライアントを示しています。

- クライアントは、Kerberos クレデンシャル・キャッシュが存在している場合は、それを使用します。
- クライアントは、Kerberos クレデンシャル・キャッシュを使用して、レルム A の相互レルム・チケット (TGS_REQ) をレルム B の KDC に要求します。
- クライアントは、相互レルム・チケットを使用して、server1 の Kerberos サービス・チケット (TGS_REQ) を レルム A の KDC に要求します。
- KDC から返された Kerberos トークン (TGS_REP) は、CSIv2 メッセージ認証トークンに追加され、認証を受けるために server1 に送られます。
- サーバーは Krb5LoginModuleWrapper を呼び出し、krb5.keytab ファイルからのサーバーの Kerberos サービス・プリンシパル名 (SPN) と鍵を使用して、クライアントとのセキュリティー・コンテキストを確立します。サーバーは、クライアントとのセキュリティー・コンテキストを正常に確立すると、常にクライアント GSS 代行クレデンシャルとチケットを抽出し、それらをクライアント・サブジェクトに配置します。
- オプションで、KDC と WebSphere Application Server が同じユーザー・レジストリーを使用していない場合は、カスタムの JAAS ログイン・モジュールが必要になることがあります。
- WebSphere Application Server のユーザー・レジストリーを使用してユーザーが検証されます。
- 結果 (成功または失敗) がクライアントに返されます。
下図は、Kerberos プリンシパル名とパスワードを使用して、Kerberos トークンを持つ WebSphere Application Server による認証を受ける Java および管理クライアントを示しています。

- クライアントは KDC から Kerberos チケット許可チケット (TGT) を取得します。
- クライアントは、その TGT を使用して server1 の Kerberos サービス・チケット (TGS_REQ) を取得します。
- KDC から返された Kerberos トークン (TGS_REP) は、CSIv2 メッセージ認証トークンに追加され、認証を受けるために server1 に送られます。
- サーバーは Krb5LoginModuleWrapper を呼び出し、krb5.keytab ファイルからのサーバーの Kerberos サービス・プリンシパル名 (SPN) と鍵を使用して、クライアントとのセキュリティー・コンテキストを確立します。サーバーは、クライアントとのセキュリティー・コンテキストを正常に確立すると、常にクライアント GSS 代行クレデンシャルとチケットを抽出し、それらをクライアント・サブジェクトに配置します。
- オプションで、KDC と WebSphere Application Server が同じユーザー・レジストリーを使用していない場合は、カスタムの JAAS ログイン・モジュールが必要になることがあります。
- WebSphere Application Server のユーザー・レジストリーを使用してユーザーが検証されます。
- 結果がクライアントに返されます。
下図は、サーバー間通信を示しています。

WebSphere Application Server は、開始時にサーバー ID とパスワードを使用して KDC にログインし、TGT を取得します。次にその TGT を使用して、もう一方のサーバーと通信するためのサービス・チケットを要求します。WebSphere Application Server がサーバー ID とパスワードの代わりに内部のサーバー ID を使用する場合、サーバー間通信は LTPA トークンを使用して行われます。上の図では、以下のイベントが発生します。
- WebSphere Application Server 1 は、WebSphere Application Server 2 で実行する Enterprise JavaBeans (EJB) のメソッド foo() を呼び出します。
- Server1 は、Server1 の TGT を使用して Server2 の Kerberos サービス・チケット (TGS_REQ) を取得します。
- ステップ 2 と同じです。
- KDC から返された Kerberos トークン (TGS_REP) は、CSIv2 メッセージ認証トークンに追加され、認証を受けるために Server2 に送られます。
- Server2 は acceptSecContext() メソッドを呼び出し、krb5.keytab ファイルからの server2 の Kerberos サービス・プリンシパル名 (SPN) と鍵を使用して、server1 とのセキュリティー・コンテキストを確立します。 server2 は、server1 とのセキュリティー・コンテキストを正常に確立すると、常に server1 の GSS 代行クレデンシャルとチケットを抽出し、それらをサブジェクトに配置します。
- WebSphere ユーザー・レジストリーを使用して、サーバー ID が検証されます。

Kerberos を WebSphere Application Server 用の認証メカニズムとしてセットアップする前の考慮事項
現在、WebSphere Application Server は、認証用に HTTP ヘッダー内の SPNEGO トークン、Kerberos トークン、LTPA トークン、および BasicAuth (GSSUP) をサポートしています。
- 「Kerberos クレデンシャルの代行が有効」オプションを選択する必要があります。 このオプションについて詳しくは、管理コンソールを使用した認証メカニズムとしての Kerberos の構成を参照してください。
- クライアントは、ターゲット・サーバーがクライアント代行 Kerberos クレデンシャルを抽出し、それを使用してダウンストリーム・サーバーに移動できるよう、転送可能で、アドレスなしかつ更新可能なフラグの設定されたチケット許可チケット (TGT) を取得する必要があります。
- ダウンストリーム・サーバー、データ複製サービス (DRS) キャッシュ、およびクラスター環境に、アドレスのあるクライアント TGT を使用することはできません。
- ご使用の Kerberos KDC プラットフォームでクライアント代行 Kerberos を使用できることを確認してください。
- 実行時間の長いアプリケーションの場合、ターゲット・サーバーが代行 Kerberos を更新できるよう、クライアントは更新可能フラグの設定された TGT を要求する必要があります。
- 実行時間の長いアプリケーションの場合、Kerberos チケットが少なくともアプリケーションの実行中は有効であるようにしてください。例えば、アプリケーションが 5 分かかるトランザクションを処理する場合、Kerberos チケットは少なくとも 5 分間は有効である必要があります。
- Kerberos 認証と SPNEGO Web 認証はどちらも、同一のフォレスト内の Active Directory クロスドメイン・トラストに対してサポートされています。
- Kerberos 認証メカニズムを使用するためには、管理エージェントは、管理サブシステム・プロファイルと LTPA 鍵を交換する必要があります。
com.ibm.websphere.security.krb.longLivedTicket セキュリティー・カスタム・プロパティーは true に設定する必要があります。
- ダウンストリーム認証にクライアント代行 Kerberos クレデンシャルを使用する予定の場合は、クライアントが 10 分より長く有効なサービス・チケットを要求できるようにします。クライアント代行 Kerberos クレデンシャルの存続時間が 10 分に満たない場合、サーバーはそれを更新しようとします。
- Tivoli® Access Manager との完全なエンドツーエンド Kerberos サポートは、以下の KDC を使用して得られます。
- z/OS
- Microsoft (単一レルムまたはマルチ・レルム)
- AIX
- Linux
- WebSphere Application Server およびシン・クライアント用 Kerberos 相互レルムを構成して使用可能に設定できるようになりました。
- Kerberos での WebSphere Application Server の管理機能は、以下のことによって制限されています。
- 柔軟な管理アクティビティーを実現するために優先される認証メカニズムは、Rivest Shamir Adleman (RSA) 認証メカニズム (デフォルト) です。
- Kerberos が管理認証として構成されているジョブ・マネージャーは、相互 Kerberos レルムをサポートしません。これらのレルムは、登録されているノードと同じ Kerberos レルム内にあるか、管理認証が RSA に設定されている必要があります。
- Kerberos 認証は管理クライアント (wsadmin または Java クライアント) に対してサポートされていますが、WebSphere Application Server を管理しているのと同じ KDC レルムを使用する必要があります。 使用しない場合は、ユーザー ID とパスワードの使用を推奨します。
- ノードの一部が WebSphere Application Server リリース 6.x またはそれよりも前のノードである場合、Kerberos と LTPA が混在するセル構成はサポートされません。
Kerberos 認証のサポート情報
- 同じフォレストにない外部ドメイン・トラスト
- 同じフォレスト内のドメイン信頼
- Kerberos レルム・トラスト
- クロス・フォレスト・トラスト
- フォレスト外部トラスト
WebSphere Application Server 用の認証メカニズムとしての Kerberos のセットアップ
ピュア Java クライアント用の認証メカニズムとしての Kerberos のセットアップ
エンド・ユーザーは、オプションでピュア Java クライアント用の Kerberos 認証メカニズムをセットアップできます。詳しくは、Kerberos 認証用 Java クライアントの構成を参照してください。