Java 認証・承認サービス (JAAS) 1.0

開発者用ガイド

• 概要
• 本書の対象読者
• 関連資料
• 概要
• コア・クラス
• 共通クラス
  • 件名
  • プリンシパル (Principals)
  • 資格情報
• 認証クラス
• LoginContext
• LoginModule
• CallbackHandler
• コールバック
• 許可クラス
• ポリシー
• AuthPermission
• PrivateCredentialPermission

参照

• 実装
• "Hello World"、JAAS スタイル!
• 付録 A: java.security セキュリティー・プロパティー・ファイル・ファイルでの JAAS 設定
• 付録 B: ログイン構成ファイル
• 付録 C: 権限ポリシー・ファイル

概要

Java Authentication and Authorization Service (JAAS) は、Java 2 Software Development Kit バージョン 1.3の標準拡張機能です。 現在、Java 2 はコード・ソース・ベースのアクセス制御 (コードの発信元の およびコードの 署名者 に基づくアクセス制御) を提供しています。 ただし、コードの実行者 に基づく追加のアクセス制御を実施する機能に欠けています。 JAAS は、そのようなサポートで Java 2 セキュリティー・モデルを拡張するフレームワークを提供します。

この資料の対象読者

この資料は、コード・ソース・ベースのセキュリティー・モデルと Subject ベースのセキュリティー・モデルによって制限されたアプリケーションを作成しようとしている、経験を積んだプログラマーを対象としています。

関連資料

この資料は、読者が以下の資料を既に読み終えていることを前提としています。

• Java 2 Software Development Kit API 仕様
• JAAS API 仕様
• セキュリティーと Java プラットフォーム

このガイドの補足として、Oracle が提供する 「LoginModule 開発者ガイド」 があります。

概要

JAAS インフラストラクチャーは、2 つのメイン・コンポーネント、すなわち認証コンポーネントと権限 (承認) コンポーネントに分割できます。 JAAS 認証コンポーネントは、コードがアプリケーション、アプレット、Bean、またはサーブレットのいずれとして実行されているかに関係なく、Java コードを現在処理しているユーザーを確実かつ安全に判別する機能を提供します。 JAAS 許可コンポーネントは、コード・ソース (Java 2 で行われる) に応じて、認証されたユーザーに応じて、処理 Java コードが機密タスクを実行しないように制限する手段を提供することにより、既存の Java 2 セキュリティー・フレームワークを補足します。

JAAS 認証は、プラグ可能 形式で実行されます。 これにより、Java アプリケーションは、基礎となる認証テクノロジーから独立した状態を保つことができます。 したがって、アプリケーションそのものに変更を加えなくても、新規または更新された認証テクノロジーをアプリケーションの下で接続することができます。 アプリケーションは、以下のオブジェクトをインスタンス化することにより認証プロセスを有効化します。

LoginContext

Configuration

LoginModule

コードを処理するユーザーが認証されると、 JAAS 許可コンポーネントは、既存の Java 2 アクセス制御モデルと連動して、機密リソースへのアクセスを保護します。 Java 2 とは異なり、アクセス制御の決定はコード・ロケーションとコード署名者のみに基づいています。

CodeSource

CodeSource

Subject

java.io.FilePermission

java.net.SocketPermission

コア・クラス

• 共通クラス
  • Subject、Principals、Credentials
• 認証クラス
  • LoginContext、LoginModule、CallbackHandler、Callback
• 権限クラス
  • Policy、AuthPermission、PrivateCredentialPermission

共通クラス

主要なクラス (JAAS クラス) は、

Subject

JAAS は既存の Java 2 を使用することに注意してください。

java.security.Principal

サブジェクト

A

Subject

Set

Set

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

    public Subject();

    public Subject(boolean readOnly, Set principals,
                   Set pubCredentials, Set privCredentials);

これらのコンストラクターを使用せずに認証済みサブジェクトへの参照を取得する代替方法を、 LoginContext セクションに示します。

サブジェクトが読み取り専用状態になるようにインスタンス化されなかった場合、次のメソッドを呼び出すことによって、読み取り専用状態に設定することができます。

    public void setReadOnly();

AuthPermission("setReadOnly")

IllegalStateException

サブジェクトの読み取り専用状態をテストするには、次のメソッドを呼び出すことができます。

    public boolean isReadOnly();

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

サブジェクトに関連した公開信任状を検索するには、次のメソッドが使用可能です。

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

getPrincipals

サブジェクトに関連した秘密信任状を検索するには、次のメソッドが使用可能です。

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

getPrincipals

getPublicCredentials

サブジェクトのプリンシパル・セット、公開資格情報セット、または秘密資格情報セットを変更するか、またはそれに対する操作を行うには、呼び出し元が

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);

AuthPermission("modifyPrincipals")

AuthPermission("modifyPublicCredentials")

AuthPermission("modifyPrivateCredentials")

getPrincipals

getPublicCredentials

getPrivateCredentials

getPrincipals(Class c)

getPublicCredentials(Class c)

getPrivateCredentials(Class c)

AccessControlContext

AccessControlContext

    public static Subject getSubject(final AccessControlContext acc);

AuthPermission("getSubject")

Subject.getSubject

また、Subject クラスには以下から継承されたメソッドが含まれます。

java.lang.Object

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

特定のサブジェクトとして処理を実行するために、次の静的メソッドを呼び出すことができます。

    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

PrivilegedExceptionAction

AuthPermission("doAs")

doAs

最初のメソッドを示す例を 2 つ紹介します

doAs

Subject

com.ibm.security.Principal

LoginContext

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

Subject.doAs の例 1

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

            // exists() 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;
            ...

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

ExampleAction

f.exists()

ExampleAction

FilePermission

ExampleAction

例 2 は、例 1 と同じシナリオを使用します。

Subject.doAs の例 2

    public class Example2 {
        // Example of using an anonymous action class.
        public static void main(String[] args) {
            // Authenticate the subject, "BOB".
            // This process is described in the
            // LoginContext section.

            Subject bob;
            ...

            // perform "ExampleAction" as "BOB":
            Subject.doAs(bob, new ExampleAction() {
                public Object run() {
                    java.io.File f = new java.io.File("foo.txt");
                    if (f.exists()) {
                        System.out.println("File foo.txt exists.");
                    }
                    return null;
                }
            });
        }
    }

SecurityException

SecurityException

どちらの例も同じ関数を実行するため、一方のコードを他方より優先するには理由が必要です。 例 1 は、無名クラスに精通していないプログラマーにとって、読み取りやすいでしょう。 また、action クラスは、固有の CodeBase を持つ個別のファイルに置くことができます。そうすると、permission grant はこの情報を使用できます。 例 2 はよりコンパクトで、実行される action は見つけるのが簡単です。なぜなら、

doAs

さらに、次のメソッドも特定のサブジェクトとして処理を実行します。 ただし

doAsPrivileged

AccessControlContext

    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

doAs

doAsPrivileged

AccessControlContext

AuthPermission("doAsPrivileged")

doAsPrivileged

Principals

java.security.Principal

java.io.Serializable

Credentials

Refreshable

    boolean isCurrent();

    void refresh() throws RefreshFailedException;

AuthPermission("refreshCredential")

Destroyable

    boolean isDestroyed();

    void destroy() throws DestroyFailedException;

IllegalStateException

AuthPermission("destroyCredential")

認証クラス

Subject

1. アプリケーションが以下をインスタンス化します。

   
   LoginContext
   

   .
2. この

   
   LoginContext
   

   は構成を調べて、そのアプリケーション用に構成されたすべての LoginModules をロードします。
3. アプリケーションは LoginContext の login メソッドを呼び出します。
4. login メソッドは、ロードされたすべての LoginModules を呼び出します。 それぞれの

   
   LoginModule
   

   が

   
   Subject
   

   を認証しようとします。成功すると、LoginModule は関係のあるプリンシパルおよび資格情報を以下と関連付けます。

   
   Subject
   

   .
5. この

   
   LoginContext
   

   は認証状況をアプリケーションに戻します。
6. 認証が成功した場合、アプリケーションは認証済みの

   
   Subject
   

   を以下から取得します。

   
   LoginContext
   

   .

LoginContext

LoginContext

LoginContext

Configuration

LoginContext

    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

LoginContext

Subject

Subject

AuthPermission("createLoginContext")

LoginContext

実際の認証は、次のメソッドの呼び出しとともに行われます。

    public void login() throws LoginException;

Subject

    public Subject getSubject();

Subject

    public void logout() throws LoginException;

アプリケーション内の次のコードの断片は、"moduleFoo" という名前の構成項目を持つ構成ファイルにアクセスした後で、"bob" と呼ばれるサブジェクトを認証します。

    Subject bob = new Subject();
    LoginContext lc = new LoginContext("moduleFoo", bob);
    try {
        lc.login();
        System.out.println("authentication successful");
    } catch (LoginException le) {
        System.out.println("authentication unsuccessful"+le.printStackTrace());
    }

    LoginContext lc = new LoginContext("moduleFoo");
    try {
        lc.login();
        System.out.println("authentication successful");
    } catch (LoginException le) {
        System.out.println("authentication unsuccessful"+le.printStackTrace());
    }
    Subject subject = lc.getSubject();

AuthPermission("getSubject")

Subject.getSubject

LoginModule

LoginModule インターフェースは、アプリケーションの下で接続できるさまざまな種類の認証テクノロジーをインプリメントする機能を開発者に提供します。 例えば、

LoginModule

「 LoginModule 開発者ガイド」 は、開発者が LoginModuleを実装するためのステップバイステップの手順を詳しく説明する資料です。

以下をインスタンス化するには

LoginModule

LoginContext

LoginModule

LoginModule

LoginContext

initialize

   void initialize(Subject subject, CallbackHandler callbackHandler,
        Map sharedState, Map options);

     boolean login() throws LoginException;

次のメソッドは、認証プロセスを完了し、終了させます。

     boolean commit() throws LoginException;

次のメソッドは、フェーズ 1 が成功しなかった場合に認証プロセスを停止します。

    boolean abort() throws LoginException;

    boolean logout() throws LoginException;

Subject

commit

CallbackHandler

場合によっては、LoginModule は、認証情報を取得するためにユーザーと通信しなければなりません。 LoginModules はこのために CallbackHandler を使用します。 アプリケーションは CallbackHandler インターフェースをインプリメントし、それを LoginContext に渡します。そして、基礎となる LoginModules に直接転送します。 LoginModules は、ユーザーからの入力 (パスワードまたはスマート・カード・ピン番号など) を収集することと、ユーザーに情報 (状況情報など) を提供することの両方のために、CallbackHandler を使用します。 アプリケーションが CallbackHandler を指定できるようにすることにより、基礎となる LoginModules は、アプリケーションがユーザーと対話するさまざまな方法からは独立したままでいられます。 例えば、GUI アプリケーション用の CallbackHandler をインプリメントすると、ユーザーからの入力を送信請求するためにウィンドウが表示されます。 非 GUI ツール用の CallbackHandler をインプリメントすると、ユーザーはコマンド行から直接入力するように促されます。

CallbackHandler

     void handle(Callback[] callbacks)
     throws java.io.IOException, UnsupportedCallbackException;

Callback

使用法の詳細については、各種の Callback API を調べてください。

権限クラス

Subject

Subject

Subject

Policy

ポリシー

Policy

    public abstract java.security.PermissionCollection getPermissions
                    (Subject subject,
                    java.security.CodeSource cs);
    public abstract void refresh();

getPermissions

Subject

CodeSource

refresh

Policy

refresh

AuthPermission("refreshPolicy")

以下のメソッドは現行のランタイム

Policy

AuthPermission("getPolicy")

    public static Policy getPolicy();

Policy

Subject

CodeSource

    policy = Policy.getPolicy();
    PermissionCollection perms = policy.getPermissions(subject, codeSource);

Policy

Policy.setPolicy

AuthPermission("setPolicy")

    public static void setPolicy(Policy policy);

ポリシー・ファイルのサンプル項目:

これらの例は、デフォルトの PolicyFile インプリメンテーションにのみ関係があります。

以下の

Policy

Subject

Principal

Subject

    grant CodeBase ["URL"],
          Signedby ["signers"],
          Principal [Principal_Class] "Principal_Name",
          Principal ... {
        permission Permission_Class ["Target_Name"]
                                    [, "Permission_Actions"]
                                    [, signedBy "SignerName"];
    };

    // example grant entry
    grant CodeBase "http://griffin.ibm.com", Signedby "davis",
          Principal com.ibm.security.auth.NTUserPrincipal "kent" {
        permission java.io.FilePermission "c:/kent/files/*", "read, write";
    };

Policy

grant 項目の CodeBase コンポーネントと Signedby コンポーネントは、JAAS

Policy

上記の例では、grant 項目は、"http://griffin.ibm.com" からダウンロードされ、"davis" によって署名されて、NT ユーザー "kent" として実行しているコードが、1 つの

Permission

Permission

複数のプリンシパルが 1 つの grant 項目内にリストされることがあります。 コードを実行している現行の

Subject

Principal

    grant Principal com.ibm.security.auth.NTUserPrincipal "kent",
          Principal com.ibm.security.auth.NTSidGroupPrincipal "S-1-1-0" {
        permission java.io.FilePermission "c:/user/kent/", "read, write";
        permission java.net.SocketPermission "griffin.ibm.com", "connect";
    };

AuthPermission

Permission

AuthPermission

    public AuthPermission(String name);
    public AuthPermission(String name, String actions);

Policy

AuthPermission オブジェクトは、Policy、Subject、LoginContext、および Configuration オブジェクトへのアクセスを保護するために使用されます。 サポートされる有効な名前のリストについては、AuthPermission Javadoc を参照してください。

PrivateCredentialPermission

    public PrivateCredentialPermission(String name, String actions);

インプリメンテーション

JAAS プロバイダーおよびポリシー・ファイルにはデフォルト値が存在するため、ユーザーは JAAS をインプリメントするためにそれらのリストを静的に (java.security ファイル内で) リストすることも、動的に (コマンド行 -D オプション) リストすることも必要ありません。 また、デフォルト構成およびポリシー・ファイル・プロバイダーは、ユーザー開発のプロバイダーによって置き換えられることがあります。 そのため、このセクションでは、JAAS デフォルト・プロバイダーおよびポリシー・ファイルとともに、代わりのプロバイダーを使用可能にするプロパティーの説明を試みます。

ここで要約される事柄よりも詳しい情報については、Default Policy File API および Default Configuration File API をお読みください。

認証プロバイダー (authentication provider)

認証プロバイダーまたは構成クラスは、

login.configuration.provider=[class]

Configuration

次に例を示します。

  login.configuration.provider=com.foo.Config

login.configuration.provider

com.ibm.security.auth.login.ConfigFile

以下の

Configuration

AuthPermission("getLoginConfiguration")

構成プロバイダーをコマンド行で動的に設定する方法はありません。

認証構成ファイル

認証構成ファイルは、java.security で、以下とともに静的に設定することができきます。

login.config.url.n=[URL]

セキュリティー・プロパティー

policy.allowSystemProperty

java.security.auth.login.config

  ... -Djava.security.auth.login.config=c:\config_policy\login.config ...
  or
  ... -Djava.security.auth.login.config=file:c:/config_policy/login.config ...

構成ファイルが静的または動的に見つからない場合、JAAS は構成ファイルを次のデフォルト位置からロードしようとします。

${user.home}\.java.login.config

許可プロバイダー

権限プロバイダー、または JAAS Policy クラスは、

auth.policy.provider=[class]

Policy

次に例を示します。

  auth.policy.provider=com.foo.Policy

auth.policy.provider

com.ibm.security.auth.PolicyFile

以下の

Configuration

AuthPermission("getPolicy")

権限プロバイダーをコマンド行で動的に設定する方法はありません。

許可ポリシー・ファイル

権限ポリシー・ファイルは、 java.security で静的に設定することができます。

auth.policy.url.n=[URL]

セキュリティー・プロパティー

policy.allowSystemProperty

java.security.auth.policy

  ... -Djava.security.auth.policy=c:\auth_policy\java.auth.policy ...
  or
  ... -Djava.security.auth.policy=file:c:/auth_policy/java.auth.policy ...

権限ポリシーのロード元にするデフォルト位置はありません。

"Hello World"、JAAS スタイル!

ダーク・サングラスとお気に入りのフェドラ・ハットでアルト・サックスを手に入れる ... JAAS-y を取得します。 はい、別の "Hello World!" です。 プログラム。 このセクションでは、JAAS インストールをテストするためのプログラムを使用可能にします。

インストール: JAAS がインストールされていることが想定されています。 例えば、JAAS JAR ファイルがご使用の Development Kit の extensions ディレクトリーにコピーされています。

ファイルの取得: HelloWorld.tar をご使用のテスト・ディレクトリーにダウンロードします。 "jar xvf HelloWorld.tar" を使用して、それを解凍します。

テスト・ディレクトリーの内容を検査します。

• HWLoginModule.java
• HWPrincipal.java
• HelloWorld.java

• ソース・ファイルは、classes ディレクトリーにプリコンパイルされています。

• jaas.config
• java2.policy
• jaas.policy

ソース・ファイルのコンパイル: 3 つのソース・ファイル、HWLoginModule.java、HWPrincipal.java、および HelloWorld.java は既にコンパイルされているため、コンパイルする必要はありません。

ソース・ファイルが変更される場合、それらが保管されているテスト・ディレクトリーに変更して、次のように入力します。

javac -d .\classes *.java

注:

HWLoginModule

HWPrincipal

com.ibm.security

ポリシー・ファイルの調査: 構成ファイル jaas.config には次の 1 つの項目が含まれています。

helloWorld {
   com.ibm.security.HWLoginModule required debug=true;
};

LoginModule

LoginModuleControlFlag

HWLoginModule

Java 2 ポリシー・ファイル java2.policyには、1 つの許可ブロックが含まれています。

grant {
   permission javax.security.auth.AuthPermission "createLoginContext";
   permission javax.security.auth.AuthPermission "modifyPrincipals";
   permission javax.security.auth.AuthPermission "doAsPrivileged";
};

Subject

Subject

JAAS ポリシー・ファイル jaas.policy にも、1 つの許可ブロックが含まれています。

grant Principal com.ibm.security.HWPrincipal "bob" {
   permission java.util.PropertyPermission "java.home", "read";
   permission java.util.PropertyPermission "user.home", "read";
   permission java.io.FilePermission "foo.txt", "read";
};

HWPrincipal

Subject

Subject.doAsPrivileged(lc.getSubject(), new PrivilegedAction() {
    public Object run() {
        System.out.println("\nYour java.home property: "
                           +System.getProperty("java.home"));

        System.out.println("\nYour user.home property: "
                           +System.getProperty("user.home"));

        File f = new File("foo.txt");
        System.out.print("\nfoo.txt does ");
        if (!f.exists()) System.out.print("not ");
        System.out.println("exist in your current directory");

        System.out.println("\nOh, by the way ...");

        try {
            Thread.currentThread().sleep(2000);
        } catch (Exception e) {
            // ignore
        }
        System.out.println("\n\nHello World!\n");
        return null;
    }
}, null);

ソースファイルの調査 LoginModule、

HWLoginModule

HelloWorld アプリケーションでは、ユーザーは 3 回までパスワードの入力を試みることができます。 Go JAAS が正しく入力されると、ユーザー名と同じ名前を持つ

HWPrincipal

Subject

Principal クラス、

HWPrincipal

メイン・アプリケーション、

HelloWorld

LoginContext

MyCallbackHandler

    LoginContext lc = null;
    try {
        lc = new LoginContext("helloWorld", new MyCallbackHandler());
    } catch (LoginException le) {
        le.printStackTrace();
        System.exit(-1);
    }

HWLoginModule

HWPrincipal

前述のように、 作業は認証済みサブジェクトとして実行されます。

HelloWorld テストの実行

HelloWorld プログラムを実行するには、最初にテスト・ディレクトリーに変更します。 構成およびポリシー・ファイルをロードする必要があります。 java.security またはコマンド行で設定する正しいプロパティーについては、 「実装」 を参照してください。 後者のメソッドについて、これから説明します。

以下のコマンドは、明確にするために複数の行に分割されています。 1 つの連続するコマンドとして入力してください。

java -Djava.security.manager=
     -Djava.security.auth.login.config=.\jaas.config
     -Djava.security.policy=.\java2.policy
     -Djava.security.auth.policy=.\jaas.policy
     HelloWorld

     -Djava.security.auth.login.config=c:\test\hello\jaas.config

SecurityException

HelloWorld を楽しむ

好きなだけ HelloWorld を再実行してください。 入力したユーザー名/パスワードを変え、構成ファイル項目を変更し、ポリシー・ファイル許可を変更し、さらに追加の LoginModules を helloWorld 構成項目に追加する (積み重ねる) ことまで、既に提案されました。 さらに、codebase フィールドをポリシー・ファイルに追加することができます。

最後に、セキュリティー・マネージャーなしでプログラムを実行して、問題発生時における動作を調べてみてください。

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

以下に示すのは、

java.security

lib/security

lib\security

jdk1.3

• 
  jdk1.3/lib/security/java.security
  

  (Unix)

• 
  jdk1.3\lib\security\java.security
  

  (ウィンドウズ)

java.security

• 認証プロパティー

  • 
    login.configuration.provider
    

  • 
    login.policy.url.n
    

• 権限プロパティー

  • 
    auth.policy.provider
    

  • 
    auth.policy.url.n
    

新規の JAAS プロパティーは、このファイルの末尾に置かれます。

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

#
# 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}/jre/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

##############################################################################
#
# Java Authentication and Authorization Service (JAAS)
# properties and policy files:
#

# Class to instantiate as the system Configuration for authentication.
# This is the name of the class that will be used as the Authentication
# Configuration object.
#
login.configuration.provider=com.ibm.security.auth.login.ConfigFile

# The default is to have a system-wide login configuration file found in
# the user's home directory.  For multiple files, the format is similar to
# that of CodeSource-base policy files above, that is policy.url.n
login.config.url.1=file:${user.home}/.java.login.config

# Class to instantiate as the system Principal-based Authorization Policy.
# This is the name of the class that will be used as the Authorization
# Policy object.
#
auth.policy.provider=com.ibm.security.auth.PolicyFile

# The default is to have a system-wide Principal-based policy file found in
# the user's home directory.  For multiple files, the format is similar to
# that of CodeSource-base policy files above, that is policy.url.n and
# auth.policy.url.n
auth.policy.url.1=file:${user.home}/.java.auth.policy

付録 B: ログイン構成ファイル

LoginContext

Application {
    LoginModule Flag ModuleOptions;
    > more LoginModule entries <
    LoginModule Flag ModuleOptions;
};

login.config.url.n

java.security

java.security

Flag の値は、認証が回を重ねて進むときの全部的な動作を制御します。 以下は、Flag の有効な値と、それぞれの意味の説明を表しています。

1. Required。以下の

   
   LoginModule
   

   は、成功するために必要です。 成功した場合でも失敗した場合でも、認証は

   
   LoginModule
   

   リストを作ることです。
2. Requisite。以下の

   
   LoginModule
   

   は、成功するために必要です。 試行した場合、認証は引き続き

   
   LoginModule
   

   リストを作ることです。 失敗した場合、制御は即時にアプリケーションに戻されます (認証では

   
   LoginModule
   

   リスト)。
3. Sufficient。以下の

   
   LoginModule
   

   は成功するために必要はありません 試行した場合、制御は即時にアプリケーションに戻されます (認証は

   
   LoginModule
   

   リスト)。 失敗した場合、認証は引き続き

   
   LoginModule
   

   リストを作ることです。
4. Optional。以下の

   
   LoginModule
   

   は成功するために必要はありません 成功した場合でも失敗した場合でも、認証は

   
   LoginModule
   

   リストを作ることです。

全体の認証は、すべての Required および Requisite の LoginModules が正常に実行される場合に限り成功します。 Sufficient の

LoginModule

LoginModule

LoginModule

サンプル構成ファイル:

/*  Sample Configuration File  */

Login1 {
   com.ibm.security.auth.module.SampleLoginModule required debug=true;
};

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

ログイン 1 には、クラス

com.ibm.security.auth.module.SampleLoginModule

LoginContext

Login2 は、表を使用して説明する方が簡単です。

付録 C: 権限ポリシー・ファイル

上記のプリンシパル・ベースの JAAS ポリシーの grant ブロックの例では十分でない場合、ここにさらに説明があります。

// SAMPLE JAAS POLICY FILE:  java.auth.policy

// The following permissions are granted to Principal 'Pooh' and all codesource:

grant Principal com.ibm.security.Principal "Pooh" {
   permission javax.security.auth.AuthPermission "setPolicy";
   permission java.util.PropertyPermission "java.home", "read";
   permission java.util.PropertyPermission "user.home", "read";
   permission java.io.FilePermission "c:/foo/jaas.txt", "read";
};

// The following permissions are granted to Principal 'Pooh' AND 'Eyeore'
// and CodeSource signedBy "DrSecure":

grant signedBy "DrSecure"
      Principal com.ibm.security.Principal "Pooh",
      Principal com.ibm.security.Principal "Eyeore" {
   permission javax.security.auth.AuthPermission "modifyPublicCredentials";
   permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
   permission java.net.SocketPermission "us.ibm.com", "connect,accept,resolve";
   permission java.net.SocketPermission "griffin.ibm.com", "accept";
};

// The following permissions are granted to Principal 'Pooh' AND 'Eyeore' AND
// 'Piglet' and CodeSource from the c:\jaas directory signed by "kent" and "bruce":

grant codeBase "file:c:/jaas/*",
      signedBy "kent, bruce",
      Principal com.ibm.security.Principal "Pooh",
      Principal com.ibm.security.Principal "Eyeore",
      Principal com.ibm.security.Principal "Piglet"  {
   permission javax.security.auth.AuthPermission "getSubject";
   permission java.security.SecurityPermission "printIdentity";
   permission java.net.SocketPermission "guapo.ibm.com", "accept";
};