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

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

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

Kerberos とは

Kerberos の歴史は長く、現在はバージョン 5.0 になっています。 Kerberos幅広いプラットフォームでサポートされています（たとえば、Windowsの場合、 Linux®、ソラリス、 AIX®、 そしてz/OS®）は、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 プロトコルは標準規格です。 これにより、他のアプリケーション（.NETなど）との相互運用が可能になります。 DB2など）をサポートするKerberos認証。 Kerberos 認証メカニズムは、シングル・サインオン (SSO) エンドツーエンドの相互運用可能なソリューションを提供し、元の要求元 ID を保持します。
  • Kerberos 認証を使用すると、ユーザーの平文のパスワードは、決してユーザー・マシンから出ることはありません。 ユーザーは、ユーザー・パスワードの片方向ハッシュ値を使用することによって、認証を行い、KDC から Kerberos チケット許可チケット (TGT) を取得します。 ユーザーはまた、TGT を使用することによって、KDC から Kerberos サービス・チケットも取得します。 のKerberosクライアントIDを表すサービスチケットが送信されますWebSphere Application Server認証用。
  • Javaクライアントは、KerberosSSOを使用するKerberos認証するための資格情報キャッシュWebSphere Application Server。
  • J2EE HTTPプロトコルを使用するWebサービス、.NET、Webブラウザクライアントは、Simple and Protected GSS-API Negotiation Mechanism（SPNEGO）トークンを使用して、 WebSphere Application ServerSPNEGO Web 認証を使用して SSO に参加します。 ウェブ認証サービスとしてのSPNEGOのサポートは、このリリースの新機能です。 WebSphere Application Server。

    詳しくはこちらSPNEGO シングル サインオン詳細については。

  • WebSphere Application Server両方をサポートできるKerberosおよび軽量サードパーティ認証 (LTPA) 認証メカニズムを同時に使用します。
  • Kerberos 認証を使用するサーバー間通信が提供されています。

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

WebSphere Application ServerサポートKerberos単一の認証Kerberos次の図に示すように、レルム環境は次のようになります。

図1： 単一の Kerberos レルム環境における Kerberos 認証
WebSphere Application ServerサポートKerberos単一の認証Kerberosレルム環境

ときWebSphere Application Server受け取るKerberosまたはSPNEGOトークンを認証に使用する場合は、Kerberosサービス プリンシパル (SPN) を使用して、要求元とのセキュリティ コンテキストを確立します。 セキュリティコンテキストが確立されると、WebSphereKerberosログインモジュールはクライアントのGSS委任資格情報を抽出し、Kerberos認証トークンベースKerberos資格情報を取得し、他のトークンとともにクライアント サブジェクトに配置します。

サーバーは、ダウンストリーム・サーバーまたはバックエンド・リソースを使用する必要がある場合には、このクライアント GSS 代行クレデンシャルを使用します。 ダウンストリーム・サーバーが Kerberos 認証をサポートしていない場合、サーバーは Kerberos トークンの代わりに LTPA トークンを使用します。 クライアントが GSS 代行クレデンシャルを要求に含めていない場合、サーバーはダウンストリーム・サーバーに対して LTPA トークンを使用します。 Kerberos 認証トークンおよびプリンシパルは、セキュリティー属性伝搬フィーチャーのパーツとしてダウンストリーム・サーバーに伝搬されます。

もし、 WebSphere Application ServerKDCが同じユーザーレジストリを使用しない場合は、 JAASカスタムログインモジュールは、Kerberos主な名前WebSphereユーザー名。

相互またはトラステッド Kerberos レルム環境における Kerberos 認証

WebSphere Application ServerサポートもKerberosクロス認証または信頼された認証Kerberos次の図に示すように、レルム環境は次のようになります。

図2： 相互またはトラステッド Kerberos レルム環境における Kerberos 認証
WebSphere Application ServerサポートもKerberosクロス認証または信頼された認証Kerberosレルム環境

ときWebSphere Application Server受け取るKerberosまたはSPNEGOトークンを認証に使用する場合は、Kerberosサービス プリンシパル (SPN) を使用して、要求元とのセキュリティ コンテキストを確立します。 セキュリティコンテキストが確立されると、WebSphereKerberosログインモジュールは常にクライアントのGSS委任資格情報を抽出し、Kerberosチケットを作成し、他のトークンとともにクライアント サブジェクトに配置します。

サーバーは、ダウンストリーム・サーバーまたはバックエンド・リソースを使用する必要がある場合には、このクライアント GSS 代行クレデンシャルを使用します。 ダウンストリーム・サーバーが Kerberos 認証をサポートしていない場合、サーバーは Kerberos トークンの代わりに LTPA トークンを使用します。 クライアントが GSS 代行クレデンシャルを要求に含めていない場合、サーバーはダウンストリーム・サーバーに対して LTPA トークンを使用します。 Kerberos 認証トークンおよびプリンシパルは、セキュリティー属性伝搬フィーチャーのパーツとしてダウンストリーム・サーバーに伝搬されます。

もし、 WebSphere Application ServerKDCが同じユーザーレジストリを使用しない場合は、 JAASカスタムログインモジュールは、Kerberos主な名前WebSphereユーザー名。

このリリースではWebSphere Application Server新しいセキュリティの複数のドメインは、Kerberos細胞レベルで。 全てWebSphere Application Serversは同じものを使用する必要がありますKerberos領域。 ただし、クライアントやバックエンドリソース（ DB2、.NETサーバーなど）をサポートするKerberos認証には独自のKerberos領域。 ピアツーピアおよび推移的なレルム間トラスト認証のみがサポートされます。 トラステッド Kerberos レルムに対しては、以下の手順を実行する必要があります。

  • Kerberos トラステッド・レルムのセットアップは、各 Kerberos KDC で実行する必要があります。 Kerberos トラステッド・レルムのセットアップ方法について詳しくは、「Kerberos Administrator and User's guide」を参照してください。
  • Kerberos 構成ファイルでトラステッド・レルムをリストする必要がある場合があります。
  • 追加Kerberos管理コンソールで信頼された領域をクリックすることでグローバルセキュリティ>CSIv2発信通信>信頼できる認証領域 - 送信。

次の図は、Javaと管理クライアントを示しています。Kerberos認証するための資格情報キャッシュWebSphere Application ServerとともにKerberos信頼できるトークンKerberos領域:

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

次の図は、Javaと管理クライアントを示しています。Kerberos認証するためのプリンシパル名とパスワードWebSphere Application ServerとともにKerberosトークン：

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

設定前に考慮すべき事項Kerberos認証メカニズムとしてWebSphere Application Server

WebSphere Application ServerHTTPヘッダーで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 ServerKDC マシンはクロックを同期させておく必要があります。 ベスト・プラクティスは、タイム・サーバーを使用してすべてのシステムの同期状態を保持することです。
このリリースではWebSphere Application Server以下の点に注意してください。
  • エンドツーエンドで完了KerberosTivoli® Access Manager のサポートは、次の KDC を使用して利用できます。
    • z/OS
    • Microsoft (単一または複数のレルム)
    • AIX
    • Linux
  • 設定して有効にできるようになりましたKerberosクロスレルムWebSphere Application Serverそしてシンクライアント。
  • WebSphere Application Server行政機能Kerberos以下の制限があります:
    • 柔軟な管理アクティビティーを実現するために優先される認証メカニズムは、Rivest Shamir Adleman (RSA) 認証メカニズム (デフォルト) です。
    • Kerberos が管理認証として構成されているジョブ・マネージャーは、相互 Kerberos レルムをサポートしません。 これらのレルムは、登録されているノードと同じ Kerberos レルム内にあるか、管理認証が RSA に設定されている必要があります。
    • その間Kerberos管理クライアント（wsadminまたはJavaクライアント）の認証がサポートされている場合は、 WebSphere Application Server管理します。 使用しない場合は、ユーザー ID とパスワードの使用を推奨します。
    • 混合セルKerberos一部のノードがLTPA構成をサポートしていない場合は、 WebSphere Application Serverリリース6.xノードまたはそれ以前。

Kerberos 認証のサポート情報

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

WebSphere Application Server 用の認証メカニズムとしての Kerberos のセットアップ

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

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

エンドユーザーはオプションで設定できますKerberos純粋な Java クライアントの認証メカニズム。 詳しくはこちらJavaクライアントの設定Kerberos認証詳細については。

[8.5.5.19 以降]

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

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

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

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