このJava GSS-APIチュートリアルは、JAAS認証の最初のステップです。前のチュートリアルでは、JAASを使用してユーザー認証を行う方法と、JAASに必要なログイン構成ファイル(使用する基盤となる認証技術を指定する)の例を示しました。JAAS入門チュートリアルの「JAAS認証」のアプリケーションは、JAASメソッドを直接コールしました。「JAAS Loginユーティリティの使用」チュートリアルでは、アプリケーションをこの操作から解放するユーティリティ・プログラムの使用方法を示しました。このチュートリアルのクライアントおよびサーバー・アプリケーションでも同じユーティリティ・プログラムを使用しますので、あらかじめLoginユーティリティのチュートリアルの内容を確認してからこのチュートリアルに進むことをお薦めします。

この一連のチュートリアルでは、Kerberosを認証およびアプリケーションのセキュアな通信をサポートする基幹技術として使用しています。「Kerberos要件」を参照してください。

このチュートリアルで使用するアプリケーションの名前は、SampleClientおよびSampleServerです。

それぞれ、このチュートリアルで提供するLoginユーティリティを実行して呼び出し、引数として、アプリケーションの名前(SampleClientまたはSampleServer)と、続いてアプリケーションが必要とする引数をそれに渡します。Loginユーティリティは、JAAS LoginContextを使用して、Kerberosを使用するユーザーを認証します。最後に、Loginユーティリティはアプリケーション・クラス(ここではSampleClientまたはSampleServer)のmainメソッドを呼び出して、アプリケーションに引数を渡します。

次に、SampleClientおよびSampleServerアプリケーションの実行方法のサマリーを示します。

1. 引数にSampleServer、続いてSampleServerプログラム用の引数を指定してLoginユーティリティを実行することにより、SampleServerアプリケーションを実行します。Loginユーティリティにより、SampleServerを実行するプリンシパルのパスワード入力が求められます。(「Kerberosユーザー名およびサービス・プリンシパル名」を参照)。認証完了後に、SampleServerが実行されます。
   1. 引数に注目し、クライアントからの接続を待機するポート番号を確認します。
   2. 指定されたポートでのクライアント接続を待機するServerSocketを作成します。
   3. 接続を待機します。
2. 引数にSampleClient、続いてSampleClientプログラム用の引数を指定してLoginユーティリティを実行することにより、SampleClientアプリケーションを実行します(通常別のマシンを使用)。Loginユーティリティにより、Kerberos名およびパスワードの入力が求められます。認証完了後に、SampleClientが実行されます。次を実行します
   1. その引数を参照してください。(1) SampleServerを表すKerberosプリンシパルの名前。(Kerberosユーザー名およびサービス・プリンシパル名を参照)、(2) SampleServerを実行中のホスト(マシン)の名前、(3) SampleServerがクライアント接続を待機するポート番号。
   2. 引数として渡されたホストおよびポートを使用して、SampleServerへのソケット接続を試みます。
3. ソケット接続がSampleServerにより受け入れられます。両方のアプリケーションが、ソケット入力および出力ストリームからのDataInputStreamおよびDataOutputStreamを初期化して、将来のデータ交換に使用します。
4. SampleClientおよびSampleServerは、それぞれGSSContextをインスタンス化し、以後のセキュアなデータ交換を可能にする共有コンテキストを確立します。
5. これで、SampleClientおよびSampleServerは、メッセージをセキュアに交換できます。
6. SampleClientおよびSampleServerは、メッセージ交換の完了後に、クリーンアップ操作を実行します。

このチュートリアルで使用するコードの詳細は、Java GSS-APIを使用した、JAASプログラミングなしのセキュアなメッセージ交換チュートリアルのSampleClientおよびSampleServerコードの項を参照してください。

このチュートリアルでは、ベースとなる認証およびセキュアな通信技術としてKerberos V5が使用されているため、ユーザーまたはサービスが要求される場合、常にKerberosスタイルのプリンシパル名が使用されます(プリンシパルを参照)。

たとえば、SampleClientを実行する場合、ユーザー名の指定が求められます。Kerberosスタイルのユーザー名は、Kerberos認証用だけに割り当てられたユーザー名です。ベース・ユーザー名(mjonesなど)、「@」およびレルムの順序で構成されます(例、mjones@KRBNT-OPERATIONS.EXAMPLE.COM)。

通常、SampleServerなどのサーバー・プログラムは、「サービス」を提供し、特定の「サービス・プリンシパル」に代わって実行されるプログラムと見なされます。SampleServerのサービス・プリンシパル名が必要とされるのは、次の場合です。

• SampleServerの実行時に、適切なサービス・プリンシパルとしてログインする必要があります。このチュートリアルのログイン構成ファイルは、実際にサービス・プリンシパル名を指定します(Krb5LoginModuleのオプションとして)。このため、JAAS認証(Loginユーティリティによって実行される)は、そのサービス・プリンシパルのパスワードの指定のみをユーザーに求めます。適切なパスワードを指定すると、認証に成功し、サービス・プリンシパル名でPrincipalを含むSubjectが作成されます。その後に実行されるコード(SampleServerコード)は、指定されたプリンシパルに代わって実行されたと見なされます。
• SampleClientを実行する場合、引数の1つはサービス・プリンシパル名です。これは必須です。このため、SampleClientは適切なサービスを使用してセキュリティ・コンテキストの確立を開始できます。

このドキュメント全体、および関連するログイン構成ファイルでは、service_principal@your_realmは、環境内で使用される実際の名前に置き換えられるプレースホルダとして使用されます。サービス・プリンシパル名として、任意の Kerberosプリンシパルを実際に使用できます。このため、このチュートリアルを実行してみる場合、クライアント・ユーザー名とサービス・プリンシパル名の両方に自分のユーザー名を使用できます。

通常、本番稼動環境では、システム管理者は、サーバーを特定のプリンシパルのみで実行し、特定の名前を割り当てて使用します。たいてい、割り当てるKerberos形式のサービス・プリンシパル名は、次のようになります。

service_name/machine_name@realm; 

たとえば、KRBNT-OPERATIONS.EXAMPLE.COMというレルム内の「raven」という名前のマシンでnfsサービスを実行する場合、サービス・プリンシパル名は次のようになります

nfs/raven@KRBNT-OPERATIONS.EXAMPLE.COM

ただし、このようなマルチコンポーネント名は必須ではありません。ユーザー・プリンシパル名のような、シングルコンポーネント名も使用できます。たとえば、インストールによって、レルム内のすべてのftpサーバーで同じftpサービス・プリンシパルftp@realmを使用する場合と、ftpサーバーごとに異なるftpプリンシパルを使用する(たとえば、マシンhost1、host2のftpプリンシパルがそれぞれftp/host1@realm、ftp/host2@realmとなる)場合があります。

JAASを使用する場合は常に、使用する認証テクノロジをログイン構成ファイルに指定する必要があります。(ログイン構成ファイルの詳細は、付録B: JAASログイン構成ファイルを参照してください。)ログイン構成ファイルに、クライアント側が使用するエントリとサーバー側が使用するエントリの2つが含まれる場合、SampleClientとSampleServerの両方で同じログイン構成ファイルを使用できます。

このチュートリアルで使用するログイン構成ファイルcsLogin.confを、次に示します。

SampleClient {
  com.sun.security.auth.module.Krb5LoginModule required;
};

SampleServer {
  com.sun.security.auth.module.Krb5LoginModule required storeKey=true 
    principal="service_principal@your_realm";
};

各エントリの名前は、2つのトップレベル・アプリケーションSampleClientおよびSampleServerのクラス名にそれぞれ一致します。これは、アプリケーション用のJAAS操作を実行するLoginユーティリティに渡される名前でもあることに留意してください。Loginユーティリティがログイン構成ファイル内で検索するエントリ名は、渡されたエントリ名と同じになります。

両方のエントリでは、ユーザー認証の成功のため、OracleのKerberos V5ログイン・モジュールを使用する必要があることが指定されています。Krb5LoginModuleが成功するのは、指定されたエンティティでのKerberos KDCへのログインが成功した場合だけです。SampleClientの場合、ユーザーは名前とパスワードの入力を求められます。SampleServerの場合、このログイン構成ファイルに名前(指定されたプリンシパル)が指定されているため、SampleServerを実行するユーザーには、その名前で指定されたエンティティのパスワードの入力だけが求められます。認証が成功するには、正確なパスワードを指定する必要があります。

SampleServerのエントリstoreKey=trueは、ログイン時に指定されたパスワードから秘密キーを計算すること、およびログインにより作成されたサブジェクトのprivateクレデンシャルに秘密キーを格納することを意味します。このキーは、SampleClientとSampleServerとの間でセキュリティ・コンテキストを確立する際、相互認証に利用されます。

Krb5LoginModuleにはprincipalオプションがあり、指定されたプリンシパル(エンティティ/ユーザー)だけが特定のプログラムにログインすることを指定するために使用できます。ここでは、SampleClientエントリにプリンシパルが指定されていない(必要に応じて指定可能)ため、ユーザーはユーザー名およびパスワードの入力を求められます。有効なユーザー名およびパスワードを保持するユーザーならだれでもSampleClientを実行できます。一方、SampleServerは特定のプリンシパルを示します。通常、システム管理者は、サーバーを特定のプリンシパルとしてのみ実行することを好むためです。この場合、SampleServerを実行するユーザーは、プリンシパルのパスワードの入力を求められ、認証が成功するには、正しいパスワードを指定する必要があります。

service_principal@your_realmを、SampleServerを表すサービス・プリンシパルの名前で置き換える必要があります。(「Kerberosユーザー名およびサービス・プリンシパル名」を参照)。

サーバーに秘密キーを含むキータブ・ファイルがある場合、次のJAASログイン・エントリを使用します。

SampleServer {
  com.sun.security.auth.module.Krb5LoginModule required
  principal="service_principal@your_realm"
  storeKey=true useKeyTab=true keyTab=keytab.file.name
  isInitiator=false;
  };

キータブ・ファイルですでにキーを指定しているため、パスワードは要求されません。キータブ・ファイルに複数のサービス・プリンシパルのキーが含まれ、サーバーがこれらすべてのサービス・プリンシパルとして機能するように設計されている場合は、プリンシパル・エントリを次のように設定できます。

  principal=*

Krb5LoginModuleに渡すことができるすべてのオプションの詳細は、Krb5LoginModule Javadoc APIドキュメントを参照してください。

SampleClientおよびSampleServerプログラムを実行するには、次の操作を行います。

• SampleServerの実行準備
• SampleClientの実行準備
• SampleServerの実行
• SampleClientの実行

クライアントがクレデンシャルをサーバーに委譲する場合、完成度のもっとも高い方法でクライアントを装うことができます。

コンテキスト・アクセプタ(前のチュートリアルのサーバー)とのコンテキストを確立する前に、コンテキスト・イニシエータ(クライアント)によりさまざまなコンテキスト・オプションの設定が行われたことを思い起こしてください。次に示すように、イニシエータがcontextオブジェクトに対し、引数trueを指定してrequestCredDelegメソッドを呼び出す場合を考えましょう。

context.requestCredDeleg(true);

この場合、コンテキスト確立時に、イニシエータのクレデンシャルをアクセプタに委譲することが求められます。

イニシエータからアクセプタにクレデンシャルを委譲することにより、アクセプタが自らをイニシエータのエージェントまたは代理人として認証することが可能になります。

コンテキスト確立後に、アクセプタはクレデンシャルの委譲が実際に行われたかどうかを最初に確認する必要があります。これは、getCredDelegStateメソッドを呼び出すことで実行されます。

boolean delegated = context.getCredDelegState();

クレデンシャルが委譲されている場合、アクセプタはgetDelegCrメソッドを呼び出して、そのクレデンシャルを取得できます。

GSSCredential clientCr = context.getDelegCred();

結果のGSSCredentialオブジェクトを使用して、以降のGSS-APIコンテキストをイニシエータの「委譲」として開始できます。たとえば、サーバーは、バックエンド・サーバーに対し、クライアントとして認証できます。バックエンド・サーバーには、中間的サーバーはどれかということよりも、元のクライアントがどれかということの方が重要です。

サーバーは、クライアントとして動作することにより、バックエンド・サーバーとの接続確立、結合セキュリティ・コンテキストの確立、およびメッセージ交換を、クライアントやサーバーと基本的に同じ方法で実行できます。

これを実行する1つの方法は、サーバーがGSSManagerのcreateContextメソッドを呼び出す際に、createContextにnullではなく委譲されたクレデンシャルを渡すことです。