Java認証・承認サービス(JAAS)リファレンス・ガイド
JAASは、次の2つの目的で使用できます。
- ユーザーを認証する際、Javaコードがアプリケーション、アプレット、Bean、またはサーブレットであるかに関係なく、Javaコードを現在実行しているユーザーを確実かつセキュアに判定する。
- ユーザーを承認する際、アクションの実行に必要なアクセス制御権(アクセス権)をユーザーが保持していることを確認する。
JAASは、Javaバージョンの標準Pluggable Authentication Module (PAM)フレームワークを実装します。
これまで、Javaは、コード・ソース・ベースのアクセス制御(コードの出所および署名者に基づくアクセス制御)を提供してきました。しかし、コードの実行者に基づくアクセス制御を追加実行する機能は不足していました。JAASは、Javaセキュリティ・アーキテクチャを拡張するフレームワークにより、この機能をサポートします。
JAAS認証は、プラガブルな方式で実行されます。これにより、アプリケーションは、基盤となる認証技術から独立した状態になります。アプリケーション自体に変更を加える必要なく、アプリケーションに新規または更新された認証技術をプラグインできます。アプリケーションは、LoginContext
オブジェクトをインスタンス化することにより、認証プロセスを有効にし、LoginContextオブジェクトはConfiguration
を参照して、認証の実行で使用する認証テクノロジまたはLoginModule
を判別します。一般的なLoginModule
は、ユーザー名およびパスワードの入力を求め、検証します。音声や指紋標本を読み取り、検証できるものもあります。
コードを実行するユーザーまたはサービスが認証されると、JAAS承認コンポーネントはコアJava SEアクセス制御モデルと連動して機能し、慎重な操作の必要なリソースへのアクセスを保護します。アクセス制御の決定は、実行コードのCodeSource
、およびコードを実行しているユーザーまたはサービス(Subject
オブジェクトで表される)の両方に基づいています。認証に成功した場合、LoginModule
は、関連するPrincipal
およびクレデンシャルを使用してSubject
を更新します。
このドキュメントの対象読者
このドキュメントは、CodeSource
ベースおよびSubject
ベースのセキュリティ・モデルの制約を受けるアプリケーションを設計する必要がある上級開発者を対象としています。LoginModule開発者(認証技術を実装する開発者)は、Java Authentication and Authorization Service (JAAS): LoginModule開発者ガイドを読む前にこれをお読みください。
最初にJAAS認証チュートリアルとJAAS承認チュートリアルでJAASの使用方法の概要と有効なサンプル・コードを確認した上で、このドキュメントから詳細情報を得ることもできます。
関連ドキュメント
このドキュメントでは、読者がすでに次のドキュメントを読んでいることを前提としています。
「JAASログイン・モジュール開発者ガイド」は、認証技術を実装するLoginModule
を記述する必要がある上級プログラマ向けのドキュメントであり、このドキュメントの補足として役立ちます。
次のチュートリアルは、JAAS認証および承認を利用するすべてのユーザーを対象としています。
次のチュートリアルは、JAAS認証および承認のチュートリアルと似ていますが、Kerberos LoginModuleの使用方法の解説が含まれるため、使用する前にKerberosをインストールする必要があります。
この2つのチュートリアルは、認証とセキュアな通信のための基盤技術としてKerberosを利用するJAASおよびJava GSS-APIチュートリアルの紹介に含まれています。
コア・クラスとインタフェース
JAAS関連コア・クラスおよびインタフェースは、共通クラス、認証クラス、および承認クラスの3つのカテゴリに分類できます。
共通クラス
共通クラスは、JAAS認証および承認コンポーネントの両方に共通です。
JAASの主要クラスは、javax.security.auth.Subject
であり、これは、単一エンティティ(個人など)の関連情報のグループ化を表します。これには、エンティティのPrincipal、publicクレデンシャルおよびprivateクレデンシャルなどがあります。
プリンシパルの表現には、java.security.Principal
インタフェースが使用されます。また、JAASにより定義されるクレデンシャルには、任意のオブジェクトを指定できます。
サブジェクト
リソースへのアクセスを承認する場合、最初に、アプリケーションが要求元を認証する必要があります。JAASフレームワークでは、要求元をサブジェクトという用語で表します。サブジェクトは、個人やサービスなどの任意のエンティティです。サブジェクトが認証されると、javax.security.auth.Subject
には関連する識別情報またはプリンシパルが割り当てられます。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 class.
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
を渡すことができます。
プリンシパル
前述したように、サブジェクトが認証されると、関連する識別情報またはプリンシパルがサブジェクトに割り当てられます。サブジェクトには、多数のプリンシパルを含めることができます。たとえば、ユーザーは、他のサブジェクトと明確に区別される名前プリンシパル(「John Doe」)およびSSNプリンシパル(「123-45-6789」)を保持できます。プリンシパルはjava.security.Principalおよびjava.io.Serializableインタフェースを実装する必要があります。サブジェクトに関連付けられたプリンシパルの更新方法の詳細は、サブジェクトを参照してください。
クレデンシャル
サブジェクトは、関連付けられたプリンシパルに加え、クレデンシャルと呼ばれる独自のセキュリティ関連属性を保持できます。クレデンシャルには、新規サービスに対してサブジェクトを認証する際に使用可能な情報が含まれます。この種のクレデンシャルには、パスワード、Kerberosチケット、および公開キー証明書が含まれます。クレデンシャルには、サブジェクトによる特定操作の実行を可能にするだけのデータが含まれる場合もあります。たとえば、暗号化キーは、サブジェクトによるデータへの署名または暗号化を可能にするクレデンシャルを表します。公開および非公開クレデンシャル・クラスは、コアJAASクラス・ライブラリの一部ではありません。したがって、あらゆるクラスがクレデンシャルを表すことができます。
公開および非公開クレデンシャル・クラスは、コア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")
セキュリティ・チェックを実行し、呼出し側がクレデンシャルを破棄するためのアクセス権を保持することを確認すべきです。
認証クラスとインタフェース
認証は、サブジェクトの識別情報を検証するプロセスを表し、セキュアな方法で実行する必要があります。さもないと、悪意のあるユーザーが他のユーザーを装ってシステムへのアクセスを試みる可能性があります。通常、認証には、識別情報を証明するなんらかの形式の証拠を示すサブジェクトが含まれます。この種の証拠には、サブジェクトのみが知るか保持できる情報(パスワードや指紋など)またはサブジェクトのみが作成可能な情報(秘密キーを使用した署名付きデータなど)があります。
サブジェクト(ユーザーまたはサービス)の認証では、次の処理が行われます。
- アプリケーションが
LoginContext
をインスタンス化します。 LoginContext
が、Configuration
に問い合わせを行い、アプリケーション用に構成されたすべてのLoginModule
をロードします。- アプリケーションが、
LoginContext
のlogin
メソッドを呼び出します。 login
メソッドがロードされたすべてのLoginModule
を呼び出します。各LoginModule
はサブジェクトを認証しようとします。成功した場合、LoginModule
は、認証されるサブジェクトを表すSubject
オブジェクトに、適切なPrincipal
とクレデンシャルを関連付けます。LoginContext
が、認証ステータスをアプリケーションに返します。- 認証が成功すると、アプリケーションは
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
は、この引数をログインConfiguration
のインデックスとして使用し、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
の機能を理解していなくてもかまいません。アプリケーションを作成し、構成情報(ログイン構成ファイルの情報など)を指定し、アプリケーションが構成によって指定されたログイン・モジュールを利用してユーザーを認証できるようにするだけで十分です。
一方、認証技術を実装するLoginModuleを作成する必要があるプログラマは、Java Authentication and Authorization Service (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
のドキュメントには、このドキュメントには記載されていない大量のサンプルが記載されています。
コールバック
javax.security.auth.callback
パッケージには、コールバック・インタフェースおよびいくつかの実装が含まれています。LoginModulesは、コールバックの配列を、CallbackHandlerのhandleメソッドに直接渡すことができます。
使用方法の詳細については、各種Callback APIを参照してください。
承認クラス
JAAS承認を行うには、実行中のコードと実行ユーザーに基づいてアクセス制御権を付与し、次の作業を行う必要があります。
- 「LoginContext」セクションの説明に従ってユーザーを認証する。
- 認証の結果生成されるサブジェクトを「サブジェクト」セクションの説明に従ってアクセス制御コンテキストに関連付ける。
- 次の説明に従ってセキュリティ・ポリシー内にプリンシパルベースのエントリを構成する。
以降では、Policy
抽象クラスと承認固有のクラスAuthPermission
およびPrivateCredentialPermission
について説明します。
Policy
java.security.Policy
クラスは、システム全体のアクセス制御ポリシーを表す抽象クラスです。Policy
APIはPrincipal
ベースの問合せをサポートしています。
JDKは、デフォルトで、ファイルベースのサブクラス実装を提供します。この実装もアップグレードされ、ポリシー・ファイル内で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 APIドキュメントを参照してください。
PrivateCredentialPermission
javax.security.auth.PrivateCredentialPermission
クラスは、Subject
の非公開クレデンシャルへのアクセスを保護し、1つのpublicコンストラクタを提供します。
public PrivateCredentialPermission(String name, String actions);
JAASチュートリアルとサンプル・プログラム
「JAAS認証」および「JAAS承認」の各チュートリアルには、次のサンプルが含まれています。
SampleAcn.java
は、JAAS認証を説明するサンプル・アプリケーションです。SampleAzn.java
は、承認チュートリアルで使用されるサンプル・アプリケーションです。認証と承認の両方を説明します。- JAAS認証チュートリアルのログイン構成ファイルでは、
sample_jaas.config
(両方のチュートリアルで使用されるサンプル・ログイン構成ファイル)について説明します。 sampleacn.policy
は、認証チュートリアルのコードに必要なアクセス権を付与するサンプル・ポリシー・ファイルです。sampleazn.policy
は、承認チュートリアルのコードに必要なアクセス権を付与するサンプル・ポリシー・ファイルです。SampleLoginModule.java
は、チュートリアルのログイン構成ファイル(sample_jaas.config
)によって、基盤となる適切な認証を実装するクラスとして指定されるクラスです。SampleLoginModuleのユーザー認証は、ユーザーによって指定された名前とパスワードが特定の値を持っていることを単に検証する処理です。SamplePrincipal.java
は、Principal
インタフェースを実装するサンプル・クラスです。SampleLoginModuleによって使用されます。
アプリケーション、ポリシー・ファイル、およびログイン構成ファイルの詳細については、チュートリアルを参照してください。
チュートリアルに説明されているとおり、アプリケーション作成者はSampleLoginModule.java
やSamplePrincipal.java
のコードを理解していなくてもかまいません。LoginModulesを作成するプログラマは、Java Authentication and Authorization Service (JAAS): LoginModule開発者ガイドでその方法を確認できます。
付録A: java.securityセキュリティ・プロパティ・ファイルでのJAAS設定
java.security
マスター・セキュリティ・プロパティ・ファイル内で多数のJAAS関連設定を構成できます。このファイルは、JDKのconf/security
ディレクトリ内にあります。
JAASは、java.security
に次の2つの新しいセキュリティ・プロパティを追加します。
login.configuration.provider
login.config.url.n
次の既存のプロパティもJAASユーザーと関係があります。
policy.provider
policy.url.n
次に、これらのプロパティを構成する方法の例を示します。この例では、policy.provider
、policy.url.n
およびlogin.configuration.provider
セキュリティ・プロパティのデフォルトのjava.security
ファイル内の値はそのまま使用します。デフォルトのjava.security
ファイルでは、login.config.url.n
セキュリティ・プロパティの値も一覧表示されていますがコメント化されています。次の例ではコメント化されていません。
...
#
# Class to instantiate as the javax.security.auth.login.Configuration
# provider.
#
login.configuration.provider=sun.security.provider.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. The system class loader is used to
# locate this class.
#
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}/conf/security/java.policy
policy.url.2=file:${user.home}/.java.policy
...
注意: このファイルに対して行われる変更は、後続のJDK更新によって上書きされることがあります。ただし、システム・プロパティ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
オプションによってコマンド行から動的に指定されることもない場合、アクセス制御ポリシーは、JDKと同時にインストールされたシステム・ポリシー・ファイルのポリシーとデフォルトで同じになります。このポリシー・ファイルの特徴は次のとおりです
- 標準の拡張機能にすべてのアクセス権を付与
- 任意のユーザーが非特権ポートで待機することを許可
- 任意のコードがセキュリティ上それほど重要でない特定の「標準」プロパティ(
os.name
、file.separator
プロパティなど)を読み取ることを許可。