|
|
フィードバック |
このチュートリアルでは、相互に通信するアプリケーション間で安全なメッセージ交換を実行するための Java GSS-API の使用方法を示す 2 つのサンプルアプリケーションを紹介します。ここでは、クライアントアプリケーションとサーバアプリケーションを例として使用しています。
Java GSS-API は、「セキュリティ機構」と呼ばれる機構を使用して、これらのサービスを提供します。Java 2 Standard Edition プラットフォームで利用可能な GSS-API 実装には、Kerberos V5 機構のサポートと、ベンダー固有の任意の選択肢が含まれます。このチュートリアルでは、Kerberos V5 機構を使用します。
クライアントとサーバ間の認証を実行し、安全な通信用の暗号化鍵を確立するために、GSS-API 機構は、接続の両側のローカルエンティティ用の特定の資格にアクセスする必要があります。このチュートリアルでは、クライアント側で使用する資格は Kerberos チケットで構成され、サーバ側の資格は長期 Kerberos 秘密鍵で構成されます。Kerberos チケットには、ホストアドレスをオプションで組み込むことができ、IPv4 と IPv6 の両方のホストアドレスがサポートされています。Java GSS-API は、機構が、これらの資格を、スレッドのアクセス制御コンテキストに関連付けられた被認証者から取得することを要求します。
通常、この種の資格を持つ被認証者を生成するため、クライアントアプリケーションおよびサーバアプリケーションは、Kerberos モジュールを使用して JAAS 認証を実行します。実行方法の詳細は、「JAAS 認証」チュートリアルを参照してください。認証された被認証者をスレッドのアクセス制御コンテキストに関連付ける方法については、「JAAS 承認」を参照してください。これらの操作を自動的に実行する ユーティリティも用意されています。Login ユーティリティの使用方法については、「JAAS Login ユーティリティの使用」チュートリアルを参照してください。
このチュートリアルでは、クライアントおよびサーバで JAAS 認証を実行しないため、Login ユーティリティは使用しません。その代わり、システムプロパティ javax.security.auth.useSubjectCredsOnly を false に設定する必要があります。この設定により、JAAS によって設定された既存の被認証者から必要な資格を取得する際、GSS 機構の要件が緩和されます。「useSubjectCredsOnly システムプロパティ」を参照してください。
注: これは入門用のチュートリアルであるため、内容は簡略化されています。たとえば、ポリシーファイルは含まれておらず、サンプルコードの実行にセキュリティマネージャを使用していません。実際には、Java GSS-API を使用するコードは、セキュリティマネージャを使用して実行する必要があります。このため、必要なアクセス権が明示的に付与されていないかぎり、セキュリティ関連の操作は許可されません。
別のチュートリアル、「JAAS Login ユーティリティおよび Java GSS-API を使用した安全なメッセージ交換」の内容は、このユーティリティと類似していますが、Login ユーティリティ、ポリシーファイル、およびより複雑なログイン構成ファイルを利用する点が異なります (ログイン構成ファイルは、JAAS 認証の実行時には常に必要なファイルで、使用する認証モジュールを指定する)。
この一連のチュートリアルでは、認証およびアプリケーションの安全な通信をサポートする基盤の技術として、Kerberos V5 を使用しています。詳細は、「Kerberos 要件」を参照してください。
チュートリアルのコードを最初に実行してみる場合、「SampleClient および SampleServer プログラムの実行」を先に読んでから、最初に戻り、学習を続けてください。
このチュートリアルで使用するアプリケーションの名前は、SampleClient および SampleServer です。
以下に、SampleClient および SampleServer アプリケーションの実行方法の概要を示します。
- SampleServer アプリケーション、SampleServer
- 引数に注目し、クライアントからの接続を待機するポート番号を確認します。
- 指定されたポート上でクライアント接続を待機する ServerSocket を作成します。
- 接続を待機します。
- SampleClient アプリケーションを実行します (通常別のマシンを使用)。SampleClient
- 引数に注目し、(1) SampleServer を表す Kerberos 主体の名前(「Kerberos ユーザ名およびサービス主体名」を参照)、(2) SampleServer を実行中のホスト (マシン) の名前、 (3) SampleServer がクライアント接続を待機するポート番号を確認します。
- 引数として渡されたホストおよびポートを使用して、SampleServer へのソケット接続を試みます。
- ソケット接続が SampleServer により受け入れられます。両方のアプリケーションが、ソケット入力および出力ストリームからの DataInputStream および DataOutputStream を初期化して、将来のデータ交換に使用します。
- SampleClient および SampleServer は、それぞれ GSSContext をインスタンス化し、以後の安全なデータ交換を可能にする共有コンテキストをプロトコルに従って確立します。
- これで、SampleClient および SampleServer は、メッセージを安全に交換できます。
- SampleClient および SampleServer は、メッセージ交換の完了後に、クリーンアップ操作を実行します。
実際のコードおよび詳細は、後述のセクションで示します。
SampleClient および SampleServer プログラムの全体のコードは、
mainメソッド内に配置されており、次の区分にさらに分割できます。注: これらのプログラムが使用する Java GSS-API クラス (GSSManager、GSSContext、GSSName、GSSCredential、MessageProp、および Oid) は、
org.ietf.jgssパッケージ内にあります。コマンド行引数の取得
クライアントとサーバの
mainメソッドが最初に行うことは、コマンド行引数の読み取りです。SampleClient が読み取る引数
SampleClient は、次の 3 つの引数を受け付けます。
- サービス主体名 -- SampleServer を表す Kerberos 主体の名前(「Kerberos ユーザ名およびサービス主体名」を参照)。
- ホスト名 -- SampleServer を実行するマシン
- ポート番号 -- SampleServer が接続を待機するポートのポート番号
以下に、コマンド行引数を読み取るコードを示します。
if (args.length < 3) { System.out.println("Usage:java <options> Login SampleClient " + " <servicePrincipal> <hostName> <port>"); System.exit(-1); } String server = args[0]; String hostName = args[1]; int port = Integer.parseInt(args[2]);SampleServer が読み取る引数
SampleServer が受け付ける引数は、次の 1 つだけです。
- ローカルポート番号 -- SampleServer がクライアントからの接続待機に使用するポート番号。この番号は、SampleClient プログラムの実行時に指定したポート番号と同じにする必要があります。
以下に、コマンド行引数を読み取るコードを示します。
if (args.length != 1) { System.out.println( "Usage:java <options> Login SampleServer <localPort>"); System.exit(-1); } int localPort = Integer.parseInt(args[0]);メッセージ交換用ソケット接続の確立
Java GSS-API は、トークン (不透明なバイトデータ) を作成および解釈するメソッドを提供します。トークンには 2 つのピア間で安全に交換されるメッセージが含まれていますが、実際にトークンを転送するメソッドはピアによって異なります。SampleClient および SampleServer アプリケーションの場合、クライアントとサーバ間のソケット接続を確立し、ソケット入力および出力ストリームを使ってデータの交換を行います。
ソケット接続用の SampleClient コード
SampleClient には、引数として SampleServer を実行中のホストマシン名、SampleServer が接続を待機するポート番号が渡されました。これで、SampleClient から SampleServer へのソケット接続確立に必要なすべてが整いました。次のコードを使用して、接続を設定し、将来のデータ交換に備えて DataInputStream および DataOutputStream を初期化します。
Socket socket = new Socket(hostName, port); DataInputStream inStream = new DataInputStream(socket.getInputStream()); DataOutputStream outStream = new DataOutputStream(socket.getOutputStream()); System.out.println("Connected to server " + socket.getInetAddress());ソケット接続用の SampleServer コード
SampleServer アプリケーションには、引数として、クライアントからの接続待機に使用するポート番号が渡されます。このアプリケーションは、指定されたポート上で待機する ServerSocket を作成します。
ServerSocket ss = new ServerSocket(localPort);次に、ServerSocket はクライアントから接続を待機および受け付け、クライアントとの将来のデータ交換に備えて DataInputStream および DataOutputStream を初期化します。
Socket socket = ss.accept(); DataInputStream inStream = new DataInputStream(socket.getInputStream()); DataOutputStream outStream = new DataOutputStream(socket.getOutputStream()); System.out.println("Got connection from client " + socket.getInetAddress());
acceptメソッドは、クライアント (ここでは SampleClient) が SampleServer のホストおよびポート上で接続を要求するまで待機します。SampleClient はこの接続を介して操作を実行します。Socket socket = new Socket(hostName, port);接続の要求および確立が実行されると、
acceptメソッドは新規ポートにバインドされた新規 Socket オブジェクトを返します。サーバは、この新規ソケット経由でクライアントと通信しつつ、元のポートにバインドされた ServerSocket に対する他のクライアントからの接続要求を待機できます。このため、一般に、サーバプログラムは複数の接続要求を処理可能なループを保持します。SampleServer の基本的なループ構造を、次に示します。
while( true ) { Socket socket = ss.accept(); <Establish input and output streams for the connection> <Establish a context with the client> <Exchange messages with the client>; <Clean up>; }クライアント接続は、元のポートでキューに入れられます。このため、SampleServer の使用するプログラム構造では、接続を行う最初のクライアントとのやり取りが完了してからでないと、次の接続を受け付けることができません。実際のところ、サーバは、クライアントごとに 1 つのスレッドを使用することで、複数のクライアントに同時に対応できます。次にその方法を示します。
while( true ) { <accept a connection>; <create a thread to handle the client>; }セキュリティコンテキストの確立
2 つのアプリケーションが Java GSS-API を利用して安全にメッセージを交換するためには、資格を使って、事前にジョイントセキュリティコンテキストを確立しておく必要があります。なお、SampleClient の場合、資格は、SampleClient が自動的に実行され、Login ユーティリティによってユーザが認証された時点で確立されます。SampleServer の場合も同様です。セキュリティコンテキストは、共有状態の情報 (暗号化鍵などを含む) をカプセル化します。暗号化が要求された場合、こうした鍵を使って、交換するメッセージを暗号化できます。
セキュリティコンテキスト確立の一部として、コンテキストイニシエータ (ここでは SampleClient) がアクセプタ (SampleServer) に認証され、それに対し、アクセプタがイニシエータに認証されることが必要になる場合があります。これを、「相互認証」が行われると言います。
両方のアプリケーションが、GSSContext オブジェクトを作成および使用して、セキュリティコンテキストを構成する共有情報の確立および保守を行います。
コンテキストオブジェクトをインスタンス化する方法は、コンテキストイニシエータとコンテキストアクセプタで異なります。イニシエータは、GSSContext をインスタンス化したあとで、目的のセキュリティコンテキストの特性を決定するさまざまなコンテキストオプション (相互認証を行うかどうかなど) を設定できます。目的の特性をすべて設定したら、イニシエータは
initSecContextメソッドを呼び出します。このメソッドは、アクセプタのacceptSecContextメソッドが必要とするトークンを生成します。Java GSS-API メソッドは、アプリケーション間で交換されるトークンを準備するために存在します。ただし、実際にアプリケーション間でトークンを転送するのは、アプリケーションの役割です。このため、イニシエータは、
initSecContextの呼び出しによりトークンを受け取ると、それをアクセプタに送信します。アクセプタは、acceptSecContextを呼び出してトークンを渡します。それに対し、acceptSecContextメソッドがトークンを返すことができます。その場合、アクセプタは、トークンをイニシエータに送信し、イニシエータはinitSecContextを再度呼び出してこのトークンを渡します。initSecContextまたはacceptSecContextがトークンを返すたびに、メソッドを呼び出したアプリケーションはトークンをピアに送信し、ピアはトークンを適切なメソッド (acceptSecContextまたはinitSecContext) に渡す必要があります。この処理は、コンテキストが完全に確立される (コンテキストのisEstablishedメソッドがtrueを返す) まで継続して行われます。サンプルアプリケーション用のコンテキスト確立コードについては、以下で説明します。
SampleClient によるコンテキスト確立
このクライアント/サーバのシナリオでは、SampleClient はコンテキストイニシエータです。以下に、セキュリティコンテキストを確立するための基本的な手順を示します。
- GSSContext をインスタンス化します。
- 使用するオプション機能をコンテキスト上に設定します。
- コンテキストが確立されるまでループを実行します。
initSecContextを呼び出すたびに、返されたトークンをすべて SampleServer に送信し、SampleServer からトークンを受け取ります (トークンが存在する場合)。SampleClient GSSContext のインスタンス化
GSSContext は、GSSManager のインスタンス化、およびいずれかの
createContextメソッドの呼び出しにより作成されます。GSSManager クラスは、他の重要な GSS API クラスのファクトリとして機能します。このクラスは、GSSContext、GSSCredential、および GSSName インタフェースを実装するクラスのインスタンスを作成します。SampleClient は、GSSManager の static メソッド
getInstanceを呼び出すことにより、デフォルトの GSSManager サブクラスのインスタンスを取得します。GSSManager manager = GSSManager.getInstance();デフォルト GSSManager サブクラスの
create*メソッド (createContextなど) が返すクラスの実装は、基盤となるテクノロジとして Kerberos をサポートします。イニシエータ側でコンテキストを作成する GSSManager ファクトリメソッドは、次のシグニチャーを保持します。
GSSContext createContext(GSSName peer, Oid mech, GSSCredential myCred, int lifetime);以下で、この引数について説明します。その後で、
createContextへの完全な呼び出しを示します。
GSSName peer引数クライアント/サーバというパラダイムにおけるピアは、サーバです。
peer引数には、サーバを表すサービス主体の GSSName を指定する必要があります。(「Kerberos ユーザ名およびサービス主体名」を参照)。サービス主体名を表す文字列は、SampleClient の最初の引数として渡されます。SampleClient は引数をserverという名前のローカルの String 変数に格納します。GSSName のインスタンス化には、GSSManagermanagerが (そのcreateNameメソッドのいずれかを呼び出すことにより) 使用されます。SampleClient は、次の署名を使用して、createNameメソッドを呼び出します。GSSName createName(String nameStr, Oid nameType);SampleClient は、
nameStr引数としてserverString を渡します。2 番目の引数は、Oid です。Oid は、汎用オブジェクト識別子 (Universal Object Identifier) を表します。Oid は、機構と名前の型を識別するために GSS-API フレームワーク内で用いられる、グローバルに解釈できる階層的な識別子です。Oid の構造およびエンコーディングは、ISOIEC-8824 および ISOIEC-8825 標準で定義されています。
createNameメソッドに渡される Oid は、厳密には機構 Oid ではなく、名前型 Oid です。GSS-API では、文字列名は、しばしば機構に依存しない形式から機構固有の形式にマッピングされます。通常、Oid では、機構がマッピング方法を認識できるよう、文字列の名前形式が指定されます。
nullの Oid は、名前が、機構の使用するネイティブの形式になっていることを示します。これが当てはまるのは、適切な Kerberos Version 5 名の形式であるserverString の場合です。このため、SampleClient は、Oid としてnullを渡します。以下に、その呼び出しを示します。GSSName serverName = manager.createName(server, null);
Oid mech引数GSSManager
createContextメソッドの 2 番目の引数は Oid です。これは、コンテキスト確立時のクライアントとサーバ間の認証、およびその後のクライアントとサーバ間の安全な通信に使用される機構を表します。このチュートリアルでは、セキュリティ機構として Kerberos V5 を使用しています。Kerberos V5 機構の Oid は、RFC 1964 で、「1.2.840.113554.1.2.2」と定義されているので、この Oid を作成します。
Oid krb5Oid = new Oid("1.2.840.113554.1.2.2");SampleClient は、
createContextの 2 番目の引数としてkrb5Oidを渡します。
GSSCredential myCred引数GSSManager
createContextメソッドの 3 番目の引数は、呼び出し側の資格を表す GSSCredential です。SampleClient の場合と同様、この引数にnullを渡す場合、デフォルトの資格が使用されます。
int lifetime引数GSSManager
createContextメソッドの最後の引数はintで、作成するコンテキストのライフタイムを秒で指定します。SampleClient は、GSSContext.DEFAULT_LIFETIMEを渡して、デフォルトのライフタイムを要求します。createContext の完全な呼び出し
ここまでで、必要な引数をすべて説明しました。ここでは、GSSContext を作成する SampleClient の呼び出しを示します。
GSSContext context = manager.createContext(serverName, krb5Oid, null, GSSContext.DEFAULT_LIFETIME);SampleClient のオプション設定
コンテキストのインスタンス化が完了したら、コンセプトアクセプタを使用してコンテキストを確立する前に、コンテキストイニシエータで、使用するセキュリティコンテキストの特性を決定するさまざまなオプションを設定できます。各オプションは、インスタンス化されたコンテキスト上で
requestメソッドを呼び出すことで設定できます。大半のrequestメソッドは、その機能を要求するかどうかを示すboolean引数をとります。要求は、常に受け入れられるわけではありません。このため、コンテキストの確立後に、いずれかのgetメソッドを呼び出して、要求が受け入れられたかどうかを確認できます。SampleClient は、次のオプションを要求します。
- 相互認証。コンテキストイニシエータは、常にアクセプタにより認証されます。イニシエータが相互認証を要求すると、アクセプタもイニシエータに認証されます。
- 機密性。機密性を要求するということは、
wrapという名前のコンテキストメソッドの暗号化を「有効にする」ことを意味します。暗号が実際に使用されるのは、wrapメソッドに渡される MessageProp オブジェクトにより機密性が要求される場合だけです。
- 保全性。これは、
wrapおよびgetMICメソッドの保存性を要求します。保全性が要求されると、これらのメソッドの呼び出し時に、メッセージ保全コード (MIC) として知られる暗号化タグが生成されます。getMICの呼び出しにより返されるトークン内に、生成された MIC が含まれます。wrapが呼び出されると、MIC がメッセージ (元のメッセージまたはメッセージ暗号化の結果、機密性が適用されたかどうかにより異なる) とともに 1 つのトークンの一部としてパッケージ化されます。次に、メッセージに対する MIC を検証して、メッセージが途中で変更されていないことを確認できます。GSSException
contextに対してこれらの要求を生成する SampleClient コードを、次に示します。context.requestMutualAuth(true); // Mutual authentication context.requestConf(true); // Will use encryption later context.requestInteg(true); // Will use integrity later注: デフォルトの GSSManager 実装および Kerberos 機構を使用する場合、これらの要求は常に許可されます。
SampleClient のコンテキスト確立ループ
SampleClient は、GSSContext のインスタンス化および使用するコンテキストオプションの指定後に、SampleServer とのセキュリティコンテキストを実際に確立できます。このために、SampleClient はループ構造を保持します。ループにより、次の操作が反復実行されます。
- コンテキストの
initSecContextメソッドの呼び出し。最初の呼び出しの場合、メソッドにはnullのトークンが渡されます。それ以外の場合、SampleServer から SampleClient に直前に送信されたトークン (SampleServer によるacceptSecContextの呼び出しで生成されるトークン) が渡されます。
initSecContextにより返されたトークン (存在する場合) の SampleServer への送信。initSecContextへの最初の呼び出しでは、常にトークンが生成されます。最後の呼び出しでは、トークンが返されない場合があります。
- コンテキストが確立されたかどうかの確認。確立されていない場合、SampleClient は SampleServer から別のトークンを受け取って、次のループ処理を開始します。
initSecContextから返される、または SampleServer から受け取るトークンは、バイト配列に格納されます。トークンは、SampleClient および SampleServer 間での送信時に不透明なデータとして処理され、Java GSS-API メソッドにより解釈されます。
initSecContext引数は、トークン、トークン開始位置の配列内の開始オフセット、およびトークンの長さを含むバイト配列です。最初の呼び出しでは、SampleClient は、SampleServer からトークンをまだ受け取っていないため、null のトークンを渡します。SampleServer とトークンを交換する際、SampleClient は、SampleServer へのソケット接続用入力および出力ストリームを使用して設定した、DataInputStream
inStreamおよび DataOutputStreamoutStreamを使用します。トークンを記述する場合、常に、トークンのバイト数を最初に記述してから、トークン自体を記述してください。その理由は、「SampleClient と SampleServer のメッセージ交換」セクションの導入部で説明します。以下に、SampleClient のコンテキスト確立ループ、およびクライアントおよびサーバの実体、相互認証を実際に行うかどうかなどの情報を表示するコードを示します。
byte[] token = new byte[0]; while (!context.isEstablished()) { // token is ignored on the first call token = context.initSecContext(token, 0, token.length); // Send a token to the server if one was generated by // initSecContext if (token != null) { System.out.println("Will send token of size " + token.length + " from initSecContext."); outStream.writeInt(token.length); outStream.write(token); outStream.flush(); } // If the client is done with context establishment // then there will be no more tokens to read in this loop if (!context.isEstablished()) { token = new byte[inStream.readInt()]; System.out.println("Will read input token of size " + token.length + " for processing by initSecContext"); inStream.readFully(token); } } System.out.println("Context Established! "); System.out.println("Client is " + context.getSrcName()); System.out.println("Server is " + context.getTargName()); if (context.getMutualAuthState()) System.out.println("Mutual authentication took place!");SampleServer によるコンテキスト確立
このクライアント/サーバのシナリオでは、SampleServer はコンテキストアクセプタです。以下に、セキュリティコンテキストを確立するための基本的な手順を示します。
- GSSContext をインスタンス化します。
- コンテキストが確立されるまで ループを実行します。各ループでは、SampleClient からトークンを受け取り、
acceptSecContextを呼び出してトークンを渡し、返されたトークンをすべて SampleClient に送信します。SampleServer GSSContext のインスタンス化
「SampleClient GSSContext のインスタンス化」で説明したように、GSSContext は、 GSSManager をインスタンス化して、
createContextメソッドのいずれかを呼び出すことで作成されます。SampleClient と同様、SampleServer は、GSSManager の static メソッド
getInstanceを呼び出すことにより、デフォルトの GSSManager サブクラスのインスタンスを取得します。GSSManager manager = GSSManager.getInstance();アクセプタ側でコンテキストを作成する GSSManager ファクトリメソッドは、次のシグニチャーを保持します。
GSSContext createContext(GSSCredential myCred);SampleServer の場合と同様、GSSCredential 引数に
nullを渡す場合、デフォルトの資格が使用されます。コンテキストは、次の方法でインスタンス化されます。GSSContext context = manager.createContext((GSSCredential)null);SampleServer のコンテキスト確立ループ
SampleServer は、GSSContext をインスタンス化したあとで、SampleClient とのセキュリティコンテキストを確立できます。これを実行するため、SampleServer はコンテキストが確立されるまで反復するループ構造を保持します。ループにより、次の操作が反復実行されます。
- SampleClient からのトークンの受け取り。このトークンは、SampleClient
initSecContext呼び出しの結果です。
- コンテキストの
acceptSecContextメソッドの呼び出し、および直前に受け取ったトークンのメソッドへの引き渡し。
acceptSecContextがトークンを返す場合、SampleServer はこのトークンを SampleClient に送信し、コンテキストがまだ確立されていない場合、次のループ処理を開始します。
acceptSecContextから返される、または SampleClient から受け取るトークンは、バイト配列に格納されます。
acceptSecContext引数は、トークン、トークン開始位置の配列内の開始オフセット、およびトークンの長さを含むバイト配列です。SampleClient とトークンを交換する際、SampleServer は、SampleClient へのソケット接続用入力および出力ストリームを使用して設定した、DataInputStream
inStreamおよび DataOutputStreamoutStreamを使用します。以下に、SampleServer のコンテキスト確立ループを示します。
byte[] token = null; while (!context.isEstablished()) { token = new byte[inStream.readInt()]; System.out.println("Will read input token of size " + token.length + " for processing by acceptSecContext"); inStream.readFully(token); token = context.acceptSecContext(token, 0, token.length); // Send a token to the peer if one was generated by // acceptSecContext if (token != null) { System.out.println("Will send token of size " + token.length + " from acceptSecContext."); outStream.writeInt(token.length); outStream.write(token); outStream.flush(); } } System.out.print("Context Established! "); System.out.println("Client is " + context.getSrcName()); System.out.println("Server is " + context.getTargName()); if (context.getMutualAuthState()) System.out.println("Mutual authentication took place!");メッセージの安全な交換
SampleClient と SampleServer 間のセキュリティコンテキストが確立されると、メッセージを安全に交換できます。
メッセージ交換用の GSSContext メソッド
メッセージの安全な交換を可能にするメソッドには、
wrapとgetMICの 2 種類があります。実際には、2 つのwrapメソッド (および 2 つのgetMICメソッド) が存在します。2 つのメソッドの相違点は、入力メッセージの位置 (バイト配列または入力ストリーム) および出力先 (バイト配列の戻り値または出力ストリーム) です。メッセージ交換用のこれらのメソッド、および対応するメソッド (生成されるトークンのピアが解釈を行うための) について、以下で説明します。
wrap
wrapメソッドは、メッセージ交換用の主要メソッドです。SampleClient により呼び出される
wrapメソッドのシグニチャーは、次のようになります。byte[] wrap (byte[] inBuf, int offset, interface len, MessageProp msgProp)
wrapに、メッセージ (inBuf内)、メッセージの開始位置inBufに対するオフセット (offset)、およびメッセージの長さ (len) を渡します。使用する QOP (Quality-of-Protection)、および機密性 (暗号化) が必要かどうかを指定する際に使用する MessageProp も渡します。QOP 値により、使用する暗号化保全および暗号化 (必要な場合) アルゴリズムが決定されます。基盤となる機構のプロバイダにより、さまざまな QOP 値に対応するアルゴリズムが指定されます。たとえば、Kerberos V5 に対応する値は、 RFC 1964 のセクション 4.2 で定義されています。デフォルトの QOP を要求する場合は、通常 QOP 値に 0 を指定します。
wrapメソッドは、メッセージを含むトークンおよびその暗号化メッセージ保全コード (MIC) を返します。MessageProp により機密性が指定されている場合、トークンに格納されたメッセージは暗号化されます。返されるトークンは、不透明なデータとして扱われるため、その形式について知る必要はありません。返されるトークンをピアアプリケーションに送信すると、unwrapメソッドが呼び出されてトークンの「ラップが解除」され、元のメッセージの取得および保全性の検証が行われます。getMIC
指定されたメッセージの暗号化メッセージ保全コード (MIC) を含むトークンの取得だけを行う場合、
getMICを呼び出します。たとえば、ピアが同じデータを保持していることを確認する場合、データ自体を相互に転送しなくても、データの MIC を転送するだけで目的を達成できます。SampleServer により呼び出される
getMICメソッドのシグニチャーは、次のようになります。byte[] getMIC (byte[] inMsg, int offset, int len, MessageProp msgProp)
getMICに、メッセージ (inMsg内)、メッセージの開始位置inMsgに対するオフセット (offset)、およびメッセージの長さ (len) を渡します。使用する QOP (Quality-of-Protection) の指定に使う MessageProp も渡します。デフォルトの QOP を要求する場合は、通常 QOP 値に 0 を指定します。
getMICにより作成されたトークンおよび MIC の計算に使用するメッセージ (または MIC を計算する予定のメッセージ) を保持する場合、verifyMICメソッドを呼び出して、メッセージの MIC を検証できます。検証が成功する (GSSException がスローされない) 場合、メッセージが、MIC 計算時のメッセージと正確に一致することが保証されます。通常、アプリケーションからメッセージを受け取るピアは、MIC も受け取ることを期待します。このため、MIC を検証して、途中でメッセージが変更または破損していないかどうかを確認できます。注: メッセージに加え、MIC も必要であることが前もってわかっている場合は、wrapおよびunwrapメソッドを使用するほうが便利です。ただし、メッセージと MIC を別個に受け取る状況も考えられます。前述の
getMICに対応するverifyMICのシグニチャーを、次に示します。void verifyMIC (byte[] inToken, int tokOffset, int tokLen, byte[] inMsg, int msgOffset, int msgLen, MessageProp msgProp);これにより、
inMsg(長さがmsgLenで、オフセットmsgOffsetから始まる) 内のメッセージに対応する、inToken(長さがtokLenで、オフセットtokOffsetから始まる) 内の MIC の検証が実行されます。基盤となる機構は、MessageProp を使用して呼び出し側に情報 (メッセージに適用された保護の強さを示す QOP など) を返します。SampleClient と SampleServer のメッセージ交換
SampleClient と SampleServer との間のメッセージ交換の概要を次に示します。その後、コードの詳細を示します。
これらのステップは、GSS-API クライアントおよびサーバの検証に使用される「標準的な」ステップです。GSS-API ライブラリの異なる実装間の相互運用性をチェックする、広く普及したテストプログラムとなった GSS-API クライアントおよび GSS-API サーバは、MIT のグループが記述しました。これらの GSS-API サンプルアプリケーションは、MIT からダウンロード可能な Kerberos ディストリビューションの一部です ( http://web.mit.edu/kerberos)。MIT から入手可能なこのクライアントおよびサーバが準拠するプロトコルでは、コンテキストの確立後にクライアントが送信したメッセージに、MIC が追加されて返されます。GSS-API ライブラリを実装する場合、そのライブラリ実装を使用するクライアントまたはサーバを、別の GSS-API ライブラリ実装を使用する対応するピアサーバまたはクライアントに対して実行して、テストを行うのが一般的な方法です。両方のライブラリ実装が標準に準拠する場合、2 つのピアの通信は成功します。
使用するクライアントまたはサーバを、C 言語で記述されたサーバ (MIT 提供のサーバなど) に対してテストする場合、トークンの交換方法を考慮する必要があります。C 言語による GSS-API の実装には、ストリームベースのメソッドが含まれません。ピアにストリームベースのメソッドが存在しない状況でトークンを記述する場合、最初にバイト数を記述してから、トークンを記述する必要があります。同様に、トークンを読み取る際、バイト数を読み取ってからトークンを読み取る必要があります。SampleClient および SampleServer は、実際にこの処理を行います。
SampleClient および SampleServer が行うメッセージ交換の概要を、次に示します。
- SampleClient が
wrapを呼び出して、メッセージの MIC を暗号化および計算します。
- SampleClient が、
wrapから返されたトークンを SampleServer に送信します。
- SampleServer が、
unwrapを呼び出して元のメッセージを取得し、保全性を検証します。
- SampleServer が
getMICを呼び出して、複号化したメッセージに対する MIC を計算します。
- SampleServer が、
getMICにより返されたトークン (MIC を含む) を SampleClient に送信します。
- SampleClient が
verifyMICを呼び出して、SampleServer により送信された MIC が元のメッセージの有効な MIC かどうかを検証します。メッセージの暗号化および送信を行う SampleClient コード
メッセージの暗号化、MIC の計算、および結果の SampleServer への送信を実行する SampleClient コードを、次に示します。
byte[] messageBytes = "Hello There!\0".getBytes(); /* * The first MessageProp argument is 0 to request * the default Quality-of-Protection. * The second argument is true to request * privacy (encryption of the message). */ MessageProp prop = new MessageProp(0, true); /* * Encrypt the data and send it across.Integrity protection * is always applied, irrespective of encryption. */ token = context.wrap(messageBytes, 0, messageBytes.length, prop); System.out.println("Will send wrap token of size " + token.length); outStream.writeInt(token.length); outStream.write(token); outStream.flush();トークンのラップ解除、MIC の計算および送信を行う SampleServer コード
次の SampleServer コードは、SampleClient により送信されたラップ済みのトークンを読み取り、「ラップを解除」して元のメッセージを取得し、保全性を検証します。この場合、メッセージが暗号化されているため、ラップの解除には複号化も含まれます。
注: ここでは、保全性チェックは成功するものと考えることができます。ただし、一般に、保全性チェックの失敗は、メッセージが途中で変更されたことが原因です。
unwrapメソッドは、保全性チェックの失敗に遭遇すると、GSSException を主要なエラーコード GSSException.BAD_MIC とともにスローします。/* * Create a MessageProp which unwrap will use to return * information such as the Quality-of-Protection that was * applied to the wrapped token, whether or not it was * encrypted, etc. Since the initial MessageProp values * are ignored, it doesn't matter what they are set to. */ MessageProp prop = new MessageProp(0, false); /* * Read the token.This uses the same token byte array * as that used during context establishment. */ token = new byte[inStream.readInt()]; System.out.println("Will read token of size " + token.length); inStream.readFully(token); byte[] bytes = context.unwrap(token, 0, token.length, prop); String str = new String(bytes); System.out.println("Received data \"" + str + "\" of length " + str.length()); System.out.println("Encryption applied: " + prop.getPrivacy());次に SampleServer は、複号化されたメッセージの MIC を生成して、SampleClient に送信します。これは、必須というわけではなく、複号化されたメッセージの MIC の生成方法を示すためのものです。複号化されたメッセージは、SampleClient がラップして SampleServer に送信した元のメッセージと正確に同じになるはずです。SampleServer がこれを生成して SampleClient に送信し、その後 SampleClient による検証が行われると、SampleServer が保持する複号化済みのメッセージは、SampleClient から送信された元のメッセージと正確に一致することが保証されます。
/* * First reset the QOP of the MessageProp to 0 * to ensure the default Quality-of-Protection * is applied. */ prop.setQOP(0); token = context.getMIC(bytes, 0, bytes.length, prop); System.out.println("Will send MIC token of size " + token.length); outStream.writeInt(token.length); outStream.write(token); outStream.flush();MIC を検証する SampleClient コード
次の SampleClient コードは、SampleServer により計算された (複号化済みメッセージに対する) MIC を読み取って検証します。これにより、SampleServer が保持する複号化されたメッセージが、元のメッセージと同じであることが保証されます。
token = new byte[inStream.readInt()]; System.out.println("Will read token of size " + token.length); inStream.readFully(token); /* * Recall messageBytes is the byte array containing * the original message and prop is the MessageProp * already instantiated by SampleClient. */ context.verifyMIC(token, 0, token.length, messageBytes, 0, messageBytes.length, prop); System.out.println("Verified received MIC for message.");クリーンアップ
SampleClient および SampleServer は、メッセージ交換の完了後に、クリーンアップ操作を実行する必要があります。どちらにも、以下の操作を実行するコードが含まれます。
- ソケット接続のクローズ
- コンテキストオブジェクトに格納されたシステムリソースおよび暗号化情報の解放、およびコンテキストの無効化
socket.close(); context.dispose();
このチュートリアルでは、基盤となる認証および安全な通信技術として Kerberos V5 が使用されているため、ユーザまたはサービスが要求される場合、常に Kerberos スタイルの主体名が使用されます。
たとえば、SampleClient を実行する場合、「ユーザ名」の指定が求められます。Kerberos スタイルのユーザ名は、Kerberos 認証用だけに割り当てられたユーザ名です。このユーザ名は、ベースユーザ名 (例、mjones)、「@」、および領域の順序で構成されます (例、mjones@KRBNT-OPERATIONS.ABC.COM)。
通常、SampleServer などのサーバプログラムは、「サービス」を提供し、特定の「サービス主体」に代わって実行されるプログラムと見なされます。SampleServer のサービス主体名が必要とされるのは、次の場合です。
- SampleServer を実行し、SampleClient が SampleServer への接続を試みると、基盤となる Kerberos 機構により Kerberos KDC への認証が試みられます。ログインするように促されるので、適切なサービス主体としてログインしてください。
- SampleClient の実行時に、引数の 1 つにサービス主体名を指定します。これは必須です。このため、SampleClient は適切なサービスを使用してセキュリティコンテキストの確立を開始できます。
- SampleClient および SampleServer プログラム (このチュートリアル用でない) をセキュリティマネージャとともに実行した場合、クライアントおよびサーバポリシーファイルはそれぞれ、サービス主体名と等価な名前、および「initiate」や「accept」(セキュリティコンテキスト確立の開始または受け入れ) と等価な操作を保持する ServicePermission を必要とします。
このドキュメントおよび関連するログイン構成ファイルを通じて、
という形式で記述された部分は、自分の環境で使用する実際の名前で置き換えてください。サービス主体名として、「任意の」Kerberos 主体を実際に使用できます。このため、このチュートリアルを実行してみる場合、クライアントユーザ名とサービス主体名の両方に自分のユーザ名を使用できます。service_principal@your_realm通常、本番稼動環境では、システム管理者は、サーバを特定の主体のみで実行し、特定の名前を割り当てて使用します。たいてい、割り当てる Kerberos 形式のサービス主体名は、次のようになります。
service_name/machine_name@realm;たとえば、「KRBNT-OPERATIONS.ABC.COM」という領域内の「raven」という名前のマシンで nfs サービスを実行する場合、サービス主体名は次のようになります。
nfs/raven@KRBNT-OPERATIONS.ABC.COMただし、このようなマルチコンポーネント名は必須ではありません。ユーザ主体名のような、シングルコンポーネント名も使用できます。たとえば、インストールによって、領域内のすべての ftp サーバで同じ ftp サービス主体
ftp@realmを使用する場合と、ftp サーバごとに異なる ftp 主体を使用する (たとえば、マシンhost1、host2の ftp 主体がそれぞれftp/host1@realm、ftp/host2@realmとなる) 場合があります。主体名に領域を指定する必要がある場合
ユーザまたはサービス主体名の領域がデフォルト領域の場合は (「Kerberos 要件」を参照)、Kerberos にログインする際、ユーザ名を求めるプロンプトが表示された時点で、必ずしも領域を指定する必要はありません。このため、たとえばユーザ名が「mjones@KRBNT-OPERATIONS.ABC.COM」で、SampleClient を実行する場合、ユーザ名が要求されたら、領域を省略して「mjones」とだけ入力できます。名前は Kerberos 主体名のコンテキストで解釈され、必要に応じてデフォルトの領域が付けられます。
GSSManager の
createNameメソッドにより、主体名が GSSName に変換される場合にも、領域の指定を省略できます。たとえば、SampleClient の実行時に、引数の 1 つにサービス主体名を指定します。この場合、SampleClient が名前をcreateNameメソッドに渡し、このメソッドが必要に応じてデフォルト領域を追加するため、名前を指定する際に領域を省略できます。主体名をログイン構成ファイルおよびポリシーファイルで使用する場合は、常に領域を含めて名前を指定することをお勧めします。理由は、これらのファイルのパーサの動作が実装に依存しないため、主体名の使用前にデフォルト領域が追加される場合と、追加されない場合があるためです。名前に領域が指定されていない場合、以降の操作は失敗します。
このチュートリアルでは、JAAS メソッドを直接的 (「JAAS 認証」および「JAAS 承認」チュートリアルの場合のように) または間接的 (たとえば、「JAAS Login ユーティリティの使用」チュートリアルや「JAAS Login ユーティリティおよび Java GSS-API を使用した安全なメッセージ交換」チュートリアルで解説されている Login ユーティリティを介して) に呼び出すのではなく、基盤となる Kerberos 機構が SampleClient および SampleServer を実行するユーザの資格を取得するようにしました。
Sun Microsystems の提供する Kerberos 機構のデフォルト実装では、Kerberos 名およびパスワードの入力が促されます。その後、Kerberos KDC に対して指定されたユーザまたはサービスの認証が行われます。この認証処理には、JAAS が使用されています。
JAAS はプラグイン可能な認証フレームワークをサポートします。これは、呼び出し側アプリケーションに任意の型の認証モジュールをプラグインできるということです。特定のアプリケーションで使用されるログインモジュールは、ログイン構成によって指定されます。Sun Microsystems 提供のデフォルトの JAAS 実装では、単一のファイル内にログイン構成情報を指定する必要があります(注: ベンダーによってはファイルベースの実装が提供されない場合もある)。ログイン構成ファイルとその内容、およびログイン構成ファイルの指定方法については、「JAAS ログイン構成ファイル」を参照してください。
このチュートリアルでは、構成ファイル内に Kerberos ログインモジュール
com.sun.security.auth.module.Krb5LoginModuleが指定されます。このログインモジュールは、Kerberos 名とパスワードの入力を求めるプロンプトを表示し、Kerberos KDC に対する認証処理を実行しようとします。ログイン構成ファイルに、クライアント側が使用するエントリとサーバ側が使用するエントリの 2 つが含まれる場合、SampleClient と SampleServer の両方で同じログイン構成ファイルを使用できます。
このチュートリアルで使用するログイン構成ファイル bcsLogin.conf を、次に示します。
com.sun.security.jgss.initiate { com.sun.security.auth.module.Krb5LoginModule required; }; com.sun.security.jgss.accept { com.sun.security.auth.module.Krb5LoginModule required storeKey=true };Sun の GSS-API 機構の実装では、新しい資格が必要な場合、
com.sun.security.jgss.initiateという名前のエントリとcom.sun.security.jgss.acceptという名前のエントリが使用されます。このチュートリアルでは Kerberos V5 機構を使用するため、これらの資格の取得に Kerberos ログインモジュールの呼び出しが必要です。このため、エントリ内に Krb5LoginModule を必須モジュールとして記載してあります。com.sun.security.jgss.initiateエントリはクライアント側の構成を指定し、com.sun.security.jgss.acceptエントリはサーバ側の構成を指定します。Krb5LoginModule が成功するのは、指定されたエンティティでの Kerberos KDC へのログインが成功した場合だけです。SampleClient または SampleServer の実行時、ユーザは名前とパスワードの入力を求められます。
SampleServer のエントリ
storeKey=trueは、ログイン時に指定されたパスワードから秘密鍵を計算すること、およびログインにより作成された被認証者の private 資格に秘密鍵を格納することを意味します。この鍵は、SampleClient と SampleServer との間でセキュリティコンテキストを確立する際、相互認証に利用されます。Krb5LoginModule に引き渡し可能なすべてのオプションの詳細は、Krb5LoginModule ドキュメントを参照してください。
このチュートリアルでは、システムプロパティ
javax.security.auth.useSubjectCredsOnlyをfalseに設定します。この設定により、JAAS によって設定された既存の被認証者から必要な資格を取得する際、GSS 機構の要件が緩和されます。この制限緩和により、機構が、ベンダー固有の位置から資格を取得できるようになります。たとえば、オペレーティングシステムのキャッシュ (存在する場合) の使用を選択するベンダーや、ディスク上の保護されたファイルから読み取りを選択するベンダーがあります。この制限が緩和された場合でも、Sun Microsystem の Kerberos スレッドのアクセス制御コンテキストに関連付けられた被認証者内の資格を検索します。ただし、資格が見つからなかった場合、Kerberos モジュールを使用して JAAS 認証を実行し、新規資格を取得します。Kerberos モジュールは、Kerberos 主体名とパスワードを求めるプロンプトを表示します。他のベンダーが提供する Kerberos 機構の実装では、このプロパティを
falseに設定した場合の動作が異なる場合があることに注意してください。各実装の動作については、提供されるドキュメントを参照してください。
SampleClient および SampleServer プログラムを実行するには、次の操作を行います。
SampleServer の実行準備
SampleServer の実行準備では、以下の操作を行います。
- 次のファイルを、SampleServer を実行するマシンからアクセス可能なディレクトリにコピーします。
- SampleServer.java ソースファイル
- bcsLogin.conf ログイン構成ファイル
SampleServer.javaをコンパイルします。javac SampleServer.javaSampleClient の実行準備
SampleClient の実行準備では、以下の操作を行います。
- 次のファイルを、SampleClient を実行するマシンからアクセス可能なディレクトリにコピーします。
- SampleClient.java ソースファイル
- bcsLogin.conf ログイン構成ファイル
SampleClient.javaをコンパイルします。javac SampleClient.javaSampleServer の実行
SampleClient を実行する前に、必ず SampleServer を実行してください。SampleClient は SampleServer へのソケット接続を試みるため、SampleServer が稼動していないとソケット接続が受け付けられず、失敗します。
SampleServer を実行する場合、SampleServer を稼動する予定のマシンで実行してください。このマシン名 (ホスト名) は、SampleClient の引数として指定します。サービス主体名は、ログイン構成ファイルやポリシーファイルなど、いくつかの場所に表示されます。
SampleServer の実行用に準備したディレクトリに移動します。以下を指定して、SampleServer を実行します。
-Djava.security.krb5.realm=<your_realm>(使用する Kerberos 領域)。たとえば、領域が「KRBNT-OPERATIONS.ABC.COM」の場合、-Djava.security.krb5.realm=KRBNT-OPERATIONS.ABC.COMのように指定します。
-Djava.security.krb5.kdc=<your_kdc>(使用する Kerberos KDC)。たとえば、KDC が「samplekdc.abc.com」の場合、-Djava.security.krb5.kdc=samplekdc.abc.comのように指定します。
-Djavax.security.auth.useSubjectCredsOnly=false(基盤となる機構による資格の取得方法の指定)。「useSubjectCredsOnly システムプロパティ」を参照してください。
-Djava.security.auth.login.config=bcsLogin.conf(ログイン構成ファイルbcsLogin.confを使用)SampleServer に必要な引数は、クライアント接続の待機に使用するポート番号だけです。通常は使用しない大きなポート番号であれば、どの番号でも選択できます(例、4444)。
以下に、Microsoft Windows および Unix システムの両方で使用可能なすべてのコマンドを示します。
重要: このコマンドの、
<port_number>を適切なポート番号に、<your_realm>を使用する Kerberos 領域に、<your_kdc>を使用する Kerberos KDC にそれぞれ置き換えてください。以下に、コマンドを示します。
java -Djava.security.krb5.realm=<your_realm> -Djava.security.krb5.kdc=<your_kdc> -Djavax.security.auth.useSubjectCredsOnly=false -Djava.security.auth.login.config=bcsLogin.conf SampleServer <port_number>コマンド全体は、1 行で入力してください。ただし、UNIX システムの場合、行の最後に行継続を示す文字「\」を付けることで (最後の行を除く)、複数行に分けて入力できます。ここでは、可読性のみを考慮して、複数行に分けて表示しています。このコマンドは非常に長いため、.bat ファイル (Windows) または .sh ファイル (UNIX) に記述して、そのファイルを実行することが必要な場合があります。
SampleServerコードは、指定されたポート上でソケット接続を待機します。入力を求められたら、サービス主体の Kerberos 名およびパスワードを入力してください。ログイン構成ファイルで指定された基盤となる Kerberos 認証機構により、サービス主体の Kerberos へのログインが行われます。ログイン時のトラブルシューティングについては、「トラブルシューティング」を参照してください。
SampleClient の実行
SampleClient を実行するため、最初に SampleClient の実行準備を行なったディレクトリに移動します。以下を指定して、SampleClient を実行します。
-Djava.security.krb5.realm=<your_realm>(使用する Kerberos 領域)
-Djava.security.krb5.kdc=<your_kdc>(使用する Kerberos KDC)
-Djavax.security.auth.useSubjectCredsOnly=false(基盤となる機構による資格の取得方法の指定)
-Djava.security.auth.login.config=bcsLogin.conf(ログイン構成ファイルbcsLogin.confを使用)SampleClient の引数は、 (1) SampleServer を表すサービス主体の Kerberos 名、(2) SampleServer を実行するホスト (マシン) の名前、(3) SampleServer がクライアント接続を待機するポート番号です。
以下に、Windows と Unix の両方のシステムで使用可能な全コマンドを示します。
重要: このコマンドの、
<service_principal>、<host>、<port_number>、<your_realm>、および<your_kdc>を、適切な値に置き換えてください (ポート番号は、SampleServer の引数として渡したポート番号と同じにする必要がある)。値を引用符で囲む必要はありません。以下に、コマンドを示します。
java -Djava.security.krb5.realm=<your_realm> -Djava.security.krb5.kdc=<your_kdc> -Djavax.security.auth.useSubjectCredsOnly=false -Djava.security.auth.login.config=bcsLogin.conf SampleClient <service_principal> <host> <port_number>コマンド全体を 1 行で入力してください。ここでは、読みやすくするために複数行に分けて表示してあります。SampleServer を実行するコマンドと同様、コマンドウィンドウに直接入力するにはコマンドが長すぎる場合、.bat ファイル (Windows) または .sh ファイル (UNIX) に記述して、そのファイルを実行してください。
入力が求められたら、Kerberos ユーザ名およびパスワードを入力します。ログイン構成ファイルで指定された基盤となる Kerberos 認証機構により、Kerberos へのログインが行われます。SampleClient コードは、SampleServer へのソケット接続を要求します。SampleServer が接続を受け付けると、SampleClient および SampleServer により、このチュートリアルで解説した方法で、共有コンテキストの確立およびメッセージの交換が行われます。
ログイン時のトラブルシューティングについては、「トラブルシューティング」を参照してください。
|
|
フィードバック |