前のチュートリアル チュートリアルの紹介および目次

Java GSS-API および JAAS で実行可能なほかの操作



前のチュートリアル、「JAAS Login ユーティリティーおよび Java GSS-API を使用したセキュアなメッセージ交換」では、2 つのアプリケーション (特にクライアントとサーバー) が Java GSS-API を使用して相互間のセキュリティー保護されたコンテキストを確立して、メッセージを安全に交換する方法を示しました。

コンテキストイニシエータ (このクライアント/サーバーの例ではクライアント) を使用してコンテキストを確立したあとで、コンテキストアクセプタ (サーバー) が実行可能な操作はほかにもあります。基本的に、サーバーはクライアントを「装う」ことができます。偽装のレベルは、クライアントがクレデンシャルをサーバーに委譲しているかどうかにより異なります。


クライアントユーザーでのコードの実行

サーバーがクライアントを装う 1 つの方法は、クライアントコードを実行するのと同じエンティティー (ユーザー) でコードを実行することです。通常、スレッドにより実行されるメソッドは、そのスレッド自体のアクセス制御設定を使用します。ただし、このチュートリアルでは、サーバーがクライアントを装う際、クライアントのアクセス制御設定を使用するため、サーバーはクライアント自体が実行時に保持する、厳密に同じリソースにアクセスできます。

このチュートリアルで使用する方法の主要な利点は、JAAS 承認コンポーネントをアクセス制御に使用できることです。JAAS 承認コンポーネントがない場合、サーバープリンシパルは、クライアントユーザーで実行されるコードがアクセスするすべてのリソースにアクセスできなければなりません。また、サーバーコードに、ユーザーがそのリソースにアクセスすることが承認されているかどうかを判別するためのアクセス制御ロジックを含める必要があります。JAAS 承認を利用することにより、プリンシパルベースのアクセス制御が提供されるため、アクセス制御が自動的に処理されます。これらのコード内のセキュリティー関連操作のアクセス権は、ユーザーにのみ付与する必要があり、サーバーコードに付与する必要はありません。JAAS 承認の詳細は、「JAAS 承認」チュートリアルを参照してください。

基本的なアプローチ

サーバーは、どのようにしてクライアントを「装い」、クライアントコードを実行するユーザーでコードを実行できるのでしょうか。基本的に、そのユーザーでクライアントコードを実行する場合と同じ方法が使用されます。すべてのサーバーコードは、ユーザーのプリンシパル名を認識する必要があります。ユーザーのプリンシパル名は、クライアントで確立されたコンテキストから取得できます。

クライアントコードを実行するユーザーの JAAS 認証により、ユーザー (プリンシパル) 名を保持するプリンシパルを含むサブジェクトが作成されることはすでに学びました。そのあと、プリンシパルは (Login ユーティリティーからの Subject.doAsPrivileged 呼び出しを介して) 新しいアクセス制御コンテキストに関連付けられ、クライアントコードがそのユーザーで実行されるものと見なされます。以降のアクセス制御は、必要なアクセス権がクライアントコードを実行する特定のユーザーに付与されるかどうかに基づいて決定されます。

サーバーコードも同様に処理されます。ただし、一般に、認証の指定されたプリンシパルはユーザープリンシパルではなく「サービスプリンシパル」である点が異なります。再度、指定されたプリンシパル名のプリンシパルを含むサブジェクトが作成され、Subject.doAsPrivileged が呼び出されます。サーバーコードは指定されたプリンシパルで実行されると見なされます。以降のアクセス制御は、必要なアクセス権がサーバーコードを実行する特定のプリンシパルに付与されるかどうかに基づいて決定されます。

いったんクライアントおよびサーバーが相互コンテキストを確立すると、次のコードでコンテキストイニシエータの名前 (クライアントのプリンシパル名) を確認できます。

GSSName clientGSSName = context.getSrcName();

コンテキストアクセプタ (サーバー) は、この名前を使用して、同じエンティティーを表すプリンシパルを含むサブジェクトを生成できます。たとえば、Sun Microsystems の提供する JRE を使用している場合、次の方法でサブジェクトを生成できます。

Subject client = 
  com.sun.security.jgss.GSSUtil.createSubject(clientGSSName, null);

createSubject メソッドは、引数として指定された GSSName および GSSCredential から新たなサブジェクトを作成します。サーバーコードがローカル JVM 内のユーザーでコードを実行する場合、ユーザーのクレデンシャルは必要ではありません。実際のところ、クライアントがサーバーにクレデンシャルを委譲しているのでないかぎり、ユーザーのクレデンシャルは取得できません。詳細は、「クライアントから委譲されたクレデンシャルの使用」を参照してください。ここではクレデンシャルは必要ではないため、GSSCredential 引数に null を渡します。

注:Sun Microsystems の提供する JRE を使用しているのではない場合、これを実行する別の方法は、次のようにして KerberosPrincipal インスタンスを生成することです。 
KerberosPrincipal principal = 
  new KerberosPrincipal(clientGSSName.toString());

次に、このプリンシパルを使用して新たなサブジェクトを生成するか、既存のサブジェクトのプリンシパルセット内でこのプリンシパルを生成します。

サーバーがユーザーとして実行するコードは、java.security.PrivilegedAction (または java.security.PrivilegedExceptionAction) を実装するクラスの run メソッドで開始する必要があります。つまり、コードをこの run メソッド内に配置することも、run メソッドから呼び出すこともできます。

サーバーコードは、PrivilegedAction (または PrivilegedExceptionAction) のインスタンスとともにサブジェクトを Subject.doAsPrivileged に渡し、以降のコードを PrivilegedAction の run メソッドから、指定されたサブジェクトのプリンシパル (ユーザー) で開始できます。

たとえば、PrivilegedAction クラスが ReadFileAction を呼び出し、引数としてプリンシパル名を保持する String を取る場合を考えましょう。このクラスのインスタンスは、次のコードで作成できます。

String clientName = clientGSSName.toString();
PrivilegedAction readFile = 
    new ReadFileAction(clientName);

doAsPrivileged の呼び出しは、次のようになります。

Subject.doAsPrivileged(client, readFile, null);

サンプルコードおよびポリシーファイル

次のサンプルコードおよびポリシーファイルは、クライアントを実行する特定のユーザーのみに許可されるセキュリティー関連操作用のコードを実行するために、サーバーがクライアントを装う方法を示します。

SampleServerImp.java

SampleServerImp.java ファイルは、クライアントとメッセージを交換したあと、クライアントユーザーとして ReadFileAction を実行するための次のようなコードが生成される点を除けば、前のチュートリアル (「JAAS Login ユーティリティーおよび Java GSS-API を使用したセキュアなメッセージ交換」) で紹介した SampleServer.java ファイルとまったく同じです。

System.out.println("Impersonating client.");

/*
 * Extract the KerberosPrincipal from the client GSSName and 
 * populate it in the principal set of a new Subject. Pass in a 
 * null for credentials since credentials will not be needed.
 */
GSSName clientGSSName = context.getSrcName();
System.out.println("clientGSSName: " + clientGSSName);
Subject client =
   com.sun.security.jgss.GSSUtil.createSubject(clientGSSName,
        null);

/*
* Construct an action that will read a file meant only for the
* client
*/
String clientName = clientGSSName.toString();
PrivilegedAction readFile = 
   new ReadFileAction(clientName);

/*
* Invoke the action via a doAsPrivileged. This allows the
* action to be executed as the client subject, and it also 
* runs that code as privileged. This means that any permission 
* checking that happens beyond this point applies only to 
* the code being run as the client.
*/
Subject.doAsPrivileged(client, readFile, null);

ReadFileAction.java

ReadFileAction.java ファイルには、ReadFileAction クラスが含まれます。このコンストラクタは、クライアントユーザー名の String を引数に取ります。クライアントユーザー名は、ReadFileAction が読み取りを試みるファイルのファイル名の作成に使用されます。ファイル名は、次のようになります。

./data/<name>_info.txt
ここで、<name> は対応するレルムを含まないクライアントユーザー名になります。たとえば、ユーザー名全体が mjones@KRBNT-OPERATIONS.EXAMPLE.COM の場合、ファイル名は次のようになります。 
./data/mjones_info.txt
注:Microsoft Windows システムの場合、スラッシュをバックスラッシュで置き換えてください。

ReadFileAction の run メソッドは、指定されたファイルを読み取り、その内容を出力します。

serverimp.policy

ReadFileAction はファイルを読み取ろうとします。この操作はセキュリティーチェックの対象になります。ReadFileAction はクライアントユーザー (プリンシパル) として実行されることになっているので、ReadFileAction コード自体とクライアントであるプリンシパルに対して適切なアクセス権を付与する必要があります。

ReadFileAction クラスが ReadFileAction.jar という名前の JAR ファイル内に配置され、ユーザープリンシパル名が mjones@KRBNT-OPERATIONS.EXAMPLE.COM である場合を考えましょう。この場合、ポリシーファイル内に次のコードを記述して、アクセス権を付与します。

grant CodeBase "file:./ReadFileAction.jar" 
    Principal javax.security.auth.kerberos.KerberosPrincipal 
        "mjones@KRBNT-OPERATIONS.EXAMPLE.COM" {

    permission java.io.FilePermission "data/mjones_info.txt", 
        "read";
};
serverimp.policy ファイルは、SampleServer コードに doAsPrivileged メソッドの呼び出しに必要なアクセス権 javax.security.auth.AuthPermission "doAsPrivileged" を付与すること、および上に示した FilePermission を付与するプレースホルダを保持することを除き、前の (「JAAS Login ユーティリティーおよび Java GSS-API を使用したセキュアなメッセージ交換」) チュートリアルの server.policy ファイルと厳密に同一です。次に、FilePermission を付与するプレースホルダを示します。 
grant CodeBase "file:./ReadFileAction.jar" 
    Principal javax.security.auth.kerberos.KerberosPrincipal 
        "your_user_name@your_realm" {

    permission java.io.FilePermission "data/your_user_name_info.txt", 
        "read";
};

ここで、your_realm は使用する Kerberos レルムで、your_user_name@your_realm と data/your_user_name_info.txt 内の your_user_name は使用するユーザー名で置き換える必要があります。また、Microsoft Windows システムの場合、data/your_user_name_info.txt 内の「/」を「\」で置き換えてください。

サンプルコードの実行

クライアントを装うサーバーのサンプルコードを実行する場合、前のチュートリアルの「SampleClient および SampleServer プログラムの実行」に説明されているのと同じ操作を実行してください。ただし、次に示す点が異なります。

クライアントから委譲されたクレデンシャルの使用

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

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

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

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

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

boolean delegated = context.getCredDelegState();

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

GSSCredential clientCr = context.getDelegCr();

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

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

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

別の選択肢として、サーバーコードが最初に com.sun.security.jgss.GSSUtil createSubject メソッドを呼び出し、それに委譲されたクレデンシャルを渡すという方法もあります。このメソッドは、これらのクレデンシャルをデフォルトのクレデンシャルとして含むサブジェクトを返します。そのあと、「JAAS 承認」チュートリアルの「サブジェクトのアクセス制御コンテキストへの関連付け」で説明したように、サーバーは、このサブジェクトを現行の AccessControlContext に関連付けることができます。次に、サーバーコードは、GSSManager createContext メソッドの呼び出し時に、null (「現行の」サブジェクトをクレデンシャルとして使用することを指示する) を渡すことができます。違う言い方をすれば、サーバーが実質的にクライアントになります。GSS を使用するそのあとのバックエンドサーバーへの接続は、前のチュートリアルで説明されるとおりの方法で確立できます。これは、委譲されたクレデンシャルを使用するコードが、デフォルトのローカルクレデンシャルを使用するコードと同一であることが必要な場合に有用な方法です。

クレデンシャルの委譲に必要なアクセス権

クレデンシャルを委譲するには、コンテキストイニシエータ (前のチュートリアルでは SampleClient) が javax.security.auth.kerberos.DelegationPermission を保持する必要があります。例を次に示します (斜体のプレースホルダには実際の値を指定)。

permission javax.security.auth.kerberos.DelegationPermission
  "\"service_principal@your_realm\"  
     \"krbtgt/your_realm@your_realm\"";

DelegationPermission が保持する単一のターゲット内に、引用符で囲まれた 2 つの項目が含まれることに注目してください。内部の各引用符は、「\」でエスケープされています。このため、最初の項目は次のようになります。

"service_principal@your_realm"
2 番目の項目は、次のようになります。 
"krbtgt/your_realm@your_realm"

これは、基本的に、クライアントとして実行されるコードに対し、指定されたピアに Kerberos チケットを転送するためのアクセス権を付与します。Kerberos チケットは、krbtgt/your_realm@your_realm からのサービス利用に使用します。

表示されている your_realm は、すべて実際のレルムで置き換えてください。また、service_principal@your_realm も、サービスプリンシパル名 (サーバーを表すサービスプリンシパルの名前) で置き換えてください。(前のチュートリアルの「Kerberos ユーザーおよびサービスプリンシパルの名前」を参照)。レルムが KRBNT-OPERATIONS.EXAMPLE.COM で、サービスプリンシパルが「sample/raven.example.com@KRBNT-OPERATIONS.EXAMPLE.COM」である場合を考えてみましょう。この場合、アクセス権をポリシーファイル内で次のように表示できます。

permission javax.security.auth.kerberos.DelegationPermission
  "\"sample/raven.example.com@KRBNT-OPERATIONS.EXAMPLE.COM\"  
     \"krbtgt/KRBNT-OPERATIONS.EXAMPLE.COM@KRBNT-OPERATIONS.EXAMPLE.COM\"";

前のチュートリアル チュートリアルの紹介および目次
Copyright © 1993, 2013, Oracle and/or its affiliates. All rights reserved.