モジュール java.base
パッケージ javax.security.auth.login

クラスLoginContext

java.lang.Object
javax.security.auth.login.LoginContext

public class LoginContext extends Object

LoginContextクラスは、Subjectを認証するための基本的なメソッドを記述し、基本となる認証テクノロジに依存しないアプリケーション開発の方法を提供します。 Configurationは、特定のアプリケーションで使用される認証テクノロジ(LoginModule)を指定します。 このため、アプリケーション自体に変更を加えることなく、アプリケーションに異なるLoginModuleをプラグインできます。

このクラスは、プラグイン可能な認証をサポートするだけでなく、認証のスタックという概念もサポートします。 アプリケーションを、2つ以上のLoginModuleを使用するように構成できます。 たとえば、1つのアプリケーションでKerberos LoginModuleとスマート・カードLoginModuleの両方を構成できます。

呼出し側は通常、nameCallbackHandlerを指定してLoginContextをインスタンス化します。 LoginContextは、nameをConfigurationのインデックスとして使用し、使用するLoginModuleや、認証全体を成功させるために成功させなければならないLoginModuleを判定します。 CallbackHandlerはベースとなるLoginModuleに渡され、LoginModuleはユーザーとのやりとり(グラフィカル・ユーザー・インタフェースでユーザー名とパスワードの入力を求めるなど)を行います。

呼出し側がLoginContextをインスタンス化すると、loginメソッドを呼び出してSubjectの認証を行います。 loginメソッドは構成済モジュールを呼び出して、それぞれのタイプの認証(ユーザー名/パスワードを使用した認証、スマート・カードのPIN認証など)を行います。 認証に失敗しても、LoginModuleは認証を再試行しません。また、遅延時間も発生しません。 こうしたタスクは、LoginContextの呼出し側が担当します。

loginメソッドが例外をスローすることなく返れば、認証は総合的に成功したことになります。 そして、呼出し側はgetSubjectメソッドを呼び出すことで、新たに認証されたSubjectを取得できます。 Subjectと関連付けられたPrincipalとCredentialは、SubjectのgetPrincipalsgetPublicCredentials、およびgetPrivateCredentialsの各メソッドを呼び出すことで取得できます。

Subjectをログアウトさせる場合、呼出し側はlogoutメソッドを呼び出します。 loginメソッドの場合と同様、このlogoutメソッドは構成済みモジュールのlogoutメソッドを呼び出します。

1つのLoginContextで複数のSubjectを認証することはできません。 Subjectごとに別個のLoginContextを使用する必要があります。

次の内容は、すべてのLoginContextコンストラクタに適用されます。

  1. Subject
    • コンストラクタにSubject入力パラメータが指定されている場合、LoginContextは呼出し側で指定されたSubjectオブジェクトを使用する。
    • 呼出し側がnull Subjectを指定した場合で、null値が許可されているとき、LoginContextは新しいSubjectをインスタンス化する。
    • コンストラクタにSubject入力パラメータが指定されていない場合、LoginContextは新しいSubjectをインスタンス化する。
  2. Configuration
    • コンストラクタにConfiguration入力パラメータが指定されている場合で、呼出し側がnull以外のConfigurationを指定したとき、LoginContextは呼出し側で指定されたConfigurationを使用する。

      コンストラクタにConfiguration入力パラメータが指定されていない場合、または呼出し側がnull Configurationオブジェクトを指定した場合、コンストラクタは次の呼出しを使用してインストール済みのConfigurationを取得する。

            config = Configuration.getConfiguration();
       
      どちらの場合も、コンストラクタに指定されたname引数はConfiguration.getAppConfigurationEntryメソッドに渡される。 Configurationが指定されたnameのエントリを持たない場合、LoginContextは、デフォルトのエントリ名であるothergetAppConfigurationEntryを呼び出す。 otherのエントリが存在しない場合、LoginExceptionがスローされる。
    • LoginContextがインストール済のConfigurationを使用する場合、呼出し側はcreateLoginContext.nameと、場合によってはcreateLoginContext.otherというAuthPermissionを必要とする。 さらに、LoginContextはAccessController.doPrivilegedから構成済モジュールを呼び出す。これは、セキュリティ保護の必要があるタスク(リモート・ホストへの接続、Subjectの更新など)を実行するモジュールはそれぞれアクセス権を必要とするが、LoginContextの呼出し側はこれらのアクセス権なしで済むようにするためである。
    • LoginContextが呼出し側で指定されたConfigurationを使用する場合、呼出し側はcreateLoginContext AuthPermissionを必要としない。 LoginContextは呼出し側に代わってAccessControlContextを保存し、そのコンテキストの制約を課されたAccessController.doPrivileged呼出し内から構成済みモジュールを呼び出す。 つまり、呼出し側のコンテキスト(LoginContextの作成時に保存されたコンテキスト)は、モジュールが実行するセキュリティ保護を必要とするタスクの実行に必要なアクセス権を備えている必要がある。
  3. CallbackHandler
    • コンストラクタにCallbackHandler入力パラメータが指定されている場合、LoginContextは呼出し側で指定されたCallbackHandlerオブジェクトを使用する。
    • コンストラクタにCallbackHandler入力パラメータが指定されていない場合や、呼出し側がnull CallbackHandlerオブジェクトを指定し、かつnull値が許可されている場合、LoginContextはauth.login.defaultCallbackHandlerセキュリティ・プロパティに問い合わせてデフォルトのハンドラ実装の完全指定クラス名を取得する。 このセキュリティ・プロパティが設定されていない場合、ベースとなるモジュールはユーザーとの通信に使用するCallbackHandlerを持たない。 このため、呼出し側は、構成済みモジュールが別の手段でユーザー認証を行うことができると想定する。
    • 上記のように呼出し側で指定されたConfigurationを使用せず、インストール済みConfigurationを使用するLoginContextは、呼出し側で指定された(デフォルトの) CallbackHandler実装を新しいCallbackHandler実装でラップする必要がある。この新しいCallbackHandler実装のhandleメソッド実装は、呼出し側の現在のAccessControlContextによって制約を課されたjava.security.AccessController.doPrivileged呼出し内で、指定されたCallbackHandlerのhandleメソッドを呼び出す。

導入されたバージョン:
1.4
関連項目: