Java 認証・承認サービス (JAAS) リファレンスガイド

このガイドでは次のトピックについて説明します。

はじめに

当初、Java 認証・承認サービス (Java Authentication and Authorization Service: JAAS) は、Java 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 を決定します。一般的な LoginModule は、ユーザー名およびパスワードの入力を促し、入力されたものを検証します。音声や指紋を読み取り検証を実行できるものもあります。

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

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

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

最初に「JAAS 認証」と「JAAS 承認」のチュートリアルで 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 の一連のチュートリアル」に含まれています。

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

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

共通クラス

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

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

プリンシパルの表現には、java.security.Principal インタフェースが使用されます。また、JAAS により定義されるクレデンシャルには、任意のオブジェクトを指定できます。

サブジェクト

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

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

サブジェクトは、次のコンストラクタを使用して作成されます。

    public Subject();

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

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

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

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

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

    public boolean isReadOnly();

サブジェクトに関連した Principal を取得する場合、次の 2 つのメソッドを利用できます。

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

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

Subject に関連した公開クレデンシャルを取得する場合は、次のメソッドを利用できます。

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

これらのメソッドの動作は getPrincipals メソッドの動作と似ています。ただし、getPrincipals メソッドでは、公開クレデンシャルを取得することはできません。

Subject に関連した非公開クレデンシャルにアクセスする場合は、次のメソッドを利用できます。

    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 を変更するために要求されます。Subject の内部セットが返すのは、引数なしの getPrincipals()、getPublicCredentials()、getPrivateCredentials() メソッドから返されるセットだけです。このため、返されたセットを変更すると、内部セットも影響を受けます。Subject のそれぞれの内部セットは、getPrincipals(Class c)、getPublicCredentials(Class c)、getPrivateCredentials(Class c) メソッドから返されるセットは返しません。メソッド呼び出しごとに、新規セットが作成され、返されます。これらのセットを変更しても、Subject の内部セットに影響はありません。

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

Subject は AccessControlContext と関連付けられます (次に示す doAs および doAsPrivileged メソッドの解説を参照)。次のメソッドは、指定された AccessControlContext と関連した Subject を返します。指定された AccessControlContext と関連付けられた Subject が存在しない場合には、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 メソッドは、呼び出されると特定の Subject としてアクションを実行します。 
    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;

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

Subject.doAs の例

次に、doAs メソッドを最初に利用する場合の例を示します。ユーザー「Bob」が LoginContext (「LoginContext」セクションを参照) によって認証されたため、com.ibm.security.Principal クラスの Principal で Subject が生成され、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 を追加するか Principal を「MOE」に変更する) と、SecurityException がスローされます。

doAsPrivileged メソッド

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

    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 とまったく同じです。ただし、指定された Subject を現行のスレッドの AccessControlContext に関連付ける代わりに、指定された AccessControlContext を使用します。このように、現行のものとは異なった AccessControlContext によってアクションが制限されることがあります。

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

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

プリンシパル

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

クレデンシャル

公開および非公開クレデンシャルクラスは、コア 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 に問い合わせを行い、アプリケーション用に構成されたすべての LoginModule をロードします。
  3. アプリケーションが、LoginContext の login メソッドを呼び出します。
  4. login メソッドがロードされたすべての LoginModule を呼び出します。各 LoginModule はサブジェクトを認証しようとします。成功した場合、LoginModule は、認証されるサブジェクトを表す Subject オブジェクトに、適切な Principal とクレデンシャルを関連付けます。
  5. LoginContext が、認証ステータスをアプリケーションに返します。
  6. 認証が成功すると、アプリケーションは Subject を LoginContext から取得します。

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

LoginContext

javax.security.auth.login.LoginContext クラスは、サブジェクトの認証に使用される基本的なメソッドを提供します。このクラスを使用すると、基盤となる認証テクノロジに依存しないアプリケーションを開発できます。LoginContext は、 Configuration を調べて、特定アプリケーション用に構成された認証サービスまたは LoginModule を判別します。このため、アプリケーション自体を変更せずに、複数の異なる 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 のインスタンス化を行うアプリケーション用として構成される LoginModule を特定します。Subject を入力パラメータとして取らないコンストラクタは、新規 Subject をインスタンス化します。どのコンストラクタでも、null の入力は許可されません。呼び出し元はターゲット名「createLoginContext.<name>」を持つ AuthPermission に対して、LoginContext のインスタンス化を要求します。ここで、<name> は、アプリケーションが LoginContext のインスタンス化の際に name パラメータで参照するログイン構成エントリの名前です。

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

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

    public void login() throws LoginException;

login を呼び出すと、すべての構成済み LoginModule が呼び出され、認証を実行します。認証に成功した場合は、次のメソッドを使用して、認証された Subject (Principal、公開クレデンシャル、非公開クレデンシャルを保持している場合がある) を取得できます。

     public Subject getSubject();

Subject をログアウトして、認証済みの Principals およびクレデンシャルを削除するには、次のメソッドを使用します。

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

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

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

CallbackHandler

LoginModule がユーザーと通信を行なって、認証情報を取得することが必要な場合があります。LoginModule は、javax.security.auth.callback.CallbackHandler を使用してこれを実行します。アプリケーションは、CallbackHandler インタフェースを実装し、これを LoginContext に渡します。LoginContext はこれを基盤となる LoginModule に直接転送します。LoginModule は CallbackHandler を使って、ユーザーからの入力 (パスワード、スマートカードの暗証番号など) を収集したり、ユーザーに情報 (ステータス情報など) を提供したりします。アプリケーションに CallbackHandler の指定を許可することにより、基盤となる LoginModules は、アプリケーションとユーザー間の通信方法に依存せずに動作するようになります。たとえば、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 インタフェースおよびいくつかの実装が含まれています。 LoginModule は、Callback の配列を、CallbackHandler の handle メソッドに直接渡すことができます。

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

承認クラス

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

以降では、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 Runtime の lib/security ディレクトリ内にあります。

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

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

次に、これらのプロパティーを構成する方法の例を示します。この例では、policy.provider、policy.url.n、および login.configuration.provider プロパティーのデフォルトの java.security ファイル内の値はそのまま使用します。デフォルトの java.security ファイルでは、login.config.url.n property の値も一覧表示されていますがコメント化されています。次の例ではコメント化されていません。 

...

#
# 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

...

注:このファイルに対して行われる変更は、後続の JRE 更新によって上書きされることがあります。ただし、システムプロパティー java.security.properties=<URL> を使用して、代替の java.security プロパティーファイルをコマンド行から指定できます。このプロパティーファイルはシステムプロパティーファイルの末尾に追加されます。両方のプロパティーファイルが同じキーに対する値を指定している場合、コマンド行プロパティーファイルが最後にロードされるため、このファイルの値が選択されます。

また、java.security.properties==<URL> と指定すると (2 つの等号を使用)、プロパティーファイルはシステムプロパティーファイルを完全にオーバーライドします。

追加のプロパティーファイルをコマンド行から指定するための機能を無効にするには、システムプロパティーファイル内のキー security.overridePropertiesFile を false に設定します。これはデフォルトでは true に設定されています。

ログイン構成プロバイダ

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

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

たとえば、

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

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

ログイン構成 URL

Oracle が提供するデフォルト実装のように、ファイル内に構成情報が指定されていることを要求するログイン構成実装を使用している場合は、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 プロパティー内に指定することで、デフォルトのポリシー実装を置き換えることができます。

たとえば、

  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 と同時にインストールされたシステムポリシーファイルのポリシーとデフォルトで同じになります。このポリシーファイルの特徴は次のとおりです。

付録 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 の認証ステータス
モジュールクラス フラグ 認証の試行 1 認証の試行 2 認証の試行 3 認証の試行 4 認証の試行 5 認証の試行 6 認証の試行 7 認証の試行 8
SampleLoginModule required 成功 成功 成功 成功 失敗 失敗 失敗 失敗
NTLoginModule sufficient 成功 失敗 失敗 失敗 成功 失敗 失敗 失敗
SmartCard requisite * 成功 成功 失敗 * 成功 成功 失敗
Kerberos optional * 成功 失敗 * * 成功 失敗 *
全体の認証 適用外 成功 成功 成功 失敗 失敗 失敗 失敗 失敗
* = 前の requisite モジュールが失敗するか、または前の sufficient モジュールが成功したため、アプリケーションに制御が返されるので、この値は微妙に変化します。
Copyright © 1993, 2013, Oracle and/or its affiliates. All rights reserved.