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

概要

当初、Java 認証・承認サービス (Java Authentication and Authorization Service: 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 の一連のチュートリアル」に含まれています。

はじめに

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

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

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

Subject は、認証中のユーザーまたはサービスを表します。認証が成功すると、関連する Principal およびクレデンシャルを保持する LoginModule により Subject が更新されます。LoginModule は、たとえばユーザー名とパスワードを取得するために、CallbackHandler を使ってユーザーと通信します。login メソッドの解説を参照してください。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 パッケージに関する知識が必要です。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 への変更は、すべての LoginContext により認識されます。

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 や 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 が成功した場合)、commit メソッドが呼び出されます。

このメソッドは、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 認証フェーズです。abort メソッドは、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 用) (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 自体を呼び出す必要はありません。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, 2013, Oracle and/or its affiliates. All rights reserved.