JavaTM 認証・承認サービス (JAAS)

リファレンスガイド

J2SE Development Kit 5.0


はじめに
このドキュメントの対象読者
関連ドキュメント

J2SDK, v 1.4 における JAAS の新機能

コアクラスとインタフェース
共通クラス
被認証者
主体
資格
認証クラスとインタフェース
LoginContext
LoginModule
CallbackHandler
Callback
承認クラス
Policy
AuthPermission
PrivateCredentialPermission

JAAS チュートリアルとサンプルプログラム

付録 A: java.security セキュリティプロパティファイルでの JAAS 設定

付録 B: サンプルログイン構成

はじめに

当初、JavaTM認証・承認サービス (JavaTM Authentication and Authorization Service: JAAS は、JavaTM 2 SDK, Standard Edition (J2SDK), v 1.3 のオプションパッケージ (拡張機能) でした。JAAS は J2SDK, v 1.4 に統合されました。

JAAS は、次の 2 つの目的で使用できます。

JAAS は、Java バージョンの標準 Pluggable Authentication Module (PAM) フレームワークを実装します。詳細については、「Making Login Services Independent of Authentication Technologies」を参照してください。

これまで、Java 2 は、コードソースベースのアクセス制御 (コードの出所および署名者に基づくアクセス制御) を提供してきました。しかし、コードの実行者に基づくアクセス制御を追加実行する機能は不足していました。JAAS は、Java 2 セキュリティアーキテクチャを拡張するフレームワークにより、この機能をサポートします。

JAAS 認証は、「プラグイン可能」方式で実行されます。このため、アプリケーションは、基盤となる認証技術から独立して機能します。アプリケーション内では、新規または更新された認証技術をプラグインとして使用できます。アプリケーションを変更する必要はありません。アプリケーションは、LoginContext オブジェクトをインスタンス化することにより、認証プロセスを有効にします。一方、LoginContext オブジェクトは Configuration を参照して、使用する認証テクノロジまたは LoginModule を決定します。一般的なログインモジュールは、ユーザ名およびパスワードの入力を促し、入力されたものを検証します。音声や指紋の読み取りおよびオブジェクトで検証が実行できるものもあります。

コードを実行するユーザが認証されると、JAAS 承認コンポーネントはコア Java アクセス制御モデルと連動して機能し、慎重な操作の必要なリソースへのアクセスを保護します。アクセス制御の決定がコード位置およびコード署名者 (CodeSource) のみに基づく J2SDK, v 1.3 とは異なり、J2SDK, v 1.4 では、アクセス制御の決定は、実行コードの CodeSource およびコードを実行する Subject オブジェクトで表されるユーザまたはサービスに基づいています。認証に成功した場合、ログインモジュールは、関連する Principal および資格を使って Subject を更新します。

このドキュメントの対象読者

このドキュメントは、CodeSource ベースおよび Subject ベースのセキュリティモデルの制約を受けるアプリケーションを設計する上級開発者を対象としています。ログインモジュール開発者 (認証技術を実装する開発者) は、「JAAS ログインモジュール開発者ガイド」 の前にこのドキュメントをお読みください。

最初に「JAAS 認証」と「JAAS 承認」 の 2 つのチュートリアルで JAAS の使用方法の概要と有効なサンプルコードを確認した上で、このドキュメントから詳細情報を得ることもできます。

関連ドキュメント

このドキュメントでは、読者がすでに次のドキュメントを読んでいることを前提としています。

「JAAS ログインモジュール開発者ガイド」は、認証技術を実装する LoginModule を記述する必要がある上級プログラマ向けのドキュメントであり、このドキュメントの補足として役立ちます。

標準 Pluggable Authentication Module (PAM) フレームワーク (JAAS は Java バージョンの PAM を実装) の詳細情報を取得したい読者は、「Making Login Services Independent of Authentication Technologies」を参照してください。

以下の「チュートリアル」は、JAAS 認証および承認を利用するすべてのユーザを対象としています。

以下のチュートリアルは、JAAS 認証および承認チュートリアルと似ていますが、Kerberos LoginModule の使用方法の解説が含まれるため、使用する前に Kerberos をインストールする必要があります。

この 2 つのチュートリアルは、認証と安全な通信のための基盤技術として Kerberos を利用する「Java GSS-API および JAAS の一連のチュートリアル」に含まれています。

J2SDK, v 1.4 における JAAS の新機能

以前のバージョンの JAAS (JAAS 1.0) と、J2SDK, v 1.4 に含まれる JAAS との相違点を、以下に示します。

J2SDK が JAAS を統合

JavaTM 2 SDK, Standard Edition (J2SDK), バージョン 1.3.x では、JAAS はオプションパッケージ (拡張機能) でした。J2SDK, v 1.4 には、今回 JAAS が統合されました。JAAS は、ユーザの認証およびアクセス制御の実行手段を提供することにより、コア Java 2 プラットフォームを拡張します。

この統合により、システムのセキュリティポリシー関連が影響を受けます。J2SDK, バージョン 1.3 以前は、独自のポリシークラス (java.security.Policy ) を保持していました。オプションパッケージの JAAS 1.0 では、Principal ベースのセキュリティポリシー (javax.security.auth.Policy) が追加提供されていました。コア SDK への統合により SDK ポリシーが優先されるため、JAAS ポリシーは非推奨になりました。

SDK Policy API が更新され、Principal ベースのクエリーを使用できるようになりました。さらに、Policy リファレンス実装が更新され、ポリシーファイル内で Principal ベースの grant エントリを使用できるようになりました。これらのエントリには、Principal フィールドが含まれている場合があります。Principal フィールドは、指定のアクセス権を持ち、ユーザまたは指定された Principal で表現されるその他のエンティティを示し、指定されたコードを実行します。ポリシーファイルを視覚的に作成するためのユーティリティ、Policy Tool も拡張され、Principal フィールドを取り込めるようになりました。これらの変更に合わせて、com.sun.security.auth パッケージ内の JAAS 1.0 Policy リファレンス実装およびそのサポートするクラスは、非推奨になりました。

Policy リファレンス実装と関連 API の変更点については、ポリシーについてのドキュメントを参照してください。

新しいクラスとインタフェース

次のクラスとインタフェースが追加されました。

非推奨項目

以下に、非推奨項目を示します。

コアクラスとインタフェース

JAAS 関連コアクラスおよびインタフェースは、共通クラス、認証クラス、および承認クラスの 3 つのカテゴリに分類できます。

共通クラス

共通クラスは、JAAS 認証および承認コンポーネントの両方に共通です。

鍵 JAAS クラスは、javax.security.auth.Subject です。このクラスは、単一エンティティ (人物など) の関連情報のグループ化を表します。関連情報には、エンティティの Principal、public 資格、および private 資格などがあります。

主体の表現には、java.security.Principal インタフェースが使用されます。また、JAAS により定義される資格には、任意のオブジェクトを指定できます。

被認証者

リソースへのアクセスを承認する場合、最初に、アプリケーションが要求元を認証する必要があります。JAAS フレームワークでは、要求元を「被認証者」という語で表します。被認証者は、ユーザやサービスなどの任意のエンティティです。一度、被認証者が認証されると javax.security.auth.Subject には関連する識別情報、または主体が割り当てられます。単一の被認証者が複数の主体を持つ場合もあります。たとえば、ある人物は、名前の主体 (「John Doe」) および SSN 主体 (「123-45-6789」) を持ちます。これらの主体により、この人物は他の被認証者と区別されます。

被認証者は、「資格」と呼ばれるセキュリティ関連の属性も保持できます。非公開暗号化鍵など、特別な保護が必要な資格は、非公開資格 Set 内に格納されます。公開鍵証明書などの共有される資格は、公開資格 Set 内に格納されます。資格 Set が異なると、それにアクセスおよび変更するためのアクセス権も異なります。

被認証者は、次のコンストラクタを使用して作成されます。 

public Subject();

public Subject(boolean readOnly, Set principals,
Set pubCredentials, Set privCredentials);
最初のコンストラクタは、主体および資格の空 (null ではない) の Set で被認証者を作成します。2 番目のコンストラクタは、指定された主体および資格の Set で被認証者を作成します。被認証者を読み取り専用にするために使用できる boolean 型の引数も持っています。読み取り専用の被認証者内では、主体および資格 Set は不変です。

アプリケーション作成者が被認証者をインスタンス化する必要はありません。アプリケーションが LoginContext をインスタンス化し、被認証者を LoginContext コンストラクタに渡さない場合、LoginContext は新しい空の被認証者をインスタンス化します。LoginContext のセクションを参照してください。

被認証者が読み取り専用の状態でインスタンス化されなかった場合、次のメソッドを呼び出して読み取り専用に設定できます。 

public void setReadOnly();
ターゲット名「setReadOnly」を持つ javax.security.auth.AuthPermission は、このメソッドを呼び出すために要求されます。読み取り専用に設定したあとで、主体や資格を追加または削除しようとすると、IllegalStateException がスローされます。

次のメソッドを使用して、被認証者の読み取り専用状態をテストできます。 

public boolean isReadOnly();

被認証者に関連した主体を取得する場合、次の 2 つのメソッドを利用できます。 

public Set getPrincipals();
public Set getPrincipals(Class c);

最初のメソッドは、被認証者に含まれるすべての主体を返します。一方、2 番目のメソッドは、指定されたクラス c またはそのサブクラスのインスタンスになっている主体しか返しません。被認証者に関連付けられている主体がない場合は、空のセットが返されます。

被認証者に関連した公開資格を取得する場合は、次のメソッドを利用できます。 

public Set getPublicCredentials();
public Set getPublicCredentials(Class c);

これらのメソッドの動作は getPrincipals メソッドの動作と似ています。ただし、getPrincipals メソッドでは、公開資格を取得することはできません。

被認証者に関連した非公開資格にアクセスする場合は、次のメソッドを利用できます。 

public Set getPrivateCredentials();
public Set getPrivateCredentials(Class c);

これらのメソッドの動作は、getPrincipals メソッドや getPublicCredentials メソッドとよく似ています。

被認証者の主体 Set、公開資格 Set、または非公開資格 Set を変更または操作する場合、呼び出し側は java.util.Set クラスで定義されたメソッドを使用します。その方法を示すサンプルコードを以下に示します。 

Subject subject;
Principal principal;
Object credential;

    . . .

// add a Principal and credential to the Subject
subject.getPrincipals().add(principal);
subject.getPublicCredentials().add(credential);

注: 「modifyPrincipals」、「modifyPublicCredentials」、「modifyPrivateCredentials」 のいずれかのターゲット名を持つ AuthPermission は、それぞれの Set を変更するために要求されます。被認証者の内部セットが返すのは、引数なしの getPrincipals()、getPublicCredentials()、getPrivateCredentials() メソッドから返されるセットだけです。このため、返されたセットを変更すると、内部セットも影響を受けます。被認証者の内部セットは、getPrincipals(Class c)、getPublicCredentials(Class c)、getPrivateCredentials(Class c) メソッドから返されるセットは返しません。メソッド呼び出しごとに、新規セットが作成され、返されます。これらのセットを変更しても、被認証者の内部セットに影響はありません。

非公開資格の Set で繰り返し処理を実行するには、各資格にアクセスするため、javax.security.auth.PrivateCredentialPermission が必要です。詳細については、「PrivateCredentialPermission」API ドキュメントを参照してください。

被認証者は AccessControlContext と関連付けられます (以下の doAs および doAsPrivileged メソッドの解説を参照)。次のメソッドは、指定された AccessControlContext と関連した被認証者を返します。指定された AccessControlContext と関連付けられた被認証者が存在しない場合には、null を返します。 

public static Subject getSubject(final AccessControlContext acc);

ターゲット名 「getSubject」を持つ AuthPermission は、Subject.getSubject を呼び出すために要求されます。

Subject クラスには、java.lang.Object から継承した次のメソッドも含まれます。 

public boolean equals(Object o);
public String toString();
public int hashCode();

特定の被認証者としてアクションを実行する doAs メソッド

次の static メソッドは、特定の被認証者としてアクションを実行します。 
public static Object
doAs(final Subject subject,
final java.security.PrivilegedAction action);

public static Object
doAs(final Subject subject,
final java.security.PrivilegedExceptionAction action)
throws java.security.PrivilegedActionException;

どちらのメソッドも、指定された被認証者を現行スレッドの AccessControlContext に関連付けてから、action を実行します。これにより、被認証者として action を実行する効果が得られます。最初のメソッドでは、実行時例外がスローされる可能性がありますが、通常の実行では、action 引数を指定して run メソッドを実行して得られたオブジェクトが返されます。2 番目のメソッドも、PrivilegedExceptionAction run メソッドからのチェックされた例外をスローする場合があることを除き、動作は同じです。ターゲット名「doAs」を持つ AuthPermission は、doAs メソッドを呼び出すために要求されます。

Subject.doAs の例

次に、doAs メソッドを最初に利用する場合の例を示します。ユーザ「Bob」が LoginContext (LoginContext を参照) によって認証されたため、com.ibm.security.Principal クラスの主体に被認証者が生成され、主体の名前が "BOB" になったと想定してください。また、SecurityManager がインストール済みで、アクセス制御ポリシー内に以下が存在するものとします (ポリシーファイルの詳細についてはPolicyを参照)。 

// grant "BOB" permission to read the file "foo.txt"
grant Principal com.ibm.security.Principal "BOB" {
permission java.io.FilePermission "foo.txt", "read";
    };

以下に、サンプルアプリケーションコードを示します。 

class ExampleAction implements java.security.PrivilegedAction {
public Object run() {
java.io.File f = new java.io.File("foo.txt");

// the following call invokes a security check
if (f.exists()) {
System.out.println("File foo.txt exists");
            }
return null;
        }
    }

public class Example1 {
public static void main(String[] args) {

// Authenticate the subject, "BOB".
// This process is desribed in the
// LoginContext section.
            
Subject bob;
// Set bob to the Subject created during the
// authentication process

// perform "ExampleAction" as "BOB"
Subject.doAs(bob, new ExampleAction());
        }
    }

実行時に、ExampleAction が f.exists() を呼び出すと、セキュリティチェックが実行されます。ただし、ExampleAction が 「BOB」 として実行中であり、ポリシー (上記) により必要な FilePermission が 「BOB」 に付与されているため、ExampleAction はセキュリティチェックを通過します。ポリシー内の grant 文を変更する (たとえば、不正な CodeBase を追加するか主体を「MOE」に変更する) と、SecurityException がスローされます。

doAsPrivileged メソッド

次のメソッドも、特定の被認証者としてアクションを実行します。 

public static Object doAsPrivileged(
final Subject subject,
final java.security.PrivilegedAction action,
final java.security.AccessControlContext acc);

public static Object doAsPrivileged(
final Subject subject,
final java.security.PrivilegedExceptionAction action,
final java.security.AccessControlContext acc)
throws java.security.PrivilegedActionException;

ターゲット名 「doAsPrivileged」 を持つ AuthPermission は、doAsPrivileged メソッドを呼び出すために要求されます。

doAs と doAsPrivileged

doAsPrivileged メソッドの動作は、doAs とまったく同じです。ただし、指定された被認証者を現行のスレッドの AccessControlContext に関連付ける代わりに、指定された AccessControlContext を使用します。このように、現行のものとは異なった AccessControlContext によってアクションが制限されることがあります。

AccessControlContext には、AccessControlContext のインスタンス化以降に実行されたすべてのコードに関する情報 (コード位置や、ポリシーによってコードに付与されたアクセス権など) が含まれます。アクセス制御チェックを成功させるため、ポリシーは、AccessControlContext によって参照される各コード項目に、必要なアクセス権を付与する必要があります。

doAsPrivileged に提供された AccessControlContext が null である場合、アクションが別の AccessControlContext によって制限されることはありません。このことは、サーバ環境で役立つ場合があります。サーバは、複数の着信要求を認証し、各要求に対して別々の doAs を実行することができます。各 doAs アクションを新たに開始し、現行のサーバの制限 AccessControlContext をなくすため、サーバは doAsPrivileged を呼び出し、null AccessControlContext を提供することができます。

Principal

以前に説明したように、認証に成功した場合、主体を被認証者に関連付けることができます。主体は、被認証者の識別情報を表します。また、java.security.Principal および java.io.Serializable インタフェースを実装する必要があります。被認証者に関連した主体の更新方法は、被認証者を参照してください。

Credentials

公開および非公開資格クラスは、コア JAAS クラスライブラリの一部ではありません。あらゆるクラスが資格になります。ただし、開発者は、資格に関連する 2 つのインタフェース、Refreshable および Destroyable を実装する資格クラスを持つことを決定できます。

Refreshable

このjavax.security.auth.Refreshable インタフェースは、資格の自動更新機能を提供します。たとえば、有効期間の制限された資格がこのインタフェースを実装すると、呼び出し側が有効期間を更新できるようになります。このインタフェースには、次の 2 つの abstract メソッドがあります。 

boolean isCurrent();
このメソッドは、資格が現在有効かどうかを判定します。 
void refresh() throws RefreshFailedException;
このメソッドは、資格の有効期間を更新または拡張します。このメソッド実装は、AuthPermission("refreshCredential") セキュリティチェックを実行します。このため、呼び出し側は資格を更新するためのアクセス権を保持します。

Destroyable

この javax.security.auth.Destroyable インタフェースは、資格のコンテンツを破棄する機能を提供します。このインタフェースには、次の 2 つの abstract メソッドがあります。 

boolean isDestroyed();
このメソッドは、資格が破棄されたかどうかを判別します。 
void destroy() throws DestroyFailedException;
このメソッドは、この資格に関連した情報を破棄および消去します。以降、この資格の特定メソッドを呼び出すと、IllegalStateException がスローされます。このメソッド実装は、AuthPermission("destroyCredential") セキュリティチェックを実行します。このため、呼び出し側は資格を破棄するためのアクセス権を保持します。

認証クラスとインタフェース

被認証者 (ユーザまたはサービス) の認証では、次の処理が行われます。
  1. アプリケーションが LoginContext をインスタンス化する

  2. LoginContext が、Configuration に問い合わせを行い、アプリケーション用に構成されたすべてのログインモジュールをロードする

  3. アプリケーションが、LoginContext の login メソッドを呼び出す

  4. login メソッドがロードされたすべてのログインモジュールを呼び出す。各ログインモジュールは被認証者を認証しようとする。成功した場合、認証されるている被認証者を表す Subject オブジェクトに、適切な主体と資格を関連付ける

  5. LoginContext が、認証状態をアプリケーションに返す

  6. 認証が成功すると、アプリケーションは Subject を LoginContext から取得する

以下では、認証クラスについて説明します。

LoginContext

javax.security.auth.login.LoginContext クラスは、被認証者の認証に使用される基本的なメソッドを提供します。このクラスを使用すると、基盤となる認証テクノロジに依存しないアプリケーションを開発できます。LoginContext は、Configuration への問い合わせを実行して、特定のアプリケーション用に構成された認証サービスまたは LoginModule を確認します。このため、アプリケーション自体を変更せずに、複数の異なるログインモジュールをプラグインとしてアプリケーションで使用できます。

LoginContext は、選択可能な 4 つのコンストラクタを提供します。 

public LoginContext(String name) throws LoginException;

public LoginContext(String name, Subject subject) throws LoginException;

public LoginContext(String name, CallbackHandler callbackHandler)
throws LoginException

public LoginContext(String name, Subject subject,
CallbackHandler callbackHandler} throws LoginException
すべてのコンストラクタは、共通のパラメータ name を共有します。LoginContext は、この引数をログイン構成のインデックスとして使用し、LoginContext のインスタンス化を行うアプリケーション用として構成されるログインモジュールを特定します。被認証者を入力パラメータとして取らないコンストラクタは、新規被認証者をインスタンス化します。どのコンストラクタでも、null の入力は許可されません。呼び出し元はターゲット名 「createLoginContext.<name>」を持つ AuthPermission に対して、LoginContext のインスタンス化を要求します。ここで、<name> は、アプリケーションが LoginContext のインスタンス化の際に name パラメータで参照するログイン構成エントリの名前です。

CallbackHandler とこれが必要な状況については、CallbackHandler のセクションを参照してください。

実際の認証は、次のメソッドへの呼び出しを使って行われます。 

public void login() throws LoginException;

login を呼び出すと、すべての構成済みログインモジュールが呼び出され、認証を実行します。認証に成功した場合は、次のメソッドを使用して、認証された被認証者 (主体、公開資格、非公開資格) を取得できます。 

public Subject getSubject();

被認証者をログアウトして、認証済みの主体および資格を削除するには、次のメソッドを使用します。 

public void logout() throws LoginException;

次のサンプルコードは、被認証者の認証およびログアウトに必要な呼び出しを示します。 

// let the LoginContext instantiate a new Subject
LoginContext lc = new LoginContext("entryFoo");
try {
// authenticate the Subject
lc.login();
System.out.println("authentication successful");

// get the authenticated Subject
Subject subject = lc.getSubject();

        ...

// all finished -- logout
lc.logout();
} catch (LoginException le) {
System.err.println("authentication unsuccessful: " +  
le.getMessage());
    }

LoginModule

LoginModule インタフェースを使用すると、異なる種類の認証技術を実装して、アプリケーションでプラグインとして利用できます。たとえば、ユーザ名/パスワードベースの認証を実行できるログインモジュールがあります。スマートカードやバイオメトリックデバイスなどのハードウェアへのインタフェースを提供するログインモジュールもあります。

注: アプリケーション作成者は、ログインモジュールの機能を理解していなくてもかまいません。アプリケーションの作成と構成情報 (ログイン構成ファイルの内容など) の指定に集中し、アプリケーションが構成によって指定されたログインモジュール利用してユーザを認証できるようにしてください。

認証技術を実装するログインモジュールを作成する必要があるプログラマは、「JAAS ログインモジュール開発者ガイド」で具体的な手順を確認してください。

CallbackHandler

ログインモジュールがユーザとの通信を介して認証情報を取得することが必要な場合があります。ログインモジュールは、 javax.security.auth.callback.CallbackHandler を使用してこれを実行します。アプリケーションは、CallbackHandler インタフェース を実装し、これを LoginContext に渡します。LoginContext はこれを基盤となるログインモジュールに直接転送します。ログインモジュールはCallbackHandler を使って、ユーザからの入力 (パスワード、スマートカードの暗証番号など) を収集したり、ユーザに情報 (状態情報など) を提供したりします。アプリケーションに CallbackHandler の指定を許可することにより、基盤となるログインモジュールは、アプリケーションとユーザ間の通信方法に依存せずに動作するようになります。たとえば、GUI アプリケーション用の CallbackHandler 実装は、ウィンドウを表示してユーザの入力を促します。一方、非 GUI ツール用の CallbackHandler は、コマンド行から直接入力するようユーザに求めます。

CallbackHandler は、1 つのメソッドを持った実装するためのインタフェースです。 
void handle(Callback[] callbacks)
throws java.io.IOException, UnsupportedCallbackException;

ログインモジュールは CallbackHandler handle メソッドに適切な Callback からなる配列 (たとえばユーザ名の場合 NameCallback、パスワードの場合 PasswordCallback) を渡し、要求に従ってユーザと通信し、Callback 内に適切な値を設定します。たとえば、NameCallback を処理する場合、CallbackHandler はユーザから名前を取得し、NameCallback の setName メソッドを呼び出してその名前を格納します。

「CallbackHandler」のドキュメントには、このドキュメントには記載されていない大量のサンプルが記載されています。

Callback

javax.security.auth.callback パッケージには、Callback インタフェースおよびいくつかの実装が含まれています。ログインモジュールは、Callback の配列を、CallbackHandler の handle メソッドに直接渡すことができます。

使用方法の詳細については、各種 Callback API を参照してください。

承認クラス

JAAS 承認を行うには、実行中のコードと実行ユーザに基づいてアクセス権を付与し、次の作業を行う必要があります。

  • LoginContext のセクションの説明に従ってユーザを認証する

  • 認証の結果生成される被認証者を被認証者の説明に従ってアクセス制御コンテキストに関連付ける

  • 以下の説明に従ってセキュリティポリシー内に主体ベースのエントリを構成する

以下では、Policy 抽象クラスと承認固有のクラス AuthPermission および PrivateCredentialPermission について説明します。

Policy

java.security.Policy クラスは、システム全体のアクセス制御ポリシーを表す抽象クラスです。Policy API は J2SDK, v 1.4 でアップグレードされ、Principal ベースのクエリーをサポートするようになっています。

J2SDK は、デフォルトで、ファイルベースのサブクラス実装を提供します。この実装もアップグレードされ、ポリシーファイル内で Principal ベースの grant エントリを使用できるようになっています。

ポリシーファイルおよびその内部のエントリ構造の詳細は、「デフォルトの Policy の実装とポリシーファイルの構文」を参照してください。

AuthPermission

javax.security.auth.AuthPermission クラスは、JAAS に必須の基本的なアクセス権をカプセル化します。AuthPermission には名前 (ターゲット名とも呼ばれる) は含まれますが、アクションリストは含まれません。したがって、名前付きアクセス権を得るか、アクセス権を得ないかのどちらかになります。

AuthPermission は、java.security.Permission から継承されたメソッドのほかに 2 つの public コンストラクタを持っています。 

public AuthPermission(String name);
public AuthPermission(String name, String actions);
最初のコンストラクタは、指定された name で新規 AuthPermission を作成します。2 番目のコンストラクタも、指定された name で AuthPermission オブジェクトを作成しますが、actions 引数が追加指定されています。この引数は現在のところ未使用であるため、null にします。このコンストラクタは、Policy オブジェクトで新規 Permission オブジェクトをインスタンス化するためだけに存在します。その他の大半のコードでは、最初のコンストラクタの使用が適しています。

現在のところ、AuthPermission オブジェクトは、Policy、Subject、LoginContext、および Configuration オブジェクトへのアクセスの保護に使用されます。サポートされる有効な名前のリストについては、 AuthPermission の javadoc ドキュメントを参照してください。

PrivateCredentialPermission

javax.security.auth.PrivateCredentialPermission クラスは、Subject の非公開資格へのアクセスを保護し、1 つの public コンストラクタを提供します。 

public PrivateCredentialPermission(String name, String actions);
このクラスの詳細は、PrivateCredentialPermission javadoc のドキュメントを参照してください。

JAAS チュートリアルとサンプルプログラム

「JAAS 認証」 および 「JAAS 承認」 の各チュートリアルには、次のサンプルが含まれています。

アプリケーション、ポリシーファイル、およびログイン構成ファイルの詳細については、チュートリアルを参照してください。

チュートリアルに説明されているとおり、アプリケーション作成者は SampleLoginModule.java や SamplePrincipal.java のコードを理解していなくてもかまいません。ログインモジュールを作成するプログラマは、「JAAS ログインモジュール開発者ガイド」でその方法を確認できます。

付録 A: java.security セキュリティプロパティファイルでの JAAS 設定

java.security マスターセキュリティプロパティファイル内で多数の JAAS 設定を行うことができます。このファイルは、Java 2 Runtime の lib/security ディレクトリ内にあります。

JAAS は、java.security に次の 2 つの新しいセキュリティプロパティを追加します。

次の既存のプロパティも JAAS ユーザと関係があります。

ログイン構成プロバイダ

Sun Microsystems が提供するデフォルトの JAAS ログイン構成実装は、その構成情報をファイルから取得します。この情報は、チュートリアルに記載されている特殊な形式で提供されることになっています。

代替プロバイダクラス実装を login.configuration.provider プロパティ内に指定することで、デフォルトの JAAS ログイン構成実装を置き換えることができます。

次に例を示します。 

login.configuration.provider=com.foo.Config
セキュリティプロパティ login.configuration.provider が見つからない、または指定されていない場合、デフォルト値が設定されます。 
login.configuration.provider=com.sun.security.auth.login.ConfigFile

ログイン構成プロバイダを、コマンド行から動的に設定することはできません。

ログイン構成 URL

Sun Microsystems が提供するデフォルト実装のように、ファイル内に構成情報が指定されていることを要求するログイン構成実装を使用している場合は、login.config.url.n プロパティに個々の URL を指定することにより、ログイン構成ファイルの位置を静的に設定できます。「n」 は、1 から始まる連続した番号です。「n >= 2」のように複数の構成ファイルが指定される場合、それらは読み込まれ、結合されて単一の構成になります。

次に例を示します。 

login.config.url.1=file:C:/config/.java.login.config
login.config.url.2=file:C:/users/foo/.foo.login.config

構成ファイルの位置が java.security プロパティファイルに指定されておらず、コマンド行から -Djava.security.auth.login.config オプションを使って動的に指定されてもいない場合、JAAS は以下からデフォルト構成のロードを試みます。 

file:${user.home}/.java.login.config

ポリシープロバイダ

代替プロバイダクラス実装を policy.provider プロパティ内に指定することで、デフォルトの JAAS アクセス制御ポリシー実装を置き換えることができます。

次に例を示します。 

policy.provider=com.foo.Policy
セキュリティプロパティ policy.provider が見つからない、または指定されていない場合、Policy はデフォルト値に設定されます。 
policy.provider=sun.security.provider.PolicyFile

ポリシープロバイダを、コマンド行から動的に設定することはできません。

ポリシーファイル URL

アクセス制御ポリシーファイルの位置は、auth.policy.url.n プロパティにそれぞれの URL を指定することにより、静的に設定できます。「n」 は、1 から始まる連続した番号です。「n >= 2」のように複数のポリシーが指定される場合、それらは読み込まれ、結合されて単一のポリシーになります。

次に例を示します。 

policy.url.1=file:C:/policy/.java.policy
policy.url.2=file:C:/users/foo/.foo.policy

java.security プロパティファイルにポリシーファイルの位置が指定されておらず、-Djava.security.policy オプションによってコマンド行から動的に指定されることもない場合、アクセス制御ポリシーは、J2SDK と同時にインストールされたシステムポリシーファイルと同じになります。このポリシーファイルの特徴は次のとおりです。

  • 標準の拡張機能にすべてのアクセス権を付与

  • 任意のユーザが非特権ポートで待機することを許可

  • 任意のコードがセキュリティ上それほど重要でない特定の「標準」プロパティ (「os.name」、「file.separator」など) を読み取ることを許可

サンプルマスターセキュリティプロパティファイル

以下に、Java 2 Runtime v1.4 で提供される java.security を示します。JAAS 関連プロパティのサンプル設定は太字で示します。この例では、policy.provider、policy.url.n、および login.configuration.provider プロパティのデフォルトの java.security ファイル内の値はそのまま使用します。デフォルトの java.security ファイル内の login.config.url.n の値はコメント化されています。以下の例ではコメント化されていません。 

#
# This is the "master security properties file".
#
# In this file, various security properties are set for use by
# java.security classes.This is where users can statically register
# Cryptography Package Providers ("providers" for short).The term
# "provider" refers to a package or set of packages that supply a
# concrete implementation of a subset of the cryptography aspects of
# the Java Security API.A provider may, for example, implement one or
# more digital signature algorithms or message digest algorithms.
#
# Each provider must implement a subclass of the Provider class.
# To register a provider in this master security properties file,
# specify the Provider subclass name and priority in the format
#
#    security.provider.<n>=<className>  
#
# This declares a provider, and specifies its preference
# order <n>.The preference order is the order in which providers are
# searched for requested algorithms (when no specific provider is
# requested).The order is 1-based; 1 is the most preferred, followed
# by 2, and so on.
#
# <className> must specify the subclass of the Provider class whose
# constructor sets the values of various properties that are required
# for the Java Security API to look up the algorithms or other
# facilities implemented by the provider.
#
# There must be at least one provider specification in java.security.
# There is a default provider that comes standard with the JDK.It
# is called the "SUN" provider, and its Provider subclass
# named Sun appears in the sun.security.provider package.Thus, the
# "SUN" provider is registered via the following:
#
#    security.provider.1=sun.security.provider.Sun
#
# (The number 1 is used for the default provider.)
#
# Note:Statically registered Provider subclasses are instantiated
# when the system is initialized.Providers can be dynamically
# registered instead by calls to either the addProvider or
# insertProviderAt method in the Security class.

#
# List of providers and their preference orders (see above):
#
security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.net.ssl.internal.ssl.Provider
security.provider.3=com.sun.rsajca.Provider
security.provider.4=com.sun.crypto.provider.SunJCE
security.provider.5=sun.security.jgss.SunProvider

#
# Select the source of seed data for SecureRandom.By default it uses
# a system/thread activity algorithm.Optionally, if the platform supports
# it an entropy gathering device can be selected. 
#
#securerandom.source=file:/dev/random
#
# The entropy gathering device is described as a URL and can
# also be specified with the property "java.security.egd".For example,
#   -Djava.security.egd=file:/dev/urandom
# Specifying this property will override the securerandom.source setting.

#
# Class to instantiate as the javax.security.auth.login.Configuration
# provider.
#
login.configuration.provider=com.sun.security.auth.login.ConfigFile

#
# Default login configuration file
#
login.config.url.1=file:${user.home}/.java.login.config

#
# Class to instantiate as the system Policy.This is the name of the class
# that will be used as the Policy object.
#
policy.provider=sun.security.provider.PolicyFile

# The default is to have a single system-wide policy file,
# and a policy file in the user's home directory.
policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy

# whether or not we expand properties in the policy file
# if this is set to false, properties (${...}) will not be expanded in policy
# files.
policy.expandProperties=true

# whether or not we allow an extra policy to be passed on the command line
# with -Djava.security.policy=somefile.Comment out this line to disable
# this feature.
policy.allowSystemProperty=true

# whether or not we look into the IdentityScope for trusted Identities
# when encountering a 1.1 signed JAR file.If the identity is found
# and is trusted, we grant it AllPermission.
policy.ignoreIdentityScope=false

#
# Default keystore type.
#
keystore.type=jks

#
# Class to instantiate as the system scope:
#
system.scope=sun.security.provider.IdentityDatabase

#
# List of comma-separated packages that start with or equal this string
# will cause a security exception to be thrown when
# passed to checkPackageAccess unless the
# corresponding RuntimePermission ("accessClassInPackage."+package) has
# been granted.
package.access=sun.

#
# List of comma-separated packages that start with or equal this string
# will cause a security exception to be thrown when
# passed to checkPackageDefinition unless the
# corresponding RuntimePermission ("defineClassInPackage."+package) has
# been granted.
#
# by default, no packages are restricted for definition, and none of
# the class loaders supplied with the JDK call checkPackageDefinition.
#
#package.definition=

#
# Determines whether this properties file can be appended to
# or overridden on the command line via -Djava.security.properties
#
security.overridePropertiesFile=true

#
# Determines the default key and trust manager factory algorithms for
# the javax.net.ssl package.
#
ssl.KeyManagerFactory.algorithm=SunX509
ssl.TrustManagerFactory.algorithm=SunX509

#
# Determines the default SSLSocketFactory and SSLServerSocketFactory
# provider implementations for the javax.net.ssl package.If, due to
# export and/or import regulations, the providers are not allowed to be
# replaced, changing these values will produce non-functional
# SocketFactory or ServerSocketFactory implementations.
#
#ssl.SocketFactory.provider=
#ssl.ServerSocketFactory.provider=

付録 B: サンプルログイン構成

ログイン構成は、java.security ファイル内の login.config.url.n セキュリティプロパティを使用して配置されます。このプロパティの詳細および java.security ファイルの位置については、「付録 A」を参照してください。

デフォルトの Configuration 実装 ConfigFile は、その構成情報をログイン構成ファイルから取得します。JAAS の提供するデフォルトログイン Configuration 実装の詳細は、com.sun.security.auth.login.ConfigFile クラスの javadoc を参照してください。

以下はサンプルのログイン構成ファイルです。 

Login1 {
sample.SampleLoginModule required debug=true;
    };

Login2 {
sample.SampleLoginModule required;
com.sun.security.auth.module.NTLoginModule sufficient;
com.foo.SmartCard requisite debug=true;
com.foo.Kerberos optional debug=true;
    };

アプリケーション Login1 は、構成済みのログインモジュールの、SampleLoginModule のみを保持します。このため、Login1 が被認証者 (ユーザまたはサービス) を認証しようとする試みは、SampleLoginModule が成功した場合にのみ成功します。

アプリケーション Login2 の認証ロジックは、以下の表で簡単に説明できます。注: required、sufficient、requisite、および optional の各フラグについては、Configuration の javadoc ドキュメントを参照してください。

Login2 の認証状態
SampleLoginModulerequired成功成功成功成功失敗失敗失敗失敗
NTLoginModulesufficient 成功失敗失敗失敗成功失敗失敗失敗
SmartCardrequisite * 成功成功失敗* 成功成功失敗
Kerberosoptional * 成功失敗* * 成功失敗*
全体の認証 成功成功成功失敗失敗失敗失敗失敗
* = 前の requisite モジュールが失敗するか、または前の sufficient モジュールが成功したため、アプリケーションに制御が返されるので、この値は微妙に変化します。

最終更新日: 2001 年 8 月 8 日