ヘッダーをスキップ

Oracle Containers for J2EE セキュリティ・ガイド
10g(10.1.3.4.0)

B50832-01
目次
目次
索引
索引

戻る 次へ

13 交換可能なアイデンティティ管理フレームワーク

OC4Jには、このマニュアルですでに説明したセキュリティ・プロバイダの他に、Webベース・アプリケーションによる異機種サード・パーティのアイデンティティ管理システムの使用を汎用的にサポートするフレームワークもあります。

この章ではこのアイデンティティ管理フレームワークについて説明します。この章の内容は次のとおりです。

OracleAS JAAS Providerアイデンティティ管理フレームワークの概要

ここでは、Webアプリケーションで使用するOC4Jアイデンティティ管理フレームワークの概要を説明します。この項の内容は次のとおりです。

交換可能なアイデンティティ管理フレームワークの必要事項

前述のように、Oracle Application Serverには、Oracle Identity Management、Oracle Access Managerなど、セキュリティ・インフラストラクチャが用意されています。両方ともアイデンティティ・リポジトリが含まれています。すでに説明したように、特定の外部LDAPプロバイダ(Active DirectoryとSun Java System Directory Server)もサポートされます。

ただし、以前のリリースでは、他のサード・パーティのアイデンティティ管理システムとセキュリティ・システムをサポートする汎用的なフレームワークはありませんでした。OC4J 10.1.3.1実装には、そのようなフレームワークが追加されました。異機種サード・パーティ・システムをOC4Jに統合できるようになったため、J2EEアプリケーションがこれらのサード・パーティ・システムと相互運用できるようになりました。

アイデンティティ管理フレームワークの仕組み

ここでは、アイデンティティ管理フレームワークのコンポーネントを紹介し、コンポーネントが連携する仕組みの概要を説明します。(サード・パーティのアイデンティティ管理システムとOC4Jとの統合は、標準のJAASログイン・モジュールに基づきます。)

アイデンティティ管理フレームワークの一般的なモデルでは、コンポーネントが次の図13-1に示すように連携します。

  1. トークン・コレクタが適切なアクションを実行して、HTTPリクエストからユーザー資格証明を収集します。トークン・コレクタのインタフェースでは、資格証明を収集するメカニズムをプラグインできます。たとえば、フォームベース認証の場合、トークン・コレクタはユーザー名とパスワード入力用のログイン・ページにリダイレクトします。トークン・コレクタでは、Basic、フォームベースまたはカスタムの各認証方式を使用して、ユーザー名とパスワードまたはHTTP Cookieなど、各種の資格証明を収集できます。HTTPリクエスト・オブジェクトの一部として受信されるかぎり、X.509トークンまたはSAMLトークンも使用できます。

  2. トークン・コレクタは、指定されたトークン・タイプに応じて、ユーザー資格証明に対応する適切なアイデンティティ・トークンを作成し、そのトークンをOC4Jに渡します。通常、アイデンティティ管理フレームワークでは、トークンのタイプはユーザー・アイデンティティを含むHTTP CookieまたはHTTPヘッダーです。Cookieまたはヘッダーを使用しない場合は、HTTPリクエスト・オブジェクト自体を使用できます。この場合、アイデンティティを取得するリクエスト・オブジェクトの解析方法を実装に設定します。(たとえば、クエリー・パラメータを解析および解釈してアイデンティティを取得するなどです。)

  3. トークン・アサータは、OC4Jからアイデンティティ・トークンを受信し、アイデンティティを検証します。このとき、アイデンティティをサード・パーティのアイデンティティ管理システムと照合して認証するか、他の方法でトークンを検証します。トークン・アサータのインタフェースを使用すると、アイデンティティ・トークンのアサーション・メカニズムをプラグインできます。(たとえば、OC4J Java SSOでアイデンティティ管理フレームワークを使用する場合、アイデンティティ・トークンはCookieにエンコードされ、Cookie内の情報の検証に対称鍵が使用されます。)

    アイデンティティ管理フレームワークにおいては、アサーションとは、アイデンティティ・トークンの解釈機能、トークン内容の検証機能、およびトークンに対応するアイデンティティの設定機能のことです。パスワードや他の資格証明は必ずしも必要ありません。通常、トークンは信頼されたソースから取得されるか、鍵とともに送信されているためです。

    トークン・アサータがシングル・サインオン・システムによって認証されたアイデンティティを受け付けることができるため、シングル・サインオン・システムはカスタム・セキュリティ・プロバイダから資格証明を収集し、アイデンティティをOC4Jに渡すことができます。次に、トークン・アサータはアイデンティティを検証し、OC4Jコンテナ内にアイデンティティを設定します。

  4. アイデンティティが検証されると、トークン・アサータは構成したアイデンティティ・コールバック・ハンドラを介してユーザー情報をOC4Jに返します。この時点で、コールバック・ハンドラに渡されたアイデンティティは信頼されたアイデンティティです。コールバック・ハンドラは、アイデンティティ文字列、またはアイデンティティ文字列とリクエスト・オブジェクトなどで渡すだけで構成できます。

  5. OC4Jは、ユーザー情報とともにアイデンティティ・コールバック・ハンドラをアプリケーション用に構成されたログイン・モジュールに渡します。ログイン・モジュールは、適切なコールバック・タイプを構成してユーザー情報を処理し、コールバック・ハンドラhandle(Callback[])メソッド(標準的なログイン・モジュール機能)を介してアイデンティティ・コールバック・ハンドラに渡します。ログイン・モジュールは、必要に応じてサード・パーティのアイデンティティ管理システムから情報を取得して、ユーザーが属するロールなど、ユーザーのプリンシパルを収集します。次に、ログイン・モジュールは移入されたサブジェクトをOC4Jに送信します。

    アイデンティティはすでにトークン・アサータによって検証されているため、ログイン・モジュールで認証を再度実行する必要はありません。また、アイデンティティ管理フレームワークのカスタム・ログイン・モジュールも、アイデンティティ・コールバック・ハンドラを処理できる必要があります。

    代替方法: アプリケーションのログイン・モジュールを実装して構成するかわりに、サブジェクトを作成し、getSubject()メソッドを実装するトークン・アサータを指定して、ログイン・モジュールを使用せずに、(ユーザー・ロールを移入された)サブジェクトを直接OC4Jに返すことができます。この方法を選択する場合、アイデンティティ管理フレームワークのプロパティ(idm.subject.loginmodule.disabled)を適切に設定する必要があります。

  6. オプションでは、サブジェクト・アサータがログイン・モジュールによって伝播されたサブジェクトを検証できます。たとえば、サブジェクト・プリンシパルに署名と検証を行い、プリンシパルの認証性を保護することができます。

これらのコンポーネントにはJavaインタフェースが提供されており、必要に応じて実装してサード・パーティのアイデンティティ管理システムとOC4Jを統合することができます。

管理者は、使用する実装クラスを参照するようにOC4Jを構成し、ログイン・モジュールを構成する必要があります。

図13-1    アイデンティティ管理フレームワークのデータ・フロー


画像の説明


注意

トークン・アサータとログイン・モジュールは、異なるバックエンド・アイデンティティ・システムにアクセスできます。たとえば、トークン・アサータは、アイデンティティを検証するためにアイデンティティ管理システムにアクセスします。一方、ログイン・モジュールは、ユーザー・グループやロールなど、ユーザーに関するアプリケーション固有の追加情報を格納した、データベースなど個別のアイデンティティ・ストアにアクセスできます。この追加情報は、ユーザー用に移入されるサブジェクト内に含めることができます。(アイデンティティ・ストアとは、ディレクトリやデータベースなど、ユーザー情報を格納するリポジトリのことです。) 


関連項目

 

プログラムによるアイデンティティ管理フレームワーク実装の概要

サード・パーティのアイデンティティ管理システムをOracleフレームワークで使用するには、次のプログラムによる手順を使用します。

  1. トークン・コレクタのインタフェースを実装するトークン・コレクタ・クラスを指定します。1つのオプションとして、Oracle実装を拡張することがあります。

  2. HTTP Cookieアイデンティティ・トークン、HTTPヘッダー・アイデンティティ・トークンまたはHTTPリクエスト・アイデンティティ・トークンに対して、Oracleが提供する適切なアイデンティティ・トークン・クラスを選択します。

  3. トークン・アサータのインタフェースを実装するトークン・アサータ・クラスを指定します。

  4. アイデンティティ・コールバック・ハンドラのインタフェースを実装するアイデンティティ・コールバック・ハンドラ・クラスを指定するか、Oracle実装を使用します。

  5. ログイン・モジュールを実装します(トークン・アサータによってサブジェクトに移入し、getSubject()メソッドを実装する代替方法を使用しない場合)。ログイン・モジュールは、アイデンティティ・コールバック・ハンドラ・インスタンスを適切に処理できる必要があります。

  6. オプションでは、サブジェクト・アサータのインタフェースを実装するサブジェクト・アサータ・クラスを指定します。

    関連項目

     

アイデンティティ管理フレームワーク構成の概要

Oracleアイデンティティ管理フレームワークには次の構成が必要です。詳細は、この章で後述します。

  1. 管理者はjazn.xmlを構成して、トークン・コレクタ実装クラス、トークン・アサータ実装クラス、トークン・タイプ(HTTPヘッダーやCookieなど)などを示す、アイデンティティ管理プロパティを設定します。各プロパティは、<jazn>要素の<property>サブ要素に設定されます。

  2. 管理者は適切なログイン・モジュールを構成します(オプションで、デフォルト・ログイン・モジュールRealmLoginModuleを使用します)。構成は、system-jazn-data.xml<jazn-loginconfig>要素の下に格納されます。

  3. フレームワークを使用するアプリケーションに対して、アプリケーション・アセンブラがアプリケーションとともにパッケージ化されているorion-application.xmlファイル内に認証方式CUSTOM_AUTHを指定します。

    関連項目

     

OC4J Javaシングル・サインオンによるアイデンティティ管理フレームワークの使用

OC4J 10.1.3.1実装には、アイデンティティ管理フレームワークを使用する、代替となるJavaシングル・サインオン実装(Java SSO)がパッケージ化されています。Java SSO(詳細は、
第14章「OC4J Javaシングル・サインオン」を参照)は、使用するアイデンティティ管理システムとOC4Jの結合を解除するSSO実装です。Oracle Identity Management(Oracle Single Sign-Onに必要)やOracle Access Manager(Oracle Access Manager SSOに必要)などのような、特定のインフラストラクチャ要件はありません。

Java SSOには、Cookie資格証明を収集し、アイデンティティ・トークンをOC4Jに返すトークン・コレクタ実装、およびトークン内のアイデンティティを検証し、アイデンティティをコールバック・ハンドラでOC4Jに戻すトークン・アサータ実装が含まれています。

アイデンティティ管理フレームワークのプログラム・インタフェース

ここでは、サード・パーティのアイデンティティ管理システムとOC4Jを統合するためのインタフェース、APIおよびOracle実装について説明します。

通常、ここで説明するメソッドは、OC4Jのアイデンティティ管理フレームワークによってコールされます。

アイデンティティ・トークン・インタフェースおよびOracle実装

Oracleは、次のアイデンティティ・トークン・インタフェースを定義しています。

oracle.security.jazn.token.IdentityToken

アイデンティティ・トークン・オブジェクトにユーザー資格証明が格納されています。トークン・オブジェクトは、トークン・コレクタによって返され、トークン・アサータに渡されます。

IdentityTokenインタフェースには、次のメソッドが指定されています。

OC4Jには、次のIdentityToken実装が用意されています。

トークン・コレクタ・インタフェースおよびOracle実装

Oracleは、次のトークン・コレクタ・インタフェースを提供しています。

oracle.security.jazn.collector.TokenCollector

このインタフェースの実装を使用して、HTTPベース認証資格証明を受信し、アイデンティティ・トークンを作成します。実装クラスには、次のような機能があります。

  1. ユーザー・リクエストから資格証明を収集します。

  2. ユーザーのアイデンティティ・トークンを作成します。

  3. トークンをOC4Jに渡します。

トークン・コレクタは次の入力を取得します。

ユーザーが指定したトークンが有効でないか、トークンがないか、その他の想定されるシナリオでユーザーを適切にアサートできない場合、OC4Jはトークン・コレクタfail()メソッドをコールし、失敗の理由を渡します。こうすると、トークン・コレクタは、必要に応じたアクションを実行できます。fail()メソッドは、適切な失敗のアクションを実行するように実装されている必要があります(ユーザーをログイン・ページにリダイレクトして戻すなど)。

TokenCollectorインタフェースには、次のメソッドが指定されています。

Oracleは、次のTokenCollector実装を提供しています。

oracle.security.jazn.collector.oc4j.TokenCollectorImpl

この実装は、アイデンティティ・トークンに対するHTTP CookieまたはHTTPヘッダーの使用をサポートする抽象クラスです。2つのうちいずれかを使用する場合、TokenCollectorImplを拡張し、fail()メソッド内に適切なエラー処理を追加できます(ユーザーをログイン・ページにリダイレクトするなど)。

TokenCollectorImplgetToken()メソッドは、構成(HttpCookieIdentityTokenまたはHttpHeaderIdentityToken)に基づいて、適切なトークン・タイプを返します。

CookieまたはヘッダーのかわりにHTTPリクエスト・オブジェクト自体を使用するには、カスタム・トークン・コレクタを実装する必要があります。

トークン・コレクタは、適切なアイデンティティ・トークン・クラスのコンストラクタを使用してトークンを作成します。HttpCookieIdentityTokenHttpHeaderIdentityTokenおよびHttpRequestIdentityTokenコンストラクタは、「アイデンティティ・トークン・インタフェースおよびOracle実装」で説明します。


重要

fail()メソッドの独自の実装を指定する必要があります。このメソッドは、TokenCollectorImpl内の抽象メソッドです。 


トークン・アサータ・インタフェース

Oracleは、次のトークン・アサータ・インタフェースを提供しています。

oracle.security.jazn.asserter.TokenAsserter

このインタフェースを実装して、OC4Jによって渡されるアイデンティティ・トークンを受け付け、アイデンティティ・コールバック・ハンドラをOC4Jに返します。

OC4Jがトークン・コレクタからアイデンティティ・トークンを正常に受信すると、OC4Jはトークンをトークン・アサータに渡し、アサータはトークンのアイデンティティを検証する必要があります。

アイデンティティが正常に検証されると、ユーザーは認証済とみなされ、アイデンティティがアイデンティティ・コールバック・ハンドラとしてOC4Jに返されます。

オプションでは、トークン・アサータはアイデンティティのすべてのロールまたはグループを取得し、そのサブジェクトを移入することもできます。またはログイン・モジュールに残すこともできます。

TokenAsserterインタフェースには、次のメソッドが指定されています。

トークン・コレクタのTokenCollectorImplを拡張する場合、トークン・アサータが適用可能なアイデンティティ・トークン・メソッドを使用してトークンからアイデンティティ情報を取得する必要があります。HttpCookieIdentityTokenHttpHeaderIdentityTokenおよびHttpRequestIdentityToken内のこれらのメソッドについては、すでに説明しました。


注意

ログイン・モジュールを使用しないためには、アイデンティティ管理システムにアクセスし、サブジェクトに移入し、getSubject()メソッドを実装するトークン・アサータを実装します。この代替方法を選択する場合、アイデンティティ管理プロパティidm.subject.loginmodule.disabledを適切に設定する必要があります。 


関連項目

 

アイデンティティ・コールバック・ハンドラ・インタフェース

アイデンティティ・コールバック・ハンドラは、トークン・アサータとともに使用します。Oracleは、次のアイデンティティ・コールバック・ハンドラ・インタフェースを提供しています。

oracle.security.jazn.callback.IdentityCallbackHandler

アイデンティティ・コールバック・ハンドラは、トークン・アサータによって構成され、アサートされたアイデンティティをOC4Jに渡すために使用されます。これは、通常はログイン・モジュールにも渡されるユーザー・アイデンティティであるため、アイデンティティに対応するサブジェクトに必要に応じてプリンシパルを移入することができます。

IdentityCallbackHandlerインタフェースには、次のメソッドが指定されています。

次のような標準のコールバック・ハンドラ・メソッドもあります。

Oracleは、次のアイデンティティ・コールバック・ハンドラ実装を提供しています。

oracle.security.jazn.callback.IdentityCallbackHandlerImpl

Oracleコールバック実装

アイデンティティ管理フレームワークで使用するために、Oracleはoracle.security.jazn.callbackパッケージ内に次のコールバック実装を提供しています。

アイデンティティ・コールバック

アイデンティティ管理フレームワークで使用するために、Oracleは次のアイデンティティ・コールバック・クラスを提供しています。

oracle.security.jazn.callback.IdentityCallback

IdentityCallbackインスタンスを使用すると、アイデンティティの認証状態(認証済であるかどうか)および認証に使用される認証方式に加えて、アイデンティティ自体を取得することができます。

コンストラクタにはパラメータはありません。

IdentityCallback()

次に、アイデンティティ・コールバック・ハンドラhandle()メソッドを使用して、アイデンティティ・コールバックをコールバック・ハンドラ内に設定できます。

// In token asserter:
IdentityCallbackHandler ich = new IdentityCallbackHandlerImpl("identity");
...

// In login module:
IdentityCallback icb = new IdentityCallback();
Callback[] callback = {icb};
ich.handle(callback);

IdentityCallbackクラスには、次のメソッドがあります。

HTTPリクエスト・コールバック

HTTP CookieまたはHTTPヘッダーをトークン・タイプとして使用しないアイデンティティ管理フレームワーク実装用に、Oracleは次のHTTPリクエスト・コールバック・クラスを提供しています。

oracle.security.jazn.callback.HttpRequestCallback

HTTPリクエスト・コールバック・インスタンスを使用すると、ログイン・モジュールがリクエスト・オブジェクトから資格証明を取得し、ユーザーを認証し、ユーザーのサブジェクトに移入できます。

コンストラクタにはパラメータはありません。

HttpRequestCallback()

次に、アイデンティティ・コールバック・ハンドラhandle()メソッドを使用して、HTTPリクエスト・コールバックをコールバック・ハンドラ内に設定できます。

// In token asserter:
IdentityCallbackHandler ich = new IdentityCallbackHandlerImpl("identity");
...

// In login module:
HttpRequestCallback httpreqcb = new HttpRequestCallback();
Callback[] callback = {httpreqcb};
ich.handle(callback);

HttpRequestCallbackクラスには、次のメソッドがあります。

ログイン・モジュールの要件

一般的に、アイデンティティ管理フレームワークの実装にはカスタム・ログイン・モジュールが含まれています。アイデンティティがトークン・アサータによって正常にアサートされると、トークン・アサータはアイデンティティをアイデンティティ・コールバック・ハンドラとしてOC4Jに渡します。OC4Jはこのアイデンティティをログイン・モジュールに渡します。

JAASの典型的な使用方法では、ログイン・モジュールが、ユーザーの認証およびユーザーのサブジェクト移入という2つの重要な機能を実行します。ただし、アイデンティティ管理フレームワーク内では、ログイン・モジュールが認証を処理する必要はありません。ログイン・モジュールの重要な機能は、ユーザーのロールに関する情報を取得してサブジェクトに移入するために、必要に応じてアイデンティティ管理システムにアクセスすることです。

ログイン・モジュールとアイデンティティ管理フレームワークを併用する場合、ログイン・モジュールがユーザー名を渡すために使用されるIdentityCallbackHandlerインスタンスを処理できる必要があります。ログイン・モジュールが実行しなければならないことは、次のとおりです。

  1. OC4JからIdentityCallbackHandlerインスタンスを受信します。

  2. ユーザー情報を処理するために適切なコールバックを作成します。Cookieまたはヘッダーのトークンを使用する場合、このコールバックには、javax.security.auth.callback.NameCallbackPasswordCallbackなど、標準的なコールバックに加えて、Oracleコールバックoracle.security.jazn.callback.IdentityCallbackも含めることができます。HTTPリクエストのトークンを使用する場合、Oracleコールバックoracle.security.jazn.callback.HttpRequestCallbackを使用します。

  3. handle(Callback[])メソッドを使用して、コールバックをIdentityCallbackHandlerインスタンスに渡します。

  4. 適切なコールバックを使用してアイデンティティを取得します。

  5. アイデンティティ・システムに移動してアイデンティティのロールまたはグループを検索します。

  6. サブジェクトに移入してOC4Jに送信します。


    注意

    • カスタム・ログイン・モジュールは、アイデンティティ管理フレームワークとともに使用する必要はありません。ファイルベース・プロバイダまたはOracle Identity Managementの場合、RealmLoginModuleで十分です。サポートされる外部LDAPプロバイダの場合(Active DirectoryまたはSun Java System Directory Server)、LDAPLoginModuleで十分です。

    • ログイン・モジュールを使用しないためには、アイデンティティ管理システムにアクセスし、サブジェクト自体に移入し、getSubject()メソッドを実装するトークン・アサータをかわりに実装します。この代替方法を選択する場合、アイデンティティ管理フレームワークのプロパティidm.subject.loginmodule.disabledを適切に設定する必要があります。

     

    関連項目

     

サブジェクト・アサータ・インタフェース

オプションでサブジェクト・アサータを実装すると、トークン・アサータまたはログイン・モジュールによって移入および返されたサブジェクトを検証することができます。OC4Jは、サブジェクト・アサータが構成されている場合にそれを起動します。典型的な使用例では、サブジェクトが署名され、署名がプリンシパルとしてサブジェクトに追加され、サブジェクト・アサータが署名を確認し、検証します。

Oracleは、次のサブジェクト・アサータ・インタフェースを提供しています。

oracle.security.jazn.asserter.SubjectAsserter

SubjectAsserterインタフェースには、次のメソッドが指定されています。

アイデンティティ管理フレームワーク実装クラスのパッケージ化

アイデンティティ管理フレームワーク用に作成する実装クラスはアプリケーションの一部ではありません。また、アプリケーションとともにパッケージ化とデプロイもされていません。実装クラスを1つのJARファイルにパッケージ化し、そのJARファイルをOC4Jクラスパスに追加します。これは、共有ライブラリとして行うことができます。共有ライブラリは、それを使用とするアプリケーションによってインポートできます(「ライブラリを共有するためのタスク」を参照)。

ログイン・モジュールをアイデンティティ管理フレームワーク実装の一部として実装すると、その実装を同じライブラリ内にも、個別のライブラリとしても含めることができます。


注意

共有ライブラリの機能はOC4Jアプリケーションで使用できるJARファイルを作成する場合に適した方法ですが、別な方法としてJARファイルを次のディレクトリに配置することもできます。

ORACLE_HOME/j2ee/home/lib/ext

(この操作を行うと、ファイルがグローバルに入手可能になります。) 


アイデンティティ管理フレームワークの構成

ここではアイデンティティ管理フレームワークの構成について説明します。この項の内容は次のとおりです。

管理者はフレームワークのプロパティとログイン・モジュールを構成します。アプリケーション・アセンブラは、認証方式を設定して、フレームワークを使用するアプリケーションを構成します。


注意

デフォルトでは、単一インスタンスOC4Jインストールでは、アイデンティティ管理フレームワークの実装であるJava SSOは、事前に構成されています(「単一インスタンスOC4Jインストール用デフォルトJava SSOプロパティ設定」を参照)。 


アイデンティティ管理フレームワーク・プロパティの構成

管理者は、jazn.xmlを構成して、使用するクラス実装に適したアイデンティティ管理フレームワークのプロパティを設定します。表13-1は、アイデンティティ管理フレームワークのプロパティを示しています。

表13-1    アイデンティティ管理フレームワークのプロパティ 
プロパティ  説明 

idm.authentication.name 

これは、アイデンティティ管理フレームワークの使用方法を指定するか限定する任意の名前にすることができます。単なる参照用であり、フレームワークによって使用されることはありません。(たとえば、OC4J Java SSOの場合、規約上、これはJavaSSOに設定されます。) 

idm.token.type 

使用するアイデンティティ・トークンのタイプ。HTTP_COOKIEHTTP_HEADERまたはHTTP_REQUESTです。 

idm.token.collector.class 

トークン・コレクタ・インタフェースを実装するクラスの完全修飾名。 

idm.token.asserter.class 

トークン・アサータ・インタフェースを実装するクラスの完全修飾名。 

idm.subject.asserter.class 

サブジェクト・アサータ・インタフェースを実装するクラスの完全修飾名(必要に応じて)。 

idm.subject.loginmodule.disabled 

ログイン・モジュールを起動するかどうかを指定するブール(デフォルトではfalseであるため、ログイン・モジュールは有効になっています)。ログイン・モジュールが起動されないと、トークン・アサータがサブジェクトに移入する必要があります。 

idm.token.collector.cookie.# 

アイデンティティ情報を含むCookieの名前(複数可)。#を数値に置き換えて、idm.token.collector.cookie.1など、1つ以上を指定できます。(通常は、1つのみです。) 

idm.token.collector.header.# 

アイデンティティ情報を含むHTTPヘッダーの名前(複数可)。Cookieと同じように、#を数値に置き換えて、1つ以上を指定できます。(通常、ユーザー名とパスワードの場合は2つです。) 

<jazn>要素の<property>サブ要素内にこれらのプロパティを設定します。次に例を示します。

<jazn provider="XML" location="./system-jazn-data.xml" default-realm="jazn.com">
   ...
   <!-- properties to configure the 3rd party IDM framework -->
   <property name="idm.authentication.name" value="JavaSSO" />
   <property name="idm.token.asserter.class"
             value="oracle.security.jazn.sso.SSOCookieTokenAsserter" />
   <property name="idm.token.collector.class"
             value="oracle.security.jazn.sso.SSOCookieTokenCollector" />
   <property name="idm.token.type" value="HTTP_COOKIE" />
   <property name="idm.token.collector.cookie.1" value="ORA_OC4J_SSO"/>
   ...
</jazn>


重要

  • デフォルトでは、アイデンティティ管理フレームワークはJava SSOを使用するように構成されています(第14章「OC4J Javaシングル・サインオン」を参照)。

  • OC4JインスタンスをOracle Internet Directoryインスタンスに関連付けると、OC4J homeインスタンスのjazn.xmlファイル内にある<jazn>要素構成は再度書き込まれます。以前の設定は失われます。

  • 既存の10.1.3.0.0インストールの上にOC4J 10.1.3.1パッチをインストールする場合、(10.1.3.1フレッシュ・インストールとは異なり)、デフォルト構成は適していません。jazn.xmlのプロパティが参照されないためです。この場合、前述の構成をjazn.xmlに手動で追加します。

 

アイデンティティ管理フレームワーク・ログイン・モジュールの構成

一般的にカスタム・ログイン・モジュールを使用することを想定しますが、その場合はモジュールを構成する必要があります。アプリケーションのデプロイメント時またはその後にApplication Server Controlを使用して、カスタム・ログイン・モジュールを構成できます(「Application Server Controlでのカスタム・セキュリティ・プロバイダの構成」を参照)。(OracleAS JAAS Provider Admintoolには、「Admintoolを使用したログイン・モジュールの構成とRMIパーミッションの付与」に記載されているように、ログイン・モジュール構成用のオプションもあります。)

構成は、system-jazn-data.xmlファイルに格納されます。次に、アプリケーションmyappとともに使用されるカスタム・ログイン・モジュールCustomLMの例を示します。

<jazn-loginconfig>
   <application>
      <name>myapp</name>
      <login-modules>
         <login-module>
            <class>mypackage.CustomLM</class>
            <control-flag>required</control-flag>
            <options>
               <option>
                  <name>addAllRoles</name>
                  <value>true</value>
               </option>
            </options>
         </login-module>
      </login-modules>
   </application>
</jazn-loginconfig>

関連項目

 

アイデンティティ管理フレームワークを使用するアプリケーションの構成

アプリケーションでアイデンティティ管理フレームワークを使用する場合、アプリケーション・アセンブラがorion-application.xmlファイルの<jazn-web-app>要素内に認証方式CUSTOM_AUTHを指定する必要があります。次に例を示します。

<jazn provider="XML" ... >
   ...
   <jazn-web-app auth-method="CUSTOM_AUTH" />
   ...
</jazn>

これにより、jazn.xmlのフレームワーク・プロパティの構成、およびsystem-jazn-data.xml(該当する場合)のログイン・モジュールの構成に基づいて、アイデンティティ管理フレームワークの使用がトリガーされます。


重要

Application Server Controlを介して任意の時点で任意のアプリケーションに対してファイルベース・プロバイダからOracle Identity Managementに切り替えると、そのアプリケーションのorion-application.xml内にある<jazn>要素が次のように置き換えられます。アイデンティティ管理フレームワークのCUSTOM_AUTH設定は失われ、再設定が必要になります。

<jazn provider="LDAP" />
 


注意

  • <jazn-web-app>要素も、特定のWebアプリケーションに対して、<orion-web-app>のサブ要素としてorion-web.xmlファイルでサポートされます。この設定は、Webアプリケーションのorion-application.xml設定よりも優先されます。

  • orion-application.xmlまたはorion-web.xml内の認証方式設定は、web.xml内の認証方式設定よりも優先されます。

 

複数OC4Jインスタンスの場合の考慮事項

複数のOC4Jインスタンスを使用するインストール・タイプの場合、インスタンス間でアイデンティティ管理フレームワークの構成が複製されている必要があります。これには、jazn.xml内のアイデンティティ管理フレームワーク・プロパティ設定、およびsystem-jazn-data.xml内のログイン・モジュール構成(該当する場合)が含まれています。必要に応じて次の手順を実行します。

  1. 各OC4Jインスタンスに同じセキュリティ・プロバイダ構成を繰り返します。

  2. OC4Jグループ機能を使用してsystem-jazn-data.xml更新を調整します。これにより、各system-jazn-data.xmlファイルがOC4Jインスタンスのグループ内で更新されます。これには、ファイルベース・セキュリティ・プロバイダを使用する場合のユーザー設定も含まれます。「クラスタMBeanブラウザの機能およびJ2EEServerGroup MBean」では、OC4Jインスタンス間で各system-jazn-data.xmlファイルの設定を調整する方法について説明します。インスタンス間でログイン・モジュール構成をメンテナンスする操作もあります(setLoginModuleなど)。

  3. 必要に応じて、各OC4Jインスタンスに移動し、適宜Application Server Controlを使用するか手動で構成を繰り返します。一般に、アイデンティティ管理フレームワーク設定など、jazn.xmlファイルのプロパティ設定に対しては、各OC4Jインスタンスのjazn.xmlを手動で構成することが唯一のオプションです。

    関連項目

    • OC4Jグループ機能の追加情報は、Application Server Controlオンライン・ヘルプのグループOC4Jインスタンスのページに関するトピックを参照してください。

     

アイデンティティ管理フレームワーク使用方法の概要

ここでは、これまでに説明したアイデンティティ管理フレームワークの使用に関連する重要な作業をまとめます。

  1. インテグレータ(いくつかのサード・パーティのアイデンティティ管理システムをOC4Jに統合する開発者)は、必要に応じて、アイデンティティ管理フレームワーク・コンポーネント、トークン・コレクタ、アイデンティティ・トークン、トークン・アサータ、アイデンティティ・コールバック・ハンドラおよびサブジェクト・アサータのクラスを実装します。

  2. インテグレータは、必要に応じてカスタム・ログイン・モジュールを開発します。

  3. インテグレータは、実装クラスをJARファイルにパッケージ化し、ログイン・モジュールを同じJARファイルまたは個別のJARファイルにパッケージ化します。

  4. インテグレータまたは管理者は、各JARファイルを共有ライブラリとしてターゲット・システムにデプロイします。

  5. アプリケーションは、アイデンティティ管理フレームワークを使用するように有効化されます。これは、デプロイメント前に、アセンブラが、アプリケーションとともにパッケージ化されているorion-application.xmlファイルの<jazn-web-app>要素内にある設定auth-method="CUSTOM_AUTH"で行うことができます。

  6. アプリケーションのデプロイヤは、Application Server Controlを使用してアプリケーションをデプロイします。これには、カスタム・ログイン・モジュールを構成すること、および実装クラスから成る共有ライブラリをインポートすることが含まれています(カスタム・ログイン・モジュールは、後で管理者が構成することもできます)。

  7. ターゲット・システム上で、管理者がjazn.xmlファイルのアイデンティティ管理フレームワーク・プロパティを構成します。

サンプル使用例: ヘッダーベース・アイデンティティ・トークンの使用

このサンプルの前提事項は、認証でユーザーがカスタム・アイデンティティ・ストアと照合されることです。次に、ログインしたユーザーのアイデンティティを含むカスタムHTTPヘッダー(Acme-Custom-Auth)がリクエストに追加されます。サンプルのコンポーネントは次のように機能します。

対応する構成は、jazn.xmlに示されているようになります。

サンプルのトークン・コレクタ: CollectorImpl.java

ここには、サンプルのトークン・コレクタ実装用コードを示します。

package com.acme.idm;
 
import java.io.IOException;
 
import java.util.List;
import java.util.Map;
import java.util.Properties;
 
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
 
import oracle.security.jazn.collector.CollectorException;
import oracle.security.jazn.collector.oc4j.TokenCollectorImpl;
import oracle.security.jazn.token.HttpHeaderIdentityToken;
import oracle.security.jazn.token.IdentityToken;
import oracle.security.jazn.token.TokenNotFoundException;
import oracle.security.jazn.collector.IdmErrorConstants;
 
 
public class CollectorImpl extends TokenCollectorImpl {
    public CollectorImpl() {
    }
 
    public IdentityToken getToken(String tokenType, 
                                  HttpServletRequest request,
                                  List tokenNames,
                                  Properties properties) 
                                             throws CollectorException,
                                                                TokenNotFoundException 
{
        if (null == tokenType || 0 == tokenType.length() ||
            !IdentityToken.HTTP_HEADER.equalsIgnoreCase(tokenType)) {
            throw new CollectorException("invalid token type" + tokenType);
        }
 
        HttpHeaderIdentityToken identityToken =
            (HttpHeaderIdentityToken)super.getToken(tokenType, 
                                                    request,
                                                    tokenNames,
                                                    properties);
        Map m = identityToken.getHeaderValues(); 
        
        if (m == null || m.size() == 0) {
            throw new TokenNotFoundException("no HTTP Header token was found");
        }
        
        return identityToken;
    }
 
    public void fail(HttpServletRequest httpServletRequest,
                     HttpServletResponse httpServletResponse, int reason) {
        try {
            switch (reason) {
                case IdmErrorConstants.REASON_INVALID_USER:
              httpServletResponse.sendError(HttpServletResponse.SC_UNAUTHORIZED);
                case IdmErrorConstants.REASON_UNAUTHORIZED:
              httpServletResponse.sendError(HttpServletResponse.SC_FORBIDDEN);
            }
        } catch (Exception e) {
            System.err.println("failed to send response " + e);
            e.printStackTrace(System.err);
        }
    }
}

サンプルのトークン・アサータ: TokenAsserterImpl.java

ここには、サンプルのトークン・アサータ実装用コードを示します。

前提事項は、すべての認証済ユーザーに対して、Oracle HTTP ServerまたはOC4Jのフロントにある他のWebサーバーが"Acme-Custom-Auth"を"ANONYMOUS"に設定することです。Acme実装には、ユーザーが認証されることが必要です。(本番環境に近い実装では、ヘッダーでクリアなユーザー名を渡さない可能性が高いと考えられます。ヘッダーが生成された場合に検証する方法がないためです。)

package com.acme.idm;
 
import java.util.Map;
import java.util.Properties;
 
import oracle.security.jazn.asserter.AsserterException;
import oracle.security.jazn.asserter.TokenAsserter;
import oracle.security.jazn.callback.IdentityCallbackHandler;
import oracle.security.jazn.callback.IdentityCallbackHandlerImpl;
import oracle.security.jazn.token.IdentityToken;
import oracle.security.jazn.token.HttpHeaderIdentityToken;
 
public class TokenAsserterImpl implements TokenAsserter {
    private static final String HEADER_NAME = "Acme-Custom-Auth";
    private static final String AUTH_TYPE = "CUSTOM_HTTP_HEADER";
    public TokenAsserterImpl() {
    }
 
    public IdentityCallbackHandler assertIdentity(String tokenType,
                                                  IdentityToken identityToken,
                                                  Properties properties) 
                                                  throws AsserterException {
        if (tokenType != null &&
            tokenType.length() > 0 &&
            IdentityToken.HTTP_HEADER.equalsIgnoreCase(tokenType)) {
            HttpHeaderIdentityToken token = 
                                          (HttpHeaderIdentityToken) identityToken;
            Map m = token.getHeaderValues();
            if (m != null && m.size() > 0) {
                String user = (String) m.get(HEADER_NAME);
                if ("ANONYMOUS".equalsIgnoreCase(user)) {
                    throw new AsserterException
                                      ("anon user - expected authenticated user");
                }
                IdentityCallbackHandler idcb = 
                                            new IdentityCallbackHandlerImpl(user);
                idcb.setIdentityAsserted(true);
                idcb.setAuthenticationType(AUTH_TYPE);
                
                return idcb;
            }
            else {
                throw new AsserterException
                                  ("not a valid token - no identity to assert");
            }
        }
    }
}

サンプル構成: jazn.xml

ここには、このサンプル用jazn.xmlファイルの構成を示します。

<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<jazn xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:noNamespaceSchemaLocation=
                         "http://xmlns.oracle.com/oracleas/schema/jazn-10_0.xsd" 
    schema-major-version="10" schema-minor-version="0" 
    provider="XML" location="./system-jazn-data.xml" 
    default-realm="jazn.com" >
        <property name="idm.token.asserter.class"
                  value="com.acme.idm.TokenAsserterImpl" />
        <property name="idm.token.collector.class"
                  value="com.acme.idm.CollectorImpl" />
        <property name="idm.token.type" value="HTTP_HEADER" />
        <property name="idm.token.collector.header.1" value="Acme-Custom-Auth" />
        <property name="idm.authentication.name" value="Acme-IDM" />
</jazn>

戻る 次へ
Oracle
Copyright © 2003, 2008 Oracle Corporation.

All Rights Reserved.
目次
目次
索引
索引