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

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

Introduction

当初、Java認証・承認サービス(JAAS)は、Java 2 SDK, Standard Edition (J2SDK), v 1.3のオプション・パッケージ(拡張機能)でした。 JAASはJ2SDK 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により定義されるクレデンシャルには、任意のオブジェクトを指定できます。

Subject

リソースへのアクセスを承認する場合、最初に、アプリケーションが要求元を認証する必要があります。 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を実装するクレデンシャル・クラスを持つことを決定できます。

リフレッシュ可能

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

    boolean isCurrent();
このメソッドは、クレデンシャルが現在有効かどうかを判定します。 
    void refresh() throws RefreshFailedException;
このメソッドは、クレデンシャルの有効期間を更新または延長します。 このメソッドの実装では、AuthPermission("refreshCredential")セキュリティ・チェックを実行し、呼出し側がクレデンシャルをリフレッシュするためのアクセス権を保持することを確認すべきです。

破棄可能

この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 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);
最初のコンストラクタは、指定された名前で新しいAuthPermissionを作成します。 2番目のコンストラクタも、指定された名前で新しい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, 2025, Oracle and/or its affiliates. All rights reserved.