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

リファレンスガイド

Java TM SE Development Kit 6


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

コアクラスとインタフェース
共通クラス
サブジェクト
プリンシパル
クレデンシャル
認証クラスとインタフェース
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 は、コードソースベースのアクセス制御 (コードの出所および署名者に基づくアクセス制御) を提供してきました。しかし、コードの実行者に基づくアクセス制御を追加実行する機能は不足していました。JAAS は、Java セキュリティーアーキテクチャーを拡張するフレームワークにより、この機能をサポートします。

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

コードを実行するユーザーが認証されると、JAAS 承認コンポーネントはコア Java SE アクセス制御モデルと連動して機能し、慎重な操作の必要なリソースへのアクセスを保護します。アクセス制御の決定がコード位置およびコード署名者 (CodeSource) のみに基づく J2SDK, v 1.3 とは異なり、J2SDK, v 1.4 では、アクセス制御の決定は、実行コードの CodeSource およびコードを実行する Subject オブジェクトで表されるユーザーまたはサービスに基づいています。認証に成功した場合、LoginModule は、関連する 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」を参照してください。

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

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

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

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

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 メソッドとよく似ています。

Subject の Principal 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 によって認証されたため、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 described 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 を提供することができます。

Principals

以前に説明したように、認証に成功した場合、プリンシパルをサブジェクトに関連付けることができます。Principal は、Subject の識別情報を表します。また、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

ログインモジュールがユーザーとの通信を介して認証情報を取得することが必要な場合があります。LoginModule は、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;

LoginModule は CallbackHandler handle メソッドに適切な Callback からなる配列 (たとえばユーザー名の場合 NameCallback、パスワードの場合 PasswordCallback) を渡し、CallbackHandler は要求に従ってユーザーと通信し、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 クラスは、サブジェクト の非公開クレデンシャルへのアクセスを保護し、1 つの public コンストラクタを提供します。 

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

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

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

  • SampleAcn.java。JAAS 認証を説明するサンプルアプリケーション

  • SampleAzn.java。承認チュートリアルで使用されるサンプルアプリケーション。認証と承認の両方を説明する

  • sample_jaas.config。両方のチュートリアルで使用されるサンプルログイン構成ファイル

  • sampleacn.policy。認証チュートリアルのコードに必要なアクセス権を付与するサンプルポリシーファイル

  • sampleazn.policy。承認チュートリアルのコードに必要なアクセス権を付与するサンプルポリシーファイル

  • SampleLoginModule.java。チュートリアルのログイン構成ファイル (sample_jaas.config) によって、基盤となる適切な認証を実装するクラスとして指定される。SampleLoginModule のユーザー認証は、ユーザーによって指定された名前とパスワードが特定の値を持っていることを検証する処理である

  • SamplePrincipal.java。 Principal インタフェースを実装するサンプルクラス。SampleLoginModule によって使用される

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

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

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

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

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

  • login.configuration.provider
  • login.config.url.n

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

  • policy.provider
  • policy.url.n

ログイン構成プロバイダ

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 SE 6 で提供される 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 の認証状態
SampleLoginModulerequiredpasspasspasspass失敗失敗失敗失敗
NTLoginModulesufficient pass失敗失敗失敗pass失敗失敗失敗
SmartCardrequisite * passpass失敗* passpass失敗
Kerberosoptional * pass失敗* * pass失敗*
全体の認証 passpasspass失敗失敗失敗失敗失敗
* = 前の requisite モジュールが失敗するか、または前の sufficient モジュールが成功したため、アプリケーションに制御が返されるので、この値は微妙に変化します。