Java Authentication and Authorization Service (JAAS): LoginModule開発者ガイド

Overview

当初、Java認証・承認サービス(JAAS)は、Java 2 SDK, Standard Edition (J2SDK), v 1.3のオプション・パッケージでした。 JAASは、J2SDK 1.4よりJava Standard Edition Development Kitに統合されています。

JAASは、認証されたアイデンティティにおけるサブジェクトベースの認証を提供します。 このドキュメントでは、JAASの認証面、特にLoginModuleインタフェースに焦点を当てて解説します。

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

このドキュメントは、認証技術を実装するLoginModuleを記述する必要がある、経験を積んだプログラマ向けに書かれています。

関連項目

このドキュメントでは、読者がすでに次のドキュメントを読んでいることを前提としています。

JAAS APIのさまざまなクラスおよびインタフェースについての説明も含まれます。 詳細は、JAAS API仕様のjavadocを参照してください。

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

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

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

Introduction

LoginModuleドキュメントでは、認証技術のプロバイダが実装する必要のあるインタフェースについて説明します。 LoginModuleは特定タイプの認証を提供するアプリケーションへプラグインされます。

アプリケーションは LoginContextアプリケーション・プログラミング・インタフェース(API)への書込みを実行するのに対し、認証技術のプロバイダはLoginModuleインタフェースを実装します。 Configurationでは、特定のログイン・アプリケーションで使用されるLoginModuleを指定します。 アプリケーション自体を変更せずに、複数の異なるLoginModuleをアプリケーションのプラグインとして使用できます。

LoginContextは、Configurationの読取りと特定のLoginModuleのインスタンス化を行います。 各LoginModuleはSubject、CallbackHandler、共有のLoginModuleの状態、およびLoginModule固有のオプションを使ってインスタンス化されます。

Subjectは、認証中のユーザーまたはサービスを表し、認証が成功すると、関連するPrincipalおよびクレデンシャルを保持するLoginModuleにより更新されます。 LoginModuleは、loginメソッドの説明で述べるように、CallbackHandlerを使用してユーザーと通信します(ユーザー名とパスワードの入力を求めるためなど)。 CallbackHandlerはnullも指定できることに注意してください。 Subjectの認証にCallbackHandlerを必要とするLoginModuleは、nullのCallbackHandlerで初期化されていると、LoginExceptionをスローする場合があります。 LoginModuleはオプションで共有状態を使用して、それら自体の間で情報やデータを共有できます。

LoginModule固有のオプションは、ログインConfiguration内で、このLoginModule用に構成されたオプションを表します。 これらのオプションはLoginModule自体によって定義され、その中での動作を制御します。 たとえば、LoginModuleでデバッグ/テスト機能をサポートするオプションを定義する場合を考えましょう。 オプションは、debug=trueなどの、キーと値の構文を使用して定義されます。 キーを使用して値を取得できるように、LoginModuleはオプションをMapとして格納します。 LoginModuleが定義することを選択するオプションの数に制限はありません。

呼出し元アプリケーションは、認証プロセスをLoginContextのloginメソッド呼出しによって呼び出された単一の操作であると見なします。 ただし、各LoginModule内部の認証プロセスは、明確な2つのフェーズにわかれています。 最初のフェーズでは、LoginContextのloginメソッドにより、Configuration内に指定された各LoginModuleのloginメソッドが呼び出されます。 LoginModuleのloginメソッドは、実際の認証を実行してから(たとえば、パスワードの入力を促し、入力されたパスワードを検証する)、認証ステータスを非公開の状態情報として保存します。 LoginModuleのloginメソッドは終了後に、true (成功した場合)またはfalse (無視する場合)を返すか、LoginExceptionをスローして障害を指定します。 障害が発生した場合、LoginModuleは認証を再試行したり、遅延を招いたりしてはいけません。 これらのタスクの実行は、アプリケーションが担当します。 アプリケーションが認証の再実行を試みると、各LoginModuleのloginが再度呼び出されます。

次のフェーズでは、LoginContextの認証がすべて成功した(関連するrequired、requisite、sufficient、およびoptional LoginModuleのloginメソッドの呼出しに成功した)場合、各LoginModuleのcommitメソッドが呼び出されます。 LoginModuleフラグ(required、requisite、sufficient、およびoptional)については、 javax.security.auth.login.Configurationのドキュメントと『JAASリファレンス・ガイド』の「付録B: サンプル・ログイン構成」を参照してください。 LoginModuleのcommitメソッドは、非公開で保存された状態をチェックして、独自の認証が成功したかどうかを確認します。 LoginContextの認証全体が成功し、LoginModule自体の認証が成功すると、commitメソッドにより、関連するPrincipal (認証済みの識別情報)およびクレデンシャル(暗号化キーなどの認証データ)がSubjectに関連付けられます。

LoginContextの認証全体が失敗した(関連するREQUIRED、REQUISITE、SUFFICIENT、およびOPTIONAL LoginModuleのloginメソッドが成功しなかった)場合、各LoginModuleのabortメソッドが呼び出されます。 この場合、LoginModuleは、当初保存されていた認証状態をすべて削除/破棄します。

Subjectからのログアウトには、1つのフェーズのみが含まれます。 LoginContextは、LoginModuleのlogoutメソッドを呼び出します。 LoginModuleのlogoutメソッドは、ログアウト処理を実行し、PrincipalやクレデンシャルをSubjectから削除したり、セッション情報をロギングしたりします。

LoginModuleの実装ステップ

次は、LoginModuleの実装およびテストに必要なステップです。

以降では、新規LoginModuleの実装およびテストのステップを示します。 いくつかのステップで実行する内容の例については、「JAASリファレンス・ガイド」で説明されているSampleLoginModuleなどのファイルを参照してください。

ステップ1: 認証技術の理解

最初に、新規LoginModuleプロバイダが実装する認証技術について理解した上で、要件を決定します。

まず、LoginModuleがユーザーとの通信(ユーザー名とパスワードの取得など)を必要とするかどうかを決定する必要があります。 ユーザーとの通信が必要な場合は、CallbackHandlerインタフェースとjavax.security.auth.callbackパッケージに関する知識が必要です。 このパッケージには、使用できるCallback実装がいくつか含まれています。 独自のCallback実装を作成することもできます。 LoginModuleは、アプリケーション自体によって指定され、LoginModuleのinitializeメソッドに渡されたCallbackHandlerを呼び出します。 LoginModuleは、適切なCallbackからなる配列をCallbackHandlerに渡します。 ステップ3のloginメソッドを参照してください。

LoginModule実装がエンド・ユーザーと通信しない設定にすることもできます。 その場合には、LoginModuleからcallbackパッケージにアクセスする必要はありません。

他に決定すべきことは、ユーザーが使用できるようにする構成オプションであり、ユーザーは、現在のConfiguration実装で期待する形式(たとえばファイル)で構成情報を指定します。 各オプションに対して、オプション名と使用可能な値を決定します。 たとえば、LoginModuleを構成して、特定の認証サーバー・ホストへの問合わせを行う場合、オプションのキー名(「auth_server」など)およびこのオプションに指定可能なサーバー・ホスト名(例、「server_one.example.com」や「server_two.example.com」など)を決定します。

ステップ2: LoginModule実装への命名

LoginModuleの適切なパッケージおよびクラス名を決定します。

たとえば、IBMにより開発されたLoginModuleにはcom.ibm.auth.Moduleと命名できます。ここで、com.ibm.authはパッケージ名、ModuleはLoginModuleクラス実装の名前です。

ステップ3: 抽象LoginModuleメソッドの実装

LoginModuleインタフェースは、実装の必要な5つのabstractメソッドを指定します。

各メソッドの詳細については、次と「LoginModule API」を参照してください。

LoginModule実装は、これらのメソッドに加え、引数をとらないpublicのコンストラクタを提供する必要があります。 このことにより、LoginContextによるインスタンス化が適切に行われるようになります。 LoginModule実装でこの種のコンストラクタが提供されない場合、引数を取らないデフォルト・コンストラクタが自動的にObjectクラスから継承されます。

LoginModule.initializeメソッド

public void initialize (
  Subject subject,
  CallbackHandler handler,
  Map<java.lang.String, ?> sharedState,
  Map<java.lang.String, ?> options) { ... }

initializeメソッドが呼び出され、関連する認証および状態情報でLoginModuleの初期化が行われます。

このメソッドは、LoginModuleをインスタンス化したあと(かつほかのpublicメソッドを呼び出す前)、すぐにLoginContextにより呼び出されます。 このメソッド実装は、将来の使用に備えて指定された引数を格納します。

initializeメソッドはさらに、指定されたsharedStateを調べて、他のLoginModuleから提供された追加の認証状態を特定し、指定されたオプションoptionsも詳しく調べて、LoginModuleの動作に影響を与えるように指定された構成オプションを特定します。 将来の使用に備えて、変数内にオプションの値を保存することもできます。

ノート: JAASログイン・モジュールは、PAM (use_first_pass、try_first_pass、use_mapped_pass、およびtry_mapped_pass)に定義されたオプションを使って、シングル・サインオンを行います。 詳細については、「Making Login Services Independent of Authentication Technologies」を参照してください。

次は、ログイン・モジュールがサポートする一般的なオプションの一覧です。 ただし、これはガイドラインにすぎません。 モジュールは、次のオプションのサブセットを随意サポートします。

initializeメソッドは、認識できない状態やオプションを無視できます。ただし、この種のイベントが発生した場合、それを記録する方が望ましい場合もあります。

このLoginModule (およびその他の構成済みLoginModule)を呼び出すLoginContextはすべて、指定されたSubjectおよびsharedStateへの同一の参照を共有します。 SubjectおよびsharedStateへの変更は、すべてが認識します。

LoginModule.loginメソッド

boolean login() throws LoginException;

loginメソッドが呼び出され、Subjectの認証が行われます。 これが認証の第1フェーズです。

このメソッド実装は、実際の認証を実行します。 たとえば、ユーザー名およびパスワードの入力を求めてから、パスワード・データベースに対しパスワードの検証を試みます。 別のサンプル実装として、フィンガプリント・リーダーに指を挿入するようユーザーに指示し、入力されたフィンガ・プリントをフィンガプリント・データベースと照合する場合が考えられます。

LoginModuleがなんらかのユーザーとの通信の形式を必要とする(ユーザー名とパスワードの取得など)場合は、それを直接実行しないでください。 それは、ユーザーとの様々な通信方法が存在するためであり、LoginModuleが様々なユーザーとの通信のタイプから独立させておくことが望ましいです。 それよりも、LoginModuleのloginメソッドから、initializeメソッドに渡されたCallbackHandlerのhandleメソッドを呼び出して、ユーザーと通信し、適切な結果(ユーザー名、パスワードなど)を設定するようにしてください。 LoginModuleはCallbackHandlerに適切なCallback (ユーザー名に対してはNameCallback、パスワードに対してはPasswordCallback)からなる配列を渡し、CallbackHandlerは要求に従ってユーザーと通信し、Callback内に適切な値を設定します。 たとえば、NameCallbackを処理する場合、CallbackHandlerはユーザーから名前を取得し、NameCallbackのsetNameメソッドを呼び出してその名前を格納します。

認証プロセスに、ネットワーク経由の通信が含まれる場合もあります。 たとえば、このメソッド実装がKerberosのkinitと等価な機能を実行する場合、KDCとのコンタクトが必要になります。 パスワード・データベースのエントリがリモート・ネーム・サービス内に存在する場合、Java Naming and Directory Interface (JNDI)を利用するなどして、そのネーム・サービスとコンタクトを取る必要があります。 実装は、基盤となるオペレーティング・システムと通信する必要もあります。 たとえば、ユーザーがSolaris、Linux、Mac OS X、Windows NTなどのオペレーティング・システムにすでにログインしている場合、このメソッドは基盤となるオペレーティング・システムの識別情報を単にインポートします。

loginメソッドは、次の処理を行う必要があります。

  1. このLoginModuleを無視するかどうかを決定します。 たとえば、ユーザーがこのLoginModuleと無関係な識別情報を使って認証を試みた場合(たとえば、ユーザーがNISを使い、rootで認証を試みた場合)は、LoginModuleを無視する必要があります。 このLoginModuleを無視する必要がある場合、loginの戻り値はfalseになります。 それ以外の場合、次の処理を行います。
  2. ユーザーとの通信が必要な場合はCallbackHandlerのhandleメソッドを呼び出します。
  3. 認証を実行します。
  4. 認証結果(成功または失敗)を格納します。
  5. 認証に成功した場合は、関連状態情報をすべて保存します。この情報は、commitメソッドで使用される可能性があります。
  6. 認証に成功した場合はtrueを返し、認証に失敗した場合は LoginException (FailedLoginExceptionなど)をスローします。

loginメソッド実装が、新規Principalまたはクレデンシャル情報を保存済みのSubjectオブジェクトに関連付けることはできません。 このメソッドは、認証のみを実行して、認証結果および対応する認証状態を格納します。 あとで、commitまたはabortメソッドからこの結果および状態へのアクセスが行われます。 結果および状態は、ほかのLoginModuleと共有ではないので、通常、sharedState Mapには保存できません。

たとえば、LoginModuleがパスワードを共有するように構成されている場合であれば、このメソッドにとって、sharedStateのMapに状態情報を保存することは有利です。 この場合、入力されたパスワードは、共有状態として保存されます。 パスワードの共有により、パスワードを1回入力するだけで後続のLoginModuleでも認証された状態を維持できます。 次に、sharedStateのMapから名前とパスワードを格納および保存する際の標準的な規約を示します。

認証に失敗した場合、loginメソッドは認証を再試行できません。 この処理はアプリケーションが担当します。 LoginModule.login()内から何度もログインを試みるよりも、アプリケーションから繰り返しLoginContextのloginメソッドを呼び出すことをお勧めします。

LoginModule.commitメソッド

boolean commit() throws LoginException;

commitメソッドが呼び出され、認証プロセスがコミットされます。 これは、第1認証フェーズが成功した場合の第2認証フェーズです。 LoginContext全体の認証が成功した場合(関連するREQUIRED、REQUISITE、SUFFICIENT、およびOPTIONALのLoginModuleが成功した場合)に呼び出されます。

このメソッドは、loginメソッドにより保存された認証結果および対応する認証状態にアクセスします。

認証結果からloginメソッドの失敗が明らかになった場合、commitメソッドは最初に保存された対応する状態をすべて削除/破棄します。

保存された結果からLoginModuleのloginメソッドの成功が明らかになった場合は、対応する状態情報から関連するPrincipalおよびクレデンシャルの情報が構築されます。 このPrincipalおよびクレデンシャルの情報が、initializeメソッドによって格納されたSubjectに追加されます。

Principalおよびクレデンシャルの追加後は、不要な状態フィールドを迅速に破棄する必要があります。 たとえば、認証プロセスで格納されたユーザー名やパスワードは破棄されます。

commitメソッドは、コミットの成功または失敗を示す非公開の状態を保存する必要があります。

次に、LoginModuleのcommitメソッドから返される結果を図示します。 各ボックスは、発生する可能性がある各種の状況を表します。 たとえば、上部左側のボックスは、以前のloginメソッド呼び出しとcommitメソッド自体の呼出しに成功した場合に返されるcommitメソッドの結果を示しています。

LoginModule.commitメソッドの戻り値
  COMMIT: 成功 COMMIT: 失敗
LOGIN: 成功 TRUEを返す 例外をスローする
LOGIN: 失敗 FALSEを返す FALSEを返す

LoginModule.abortメソッド

boolean abort() throws LoginException;

abortメソッドが呼び出され、認証プロセスが強制的に中断されます。 これは、第1認証フェーズが失敗した場合の第2認証フェーズです。 これは、LoginContextの全体の認証に失敗した場合に呼び出されます。

このメソッドは、最初に、loginメソッド(および場合によりcommitメソッド)によって保存されているLoginModuleの認証結果および対応する認証状態にアクセスし、情報をクリアおよび破棄します。 たとえば、ユーザー名およびパスワードは破棄されます。

LoginModuleの認証に失敗した場合、非公開の状態を消去する必要は生じません。

次に、LoginModuleのabortメソッドから返される結果を図示します。 最初の図は、以前のlogin呼出しが成功したことを想定しています。 たとえば、上部左側のボックスは、以前のloginメソッド呼び出しとcommitメソッドの呼出しに成功し、さらにabortメソッド自体の呼出しにも成功した場合に返されるabortメソッドの結果を示しています。

ログイン成功時のLoginModule.abortメソッドの戻り値
  ABORT: 成功 ABORT: 失敗
COMMIT: 成功 TRUEを返す 例外をスローする
COMMIT: 失敗 TRUEを返す 例外をスローする

2番目の図は、以前のloginメソッドの呼出しに失敗した場合に返されるLoginModuleのabortメソッドの結果を示しています。 たとえば、上部左側のボックスは、以前のloginメソッド呼出しには失敗したが、commitメソッドの呼出しには成功し、さらにabortメソッド自体の呼出しにも成功した場合に返されるabortメソッドの結果を示しています。

ログイン失敗時のLoginModule.abortメソッドの戻り値
  ABORT: 成功 ABORT: 失敗
COMMIT: 成功 FALSEを返す FALSEを返す
COMMIT: 失敗 FALSEを返す FALSEを返す

LoginModule.logoutメソッド

boolean logout() throws LoginException;

logoutメソッドが呼び出され、Subjectからログアウトします。

このメソッドは、Principalを削除し、commit操作中にSubjectに関連付けられたクレデンシャルを削除/破棄します。 このメソッドは、Subject内の既存のPrincipalやクレデンシャル、またはほかのLoginModuleによって追加されたPrincipalやクレデンシャルに対しては、一切の操作を実行できません。

Subjectが読取り専用 (SubjectのisReadOnlyメソッドがtrueを返す)の場合、このメソッドはcommit操作中にSubjectに関連付けられているクレデンシャルの破棄のみを行います(クレデンシャルを削除することはできません)。 Subjectが読取り専用であり、commit操作中にSubjectと関連付けられたクレデンシャルを破棄できない(このクレデンシャルがDestroyableインタフェースを実装していない)場合、このメソッドはLoginExceptionをスローする可能性があります。

logoutメソッドは、ログアウトに成功した場合はtrueを返し、それ以外の場合はLoginExceptionをスローします。

ステップ4: サンプル・アプリケーションの選択または記述

テスト用として、既存のサンプル・アプリケーションを選択するか、新しいサンプル・アプリケーションを作成します。 アプリケーションの要件とテストに使用できるサンプル・アプリケーションについては、「JAASリファレンス・ガイド」を参照してください。

ステップ5: LoginModuleおよびアプリケーションのコンパイル

テストに使用する新しいLoginModuleおよびアプリケーションをコンパイルします。

ステップ6: テストの準備

ステップ6a: LoginModuleとアプリケーション・コードをJARファイルに配置

ステップ6cでポリシー内のJARファイルを参照できるように、LoginModuleおよびアプリケーション・コードを別々のJARファイルに格納します。 次は、JARファイルを作成するサンプル・コマンドです。 

jar cvf <JAR file name> <list of classes, separated by spaces>

このコマンドにより、指定されたクラスを含む、指定された名前のJARファイルが作成されます。

jarツールの詳細は、jar (Solaris、LinuxまたはMac OS X用、Microsoft Windows用)を参照してください。

ステップ6b: JARファイルの格納場所を決定

本来、アプリケーションはユーザーの好みの場所に格納できます。

LoginModuleも、ユーザーまたはその他のクライアントの好みの場所に格納できます。 完全に信頼できるLoginModuleは、JREのlib/ext (標準拡張)ディレクトリに格納できます。

lib/extディレクトリ内にあるLoginModuleとその他のディレクトリにあるLoginModuleを両方ともテストする必要があります。これは、LoginModuleにセキュリティ関連操作の実行に必要なアクセス権を明示的に付与しなければならない場合と、そうでない場合があるためです。

JREのlib/extディレクトリ内のLoginModuleは、インストール済み拡張機能と見なされるので、これにアクセス権を付与する必要はありません。インストール済み拡張機能には、デフォルトのシステム・ポリシー・ファイルにより、すべてのアクセス権が付与されます。

一方、それ以外のディレクトリ内のLoginModuleには、ポリシー・ファイル内のgrant文を使うなどしてアクセス権を付与する必要があります。

LoginModule JARファイルがインストール済み拡張機能と見なされない場合は、このファイルの格納場所を指定してテストします。 次のステップでは、指定された場所にあるJARファイルにアクセス権を付与します。

ステップ6c: LoginModuleとアプリケーションのJARファイルにアクセス権を設定

LoginModuleやアプリケーションが、セキュリティ・チェックをトリガーするセキュリティ関連タスク(ネットワーク接続の確立、ローカル・ディスク上のファイルの読み取り、書き込みなど)を実行するとします。これらがインストール済み拡張機能(ステップ6bを参照)ではなく、セキュリティ・マネージャがインストールされている環境で実行される場合は、アクセス権を付与する必要があります。

通常、LoginModuleはPrincipalとクレデンシャルを認証済みのサブジェクトに関連付けます。このため、LoginModuleは、アクセス権として、「modifyPrincipals」、「modifyPublicCredentials」、「modifyPrivateCredentials」というターゲット名のAuthPermissionを必要とします。

次のコード例MyLM.jarには、LoginModuleにアクセス権を付与する文が含まれています。 この種の文は、ポリシー・ファイルに記述されます。 この例では、MyLM.jarファイルは/localWorkディレクトリに格納されるものとします。 

grant codeBase "file:/localWork/MyLM.jar" {
  permission javax.security.auth.AuthPermission "modifyPrincipals";
  permission javax.security.auth.AuthPermission "modifyPublicCredentials";
  permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
};

ノート: LoginModule呼出しは、常にAccessController.doPrivileged内で行われるため、doPrivileged自体を呼び出す必要はありません。 これを呼び出すと、意図せずにセキュリティ・ホールを作り出してしまう可能性があります。 たとえば、LoginModuleがdoPrivileged呼出しの中でアプリケーション提供のCallbackHandlerを呼び出す場合、ほかの場合にはアクセス不可能なリソースへのアクセスがアプリケーションのCallbackHandlerに許可されるため、セキュリティ・ホールが作り出されます。

ステップ6d: ログイン・モジュールを参照する構成を作成

JAASはプラガブルな認証アーキテクチャをサポートするため、既存のアプリケーションを変更せずに新しいLoginModuleを使用できます。 新しいLoginModuleの使用を示すためには、ログインConfigurationを更新するだけで済みます。

OracleのデフォルトのConfiguration実装は、com.sun.security.auth.login.ConfigFile.htmlで説明するように、構成ファイルから構成情報を読み取ります。

テスト用の構成ファイルを作成します。 たとえば、以前取り上げた架空のIBMのアプリケーション用LoginModuleを構成する場合、次のような内容の構成ファイルを使用することになります。 

    AppName {
        com.ibm.auth.Module REQUIRED debug=true;
    };

AppNameは、アプリケーションがログイン構成ファイル内のこのエントリを参照するために使用する任意の名前です。 アプリケーションはこの名前をLoginContextコンストラクタの第1引数として指定します。

ステップ7: LoginModuleの試用

最後に、アプリケーションとLoginModuleの使用をテストします。 アプリケーションの実行時、使用するログイン構成ファイルを指定します。 たとえば、MyApp.jarにMyAppという名前のアプリケーションが格納されていて、構成ファイルの名前がtest.confだとします。 この場合、次のようにしてアプリケーションを実行し、構成ファイルを指定できます。 

java -classpath MyApp.jar
 -Djava.security.auth.login.config=test.conf MyApp

コマンド全体は、1行で入力してください。 ここでは、読みやすくするために複数行に分けて表示してあります。

my.policyという名前のポリシー・ファイルを指定し、インストールされているセキュリティ・マネージャを使ってアプリケーションを実行するには、次のように入力します。

java -classpath MyApp.jar -Djava.security.manager
 -Djava.security.policy=my.policy
 -Djava.security.auth.login.config=test.conf MyApp

ここでも、コマンド全体は1行で入力してください。

debugオプションを付けてLoginModuleを構成すると、適正に動作することを確認できます。

コードをデバッグし、必要に応じてテストを続行します。 問題が発生する場合は、上記のステップがすべて完了していることを確認してください。

ユーザーによる入力と、構成ファイルに指定したLoginModuleオプションを確実に変更してください。

異なったインストール・オプション(LoginModuleをインストール済み拡張機能にする、クラス・パス内に配置する、など)および実行環境(セキュリティ・マネージャを実行する、または実行しない)を使用するテストも実行してください。 インストール・オプションの詳細は、ステップ6bを参照してください。 特に、セキュリティ・マネージャがインストールされていてLoginModuleとアプリケーションがインストール済み拡張機能でない場合は、LoginModuleを確実に動作させるため、ステップ6cのようにして必要なアクセス権を付与したあと、インストールおよび実行環境をテストする必要があります。

テスト中にLoginModuleまたはアプリケーションを変更する必要が生じた場合は、適切な変更を加え、再コンパイルし(ステップ5)、変更されたコードをJARファイル内に配置し(ステップ6a)、JARファイルを再インストール(ステップ6b)します。さらに、必要に応じてアクセス権を変更または追加し(ステップ6c)、ログイン構成ファイルを変更し(ステップ6d)、アプリケーションを再実行します。そのあと、必要に応じて同じステップを繰り返します。

ステップ8: LoginModule実装のドキュメント化

次のステップでは、LoginModuleのクライアント用ドキュメントを記述します。 たとえば、次のようなドキュメントを記述できます。

ステップ9: LoginModule JARファイルおよびドキュメントの有効化

最後のステップでは、LoginModule JARファイルおよびドキュメントをクライアントから使用できるようにします。

Copyright © 1993, 2025, Oracle and/or its affiliates. All rights reserved.