セキュリティーのための Kerberos (KRB5) 認証メカニズムのサポート

Kerberos 認証メカニズムにより、 Kerberos 認証をサポートする他のアプリケーション (.NET、 DB2® など) とのインターオペラビリティーが可能になります。 Kerberos 認証メカニズムは、シングル・サインオン (SSO) エンドツーエンドの相互運用可能なソリューションを提供し、元の要求元 ID を保持します。

注: WebSphere® Application Server バージョン 7.0の認証メカニズムとして、 Kerberos のセキュリティー・サポートが追加されました。 Kerberos は、成熟し、柔軟性が高く、オープン、かつ非常にセキュアなネットワーク認証プロトコルです。 Kerberos には、認証、相互認証、メッセージの保全性と機密性、および委任の機能が含まれています。 サーバー・サイドで Kerberos を使用可能にすることができます。 リッチ Java™ クライアントが WebSphere Application Serverへの認証に Kerberos トークンを使用できるようにするためのサポートが提供されています。
以下のセクションで、Kerberos 認証についてより詳しく説明します。

Kerberos とは

Kerberos の歴史は長く、現在はバージョン 5.0 になっています。 Kerberos は、広範囲にわたるプラットフォーム・サポート (例えば、Windows、 Linux®、Solaris、 AIX®、および z/OS®の場合) を利用できます。これは、 Kerberos ソース・コードが元々作成されたマサチューセッツ工科大学 (MIT) から自由にダウンロードできるためです。

Kerberos は、クライアント、サーバー、および Kerberos 鍵配布センター (KDC) と呼ばれる信頼のおける第三者機関という 3 つのパーツで構成されます。 KDC は、認証サービスとチケット許可サービスを提供します。

KDC は、そのレルム内のすべてのセキュリティー・プリンシパルのユーザー・アカウントを格納するデータベースまたはリポジトリーを保守しています。 多くの Kerberos 配布は、Kerberos プリンシパルとポリシー DB にはファイル・ベース・リポジトリーを使用していますが、Lightweight Directory Access Protocol (LDAP) をリポジトリーとして使用している配布もあります。

Kerberos は、グループ (すなわち、iKeys グループ、あるいはユーザーまたはプリンシパルのグループ) という概念をサポートしていません。 KDC は、長期使用鍵をプリンシパルごとにそのアカウント・データベースで保守します。 この長期使用鍵は、プリンシパルのパスワードから導出されます。 長期使用鍵またはパスワードを知っているのは、KDC、およびプリンシパルが表しているユーザーだけでなければなりません。

Kerberos を認証メカニズムとして持つことの利点

WebSphere Application Server の認証メカニズムとして Kerberos を使用することには、以下のような利点があります。

  • 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に対する認証を行うことができます。
  • J2EE、Web サービス、.NET、および HTTP プロトコルを使用する Web ブラウザー・クライアントは、Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) トークンを使用して、 WebSphere Application Server に対して認証し、SPNEGO Web 認証を使用して SSO に参加することができます。 Web 認証サービスとしての SPNEGO のサポートは、このリリースの WebSphere Application Serverの新機能です。

    詳しくは、 SPNEGO シングル・サインオン を参照してください。

  • WebSphere Application Server は、 Kerberos 認証メカニズムと Lightweight Third-Party Authentication (LTPA) 認証メカニズムの両方を同時にサポートできます。
  • Kerberos 認証を使用するサーバー間通信が提供されています。

単一の Kerberos レルム環境における Kerberos 認証

WebSphere Application Server は、以下の図に示すように、単一の Kerberos レルム環境で Kerberos 認証をサポートします。

図1： 単一の 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 認証もサポートします。

図2： 相互またはトラステッド 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 構成ファイルでトラステッド・レルムをリストする必要がある場合があります。
  • グローバル・セキュリティー > CSIv2 アウトバウンド通信 > トラステッド認証レルム-アウトバウンドをクリックして、管理コンソールに Kerberos トラステッド・レルムを追加します。

以下の図は、 Kerberos 資格情報キャッシュを使用して、トラステッド Kerberos レルム内の Kerberos トークンを使用して WebSphere Application Server に対する認証を行う Java および管理クライアントを示しています。

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

以下の図は、 Kerberos トークンを使用して WebSphere Application Server に対する認証を行うために、 Kerberos プリンシパル名とパスワードを使用する Java および管理クライアントを示しています。

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

下図は、サーバー間通信を示しています。

図 5. サーバー間通信
WebSphere アプリケーション・サーバーは、始動時にサーバー ID とパスワードを使用して KDC にログインし、TGT を取得します。 次にその TGT を使用して、もう一方のサーバーと通信するためのサービス・チケットを要求します。 WebSphere アプリケーション・サーバーがサーバー ID とパスワードの代わりに内部サーバー ID を使用する場合、サーバー間通信は LTPA トークンを使用して行われます。

WebSphere Application Server は始動時に、サーバー ID とパスワードを使用して KDC にログインし、TGT を取得します。 次にその TGT を使用して、もう一方のサーバーと通信するためのサービス・チケットを要求します。 WebSphere Application Server がサーバー ID とパスワードの代わりに内部サーバー ID を使用する場合、サーバー間通信は LTPA トークンを使用して行われます。 上の図では、以下のイベントが発生します。

  1. WebSphere Application Server 1 は、 WebSphere Application Server 2 で稼働する Enterprise JavaBeans (EJB) でメソッド foo () を呼び出します。
  2. Server1 は、Server1 の TGT を使用して Server2 の Kerberos サービス・チケット (TGS_REQ) を取得します。
  3. ステップ 2 と同じです。
  4. KDC から返された Kerberos トークン (TGS_REP) は、CSIv2 メッセージ認証トークンに追加され、認証を受けるために Server2 に送られます。
  5. Server2 は acceptSecContext () メソッドを呼び出し、 krb5.keytab ファイルから server2 Kerberos サービス・プリンシパル名 (SPN) と鍵を使用して server1 とのセキュリティー・コンテキストを確立します。 server2 は、server1 とのセキュリティー・コンテキストを正常に確立すると、常に server1 の GSS 代行クレデンシャルとチケットを抽出し、それらをサブジェクトに配置します。
  6. サーバー ID は、 WebSphere ユーザー・レジストリーを使用して検証されます。
トラブルの回避: Java クライアント・アプリケーションとアプリケーション・サーバーが同じマシン上に存在し、異なる Kerberos レルム名を使用する場合、ランタイムは Kerberos 構成ファイルのデフォルト・レルム名を使用します。 あるいは、ログイン処理時にレルム名を指定できます。
問題の回避: Kerberos および LTPA 認証は、複数の KDC 環境で構成できます。 基本認証は、Kerberos レルム名を使用せずに、パスワードとショート・ネームから構成できます。 この基本認証の場合、domain_realm エレメントと default_realm エレメントによって、要求を認証するために Kerberos クライアントがどの KDC を使用するのが決まります。 決定した KDC に属していないユーザーは、完全修飾 Kerberos プリンシパル名 (例: Bob@myKerberosRealm) を使用してログインする必要があります。

WebSphere Application Server の認証メカニズムとして Kerberos をセットアップする前に考慮すべき事項

WebSphere Application Server は、HTTP ヘッダー内の SPNEGO トークン、 Kerberos トークン、LTPA トークン、および認証用の BasicAuth (GSSUP) をサポートするようになりました。

エンドツーエンドの Kerberos ソリューションおよびエンドツーエンドの SPNEGO to Kerberos ソリューションを提供するには、以下のことを考慮してください。
  • 「Kerberos クレデンシャルの代行が有効」オプションを選択する必要があります。 このオプションについて詳しくは、 管理コンソールを使用した認証メカニズムとしての Kerberos の構成 を参照してください。
  • クライアントは、ターゲット・サーバーがクライアント代行 Kerberos クレデンシャルを抽出し、それを使用してダウンストリーム・サーバーに移動できるよう、転送可能で、アドレスなしかつ更新可能なフラグの設定されたチケット許可チケット (TGT) を取得する必要があります。
  • ダウンストリーム・サーバー、データ複製サービス (DRS) キャッシュ、およびクラスター環境に、アドレスのあるクライアント TGT を使用することはできません。
  • ご使用の Kerberos KDC プラットフォームでクライアント代行 Kerberos を使用できることを確認してください。
  • 実行時間の長いアプリケーションの場合、ターゲット・サーバーが代行 Kerberos を更新できるよう、クライアントは更新可能フラグの設定された TGT を要求する必要があります。
  • 実行時間の長いアプリケーションの場合、Kerberos チケットが少なくともアプリケーションの実行中は有効であるようにしてください。 例えば、アプリケーションが 5 分かかるトランザクションを処理する場合、Kerberos チケットは少なくとも 5 分間は有効である必要があります。
  • Kerberos 認証と SPNEGO Web 認証はどちらも、同一のフォレスト内の Active Directory クロスドメイン・トラストに対してサポートされています。
  • Kerberos 認証メカニズムを使用するためには、管理エージェントは、管理サブシステム・プロファイルと LTPA 鍵を交換する必要があります。
  • ダウンストリーム認証にクライアント代行 Kerberos クレデンシャルを使用する予定の場合は、クライアントが 10 分より長く有効なサービス・チケットを要求できるようにします。 クライアント代行 Kerberos クレデンシャルの存続時間が 10 分に満たない場合、サーバーはそれを更新しようとします。
注: クライアント、 WebSphere Application Server 、および KDC マシンは、クロックの同期を保つ必要があります。 ベスト・プラクティスは、タイム・サーバーを使用してすべてのシステムの同期状態を保持することです。
WebSphere Application Serverのこのリリースでは、以下の点に注意してください。
  • 以下の KDC を使用して、Tivoli ® Access Manager で完全なエンドツーエンドの Kerberos サポートを使用できます。
    • 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 のセットアップ

WebSphere Application Server の認証メカニズムとしての Kerberos のセットアップ にリストされている順序でステップを実行して、 Kerberos を WebSphere Application Serverの認証メカニズムとしてセットアップする必要があります。
注: サーバー・サイドの Kerberos 認証メカニズムは、システム管理者が実行し、Java クライアント・サイドでユーザーが実行する必要があります。 Kerberos キータブ・ファイルを保護する必要があります。

ピュア Java クライアントの認証メカニズムとしての Kerberos のセットアップ

エンド・ユーザーは、ピュアな Java クライアントの Kerberos 認証メカニズムをオプションでセットアップできます。 詳しくは、 Kerberos 認証用の Java クライアントの構成 を参照してください。

[9.0.5.7 以降]

LDAP 用のバインド認証メカニズムとしての Kerberos のセットアップ

LDAP サーバーにバインドし、ユーザーおよびグループの検索を実行するために、バインド認証メカニズムとして Kerberos をセットアップできます。 このバインド認証メカニズムは、バインド識別名とバインド・パスワードを使用するシンプルなバインド認証メカニズムの代替方法として使用できます。

統合リポジトリー内の LDAP サーバー用のバインド認証メカニズムとして Kerberos を構成するには、統合リポジトリー構成での LDAP の構成に関するトピックのステップを実行します。

スタンドアロン LDAP サーバー用のバインド認証メカニズムとして Kerberos を構成するには、LDAP ユーザー・レジストリーの構成に関するトピックのステップを実行します。