1 Javaセキュリティ・モデルの概要

1.2.1 パーミッション

パーミッションとは、ある一連のリソースに対して実行が許可されている一連の操作です。実行環境にロードされるすべてのJavaクラスには、一定の基準に従って一連のパーミッションが割り当てられ、各パーミッションによって特定のリソースに対する特定のアクセス権が付与されます。たとえば、パーミッションによって、データベースへのアクセスを制限したり、ファイルの編集を禁止したりできます。

コードベースのセキュリティでは、コードが生成された状況、デジタル署名されているかどうか（また、誰が署名しているか）など、コードの特性に基づいてパーミッションが付与されます。コードベースは、コードの場所を示すURLです。次に例を示します。

• file:（ローカル・ファイル・システム上のファイル）

• http://*.oracle.com（oracle.comのホスト上のファイル）

• file:${j2ee.home}/lib/oc4j-internal.jar

コードソースはこの概念を拡張し、Javaキーストアに格納されている証明書の配列を必要に応じて扱い、その場所で生成された署名付きのコードを検証します。コードソースはjava.security.CodeSourceインスタンスで表されます。このインスタンスは、java.net.URLインスタンスと、java.security.cert.Certificateインスタンスの配列を指定することによって構築します。

抽象Javaクラスjava.security.Permissionはパーミッションを表し、このクラスから派生した具象型には次のようなものがあります。

• java.security.AllPermission

• java.lang.RuntimePermission（リソース・ターゲットのみが対象）

• java.io.FilePermission（リソースとアクションが対象）

パーミッションの詳細は、http://java.sun.com/j2se/1.5.0/docs/guide/security/spec/security-spec.doc3.htmlを参照してください。

1.2.2 保護ドメインとセキュリティ・ポリシー

保護ドメインによって、パーミッションがコードソースと関連付けられます。その時点で有効なポリシーによって、保護ドメインが決まります。保護ドメインには1つ以上のコードソースが存在します。また、コードを実行しているエンティティ、クラスローダーの参照、およびパーミッション・オブジェクトの集合を表すパーミッション・セット（java.security.PermissionCollectionインスタンス）を記述したプリンシパル配列が存在することもあります。

セキュリティ・ポリシーは、環境の保護ドメインを定義します。つまり、指定のソースからクラスに割り当てられているパーミッションがこのポリシーで特定されます。保護ドメインによってクラスに割り当てられたパーミッションは、クラスがロードされるときに静的にバインドされるか、コードが実行されてセキュリティに関係する操作が行われるときに動的にバインドされます。保護ドメインは、1つまたは複数のポリシー・ファイルで指定されます。

次のポリシー・ファイルのサンプルは、ディレクトリ/home/sysadminに置かれ、かつjJoeによって署名されたコードに、ファイル/tmp/abcへの読取りアクセス権を付与する方法を示しています。

grant signedby jJoe codeBase "file:/home/sysadmin/" {
    permission java.io.FilePermission "/tmp/abc", "read";
};

この例のsignedBy句はオプションです。省略すると、指定された場所にあるすべてのコードにパーミッションが付与されます。図1-1は、クラス、保護ドメインおよびパーミッション・セット間の関係を示しています。

図1-1 保護ドメインによるクラスとパーミッションの関連付け

ポリシー・ファイルの形式およびポリシーのカスタマイズの詳細は、http://java.sun.com/j2se/1.5.0/docs/guide/security/spec/security-spec.doc3.html#20128を参照してください。

1.2.3 セキュリティ・マネージャとアクセス・コントローラ

セキュリティ・マネージャは、Javaセキュリティ・モデルのコンポーネントであり、セキュリティ・ポリシーによってアプリケーションに付与されたパーミッションを適用します。セキュリティに関係する操作をアプリケーションが試行すると、セキュリティ・マネージャによってアプリケーションのパーミッションがチェックされ、操作を許可するかどうかが決定されます。Javaクラスjava.lang.SecurityManagerはセキュリティ・マネージャであり、操作を許可するかどうか、または指定されたパーミッションを適用するかどうかを判定する複数のチェック・メソッドを備えています。

アクセス・コントローラは、セキュリティ・マネージャが操作と決定を制御するために使用するオブジェクトです（セキュリティ・マネージャが無効になっている場合はアプリケーションが直接使用）。アクセス・コントローラの具体的な役割は次のとおりです。

• 現在有効なセキュリティ・ポリシーに基づいて、システム・リソースへのアクセスを許可するかどうかを決定します。

• コードを権限付きとしてマークして、その後のアクセスの判定に影響するようにします。

• 現在のコール・コンテキストを保存できるようにして、保存したコンテキストを他の異なるコンテキストで考慮してアクセス制御を決定できるようにします。

Javaクラスjava.security.AccessControllerはアクセス・コントローラを表し、渡されたパーミッションでリクエストされたアクセスを承諾するかどうかを決定するcheckPermission(aPerm)メソッドを備えています。次のコードSnippetでは、このメソッドを使用してファイル/temp/testFileの読取りを許可しています。

FilePermission perm = new FilePermission("/temp/testFile", "read");
AccessController.checkPermission(perm);

checkPermissionは、アクセス・コントローラの特定の実装に従って評価を行います。デフォルトの実装では、コール・スタック全体、そこに含まれるクラスおよびそれらのクラスに付与されているパーミッションを調べて、リクエストを承諾するかどうかが決定されます。リクエストが承諾された場合も、リクエストが拒否されて（または渡されたパーミッションが無効で）例外がスローされた場合も、このメソッドは通知なしに戻ります。

セキュリティ・マネージャはアクセス制御の中心点を表し、アクセス・コントローラは特定のアクセス・アルゴリズムを実装します。

セキュリティ・マネージャとアクセス・コントローラの詳細は、http://java.sun.com/j2se/1.5.0/docs/guide/security/spec/security-spec.doc6.htmlを参照してください。

1.3.1 プリンシパルとサブジェクト

プリンシパルは、認証プロセスによってエンティティ（ユーザー、グループ、システム・プロセスなど）に割り当てられるアイデンティティです。プリンシパルの抽象概念は、Javaインタフェースjavax.security.auth.Principalで表されます。具象的なプリンシパルは、このインタフェースを実装するクラスのインスタンスで表されます。アプリケーションでインスタンス化される各プリンシパルには、そのプリンシパルを識別する個別の名前が必要です。

サブジェクトは、一連のプリンシパルおよび場合によってはパスワードや暗号キーなどの資格証明を含めた、関連するセキュリティ情報のグループです。Javaクラスjavax.security.auth.Subjectはサブジェクトを表します。認証が成功すると、このクラスのインスタンスが作成され、プリンシパルが移入されます。したがって、サブジェクトは認証されたエンティティを表し、サブジェクト内のプリンシパルと資格証明を使用して、認証されたエンティティで実行できるアクションが決まります。

プリンシパルとサブジェクトの詳細は、次のサイトを参照してください。

• http://java.sun.com/j2se/1.5.0/docs/api/java/security/Principal.html

• http://java.sun.com/j2se/1.5.0/docs/api/javax/security/auth/Subject.html

1.3.2 ログイン・モジュール

ログイン・モジュールは、ユーザーを認証し、サブジェクトにプリンシパルを移入するコンポーネントです。ログイン・モジュールは、アプリケーション・コードを変更することなくアプリケーションにプラグインして使用できます。アプリケーションでは複数のログイン・モジュールを使用できます。

ログイン・モジュールの抽象概念は、Javaインタフェースjavax.security.auth.spi.LoginModuleで表されます。具象的なログイン・モジュールは、このインタフェースを実装するクラスのインスタンスで表されます。

ログイン・モジュールでユーザーを認証するために、JavaSEアプリケーションではまずログイン・コンテキストがインスタンス化されます。次に構成ファイルが参照され、アプリケーションに対して構成されているすべてのログイン・モジュールがロードされ、各モジュールでメソッドloginが起動されます。各ログイン・モジュールで、必要に応じて1つ以上のプリンシパルがサブジェクトに追加されます。サブジェクトは、認証が成功した場合にのみ使用可能となります。

ただし、JavaEEアプリケーションでは、アプリケーションでログイン・コンテキストをインスタンス化しなくても、ログイン・モジュールをコンテナで暗黙的に起動できます。

ログイン・モジュールがユーザーと通信して認証データを取得する手段としてコールバック・ハンドラがあります。このハンドラをアプリケーションでログイン・コンテキストがインスタンス化される際に指定することで、そのコンテキストで起動されるすべてのログイン・モジュールが、渡されたコールバック・ハンドラを使用するようになります。このメカニズムにより、ログイン・モジュールのロジックでユーザー操作が不要となります。

アプリケーションではログイン・モジュールのスタックを使用してユーザーを認証でき、各モジュールではスタック内の他のモジュールとは無関係に独自の計算を実行できます。アプリケーションで使用されるスタックは、アプリケーションのデプロイメント・ディスクリプタで定義されます。このファイルでログイン・モジュールが列挙される順序は重要です。これは、認証アルゴリズムで、モジュールのセキュリティ・レベルを特定するフラグ（required、sufficient、requisite、optional）などのデータに加えてこの順序が考慮されるためです。

ログイン・モジュール構成の詳細は、http://java.sun.com/j2se/1.5.0/docs/api/javax/security/auth/login/Configuration.htmlを参照してください。

1.3.3 サブジェクトとアクセス制御コンテキスト

認証プロセスが成功してサブジェクトが使用可能になると、アプリケーションでは、メソッドdoAsまたはdoAsPriviledgedをコールし、特定のコンテキストで機密性の高いアクションを実行することをそのサブジェクトに認可します。両者の違いは、doAsが現在実行中のコンテキストを使用する一方で、doAsPriviledgedが実行中のコンテキストと必ずしも同じでない提供されたコンテキストを使用する点です。

アクションと制御コンテキストの詳細は、次のサイトを参照してください。

• http://java.sun.com/j2se/1.5.0/docs/api/java/security/class-use/PrivilegedAction.html

• http://java.sun.com/j2se/1.5.0/docs/api/java/security/AccessController.html

メソッドdoAsおよびdoAsPrivilegedの詳細は、次のドキュメントを参照してください。

• http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/JAASRefGuide.html.

1.4.1 コンテナベースのセキュリティ

コンテナは、コンテナ内で実行されるアプリケーションに、宣言的なセキュリティとプログラム的なセキュリティの2種類のセキュリティを提供します。

宣言的なセキュリティでは、アプリケーション・デプロイメント・ディスクリプタ・ファイルで表されているセキュリティが参照されます。コンテナは、実行時にこのファイルを使用して、WebモジュールURLやEJB Beanメソッドなどのアプリケーション・リソースへのアクセス制御を適用します。

EJBテクノロジとWebサーバー・セキュリティ・モデルの詳細は、次のサイトを参照してください。

• http://java.sun.com/developer/technicalArticles/J2EE/jpa/

• http://docs.sun.com/app/docs/doc/820-1066/abxep?a=view

プログラム的なセキュリティでは、セキュリティ対応アプリケーションのコードで表されているセキュリティが参照されます。このセキュリティは、宣言的なセキュリティでアプリケーションのセキュリティ要件を十分に表せない場合に役立ちます。

プログラム的なセキュリティを使用するには、通常、アプリケーションでインタフェースjavax.ejb.EJBContextまたはjavax.servlet.http.HttpServRequestを実装し、weblogic.security APIと次のメソッドを使用してセキュリティ上の決定をカスタマイズします。

• EJBContext.isCallerInRole(aRoleName)

• EJBContext.getCallerPrincipal()

• HttpServRequest.isUserInRole(aRoleName)

• HttpServRequest.getUserPrincipal()

これらのインタフェースの詳細は、次のサイトを参照してください。

• http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/http/HttpServletRequest.html

• http://java.sun.com/j2ee/1.4/docs/api/javax/ejb/EJBContext.html

1.4.2 認証モデル

サーバーでは、Basic、フォームまたはクライアント証明書でWebアプリケーションのエンドユーザーが認証されます。この3つの方法は提供するセキュリティの範囲が異なりますが、基本的にはどの方法も、サーバーで資格証明を作成したりアクセスを拒否したりするために処理されるアカウント名やパスワードなどのデータをユーザーから取得します。サーバーによるユーザーの認証方法は、アプリケーション・デプロイメント・ディスクリプタで指定します。

サーバーでは、構成済のアイデンティティ・ストアと照合することで、提供された資格証明を検証し、それを使用してそのサーバーにあるセキュアなリソースへのアクセスのほか、別のサーバーで実行されていることもあるエンタープライズBeanメソッドのコールへのアクセスを認可します。

1.4.3 認可モデル

JavaEE認可モデルは、セキュリティ・ロールに基づいています。セキュリティ・ロールは、アプリケーション・デプロイメント・ディスクリプタまたはアプリケーション・コード（注釈を使用）で指定できる一連のユーザーです。アプリケーションでは、リソースに対する特定の操作の実行を許可されるロールを指定することで、リソース（WebモジュールURLやBeanメソッドなど）へのアクセスを制御します。

デプロイ時に、アプリケーションスコープのロールが実行環境のセキュリティ・エンティティ（ユーザー、ユーザーのグループ、プリンシパルなど）にマップされます。このマッピングは、デプロイメント・ディスクリプタとは別の構成ファイルで指定します。

実行時にプリンシパルがリソースへのアクセスをリクエストすると、リソースへのアクセスを許可されたロールがプリンシパルに関連付けられているかがコンテナによって確認され、関連付けられている場合はコンテナからアプリケーションに制御が渡されてリクエストが許可されます。

このモデルでは、他にもエンタープライズJava BeanまたはWebコンポーネントを実行する際に必ず使用するアイデンティティをアプリケーションで指定でき（run-asメソッドベースの認可）、トランスポート層のセキュリティ（SSL）がサポートされます。

サーブレットのセキュリティの詳細は、http://java.sun.com/products/servlet/whitepaper.htmlを参照してください。

1.6.1 モデルの比較の要約

これらの3つのモデルの違いは、各モデルが誰からのアクセスから何を保護しているかという点にあります。

次の表は、各モデルとOPSSについてこの点をまとめたものです。