| Oracle Access Manager IDおよび共通管理ガイド 10g（10.1.4.3） B55478-01 |
|
 戻る |
 次へ |
この章では、複数の言語の構成方法や、ディレクトリとデータベース・サーバーの構成方法など、Oracle Access Managerの基本機能に関連するタスクについて説明します。
また、この章では、アイデンティティ・システム・アプリケーションの外観と機能を制御する方法についても説明します。たとえば、検索ベースとスタイルシートを使用して、ユーザーに表示する項目や、アイデンティティ・システム・アプリケーションで実行可能なアクションを制御できます。パフォーマンスを向上するために、別のアイデンティティ・サーバーまたはWebパスを追加することも可能です。
これらのタスクを円滑に管理するため、「アイデンティティ・システム管理者の指定」の手順に従って他のOracle Access Manager管理者およびマスターID管理者を指定できます。
この章の内容は次のとおりです。
コンポーネントのクローニングと同期化
|
注意: アイデンティティ・システムを構成するには、マスター管理者である必要があります。この章のほとんどのタスクは、アイデンティティ・システム・コンソールを通じて実行します。 |
「トランスポート・セキュリティ・モードの変更」、「.NET機能の実装」、「ロギング」、「監査」および「SNMPモニタリング」も参照してください。
スタイルを使用すると、アイデンティティ・システム・アプリケーション全体の外観を変更することや、その機能を制限することができます。スタイルは、スタイルシート、グラフィック・ファイル、およびシステムの特定のユーザー・インタフェースを定義するスクリプトを組み合せて名前を付けたものです。スタイルは、アプリケーション・ページの各要素の外観を定義するスタイルシートに基づきます。スタイルには、フィールドと機能の名前、タブやボタンの色、形状、サイズを指定するためのGIFイメージ、およびタブやボタンの名前に使用されるフォントが含まれます。
スタイルには、整形用と機能用があります。整形用のスタイルでは、色などのアイデンティティ・システム・アプリケーションの外観またはタブの外観を決定します。機能用のスタイルでは、アイデンティティ・システム・アプリケーションの機能を決定します。つまり、アイデンティティ・システム・アプリケーション・ページの特定の機能を追加、変更または削除できます。たとえば、3つのすべてのアイデンティティ・システム・アプリケーションから「代替権限」機能を削除できます。アイデンティティ・システムには、クラシック・スタイルというデフォルト・スタイルが付属していますが、PresentationXMLを使用して他のスタイルを開発し、アイデンティティ・システムの外観を変更できます。
アイデンティティ・システム・コンソールの「スタイルのカスタマイズ」オプションを使用すると、デフォルト・スタイルの設定、スタイルの作成、スタイルの変更、またはスタイルの削除を行うことができます。ただし、アイデンティティ・システム・コンソールを通じてスタイルを作成または変更する場合、システムにより既存のスタイルシートがコピーされ、その名前が変更されます。スタイルシートを開いて、手動で必要な変更を加える必要があります。
スタイルシートを作成および変更する方法の詳細は、『Oracle Access Managerカスタマイズ・ガイド』のPresentationXMLによるGUIの設計に関する内容を参照してください。
|
注意: 変更できるのは、アイデンティティ・システム・アプリケーション・ページの外観のみです。システム・コンソールでは、変更不可能なスタイル設定が使用されます。 |
この項には、次の各項目が含まれます。
現在構成されているスタイルを表示するには、次の手順を使用します。これにより、スタイル関連の操作手順の開始ポイントとなる「スタイルのカスタマイズ」ページに進みます。
アイデンティティ・システム・コンソールで、「システム構成」を選択します。
「システム構成」ページの左側のナビゲーション・ペインで、「スタイル」を選択します。
「スタイルのカスタマイズ」ページが表示されます。次の例では、アイデンティティ・システムにデフォルトで付属するクラシック・スタイルが表示されています。
スタイルのリンクをクリックし、スタイルのパラメータを表示します。
スタイル名、スタイル・ファイルの格納ディレクトリ、およびスタイル・ファイルのソース（「コピー元」フィールド）が表示されます。
アイデンティティ・システムには、クラシック・スタイルというデフォルトの表示スタイルが初めから付属しています。IdentityServer_install_dir/identity/oblix/lang/en-us/style0ディレクトリには、クラシック・スタイルのXSLラッパー・スタイルシート・ファイルが含まれます。これらのファイルの大部分は、IdentityServer_install_dir/identity/oblix/lang/sharedディレクトリに含まれるすべての言語のグローバル共有スタイルシート・テンプレート・ファイルを参照します。
ユーザー・アプリケーションのためにアイデンティティ・システム・ページの表示用カスタム・スタイルを作成するプロセスは、この項で説明するとおりアイデンティティ・システムに新規スタイルを追加することから始めます。その結果、XSLラッパー・スタイルシート・ファイルを含む新規カスタム・スタイル・ディレクトリが作成されます。その後、既存のスタイルをコピーして変更するか、新規スタイルシートに基づいて完全に新しいスタイルを作成します。
|
注意: 変更できるのは、ユーザー・アプリケーションのスタイルのみです。システム・コンソールでは、常にデフォルト・スタイルが使用されます。 |
どちらの場合でも、アイデンティティ・システムにスタイル（およびカスタム・スタイル・ディレクトリ）を追加するときには同じ方法を使用します。つまり、スタイル名と、スタイル・ファイル用のディレクトリ名を指定します。新規スタイルの基盤とする既存のスタイルを選択することも可能です。デフォルトとして新規スタイルを選択したら、アイデンティティ・システムのスタイルシートのコピーをカスタマイズするか、独自のスタイルシートを作成します。このプロセスを完了するには、独自の新規スタイルシートおよびGIFをすべてのアイデンティティ・サーバー・コンピュータとWebパス・ホスト・コンピュータにそれぞれコピーする必要があります。
最初の新規スタイルを追加する前に、次のいくつかの点に留意してください。
複数の言語: 複数の言語をサポートするために、アイデンティティ・システムには、インストール済の言語ごとに特定の名前付きディレクトリが存在します。たとえば、/lang/en-usはデフォルトの英語用言語ディレクトリであり、/lang/fr-frはフランス語用ディレクトリです。アイデンティティ・システムのデフォルト・スタイル・ディレクトリとカスタム・スタイル・ディレクトリは、どちらもインストール済の各言語ディレクトリ内に格納されます。
たとえば、フランス語言語パックをインストールしているとします。この場合、lang/en-usディレクトリとlang/fr-frディレクトリの両方に/style0ディレクトリが含まれます。アイデンティティ・システムにスタイルを追加すると、次のように新規スタイル・ディレクトリがlang/en-usディレクトリとlang/fr-frディレクトリの両方に追加されます。
IdentityServer_install_dir/identity/oblix/lang/en-us/NewStyle
IdentityServer_install_dir/identity/oblix/lang/en-us/style0
IdentityServer_install_dir/identity/oblix/lang/fr-fr/NewStyle
IdentityServer_install_dir/identity/oblix/lang/fr-fr/style0
スタイル名: アイデンティティ・システムでは、ユーザーが指定したスタイル名が内部的に使用されます。ベスト・プラクティスとして、スタイル名はカスタム・スタイル・ディレクトリ名と一致させてください。これにより、識別が容易になります。名前には、空白、&、*またはカッコ()を含めることはできません。
スタイル・ディレクトリ名: ユーザーが指定したディレクトリ名は、関連するラッパー・スタイルシート・ファイル用のディレクトリを作成するのに使用されます。この名前は、スタイル名と同一で、同じネーミング規則に準拠している必要があります。
また、カスタム・スタイル・ディレクトリ名は、新規スタイルのステータスとコピー元を識別するために作成されるXML文書（style0.xmlの複製）にも割り当てられます。たとえば、新規ディレクトリの名前がPastelである場合、次のファイルが作成されて格納されます。
IdentityServer_install_dir/identity/oblix/config/style/Pastel.xml
その他のファイルはこのプロセスでは作成されません。ただし、styles.xmlファイルは、設定したディレクトリ、スタイル名およびディレクトリ名を指定するNameValPairを含むように更新されます。たとえば、次のようになります。
IdentityServer_install_dir/identity/oblix/config/style/styles.xml
config/styleのスタイル情報ファイルは、Webパスには含まれません。詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
既存のスタイルからのコピー: 既存のスタイル・ディレクトリからスタイルシートをコピーできます。または、「なし」を選択して既存のスタイルに基づかないスタイルを構築するか、選択したスタイルシートのみをカスタマイズすることが可能です。
|
注意: 最初にスタイルを追加する場合、使用可能な唯一のスタイルは、デフォルトのクラシック・スタイルです。 |
「なし」の選択: 「なし」を選択した場合、作成されるディレクトリは空のため、新規スタイル用のスタイルシートのセットを手動で作成するか、操作するファイルを/style0ディレクトリから選択的にコピーする必要があります。
「なし」を選択すると、新規スタイルのステータスは、スタイルを選択するまでアイデンティティ・システム内で「作成中」と表示されます。空のスタイル・ディレクトリが自動的に作成され、style0.xmlの複製がIdentityServer_install_dir/identity/oblix/config/style/style0.xmlとして作成されます。
スタイルの選択: コピー元のスタイルを選択した場合、コピー元のディレクトリの複製が、指定したカスタム・ディレクトリ名で作成されます。コピーしたファイルでは、コピー元のディレクトリ（/style0またはコピー元として選択したカスタム・スタイル）に対する相対参照が保持されます。
カスタマイズ時には、新規スタイル・ディレクトリに含まれる変更されたバージョンのスタイルシートを指し示す参照を更新するだけで済みます。
結果: Pastelという新規スタイルをPastelというディレクトリに追加し、デフォルトのクラシック・スタイルからコピーするとします。この場合、次のように各langTagディレクトリ内にPastelディレクトリが作成され、クラシック・スタイルのディレクトリである/style0からの複製ファイルが格納されます。
IdentityServer_install_dir/identity/oblix/lang/en-us/Pastel
クラシック・スタイルのディレクトリである/style0は、次のようにそのまま残ります。
IdentityServer_install_dir/identity/oblix/lang/en-us/style0
また、新規スタイルがデフォルトとして選択されると、ユーザーが作成したディレクトリの名前に基づいてstyle0.xmlの複製であるXML文書が作成され、次のようにconfig/styleにstyle0.xmlとともに格納されます。
IdentityServer_install_dir/identity/oblix/config/style/Pastel.xml
IdentityServer_install_dir/identity/oblix/config/style/Pastel.xml.lck
追加情報と各種ファイルの内容は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
アイデンティティ・システム・コンソールで、「システム構成」を選択し、次に「スタイル」を選択して「スタイルのカスタマイズ」ページを表示します。
「スタイルの追加」ボタンをクリックし、「スタイルの追加」ページを表示します。
「スタイルの追加」ページの各フィールドに値を入力します。たとえば、次のようになります。
名前: Pastel
ディレクトリ名: Pastel
|
注意: ここで指定するスタイル名は、アイデンティティ・システムにより内部的に使用されるため、指定するディレクトリ名と一致させる必要があります。 |
「コピー元」フィールドで、既存のスタイルを選択して新規スタイルのテンプレートとして使用します。
たとえば、次のようになります。
Classic Style
「保存」をクリックして新規スタイルを保存します。
「スタイルのカスタマイズ」ページに新規スタイル名がリストされます。新規ラッパー・スタイルシートを格納するために1つ以上のディレクトリが作成されます。
次のように新規スタイルをデフォルト・スタイルとして選択します。
「デフォルト・スタイルの設定」ボタンをクリックして「デフォルト・スタイルの設定」ページを表示します。
新規スタイル名の横の「デフォルトに設定」ボタンをクリックし、次に「保存」をクリックします。
ファイル・システムで、指定した新規スタイル・ディレクトリ名を確認します。
次に、スタイルをカスタマイズします。アイデンティティ・システムページのカスタマイズ、スタイルのコピー、スタイルのテストおよび伝播の詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
次の手順により、エンド・ユーザーがスタイルを使用できるようにします。
次のように、ユーザーがアイデンティティ・システムを表示する最初のページのURLに、スタイルシートを含むディレクトリ名を追加します。
&style=directory_name
ここで、directory_nameは、アイデンティティ・システムのスタイルシートを含むディレクトリの名前です。
スタイルのテストおよび伝播の詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
次の手順を使用してスタイル名を変更できます。
アイデンティティ・システム・コンソールで、「システム構成」を選択し、次に「スタイル」を選択して「スタイルのカスタマイズ」ページを表示します。
「スタイルのカスタマイズ」ページで、変更するスタイルの名前をクリックします。
「スタイルの表示」ページが表示されます。
「変更」をクリックします。
「スタイルの変更」ページが表示されます。
スタイル名を変更します。
「保存」をクリックして変更を保存します。
「スタイルの表示」ページに新規スタイル名が表示されます。
アイデンティティ・システムに付属のデフォルト・スタイルであるクラシック・スタイルは、アイデンティティ・システムにより使用されるため変更できません。ただし、ユーザーが作成したカスタム・スタイルは変更可能です。
『Oracle Access Managerカスタマイズ・ガイド』の「PresentationXMLを使用したGUIの設計」の章の説明に従って、対応するスタイルシートを変更します。
変更が完了したら、そのスタイルシートを各アイデンティティ・サーバーと、スタイルシートが変更されたアイデンティティ・サーバーにリンクする各Webパスにコピーします。
アイデンティティ・システムに付属のデフォルト・スタイルであるクラシック・スタイルは、アイデンティティ・システムにより使用されるため削除できません。ただし、ユーザーが作成したカスタム・スタイルは削除可能です。
「スタイルのカスタマイズ」ページで、スタイルの名前をクリックします。
「スタイルの表示」ページが表示されます。
「削除」をクリックします。
プロンプトが表示されたら、削除を確認します。
「スタイルのカスタマイズ」ページが再表示されます。
他のすべてのアイデンティティ・サーバーおよびWebパス・インストール領域の新規スタイル・ディレクトリから新規スタイルシートを削除します。
『Oracle Access Managerインストレーション・ガイド』の説明にあるとおり、英語の言語は自動的にインストールされます。ただし、Oracleに付属する1つ以上の言語パックをインストールできます。言語パックにより、『Oracle Access Manager概要』に指定されている言語でエンド・ユーザーおよび管理者にローカライズされた情報を提供できます。
一部の表示名および属性は、アイデンティティ・システム・アプリケーション（ユーザー・マネージャ、グループ・マネージャおよび組織マネージャ）と管理者アプリケーション（アイデンティティ・システム・コンソール、アクセス・システム・コンソールおよびポリシー・マネージャ）のエンド・ユーザーに表示されます。
Oracle Access Managerでは、エンド・ユーザーに対して静的アプリケーション・データ（エラー・メッセージ、およびタブ、パネル、属性の表示名など）をサポート対象のエンド・ユーザー言語で表示できます。管理情報は、サポート対象の管理者言語でのみ表示できます。
インストールおよび設定後に、使用する言語を構成して属性の表示名をローカライズする必要があります。この作業は、次のレベルで実行します。
オブジェクト・クラス・レベル
タブ・レベル
パネル・レベル
検索結果属性レベル
|
注意: 表示名は、最上位レベルであるオブジェクト・クラス・レベルで構成することをお薦めします。これより下位のレベルで表示名を構成する場合は、必ず各レベルですべての言語の表示名を指定してください。 |
Oracleに付属する1つ以上の言語パックを使用してOracle Access Managerをインストールおよび設定します（『Oracle Access Managerインストレーション・ガイド』を参照してください）。
使用するインストール済言語を有効化します（「複数言語の管理」を参照してください）。
手動でラベルと属性の表示名を入力し、インストール済言語を使用するようアプリケーションを構成します。たとえば、次の作業を実行します。
オブジェクト・クラス属性のローカライズ（「属性表示名のローカライズ」を参照）。
タブ、グループ・タイプ・パネル、検索結果属性およびレポートの表示名のローカライズ（「ユーザー・マネージャ、グループ・マネージャおよび組織マネージャの構成」を参照）。
ワークフロー・パネル名のローカライズ（「ワークフロー・パネルのローカライズ」を参照）。
他の言語で表示するためのタブ名のローカライズ（「タブのローカライズ」を参照）。
検索結果属性のローカライズ（「検索結果に表示される属性の表示、変更およびローカライズ」を参照）。
複数の言語をインストールして構成している場合、アイデンティティ・システム・コンソール、アクセス・システム・コンソールおよびポリシー・マネージャの管理情報に使用する言語を指定できます。この操作は、ブラウザで実行します。詳細は、使用しているブラウザのドキュメントを参照してください。
管理情報に対応していない言語で管理ページがリクエストされた場合、製品のインストール時に選択されたデフォルト言語が管理ページの表示に使用されます。
インストール済言語を有効化し、インストール済言語を使用するよう属性を構成すると、エンド・ユーザーに対してアプリケーション・ページを表示するための言語が次の評価順序に従って選択されます。
評価順序
URLに指定された言語。
ユーザーは、URLに言語を指定できます。たとえば、ユーザー・マネージャで「ユーザーの作成」機能を選択する場合、ユーザーはlang=fr-frを追加することで「ユーザー・マネージャ」ページをフランス語で表示できます。アプリケーションでは、リソースのURLに指定された言語プリファレンスが最初に検索されます。ユーザーまたは管理者は、URLにlang=languageTagを追加して言語を指定できます（languageTagはRFC 1766形式の言語タグです）。
次の例では、「ユーザー・プロファイルの作成」ページがフランス語で表示されます。
http://localhost/identity/oblix/apps/userservcenter/bin/userservcenter.cgi? program=workflowCreateProfile&tab_id=employees&lang=fr-fr
ObTEMC CookieのLangCookieというパラメータに格納された言語。
前の手順のようにURLに言語を指定すると、その言語はLangCookieパラメータに設定されます。ObTEMC Cookieは、ユーザーのログイン時に作成され、ユーザーのセッション期間中は維持されます。URLに言語指定が含まれない場合、アプリケーションでは、セッション期間中に維持されるObTEMC Cookieがチェックされます。ObTEMC Cookieは、フォームまたはページにも設定できます。
HTTPヘッダー変数のHTTP_OBLIX_LANGに指定された言語。
認証または認可成功ヘッダー変数を作成してこの値を含めることができます。『Oracle Access Managerアクセス管理ガイド』の認証と認可に関する章の説明を参照してください。HTTP_OBLIX_LANGヘッダー変数の名前を変更する場合、次のファイルで実行できます。
IdentityServer_install_dir/oblix/apps/common/bin/globalparams.xml
PolicyManager_install_dir/access/oblix/apps/common/bin/globalparams.xml
ここで、IdentityServer_install_dirはアイデンティティ・サーバーがインストールされているディレクトリであり、PolicyManager_install_dirはポリシー・マネージャがインストールされているディレクトリです。
globalparams.xmlの詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
ユーザーのWebブラウザに設定されている値により決定されるデフォルト言語。この値は、ヘッダー変数のAccept-Languageに指定されます。
アプリケーションでHTTP_OBLIX_LANGヘッダー変数を検出できない場合、ユーザーのブラウザに設定されたAccept-Languageヘッダー変数が検索されます。
|
注意: HTTP_OBLIX_LANGヘッダー変数とAccept-Languageヘッダー変数は、両方とも構成可能です。詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。 |
Oracle Access Managerインストール環境のデフォルト言語。
Accept-Languageヘッダー変数をユーザーのブラウザで検出できない場合、アプリケーションでは、obnls.xml構成ファイルでOracle Access Managerインストール環境のデフォルト言語が検索されます。
obnls.xmlファイルは、IdentityServer_install_dir/identity/oblix/configディレクトリにあります。IdentityServer_install_dirは、アイデンティティ・サーバーがインストールされているディレクトリです。
詳細は、「複数言語の管理」を参照してください。
アイデンティティ・サーバーの構成には、ユーザー・セッション期間の指定、ユーザー・フィードバック用の電子メール・アドレスの指定、通知イベント用のメール・サーバーの構成、キャッシュの管理、および複数の言語の有効化が含まれます。
サーバー設定を表示および変更するには、アイデンティティ・システム・コンソールを使用します。
この項には、次の各項目が含まれます。
アイデンティティ・システム・コンソールで、「システム構成」→「サーバー設定」を選択します。
次のスクリーン・ショットのような「サーバー設定の表示」ページが表示されます。
設定の値を表示または変更するには、各設定のリンク（「メール・サーバー」や「マルチ言語」など）をクリックします。
必要に応じて設定を変更します。
「保存」をクリックして変更を保存します（変更を保存せずに終了する場合は、「取消」をクリックします）。
新しい値を有効化するため、アイデンティティ・サーバーを再起動します。
セッション・タイムアウトを構成すると、ユーザーのアイドル・セッション時間（分単位）を指定できます。ユーザー・セッションは、指定したアイドル時間が経過すると自動的に終了します。
このページの設定は、すべてのユーザーおよびすべてのアイデンティティ・システム・アプリケーションに適用されます。ユーザーやアプリケーション別に異なる設定を構成することはできません。
WebGateなどによるWebサーバー・ベースのログインを使用している場合は、WebGateインスタンスがタイムアウトを処理するため、セッション・タイムアウトは適用されません。
|
注意: Webシングル・サインオンにより保護されるリソースでは、アイドル・セッション・タイムアウト設定は常に無視されます。 |
ユーザーのアイデンティティ・システム・セッション期間を構成する手順
アイデンティティ・システム・コンソールで、「システム構成」→「サーバー設定」を選択し、「セッション・タイムアウトの構成」をクリックして次のページを表示します。
次のタイムアウト・オプションを選択します。
タイムアウトなし: ブラウザがアクティブであるかぎり、ユーザー・セッションは無期限に続きます。
アイドル・セッション・タイムアウト: アイドル・セッションを終了するまでの待機分数。アクティブではない状態でこの分数が経過すると、ユーザーはアプリケーションを継続するためにログインする必要があります。
事前に指定された時間間隔の経過後にアイドル・セッションを終了することには、いくつかの理由があります。セッションを短くすることで、ユーザーにロックされないまま放置されたワークステーションが不正に使用されることを防止できます。
リフレッシュ期間: ユーザー・セッションのタイムスタンプを更新する頻度を構成します。0（ゼロ）の値は、セッション・タイムスタンプをリクエストのたびに更新することを意味します。この値は、「アイドル・セッション・タイムアウト」の値の4分の1に設定することをお薦めします。
「保存」をクリックして変更を保存します（保存せずにページを終了する場合は、「取消」をクリックします）。
電子メールのカスタマイズ機能を使用して、ユーザー・フィードバック用の電子メール・アドレスを指定できます。エンド・ユーザーは、サイド・ナビゲーション・バーの「バージョン情報」をクリックし、次に「管理フィードバックを送信」または「Oracleにフィードバックを送信」をクリックすることでこれらのアドレスにアクセスできます。
アイデンティティ・システム・コンソールで、「システム構成」→「サーバー設定」を選択します。
「サーバー設定」ページで、「電子メール宛先のカスタマイズ」をクリックして次のページを表示します。
次のフィールドに電子メール・アドレスを入力します。
バグ・レポートの電子メール・アドレス: 組織内の担当者または代表窓口にレポートを送信する場合、このアドレスを変更する必要があります。この担当者または部門は、問題を解決するか、オラクル社カスタマ・サポート・センターに連絡することが可能な宛先です。
ユーザー・フィードバックの電子メール・アドレス: 自社ユーザーがローカル・ネットワークの外部に電子メールを送信できない場合、管理者はバグおよびフィードバック用のフィールドに内部アドレスを入力できます。オラクル社への情報の転送を担当するユーザーのアドレスを指定します。
Webマスターの電子メール・アドレス: Oracle Access Managerの管理を担当する自社ユーザーの電子メール・アドレスを入力します。
「保存」をクリックして変更を保存します（保存せずにページを終了する場合は、「取消」をクリックします）。
アイデンティティ・システムでは、リクエスト・チケットの処理、グループの管理、パスワード期限切れの通知、またはプロファイル属性の変更の際に、電子メール・アラートを発行できます。SMTPサーバー構成機能を使用して、アイデンティティ・システムでこれらの電子メールを処理する方法を構成します。
メール・サーバーを構成する場合、オプションの1つに「MHTML電子メールをサポート」があります。MHTMLは、HTMLなどのドキュメントの集合をMIMEでカプセル化したものを意味します。
MHTMLにより、MIME multipart/relatedボディ形式のインライン・グラフィック、アプレットおよびリンク・ドキュメントを含むHTMLドキュメントを送信できます。CID（content-ID）URLまたはその他の種類のURLを使用して、HTMLドキュメントに含まれる他のパートへのリンクを指定することが可能です。リンクされたボディ・パートは、content-ID（CID URLによるリンク）またはcontent-location（他の種類のURLによるリンク）のいずれかによりそのヘッダーで識別されます。
HTMLとMHTMLの主な違いは、MHTMLの場合、画像がHTML形式のようにリンクで参照されるのではなく、電子メールに埋め込まれることです。
アイデンティティ・システム・コンソールで、「システム構成」→「サーバー設定」を選択します。
「サーバー設定」ページで、「メール・サーバー」をクリックして次のページを表示します。
「サーバー名」フィールドにSMTPサーバー名を入力します。
「サーバー・ポート番号」フィールドにメール・サーバーのポート番号を入力します。
「ドメイン名」フィールドにWebサーバーのドメイン名を入力します。
|
注意: このフィールドはオプションですが、ドメイン名を指定すると、RFC 821に従ってSMTP接続を設定できます。 |
「メール送信スタイル」で次のオプションを選択します。
同期メーラー。: 電子メールを起動した「属性の変更」などのプロセスから送信します。メール・サーバーへの接続時にエラーが発生した場合や、サーバーが停止した場合、電子メールは送信されず、再生成もされません。
非同期メーラー。: すべてのアプリケーションからの電子メールをキューイングするスレッドを使用して、メールを1つずつ送信します。メール・サーバーに接続できない場合、電子メールはスレッドにより再送信されます。キューイングされたメールは、ディスクに保存されます。「非同期メーラー。」を選択する場合、メール・キュー・サイズも指定します。
「メール・スタイル」のオプションを選択します。
「保存」をクリックして変更を保存します（保存せずにページを終了する場合は、「取消」をクリックします）。
アイデンティティ・サーバー・キャッシュの内容の表示、新規情報を使用したキャッシュのロード、および非一貫性を解決するためのメモリー・キャッシュの消去を行うことができます。
アイデンティティ・システム・コンソールで、「システム構成」→「サーバー設定」を選択します。
「サーバー設定」ページで、「キャッシュ」をクリックしてページを表示します。
必要なオプションを選択します。次に例を示します。
キャッシュ内容の表示: 「キャッシュ」リンクをクリックした時点での現在の内容が表示されます。
メモリー・キャッシュのロード: キャッシュに最新情報が移入されますが、現在の情報は更新されません。現在の情報を更新するには、キャッシュをクリアしてからリロードします。
メモリー・キャッシュのクリア: 構成に影響することなくキャッシュ内の非一貫性が解決されます。
キャッシュの管理方法の詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。
新規インストールでは、デフォルトでマルチ言語機能が有効化されます。アイデンティティ・システム・コンソールで、優先言語の有効化、無効化および指定を行うことができます。
|
注意: 以前のリリースからアップグレードする場合、マルチ言語機能は無効化されます。この機能を有効化するには、次の手順を実行します。 |
アイデンティティ・システム・コンソールで、「システム構成」→「サーバー設定」を選択します。
「サーバー設定の表示」ページで、「マルチ言語」を選択します。
「マルチ言語の管理」ページが表示されます。このページには、使用可能な言語、優先順序、および言語が有効化されているかどうかなどの詳細情報が表示されます。
有効化または無効化する言語を決定します。
有効化: 言語を選択し、「有効化」をクリックしてその言語を有効化します。
無効化: 言語を選択し、「無効化」をクリックしてその言語を無効化します。
「戻る」をクリックして「サーバー設定」ページに戻ります。
アイデンティティ・サーバーの管理は、アイデンティティ・サーバーの追加または削除、アイデンティティ・サーバーのパラメータ値の変更などのタスクで構成されます。アイデンティティ・サーバーをインストールする方法の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。サーバーを完全に削除するには、サーバーをアンインストールする必要があります。
この項の内容は次のとおりです。
次の概要では、複数のアイデンティティ・サーバーを設定する方法について説明します。
最初のアイデンティティ・サーバーとWebパスをインストールし、アイデンティティ・システムを設定します（『Oracle Access Managerインストレーション・ガイド』を参照してください）。
アイデンティティ・システム・コンソールで新規アイデンティティ・サーバー・インスタンスを追加します（「アイデンティティ・サーバーの追加」の手順を参照してください）。
新規アイデンティティ・サーバー・インスタンスをWebパスに関連付け、優先順位をプライマリとして設定します（「アイデンティティ・サーバーとWebパスの関連付けの管理」を参照してください）。
Webパス・インスタンスを変更して、最大接続数をすべてのプライマリ・アイデンティティ・サーバーと通信するのに適切な数に設定します（「Webパスの追加または変更」を参照してください）。
手順5を実行する前に少なくとも1分間待機する必要があります。これにより、Webパス構成ファイルのwebpass.xmlが新規インスタンス情報で更新されるのを待機します。待機しない場合、Webパス・インスタンスで新規情報を取得できず、新規アイデンティティ・サーバー・インスタンスに接続できない可能性があります。
待機する実際の時間は、リフレッシュに設定された間隔に応じて変化します（「Webパス・ポーリング追跡パラメータの構成」を参照してください）。
少なくとも1分間待機してから、インストール済のすべてのアイデンティティ・サーバーを停止します。
新規アイデンティティ・サーバーをインストールし、このディレクトリ・サーバーで最初のアイデンティティ・サーバーではないことを示します（『Oracle Access Managerインストレーション・ガイド』を参照してください）。
スキーマを再更新する必要はありません。
インストールした追加のアイデンティティ・サーバーを設定します（『Oracle Access Managerインストレーション・ガイド』を参照してください）。
新規アイデンティティ・サーバー・インスタンスをインストール環境に追加する場合、次の手順を使用します。
アイデンティティ・サーバーを追加する手順
アイデンティティ・システム・コンソールで、「システム構成」→「アイデンティティ・サーバー」を選択します。
既存のアイデンティティ・サーバーへのリンクを含む「すべてのアイデンティティ・サーバーをリスト」ページが表示されます。
「追加」ボタンをクリックします。
「新規アイデンティティ・サーバーの追加」ページが表示されます。
「名前」フィールドから「スレッド数」フィールドまでを次のように入力します。
名前: アイデンティティ・サーバーの名前を入力します。
ホスト名: アイデンティティ・サーバーが稼働しているコンピュータの名前を入力します。
ポート: アイデンティティ・サーバーのポート番号を入力します。
デバッグ: アイデンティティ・サーバーとWebパス間の低レベル・トラフィックに関するデバッグ情報を格納するかどうかを指定します。
デバッグ・ファイル名: デバッグ・ファイルの名前とパスを入力します。デフォルト・パスは、IdentityServer_install_dir/oblix/logs/debugfile.lstです（IdentityServer_install_dirは、アイデンティティ・サーバーがインストールされているディレクトリです）。
トランスポート・セキュリティ: Webパスとアイデンティティ・サーバー間の通信に使用するセキュリティ方式を次から選択します。
|
注意: 証明書: 内部認証局（CA）を管理する場合に使用します。通信は、TLS v1を使用して暗号化されます。また、クライアントとサーバーの各要素は、接続の確立時にX.509証明書を提出する必要があります。証明書は、VeriSign社などのサード・パーティにより提供される必要があります。 |
最大セッション時間(時間): Webパスとアイデンティティ・サーバー間の接続をオープン状態のまま維持する最大時間を入力します。
この時間が経過すると、既存の接続はクローズされて新規接続がオープンされます。アイデンティティ・サーバーの構成で最大セッション時間が設定されている場合は、その設定が、接続されているすべてのWebパス・インスタンスに適用されます。Webパスとアイデンティティ・サーバーの両方の構成でこのパラメータが設定されている場合は、2つのうち低い方の値が使用されます。
スレッド数: アイデンティティ・サーバーで許可する同時リクエストの最大数を入力します。
現在の環境に応じた監査情報を次のように入力します。
データベースの監査フラグ(監査オン/オフ): 「オン」を選択すると、構成済のデータベースに監査情報が送信されます。デフォルトは「オフ」です。
ファイルの監査フラグ(監査オン/オフ): 「オン」を選択すると、次のフィールドで指定する名前のファイルに監査情報が送信されます。デフォルトは「オフ」です。
監査ファイル名: アイデンティティ・サーバーの監査情報を書き込む監査ファイルの名前を入力します。
アクセス・サーバーまたはアイデンティティ・サーバーの監査ファイルの絶対パスまたは相対パスを指定できます。相対パスを指定する場合は、パスの先頭に.または..を使用します。たとえば、次の相対パスを入力できます。
./auditfile.lst\
この相対パスにより、次の場所に監査ファイルが作成されます。
Component_install_dir\oblix\apps\common\bin\auditfile.lst
ここで、Component_install_dirは、関連するアクセス・サーバーまたはアイデンティティ・サーバーのルート・インストール・ディレクトリです。
次の相対パスを入力するとします。
../../../logs/auditfile.lst
この場合、Component_install_dir\oblix\logs\auditfile.lstが作成されます。
|
注意: IISのデプロイメント環境では、監査ファイルを表示可能にするため、IISユーザー（Webサーバーを実行しているシステム・ユーザー）に%TEMP%および%TMP%ディレクトリと、監査ファイルの保存先ディレクトリに対する書込み権限を付与する必要があります。 |
監査ファイル最大サイズ(バイト): 監査ファイルに格納するバイト数を入力します。このサイズに到達すると、監査ファイルはタイムスタンプ付きで保存され、新規ファイルが作成されます。
監査ファイル・ローテーション間隔（秒）: 監査ファイルのローテーション発生までの秒数を示す数値を入力します。ローテーションが発生すると、監査ファイルにタイムスタンプが記録され、新規ファイルが作成されます。デフォルト値は7200です。0（ゼロ）を設定すると監査ファイルのタイムアウトはなくなり、監査情報はファイルに継続的に追加されます。
「スコープ・ファイル名」フィールドを次のように入力します。
スコープ・ファイル名: バグ・レポートを記録するファイルの名前を入力します。バグ・レポートが生成される場合、ページに表示される情報もファイルに記録されます。このパラメータにより、バグ・レポートまたはOB_SCOPEメッセージ用のファイル名を指定します。
現在の環境におけるSNMP状態とSNMPエージェント登録ポートの詳細を入力します。
詳細は、「SNMPモニタリング」を参照してください。
SNMP状態: 「オン」を選択するとSNMPモニタリングが有効化されます。デフォルトは「オフ」です。
SNMPエージェント登録ポート: SNMPエージェントがリスニングするポートです。
|
注意: SNMPモニタリングをオンにした場合でも、SNMP統計を取得するには、独自のネットワーク管理ステーション（NMS）を構成して管理情報ベース（MIB）で定義された情報を処理する必要があります。SNMPエージェントのMIB変数の詳細は、このマニュアルの後続の説明を参照してください。 |
「保存」をクリックして新規アイデンティティ・サーバーの定義を終了します（保存せずに終了する場合は、「取消」をクリックします）。
アイデンティティ・システム・コンソールでパラメータを表示または変更するには、次の手順を使用します。
アイデンティティ・サーバー・パラメータを表示または変更する手順
アイデンティティ・システム・コンソールで、「システム構成」→「アイデンティティ・サーバー」を選択します。
既存のアイデンティティ・サーバーのリストが、各サーバーの名前、ホスト名およびポート番号とともに表示されます。
アイデンティティ・サーバーの名前をクリックしてそのパラメータを表示します。
「アイデンティティ・サーバーの詳細」ページが表示されます。このページには、サーバーのパラメータがリストされます。
「変更」をクリックします。
「アイデンティティ・サーバーの変更」ページが表示されます。
必要に応じてパラメータを変更します。
各パラメータの詳細は、「アイデンティティ・サーバーを追加する手順」を参照してください。
「保存」をクリックして変更を保存します（保存せずに終了する場合は、「取消」をクリックします）。
アイデンティティ・システム・コンソールでアイデンティティ・サーバー・パラメータを削除するには、次の手順を使用します。システム・コンソールからアイデンティティ・サーバーを削除する前に、そのアイデンティティ・サーバーの参照をWebパスの各エントリから削除し、作動するアイデンティティ・サーバーに置き換える必要があります。これを行わない場合、存在しないアイデンティティ・サーバーと通信するように構成されているWebパスのエントリを示すメッセージが表示されます。
|
注意: コンソールでアイデンティティ・サーバーを削除した場合、アイデンティティ・サーバー・パラメータがコンソールから削除されているため、コマンドラインからそのサーバーを起動しようとしても失敗します。 |
Webパス・プロファイルの編集: この手順を実行して、削除するアイデンティティ・サーバーの名前を削除し、作動するアイデンティティ・サーバーの名前を指定します。
アイデンティティ・システム・コンソールで、「システム構成」→「Webパス」を選択します。
目的のWebパスの名前をクリックしてプロファイルを表示します。
「変更」をクリックします。
プロファイルで、削除するアイデンティティ・サーバーの名前を削除し、作動する新規アイデンティティ・サーバーの名前を追加します。
「保存」をクリックします。
削除するアイデンティティ・サーバーが含まれているすべてのWebパスのプロファイルで、この手順を繰り返します。
アイデンティティ・サーバーの削除: 次の手順を実行します。
アイデンティティ・システム・コンソールで、「システム構成」→「アイデンティティ・サーバー」を選択します。
既存のアイデンティティ・サーバーのリストが、各サーバーの名前、ホスト名およびポート番号とともに表示されます。
「すべてのアイデンティティ・サーバーをリスト」ページで、削除するアイデンティティ・サーバーを選択します。
「削除」をクリックします。
削除の確認を求められたら「OK」をクリックします。選択したサーバーの名前がサーバー・リストから削除されます。
コマンドライン・ツールのconfig_oisを使用すると、Windowsのサービス・ウィンドウに含まれるアイデンティティ・サーバー・サービス関連のタスクを管理できます。
|
注意: すべてのコマンドライン・ユーティリティおよびツールは、製品をインストールしたユーザーとして実行する必要があります（『Oracle Access Managerインストレーション・ガイド』を参照してください）。インストール後にファイルの所有権やアクセス権の変更を試みないことをお薦めします。 |
付録7に記載されているコマンドを使用して、アイデンティティ・サーバー・サービスのインストールや、サービスの開始または停止などのタスクを実行できます。
表7-1 config_oisのコマンド
| コマンド | 操作 |
|---|---|
|
[-i install_dir] |
アイデンティティ・サーバー・サービスのインストール・ディレクトリを指定します。 |
|
-v |
サービス名を指定します。 |
|
[-a <start, stop, query, install, remove>] |
実行するアクションを指定します。 |
C:\IdentityServer_install_dir\identity\oblix\apps\common\bin\ config_ois.exe -q -i c:\IdentityServer_install_dir\identity -vIdentity_ServiceName-a query
ここで、IdentityServer_install_dirはアイデンティティ・サーバーがインストールされているディレクトリであり、Identity_ServiceNameはアイデンティティ・サーバー・サービスの名前です。
この問合せにより、次の情報が表示されます。
Sample_Srv configuration:
Service Type: 0x110
Start Type: 0x2
Err Control: 0x1
Binary path:
c:\COREid\identity\oblix\apps\common\bin\ois_server.exe
Load order group:
Dependencies:
Dependencies: LocalSystem
ディレクトリ・サーバーと通信するコンポーネントをインストールする場合、コンポーネントの通信先のディレクトリ・サーバーを指定します。各コンポーネントは、次の特定の目的でディレクトリと通信します。
アイデンティティ・サーバー: アイデンティティ・サーバーをインストールする場合、構成データを格納するLDAPディレクトリ・サーバーと、ユーザー・データを格納する場所を指定します。ユーザー・データは、構成データと同じディレクトリ・サーバーに格納するか、別のディレクトリ・サーバーに格納できます。
ポリシー・マネージャおよびアクセス・サーバー: ポリシー・マネージャまたはアクセス・サーバーをインストールする場合も、ユーザー・データと構成データを格納する場所を指定します。構成データには、システム構成、属性定義、属性アクセス制御、ワークフロー定義およびワークフロー・インスタンス・データが含まれます。また、アクセス・ポリシー・データの格納先も指定します。
|
注意: リリース7.0以上では、ユーザー・データを1つのディレクトリ・サーバー・タイプに格納し、構成データとポリシー・データをまとめて別のディレクトリ・サーバー・タイプに格納できます。データの格納方法の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。 |
次の各項目で詳細情報を提供します。
Oracle Access Managerに必要とされるデータのタイプ（構成データ、ユーザー・データおよびポリシー・データ）ごとに、LDAPディレクトリ・サーバー・プロファイルによりそのデータの正確な場所が識別されます。ポリシー・データと構成データの場所は、アイデンティティ・サーバー、アクセス・サーバーおよびポリシー・マネージャの.xmlファイルにも格納されます。ディレクトリ・サーバー・プロファイルには、同じネームスペースと（読取り、書込み、検索などの）操作要件を共有する1つ以上のディレクトリ・サーバーに対する接続情報が含まれます。接続情報には、名前、適用されるドメインまたはネームスペース、ディレクトリ・タイプ、および操作のセットが含まれます。デフォルトのディレクトリ・サーバー・プロファイルは、アイデンティティ・サーバーをインストールして新規ディレクトリ・サーバーの接続情報を指定するたびに自動的に作成されます。
ロード・バランシングおよびフェイルオーバーのために追加のLDAPディレクトリ・サーバー・プロファイルを作成できます。ディレクトリ情報ツリー（DIT）のパーティションに対応するディレクトリ・サーバー・プロファイルを作成できます。パーティション化により、DITの特定部分に対する読取りおよび書込み操作を実行するCPUサイクルが解放され、パフォーマンスが向上する可能性があります。これは、複数のディレクトリ・サーバーおよびコンピュータを含むインストール環境で特に役立ちます。
DITのマスター・コピーとレプリケート・コピーに対して異なる操作を指定するLDAPディレクトリ・サーバー・プロファイルを作成することも可能です。たとえば、マスターでは書込み操作にのみ対応し、レプリカでは読取り操作にのみ対応するよう指定できます。
|
注意: Oblixツリーを含むディレクトリ・サーバー・プロファイルでは、常に読取り、検索、変更、作成および削除操作をサポートする必要があります。Oblixツリーに関しては、読取り専用または書込み専用のディレクトリ・サーバー・プロファイルは作成できません。構成データまたはポリシー・データのディレクトリ・プロファイル設定を変更する場合、アイデンティティ・サーバーおよびポリシー・マネージャの設定を再実行し、アクセス・サーバーを再構成する必要があります。詳細は、「手動によるシステム設定の再実行」を参照してください。 |
Oracle Access Managerコンポーネントを新規にインストールし構成する場合、様々なプロファイルが次の構成ディレクトリ・サーバーに格納されます。
obcontainerId=DBAgents,oblix-root-node
ここで、oblix-root-nodeは、Oracle Access Managerデータの最上位レベルのノードです。ユーザー、ポリシーおよび構成データをディレクトリ・サーバーと同一のブランチに格納すると、プロファイルを必要とする各コンポーネントにすべてのデータを含む単一プロファイルが作成されます。ユーザー、ポリシーおよび構成データを非結合ブランチまたは別々のディレクトリ・サーバーに格納する場合、個別のプロファイルが必要です。
表7-2に、ディレクトリ・サーバー・プロファイルの作成の説明を示します。アクセス・サーバーの追加インスタンスに新規プロファイルは作成されません。
表7-2 インストール中に作成されるディレクトリ・サーバー・プロファイル
| インストールおよび構成の使用例 | 最初のアイデンティティ・サーバーおよびポリシー・マネージャに作成されるプロファイル | 2番目のアイデンティティ・サーバーに作成されるプロファイル | 2番目のポリシー・マネージャに作成されるプロファイル |
|---|---|---|---|
|
ユーザー、構成およびポリシー・データを、同じディレクトリ・サーバーに格納します。 ユーザー検索ベースが最上位ノードで、構成ベースはユーザー検索ベースの子、ポリシー・ベースは構成ベースの子です。 |
次の新規プロファイルが作成されます。
|
新規アイデンティティ・サーバーのプロファイルが作成されます。 |
新規プロファイルは作成されません。 |
|
構成データおよびポリシー・データを同一のディレクトリに格納しますが、ユーザー・データを個別のディレクトリに格納します。 または、ポリシー・ベースは構成ベースの子で、構成ベースはユーザー検索ベースと非結合です。 |
次の新規プロファイルが作成されます。
|
次の新規プロファイルが作成されます。
|
新規プロファイルは作成されません。 |
|
ユーザー、構成およびポリシー・データを、3つの別々のディレクトリ・サーバーに格納します。 または、ユーザー、構成およびポリシー・データを、別々の非結合ドメインに格納します。格納されたどのデータも、別のものの子ではありません。 |
次の新規プロファイルが作成されます。
|
次の新規プロファイルが作成されます。
|
ポリシー・ベースに既存のプロファイルがない場合、すべての新規アイデンティティ・サーバーに新しいポリシー・データ・プロファイルが1つ作成されます。 |
|
注意: 2番目のアイデンティティ・サーバーをインストールして既存のデータベース・プロファイルが変更された場合、新しいアイデンティティ・サーバーに一意のIDを指定してください。既存のIDを使用すると、プロファイルが上書きされます。 |
次のスクリーン・ショットは、アイデンティティ・システム・コンソールの「プロファイルの構成」ページを示しています。
「プロファイルの構成」ページの上部には、ユーザー・データと構成データを含むディレクトリ・サーバーの詳細が表示されます。ページの中央部には、LDAPディレクトリ・サーバー・プロファイルを構成するためのリンクが含まれます。ページの下部には、RDBMSプロファイルを構成するためのリンクが含まれます。RDBMSプロファイルの詳細は、「RDBMSプロファイルの管理」を参照してください。
「ディレクトリ・サーバー」リンクをクリックすると、「ディレクトリ・サーバー構成」ページが表示されます。ディレクトリ・サーバーの通信モード（またはホスト名あるいはポート番号）を変更する場合、「ディレクトリ・サーバー構成」ページの情報を変更して設定プログラムを再実行する必要があります。このタイプの変更の詳細は、「トランスポート・セキュリティ・モードの変更」を参照してください。
「プロファイルの構成」ページの中央部にある「LDAPディレクトリ・サーバー・プロファイルの構成」という見出しの下には、ユーザー・データ、構成データおよびポリシー・データ用のLDAPディレクトリ・サーバー・プロファイルへのリンクがリストされます。プロファイル・リンクをクリックすると、そのプロファイルに指定されている情報とサポート対象の操作を確認できます。表7-3にリストされているすべての操作または特定の操作を指定できます。
表7-3 サポートされるディレクトリ・サーバー操作
| カテゴリ | 操作 | コメント |
|---|---|---|
|
すべての操作 |
すべての操作が許可されます（デフォルト）。 |
|
|
検索 |
検索エントリ ユーザーの認証 |
「ユーザーの認証」操作により、ユーザーは、ディレクトリ・サーバー・プロファイルのネームスペース内での認証が可能になります。このオプションを選択すると、認証ドメインのログイン・ページのリストに含まれます。 |
|
読取り |
読取りエントリ |
この操作により、ディレクトリ・サーバー・プロファイルでは、スキーマの読取りもサポートされます。 |
|
書込み |
エントリの作成 エントリを修正 エントリの削除 パスワードの変更 |
「パスワードの変更」操作により、ユーザーは、ADSIまたはSSL接続を通じて各自のパスワードを変更できます。一方で、より頻繁に利用される検索などの他の操作は、別のディレクトリ・サーバー・プロファイルに割り当てることが可能です。 |
次の手順では、ディレクトリ・サーバー・プロファイルを作成する方法について説明します。
アイデンティティ・システム・コンソールで、「システム構成」をクリックし、次に「ディレクトリ・プロファイル」をクリックします。
「追加」をクリックして新規LDAPディレクトリ・プロファイルを作成します。「ディレクトリ・サーバー・プロファイルの作成」ページが表示されます。
|
注意: ディレクトリ・サーバー・プロファイルを変更するには、「LDAPディレクトリ・サーバー・プロファイルの構成」のリストでプロファイル名をクリックします。この場合、「ディレクトリ・サーバー・プロファイルの変更」ページが表示されます（「LDAPディレクトリ・サーバー・プロファイルの変更」を参照してください）。 |
|
注意: *付きのフィールドは必須です。 |
「名前」フィールドにディレクトリ・サーバー・プロファイルの名前を入力します。
この名前は、情報目的専用です。アイデンティティ・システムでは、アイデンティティ・システムのインストール時に自動的に作成されるすべてのデフォルト・ディレクトリ・サーバー・プロファイルに対して<Identity Server id>というデフォルトのネーミング規則を使用します。
「ネームスペース」フィールドにディレクトリ・サーバー・プロファイルの検索ベースを入力します。
|
注意: このネームスペースは他のディレクトリ・サーバー・プロファイルのネームスペースと重複しないよう注意してください。ネームスペースが重複すると、重複エントリが発生します。ネームスペースの重複の例外として、Microsoft Active Directoryサブドメインのディレクトリ・サーバー・プロファイルと、構成DNを含むディレクトリ・サーバー・プロファイルがあげられます。 |
ディレクトリ・サーバーのタイプを選択します。
Siemens DirXおよびSun: Siemens DirXまたはSun（旧iPlanet）のいずれかを単独で使用する場合、データを別々に格納するか一緒に格納するかを選択できます。『Oracle Access Managerインストレーション・ガイド』を参照してください。
Oracle Data Anywhere: Oracle Virtual Directory Server（VDS）と統合する必要があります。
Oracle Data Anywhereは、データ管理レイヤーであり、RDBMSやLDAPディレクトリなどの複数のソースからユーザー・データを収集して仮想LDAPツリーに統合します。この仮想LDAPツリーは、アイデンティティ・システムで管理可能であり、アクセス・システムを使用した認証および認可のサポートに使用できます。
構成データとポリシー・データを含むLDAPディレクトリのブランチは、VDSまたはユーザー・データをホストするディレクトリ・サーバーとは異なる1つ以上のディレクトリ・サーバーに存在する必要があります。アイデンティティ・システム・アプリケーションで認識できるのは、VDS仮想ディレクトリの外部に存在する構成情報とポリシー情報のみです。
|
注意: Oracle Data AnywhereとVDSを使用するためのインストール作業を行う前に、『Oracle Access Manager統合ガイド』のVDSとの統合に関する章を必ず参照してください。 |
Active Directory: Active Directoryを選択する場合、パスワード変更操作にADSI（Active Directory Service Interfaces）を使用するかどうかを指定します。「ADSI」オプションを選択する場合、パスワード変更用にLDAP/SSL接続を設定する必要はありません。ADSIを使用しない場合、Oracle Access Managerでは、パスワード変更にSSL接続が使用されます。「ADSIに対する構成」を参照してください。
ディレクトリ・サーバーに対する他のすべての通常操作用にLDAP/SSLを設定済の場合、証明書サーバーの設定やCA証明書のインポートなどを行う必要はありません。それ以外の場合は、パスワード変更用にLDAP/SSLを構成する必要があります。
詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
動的補助クラス: Active Directoryで動的補助クラスを使用する場合、「動的補助」で「はい」を選択し、動的補助クラスをActive Directory 2003の構造化オブジェクト・クラスに関連付けます。
詳細は、「Active Directoryでのデプロイ」を参照してください。
|
注意: Active Directory 2003では、動的補助クラスまたは静的補助クラスを有効化できます。 |
このディレクトリ・サーバー・プロファイルでサポートする操作を指定します（表7-3のリストを参照してください）。
このプロファイルを使用するサーバーを指定します。
すべてのOracle Access Managerコンポーネント: インストール環境の各コンポーネント・サーバーで同じプロファイルを共有する場合、このオプションを選択します。
アイデンティティ・サーバー: アイデンティティ・サーバーでのみこのプロファイルを共有する場合、このオプションを選択します。特定のアイデンティティ・サーバーでこのプロファイルを使用する場合、付属のリスト・ボックスからサーバー名を選択します。
AAA Servers: AAA Serverオプションは、アクセス・サーバーの構成オプションを示します。新規アクセス・サーバーを追加すると、常にデータベース・プロファイルを作成するよう求められます。アクセス・サーバー・インスタンスを追加する方法の詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
「追加」をクリックしてディレクトリ・サーバー・インスタンス（データベース・インスタンス）をこのプロファイルに関連付け、プライマリまたはセカンダリのサーバー・タイプを割り当てます。
詳細は、「LDAPディレクトリ・サーバー・プロファイルのデータベース・インスタンスを追加または変更する手順」を参照してください。
必要なアクティブ・サーバーの最大数（ロード・バランシングのために接続するプライマリおよびセカンダリ・データベース・インスタンスの数）を指定します。
デフォルト値の1は、ロード・バランシングを使用しないことを示します。
1を超える値では、最も短いジョブ・キューを保持するデータベース・インスタンスに従って、すべてのデータベース・インスタンス全体にデータベース・リクエストが分散されます。これにより、可能なかぎり迅速にジョブが処理されます。
ロード・バランシングの詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。
フェイルオーバーしきい値を指定します。
この値では、稼働している必要のあるプライマリ・サーバーの最小数を指定します。稼働しているプライマリ・サーバーの数がこの指定数を下回ると、フェイルオーバーが発生します。この値は、最大アクティブ・サーバー数と同じにすることをお薦めします。その結果、プライマリ・サーバーが停止すると即座にセカンダリ・サーバーへのフェイルオーバーが発生します。
デフォルト値は1です。この場合、アイデンティティ・サーバーから接続できるプライマリ・ディレクトリ・サーバーが存在しない場合にのみ、セカンダリ・サーバーへのフェイルオーバーが発生します。
|
注意: プライマリ・サーバーが停止したときに即座にセカンダリ・サーバーへのフェイルオーバーを実行するため、この値は最大アクティブ・サーバー数と同じにすることをお薦めします。フェイルオーバーと関連パラメータの詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。 |
「スリープ時間（秒）」フィールドに、ウォッチャ・スレッドを起動して、停止している1つ以上のプライマリ・サーバーに対する接続を再確立するまでに待機する秒数を入力します。
|
注意: フェイルオーバーの発生時にプライマリ・サーバーが使用可能な場合、アイデンティティ・サーバーは最初にプライマリ・サーバーにフェイルオーバーされます。 |
「最長セッション時間」フィールドに、再接続を試行するまでにアイデンティティ・サーバーでディレクトリへの接続を維持する分数を指定します。
デフォルト値は0（無制限）です。アイデンティティ・サーバー、アクセス・サーバーまたはポリシー・マネージャのメモリー使用量が増加している場合は、この値を600（10時間）に変更することをお薦めします。
このプロファイルを使用可能にする場合、「プロファイルの有効化」を選択します。
次のスクリーン・ショットは、この構成ページの下半分を示しています。
次のように「保存」、「取消」または「リセット」を選択します。
「保存」をクリックして変更を保存します。
保存せずにこのページを終了する場合、「取消」をクリックします。
すべての設定をデフォルト設定にリセットする場合、「リセット」をクリックします。
「OK」をクリックして設定の追加を確認します。
アイデンティティ・サーバーを再起動して新規プロファイルを有効化します。
「プロファイルの構成」ページの中央部にある「LDAPディレクトリ・サーバー・プロファイルの構成」という見出しの下には、構成済のディレクトリ・サーバー・プロファイルのリストが含まれます。
アイデンティティ・システム・コンソールで、「システム構成」をクリックします。
「システム構成」ページで、「ディレクトリ・プロファイル」をクリックします。
「プロファイルの構成」ページが表示されます。
ページの中央部にある「LDAPディレクトリ・サーバー・プロファイルの構成」という見出しの下に、構成済のディレクトリ・サーバー・プロファイルのリストが含まれます。
表示するディレクトリ・サーバー・プロファイルのリンクをクリックします。
「ディレクトリ・サーバー・プロファイルの変更」ページが表示されます。
既存のLDAPディレクトリ・サーバー・プロファイルの変更が必要とされる場合もあります。
アイデンティティ・システム・コンソールで、「システム構成」を選択します。
「システム構成」ページで、「ディレクトリ・プロファイル」をクリックします。
「プロファイルの構成」ページの「LDAPディレクトリ・サーバー・プロファイルの構成」という見出しの下のリストで、変更するディレクトリ・サーバー・プロファイルのリンクをクリックします。
パラメータの詳細は、「LDAPディレクトリ・サーバー・プロファイルの作成」を参照してください。
必要に応じて変更を加え、「保存」をクリックして変更を確定します。
アイデンティティ・サーバーを再起動して新規プロファイルを有効化します。
構成データおよびポリシー・データ用のディレクトリ・サーバー・プロファイルに対して次のいずれかの操作を実行したら、その完了後にシステム設定を再実行する必要があります。
システム・コンソールでのディレクトリ・サーバー構成オプションの変更。
構成データおよびポリシー・データ用の新規ディレクトリ・プロファイルの作成。
構成データおよびポリシー・データに属するディレクトリ・プロファイルの削除。
構成データおよびポリシー・データ用のディレクトリ・プロファイルの変更。
プロファイル内のディレクトリ・インスタンスの追加または変更。
|
注意: 「ディレクトリ・サーバー構成」ページで特定の項目（アスタリスク（*）付きの項目）を変更した場合も、システム設定を再実行する必要があります。 |
設定の再実行は、特定の順序で行う必要があります。
タスクの概要: システム設定の再実行
アイデンティティ・システム設定を再実行します（「アイデンティティ・システム設定の再実行」を参照してください）。
必要に応じてポリシー・マネージャ設定を再実行します（「ポリシー・マネージャ設定の再実行」を参照してください）。
アクセス・サーバーを再構成します（「アクセス・サーバーの再構成」を参照してください）。
setup.xmlのstatusパラメータを変更または削除して、インストールが未完了のため設定の再実行を許可するようアイデンティティ・システムに指示します。
複数のアイデンティティ・サーバーが稼働している場合、1つだけ残して停止します。
稼働している唯一のアイデンティティ・サーバー・ホストに移動し、次のsetup.xmlファイルを開きます。
IdentityServer_install_dir/identity/oblix/config/setup.xml
statusパラメータを削除するか、次の例に示すとおりstatusパラメータの値をdoneからincompleteに変更します。
<NameValPair ParamName="status" Value="incomplete"></NameValPair>
ファイルを保存します。
アイデンティティ・サーバーを再起動します。
Webブラウザでアイデンティティ・システム・コンソールを起動します。
アイデンティティ・システムの初期設定時に表示されるページに似た「セットアップ」ページが表示されます。
設定を再度開始し、新規情報を指定します。
設定の完了後、他のアイデンティティ・サーバーを再起動します。
他のアイデンティティ・サーバーにより、新規情報が検出されます。
次の手順を完了して、ポリシー・マネージャ設定を再実行します。
実装にアクセス・システムが含まれる場合、アイデンティティ・システム設定の再実行後にポリシー・マネージャを手動で設定します。setup.xmlのstatusパラメータを変更または削除して、ポリシー・マネージャ設定の再実行を可能にします。
複数のポリシー・マネージャWebサーバーが稼働している場合、1つだけ残して停止します。
稼働している唯一のポリシー・マネージャ・ホストに移動し、次のsetup.xmlファイルを開きます。
PolicyManager\access\oblix\config\setup.xml
statusパラメータを削除するか、次の例に示すとおりstatusパラメータの値をdoneからincompleteに変更して、ファイルを保存します。
<NameValPair ParamName="status" Value="incomplete"></NameValPair>
ポリシー・マネージャWebサーバーを再起動します。
Webブラウザでアクセス・システム・コンソールを起動します。
アクセス・システムの初期設定時に表示されるページに似た「セットアップ」ページが表示されます。
設定を再度開始し、新規情報を指定します。
設定の完了後、他のポリシー・マネージャWebサーバーを再起動します。
他のポリシー・マネージャにより、新規情報が検出されます。
アクセス・サーバーを再実行します（「アクセス・サーバーの再構成」を参照してください）。
ポリシー・マネージャの設定を手動で再実行したら、次の手順に従ってアクセス・サーバーを再構成する必要があります。
Windowsシステム: configureAAAServerツールを使用します。
UNIXシステム: start_configureAAAServerスクリプトを使用してconfigureAAAServerツールを起動します。このツールをオプションなしで実行すると、オプションを表示できます。
独自の環境に対応するツールを探します。
AccessServer_install_dir/access/oblix/tools/configureAAAServer
configureAAAServerツールで次のコマンドを使用し、アクセス・サーバーを設定します。
UNIX: start_configureAAAServer reconfigAccessServer_install_dirWindows: configureAAAServer reconfigAccessServer_install_dir
新規情報を指定します。
アクセス・サーバーを再起動します。
ディレクトリ・サーバー・プロファイルには、特定のLDAPディレクトリ・サーバーのバインド情報（サーバー名、ホスト・コンピュータ、ポート、ルートDN、パスワードなど）が含まれます。ディレクトリ・サーバー・プロファイルの一部として、データベース・インスタンスを構成できます。このようなデータベース・インスタンスを定義すると、Oracle Access Managerにより、指定されたバインド資格証明に基づいて構成済のホストとポートが検証されます。データベース・インスタンスに対応するディレクトリ・サーバーは、構成時に稼働している必要があります。
|
注意: LDAPディレクトリ・サーバー・プロファイル内のデータベース・インスタンスは、RDBMSプロファイル内のデータベース・インスタンスとは異なります。RDBMSプロファイルは、Oracle Access ManagerをODBC 3.0に準拠する外部のリレーショナル・データベースに接続する場合に使用します。「RDBMSプロファイルの管理」を参照してください。 |
LDAPディレクトリ・サーバー・プロファイルは、ロード・バランシングおよびフェイルオーバーに使用される1つ以上のデータベース・インスタンスで構成されます。ディレクトリ・サーバー・プロファイルにより、アクティブ・サーバーの最大数に応じてそのインスタンス間で負荷が分散されます。また、フェイルオーバーしきい値に応じてそのインスタンス間でフェイルオーバーが実行されます。
ディレクトリ・サーバー・インスタンスを追加する場合、LDAP参照を有効化するかどうかを指定できます。参照を使用すると、クライアント・リクエストを別のサーバーにリダイレクトし、リクエストされた情報を別の場所で検索できます。参照には、オブジェクトの名前と場所が含まれます。
ディレクトリ・サーバー・インスタンスを追加する際にLDAP参照を有効化する場合、次のファイルでenableLDAPReferralパラメータをtrueに設定する必要があります。
install-dir\oblix\data\common\ldapconfigdbparams.xml
ここで、install_dirは、ポリシー・マネージャ、アクセス・サーバーまたはアイデンティティ・サーバーのインストール・ディレクトリです。
次に、Active Directoryに対応するこのファイルの例を示します。
BEGIN:vCompoundList
specialAttrs:
BEGIN:vNameList
userPassword:( 2.5.4.35 NAME 'userPassword' DESC
'Standard Attribute' SYNTAX '1.3.6.1.4.1.1466.115.121.1.5' )
sAMAccountName:( 1.2.840.113556.1.4.221 NAME 'sAMAccountName' DESC 'sAMAccountName' SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
END:vNameList
useOIDNamingAttribute:false
dynamicAuxiliary:false
enableLDAPReferral:true
END:vCompoundList
LDAPディレクトリ・サーバー・プロファイルのデータベース・インスタンスを追加または変更する手順
アイデンティティ・システム・コンソールで、「システム構成」をクリックします。
「システム構成」ページで、「ディレクトリ・プロファイル」をクリックします。
データベース・インスタンスを追加するディレクトリ・サーバー・プロファイルのリンクをクリックします。
「ディレクトリ・サーバー・プロファイルの変更」ページが表示されます。
「データベース・インスタンス」まで下にスクロールし、「追加」ボタンをクリックします（既存のデータベース・インスタンスを編集または変更する場合は、データベース・インスタンスのリストからそのインスタンスを選択します）。
「データベース・インスタンスの作成」ページ（または「データベース・インスタンスの変更」ページ）が表示されます。
|
注意: LDAPディレクトリ・サーバー・プロファイルの「データベース・インスタンスの変更」ページのフィールドは、RDBMSの「データベース・インスタンスの変更」ページのフィールドとは異なります。詳細は、「RDBMSデータベース・インスタンスの追加または変更」を参照してください。 |
各フィールドを次のように入力します。
名前: ディレクトリ・サーバー・インスタンスの名前を入力します。
マシン: ディレクトリ・サーバー・インスタンスをホストするコンピュータの名前を入力します。
ポート番号: ディレクトリ・サーバーのポート番号を入力します。
ルートDN: 管理権限を保持するディレクトリ・サーバー・ユーザーのルートDN（バインドDN）を入力します。
ルート・パスワード: 管理権限を保持するディレクトリ・サーバー・ユーザーのパスワードを入力します。
時間制限: ディレクトリ・サーバーに対するリクエストを許可する最大時間を指定します。
デフォルト値は0（ゼロ）秒であり、時間はサーバーにより決定されます。データベース・インスタンス設定は、この設定に優先します。
サイズ制限: 検索操作でディレクトリ・サーバーが戻すことのできるエントリの最大数を指定します。
デフォルト値は0（ゼロ）エントリであり、エントリ数はサーバーにより決定されます。
フラグ: 次のいずれかを選択します。
SSL: SSLを使用するディレクトリ・サーバー・プロセス。この場合、最初に証明書を構成する必要があります。詳細は、使用しているディレクトリ・サーバーのドキュメントを参照してください。
参照: ディレクトリ・サーバー・プロファイルでこのディレクトリ・サーバーのLDAP参照をトレースするかどうかを指定します。参照サーバーへのログイン時には同じバインド資格証明（ルートDNとパスワード）が使用されます。
ファスト・バインド(Windows Server 2003のADのみ): 簡易バインドとは異なり、セキュリティ・トークンを戻すことなくユーザー名とパスワードを認証します。認証のみを実行するアプリケーションの場合、この方式の方が簡易バインドより高速です。
セキュア・ポート番号: ディレクトリ・サーバーにアクセスするためのポートを指定します。
SSLを使用していない場合、またはパスワード変更にActive DirectoryとADSIを組み合せて使用している場合、このフィールドは空白のままとします。
最初の接続数: ディレクトリ・サーバーへの接続に使用する初期接続数を指定します。
これらの接続は、すべてのユーザー・リクエストで共有されます。最小値は1です。
最大接続数: ディレクトリ・サーバーに許可する最大接続数を指定します。
デフォルトは1です。異なるタイプの操作には、異なるDBエージェントが使用されます。「最大接続数」フィールドは、特定のエージェント向けに実装されています。オープン可能な接続の合計数は、このフィールドに指定する値よりずっと多くすることができます。詳細は、『Oracle Access Managerデプロイメント・ガイド』のディレクトリ接続プールの構成方法に関する情報を参照してください。
「保存」をクリックして設定を保存します。
保存せずに終了する場合は「取消」をクリックし、最後に保存した設定に戻る場合は「リセット」をクリックします。
LDAPディレクトリ・サーバー・インスタンスは、削除できます。
LDAPディレクトリ・サーバー・プロファイルのディレクトリ・サーバー・インスタンスを削除する手順
アイデンティティ・システム・コンソールで、「システム構成」を選択し、次に「ディレクトリ・オプションの構成」をクリックします。
ディレクトリ・サーバー・プロファイルの構成ページが表示されます。このページには、すべてのディレクトリ・サーバー・プロファイルがリストされます。
インスタンスを追加するディレクトリ・サーバー・プロファイルをクリックします。
「ディレクトリ・サーバー・プロファイルの変更」ページが表示されます。
「ディレクトリ・サーバー・プロファイルの変更」ページで、削除するデータベース・インスタンスを選択します。
「削除」をクリックします。
ディレクトリ・サーバー・インスタンスが削除されます。
Oracle Internet Directoryなどの一部のディレクトリでは、非結合検索ベースまたはレルムとも呼ばれる複数の検索ベースを構成できます。これらの非結合検索ベースまたはレルムは、次のような重複しないディレクトリ・ツリーで構成されます。
o=company,c=us
o=oracle,c=us
Oracle Access Managerでこのような複数の検索ベースに含まれるデータを管理する場合、検索ベースごとにアイデンティティ・システムとアクセス・システムを個別に構成する必要があります。
次の手順では、ディレクトリに非結合検索ベース（またはレルム）をすでに定義してあると仮定します。
非結合検索ベースを操作するためにアイデンティティ・システムを構成する手順
アイデンティティ・システム・コンソールで、「システム構成」をクリックし、次に「ディレクトリ・プロファイル」をクリックします。
サポートする新規非結合検索ベースごとに個別のディレクトリ・サーバー・プロファイルを追加します。
詳細は、「LDAPディレクトリ・サーバー・プロファイルの作成」を参照してください。指定したネームスペースがディレクトリのネームスペースと正確に一致していることを確認します。
アイデンティティ・サーバーと、アイデンティティ・サーバーを実行しているWebサーバーを再起動します。
アイデンティティ・システム・コンソールで、「システム構成」→「ディレクトリ・プロファイル」をクリックし、「ディレクトリ・プロファイル」ページに戻ります。
「ディレクトリ・プロファイル」ページの「ディレクトリ・サーバー」リンクをクリックします。
「非結合検索ベース」フィールドに、最初の非結合検索ベースのネームスペースを入力します。
これは、ディレクトリ・サーバー・プロファイルに指定されているネームスペースと同じである必要があります。
「追加」をクリックして追加の非結合検索ベースを構成します。
新規非結合検索ベースごとに、検索ベースにエントリのあるユーザーの新規権限を構成します。
詳細は、「ユーザーによるLDAPデータの表示および変更の許可」を参照してください。
非結合検索ベースごとにID管理者と委任ID管理者を追加します。
詳細は、「アイデンティティ・システム管理者の指定」を参照してください。
次のファイルをテキスト・エディタで開き、このファイルのwhichAttrIsLoginパラメータの値がディレクトリのユーザー属性と一致していることを確認します。
IdentityServer_install_dir/oblix/apps/common/bin/globalparams.xml
非結合検索ベースを操作するためにアクセス・システムを構成する手順
「非結合検索ベースを操作するためにアイデンティティ・システムを構成する手順」の手順のステップを完了します。
次のファイルをテキスト・エディタで開き、このファイルのwhichAttrIsLoginパラメータの値がディレクトリのユーザー属性と一致していることを確認します。
PolicyManager_install_dir/access/oblix/apps/common/bin/globalparams.xml
アクセス・システム・コンソールで、適切な資格証明マッピング・パラメータを使用する認証スキームを作成します。
obMappingBase="%domain%",obMappingFilter="(&(&(objectclass=objectclassname)(loginattribute=%userid%))(|(!(obuseraccountcontrol=*)) (obuseraccountcontrol=ACTIVATED)))",obdomain="domain"
ここで、objectclassnameはPersonオブジェクト・クラスの名前（gensiteorgpersonなど）であり、loginattributeはPersonオブジェクト・クラスのログイン属性の名前（genuseridなど）です。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
たとえば、現在の非結合検索ベースでPersonオブジェクト・クラスとしてgensiteorgpersonを使用し、ログイン属性としてgenuseridを使用している場合、認証スキームを次のように作成します。
obMappingBase="%domain%",obMappingFilter="(&(&(objectclass=gensiteorgperson) (genuserid=%userid%))(|(!(obuseraccountcontrol=*))(obuseraccountcontrol= ACTIVATED)))",obdomain="domain"
ポリシー・マネージャで、適切な認証スキームを使用するよう関連する認証ルールを変更します。
詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
ポリシー・マネージャで、認証の成功時にHTTP_OBLIX_UIDヘッダー変数のobuniqueIDの値を戻すよう/accessおよび/identityポリシー・ドメインを構成します。
これらのポリシー・ドメインの認証ルールで、次の認証成功アクションを構成します。obuniqueid属性により、特定のログイン属性に構成されている任意の値が戻されます（これらの属性は、ディレクトリの各検索ベースで使用されます）。
タイプ: HEADERVAR
名前: HTTP_OBLIX_UID
戻り属性: obuniqueid
Oracle Access Managerでは、RDBMSプロファイルを使用して、ODBC 3.0に準拠する外部のリレーショナル・データベースに接続します。現在のところ、ユーザー・アクセス・プロファイル・レポート機能とデータベースへの監査送信機能でRDBMSプロファイルを使用しています。各プロファイルでは、データベースのプライマリ・インスタンスが停止した場合のフェイルオーバーに備えて、複数のデータベース・インスタンスを含むことができます。
|
注意: RDBMSプロファイルには、データベース・インスタンスが含まれます。これらのデータベース・インスタンスは、LDAPディレクトリ・サーバー・プロファイルの一部として構成されるデータベース・インスタンスとは異なります。LDAPディレクトリ・サーバー・プロファイルのデータベース・インスタンスは、LDAPディレクトリのロード・バランシングおよびフェイルオーバーに使用されます。 |
この項には、次の各項目が含まれます。
RDBMSプロファイルを追加する手順と変更する手順は似ています。次に、これらの手順を説明します。表7-4に、入力するフィールドを示します。
表7-4 RDBMSプロファイルを追加または変更する場合のフィールドの説明
| フィールド | 説明 |
|---|---|
|
名前 |
RDBMSプロファイルのわかりやすい名前を選択します。 |
|
データベース接続タイプ |
データベースへの監査送信を構成している場合、データベースで使用されている接続タイプを選択します。詳細は、「監査」を参照してください。 |
|
使用 |
RDBMSプロファイルを使用する機能に対応するボックスを選択します。現在のところ、ユーザー・アクセス権限レポート機能とデータベースへの監査送信機能を選択できます。 |
|
フェイルオーバーに使用するデータベースの複数のコピーを次のように作成できます。
|
|
|
最大アクティブ・サーバー数 |
これは、任意の時点でリレーショナル・データベースに接続できるサーバーの最大数です。 |
|
フェイルオーバーしきい値 |
接続しているプライマリ・サーバーの数がこの数を下回ると、フェイルオーバーが発生します。 |
|
スリープ時間（秒） |
接続の切断後、フェイルオーバーを実行するまでに待機する秒数です。 |
|
最長セッション時間 |
データベースに対する接続は、この分数が経過すると、正常に機能している場合でも破棄されて新規接続が確立されます。 |
|
プロファイルの有効化 |
プロファイルをアクティブにする場合、必ずこのボックスを選択します。 |
アイデンティティ・システム・コンソールで、「システム構成」を選択し、次に「ディレクトリ・プロファイル」をクリックします。
「プロファイルの構成」ページが表示されます。このページには、すべてのディレクトリ・サーバー・プロファイルがリストされます。
「プロファイルの構成」ページの下部に「RDBMSプロファイルの構成」セクションがあります。
RDBMSプロファイルのリストで、編集するプロファイルの名前を選択します（または、「追加」をクリックして新規プロファイルを作成します）。
「RDBMSプロファイルの作成」ページ（または「RDBMSプロファイルの変更」ページ）のフィールドを入力または変更します（表7-4を参照してください）。
フィールドへの情報の入力を完了したら、「保存」をクリックして変更をコミットします。
RDBMSデータベース・プロファイルのデータベース・インスタンスを作成する手順と変更する手順はよく似ているため、次の手順でまとめて説明します。どちらの場合も、表7-5の情報をフィールドに入力する必要があります。
表7-5 RDBMSプロファイルのデータベース・インスタンスを追加または変更する場合のフィールドの説明
| フィールド | 説明 |
|---|---|
|
名前 |
データベース・インスタンスの名前 |
|
「DSN名」または「グローバル・データベース名」 |
ODBC接続タイプでデータベース監査を構成している場合、「DSN名」フィールドが表示されます。これにより、特定のデータ・ソースにアクセスするすべてのクライアントの一意のデータ・ソース定義が識別されます。（DSNという用語は、ODBCデータ・ソース定義全体を示すものとして不正確に使用されることがよくあります。） OCI接続タイプでデータベース監査を構成している場合、データベース・インスタンス定義にグローバル・データベース名（GDN）を指定します。 詳細は、「データベース監査用のRDBMSプロファイルについて」を参照してください。 |
|
ユーザー名 |
このデータベース・インスタンスへのアクセス権限を保持する管理者の名前 |
|
パスワード |
このデータベース・インスタンスのパスワード |
|
時間制限 |
データベースへの接続を切断し、新規接続で置き換えるまでの分数 |
|
サイズ制限 |
データベースの最大サイズ |
|
最初の接続数 |
初期化時にこのデータベース・インスタンスに接続されるプライマリ・サーバーとセカンダリ・サーバーの数 |
|
最大接続数 |
このデータベース・インスタンスに接続できるプライマリおよびセカンダリのアクセス・サーバーの合計数 |
RDBMSプロファイルのデータベース・インスタンスを追加または変更する手順
アイデンティティ・システム・コンソールで、「システム構成」を選択し、次に「ディレクトリ・プロファイル」をクリックします。
ディレクトリ・サーバー・プロファイルの構成ページが表示されます。
「RDBMSプロファイルの構成」セクションで、「追加」をクリックしてRDBMSプロファイルを作成するか、変更するRDBMSプロファイルの名前をリストから選択します。
ユーザーの選択に応じて、「RDBMSプロファイルの作成」ページまたは「RDBMSプロファイルの変更」ページが表示されます。
「データベース・インスタンス」セクションで、「追加」ボタンをクリックして新規インスタンスを作成するか、編集するインスタンスの名前をリストから選択します。
「データベース・インスタンスの変更」ページまたは「データベース・インスタンスの作成」ページのフィールドを入力します。
各フィールドの説明は、表7-5を参照してください。
ページのフィールドに情報を入力したら、「保存」をクリックして変更をコミットします。
アイデンティティ・サーバーのインストール後、最初にWebパスをインストールします。アイデンティティ・システムの設定後、複数のWebパス・インスタンスをインストールおよび構成できます。各Webパス・インスタンスは、個別にインストールおよび構成します。Webパス・インスタンスをインストールする場合、いくつかの必須パラメータを指定します。マスター管理者は、アイデンティティ・システム・コンソールでこれらのパラメータを変更し、追加の情報（フェイルオーバーしきい値など）を入力できます。
ユーザーからWebサーバー・リソースへのアクセス・リクエストがあると、そのリクエストはWebパスによってアイデンティティ・サーバーにリダイレクトされます。その後、アイデンティティ・サーバーにより、ディレクトリ・サーバーを通じてユーザーのIDがチェックされます。Webパス・プラグインは、Webサーバーごとに構成する必要があります。
Webパスのインストール方法の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。この項には、次の各項目が含まれます。
Webパスの構成は、アイデンティティ・システム・コンソールの「Webパスの構成」機能を使用して行います。
アイデンティティ・システム・コンソールで、「システム構成」→「Webパス」を選択します。
「すべてのWebパスをリスト」ページが表示されます。このページで、Webパスを追加、変更または削除できます。
Webパスの情報を表示するには、Webパスのリンクをクリックします。
「WebPassの詳細」ページが表示されます。このページには、Webパス・インスタンスに関するすべての情報がリストされます。
新規Webパスを追加する場合、アイデンティティ・システム・コンソールでインスタンスを追加してWebサーバー・ホストにWebパスをインストールし、Webサーバー構成を更新してWebパスとWebサーバー間の通信を確立します。インスタンスを追加するには、次の手順を使用します。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
アイデンティティ・システム・コンソールで、「システム構成」サブタブをクリックし、次に左側のナビゲーション・ペインの「Webパス」をクリックします。
「すべてのWebパスをリスト」ページが表示されます。このページで、Webパスを追加、変更または削除できます。
「Webパスの構成」ページで、「追加」をクリックします。
「新規Webパスの追加」ページが表示されます。
「名前」フィールドにこのWebパス・インスタンスの名前を入力します。
|
注意: このインスタンスとともに保存する名前は、変更できません。名前を変更するには、このインスタンスを削除して別の名前で再構成します。 |
「ホスト名」フィールドに、このWebパスをホストするWebサーバー・インスタンスの名前を入力します。
「Webサーバー・ポート」フィールドに、Webサーバー・インスタンスがリスニングするポート番号を入力します。
最大値は65535です。
「最大接続数」フィールドに、このWebパスでアイデンティティ・サーバーに対してオープンする接続の最大数を指定します。
接続の最小数は1です。ロード・バランシングおよびフェイルオーバーのためにより多くの接続を指定できます。
「トランスポート・セキュリティ」フィールドで、Oracle Access Managerのインストール時に指定されたセキュリティ・モードを変更できます。
トランスポート・セキュリティ・モードにより、Webパスとアイデンティティ・サーバー間の通信のセキュリティ・レベルを指定します。詳細は、「トランスポート・セキュリティ・モードの変更」を参照してください。
サポートされるトランスポート・セキュリティ・モードは、次のとおりです。
オープン: トランスポート・セキュリティは適用されません。
簡易: 基本セキュリティが提供されます。通信は、Transport Layer Security、RFC 2246（TLS v1）を使用して暗号化されます。通信要素は、パスワード・ベースのメカニズムを使用して相互に認証を行います。簡易セキュリティを使用するすべての要素は、インストール環境全体で同じパスワードを使用する必要があります。Oracle Access Managerでは、認証を実行する証明書が提供されます。
証明書: 内部認証局（CA）を管理する場合に使用します。通信は、TLS v1を使用して暗号化されます。クライアントとサーバーは、接続の確立時にVeriSign社などのサード・パーティのX.509証明書を提出する必要があります。
|
注意: アイデンティティ・サーバーとWebパスでは、同じトランスポート・セキュリティ・モードを使用する必要があります。必要に応じて、インストール済のコンポーネントごとにこれらの手順を繰り返してください。 |
「最大セッション時間(時間)」フィールドに、Webパスとアイデンティティ・サーバー間の接続をクローズして新規接続をオープンするまでの最大時間（時間単位）を指定します。
アイデンティティ・サーバーの構成で最大セッション時間が設定されている場合は、その設定が、接続されているすべてのWebパス・インスタンスに適用されます。Webパスとアイデンティティ・サーバーの両方の構成でこのパラメータが設定されている場合は、2つのうち低い方の値が使用されます。
「フェイルオーバーしきい値」フィールドに、プライマリ・アイデンティティ・サーバーに対する接続の最大数を指定します。
プライマリ・サーバーのみではこの数に満たない場合、Webパスではセカンダリ・サーバーを使用してこの数を確保しようとします。たとえば、このフィールドに4が指定された状態で、プライマリ・アイデンティティ・サーバーに対する使用可能な接続数が3に減少した場合、Webパスではセカンダリ・サーバーに対する接続をオープンしようと試みます。
Webパスとアイデンティティ・サーバー間のフェイルオーバーを構成する方法の詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。
「アイデンティティ・サーバー・タイムアウトしきい値」フィールドに、応答しないアイデンティティ・サーバーにWebパスで接続を試みた後、そのサーバーを接続不可能とみなして別のサーバーへの接続を試みるまでの時間（秒単位）を指定します。
タイムアウトの値を-1に設定（タイムアウトが適用されません）することをお薦めします。これを下回る値に設定すると、アイデンティティ・サーバーからリプライを受け取る前にソケット接続がクローズする危険性が発生します。アイデンティティ・サーバーでリクエストの処理に要する時間が、タイムアウトしきい値の値よりも長い場合、Webパスはリクエストを中止して別のアイデンティティ・サーバーへの接続を試み、応答しないとみなすまでそのアイデンティティ・サーバーにリクエストします。ただし、すべてのアイデンティティ・サーバーでリクエストの処理に要する時間が、タイムアウトしきい値の値よりも長い場合、再試行はサーバーが停止するまで継続されます。globalparams.xmlのclient_request_retry_attemptsパラメータを使用すると、応答しないサーバーで実行するWebパスの試行回数の制限を構成できます。詳細は、「応答しないアイデンティティ・サーバーへの再試行回数を構成する手順」を参照してください。
「スリープ時間（秒）」フィールドに、Webパスでアイデンティティ・システムとの接続をチェックする間隔を指定します。
フェイルオーバーしきい値に満たないためにセカンダリ接続が現在使用中の場合に、最小接続数のチェックに加え、同じチェックによりプライマリ・サーバー接続の再確立も試行されます。
「保存」をクリックしてWebパス・プラグインを追加します（保存せずにこのページを終了する場合は、「取消」をクリックします）。
「保存」をクリックすると、「すべてのWebパスをリスト」ページにWebパス・プラグインが表示されます。
Webパス・プラグインを1つ以上のアイデンティティ・サーバーに関連付けます（「アイデンティティ・サーバーとWebパスの関連付けの管理」を参照してください）。
アイデンティティ・システム・コンソールで、「システム構成」サブタブをクリックし、次に左側のナビゲーション・ペインの「Webパス」をクリックします。
「すべてのWebパスをリスト」ページが表示されます。このページで、Webパスを追加、変更または削除できます。
「すべてのWebパスをリスト」ページで、変更するWebパスの名前をクリックします。
「WebPassの詳細」ページが表示されます。
「変更」をクリックします。
「Webパスの変更」ページが表示されます。
必要に応じてパラメータを変更します。
「保存」をクリックして変更を保存します（保存せずにこのページを終了する場合は、「取消」をクリックします）。
ここでのWebパスの削除は、構成済のWebパス・インスタンスのリストからWebパスを除外することを意味します。WebパスをWebサーバー・インスタンスから削除するには、Webパスをアンインストールする必要があります。
|
関連項目: 『Oracle Access Managerインストレーション・ガイド』の「Oracle Access Managerの削除」の章を参照してください。 |
アイデンティティ・システム・コンソールで、「システム構成」サブタブをクリックし、次に左側のナビゲーション・ペインの「Webパス」をクリックします。
「すべてのWebパスをリスト」ページが表示されます。このページで、Webパスを追加、変更または削除できます。
「すべてのWebパスをリスト」ページで、削除するWebパス・インスタンスの横のチェック・ボックスを選択します。
「削除」をクリックします。
プロンプトが表示されたら、「OK」をクリックして操作を確認します。
構成済のWebパス・インスタンスのリストからWebパス・インスタンスが削除されます。
|
注意: アイデンティティ・システム・コンソールでWebパス・インスタンスを削除しても、アンインストール・プログラムを実行しなければ、そのWebパス・インスタンスはWebサーバーの再起動時に再度ディレクトリ・サーバーに追加されます。 |
状況によっては、Webパス・パラメータの変更が必要となります。最大セッション時間やフェイルオーバーしきい値などの一部のパラメータは、アイデンティティ・システム・コンソールで変更できます。コマンドライン・ツールのsetup_webpassを使用すると、ホスト・コンピュータ名やトランスポート・セキュリティ・モードなどの他のパラメータを変更できます。
通常は、コマンドライン・ツールを使用してトランスポート・セキュリティ・モードを変更します。このツールは、WindowsとUNIX（LinuxとSolaris）の両方のインストール環境で使用できます。
次の場所に移動します。
WebPass_install_dir\identity\oblix\tools\setupWebPass
ここで、WebPass_install_dirは、Webパスがインストールされているディレクトリです。
setupWebPassディレクトリで、setup_webpassツールを実行します。
表7-6のコマンドを使用してパラメータを指定できます。
表7-6 setup_webpassのコマンド
| コマンド | 操作 |
|---|---|
|
[-i install_dir] |
Webパスのインストール・ディレクトリを指定します。 |
|
[-q] [-n WebPass _ID] |
WebパスIDを指定します。 |
|
[-h Identity_Server_Host_Name] |
アイデンティティ・サーバーがインストールされているコンピュータの名前を指定します。 |
|
[-p Identity_Server_port_#] |
アイデンティティ・サーバーがインストールされているコンピュータのポート番号を指定します。 |
|
[-s open|simple|cert |
トランスポート・セキュリティ・モードを指定します。 |
|
[-P simple|cert mode password] |
簡易または証明書トランスポート・セキュリティ・モードのパスワードを指定します。 |
|
[-c request|install] |
証明書のリクエストまたはインストールを指定します。 |
コマンドラインによりトランスポート・セキュリティ・モードを再構成する手順
Webパスのトランスポート・セキュリティ・モードを再構成するには、コマンドラインで次のコマンドを実行します。
setup_webpass -i WebPass_install_dir -m
Webパスのトランスポート・セキュリティ・モードを選択します。
| 「オープン」を選択する場合 | 「簡易」を選択する場合 | 「証明書」を選択する場合 |
|---|---|---|
| トランスポート・セキュリティ・モードは、オープン・モードで実行するよう再構成されます。 | システムによりパスワードを求められます。 |
|
証明書モードの場合、情報を入力すると、証明書リクエストが生成されてIdentity Server_install_dir\identity\oblix\config\ois_req.pemファイルに配置されます（IdentityServer_install_dirは、アイデンティティ・システムがインストールされているディレクトリです）。
この証明書リクエストは、認証局の署名を受ける必要があります。
証明書インストールを指定した場合、証明書キー・ファイル、証明書ファイルおよび証明書連鎖ファイルの場所を示すフルパスを求められます。
パスを指定すると、トランスポート・セキュリティ・モードが再構成されます。詳細は、「トランスポート・セキュリティ・モードの変更」を参照してください。
トランスポート・セキュリティ・モードのパスワードを変更する手順
コマンドラインで次のコマンドを実行します。
setup_webpass -i WebPass_install_dir -k
次の情報を入力します。
旧パスワード
新パスワード
新パスワードの再確認
パスワードが変更されます。
Webパスからのリクエストを受信する1つ以上のアイデンティティ・サーバーを選択する必要があります。1つのアイデンティティ・サーバーは、複数のWebパスに関連付けることができます。Webパス・インスタンスに関連付けられているプライマリおよびセカンダリのアイデンティティ・サーバーのリストを表示することが可能です。また、次の手順を使用することで、ロード・バランシングおよびフェイルオーバーのためにアイデンティティ・サーバーとWebパス間に構成されている接続の数を変更できます。
アイデンティティ・システム・コンソールで、「システム構成」サブタブをクリックし、次に左側のナビゲーション・ペインの「Webパス」をクリックします。
「すべてのWebパスをリスト」ページが表示されます。このページで、Webパスを追加、変更または削除できます。
Webパスのリンクをクリックします。
「WebPassの詳細」ページが表示されます。
「アイデンティティ・サーバーをリスト」ボタンをクリックします。
Webパスに構成されているプライマリ・サーバーとセカンダリ・サーバーをリストしたページが表示されます。
アイデンティティ・サーバーのリンクをクリックしてその詳細を表示します。
「アイデンティティ・サーバーの詳細」ページが表示されます。
アイデンティティ・システム・コンソールで、「システム構成」サブタブをクリックし、次に左側のナビゲーション・ペインの「アイデンティティ・サーバー」をクリックします。
「すべてのアイデンティティ・サーバーをリスト」ページが表示されます。このページで、Webパスを追加、変更または削除できます。
適切なサーバーのリンクをクリックします。
「アイデンティティ・サーバーの詳細」ページが表示されます。
「アイデンティティ・サーバーの詳細」ページで、「変更」をクリックします。
アイデンティティ・サーバーの詳細がリストされた「アイデンティティ・サーバーの変更」ページが表示されます。
必要に応じて、「スレッド数」フィールドの値を変更します。
「保存」をクリックして変更を保存します。
アイデンティティ・サーバーを再起動します。
アイデンティティ・システム・コンソールで、「システム構成」サブタブをクリックし、次に左側のナビゲーション・ペインの「Webパス」をクリックします。
「すべてのWebパスをリスト」ページが表示されます。このページで、Webパスを追加、変更または削除できます。
適切なWebパスのリンクをクリックします。
「Webパスの詳細」ページで、「COREidサーバーのリスト」をクリックします。
次のページに、Webパスに関連付けられているプライマリ・サーバーとセカンダリ・サーバーがリストされます。
「追加」をクリックします。
「Webパスへ新規アイデンティティ・サーバーを追加」ページが表示されます。
「サーバーの選択」リストでアイデンティティ・サーバーを選択します。
このアイデンティティ・サーバーがプライマリ・サーバーかセカンダリ・サーバーかを指定します。
この情報は、ロード・バランシングおよびフェイルオーバーのために必要です。
「接続数」ボックスで、Webパス・インスタンスによりこのアイデンティティ・サーバーに対してオープンする接続の最大数を指定します。
最小数は1です。ロード・バランシングおよびフェイルオーバーのためにより多くの接続を追加できます。
「追加」をクリックしてこのアイデンティティ・サーバーをWebパスに関連付けます。
テキスト・エディタで次のファイルを開きます。
IdentityServer_install_dir/apps/common/bin/globalparams.xml
client_request_retry_attemptsパラメータをこのファイルに追加します。
次に、例を示します。
<SimpleList>
<NameValPair
ParamName="client_request_retry_attempts" Value="3">
</NameValPair>
</SimpleList>
アイデンティティ・サーバーでリクエストの処理に要する時間が、「アイデンティティ・サーバー・タイムアウトしきい値」の値よりも長い場合、Webパスは継続してアイデンティティ・サーバーに接続しリクエストを試行します。このパラメータを使用すると、Webパスが試行する再試行回数に制限を設定できます。このパラメータは整数値を使用します。デフォルトの-1では、再試行の回数が制限されません。
状況によっては、アイデンティティ・サーバーとWebパス・インスタンスの関連付けの解除が必要となります。たとえば、所属部署のコンピュータ・リソースが再割当てされる場合です。この場合、Webパスとアイデンティティ・サーバーの関連付けの妥当性が失われる可能性があります。そのため、相互の関連付けを解除する必要があります。関連付けを解除しないと、Webパスでは引き続き同じアイデンティティ・サーバーがポーリングされるため、Webサーバーのパフォーマンスが低下します。
|
注意: Webパスにただ1つのプライマリ・サーバーが構成されている場合、そのアイデンティティ・サーバーとの関連付けは解除できません。 |
アイデンティティ・サーバーとWebパスの関連付けを解除する手順
アイデンティティ・システム・コンソールで、「システム構成」サブタブをクリックし、次に左側のナビゲーション・ペインの「Webパス」をクリックします。
既存のWebパスをクリックします。
「アイデンティティ・サーバーをリスト」をクリックします。
関連付けを解除するアイデンティティ・サーバーの横のチェック・ボックスを選択します。
「削除」をクリックします。
プロンプトが表示されたら、「OK」をクリックして削除を確認します。
これで、このWebパス・インスタンスでは、関連付けを解除したアイデンティティ・サーバーと通信できなくなります。
Webパスは、webpass.xmlファイルで指定された間隔に基づき、アイデンティティ・サーバーに更新リクエストを送信します。デフォルト値は60秒です。
アイデンティティ・サーバーは更新リクエストに応答すると、アイデンティティ・システム・コンソールを使用して指定されディレクトリに格納された構成情報を読み取ります。webpass.xmlのrefreshパラメータがtrueに設定されている場合、アイデンティティ・サーバーはwebpass.xmlを最新情報に更新します。これには、次の最新の設定が含まれます。
最大接続数: このWebパスでアイデンティティ・サーバーに対してオープンする接続の最大数
最大セッション時間(時間): Webパスとアイデンティティ・サーバー間の接続をオープン状態のまま維持する最大時間この時間が経過すると、既存の接続はクローズされて新規接続がオープンされます。アイデンティティ・サーバーの構成で最大セッション時間が設定されている場合は、その設定が、接続されているすべてのWebパス・インスタンスに適用されます。Webパスとアイデンティティ・サーバーの両方の構成でこのパラメータが設定されている場合は、2つのうち低い方の値が使用されます。
「アイデンティティ・サーバー・タイムアウトしきい値: 応答しないアイデンティティ・サーバーにWebパスで接続を試みた後、そのサーバーを接続不可能とみなして別のサーバーへの接続を試みるまでの時間
フェイルオーバーしきい値: 稼働しているプライマリ・サーバーの数が下回るとフェイルオーバーが発生する指定数
スリープ時間（秒）: 接続に失敗してからファイルオーバーが発生するまでの間隔
プライマリ・サーバー・ホスト、ポートおよび接続数
セカンダリ・サーバー・ホスト、ポートおよび接続数
マルチプロセス環境では、多数のプロセスがアイデンティティ・サーバーをポーリングします。たとえば、実行中のプロセスの数が100で、各プロセスでwebpass.xmlファイルへの更新が発生するとします。考えられる負荷を排除するために、Oracle Access Managerでは、1つのプロセスのみが特定の時にポーリング追跡情報を取得できます。いずれかの構成の変更が検知されると、webpass.xmlファイルが決められた時間に更新されます。
パッチ・セット1、10g（10.1.4.2.0）以降では、管理者がPollTrackingRefreshIntervalパラメータをwebpass.xmlファイルで構成できます。ディレクトリで1つ以上の構成仕様が変更された場合のみ、ポーリング追跡情報を取得するプロセスがwebpass.xmlファイルへの更新を起動します。それ以外の場合、プロセスは現行のwebpass.xmlファイルのタイムスタンプを最新のwebpass.xmlファイルのタイムスタンプと比較します。
タイムスタンプが異なる場合、管理者がwebpass.xmlファイルを変更したことを示します。このとき、プロセスはPollTrackingRefreshIntervalパラメータを読み込み、値で指定された次の間隔まで待機します。他のすべてのプロセスは、ホスト・コンピュータ上のwebpass.xmlファイルを読み込み、PollTrackingRefreshIntervalパラメータ値で指定された次の間隔まで待機します。
ポーリング間隔はWebサーバー固有ではありません。ただし、このパラメータを使用して指定した間隔は、ApacheなどのマルチプロセスWebサーバーを使用する場合に、明白で効果的な影響を与えます。
PollTrackingRefreshIntervalパラメータを60秒より長い間隔に設定すると、アイデンティティ・サーバーで最新の構成情報を取得して、ディレクトリ・サーバーとwebpass.xmlファイルを同期化できます。60秒より長い間隔に値を設定すると、アイデンティティ・サーバーがwebpass.xmlの更新を繰り返さないため、Webサーバーを何度も再起動する必要がありません。
PollTrackingRefreshIntervalパラメータは、webpass.xmlファイルで次のように表示されます。値は任意の長さに指定できます（32767秒、約9時間まで）。ただし、値が大きいと、システム・コンソールを使用して変更されディレクトリに記録された構成の変更と、Webパスが同期されません。
<SimpleList>
<NameValPair ParamName="PollTrackingRefreshInterval" Value="60" />
</SimpleList>
このパラメータは、アイデンティティ・システム・コンソールを使用して構成できません。PollTrackingRefreshInterval値の変化は、明示的に表示されません。ただし、oblog_config_wp.xmlファイルのLOGLEVEL_DEBUG1を設定して、動作を検証できます。Webパスがポーリング追跡間隔を待機するたびに、メッセージがロギングされます。ロギング構成の詳細は、第10章を参照してください。
WebパスWebコンポーネントのインストール・ディレクトリにあるwebpass.xmlファイルを探します。次に例を示します。
oam1014\webcomp\nsapi\identity\oblix\apps\webpass\bin\webpass.xml
パス名で、oam1014\webcomp\nsapiはSun（旧名称Netscape/iPlanet）Webサーバー用のOracle Access Manager Webパスがインストールされたディレクトリを表します。パス名のこの部分は、WebPass_install_dirとも呼ばれます。
ファイルをエディタで開き、必要に応じ、PollTrackingRefreshIntervalを変更します。次に例を示します。
<SimpleList>
<NameValPair ParamName="PollTrackingRefreshInterval" Value="180" />
</SimpleList>
ファイルを保存します。
設定した間隔の値に基づき、パラメータは即時に有効になります。アイデンティティ・サーバーまたはWebサーバーの再構成または再起動は必要ありません。
パスワード・ポリシーは、ユーザーが作成するパスワードの種類とパスワードの有効期間を制御する一連のルールで構成されます。パスワード・ポリシーにより、ユーザーへのパスワード期限切れの通知方法、ユーザーによる期限切れパスワードのリセット方法、およびユーザーによるロスト・パスワードの回復方法も制御されます。
パスワード・ポリシーは、アイデンティティ・システムで作成します。これらのポリシーは、アイデンティティ・システムとアクセス・システムに対してログインを試みるユーザーに適用されます。また、これらのポリシーは、アクセス・システムにより保護されているリソースにアクセスしようとするユーザーにも適用されます（「アクセス・システムでのパスワード・ポリシーの実施」を参照してください）。
パスワード・ポリシーで制御されるパスワードの特性およびライフ・サイクルは、次のとおりです。
有効なパスワードのルール。
有効なパスワードのルールには、パスワードとして使用できる最低文字数や、使用する必要のある文字のタイプが含まれます。たとえば、数字と文字の両方を必ず含めるよう強制できます。
パスワード・プロパティは、アイデンティティ・システム・コンソールで構成します。
有効なパスワードを構成するための追加ルールを定義する場合、アイデンティティ・イベントAPIに付属するパスワード・ポリシー実施用の外部フックを使用できます。詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
ロスト・パスワード管理のためのチャレンジ・フレーズとレスポンス。
ロスト・パスワードを回復する際に、1つ以上のチャレンジ・フレーズに回答するようユーザーに強制できます。また、チャレンジ・フレーズのルールを構成できます。たとえば、複数のチャレンジに対して同じレスポンスを使用することを禁止できます。1つ以上のチャレンジ・フレーズに正しく回答した場合、ユーザーはパスワード・リセット・ページにリダイレクトされます。パスワードのリセット後、ユーザーはログインを許可されます。
パスワード期限切れおよびパスワード・リセットの設定。
パスワードの有効期間を指定し、パスワード期限切れが迫ったときに電子メールやログイン時の画面でそのことをユーザーに通知できます。また、URLリダイレクトを構成して、パスワードのリセット後にユーザーを当初リクエストされたリソースに戻すことが可能です。
不適切なパスワード入力後のアカウント・ロックアウト。
一定の時間内に不適切なパスワードを何回入力したらそのユーザーをロックアウトするかを構成できます。
アクセス・システムでは、ユーザーIDまたはリクエストされたリソース情報を含まないロックアウトURLを構成することもできます。
パスワード・リセット・ページおよびロスト・パスワード管理ページ用のスタイルシート。
アクセス・システムでは、ユーザーをこれらのページにリダイレクトできますが、これらのページ自体はアイデンティティ・システムに存在します。これらのページに対して、アイデンティティ・システムに付属する様々なスタイルシートを構成できます。
ディレクトリ内の個々のドメインに対応する一意のパスワード・ポリシー。
ディレクトリ・ツリーの異なるブランチに対応するパスワード・ポリシーの個別セットを作成できます。
最近の成功したログイン試行と失敗したログイン試行のログ。
ディレクトリに書き込まれたこれらのログには簡単にアクセスできます。監査ログに含まれる履歴データに加え、これらのログが提供されます。
この項には、次の各項目が含まれます。
異なるドメインに対して異なるパスワード・ポリシーを構成できます。1つのドメインは、ディレクトリ・ツリーに含まれる特定ノードの下の領域です。
ユーザーは、ドメイン内で複数のポリシーの制御下に置かれる場合があります。この場合、パスワード・ポリシーは、下から上へと評価されます。ユーザーに適用される最初のポリシーは、図7-1のように選択されます。
この例では、4つのパスワード・ポリシーがJohn Smithに適用されています。パスワード・ポリシー4は、ディレクトリ・ツリーの最下位レベル（cn）に存在するため、このポリシーが最初に評価されて実施されます。
Oracle Access Managerでパスワード・ポリシーを構成する際には、適切なパスワード・ポリシー・ドメイン（たとえばou=users,dc=example,dc=com）用にディレクトリ・サーバーで構成した、既存のパスワード・ポリシーを評価する必要があります。ディレクトリ・サーバーに含まれるパスワード・ポリシーがOracle Access Managerのポリシーと競合する場合は、予期しない動作が発生します。
たとえば、Oracle Access Managerで「最大ログイン試行回数」の設定を構成すると、ユーザーがロックアウトされるまでにパスワードの入力を試行できる回数を指定できます。この設定で構成した回数よりも少ない再試行回数でユーザーがロックアウトされる場合は、ディレクトリ・サーバーのパスワード・ポリシーと競合する可能性があります。Oracle Access Managerのパスワード・ポリシーを構成する前に調べておく必要があるディレクトリ・サーバーの設定の例を次に示します。次の設定は、RFC準拠のポリシー要素です。
pwdlockout=n: ログイン試行の失敗がここに指定された回数に達すると、ユーザーはロックされます。
orclpwdiplockout=n: ここに指定された秒数が経過するまで、ユーザーはログインを再試行できません。
pwdminlength=n: ユーザーは、ここに指定された文字数に達しないパスワードを設定できません。
マスター管理者は、アイデンティティ・システム・コンソールでパスワード・ポリシーを構成できます。すべてのドメインに適用するデフォルト・パスワード・ポリシーを作成できます。また、特定のディレクトリ・ドメインに対応するパスワード・ポリシーを定義することや、1つのドメイン内に複数のポリシーを定義することも可能です。
この項には、次の各項目が含まれます。
パスワード・ポリシーは、アイデンティティ・システム・コンソールの「パスワード・ポリシー管理」ページで参照できます。
アイデンティティ・システム・コンソールで、「システム構成」サブタブをクリックします。
左側のナビゲーション・ペインの「パスワード・ポリシー」をクリックします。
「パスワード・ポリシー管理」ページが表示されます。このページには、すべてのパスワードに適用されるデフォルト・パスワード・ポリシーと、定義されているドメイン固有のパスワード・ポリシーのリストが表示されます。
設定を表示するポリシーのリンクをクリックします。
このページには、選択したパスワード・ポリシーの仕様が表示されます。
パスワード・ポリシーのデフォルトを設定できます。これらのデフォルトには、ユーザーをパスワード変更ページ、パスワード期限切れ警告ページおよびカスタム・アカウント・ロックアウト・ページに移動できるURLが含まれます。これらのデフォルトは、ユーザーが作成するドメイン固有のポリシーにより上書きされます。
次のデフォルトを作成できます。
パスワード期限切れ警告のURL: この設定は、アクセス・システムにより保護されているリソースにのみ適用されます。
このURLにより、ユーザーは、期限切れ通知フォームにリダイレクトされます。オプションで、このURLによりユーザーをパスワード変更フォームにリダイレクトできます。また、このURLを使用して、ユーザーをパスワード変更後に当初リクエストされたリソースへ戻すことも可能です。
詳細は、「デフォルトのパスワード期限切れ警告のリダイレクトURLを設定する手順」を参照してください。
パスワード変更のリダイレクトURL: この設定は、アクセス・システムにより保護されているリソースにのみ適用されます。
この設定は、パスワード期限切れ警告のURLとほぼ同じです。このURLは、パスワード変更ページを参照します。オプションで、このURLによりユーザーを当初リクエストされたリソースにリダイレクトできます。
詳細は、「パスワード期限切れ後にパスワード・リセット・ページにリダイレクトするための構成」を参照してください。
ロスト・パスワードのリダイレクトURL: このURLは、パスワード管理システムの一部として簡単に使用できるように、Webページ上にPortal Insertsとして設定します。
アイデンティティ・システム・コンソールでは、情報目的でこのURLを記録します。
詳細は、「ロスト・パスワード管理」を参照してください。
カスタム・アカウント・ロックアウトのリダイレクトURL: このURLは、アクセス・システムにより保護されているリソースにのみ適用されます。
詳細は、「アカウント・ロックアウトのリダイレクトURLの設定」を参照してください。
アイデンティティ・サーバーには、デフォルトでロックアウト情報を表示するメカニズムが用意されています。アカウント・ロックアウトの動作をカスタマイズする場合、IDXMLプログラムで使用できるエラー・コードをアイデンティティ・システムから戻すことができます。詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
成功した認証イベント: この設定により、ユーザーがユーザー・ディレクトリ・サーバーへのログイン試行に成功した最新の時刻が書き込まれます。
デフォルトでは、情報はOblixPersonPasswordPolicyオブジェクト・クラスのoblastSuccessfulLogin属性に書き込まれます。この機能により、最も関連性の高いログイン情報に迅速にアクセスできます。履歴情報は、監査ログに含まれます。
失敗した認証イベント: この設定により、ユーザーがユーザー・ディレクトリ・サーバーへのログイン試行に失敗した最新の時刻が書き込まれます。
デフォルトでは、ログ認証情報はOblixPersonPasswordPolicyオブジェクト・クラスのoblastFailedLogin属性に書き込まれます。この機能により、最も関連性の高いログイン情報に迅速にアクセスできます。履歴情報は、監査ログに含まれます。
アイデンティティ・システム・コンソールで、「システム構成」サブタブをクリックします。
左側のナビゲーション・ペインの「パスワード・ポリシー」をクリックします。
「パスワード・ポリシー管理」ページが表示されます。
次の情報を入力します。
ロスト・パスワードのリダイレクトURL: これは、ユーザーがアイデンティティ・システムのロスト・パスワード管理ページに移動できるURLです。このフィールドに入力するURLは、情報目的専用です。実際のURLは、Portal Insertsで提供されます。詳細は、「ロスト・パスワード管理」を参照してください。
パスワード変更のリダイレクトURL: これは、パスワード変更フォームのURLです。詳細は、「パスワード期限切れ後にパスワード・リセット・ページにリダイレクトするための構成」を参照してください。
パスワード期限切れ警告のリダイレクトURL: パスワード期限切れ警告フォームのURLを入力します。詳細は、「パスワード期限切れ警告のリダイレクトURLの設定」を参照してください。
カスタム・アカウント・ロックアウトのリダイレクトURL: ロックアウト通知ページのURLを入力します。詳細は、「アカウント・ロックアウトのリダイレクトURLの設定」を参照してください。
次のように認証試行のロギングを設定します。
試行成功属性: デフォルトでは、この値はoblastSuccessfulLoginです。これは推奨値です。この値を変更するには、Personオブジェクト・クラスの文字列属性を入力するか、Personオブジェクト・クラスに関連付けられている補助クラスの文字列属性を入力します。
試行失敗属性: デフォルトでは、この値はoblastFailedLoginです。これは推奨値です。この値を変更するには、Personオブジェクト・クラスの文字列属性を入力するか、Personオブジェクト・クラスに関連付けられている補助クラスの文字列属性を入力します。
「有効化」をクリックしてロギング機能を有効化します。
「保存」をクリックします。
特定ドメイン用のパスワード・ポリシーを構成できます。グローバル・デフォルト設定は、これらの設定により上書きされます。これらのポリシーには、パスワード・ルールおよびパスワード・リダイレクトURLなどが含まれます。
特定ポリシー・ドメインでは、ユーザーに表示されるロスト・パスワード・ページおよびパスワード変更ページの外観をカスタマイズすることもできます。これらのページのデフォルトのスタイルシートは次のフォルダに格納されます。
IdentityServer_install_dir/identity/oblix/lang/language_id/style0
ここで、IdentityServer_install_dirはアイデンティティ・サーバーがインストールされているディレクトリで、language_idは言語パックが使用されているディレクトリです。デフォルトの言語パックはen-usで、デフォルトのスタイルシートはstyle0という名前のクラシック・スタイル・フォルダにあります。
ファイルlpm_cr.xsl and lpm_changepwd.xslは、元のスタイルシートです。これらのスタイルシートをコピーしてカスタマイズし、現在アクティブなスタイル・フォルダ内のファイルに配置します。関連するパスワード・ポリシーを変更して、アクティブなスタイル・フォルダのXSLファイルへの相対パスを示すこともできます。新規パスワード・ポリシーの構成後、アイデンティティ・サーバーでカスタム・パスワード・ポリシーのカスタム・スタイルシートが適用されます。アイデンティティ・サーバーでは、その他のすべてのパスワード・ポリシーでデフォルトのスタイルシートが使用されます。
詳細は、「アイデンティティ・システム・アプリケーションのスタイルの構成」を参照してください。『Oracle Access Managerカスタマイズ・ガイド』も参照してください。
デフォルト: ページ下部にある「デフォルト」ボタンを使用すると、「パスワード・ポリシー名」、「パスワード・ポリシー・ドメイン」、「パスワード・ポリシー・フィルタ」以外のすべてのフィールドに値が移入されます。「数値文字の最小数」フィールドにはデフォルト値がないため、「デフォルト」ボタンをクリックしても空のままです。「パスワードの最小期間」および「ログイン試行のリセット」にもデフォルト値はありません。そのため、「デフォルト」ボタンをクリックしてもこれらのフィールドは空のままです。
アイデンティティ・システム・コンソールで、「システム構成」サブタブをクリックし、左側のナビゲーション・ペインの「パスワード・ポリシー」をクリックします。次に、「パスワード・ポリシー管理」ページの「追加」をクリックします。
「パスワード・ポリシー名」フィールドに、ポリシーの名前を入力します。
「パスワード・ポリシー・ドメイン」フィールドに、このポリシーを適用するLDAPディレクトリのドメインを入力します。次に例を示します。
ou=corporate,o=company,c=us
オプションで、「パスワード・ポリシー・フィルタ」フィールドにLDAPフィルタを追加して、このパスワード・ポリシーを適用するドメインの一部をより詳細に定義できます。
たとえば、(title=System Administrator)と指定すると、このパスワード・ポリシーの適用先が一部の人々に制限されます。
「ロスト・パスワード・ポリシー」リストで、実施するロスト・パスワード・ポリシーの名前を選択します。
詳細は、「ロスト・パスワード管理」を参照してください。このフィールドを空白のままとすると、単一のチャレンジ・レスポンス・モデルが使用されます。
「パスワードの最小長」フィールドに、パスワードに含める必要のある文字の最小数を入力します。
デフォルトは8です。
「大文字の最小数」フィールドに、パスワードに含める必要のある大文字の最小数を入力します。
デフォルトは2です。
「小文字の最小数」フィールドに、パスワードに含める必要のある小文字の最小数を入力します。
デフォルトは2です。
「非英数字文字の最小数」フィールドに、パスワードに含める必要のある非英数字の最小数を入力します。
非英数字は、英字または数字以外の出力可能な任意の文字です。たとえば、+、!、@などです。
デフォルトは4です。
「数値文字の最小数」フィールドに、パスワードに含める必要のある数字の最小数を入力します。
デフォルトでは値は設定されません。ユーザーが指定する必要があります。
このパスワード・ポリシーに外部ルールを適用する場合、「外部的に指定された検証ルール」を選択します。
Oracle Access Managerでは、パスワード・ポリシー実施用の外部フックを提供しています。詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
「パスワード有効期間」フィールドで、次のいずれかのオプションを選択します。
パスワードの有効期限なし。
パスワードが期限切れになるまでの日数: このパスワードを有効とする日数を入力します。デフォルトは100です。このオプションを選択する場合、値を指定する必要があります。
「パスワード期限切れ通知期間」に、パスワード期限切れを何日前にユーザーに通知するかを指定します。
デフォルト値は1です。
「期限切れ通知の伝達モード」フィールドで、次のオプションの一方または両方を選択します。
ログイン時: ユーザーがログインすると、パスワードが期限切れになるまでの残り日数を示すメッセージが表示されます。
アイデンティティ・システムがアクセス・システムにより保護されている場合、パスワード期限切れ警告のリダイレクトURLを入力する必要があります。詳細は、「パスワード期限切れ警告のリダイレクトURLの設定」を参照してください。
電子メール: ユーザーは、パスワードが期限切れになるまでの残り日数を電子メールで通知されます。メッセージはカスタマイズできません。
「パスワードの最小期間」フィールドに、変更前にパスワードを使用し続ける必要のある日数を入力します。
デフォルトはありません。
管理者によるパスワードのリセット後、ユーザーが最初にシステムにログインしたときにパスワードの変更を強制する場合は、「リセット時に変更」を選択します。
「リセット時に変更」フラグはデフォルトで設定されます。自己登録時にも「リセット時に変更」フラグは設定されません。
このフィールドは、アイデンティティ・システムとアクセス・システムの両方に適用されます。アクセス・システム専用の場合、パスワード変更のためのリダイレクトURLも構成できます。詳細は、「パスワードのリダイレクトURLの構成」を参照してください。
|
注意: WebGateが有効な場合、アクセス・システムのパスワード・ポリシーで「リセット時に変更」機能が有効化されており「パスワード変更のリダイレクトURL」が指定されていないと、ログイン・プロンプトが再表示されます。この場合、ユーザーはパスワードを変更できず、最終的にはログインできなくなります。 |
「パスワード履歴」フィールドに、パスワード履歴を維持するかどうかを指定します。
デフォルトは5です。「パスワード履歴を保存しない」を選択するか、ユーザーごとに保存するパスワード数を入力します。保存されたパスワードはディレクトリに格納され、再利用はできません。
Oracle Access Managerでは、ディレクトリに保存されている最新のパスワードを判別できます。パスワードを削除する場合、Oracle Access Managerにより、残っているうちで最も古いパスワードが特定されます。
「最大ログイン試行回数」フィールドに、ユーザーのアカウントをロックするまでに許可するログイン試行回数を指定します。
デフォルト値は3です。この場合、ユーザーが不適切なログイン資格証明を使用して3回ログインを試みると、「ログイン試行のリセット」の値により指定されているログイン試行のリセット期間内に3回目のログイン試行が発生した後、ユーザーはロックアウトされます。不適切なログイン資格証明は、適切なユーザー名と不適切なパスワードで構成されます。ロックアウト期間中、ユーザーは適切な資格証明を入力してもログインできません。
|
注意: この設定は、ロスト・パスワード管理におけるチャレンジ・レスポンスの試行回数にも適用されます。 |
「ロックアウト継続時間」フィールドに、ユーザーによるログインの失敗回数が前の手順で指定された回数を超えた後にアカウントをロックし続ける時間数を指定します。
デフォルトは24時間です。ロックアウト継続時間の期限前にロックアウトを解除する場合、管理者はアイデンティティ・システムでユーザー・パスワードをリセットできます。管理者がパスワードをリセットする前に「パスワード・ポリシー管理」ページで「リセット時に変更」が選択されていた場合、ユーザーは、ログイン時に新パスワードを選択できるページにリダイレクトされます。
管理者が新パスワードを割り当てた時点で「リセット時に変更」が選択されていなかった場合、ユーザーは、管理者に割り当てられたパスワードでシステムにログインできます。
「ログイン試行のリセット」フィールドに、ログインの成功によって中断せずにログイン試行の失敗を格納する日数を指定します。
たとえば、この値を3に設定した場合、ユーザーがログインに1回失敗すると、アプリケーションではその失敗を3日間維持した後に消去します。デフォルト設定はありません。
オプションで、「ロスト・パスワードのリダイレクト・スタイルシート」にXSLスタイルシートへの相対パスを入力できます。
たとえば、スタイルシート・ファイルがIdentityServer_install_dir /identity/oblix/lang/en-us/style0/myStyleSheet.xslにある場合、/myStyleSheet.xslと入力します。
スタイルシート構成の詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。ロスト・パスワード・リダイレクションの詳細は、「ロスト・パスワード管理」を参照してください。
このフィールドを空白のままにすると、デフォルトのスタイルシートが使用されます。
オプションで、「パスワード変更のリダイレクト・スタイルシート」にXSLスタイルシートへの相対パスを入力できます。
たとえば、スタイルシート・ファイルがIdentityServer_install_dir /identity/oblix/lang/en-us/style0/myStyleSheet.xslにある場合、/myStyleSheet.xslと入力します。
スタイルシート構成の詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。パスワード変更フォームの詳細は、「パスワード期限切れ後にパスワード・リセット・ページにリダイレクトするための構成」を参照してください。
「デフォルト」オプションが選択されています。このフィールドを空白のままにすると、デフォルトのスタイルシートが使用されます。
オプションで、「パスワード期限切れ警告のリダイレクトURL」にデフォルト設定を上書きするURLを指定できます。
「デフォルト」オプションが選択されています。この設定は、アクセス・システムにのみ適用されます。このURLの詳細は、「パスワード期限切れ警告のリダイレクトURLの設定」を参照してください。
「カスタム・アカウント・ロックアウトのリダイレクトURL」に、ログイン試行回数を超えたユーザー用のリダイレクトURLを指定します。
「デフォルト」オプションが選択されています。この設定は、アクセス・システムにのみ適用されます。詳細は、「アカウント・ロックアウトのリダイレクトURLの設定」を参照してください。
「パスワード・ポリシー有効化」を選択してこのパスワード・ポリシーを有効化します。
後でこのフィールドの設定を変更した場合、またはこのパスワード・ポリシーになんらかの変更を加えた場合、パスワード・ポリシー・キャッシュをフラッシュする必要があります。アクセス・システム・コンソールで、「共通情報の構成」をクリックし、次に「パスワード・ポリシー・キャッシュのフラッシュ」タブをクリックします。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
「保存」をクリックしてこのポリシーを保存し、「パスワード・ポリシー管理」ページに戻ります。
ページのリストに新規ポリシーが表示されます。
この操作で「デフォルト」ボタンをクリックすると、「パスワード・ポリシー名」、「パスワード・ポリシー・ドメイン」および「パスワード・ポリシー・フィルタ」以外のすべてのフィールドにデフォルト値が移入されます。各パラメータの詳細は、「パスワード・ポリシーの評価順序」を参照してください。
アイデンティティ・システム・コンソールで、「システム構成」サブタブをクリックし、次に左側のナビゲーション・ペインの「パスワード・ポリシー」をクリックします。
「パスワード・ポリシー管理」ページにパスワード・ポリシーのリストが表示されます。
「パスワード・ポリシー管理」ページで、変更するポリシーをクリックします。
ポリシーのパラメータを含むページが表示されます。
必要に応じてパラメータを変更します。
「保存」をクリックします。
「パスワード・ポリシー管理」ページにパスワード・ポリシーのリストが表示されます。パスワードを保存すると、LDAPディレクトリに格納されます。Oracle Access Managerでは、最新のパスワードを判別できます。パスワードを削除する場合、Oracle Access Managerにより最も古いパスワードが特定されます。
アイデンティティ・システム・コンソールで、「システム構成」サブタブをクリックし、次に左側のナビゲーション・ペインの「パスワード・ポリシー」をクリックします。
「パスワード・ポリシー管理」ページで、削除するポリシーの横のチェック・ボックスを選択します。
「削除」をクリックします。
削除を確認するプロンプトが表示されたら、「OK」をクリックします。
ロスト・パスワード管理により、ユーザーは、自分のパスワードを忘れた場合にパスワードをリセットできます。ロスト・パスワード管理は、次の要素で構成されます。
チャレンジ・フレーズに回答できるページにユーザーを移動する、ログイン・ページ上の「パスワードの紛失」ボタン。
ロスト・パスワード管理を実装するには、ロスト・パスワード管理ページのURLを作成し、そのリンクをWebページに配置してユーザーがロスト・パスワード管理機能にアクセスできるようにします。これらのURLは、Portal Insertsと呼ばれます。詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
チャレンジ・フレーズおよびレスポンスのフィールドを含むロスト・パスワード管理ページ。
ロスト・パスワード管理URLにより、ユーザーは、1つ以上のチャレンジ質問を含むアイデンティティ・システム・ページにルーティングされます。
ユーザーがチャレンジに正しく回答した場合に表示されるパスワード・リセット・ページ。
正しいレスポンスを入力すると、ユーザーは、アイデンティティ・システムで新パスワードを設定できます。
ユーザーを当初リクエストされたページにリダイレクトできる追加機能。
パスワード・ポリシーのロスト・パスワード管理URLは、記録保持のためにアイデンティティ・システム・コンソールで記録します。特定のドメイン用のロスト・パスワード管理ポリシーを構成できます。
アイデンティティ・システムでは、RSAのライセンスに基づく暗号化スキームによりレスポンス値が暗号化されます。この暗号化スキームは、Secure Hash Algorithm（SHA）とは異なります。デフォルトの暗号化機能を独自の機能で置き換えるには、IDイベント・プラグインAPIを使用してカスタム・アクションを記述します。これは、アイデンティティ・システムにインポートできる既存のチャレンジ属性とレスポンス属性が存在する場合に便利です。詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
ロスト・パスワード管理は、デフォルトで有効化されます。つまり、ログイン・ページにボタンが表示され、ユーザーがそれをクリックすると、ロスト・パスワード管理の有効なWebページに移動します。ロスト・パスワード・ポリシーが作成されていない場合は、チャレンジ・レスポンスを構成する必要があることを示すメッセージがロスト・パスワード管理のWebページに表示されます。
|
注意: アイデンティティ・システムで入力する他のリダイレクトURLとは異なり、ロスト・パスワード管理のリダイレクトURLは、情報目的専用で入力します。その主な場所は、Portal Insertsです。 |
ディレクトリに2つの新規属性を作成します。1つの属性はユーザーに表示するチャレンジ用として使用し、もう1つの属性はユーザーがチャレンジに回答するレスポンス用として使用します。
ロスト・パスワード管理をサポートするため、ユーザーに表示するチャレンジの値とそれらのチャレンジに対するレスポンスの値を格納する属性のペアを定義します。たとえば、「チャレンジ」および「レスポンス」という属性のペアを定義します。アイデンティティ・システム・コンソールで、これらの属性に「チャレンジ」および「レスポンス」セマンティク型を割り当てます。詳細は、「ディレクトリでチャレンジ・タイプおよびレスポンス・タイプの属性を構成する手順」を参照してください。
アイデンティティ・システム・コンソールで、Personオブジェクト・クラスの属性を変更します。
チャレンジ・フレーズを格納する属性と、そのチャレンジ・フレーズに対するユーザーのレスポンスを格納する属性を構成します。
詳細は、「ロスト・パスワード管理属性を構成する手順」を参照してください。
ユーザー・マネージャで、これらの属性の属性アクセス制御を構成します。
プロファイル・ページのチャレンジとレスポンスを表示および変更する場合、ユーザーは、チャレンジとレスポンスに対する読取り権限と変更権限を保持する必要があります。詳細は、「ユーザーによるLDAPデータの表示および変更の許可」を参照してください。
ユーザーがプロファイル・ページを参照または変更するときに表示されるように、ユーザー・プロファイル・ページにチャレンジ属性とレスポンス属性を追加します。
ロスト・パスワード管理で、ユーザーはチャレンジ・フレーズを含むページに移動されます。チャレンジ・フレーズおよびレスポンスの入力フィールドを含むページは、ユーザー・マネージャで構成するプロファイル・ページです。プロファイル・ページには、チャレンジ質問と同じ数のチャレンジとレスポンスのペアを含める必要があります。詳細は、「タブのプロファイル・ページおよびパネルの構成」を参照してください。ユーザーは、関連する属性に独自の読取りまたは書込み権限がない場合でも、ログイン中にチャレンジを構成できることに注意してください。
|
注意: LPM機能では、チャレンジ属性とレスポンス属性を同時に変更する必要はありません。たとえば、委任管理者がユーザーのチャレンジ質問を設定する一方で、レスポンスを設定しないことも可能です。1つのフィールドに複数のチャレンジ質問が入力されますが、各質問へのレスポンスは個々に入力する必要があります。詳細は、このタスクの概要の手順10を参照してください。 |
ワークフロー・ステップ・ページを構成してこれらの属性を使用します。
チャレンジ・フレーズとレスポンスは、後でパスワード取得に使用できるように、自己登録の実行中に構成する必要があります。あまり一般的ではありませんが、ユーザーの作成ワークフローを使用して、ワークフローの参加者に新規ユーザー用のチャレンジ・フレーズを構成させることも可能です。詳細は、「アイデンティティ機能とワークフローの連携」を参照してください。ワークフロー・ステップ・ページでは、チャレンジ・パラメータに対する読取りまたは書込み権限は必要ありません。
アイデンティティ・システム・コンソールでロスト・パスワード管理ポリシーを構成します。
詳細は、「ロスト・パスワード管理ポリシーの表示と構成」を参照してください。
ロスト・パスワード管理URLをサード・パーティ・アプリケーションまたはポータル・ページに挿入します。
詳細は、この項の情報を参照してください。Portal Insertsの詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
パスワード・ポリシーを構成してロスト・パスワード管理ポリシーを含めます（「パスワード・ポリシーの管理」を参照してください）。
ユーザー・プロファイルのチャレンジ属性とレスポンス属性の値を変更します（「ユーザー・プロファイルの変更」を参照してください）。
ロスト・パスワード管理URLの形式は、次のとおりです。
http://hostname:portnumber/identity/oblix/apps/lost_pwd_ mgmt/bin/lost_pwd_mgmt.cgi?program=passwordChallengeResponse&login=%scheme1_uid_parameter_value%%scheme2_uid_parameter_ value%%schemeN_uid_parameter_value%&target=top
このURLは、「パスワード期限切れ後にパスワード・リセット・ページにリダイレクトするための構成」で説明しているパスワード期限切れリセットのURLと似ています。2つのURLタイプの違いの1つは、次のパラメータ部分です。
program=passwordChallengeResponse
もう1つの違いは、このURLにユーザーIDなどの変数を指定する場合、対応するcgiスクリプトを変更してユーザーのログインIDを渡す必要があることです。または、次のURL構文を使用して、ロスト・パスワード・リセット・ページへのリダイレクト後にユーザーにユーザーIDを再入力させる必要があります。
http://hostname:portnumber/identity/oblix/apps/lost_pwd_ mgmt/bin/lost_pwd_mgmt.cgi?program=passwordChallengeResponse&target=top
前述のURLのlost_pwd_mgmt.cgiは、Oracle Access Managerに付属しています。
ロスト・パスワード管理は、単一または複数のチャレンジ・レスポンス・システムとして構成できます。チャレンジとレスポンスのペアは、次の場所に表示されます。
ユーザー・アカウントの作成ワークフローでは、ワークフロー・ステップにチャレンジ属性とレスポンス属性のエントリが含まれます。
「プロファイルの表示」および「プロファイルの変更」ページには、チャレンジとレスポンスのペアが表示されます。
ロスト・パスワード管理では、ユーザーは1つ以上のチャレンジ・フレーズに回答する必要があります。
構成済のチャレンジの数が、ユーザーに適用されるロスト・パスワード・ポリシーで必要とされる数より少ない場合、ユーザーは、Oracle Access Managerへのログイン時に追加のチャレンジを指定するよう求められます。
ロスト・パスワード管理ページにチャレンジとレスポンスのプロンプトを指定する以外に、このページに追加の情報を指定できます。たとえば、ロスト・パスワード管理のチャレンジに正しく回答したユーザーをパスワード・リセット・ページに移動するリンク（またはワークフロー・ステップ）を構成できます。
ロスト・パスワード管理ポリシーがユーザーに適用される場合、ユーザーがロスト・パスワード管理URLをクリックすると、複数のチャレンジおよびレスポンス・フィールドが表示されます。ユーザーに表示されるチャレンジの数は、「回答する最小チャレンジ」フィールドにより決定されます。詳細は、「パスワード・ポリシー・ドメインのロスト・パスワード管理の構成」を参照してください。
「特定ドメイン用のパスワード・ポリシーの作成」に記載されているとおり、パスワード・ポリシーは、特定のドメインまたはユーザー・グループに適用されます。ユーザーにロスト・パスワード・ポリシーが適用されない場合、1つのチャレンジ・フレーズおよび1つのレスポンスの入力フィールドのみが表示されます。複数のチャレンジとレスポンスを構成していても、ロスト・パスワード・ポリシーがユーザーに適用されなければ、最初に構成されたチャレンジ・フレーズとレスポンスが表示されます。
構成済のチャレンジ・フレーズとレスポンスの数が、ロスト・パスワード・ポリシーに構成されている最小数未満の場合、ユーザーは、ログイン時に追加のチャレンジ・フレーズを構成するよう求められます。例として、最初のロスト・パスワード管理ポリシーの設定後に、チャレンジの最小数を増加するよう構成した場合を検討します。この場合、ユーザーがログインすると、次のいずれかの形式で追加のチャレンジ・フレーズが表示されます。
テキスト・ボックス: ロスト・パスワード管理ポリシーで「ユーザー」設定を選択した場合に表示されます。
事前定義されたフレーズを含む選択ボックス: ロスト・パスワード管理ポリシーで「事前定義」設定を選択した場合に表示されます。
事前定義されたフレーズを含むコンボ・ボックス: ロスト・パスワード管理ポリシーで「ユーザーまたは事前定義」設定を選択した場合に表示されます。
詳細は、「パスワード・ポリシー・ドメインのロスト・パスワード管理の構成」を参照してください。
ロスト・パスワード管理ポリシーでソース・タイプを変更した場合（たとえば、ソースを「ユーザー」から「事前定義」に変更した場合）、最小長を変更した場合、または「重複レスポンスを許可」フラグを変更した場合、それらの変更はユーザーが自分のプロファイルを変更するときに適用されます。
追加のチャレンジの構成を求めるプロンプトでユーザーに表示されるメッセージのタイプは、ロスト・パスワード管理ポリシーで変更された設定に応じて変化します。たとえば、レスポンスの最小長を3文字から8文字に変更したとします。ユーザーが自分のプロファイルの変更を保存しようとすると、「レスポンスが最小長の要件を満たしていません」というエラー・メッセージが表示されます。ポリシーでチャレンジの最小数を増やした場合、ユーザーは、ログイン時に必要な情報を指定するよう求められます。
次の手順では、ロスト・パスワード管理を構成する方法について説明します。
ディレクトリでチャレンジ・タイプおよびレスポンス・タイプの属性を構成する手順
ユーザーのチャレンジおよびレスポンスに使用する未使用で空の属性を2つディレクトリに用意します。
2つの適切な属性を使用できる場合、次の手順に進みます。
新規属性の追加: 新規属性を追加する必要がある場合、任意の方法を使用して属性を追加できます。
次に、新規補助オブジェクト・クラスと2つの新規属性を含むLDIFスキーマ・ファイルを作成する場合の例を示します。現在のディレクトリ・サーバー・タイプに適した構文を使用して、次のような属性を作成できます。
# ----------- Attributes --------------- # dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.9999.1.1094.204 NAME 'Challenge2' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.9999.1.1094.205 NAME 'Response2' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) # ----------- Object class --------------- # dn: cn=schema changetype: modify add: objectclasses objectclasses: ( 1.3.6.1.4.1.9999.1.1094.206 NAME 'oblixAuxPerson4LPM' DESC 'User defined objectclass' SUP top AUXILIARY MAY ( Challenge2 $ Response2 ) )
LDIFファイルをディレクトリにインポートします。
Oracle Access Managerで新規補助オブジェクト・クラスを構成するため、アイデンティティ・システム・コンソールで「共通構成」をクリックします。
左側のナビゲーション・ペインの「オブジェクト・クラス」をクリックします。
「追加」をクリックします。
リストから新規オブジェクト・クラスの名前を選択します。
Person構造化オブジェクト・クラスのオプション・ボタンを選択します。
これで、新規補助オブジェクト・クラスがPerson構造化オブジェクト・クラスに関連付けられました。このオブジェクト・クラスでチャレンジ・タイプとレスポンス・タイプの新規属性を構成できます（「ロスト・パスワード管理属性を構成する手順」を参照してください）。
Personオブジェクト・クラスの属性を構成してチャレンジ・フレーズを格納するには、アイデンティティ・システム・コンソールで「共通構成」をクリックします。
左側のナビゲーション・ペインの「オブジェクト・クラス」をクリックします。
Personオブジェクト・クラスのリンクをクリックします。
「属性の変更」をクリックします。
「属性」リストで、チャレンジ・フレーズに使用する属性を選択します。
これは、空の新規属性である必要があります。
次のように構成します。
詳細は、「オブジェクト・クラス属性の概要」および「属性の構成」を参照してください。
この属性のセマンティク型を「チャレンジ」に設定します。
データ型を大/小文字を区別する文字列に設定します。
「属性値」フィールドを「単一」に設定します。
表示タイプは、構成するポリシーのタイプに応じて自動的に構成されます。
「チャレンジ」などの適切な表示名を割り当てます。
|
注意: 複数のチャレンジ・フレーズを構成する場合、それらのフレーズは、チャレンジ属性用のユーザー・ディレクトリ・エントリに単一値として格納されます。各値は、エンコードされた形式で格納されます。 |
「属性」リストで、チャレンジ・フレーズに対するユーザーのレスポンスを格納するPersonオブジェクト・クラスの2番目の属性を選択します。
これは、空の新規属性である必要があります。
この属性を次のように構成します。
この属性のセマンティク型を「レスポンス」に設定します。
データ型を大/小文字を区別する文字列に設定します。
表示タイプを「パスワード」に設定します。
「属性値」フィールドを「単一」に設定します。
「レスポンス」などの適切な表示名を割り当てます。
|
注意: ロスト・パスワード管理ポリシーの一部として複数のチャレンジおよびレスポンスを構成する場合、ユーザーがレスポンスに指定した値は、レスポンス属性用のユーザー・ディレクトリ・エントリに単一値として格納されます。各値は、エンコードおよび暗号化された形式で格納されます。 |
表示する場所に応じて、これらの属性をユーザー・プロファイル・ページまたはワークフロー・ステップ・パネルに追加します。
アイデンティティ・システム・コンソールで、「システム構成」サブタブをクリックし、次に左側のナビゲーション・ペインの「ロスト・パスワード・ポリシー」をクリックします。
「ロスト・パスワード・ポリシー管理」ページで、表示するポリシーのリンクをクリックします。
oblixbaseparams.xmlファイルの場所を見つけます。
このファイルのデフォルト・パスは、次のとおりです。
IdentityServer_install_dir/identity/oblix/apps/common/bin/oblixbaseparams.xml
IdentityServer_install_dirは、アイデンティティ・サーバーがインストールされているファイル・システム・ディレクトリです。
Apply_LostPwdMgmtパラメータにYesが入力されていることを確認します。
デフォルトはYesです。Noを入力すると、この機能を無効化できます。
ファイルを保存して閉じます。
パスワード・ポリシー・ドメインのロスト・パスワード管理を構成する手順
アイデンティティ・システム・コンソールで、「システム構成」サブタブをクリックし、次に「ロスト・パスワード・ポリシー」をクリックします。
「ロスト・パスワード・ポリシー」ページで、「追加」をクリックします。
「ロスト・パスワード・ポリシーの追加」ページが表示されます。
「ロスト・パスワード・ポリシー名」フィールドに名前を入力します。
Oracle Internet Directoryを使用する環境では、この名前に特殊文字を含めることはできません。
「チャレンジ・フレーズ・ソース」で、チャレンジ・フレーズの提供元を次のように選択します。
ユーザー: アカウントの作成時に、ユーザーがチャレンジ・フレーズを指定する必要があります。
事前定義: ユーザー・アカウントの作成時に、事前定義されたチャレンジのリストがユーザーに表示されます。ユーザーは、指定されたチャレンジ・フレーズの中から選択する必要があります。
ユーザーまたは事前定義: ユーザー・アカウントの作成時に、事前定義されたフレーズのリストがユーザーに表示されます。ユーザーは、指定されたチャレンジ・フレーズの中から選択するか、新規チャレンジ・フレーズを指定することが可能です。
「事前定義済チャレンジ・フレーズ」フィールドに、チャレンジ・フレーズを入力して「追加」をクリックします。
フレーズが選択リストに追加されます。選択されたフレーズをリストから削除するには、「削除」ボタンを使用します。
このロスト・パスワード・ポリシー定義の完了後、いつでも事前定義済チャレンジ・フレーズを追加することや、既存のフレーズを削除することができます。
「構成する最小チャレンジ」フィールドに、ユーザー・アカウントの作成時またはユーザー・プロファイルの変更時に構成する必要のあるチャレンジの数を入力します。
「チャレンジ・レスポンスの最小長」フィールドに、ユーザーが構成するレスポンスに許可する最小文字数を入力します。
「重複レスポンスを許可」チェック・ボックスを次のように構成します。
選択解除: False。ユーザーが複数のチャレンジ・フレーズに対して同じレスポンスを入力すると、エラーが表示されます。
選択: True。重複チェックは無効になります。
「回答する最小チャレンジ」フィールドに、ロスト・パスワード管理アプリケーションを使用してパスワードをリセットしたときに、ユーザーに回答させるチャレンジの数を入力します。
この値は、「構成する最小チャレンジ」フィールドの値以下である必要があります。たとえば、このフィールドの値を3に設定し、チャレンジとレスポンスのペアを4つ構成した場合、ユーザーが回答する必要のあるチャレンジの数は3つです。
|
注意: ユーザーが入力する必要のある実際のレスポンスの数は、このフィールドの値に加え、正しく構成されたチャレンジとレスポンスの数に応じて変化します。たとえば、このフィールドに2を入力しても、2つのチャレンジとレスポンスのペアのうち1つのみが正しく構成されている場合、ユーザーは1つのチャレンジにのみ回答するよう求められます。 |
「チャレンジ・ポーズ・タイプ」フィールドで、チャレンジを一度にすべて表示するか、順番に表示するかを選択します。
同時: チャレンジは同時に表示されます。チャレンジの表示順序は、毎回変化します。ユーザーは、すべてのチャレンジに正しく回答する必要があります。
順番に: ユーザーが1つのチャレンジ・フレーズに回答するまで、次のフレーズは表示されません。
パスワードのリセット後にユーザーに電子メールを送信する場合、「パスワード変更後に電子メール送信」ボックスを選択します。
ユーザーに電子メールを送信するよう設定すると、ユーザーは、侵入者がパスワードをリセットしたときに予期しない事態が発生したことに気付くため、管理者に連絡を取ることができます。
管理者がこのポリシーを使用できるようにする場合、「ロスト・パスワード・ポリシー有効化」ボックスを選択します。
「保存」をクリックします。
このポリシーの名前をパスワード・ポリシー・ドメインに追加します。
詳細は、「特定ドメイン用のパスワード・ポリシーの作成」を参照してください。
アイデンティティ・システム・コンソールで構成したパスワード・ポリシーを、アクセス・システムにより保護されているリソースに適用できます。これを行うには、各リソースを保護する認証スキームを変更します。ユーザーがアクセス・システムにより保護されたリソースに対する認証を受ける場合、それらのユーザーがパスワード・ポリシー・ドメインに存在すると、パスワード・ポリシーが起動されます。
この項には、次の各項目が含まれます。
詳細は、「パスワード・ポリシーの評価順序」の項を参照してください。認証スキームの作成方法の詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
次の手順では、認証スキームを変更してパスワード・ポリシーを含める方法について説明します。
アクセス・システムにログインします。
アクセス・システム・コンソールで、「アクセス・システム構成」をクリックし、次に左側のナビゲーション・ペインの「認証管理」をクリックします。
構成済のすべての認証スキームがリストされた「認証管理」ページが表示されます。
変更する認証スキームのリンクをクリックし、表示されたページの「変更」ボタンをクリックします。
「認証スキームの変更」が表示されます。
validate_passwordプラグインを選択し、次の情報を「プラグイン・パラメータ」フィールドに追加して「保存」をクリックします。
obReadPasswdMode="LDAP",obWritePasswdMode="LDAP"
たとえば、Basic Over LDAPスキームの元のvalidate_passwordプラグイン・パラメータ文が次のように設定されているとします。
obCredentialPassword="password"
新規パラメータは、次のように設定されます。
obCredentialPassword="password",obReadPasswdMode="LDAP", obWritePasswdMode="LDAP".
新規パラメータは、パスワード変更のリダイレクト用として追加する必要があります。
WebパスおよびWebGateが別々のサーバーにある場合、validate_passwordプラグインを選択し、次のようにして、obWebPassURLprefixパラメータを「プラグイン・パラメータ」フィールドに追加します。
http://webpasshost:port
ここで、webpasshostおよびportは、Webパスが存在するWebサーバーのホストとポートです。
credential_mappingプラグインのuidパラメータ値を書き留めます。
この値は、パスワード変更のリダイレクトURLを作成する際に必要です。たとえば、uidパラメータ値は%userid%になります。
パスワード変更のリダイレクトを設定するすべての認証スキームでこのプロセスを繰り返します。
次のページにユーザーをリダイレクトするURLを構成できます。
パスワード・リセット・ページ
パスワード期限切れ警告ページ
ユーザー・アカウントがロックされていることを示すエラー・ページ
これらのリダイレクトURLは、WebGateまたはアクセス・ゲートにより保護されているリソースにユーザーがログインした場合にのみ適用されます。つまり、『Oracle Access Managerアクセス管理ガイド』の記載に従ってリソースを保護している場合に、これらのURLのいずれかを構成できます。ユーザーがリダイレクトURLに指定されたターゲット・ページでの操作を完了したときに、当初リクエストされたリソースにユーザーを戻すようこれらのURLを構成することも可能です。
これらのURLの詳細は、次の各項目を参照してください。
パスワード・ポリシーに構成されているパスワードの有効期限が経過した後に、ユーザーがログインを試みると、そのユーザーは自動的にパスワード・リセット・ページにリダイレクトされます。このパスワード・リセット・ページのURLを構成できます。オプションで、このパスワード・リセットURLにより、パスワードのリセット後にユーザーを当初リクエストされたリソースにリダイレクトできます。
アイデンティティ・システム・コンソールで、「システム構成」サブタブをクリックし、次に左側のナビゲーション・ペインの「パスワード・ポリシー」をクリックします。
「パスワード・ポリシー管理」ページにパスワード・ポリシーのリストが表示されます。
「パスワード変更のリダイレクトURL」フィールドに、次の構文を使用してURLを入力します。
http://hostname:portnumber/identity/oblix/apps/lost_pwd_mgmt/bin/lost_pwd_ mgmt.cgi?program=redirectforchangepwd&login=%scheme1_uid_parameter_value% %scheme2_uid_parameter_value%%schemeN_uid_parameter_value% &target=top
この場合:
hostname:portnumberは、WebパスがインストールされているWebサーバーのホストとポートです。
%scheme1_uid_parameter_value% %scheme2_uid_parameter_value%%schemeN_uid_parameter_value%は、パスワード変更のリダイレクトを設定するすべての認証スキームに対応するuidパラメータ値の文字列です。
たとえば、2つの認証スキームに次のcredential_mappingプラグイン・パラメータが含まれるとします。
Form over LDAP: obMappingBase="o=company,c=us", obMappingFilter="(&(objectclass=genSiteOrgPerson) (uid=%login%))"
Basic over LDAP: obMappingBase="o=company,c=us", obMappingFilter="(&(objectclass=genSiteOrgPerson) (uid=%userid%))"
これらのパラメータに対応するパスワード変更のリダイレクトURLは、次のとおりです。
http://hostname:portnumber/identity/oblix/apps/lost_pwd_mgmt/bin/lost_pwd_ mgmt.cgi?program=redirectforchangepwd&login=%login%%userid%&target=top
パスワード変更フォームの送信後にユーザーを当初リクエストされたリソースに戻す場合、このURLの問合せ文字列にBackURL文を記述できます。基本構文は次のとおりです。
http://hostname:portnumber/identity/oblix/apps/lost_pwd_mgmt/bin/lost_pwd_ mgmt.cgi?program=redirectforchangepwd&login=%login%%userid%&backURL=%HostTarget %%RESOURCE% &target=top
たとえば、次のようになります。
http://130.35.46.141:99/identity/oblix/apps/lost_pwd_mgmt/bin/lost_pwd_ mgmt.cgi?login=%login%%userid%&backUrl=%HostTarget%%RESOURCE%
実行時に、%デリミタで囲まれた値が、当初リクエストされたリソースのURLで置き換えられます。たとえば、次のようになります。
http://130.35.46.141:99/identity/oblix/apps/lost_pwd_mgmt/bin/lost_pwd_ mgmt.cgi?login=admin&backUrl=http://www.webserver1.com/test/a.html
lost_pwd_mgmt.cgiスクリプトには、問合せパラメータを処理するロジックが含まれます。lost_pwd_mgmt.cgiスクリプトは、Oracle Access Managerに付属しています。ページは動的に生成されるため、手動による構成は必要ありません。
「保存」をクリックします。
パスワードの有効期間は、パスワード・ポリシーで構成します。ユーザー・パスワードの期限切れが近づくと、ユーザーは、リダイレクトURLにより警告ページに移動されます。Oracle Access Managerでは、この警告ページを提供していません。警告を含む実際のランディング・ページを作成する必要があります。オプションで、この警告ページに、ユーザーをパスワード・リセット・ページに移動するURLを含めることもできます。
パスワード期限切れのリダイレクトURLは、アクセス・システムにより保護されているリソースにのみ適用されます。つまり、WebGateでリソースを保護している場合に、このURLを構成できます。
パスワード期限切れのURLは、パスワード変更のリダイレクトURLと似ています。このURLにより、ユーザーを期限切れ通知フォームに移動できます。オプションで、ユーザーをパスワード変更フォームにリダイレクトすることや、パスワードの変更後にユーザーを当初リクエストされたリソースに戻すことも可能です。
すべてのパスワード・ポリシーに適用されるデフォルトのパスワード期限切れURLを構成するか、個々のポリシーに適用されるURLを構成します。
自動的にユーザーをこのURLにリダイレクトするか、期限切れ前に電子メールでユーザーに通知できます。詳細は、「特定ドメイン用のパスワード・ポリシーの作成」を参照してください。
このURLのターゲットとして機能する組込みのページまたはポータルはありません。適切なページを作成する必要があります。たとえば、「パスワードの期限がもうすぐ切れるため、変更する必要があります」というメッセージの表示されるページを作成できます。
デフォルトのパスワード期限切れ警告のリダイレクトURLを設定する手順
アイデンティティ・システム・コンソールで、「システム構成」サブタブをクリックし、次に左側のナビゲーション・ペインの「パスワード・ポリシー」をクリックします。
「パスワード・ポリシー管理」ページにパスワード・ポリシーのリストが表示されます。
「パスワード期限切れ警告のリダイレクトURL」に、次の構文を使用してURLを入力します。
http://hostname:port/path-to-custom-page
この場合:
hostname:portは、WebパスがインストールされているWebサーバーのホストとポートです。
path-to-custom-pageは、パスワードの期限切れが近いことを警告するカスタムWebページのパスです。
認証後にユーザーを当初リクエストされたリソースに戻す場合、次のようにこのURLの問合せ文字列にバックURL（backURL文）を記述できます。
http://hostname:portnumber/notice.cgi?program=redirectforchangepwd&login=%login %%userid%&backURL=%HostTarget%%RESOURCE%&target=top
たとえば、次のURLを入力できます。
http://130.35.46.141:99/cgi-bin/notice.cgi?login=%login%%userid%&backUrl=%HostT arget%%RESOURCE%
この例では、notice.cgiに問合せパラメータを処理するロジックが含まれます。簡単なWebページを作成するか、またはcgiなどのスクリプトやJSPページを記述してURLのパラメータ解析と適切なメッセージの表示、タイムアウトの処理、およびユーザーのbackURLへのリダイレクトを行うことが可能です。
実行時に、問合せ文字列は、ユーザーおよび当初リクエストされたリソースの実際の値で置き換えられます。たとえば、次のようになります。
http://130.35.46.141:99/cgi-bin/notice.cgi?login=admin&backUrl=http:// www.webserver1.com/test/a.html
この例では、ユーザーが記述したスクリプトのnotice.cgiに、問合せパラメータを処理するロジックが含まれます。
カスタム・ページでは、ExpiryDate問合せパラメータを使用して有効期限日を取得することもできます。次に、このパラメータの例を示します。
http://130.35.46.141:99/cgi-bin/notice.cgi?ExpiryDate=%PwdExpiryDate%&backUrl=% HostTarget%%RESOURCE%
「保存」をクリックします。
他のリダイレクトURLと同様に、アカウント・ロックアウトのリダイレクトURLは、アクセス・サーバーにのみ適用されます。ユーザーIDまたはリクエストされたリソース情報を含まないロックアウトURLを構成できます。
アカウント・ロックアウトのリダイレクトを実装するには、Webページを作成するか、またはcgiなどのスクリプトやJSPページを記述してアカウント・ロックアウトURLのパラメータを解析する必要があります。スクリプトまたはJSPでは、アカウント・ロックアウトに関するメッセージの表示、タイムアウトの処理、および当初リクエストされたリソースへのユーザーのリダイレクトを行う必要があります。
アイデンティティ・システム・コンソールで、「システム構成」サブタブをクリックし、次に左側のナビゲーション・ペインの「パスワード・ポリシー」をクリックします。
「パスワード・ポリシー管理」ページにパスワード・ポリシーのリストが表示されます。
「カスタム・アカウント・ロックアウトのリダイレクトURL」フィールドに、ユーザーをアカウント・ロックアウト・フォームにリダイレクトするURLを入力します。
「保存」をクリックします。
アイデンティティ・システムで発生した変更をアクセス・サーバーに通知し、アクセス・システムのキャッシュを自動的にフラッシュできます。ただし、キャッシュの自動的なフラッシュを実行しないよう選択して、アイデンティティ・システムの「パスワード・ポリシー管理」ページで変更操作を行った場合に手動でキャッシュをフラッシュすることが可能です。この方法は、パスワード・ポリシー管理の変更の適用に大幅な遅れが生じることを回避する場合に有効です。
アクセス・サーバー・キャッシュをフラッシュする方法の詳細は、『Oracle Access Managerアクセス管理ガイド』および『Oracle Access Managerデプロイメント・ガイド』を参照してください。
Access Managerのソフトウェア開発キットは、アイデンティティ・サーバーとともにIdentityServer_install_dir/AccessServerSDKに自動的にインストールされます。アイデンティティ・システムの次の機能にはSDKが必要です。SDKは手動で構成する必要があります。
アイデンティティ・システムとアクセス・システム間の自動キャッシュ・フラッシュ
自動キャッシュ・フラッシュのために、アイデンティティ・システムでは、アクセス・ゲートを使用してアクセス・サーバーと通信します（SDKで使用可能なAPIを使用）。自動キャッシュ・フラッシュのために、アクセス・ゲートではアイデンティティ・サーバーとバンドルされているAccess Manager SDKのAPIを使用します。アクセス・ゲートが関連付けられているアクセス・サーバーのプロファイルで、「アクセス管理サービス」が「オン」に設定されていることを確認してください。アクセス・サーバー・キャッシュをフラッシュする方法の詳細は、『Oracle Access Managerアクセス管理ガイド』および『Oracle Access Managerデプロイメント・ガイド』を参照してください。
自己登録後のアクセス・システムへの自動ログイン
WebパスをWebGateで保護する場合、次の手順を実行します。前述のアイデンティティ・システム機能ごとにこの手順を繰り返す必要はありません。
アイデンティティ・システムとアクセス・システムをインストールして設定します（『Oracle Access Managerインストレーション・ガイド』を参照してください）。
|
注意: Access Manager SDKは、アイデンティティ・システムとともにIdentityServer_install_dir/AccessServerSDKに自動的にインストールされます。 |
Windows: 次のようにPATHシステム変数を変更して、パスがAccess Manager SDKを参照するよう設定します。
set PATH = %PATH%;Identityserver_install_dir\AccessServerSDK\oblix\lib
アクセス・システム・コンソールで、「アクセス・システム構成」→「アクセス・ゲート構成」をクリックします。
アクセス・ゲート・プロファイルを追加します。
ポートを構成する必要はありません。
自動キャッシュ・フラッシュのために、「アクセス管理サービス」が「オン」に設定されていることを確認してください。
アクセス・ゲート・プロファイルを保存します。
アクセス・ゲート・プロファイルの追加および変更方法の詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
IdentityServer_install_dir/identity/AccessServerSDK/oblix/ tools/configureAccessGateディレクトリにアクセスし、configureAccessGateスクリプトを実行します。
IdentityServer_install_dirは、アイデンティティ・サーバーがインストールされているディレクトリです。configureAccessGateを実行する場合、アクセス・ゲートIDが、手順4のアクセス・システム・コンソールで入力したアクセス・ゲート名と同じであることを確認してください。
IdentityServer_install_dir/identity/oblix/data/commonディレクトリのbasedbparams.xmlパラメータ・カタログ・ファイルをテキスト・エディタで開きます。
doAccessServerFlushフラグの値を次のようにtrueに変更します。
<NameValPair ParamName="doAccessServerFlush" Value="true" />
アイデンティティ・サーバーを再起動します。
この項では、クローニングおよび同期化について説明します。
クローニングにより、既存のインストール済コンポーネントをテンプレートとして使用し、リモート・システムにコンポーネントのコピーを作成できます。コマンドラインやインストールGUIを使用してOracle Access Managerコンポーネントをインストールするかわりに、既存のインストール済コンポーネントの構成をクローニングしてコンポーネントを自動的にインストールできます。
同期化では、同じコンポーネントの2つのインストールについて、一方が他方より新しい場合にそれらのインストールを一致させることができます。同期化を使用すると、類似したプラットフォーム上のインストールをアップグレードまたは修復できます。
詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
