| Oracle Access Managerデプロイメント・ガイド 10g（10.1.4.3） B55479-01 |
|
 戻る |
 次へ |
Oracle Access Managerのインストールと構成を行ったら、最適なパフォーマンスを得ることができるようにこの製品をチューニングする必要があります。
この章では、熟練したOracle Access Manager管理者によるOracle Access Managerのパフォーマンスの最適化方法について説明します。この章に含まれる内容は次のとおりです。
デプロイメントの一般的な推奨事項は、第1章を参照してください。Apache Webサーバーに対するポリシー・マネージャのチューニング要素の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
Oracle Access Managerのデータは、Lightweight Directory Access Protocol（LDAP）ディレクトリに格納されます。Oracle Access Managerが原因と考えられる問題を診断する場合、ディレクトリのパフォーマンスの確認が必要になることがあります。また、パフォーマンスに関する問題の多くは（特に書込み操作の場合）、ディレクトリに移動することなく解決できます。
後述の項の内容は次のとおりです。
ディレクトリのパフォーマンスが低い場合、アクセス・サーバーやアイデンティティ・サーバーのパフォーマンスにも影響します。詳細は、ディレクトリのベンダーから提供されているドキュメントを参照してください。Oracle Internet Directoryについては、『Oracle Internet Directory管理者ガイド』のパフォーマンスの最適化に関する章を参照してください。
アイデンティティ・サーバーとアクセス・サーバーにより、LDAPへの接続が構成可能な数だけ開かれます。時間のかかるユーザー・プロファイルの検索を多数実行する場合、データベース接続プール・サイズを大きくしてパフォーマンスを向上させることができます。
アイデンティティ・システム・コンソールまたはアクセス・システム・コンソールで接続プール・サイズを構成します。構成データやポリシー・データへのアクセスに使用される接続の詳細を指定する場合、システム・コンソールからではなく構成ファイル内で指定します。これらのファイルは、アイデンティティ・サーバー、アクセス・サーバーおよびポリシー・マネージャの/oblix/config/ldapディレクトリに格納されています。「最初の接続数」設定に従い、起動時に多数の接続が開きます。必要に応じて、「最大接続数」設定に指定された値に達するまでさらに接続が開きます。アイデンティティ・サーバーまたはアクセス・サーバーが停止するかディレクトリ・サーバーからのレスポンスが停止するまで、接続は開いたままの状態になります。
アイデンティティ・サーバーやアクセス・サーバーによってディレクトリに対して開かれる接続数は、アイデンティティ・システム・コンソールやアクセス・システム・コンソールで指定された接続数とは異なります。これは、特定の接続についての詳細情報が構成ファイルから取得されるためです。接続に関する情報は、次のファイル内で指定されます。
構成データへアクセスする場合の接続: component_install_dir/oblix/config/ldap内に3つのデータベース構成ファイルが格納されています。ここで設定された接続数が、各構成ファイルに対して適用されます。デフォルト値は「1」です。この場合、少なくとも3つの接続が常に開いている状態になります。
ポリシー情報へアクセスする場合の接続: 4つのロケータ・ファイルを使用してポリシー定義が管理されます。これらのロケータ・ファイルは、AccessServer_install_dir/oblix/config/ldapに格納されています。開かれる接続数の設定は、各ロケータ・ファイルで個別に管理されます。デフォルト値は「1」です。この場合、少なくとも4つの接続が常に開いている状態になります。
設定時に作成されるデータベース・プロファイル用の接続: 構成ベースと検索ベースが同じであるかあるいは非結合であるかにより、Oracle Access Managerの設定時に1つまたは2つのデータベース・プロファイルが自動的に作成されます。各データベース・プロファイルに対して1つのインスタンスが設定され、接続数に「1」が指定されます。データベース・プロファイルが認証操作をサポートしている場合、認証操作に対して個別の接続プールが使用されます。たとえば、あるデータベース・プロファイルに1つのデータベース・インスタンスが設定され接続数に「1」が指定されている場合、認証操作用とその他のLDAP操作用に合計2つの接続を開くことができます。
設定済の接続数と実際の接続数との違いを説明するため、非結合ドメインの構成を行わずに製品の設定を実行したと想定します。この場合、デフォルトで9つの接続が開きます。
構成データ用の接続（合計3つ）
ポリシー・データ用の接続（合計4つ）
1つのデータベース・インスタンスと1つの構成済接続が設定されたデータベース・プロファイル用の接続（合計2つ）
別の例として、2つのデータベース・プロファイルを構成したと想定します。各プロファイルには1つのデータベース・インスタンスが設定され、「最初の接続数」設定には「3」、「最大接続数」設定には「5」がそれぞれ指定されているとします。どちらのデータベース・インスタンスも同じディレクトリに適用され、構成データとユーザー・データも同じディレクトリに格納されます。認証操作はサポートされているものとします。この場合、ディレクトリに対して開かれる接続の最小数は、次のように「19」になります。
構成データ用の接続（合計3つ）
ポリシー・データ用の接続（合計4つ）
2つのデータベース・プロファイルに対して適用される3つの接続（合計12）
各データベース・プロファイルには6つの接続が設定されます。これは、2つの接続プールが3つの接続それぞれ（合計6つ）に対して設定されるためです。1つのプールが認証リクエスト操作用に設定され、もう1つのプールがその他の操作に対して設定されます。
この例では、接続の最大数を「2」に設定した場合、ディレクトリへの接続数は「19」から「27」の範囲になります。
次に示す手順は、LDAP接続数の構成方法を説明したものです。
「アイデンティティ・システム・コンソール」、「システム構成」、「ディレクトリ・プロファイル」に移動します。
「プロファイルの構成」ページの「LDAPディレクトリ・サーバー・プロファイルの構成」リストに表示されているユーザー・データ・ディレクトリ・サーバー・インスタンスの名前をクリックします。
「ディレクトリ・サーバー・プロファイルの変更」ページの「データベース・インスタンス」リストに表示されているディレクトリ・サーバー・インスタンスの名前をクリックします。
「データベース・インスタンスの変更」ページで、次の2つのパラメータを変更します。
最大接続数: プール内の使用可能な接続数を大きくします。デフォルト値は「1」です。上限値はありません。様々な値を指定して最適な接続数を設定してください。
最初の接続数: データベースを初期化する際に開く接続数を指定します。デフォルト値は「1」です。上限値はありません。
『Oracle Access Manager IDおよび共通管理ガイド』に記述されているように、ワークフローの各ステップでチケットが生成され、Oracle Access Managerによってそのチケットがディレクトリに対して書き出されます。この操作はデフォルトで実行されます。
ディレクトリに対する不要な書込み操作を行わないようにする場合、ワークフロー内のステップ数を最小にするという方法があります。もう1つの方法として、ワークフロー内のすべてのステップでチケットを生成するというOracle Access Managerのデフォルトの動作を変更する方法があります。
次に示す状況では、チケットを生成する必要はありません。
あるステップにおける情報が、次のステップに対して重要ではない場合
参加者によってワークフローがトリガーされたが、他のステップでは参加者がいない場合
ディレクトリ・サーバーに格納されているワークフロー・チケットの数を監視し、手動またはスクリプト・ベースのユーティリティを使用して古いチケットを定期的に削除することをお薦めします。
ワークフローの例
次のステップから構成されるワークフローを作成するとします。
開始: ユーザーによって自動登録が開始されます。
外部アクション: リクエストが外部プロセスに渡されます。
有効化: ワークフローが有効になります。
ステップ2とステップ3で参加者がいない場合、このワークフローにチケットは必要ありません。
WFInstanceNotRequiredフラグにより、ワークフローのすべてのステップでチケットを生成するかどうかが決定されます。デフォルトでは、このフラグはfalseに設定されます。この場合、ワークフローのすべてのインスタンスがディレクトリに書き出されます。trueに設定された場合、ワークフローのインスタンスは次に示す場合のみディレクトリに書き出されます。
ユーザーによる操作が必要な場合
エラーが発生した場合（コミット操作の失敗など）
サブフローがトリガーされた場合
これら以外にワークフローに必要な入力や承認ステップがない場合は、WFInstanceNotRequiredフラグをtrueに設定することをお薦めします。WFInstanceNotRequiredフラグをtrueに設定すると、ディレクトリのサイズが小さくなり、ワークフローの処理速度が上がります。このパラメータは、ディレクトリ・サーバーにオーバーヘッドを生じさせる可能性のある、ワークフロー追跡データの生成と格納を抑制します。ただし、このフラグをtrueに設定した場合、Oracle Access Managerワークフロー・モニターから実行されたワークフローをすべては表示できないという不都合が生じます。これは、ワークフローのインスタンスが保存されないためです。
ワークフローのすべてのステップでチケットが生成されないようにする手順
次のファイルで、WFInstanceNotRequiredフラグをtrueに設定します。
IdentityServer_install_dir/identity/oblix/data/common/workflowdbparams.xml
アイデンティティ・サーバーを再起動します。
詳細は、『Oracle Access Manager IDおよび共通管理ガイド』のユーザー、グループおよび組織マネージャの構成に関する章を参照してください。
索引を作成することにより、ディレクトリ内の検索効率を上げることができます。ただし、データベースの変更操作や作成操作が遅くなり、余分なディスク領域が必要になります。Oracle Access Managerの設定プログラムを実行すると、キー属性の索引が自動的に作成されます。索引ファイルは各ディレクトリ・サーバー・タイプに対して固有で、次の場所に保存されます。
IdentityServer_install_dir/identity/oblix/data/common
このIdentityServer_install_dirは、アイデンティティ・サーバーがインストールされているディレクトリです。
索引タイプには次のものがあります。
等価索引は、特定の属性値が含まれるディレクトリ・エントリの検索効率を高めます。
プレゼンス索引は、特定の属性が含まれるディレクトリ・エントリの検索効率を高めます。
サブストリング索引は、特定のテキスト文字列が含まれるエントリの検索効率を高めます。
様々な操作の際に読み取られる属性の索引を作成することにより、パフォーマンスを向上させることができます。こうした属性には、次のものがあります。
ユーザーの操作によって間接的にトリガーされた検索内で使用される属性
ユーザーによって明示的に呼び出された検索内で使用される属性
認証スキーム用のマッピング・フィルタ内で使用される属性
グループ・マネージャの動的メンバー定義用フィルタ内の属性
属性の索引を作成する方法は、ディレクトリ内のドキュメントに記述されています。
Oracle Access Managerにより、索引ファイル・フラグメントが提供されます。ここには、サポートされている各ディレクトリ・サーバーに対して、Oracle Access Manager固有の属性の索引を作成する方法が記述されています。たとえば、次に示すファイルには、Sun（以前はiPlanet）によって管理されているディレクトリ内のパフォーマンスを改善する目的で索引を作成できるOracle Access Managerの属性がリストされています。
IdentityServer_install_dir/identity/oblix/data/common/iPlanet5_oblix_index_add.ldif
このファイルに登録されている索引エントリの例は、次のようになります。
index obclass pres,eq,sub
このエントリは、obclass属性の索引を作成する場合に、プレゼンス（pres）、等価（eq）、サブストリング（sub）の各タイプ別に作成できることを示しています。
|
注意: ldapmodifyを使用して、iPlanet5_oblix_index_add.ldifファイルをディレクトリ・サーバーにロードする必要があります。 |
ディレクトリ属性の索引を作成する場合、検索操作の際に得られるメリットと、これらの属性が変更された際に生じる余分な作業とのバランスを、慎重に検討してください。ある属性値が変更された場合、ディレクトリ・サーバーによってこの属性の索引を再構築する作業が必要になります。ただし、再構築の方法は各ディレクトリ・サーバーによって異なります。
索引を作成する場合は、製造元から提供されているガイドラインを参照してください。属性の索引を過剰に作成することは避けてください。
多数のユーザーを非アクティブ化した場合、Oracle Access Managerのパフォーマンスが低下することがあります。この問題が発生した際に非アクティブ化したユーザーをすべてディレクトリ内に残しておく場合、次に示す属性に対して等価索引を使用してください。
ObIndirectManager
ObUniqueMemberstr
等価索引を使用すると、特定の属性値が含まれたエントリを効率的に検索できます。
ワークフローの削除に時間がかかる場合は、削除処理中にシステムによって確認されるすべての属性の索引を作成します。ワークフローの削除機能に関するパフォーマンス上の問題は、属性に対して索引が必要であるために発生する場合が一般的です。
等価、プレゼンス、サブストリングの各タイプを使用して、次に示す属性の索引を作成します。
ObWorkflowID
ObContainerID
ObWFStepID
ObWFTargetID
ObIsWorkflowProvisioned
ObLocationDN
OblixGID
Manager
Secretary
等価タイプの索引は、特定の属性値が含まれるディレクトリ・エントリの検索効率を高めます。プレゼンス・タイプの索引は、特定の属性が含まれるエントリの検索効率を高めます。サブストリング・タイプの索引は、特定の文字列が含まれるエントリの検索効率を高めます。
たとえば、次に示すサブストリング・タイプの索引が作成されている属性を検索したとします。
cn=*lane
この場合、次の文字列が含まれる名前が検索結果として返されます。
John Lane Jane Tulane
さらに、次の検索を行います。
telephonenumber= *123*
この場合、「123」が含まれるすべての電話番号が検索結果として返されます。
次の属性はグループの拡張に使用され、索引を作成してパフォーマンスを向上させることができます。
obSDynamicMemberセマンティク型によって構成されたすべての属性
oblixAdvancedGroupオブジェクト・クラスのobGroupExpandedDynamic属性
拡張対象グループの動的フィルタ内で使用されるすべてのユーザー属性
ユーザーが検索を行う場合の最小文字数を定義することにより、検索の際に生じるパフォーマンス上の影響を小さくすることができます。これは、searchStringMinimumLengthパラメータによって制御されます。このパラメータのデフォルト値は「0」です。
次のカタログ内でseachStringMinimumLengthを探します。
IdentityServer_install_dir/identity/oblix/apps/common/bin/ oblixappparams.xml
指定されている値を、検索に使用する場合の最小文字数に設定します。
たとえば、この値を「6」に設定した場合、ユーザーは"Smith"という文字列を検索に使用できなくなります。この文字列には5文字しかないためです。この制約は、ユーザーが入力した文字列のうち、最も長い文字列に対してのみ適用されます。たとえば、前述の検索の際に、姓の検索の他に役職名の検索も同時に行ったとします。ユーザーが「manager」と入力して役職名を検索した場合、この検索文字列は7文字になるため、この検索は許可されます。この値を「0」に設定すると、検索文字数の検査は行われません。
searchStringMinimumLengthによる制約は、Oracle Access Managerのユーザー・インタフェースを使用して実行される検索と、Oracle Access Managerの他のインタフェース（Identity XMLクライアントなど）を使用するクライアントに対して適用されます。
属性ごとに検索用の最小文字数を設定する手順
カタログ内で、searchStringMinimumLengthの値を「0」に設定します。
JavaScriptコード内で、misc.jsファイルのvalidateSearchAndSubmit()関数を探します。
必要な検索用の最小文字数を属性ごとに設定できるよう、JavaScriptコードを変更します。
|
注意: Identity XMLクライアントのユーザーに対してこの手順を実行しても、制約は適用されません。 |
その他のパラメータと同じように、searchStringMinimumLengthをグローバルのoblixappparams.xmlカタログ内で定義されている値に設定することができます。また、1つ以上のアプリケーション固有のカタログ内で異なった値に設定することもできます。たとえば、グローバル値を上書きしてsearchStringMinimumLengthをユーザー・マネージャ用に異なった値に設定する場合、次に示すカタログ内のみでこのパラメータ値をユーザー・マネージャ用に指定します。
IdentityServer_install_dir/identity/oblix/apps/userservcenter/bin/ userservcenterparams.xml
デフォルトでは、各アクセス・サーバーによって開かれる接続は、プライマリ・ディレクトリ・サーバーとフェイルオーバー・ディレクトリ・サーバー（フェイルオーバー・サーバーが構成されている場合）に対してそれぞれ1つだけです。高い負荷がかかっているシステムの場合、これは最適な設定ではありません。
Oracle Access Manager構成とポリシー・データ用に、アクセス・サーバーに対するディレクトリ・サーバーの接続を追加して構成するには、コマンドライン・ツールのconfigureAAAServerを使用します。このツールに関する情報については、『Oracle Access Managerアクセス管理ガイド』を参照してください。非常に高い負荷がかかっている環境において（アクセス・サーバーで1秒間当たり1,000件のヒットがあるような場合）20の接続を作成すると、大幅にパフォーマンスが改善されます。
|
注意: 仕様の低いシステムでディレクトリが実行されている場合、ディレクトリ自体がパフォーマンス低下の要因になることがあります。この場合、接続数を増やしてもほとんど効果はありません。ディレクトリを実行しているコンピュータに問題がある場合は、ディレクトリ・サーバー・インスタンスの数を増やし、これらのインスタンス間にロード・バランシングを構成してください。 |
Oblixツリーが大きくなりすぎるのを防ぐため、定期的にワークフローの削除やアーカイブを行ってください。ワークフロー・インスタンスを削除すると、そのインスタンスに関連するディレクトリ・エントリも削除されます。ワークフロー・インスタンスをアーカイブすると、インスタンスのレコードがLDIFファイルに保存され、その後でインスタンスがディレクトリから削除されます。
ワークフローの削除やアーカイブを行う頻度は、ワークフローの使用頻度によって異なります。
アーカイブされたワークフローは、LDIF形式で保存されます。デフォルトのアーカイブ・ファイルは次のファイルです。
IdentityServer_install_dir/identity/oblix/data/common/wfinstance.ldif
複数のアーカイブ操作によって情報がこのファイルに追加されます。次に示すファイル内のエントリを変更することにより、アーカイブ・ファイルを変更することができます。
ユーザー・マネージャ
IdentityServer_install_dir/identity/oblix/apps/userservcenter/bin/usc_wf_params.xml
グループ・マネージャ
IdentityServer_install_dir/identity/oblix/apps/groupservcenter/gsc_wf_params.xml
組織マネージャ
IdentityServer_install_dir/identity/oblix/apps/objservcenter/osc_wf_params.xml
変更するエントリは、次のようなエントリです。
<NameValPair ParamName="archiveFileName" Value="wfinstance.ldif"/>
「ユーザー」、「グループ」、または「組織マネージャ」で「リクエスト」をクリックします。
「リクエストのモニター」をクリックします。
サブフローの場合、最初のステップが処理されていなければ「処理日」フィールドが空で表示されます。
検索フィールドで検索基準を選択します。
「実行」をクリックします。
検索フィールドの下に検索結果が表示されます。
個々のチェック・ボックスをクリックするか、「すべて選択」ボタンをクリックします。
画面に表示されていない検索結果を表示する場合は、「次へ」か「前へ」を必要に応じてクリックします。
「削除」ボタンか「アーカイブ」ボタンをクリックします。
デフォルトでは、管理者はディレクトリ内のすべての属性を表示できます。これにより、管理者はOracle Access Managerの初期設定を行うことができます。エンドユーザーに対しては特定の属性の読取り権限しか設定されていないため、管理者とエンドユーザーとでは、パフォーマンス上の違いがあります。
BypassAccessControlForDirAdminパラメータは、ディレクトリ内のすべての属性を表示する権限をマスターID管理者に対して許可するか、あるいは委任管理者に対して許可するかを制御します。デフォルトでは、BypassAccessControlForDirAdminパラメータはtrueに設定されます。次のファイルで、このパラメータの値をfalseに設定できます。
IdentityServer_install_dir/identity/oblix/apps/common/bin/globalparams.xml
BypassAccessControlForDirAdminフラグがfalseに設定されている場合、エンドユーザーと管理ユーザーとの間にパフォーマンス上の違いは発生しません。これは、属性の読取り権限と書込み権限が管理ユーザーに対して適用されるためです。
次に示すのは、パラメータ・エントリの例です。
<SimpleList> <NameValPair ParamName="BypassAccessControlForDirAdmin" Value="true"> </NameValPair> </SimpleList>
検索ベースの構成は、Oracle Access Managerのパフォーマンスに影響を与える場合があります。検索ベースを構成する際のガイドラインを次に示します。
すべてのユーザーをルートなどの場所で検索できるユーザー・ブランチ内に、ユーザー・オブジェクト・クラス用の検索ベースを設定します。
ユーザー、グループ、または組織のオブジェクト・クラスごとに構成する検索ベースの数を最小限にします。
複数の検索ベースを設定してユーザーのアクセスを制限するよりも、ユーザー・オブジェクトのクラス属性に対する属性のアクセス制御を構成するほうがより効率的です。
可能な場合、デフォルトの検索ベース・フィルタobjectclass=*を常に使用します。
検索ベース・フィルタを定義するかわりに、属性の読取り権限と書込み権限を構成します。
検索ベースの構成では、代替構文の使用は避けてください。
"...(...=*something*)..."などのサブストリング検索を含む検索ベースやACLの使用は避けてください。
ワークフローのルールとロールを構成し、ユーザーに対する属性値の表示機能や変更機能を制御します。
詳細は、『Oracle Access Manager IDおよび共通管理ガイド』の、スキーマ・データをアイデンティティ・システムで使用可能にする方法に関する章を参照してください。
検索ベースを構成する際に、フィルタを追加してデフォルトのフィルタ（objectclass=*）以外のフィルタを入力した場合、リソース・フィルタの検索範囲が有効になります。フィルタを定義しないかぎり、リソース・フィルタの検索範囲は無効です。
デフォルトの検索ベース・フィルタ（objectclass=*）からOracle Access Managerに対して指示が出され、検索ベースとして選択されたディレクトリ・ツリーのすべてのセクションに対してユーザーの検索基準が適用されます。（telephone=408*）などの別の検索基準を指定した場合、この基準を満たすすべてのユーザーがOracle Access Managerによって取得されます。その後、ツリー全体に対してではなく、フィルタによって指定されたサブセットに対してユーザーの検索基準が適用されます。
これは、パフォーマンスを低下させる可能性があります。特にフィルタによって多数のエントリを取得する場合、この可能性が大きくなります。たとえば、フィルタ内に（objectclass=wwmOrgPerson）を指定した場合、ユーザーが指定した検索基準が適用される前に、指定されたツリーに属するすべてのユーザーがOracle Access Managerによって取得される可能性があります（すべてのユーザーがこの基準を満たしている場合）。この場合、パフォーマンスが大幅に低下する可能性があります。このオブジェクト・クラスに対してすでに検索ベースが設定されているため、（objectclass=wwmOrgPerson）を指定する必要はありません。ユーザーのアクセスを制御する場合、検索ベース・フィルタを設定するよりも、属性に対する読取り権限と書込み権限を設定するほうが一般的でより効果的な方法です。ディレクトリのパフォーマンスを最適化するため、検索ベース用に複雑なフィルタを定義することは避けてください。タブに対する検索ベースの場合、このタブが適用されるクラスのオブジェクトのみが検索対象になります。明示的に（objectclass=*）を宣言する必要はありません。
フィルタの入力が必要な場合、resourceSearchFilterのスコープ・パラメータを「1」に設定することにより、パフォーマンス上の影響を小さくすることができます。
検索によって実際に返される（または返される可能性のある）エントリの数が大きくなればなるほど、検索にかかる時間も長くなります。Oracle Access Managerのような対話型アプリケーションの場合、結果セットが大きくなるとエンドユーザーでは処理できない可能性があります。
ディレクトリを使用することにより、ディレクトリ・サーバーが1回の検索に使用する時間や検索結果のサイズを制限できます。
LDAPデータベース・インスタンス最大接続数は、アイデンティティ・サーバーからディレクトリ・サーバーに対して許可されている最大接続数です。デフォルト値は「1」に設定されていますが、「1」より大きな値を設定するとパフォーマンスが向上する可能性があります（SQLプロファイルの場合、デフォルト値は「5」になります）。
最大接続数に対する最適値はありません。ディレクトリ構成やハードウェアなどは、考慮すべき要素です。ディレクトリの最大接続数は、アイデンティティ・サーバー用のスレッド数以下に設定してください。たとえば、アイデンティティ・サーバーに対してスレッドが20しか設定されていない場合、20を超える接続を構成しても利点はありません。これは、余分なスレッドを追加してもIDワーカー・スレッドにとってはメリットがないためです。
最大接続数を増やす場合、値を5ずつ大きくしてシステムのパフォーマンスを確認します。パフォーマンスが低下した場合は、接続数を少なくします。「最初の接続数」設定と「最大接続数」設定は、ともに機能します。アイデンティティ・サーバーが起動すると、「ディレクトリ・プロファイル」の「最初の接続数」に指定されている数の接続がディレクトリに対して開かれます。開かれた接続は、アイデンティティ・サーバーによってプールされて使用されます。
|
注意: 接続を追加するとオーバーヘッドが発生する場合があり、その結果パフォーマンスが低下する可能性があります。たとえば、ディレクトリ・サーバーを再起動した場合、指定された数の接続をアイデンティティ・サーバーによって接続しなおす操作が発生します。 |
この項では、Oracle Access Managerの操作に影響を与えるディレクトリ内容の変更について説明します。こうした変更を行うために必要なツールの情報については、「LDAPツール」を参照してください。
ポリシー・ドメイン名やポリシー名をポリシー・マネージャで検索すると、検索結果の列がデフォルトの順序で返されます。デフォルトでは表示されない列の表示や、列の順序の変更ができます。この操作は、レスポンス時間の点ではパフォーマンスに影響しません。返された検索結果の列を希望どおりに並び替えたい場合に、この操作を行います。
ポリシー名またはポリシー・ドメイン名の検索結果を変更する手順
次のようにしてDNを取得します。
obname=SDSearchColumnList, obapp=WRSC, o=Oblix, o=Company, c=US2
取得したDN内で、現在の列リストを検索します。
列リストは、obsearchresultcolumnsに対する値から構成されています。
ポリシー名は、次の値で検索できます。
WRORname: ポリシー名
AuthentPolicyName: 認証ルール名
AuthorPolicyName: 認可ルール名
AdminPolicyName: 監査ルール名
URLPrefix: ポリシーによって制御されるドメインのURL
ポリシー・ドメイン名は、次の値で検索できます。
SDName: ポリシー・ドメイン名
AuthentPolicyName: 認証ルール名
AuthorPolicyName: 認可ルール名
AdminPolicyName: 監査ルール名
AbsPathPattern: 制御されるドメインのパス
次に示すのは、ポリシー名、認証ルール名、認可ルール名、ポリシーによって制御されるドメインのURLを示したLDIFの一例です。
dn: obname=SDSearchColumnList, obapp=WRSC, o=Oblix, o=Company, c=US objectclass: top objectclass: OblixWRSSearchResultColumns obname: SDSearchColumnList obSearchResultColumns: WRORName obSearchResultColumns: AuthentPolicyName obSearchResultColumns: AuthorPolicyName obSearchResultColumns: URLPrefix
表示される検索結果の順序や内容を変更するには、この情報を変更してディレクトリに保存します。
Directory ManagerをバインドDNとして使用すると、検索範囲の制限、サイズの制限、検索時間の制限などの検索に関する制限が無視されます。この状態で大規模な検索を行った場合、ディレクトリ・サーバーが占有されるためアイデンティティ・サーバーの処理量が増大する可能性があります。
この場合は、Directory ManagerをバインドDNとして使用するユーザーを別に作成します。
|
注意: この処理は、Sun（以前はNetscapeおよびiPlanet）のディレクトリに対する処理方法を説明したものです。適切な権限が設定されたディレクトリ・ユーザーを作成する方法については、ディレクトリ・サーバーの管理マニュアルを参照してください。 |
orcladminなど、新しいユーザーを作成します。LDAPディレクトリを使用して、新しく作成したユーザーに対してOracle Access Managerの管理者権限を設定します。検索ベースや構成ベース、およびそれらに含まれるすべてのブランチに対して、このユーザーには次の権限が必要になります。
読取り
書込み
追加
削除
検索
比較
自己書込み
バインドDN権限を変更する手順
Sun LDAPサーバーの管理コンソールからディレクトリ・サーバー・インスタンスに移動し、そのインスタンスを開きます。
「Directory」タブを選択し、権限を設定するブランチを探して右クリックします。
次に例を示します。
o=Company、c=USとなっている場合はCompanyノードが表示されるので、これを右クリックしてメニューを表示します。
メニューから「Set Access Permissions」を選択します。
新しいアクセス権限を追加するか、すでに設定されているアクセス権限を編集します。
処理が終了すると、2つの行が表示されます。最初の行はすべてのユーザーに対するデフォルトの拒否文で、次の行は許可文です。
「Allow」を選択し、ユーザーとグループを検索して新しい管理ユーザーを特定します。
特定したユーザーに対して権限を設定します。
Oracle Access Managerのインストール後にこの変更を行った場合、アイデンティティ・サーバー用のバインドDNを変更してディレクトリ内に作成した値と一致させてください。
キャッシュを使用すると、不必要な検索や計算にかかる待機時間をなくすことができます。最近実行された検索リクエストの結果をユーザーの近くに保存しておくことにより、検索結果を再計算するかわりにキャッシュされた検索結果を返すことで、すばやく応答することができます。通常、キャッシュ処理の際には、RAMとディスク領域が余分に必要になります。
キャッシュ・サイズとエントリ数の関係は、多数のエントリを管理するディレクトリの場合は最初に最大キャッシュ・サイズに達し、少数のエントリを管理するディレクトリの場合は最初に最大エントリ数に達するのが一般的です。これら2つの値のどちらかだけを管理する場合は、もう一方の値を非常に大きな値に設定します。または、最初に最大キャッシュ・サイズを設定し、この最大キャッシュ・サイズを各エントリのサイズで割り、キャッシュ内で使用する必要のあるエントリの最大数を求めます。
Oracle Access Managerのユーザー・エントリ、ポリシー・ドメインの変更、ホスト識別子の変更、リソース変更などのキャッシュ可能な項目に対して変更が行われるたびに、ObSyncRecordというディレクトリ・エントリが作成されます。このディレクトリ・エントリにより、異なるOracle Access Managerサーバー間のキャッシュの同期をとることができます。これらのエントリに対して短い間隔で更新が行われた場合、ObSyncRecordに作成されたエントリの数によっては、ディレクトリにパフォーマンス上の問題が発生することがあります。
そのため、ObSyncRecordのエントリは定期的に削除してください。各エントリを削除する場合、そのエントリがキャッシュ・フラッシュ間隔よりも長くディレクトリ内に存在していることを確認してから削除してください。
|
関連項目:
|
次に示すパフォーマンス・チューニングの考慮事項は、Microsoft Active Directoryを使用するデプロイメントに適用されます。
パフォーマンス・チューニングの推奨事項は、第3章を参照してください。Microsoft Active DirectoryをOracle Access Managerとともにインストールする場合の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。Microsoft Active DirectoryをOracle Access Manager用に構成する場合は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
Microsoft Active Directory環境内にデプロイする場合は、必ずドメイン・コントローラを直接ポイントして、データ非一貫性による問題の発生を回避してください。Microsoft Active Directoryをユーザーおよびグループ・ディレクトリとして使用する場合は、DNS別名ではなく、必ずドメイン・コントローラを直接ポイントしてください。これにより、一時的な非一貫性によって発生する問題を回避できます。たとえば、動的DNSやラウンド・ロビンの別名割当てによって、処理速度の遅いサーバー、リモート・サーバー、または最新でないデータを含むサーバーに接続が迂回されることを回避できます。Active Directory環境で高可用性を実装するには、各ドメイン・コントローラをディレクトリ接続として構成し、その後Oracle Access Managerからの読取りおよび書込みのパフォーマンスを調整します。
この推奨事項は、複数のサブドメインを含むActive Directoryフォレストにも該当します。この場合、ルート・ドメインのみでなく各サブドメインにも別個のディレクトリ・プロファイルを作成する必要があります。また、各サブドメインは適切なドメイン・コントローラ・サーバーをポイントしている必要があります。
Oracle Access ManagerをWindows上でMicrosoft Active Directoryに対してデプロイする場合は、ADSIよりLDAP over SSLを使用したほうが適切である可能性があるということを考慮することが重要です。一般的に、LDAP over SSLはADSIよりパフォーマンスとスケールの面で優れています。これは特に、大量のトランザクションが発生する環境で顕著です。また、LDAP over SSLを使用すると、Oracle Access Manager（アクセス・サーバー、アイデンティティ・サーバーおよびポリシー・マネージャ）を特定のActive Directoryインスタンスに依存させることができます。これに対し、ADSIを使用した場合、Oracle Access Managerの接続先となるActive Directoryインスタンスはその都度決定されます。このインスタンス選択方法は、使用可能なすべてのActive Directoryドメイン・コントローラの間で全体的なレスポンスとパフォーマンスに著しいばらつきがある場合には適さない可能性があります。
Microsoft Active Directory環境でOracle Access Managerをデプロイする場合、Active Directory内で構成パラメータを適切に設定し、Oracle Access Manager全体のパフォーマンスを最適化することが重要です。表3-1に、最も重要なActive Directoryの構成パラメータを示します。
表3-1 Active Directoryの構成パラメータ
| Active Directoryの構成パラメータ | 説明 | デフォルト値 | Oracle Access Managerへの影響 |
|---|---|---|---|
|
MaxActiveQueries |
1つのドメイン・コントローラで同時に実行することが許可される、同時LDAP検索操作の最大数を指定します。この制限値に達した場合、LDAPサーバーによってビジー状態を示すエラーが返されます。 注意: この制御は、MaxPoolThreadsの値と正しく相互作用しません。MaxActiveQueriesが絶対数を定義するのに対し、MaxPoolThreadsはプロセッサ単位で制御します。Windows Server 2003以降では、MaxActiveQueriesは適用されません。また、MaxActiveQueriesはWindows Server 2003バージョンのNtdsutil.exeには表示されません。 |
20 |
20 すべてのサービス・スレッドが同時に検索操作を実行できるように、この値はOracle Access Managerのサービス・スレッド合計数より多く設定する必要があります。 Oracle Access Managerのサービス・スレッド合計数は、アイデンティティ・サーバーとアクセス・サーバーのスレッド数およびポリシー・マネージャをホストするWebサーバーのスレッド数の合計です。 |
|
MaxConnections |
ドメイン・コントローラによって受け入れられる、LDAPの同時接続の最大数を指定します。ドメイン・コントローラがこの制限値に達した後に接続が発生した場合は、ドメイン・コントローラによって別の接続が切断されます。 |
5000 |
この値は、Active Directoryドメイン・コントローラを使用してOracle Access Managerで確立される接続の数と同じかそれ以上に設定する必要があります。 |
|
MaxConnIdleTime |
クライアントがアイドル状態になってからLDAPサーバーの接続が切断されるまでの最大時間を秒単位で指定します。接続のアイドル状態がこの時間より長く続くと、LDAPサーバーによってLDAP切断通知が返されます。 |
900秒 |
Oracle Access Managerで最大セッション時間が設定されている場合は、その値より若干高い値を設定する必要があります。 |
|
MaxPageSize |
1回の検索結果で返されるオブジェクトの最大数を制御するための値を指定します（返される各オブジェクトの大きさは関係ありません）。ここで指定したオブジェクト数より多くの結果を返す検索を実行するには、クライアントがページ検索制御を指定する必要があります。これにより、返された結果が、MaxPageSizeの値を超えないよう複数のグループに分けられます。このようにして、MaxPageSizeは1回の検索結果で返されるオブジェクトの数を制御します。 |
1,000 |
この値は、Oracle Access Managerコンポーネントで作成された検索リクエストで返されるエントリの数より大きく設定する必要があります。 Oracle Access Managerコンポーネントでは、次の2つのケースで検索操作が実行されます。
空白の場合でも検索は許可されるため（一般的には検索結果がシステム内のすべてのユーザー・エントリになるすべての検索）、この値をシステム内のユーザー数より大きくする必要があります。 通常このようなユーザー検索が制限されているかこのようなリクエストが発生しない場合は、Oracle Access Manager構成データの次に示す2つのノードの下の最大ノード数より大きい値に設定する必要があります。
|
|
MaxPoolThreads |
ドメイン・コントローラがネットワークの入力または出力のリスニング専用であるプロセッサごとの最大スレッド数。同時に、この値により、LDAPリクエストも処理できるプロセッサごとの最大スレッド数も決まります。 |
1プロセス当たり4スレッド または |
アイデンティティ・サーバーまたはアクセス・サーバーによって単一のプロセッサ・サーバーが実行される場合は、Oracle Access Managerによって確立される接続の数より多い値に設定する必要があります。これにより、ドメイン・コントローラがすべての操作を並行して実行できます。 |
ディレクトリ内に保存されているデータの作成、変更、レポート作成を行う場合、ディレクトリ・アプリケーションによってLDAPが標準ツールとして使用されます。ツールを使用すると、こうしたデータを容易に操作できます。この項では、こうしたデータの操作に使用するツールを紹介します。ツールの詳細は、ご使用のサーバー・アプリケーションの製造元に問い合せてください。
ディレクトリ構造とディレクトリに格納されているデータは、LDAP Data Interchange Format（LDIF）ファイルの内容によって表されます。このファイルの内容は出力できます。出力リクエストの結果は、LDAPSEARCHなどのLDAPレポート・ツールによって書式設定されてディレクトリに書き出されます。このファイルに対して入力することもできます。LDAPMODIFYなどの更新ツールを使用し、すべて新規データとして、またはすでに存在するデータに対する更新データとしてディレクトリに挿入されます。
例として次に示すのは、Oracle Access Managerのデモ・ディレクトリから取得されたLDIFファイルの一部です。
dn: cn=John Kramer, ou=Sales, o=Company, c=US objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: companyOrgPerson cn: John Kramer sn: Kramer telephonenumber: 415-555-5269 facsimiletelephonenumber: 415-333-1005 title: Account Manager departmentnumber: 1204 employeetype: Fulltime employeenumber: 521-321-4560 givenname: John . . LDAPSEARCHによるディレクトリ内容のレポートの作成
LDAPSEARCHは、ディレクトリ内容のレポートを作成する場合に使用できるツールの1つです。異なる構文を使用する別のツールもありますが、概念は同じです。
LDAPSEARCHは、コマンドラインと対話型モードのいずれでも使用できます。コマンドラインの場合はレポート・リクエストのテキストが入力ファイルによってユーザーに表示されるため、コマンドラインから使用することをお薦めします。リクエストを行う前に、このファイルの内容を容易に確認できます。エラーを修正する場合、対話型モードではリクエストをすべて入力しなおす必要がありますが、コマンドラインではファイル内の文字をいくつか変更するのみで済みます。
LDAPSEARCHのコマンドライン形式は次のとおりです。
ldapsearchparamsfilterattr_list
|
注意: <>内に表示されている次の3つのカテゴリは、すべてオプションです。これらのオプションがすべて省略された場合、LDAPSEARCHは対話型モードで実行されます。対話型モードについては、ここでは説明しません。 |
カテゴリは次のとおりです。
<params>: パラメータのカテゴリ。パラメータは、LDAPSEARCHの動作を指示します。-fパラメータは、フィルタ・ファイルを指定する場合に使用します。かわりに検索フィルタをコマンドラインで指定する場合、このフィルタを指定する前にすべてのパラメータを定義しておく必要があります。
<filter>: フィルタのカテゴリ。フィルタはLDAPSEARCHに対して、データのサブセットを取得するように指示を出します。たとえば、フィルタを使用すると、Nで始まる名前のレポートのみを作成できます。コマンドラインでフィルタを指定する場合、引用符で囲む必要があります。
<attr_list>: 属性リストのカテゴリ。属性リストをコマンドラインで指定した場合、デフォルトの属性リストが上書きされます。デフォルトのリストには、ディレクトリ・エントリに属するすべての属性が表示されます。ただし、操作属性は表示されません。一部の属性のみを表示する場合は、その属性の名前をコマンドラインから入力し、その後にフィルタ名を入力します。属性の名前とフィルタ名は、空白で区切ります。操作属性を表示する場合は、その操作属性の名前をコマンドラインから入力します。操作属性の後に*を入力すると、デフォルトの属性リストも表示されます。
パラメータは、必ず次の形式で定義します。
-p pdata
このpは、パラメータを表します。パラメータの前にはダッシュを入力します。pdataは、パラメータが必要とする情報またはデータを表します（必要な場合）。pdataの部分に1つ以上の空白が含まれる場合、次のように二重引用符で囲む必要があります。
-p "pdata with spaces"
よく使用されるパラメータを、次に示します。ご使用のバージョンのLDAPSEARCHについては、関連するドキュメントを参照してください。/?パラメータを使用すると、パラメータの一覧が表示されます。
-A: 属性の名前のみを取得します。属性値は取得しません。
-b: 検索ベース。ここから検索が開始されます。ここで指定した値が、ディレクトリ内の識別名になります。このパラメータで指定するデータは、必ず二重引用符で囲む必要があります。次に例を示します。
-b "cn=Barbara Jensen, ou=Development, o=Oblix.com"
-D: サーバー管理者の識別名、またはエントリの検索を許可されたその他のユーザーの識別名。サーバーで匿名アクセスがサポートされている場合、このパラメータはオプションになります。次に例を示します。
-D "uid=j.smith, o=Oblix.com"
-f: 検索で使用される検索フィルタを含むファイルを指定します。次に例を示します。
-f filterfile
-h: ディレクトリ・サーバーがインストールされているコンピュータのホスト名またはIPアドレス。このエントリはオプションです。ホスト名が指定されなかった場合、LDAPSEARCHによってローカル・ホストが使用されます。たとえば、-h myserver.comのようにします。
-H: 指定可能なすべてのLDAPSEARCHパラメータを生成します。
-p: ディレクトリ・サーバーがリスニングするポート番号。次に例を示します。
-p 1049
-s: 検索の範囲。検索範囲として指定するデータは、次のいずれかにする必要があります。
base: -bパラメータで指定されたエントリのみを検索します。
one: -bパラメータで指定されたエントリの直下の子のみを検索します。-bパラメータで指定された実際のエントリは検索しません。
sub: -bパラメータで指定されたエントリと、そのエントリに属するすべての子を検索します。つまり、-bパラメータで指定された場所から、サブツリー検索が実行されることになります。-sパラメータを使用しない場合、これがデフォルトになります。
-S: ソート基準として使用する属性を指定します。検索結果の表示順序を制御します。複数の基準を使用してソートする場合、-Sパラメータに対して複数の引数を指定することができます。デフォルトの場合、返されたエントリはソートされません。たとえば、-S sn -S firstnameの場合、検索結果は最初に姓でソートされ、姓が同じ場合は名前でソートされます。
-w: -Dパラメータで指定された識別名と関連するパスワード。このパラメータを指定しなかった場合、匿名アクセスが使用されます。たとえば、-w passwordのようにします。
|
注意: Oracle Internet Directory LDAPツールは、環境変数LDAP_PASSWORD_PROMPTONLYがTRUEまたは1に設定された場合、安全性の低い-w passwordおよび-P passwordオプションを無効にするように変更されています。-q（または-Q）を使用すると、コマンドでユーザー・パスワード（またはウォレット・パスワード）を入力するよう求められます。可能なかぎり、この変数を設定することをお薦めします。 |
-x: 検索結果をクライアント側ではなくサーバー側でソートする場合に指定します。様々な国のデータを検索する場合など、一致規則に従って検索結果をソートする場合に、このパラメータを指定すると便利です。通常、クライアント側でソートするよりも、サーバー側でソートしたほうが処理速度は速くなります。
-z: 検索リクエストに対して返すエントリの最大数を指定します。たとえば、-z 1000のようにします。
ポート392をリスニングしているディレクトリ内で、Sales部門に所属する社員の中からJohnという名前の社員の姓（sn）と共通名（cn）と名前（givenname）をすべて取得する場合、次に示す情報をすべてコマンドラインから入力します。
ldapsearch -p 392 -b "ou=sales, o=company, c=US" -s sub "givenname=John" sn cn givenname
検索結果は次のようになります。
dn: cn=John Jackson, ou=Sales, o=Company, c=US sn: Jackson cn: John Jackson givenname: John dn: cn=John Kramer, ou=Sales, o=Company, c=US sn: Kramer cn: John Kramer givenname: John
フィルタ・ファイルを使用しても、同じ検索結果を取得できます。たとえば、namejohnというファイルに次のフィルタが含まれているとします。
givenname=John
次のようにコマンドラインから入力すると、このフィルタを使用して同じ検索結果を取得できます。
ldapsearch -p 392 -b "ou=sales, o=company, c=US" -s sub -f namejohn sn cn givenname
LDAPMODIFYツールを使用すると、ディレクトリ内容の変更や追加を行うことができます。この他のツールもありますが、概念は同じです。指定された識別名とパスワードを使用して、指定されたサーバーへの接続がLDAPMODIFYツールによって開かれます。さらに、指定されたファイルに登録されているLDIF更新文によってエントリが更新されます。LDAPMODIFYは対話モードで実行することもできますが、対話モードについてはここでは説明しません。
LDAPMODIFYを使用する際にスキーマ・チェックが有効になっている場合、サーバーによってスキーマ・チェックが実行されてから、ディレクトリに対して適用されます。ディレクトリ・サーバーによって、スキーマが認識できない属性やオブジェクト・クラスがエントリ内で検出された場合、変更操作はすべて失敗します。また、必要な属性に対する値が存在しない場合も、更新操作は失敗します。更新操作の対象が問題のあるオブジェクト・クラスや属性に対する値ではない場合でも、更新操作は失敗します。
|
注意: データを誤ってディレクトリに追加しないよう、スキーマ・チェックは常にオンにしてください。データを誤って追加すると、オフになっているスキーマ・チェックを再度オンにしたときに、ディレクトリが使用できなくなったり、スキーマ違反が発生することがあります。スキーマ・チェックはディレクトリの管理サーバー・コンソールで制御され、デフォルトではオンになっています。 |
LDAPMODIFYのコマンドライン形式は次のとおりです。
ldapmodify <params>
|
注意: paramsの部分はオプションです。この部分を入力しなかった場合、LDAPMODIFYは対話モードで実行されます。対話モードについては、ここでは説明しません。 |
<params>: これらのパラメータは、LDAPMODIFYの動作を指示します。-fパラメータは、ディレクトリに対して行う更新が記述されたファイルを指定する場合に使用します。
パラメータは、必ず次の形式で定義します。
-p pdata
このpは、パラメータを表します。パラメータの前にはダッシュを入力し、パラメータの後には空白を入力します。pdataは、パラメータが必要とする情報またはデータを表します（必要な場合）。pdataの部分に1つ以上の空白が含まれる場合、次のように全体を二重引用符で囲む必要があります。
-p "pdata with spaces"
よく使用されるパラメータの一部を、次に示します。すべてのパラメータのリストを表示するには、/?パラメータを使用します。
-a: LDIFエントリをディレクトリに追加します。対話モードの場合はLDIF更新文のchangetype:addが必要ですが、コマンドラインの場合は必要ありません。このパラメータを使用すると、簡単にディレクトリにエントリを追加できます。LDAPSEARCHによって作成および変更されたファイルを直接追加して更新を行う場合に、特に便利です。
-c: ユーティリティを連続操作モードで実行します。エラーが報告された場合も、ユーティリティは更新操作を続行します。デフォルトでは、エラーが報告されるとユーティリティは停止します。
-D: サーバー管理者の識別名、またはディレクトリ・エントリの変更を許可されたその他のユーザーの識別名。サーバーで匿名アクセスがサポートされている場合、このパラメータはオプションになります。たとえば、-D "uid=j.smith, o=Oblix.com"のようにします。
-f: ディレクトリの更新を定義する際に使用するLDIF更新文が含まれるファイル名を指定します。たとえば、-f changestomake.txtのようにします。
-h: ディレクトリ・サーバーがインストールされているコンピュータのホスト名またはIPアドレス。このエントリはオプションです。ホスト名が指定されなかった場合、LDAPSEARCHによってローカル・ホストが使用されます。たとえば、-h mozillaのようにします。
-H: 指定可能なすべてのLDAPMODIFYパラメータをリストします。
-p: ディレクトリ・サーバーが使用するポート番号。たとえば、-p 1049のようにします。
-w: -Dパラメータで指定された識別名と関連するパスワード。このパラメータを指定しなかった場合、匿名アクセスが使用されます。たとえば、-w passwordのようにします。
|
注意: Oracle Internet Directory LDAPツールは、環境変数LDAP_PASSWORD_PROMPTONLYがTRUEまたは1に設定された場合、安全性の低い-w passwordおよび-P passwordオプションを無効にするように変更されています。-q（または-Q）を使用すると、コマンドでユーザー・パスワード（またはウォレット・パスワード）を入力するよう求められます。可能なかぎり、この変数を設定することをお薦めします。 |
前の説明で、LDAPSEARCHを使用してJohn Kramerのレポートを作成しましたが、ここでは保存されたJohn Kramerの名前を変更します。作成されたレポートは、次のレポートでした。
dn: cn=John Kramer, ou=Sales, o=Company, c=US sn: Kramer cn: John Kramer givenname: John
この出力を使用して、ToHarveyという入力ファイルを導出できます。この入力ファイルの内容は、次のようになっています。
dn: cn=John Kramer, ou=Sales, o=Company, c=US changetype:modify replace:givenname givenname: Harvey
この場合、コマンドラインには次のように入力します。
ldapmodify - p 392 -f ToHarvey
さらに、コマンドラインから次のように入力してディレクトリを検索します。
ldapsearch -p 392 -b "ou=sales, o=company, c=US" -s sub "givenname=Harvey" sn cn givenname
この場合、レスポンスは次のようになります。
dn: cn=John Kramer, ou=Sales, o=Company, c=US sn: Kramer cn: John Kramer givenname: Harvey
アイデンティティ・システムのパフォーマンスを向上させるには、アイデンティティ・システム・サーバーとプラグインの構成が最適になるように、アイデンティティ・システムとディレクトリ・サーバーの相互操作の方法をチューニングできます。
この項の内容は次のとおりです。
「ディレクトリ・チューニングのガイドライン」で説明したように、ディレクトリ・サーバーは、Oracle Access Managerの全体的なシステム・パフォーマンスに大きく影響します。アイデンティティ・システムでは、ユーザーがディレクトリ内で実行する検索のタイプが、パフォーマンスに多大な影響を与えます。
この項では、ディレクトリでのアイデンティティ・システム検索の最適化に関して、次の内容について説明します。
ユーザーがアイデンティティ・システム・アプリケーションで検索を行う際には、入力内容と結果セットの比較方法を指定するためのオプションを含んだドロップダウン・リストが検索バーに表示されます。これらのオプションの詳細は次のとおりです。
次を含む
次の順序で含む
次と等しい
次より小さい
次より大きい
次で始まる
次で終わる
次と類似する
「次より大きい」演算子および「次より小さい」演算子を使用した場合、多数のエントリが検索および取得される可能性があります。これらの選択肢を排除すると、検索操作のパフォーマンスを向上させることができます。排除するには、後述の手順に従い、一連のパラメータ・ファイル内で検索操作の構成を変更します。
アイデンティティ・システムでは検索バーに加え、ユーザーによる検索フィルタの作成が可能なクエリー・ビルダー機能も提供されています。検索バーと同様、このクエリー・ビルダーからも、「次より大きい」および「次より小さい」の選択肢を排除できます。
「次より大きい」演算子および「次より小さい」演算子を排除する手順
検索バーを変更するために、テキスト・エディタで次のファイルをそれぞれ開きます。
Install_dir\identity\oblix\apps\userservcenter\bin\ userservcenterparams.xml
Install_dir\identity\oblix\apps\groupservcenter\bin\ groupservcenterparams.xml
Install_dir\identity\oblix\apps\objservcenter\bin\objservcenterparams.xml
Install_dir\identity\oblix\apps\selector\bin\selectorparams.xml
このInstall_dirは、Oracle Access Managerがインストールされているディレクトリです。
それぞれのファイルでObEnhanceSearchListパラメータのエントリを探します。
各ファイルでこのエントリを編集し、次のパラメータのみが含まれるようにします。
<ValNameList ListName="ObEnhanceSearchList" >
<NameValPair ParamName="OOS" Value="MOOS"/>
<NameValPair ParamName="OSM" Value="MOSM"/>
<NameValPair ParamName="OEM" Value="MOEM"/>
<NameValPair ParamName="OBW" Value="MOBW"/>
<NameValPair ParamName="OEW" Value="MOEW"/>
</ValNameList>
クエリー・ビルダーを変更するために、テキスト・エディタで次のファイルを開きます。
Install_dir\identity\oblix\apps\querybuilder\bin\querybuilderparams.xml
要素ObQBOperatorsListを編集して、次の値のみが含まれるようにします。
<ValList ListName="ObQBOperatorsList" >
<ValListMember Value="CND_CON"/>
<ValListMember Value="CND_DNC"/>
<ValListMember Value="CND_EQ"/>
<ValListMember Value="CND_NEQ"/>
<ValListMember Value="CND_PRE"/>
<ValListMember Value="CND_NPR"/>
<ValListMember Value="CND_BW"/>
<ValListMember Value="CND_EW"/>
</ValList>
検索でユーザーが入力する必要がある最小文字数を指定すると、ディレクトリ内で検索されるエントリが少なくなります。たとえば、ユーザーが最低3文字を入力しなければならないようにすれば、ディレクトリ検索で本来検索される可能性のあるすべてのエントリから、特定のサブセットのみが検索されて返される可能性が高まります。これにより、パフォーマンスを向上できます。
検索フィールドにユーザーが入力する必要がある最小文字数を指定する手順
主要検索バーにユーザーが入力する必要がある最小文字数を指定するには、テキスト・エディタで次のファイルを開きます。
Install_dir\identity\oblix\apps\common\bin\oblixappparams.xml
このInstall_dirは、Oracle Access Managerがインストールされているディレクトリです。
次の例のように、searchStringMinimumLengthパラメータの値をユーザーが入力できる最小文字数に設定します。
<NameValPair ParamName="SearchStringMinimumLength" Value="3"/>
グループ・マネージャの「グループ・メンバーの管理」ページに表示される検索バーにユーザーが入力する必要がある最小文字数を指定するには、テキスト・エディタで次のファイルを開きます。
Install_dir\identity\oblix\apps\groupservcenter\bin\ groupservcenterparams.xml
このInstall_dirは、Oracle Access Managerがインストールされているディレクトリです。
次の例のように、groupMemberSearchStringMinimumLengthパラメータの値をユーザーが入力できる最小文字数に設定します。
<NameValPair ParamName="groupMemberSearchStringMinimumLength" Value="3"/>
アイデンティティ・システム・アプリケーションで検索結果として返される要素の数には、制限を設定することができます。これにより、検索によるパフォーマンスへの影響を制限できます。
ディレクトリ・サーバーから返される検索結果の最大数は、ディレクトリ・サーバー・インスタンス・プロファイルの「サイズ制限」パラメータで構成できます。たとえば、このパラメータの値を1,000に設定した場合、検索結果として返されるのは最大1,000エントリとなります。デフォルト値の0は、検索結果が数に制限なく返されることを示します。
サイズ制限はディレクトリ・サーバー・プロファイルごとに異なる値で指定できます。たとえば、アイデンティティ・システム管理者が使用するディレクトリ・サーバー・インスタンスのサイズ制限を0（無制限）とし、エンド・ユーザーが使用するディレクトリ・サーバー・プロファイルのサイズ制限を1,000とするなどの構成が可能です。
アイデンティティ・システム・コンソールから「システム構成」をクリックします。
「システム構成」ページで「ディレクトリ・プロファイル」をクリックします。
データベース・インスタンスを追加するディレクトリ・サーバー・プロファイルのリンクをクリックします。
「ディレクトリ・サーバー・プロファイルの変更」ページが表示されます。
「データベース・インスタンス」を下へスクロールし、構成するデータベース・インスタンスをクリックします。
「データベース・インスタンスの変更」ページが表示されます。
ディレクトリ・サーバーから返される検索結果の最大数を示すように、「サイズ制限」パラメータを構成します。
アクセス・サーバーおよびアイデンティティ・サーバーは、ともにマルチスレッド化されています。すべてのアイデンティティ・イベント・プラグインがスレッド・セーフであることを確認してください。この推奨事項は、アイデンティティ・イベント・プラグインにも適用されます。
プールされたプライマリ構成で実行されているアイデンティティ・サーバーを2台以上使用するのは、効果的な方法です。プールされたプライマリ構成とは、プライマリのアイデンティティ・サーバーに接続している1つ以上のWebPassインスタンスとともに、複数のアイデンティティ・サーバーをプライマリ・サーバーとして使用する方法です。
プールされたプライマリ構成の方法を使用する場合、個別のアイデンティティ・サーバーをセカンダリ・サーバーとして使用できます。サーバーが2台しかない場合、プールされたプライマリ構成において、1台をプライマリ・サーバーとして使用し、もう1台をセカンダリ・サーバーとして使用することをお薦めします。プールされたプライマリ構成を実行する場合、アイデンティティ・サーバーに対して同じ仕様のハードウェアを個別に使用するのが最善の方法です。
プールされたプライマリ・モードのメリット
ロード・バランシングによるパフォーマンスの向上
複数のサーバーによる可用性の向上
自動フェイルオーバー
追加で必要となるハードウェアのコスト
セカンダリ・サーバーがない状態で他のプライマリ・サーバーが使用できない場合、予想される総負荷を処理できるように各プライマリ・サーバーのサイズを指定する必要があります。
追加で必要となるシステム構成
アイデンティティ・サーバー構成とスタイルシート・ファイルは、すべてのサーバーで一致させる必要があります。これは、複数のアイデンティティ・サーバーを使用するすべての構成に対して当てはまります。ファイル・システムのレベルから、すべてのアイデンティティ・サーバーを構成する必要があります。つまり、すべてのディレクトリとファイル・システムの構造を一致させる必要があります。
Windowsでは、アイデンティティ・サーバーの影響でメモリー使用率が高くなると、システムがクラッシュする可能性があります。これを回避するために、3GBの仮想アドレス領域を使用するようアイデンティティ・サーバーを構成できます（boot.iniファイルですでに2GBのアドレッシングが有効化されている場合）。アイデンティティ・サーバーは、今バージョンから3GBの仮想アドレス領域を使用できるようになりました。
デフォルトでは、アイデンティティ・サーバーの仮想アドレス領域は2GBに制限されています。Boot.iniファイル内に/3GBスイッチを構成すると、プロセス・ヘッダーでIMAGE_FILE_LARGE_ADDRESS_AWAREを使用しているアイデンティティ・サーバーに、3GBの仮想アドレス領域を割り当てられます。このスイッチを使用することで、アプリケーションは通常の2GBの制限値を超えて、追加の1GBの仮想アドレス領域をアドレッシングできるようになります。
次の例は、Boot.iniファイルに/3GBパラメータを追加して、アイデンティティ・サーバーのメモリー・チューニングを有効にする方法を示しています。
[boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(2)\WINNT [operating systems] multi(0)disk(0)rdisk(0)partition(2)\WINNT="????"/3GB
|
注意: Boot.iniファイルは、一般的にシステムのルート・ディレクトリにあります。 |
詳細は、次のURLを参照してください。
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
グループのサイズによっては、パフォーマンスが低下する場合があります。たとえば、30,000を超えるユーザーが所属するグループがいくつかある場合、こうしたグループに関連する操作は時間がかかります。同じように、ネストされたグループの場合も、ネストされたグループに所属する多数のメンバーのために、評価の際にパフォーマンスが低下することがあります。
次の項では、グループの使用に関するガイドラインを示します。
次の項では、アイデンティティ・システムでのパフォーマンスを向上するための、グループのチューニングに関する一般的な推奨事項を提供します。
Oracle Access Managerでは、動的グループのメンバーシップはフィルタ属性とユーザー属性に基づいて自動的に評価されます。そのため、通常は静的グループより動的グループのほうが簡単に管理できます。また、動的グループのメンバーシップ評価はリソース消費が少ないため、パフォーマンスを低下させることなく動的グループを必要なだけ大きくすることができます。
他のアプリケーションが静的グループのみに対応している場合は、アイデンティティ・システムのグループ・マネージャ・アプリケーションを使用して、グループをメンバーの静的リストに展開することができます。グループ展開が定期的に実行されるようにスケジューリングするには、expandGroup IdentityXMLまたはWebサービス・コールを使用して、cronジョブにグループ展開機能を追加することもできます。詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
次の手順を行うと、グループの評価機能を使用して属性アクセス制御のパフォーマンスを向上させることができます。リソースへのアクセスがグループによって決定されるときはいつでも、静的、動的およびネストされたグループの順序でグループのメンバーシップが評価されます。動的グループを使用しない場合は、動的グループの評価機能をオフにすることをお薦めします。
TurnOffDynamicGroupEvaluationをtrueに設定すると、ユーザー、グループおよび組織マネージャのプロファイル内の表示、変更、および通知の属性が影響を受けます（属性用のACLがグループ・メンバーシップに基づいて定義される場合）。このパラメータを使用すると、oblog.logファイルの次のメッセージは、対応するグループ・タイプがgroupdbparams.xmlで有効化されている場合にのみ表示されます。
動的グループ・メンバーシップのチェック
ネストされたグループ・メンバーシップのチェック
|
注意: アイデンティティ・サーバーのgroupdbparams.xmlファイルでTurnOffDynamicGroupEvaluationパラメータを使用しても、同じメカニズムを提供するIdentityXMLコールはオーバーライドされません。 |
『Oracle Access Manager開発者ガイド』に記述されているように、同じメカニズムを提供するIdentityXMLコールはオーバーライドされません。次のものがあります。
checkDynamic: 自分はユーザーはグループのメンバーか（このユーザーはグループのメンバーか）を確認します。
showDynamicGroups: 自分がメンバー、所有者または管理者であるグループを取得します（このユーザーがメンバー、所有者または管理者であるグループを取得します）。
showDynamicUserMembers: グループ・メンバーを表示します。
次の手順を行うと、属性アクセス制御に対して動的グループの評価機能をオフにすることができます。groupdbparams.xmlファイルのTurnOffDynamicGroupEvaluationパラメータをtrueに設定します。動的グループの評価機能をリストアするには、値をfalseに設定します。
アイデンティティ・サーバーに対して動的グループの評価機能をオフにする手順
エディタで次のファイルを開きます。
IdentiyServer_install_dir\identity\oblix\data\common\groupdbparams.xml
このIdentityServer_install_dirは、アイデンティティ・サーバーがインストールされているディレクトリです。
groupdbparams.xmlでTurnOffDynamicGroupEvaluationパラメータの値をtrueに設定します。
アイデンティティ・サーバーを再起動します。
デプロイメント内の各アイデンティティ・サーバーに対して、これらの手順を繰り返します。
groupdbparams.xmlファイルのパラメータに関する詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
ネストされたグループの評価では、グループのメンバーの属性を突き止めるために、LDAP問合せが繰り返し実行され、大量のリソースが消費されます。そのため、ネストされたグループについては、評価機能をオフにするか、機能を選択的に使用することをお薦めします。
ネストされたグループの評価を選択的に実行するには、IdentityXMLと、それに関連するWebサービス・コールviewGroupMembersを使用します。このコールには、次のパラメータのいずれかを含めることができます。
showStaticUserMembers
showDynamicUserMembers
showNestedUserMembers
詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
次の手順を行うと、アイデンティティ・システムで「グループ」に対してのみネストされたグループの評価機能をオフにすることができます。
アイデンティティ・システム内からネストされたグループの評価機能をオフにする手順
アイデンティティ・システム・コンソールから「グループ・マネージャ構成」をクリックします。
「グループ・マネージャ・オプションの構成」をクリックします。
ネストされたグループを許可（グループ・ページ内）およびグループのネストされたメンバーの表示（メンバーの管理ページ内）の各オプションを選択解除します。
次の手順を行うと、グループの評価機能を使用して属性アクセス制御のパフォーマンスを向上させることができます。リソースへのアクセスがグループによって決定されるときはいつでも、静的、動的およびネストされたグループの順序でグループのメンバーシップが評価されます。ネストされたグループを使用しない場合は、ネストされたグループの評価機能をオフにすることをお薦めします。
ネストされたグループを使用しない場合は、groupdbparams.xmlファイルのTurnOffNestedGroupEvaluationパラメータの値をtrueに設定します。ユーザー、グループおよび組織マネージャのプロファイル内の属性の表示、変更、および通知関数は影響を受けます（属性用のACLがグループ・メンバーシップに基づいて定義される場合）。このパラメータを使用すると、oblog.logファイルの次のメッセージは、対応するグループ・タイプがgroupdbparams.xmlで有効化されている場合にのみ表示されます。
動的グループ・メンバーシップのチェック
ネストされたグループ・メンバーシップのチェック
|
注意: アイデンティティ・サーバーのgroupdbparams.xmlファイルでTurnOffNestedGroupEvaluationパラメータを使用しても、同じメカニズムを提供するIdentityXMLコールはオーバーライドされません。 |
『Oracle Access Manager開発者ガイド』に記述されているように、同じメカニズムを提供するIdentityXMLコールはオーバーライドされません。次のものがあります。
checkNested: 自分はユーザーはグループのメンバーか（このユーザーはグループのメンバーか）を確認します。
showNestedGroups: 自分がメンバー、所有者または管理者であるグループを取得します（このユーザーがメンバー、所有者または管理者であるグループを取得します）。
showNestedUserMembers: グループ・メンバーを表示します。
次の手順を行うと、属性アクセス制御に対してネストされたグループの評価機能をオフにすることができます。groupdbparams.xmlファイルのTurnOffNestedGroupEvaluationパラメータをtrueに設定します。ネストされたグループの評価機能をリストアするには、値をfalseに設定します。
アイデンティティ・サーバーでネストされたグループの評価機能をオフにする手順
エディタで次のファイルを開きます。
IdentityServer_install_dir\identity\oblix\data\common\groupdbparams.xml
このIdentityServer_install_dirは、アイデンティティ・サーバーがインストールされているディレクトリです。
groupdbparams.xmlでTurnOffNestedGroupEvaluationパラメータの値をtrueに設定します。
アイデンティティ・サーバーを再起動します。
デプロイメント内の各アイデンティティ・サーバーに対して、これらの手順を繰り返します。
groupdbparams.xmlファイルのパラメータに関する詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
アイデンティティ・システムでグループを扱う場合は、一般的に大規模な静的グループを動的グループに置き換えることが最良です。静的グループを使用する必要がある場合は、次の項の静的グループ使用の推奨事項に従ってください。
大規模な静的グループがある場合は、グループ・プロファイル・パネルでのメンバー属性の表示を避け、検索結果表でメンバー属性が使用されないようにします。
ユーザーがグループ・プロファイル・ページを表示するたびに、そのユーザーによる表示が許可されているメンバーを特定するために、Oracle Access Managerでは多数の評価が実行されます。数千単位のメンバーが関与する場合は、ユーザーに付与されている各メンバーの表示許可を評価するのにかなりの時間がかかります。
グループ・プロファイル・パネルからメンバー属性を削除すると、メンバーの管理ページを使用してメンバーシップの操作（検索、メンバーの追加、メンバーの削除など）を処理できます。グループ・プロファイル・ページの一部としてメンバー・セマンティク属性を定義するのとは対照的に、このページは、（1000以上のメンバーを含む静的グループとして定義される）大規模なグループの管理を最適化します。これにより、大規模なグループを管理する際のパフォーマンスが大幅に向上します。ユーザー、グループおよび組織マネージャの構成に関する詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
グループ・プロファイル・パネルからメンバー属性を削除する場合の注意点は、グループ・メンバーシップの更新にIdentityXMLおよびWebサービス・コールmodifyGroupを使用できないことです。ただし、このコールはオーバーヘッドが発生するため推奨されていません。次に示すコールを使用するほうが適しています。
subscribeToGroup
subscribeUserToGroup
unsubscribeFromGroup
unsubscribeUserFromGroup
これらのコールでは、グループ・プロファイル・パネルでメンバー属性を構成する必要がありません。これらのコールでは、グループのサブスクリプション・ポリシーが使用されます。これらの操作では変更されたデータのみが対象となるため、大規模なグループに対する操作はmodifyGroupより短時間に処理されます。
アクセス制御ポリシーにメンバー・ロールを追加すると、ポリシーの評価に大量のオーバーヘッドが追加されます。これは、ポリシーが使用されるすべての場所でレスポンス時間に影響します。
静的グループが特に大きい場合、たとえばグループに10,000以上のメンバーが含まれる場合は、パフォーマンスに影響を及ぼす場合があります。静的グループが大きくなりすぎた場合は、そのグループに対して異なる評価アルゴリズムを使用することを選択できます。
グループの評価プロセスを変更する場合は、引き続きグループのメンバーが目的どおりに検索および評価されるように、アイデンティティ・システム構成で適切な変更を行う必要があります。変更の詳細は次のとおりです。
このグループのメンバーおよびサブグループは、グループ・プロファイル・ページに表示されない。
グループのメンバーを検索した場合、このグループのサブグループのメンバーは表示されない。
解決策として、ユーザーはサブグループ・プロファイル・ページを表示してサブグループのプロファイル・ページから検索を実行できます。
このグループのサブグループは、アイデンティティ・システム・ポリシーで評価されなくなる。
たとえば、サブグループおよびそのメンバーは、次の操作で受託者とみなされません。
属性の読取り権限と書込み権限の評価
検索ベースの定義
管理権限の委任
ワークグループ参加者の追加
解決策として、サブグループをポリシーに直接含めることができます。
エディタで次のファイルを開きます。
Identity_Server_installdir\identity\oblix\apps\common\bin\globalparams.xml
globalparams.xmlファイルで、LargeStaticGroupsパラメータにグループDNを追加します。
このパラメータを使用して、複数のグループの値を入力できます。次に例を示します。
<ValList xmlns="http://www.oblix.com"
ListName="LargeStaticGroups">
<ValListMember Value="cn=testgroup1,o=mycompany,c=us"></ValListMember>
<ValListMember Value="cn=testgroup2,o=mycompany,c=us"></ValListMember>
</ValList>
ファイルを保存します。
アイデンティティ・サーバーを再起動します。
アイデンティティ・サーバーが複数ある場合は、サーバーごとにこの手順を繰り返します。
グループ・マネージャはアイデンティティ・システム内のアプリケーションです。グループのサイズは、大規模なネストされたグループの場合は特に、グループ・マネージャ・アプリケーションのページでの操作のパフォーマンスを低下させる可能性があります。可能な場合は、ネストされたグループのかわりに動的グループを使用してください。
グループ・マネージャの3つのページをチューニングしてパフォーマンス最適化できます。ここでは、次の内容について説明します。
次の手順で、「グループ」ページのパフォーマンスをチューニングできます。
アイデンティティ・システム・コンソールから、「グループ・マネージャ構成」、「グループ・マネージャ・オプション」に移動します。
この画面にはいくつかのブール・フラグがあります。「変更」をクリックすることにより、このフラグを設定できます。この設定については、『Oracle Access Manager IDおよび共通管理ガイド』に記載されています。これらのフラグがシステムに対してどのような影響を与えるかを考える例として、ネストされたグループの表示というラベルの付いた設定を考えてみます。グループの階層の複雑さによっては、ネストされたグループの表示は時間のかかる操作になる場合があります。このオプションをfalseに設定すると、グループの表示は単純な形式に限定されますが、ページのパフォーマンスは大幅に向上します。
ディレクトリのパフォーマンスを向上させるために、「グループ」プロファイルで使用される次の属性に索引を付けます。
ObSDynamicMemberセマンティク型によって構成された属性
ObSStaticMemberセマンティク型として構成された属性
グループの動的フィルタで使用されるすべてのユーザー属性
「グループ」プロファイルに表示される結果をさらに修飾するために、オプションのグループ・フィルタを構成します。
このフィルタを使用してすべての検索ベースの検索結果をさらに修飾できます。このフィルタは、すべてのエントリが1つのコンテナに格納されるFATツリーで使用するのが最も一般的です。このフィルタの使用を制御するパラメータは、groupdbparams.xmlカタログのextra_group_filterとuse_extra_group _filter_mygroupsに設定されています。追加のフィルタは、LDAPフィルタであればどんなフィルタでもかまいません。また、追加のフィルタには、Oblixルール置換（$ $）を含めることができます。ルール置換を使用する場合、ユーザー・エントリの値が置き換えられます。これにより、ユーザー・エントリ内の値とグループ・エントリ内の値をリンクさせることができます。たとえば、ou=$ou$などのフィルタによってグループ・エントリを修飾する場合、ユーザーのouと一致させる必要のあるグループのouが指定されます。
デフォルトのスタイルシートであるgsc_myprofile.xslを、gsc_myprofile_simple.xslに置き換えます。
「グループ」ページのデフォルトのスタイルシートでは、参照可能なツリー形式にグループをレンダリングする際にDHTMLとレイヤーが使用されます。「グループ」ページで多くのグループを表示する必要がある場合、ブラウザによるページのレンダリングに時間がかかることがあります。gsc_myprofile_simple.xslスタイルシートの場合、より単純でブラウザに依存しないインタフェースが使用され、DHTMLやレイヤーはあまり使用されません。どちらのスタイルシートも、次のディレクトリに格納されています。
IdentityServer_install_dir/identity/oblix/lang/en-us/style0/ (stylesheet template)IdentityServer_install_dir/identity/oblix/shared/ (wrapper stylesheet)
スタイルシートとスタイルの詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
gsc_myprofile_simple.xslを使用する手順
次のレジストリ・ファイル内のXMLレジストリ設定を変更します。
IdentityServer_install_dir/identity/oblix/apps/groupservcenter/bin/groupservcenterreg.xml
このファイル内で、次の行を探します。
<ObStyleSheet name="gsc_myprofile.xsl"/>
この行を、次のように変更します。
<ObStyleSheet name="gsc_myprofile_simple.xsl"/>
アイデンティティ・サーバーとWebサーバーを再起動します。
次の手順で、「メンバーの表示」ページのパフォーマンスをチューニングできます。
3つのアイデンティティ・システム・コンソール・オプションを使用して、「メンバーの表示」ページの動作を制御できます。
これらのオプションは、「システム構成」、「グループ・マネージャ構成」、「グループ・マネージャ・オプション」の各ページからオンまたはオフにすることができます。これらのページに関する情報については、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
「メンバーの表示」ページで実行される検索を制限することができます。次のカタログから、groupMemberSearchStringMinimumLengthパラメータを探します。
IdentityServer_install_dir/identity/oblix/apps/groupservcenter/bin/ groupservcenterparams.xml
このパラメータは、グループ内のメンバーを検索する際にユーザーが入力しなければならない最小文字数を制御します。検索範囲がグループ・メンバーシップに限定される以外は、このパラメータの使用方法はsearchStringMinimumLengthパラメータと同じです（詳細は「索引処理と検索に関する制約」を参照）。
グループの動的フィルタで使用されるユーザー属性の索引を作成できます。
次の属性は、グループの拡張に使用されます。パフォーマンスを向上させる場合は、索引を作成する必要があります。
ObSDynamicMemberセマンティク型によって構成されたすべての属性
oblixadvancedgroupオブジェクト・クラスのobgroupexpandeddynamic属性
拡張対象グループの動的フィルタ内で使用されるすべてのユーザー属性
「グループ」ページのチューニングの説明のように、検索ベースの設定機能を使用して、サブドメインへのアクセスを適切にローカライズします。
これにより、「グループ拡張」ページのパフォーマンスも改善できます。
「グループ拡張」ページのパフォーマンスは、「グループ」ページのチューニングで説明した追加のグループ・フィルタ機能を使用して改善できます。
次に示す方法で、ワークフローのパフォーマンスをチューニングできます。
ワークフローについては、ディレクトリのチューニングと索引処理の項でも説明されています。詳細は、「ワークフロー・チケットのディレクトリへの保存」と「索引処理とワークフロー」を参照してください。
workflowdbparams.xmlファイルは、次の場所に格納されています。
IdentityServer_install_dir/identity/oblix/data/common
次のパラメータをチューニングして、ワークフローのパフォーマンスを改善することができます。これらのパラメータに対する変更を有効にするには、アイデンティティ・サーバーを再起動する必要があります。
WfDefCacheMaxNoOfElements: このパラメータは、ワークフロー定義キャッシュのサイズを指定します。このパラメータには、定義されているワークフローの数よりも大きな値を設定してください。
WfDefMaxNumStepDefFiltersPerSearch: このパラメータは、アイデンティティ・システムによってこのインスタンス・データで実行される検索の数を制御します。ユーザーが多数のワークフローのステップに参加している場合、このパラメータの値を大きくすると、ディレクトリの検索回数を減らすことができます。このパラメータを試す場合は、値を20ずつ大きくして試してください。値が大きくなるにつれてディレクトリの検索回数は減りますが、LDAPフィルタの長さは大きくなります。ディレクトリのCPU使用率を監視して、最適な値を設定してください。
ワークフローの検索パフォーマンスを改善する場合は、次のガイドラインを参照してください。
1ページ当たりに返される検索結果の数を確認します。デフォルト値は「20」です。1ページ当たりの数を大きくすると、パフォーマンスが下がることがあります。
ワークフローの参加者がフィルタとして指定されている場合、パフォーマンスが下がります。参加者を指定する場合、静的グループを使用できないかを確認します。
この項では、アクセス・サーバーのパフォーマンス・チューニングの方法を説明します。これ以降の内容は次のとおりです。
デフォルトでは、validate_passwordプラグインの一部としてOracle Access Managerによるユーザー・パスワードの検証が行われる場合、リクエストがユーザー・ディレクトリ・サーバーに渡されます。ディレクトリ・サーバーによってパスワードが検証され、結果がOracle Access Managerに返されます。この操作は時間がかかります。多数の認証が存在する環境でこの操作を実行した場合、アクセス・サーバーのパフォーマンスが低下します。
スキーマごとにパスワード検証を行う場合、アクセス・サーバーを使用するかディレクトリ・サーバーを使用するかを選択できます。
アクセス・サーバーによるパスワード検証の処理概要は、次のようになります。
最初にユーザー・パスワードの検証を行う場合、アクセス・サーバーはディレクトリ・サーバーに移動して検証を行います。
パスワードが検証されたら、アクセス・サーバーによってパスワードのMD5ハッシュがキャッシュされます。アクセス・サーバーは、クリアテキスト・パスワードのキャッシュは行いません。
次にユーザー・パスワードの検証が必要になった場合は、指定されたパスワードのMD5ハッシュがアクセス・サーバーによって作成され、前にキャッシュされたパスワードのハッシュと比較されます。
2つのキャッシュが一致した場合に、ユーザー・パスワードは有効だと認識されます。
2つのハッシュが一致しなかった場合、アクセス・サーバーはディレクトリに対してパスワードの検証を行います。ディレクトリによってパスワードが検証された場合、アクセス・サーバーによってこのパスワードのハッシュが作成され、キャッシュに保存されている古いハッシュが置き換えられます。
アクセス・サーバーによるパスワード検証を実行できるように認証スキームを構成するには、trueの値が設定されたObCredValidationByASパラメータをvalidate_passwordプラグインのリストに追加します。キャッシュされたパスワードのタイムアウトをスキーマごとに制御する場合、Time To Liveパラメータを使用します。Time To Liveパラメータのデフォルト値は1800秒（30分）です。パスワード検証の際にアクセス・サーバーがディレクトリに移動する間隔を制御するには、必要な秒数が指定されたobPwdHashTTLパラメータを追加します。
すぐに使用できるvalidate_passwordプラグインの例を、次に示します。
validate_password obCredentialPassword="password", obAnonUser="cn=anonymous, o=Company, c=US"
次に示すのは、デフォルトのTime To Liveパラメータが設定されたアクセス・サーバーによるパスワード検証を使用するように構成されたvalidate_passwordの例です。
validate_password obCredentialPassword="password", ,obCredValidationByAS="true", obAnonUser="cn=anonymous,o=Company, c=US"
次に示すのは、Time To Liveパラメータが100秒に指定されたアクセス・サーバーによるパスワード検証を使用するように構成されたvalidate_passwordの例です。
validate_password obCredentialPassword="password", ,obCredValidationByAS="true", obAnonUser="cn=anonymous,o=Company, c=US", obPwdHashTTL="100"
アクセス・サーバーはリクエスト・キューを使用して、ワーカー・スレッドによって処理された着信リクエストのシーケンスを作成します。
リクエスト・キューの値をデフォルト値の「1」より大きくすることにより、アクセス・サーバーのパフォーマンスを調整することができます。複数のリクエスト・キューを作成することにより、サービス・スレッドとメッセージ・スレッド間の競合を減らすことができます。これは、マルチプロセッサ・コンピュータの場合に特に有効です。詳細は、「リクエスト・キューの数を変更する手順」を参照してください。リクエスト・キューの数を変更した場合は、1つのキュー当たりのスレッド数も変更してください。詳細は、「必要なスレッドとキューの数の見積り」を参照してください。
リクエスト・キューにはアクセスゲートからのリクエストが格納され、処理されるまでキューに格納されたままの状態になります。デフォルトでは、リクエスト・キューは1つだけ設定されます。
アクセス・サーバーによって使用されるのは、次に示す3つのタイプのスレッドです。
メッセージ・スレッド
メッセージ・スレッドはアクセスゲートからの新しいリクエストを受け入れ、そのリクエストをリクエスト・キューに追加します。メッセージ・スレッドの数は、アクセスゲートとアクセス・サーバー間で開かれた接続数と同じになります。
サービス・スレッド
サービス・スレッドは、キューからリクエストを削除して処理します。各リクエスト・キューには、一定数のサービス・スレッドが構成されています。サービス・スレッドの数は、アクセス・システム・コンソールで定義します。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。デフォルトでは、1つのリクエスト・キューにつき60のサービス・スレッドが構成されます。1つのアクセス・サーバー当たりのサービス・スレッドの合計数は、リクエスト・キューの数と1つのキュー当たりのサービス・スレッド数をかけた値になります。
ユーティリティ・スレッド
これらは、ハウスキーピング・アクティビティを実行します。通常は、20～40のユーティリティ・スレッドが構成されます。この数字は、アクセス・サーバー用に構成されているディレクトリ・プロファイルの数や、定義されているファイル・ログ・ライターの数によって異なります。
スレッドの合計数を見積る場合、次のようにしてスレッドの各タイプの合計数を求めます。
メッセージ・スレッドの合計数
netstatコマンドを使用すると、アクセスゲートによってアクセス・サーバーに対して開かれた接続数を取得することができます。この接続数とメッセージ・スレッドの数をかけます。たとえば、50のWebGatesが構成されていて、各WebGatesにつき3つの接続がアクセス・サーバーに対して設定されている場合、メッセージ・スレッドの合計数は3と50をかけて150になります。
サービス・スレッドの合計数
サービス・スレッドの数は、アクセス・システム・コンソールで定義します。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
ユーティリティ・スレッドの合計数
上のパラグラフのガイドラインに基づき、平均値として30が安全な値として考えられます。
たとえば、50のWebGatesが構成されていて、各WebGatesにつき3つの接続がアクセスゲートに対して設定されている状態で、サービス・スレッドの数がアクセス・システム・コンソールで60に指定され、ユーティリティ・スレッドの数を30と見積った場合、合計スレッド数は150 + 60 + 30で240になります。
スレッド数が比較的少ないキューを多数構成した場合、リクエストが1つのキューに集中すると問題が発生する可能性があります。そのためスレッド数には、キュー当たりの最小スレッド数よりも大きな値を設定してください。ワーカー・スレッドの数は、コマンドラインまたはアクセス・サーバーの構成ページから設定できます。
アクセス・サーバーが1秒当たり800を超えるリクエストを処理している場合、リクエスト・キューの数を変更する必要があります。大まかな目安を次に示します。
ピーク時の1秒当たりのリクエスト数を800で割った値を、キューの数として設定します。
60をリクエスト・キューの数で割った値を、キュー当たりのスレッド数として設定します。
この算出方法は、ベンチマーク・テストとパフォーマンス・テストに基づいたものです。たとえば、アクセス・サーバー当たりのピーク時のリクエスト数が1秒間に2000と予想される場合、キューの数は2000を800で割っておよそ2になります。キュー当たりのスレッド数は、60を2で割って30になります。
キュー当たりのスレッド数には、適切な値を設定してください。少なすぎる値や多すぎる値は避けてください。ベンチマークによる適切なスレッド数は4ですが、ディレクトリ・サーバーの応答が遅い場合、スレッド数を増やす必要が出てくることがあります。大規模かつ高速なシステムで適切なパフォーマンスの向上を得ようとする場合、最適なスレッドの合計数は100に近い数字になることがあります。ただし、スレッド数の変化に従って厳密にパフォーマンスが左右されるわけではありません。
たとえば、16のキューが構成されていて各キューにつき16のスレッドが設定されている環境で（スレッドの合計数は256）、ディレクトリのアクセスを無効に設定した状態でラボのテストを行ったところ、1秒当たりのトランザクション数は約9,000でした。16のキューが構成されていて各キューにつき4つのスレッドが設定されている環境で（スレッドの合計数は64）前述のテストを行ったところ、1秒当たりのトランザクション数は約9,400でした。どんなに大規模なデプロイであっても、キューの数は8つで十分です。2～4つでも問題はありません。
|
注意: デフォルトのキュー・サイズは「1」です。アクセス・サーバーglobalparams.xmlの「numQ」パラメータを変更してサービス・スレッドとメッセージ・スレッド間の競合を減らすことは有益です。これは、マルチプロセッサ・コンピュータの場合に特に有効です。リクエスト・キューの数を変更する場合、サービス・スレッドも変更（削減）する必要があります。各キューには、それに関連するサービス・スレッドのセットが構成されているためです。 |
コマンドラインからアクセス・サーバーを起動する場合、次のように入力します。
aaa_server -i install_dir -Q n
このnは、リクエスト・キューの数を表しています。キューの数は、1024以下の整数値で指定する必要があります。
アクセス・サーバー・サービスをWindowsで使用する場合、サービスの起動パラメータとして-Qパラメータを指定する必要があります。または、次に示すスクリプトを変更して、-Qパラメータをこのスクリプト内に指定することもできます。
AccessServer_install_dir/access/oblix/apps/common/bin/start_access_server
アクセス・サーバーを再起動すると、このパラメータが有効になります。
ポリシー・ドメインに対するアクセス・ポリシーを定義した場合、そのドメイン内のリソースにユーザーがアクセスしようとするたびに、WebGateはデフォルトでアクセス・サーバーに問合せを行います。ポリシー・ドメインの範囲が広くなるほど、アクセス・サーバーに対する問合せの頻度も高くなります。たとえば、ポリシー・マネージャ内にポリシー・ドメインとしてルート（/）を指定した場合、Webサイト全体のいずれかのリソースにユーザーがアクセスしようとするたびに、WebGateはアクセス・サーバーに対して問合せを行います。
WebGateによるアクセス・サーバーへの問合せ回数を最小限にするには、DenyOnNotProtectedフラグを構成します。DenyOnNotProtectedフラグの値がtrueに設定されている場合、ルールまたはポリシーによって明示的にアクセスを許可されていないリソースに対するアクセスがすべて拒否されます。これにより、WebGateによるアクセス・サーバーへの問合せ回数を減らし、大規模なポリシー・ドメインや負荷の高いポリシー・ドメインのパフォーマンスを改善できます。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
APIベースのプラグインを使用した場合にアクセス・サーバーが不安定になる危険性を軽減するためのガイドラインを次に示します。
アクセス・サーバーにデプロイされているすべてのAPIベースのプラグインはスレッド・セーフであることを確認してください。
アクセス・サーバーおよびアイデンティティ・サーバーは、ともにマルチスレッド化されています。この推奨事項は、アイデンティティ・イベント・プラグインにも適用されます。
認可および認証のプラグインAPIがすべて永続的であることを確認し、接続プールおよびキャッシングの実装によってパフォーマンスを改善します。
プラグイン関数で使用されるグローバル変数およびローカル変数をすべて初期化します。
認可および認証のすべてのプラグインが、構成情報を指定するためにアクセス・サーバーから入力パラメータを取得することを確認します。
詳細は、「プラグイン」を参照してください。Oracle Access ManagerのAPIおよびプラグインの詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
アクセスゲート・クライアント構成には、無効なクライアントがアクセス・サーバーに接続するのを防ぐための、アクセス・サーバーとアクセスゲート間の秘密のパスワードが含まれます。アクセス・サーバーとアクセスゲートのクライアント間の通信を暗号化するために、SSLを実装することをお薦めします。また、シングル・サインオン・トークン（通常はObSSOCookieのコンテンツ）をパスワードとして扱い、外部のアプリケーションには提供しないでください。
詳細は、『Oracle Access Managerカスタマイズ・ガイド』の、プラグインを使用したアクセス制御のカスタマイズに関する章を参照してください。
アクセス・システムでのグループに関連する機能の構成は、パフォーマンスに影響します。デフォルトでは、グループのユーザー・メンバーシップを評価する際に、アクセス・サーバーは様々なタイプのグループ・メンバーシップをチェックします。ディレクトリ・サーバーで許可されるのは、次のタイプのグループ・メンバーシップです。
静的グループ・メンバーシップ
このタイプのグループでは、各ユーザーは明示的にメンバーとして定義されます。
動的グループ・メンバーシップ
このタイプのメンバーシップはLDAPルールによって定義されます。このLDAPルールと一致する各ユーザーが、グループのメンバーです。
ネストされたグループ・メンバーシップ
ネストされたグループは、1つ以上の静的グループ、動的グループまたはその両方で構成されます。
アクセス・サーバーによってグループ・メンバーシップが評価されるのは、次の場合です。
認可スキームを作成して1つ以上のユーザー・グループに割り当てる場合。たとえば、経理グループのすべてのメンバーにアカウント・データへのアクセスを付与する場合。
obmygroups属性を含む認可アクションまたは認証アクションを定義する場合、アクセス・サーバーはユーザーが所属するすべてのグループを検索し、グループのリストをCookieまたはヘッダーに返します。
次の各項では、アクセス・システムでのグループ・メンバーシップの評価のガイドラインを示します。
動的グループ・メンバーシップは、フィルタ属性とユーザー属性に基づいて自動的に評価されます。そのため、通常は静的グループより動的グループのほうが簡単に管理できます。また、動的グループのメンバーシップ評価はリソース消費が少ないため、パフォーマンスを低下させることなく動的グループを必要なだけ大きくすることができます。
ユーザー認証の構成の詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。動的グループを使用しない場合のパフォーマンス向上の詳細は、「動的グループを使用しない場合のグループ検索パフォーマンスの向上」を参照してください。
デフォルトでは、グループベースの認可ルールを使用してリソースへのアクセスが保護されている場合、ユーザー・メンバーシップがグループ・メンバーシップによって決定されます。グループは静的、動的、そしてネストされたグループの順序で評価されます。obmygroups属性値の評価も、同じ順序で行います。
グループ・メンバーシップが評価されるのは、次の場合です。
グループベースの認可ルール
obmygroupsパラメータを使用する認証アクションおよび認可アクション
認可スキームにアクセスの許可およびアクセスの拒否を割り当てられるグループ
ポリシー・マネージャでのアクセス・テスター操作
現在、アクセス・サーバー（アクセス・テスターを使用する場合はポリシー・マネージャ）によって、グループのタイプが有効になっている場合にのみ、メンバーシップに対するグループがタイプとして評価されます。動的グループを使用しない、または存在する動的グループを評価しない場合、グループ評価のパフォーマンスを向上させるには、次の手順に従って動的グループの評価機能をオフにします。
|
注意: エンド・ユーザーのアクセスに影響するため、この手順は注意して行うことをお薦めします。 |
デフォルトでは、認可を決定するために、アクセス・サーバーによって静的、動的およびネストされたグループ・メンバーシップがチェックされます。ただし、動的グループ・メンバーシップだけに基づく認可ポリシーがあるか、または認証アクションheaderVarやCookieをobmygroupsとして構成していると想定します。TurnOffDynamicGroupEvaluationの値をtrueに設定すると、動的グループのメンバーであるユーザーが保護されたリソースを要求する場合、アクセス・サーバーは（指示のとおりに）動的グループの評価をスキップし、ユーザーはアクセスが拒否されたことを示すメッセージを受信します。ObMyGroups headerVarの場合は、グループ名はメッセージに表示されません。
エディタで次のファイルを開きます。
AccessServer_install_dir\access\oblix\apps\common\bin\globalparams.xml
このAccessServer_install_dirは、アクセス・サーバーがインストールされているディレクトリです。
globalparams.xmlで、TurnOffDynamicGroupEvaluationパラメータの値をtrueに設定します。次に例を示します。
<SimpleList> <NameValPair ParamName="TurnOffDynamicGroupEvaluation" Value="true" /> </SimpleList>
アクセス・サーバーを再起動します。
デプロイメント内の各アクセス・サーバーに対して、これらの手順を繰り返します。
アクセス・テスター: これらの手順を繰り返してポリシー・マネージャのglobalparams.xmlファイルのTurnOffDynamicGroupEvaluationパラメータの値をtrueに設定し、ポリシー・マネージャWebサーバーを再起動します。デプロイメント内の各ポリシー・マネージャに対して、これらの手順を繰り返します。
PolicyManager_install_dir\access\oblix\apps\common\bin\globalparams.xml
PolicyManager_install_dirは、ポリシー・マネージャがインストールされているディレクトリです。
ObMyGroupsの詳細は、「ObMyGroupsの考慮事項」を参照してください。globalparams.xmlファイルの詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
ネストされたグループは注意して使用してください。デフォルトでは、認可を決定するために、アクセス・サーバーによって静的、動的およびネストされたグループ・メンバーシップがチェックされます。ネストされたグループ・メンバーシップの評価は、大量のリソースを消費します。LDAPディレクトリ・サーバーは、ネストされたグループのメンバーの属性値を特定するために、問合せを繰り返し実行する必要があります。ネストされたグループを使用しない場合は、ネストされたグループ・メンバーシップのチェック機能を無効にすると、パフォーマンスが向上します。
次の手順を行うと、アクセス・システムのネストされたグループの評価機能を無効にすることができます。
|
注意: エンド・ユーザーのアクセスに影響するため、この手順は注意して行うことをお薦めします。 |
ネストされたグループをチェックするのは、デフォルトの動作です。ただし、ネストされたグループ・メンバーシップだけに基づく認可ポリシーがあるか、または認証アクションheaderVarやCookieをObMyGroupsとして構成していると想定します。TurnOffNestedGroupEvaluation=trueを設定すると、ネストされたグループのメンバーであるユーザーが保護されたリソースを要求する場合、アクセス・サーバーは（指示のとおりに）ネストされたグループの評価をスキップし、ユーザーはアクセスが拒否されたことを示すメッセージを受信します。ObMyGroups headerVarの場合は、グループ名はメッセージに表示されません。
アクセス・システムでネストされたグループの評価機能をオフにする手順
エディタで次のファイルを開きます。
AccessServer_install_dir\access\oblix\apps\common\bin\globalparams.xml
このAccessServer_install_dirは、アクセス・サーバーがインストールされているディレクトリです。
globalparams.xmlでTurnOffNestedGroupEvaluationパラメータの値をtrueに設定します。
アクセス・サーバーを再起動します。
デプロイメント内の各アクセス・サーバーに対して、これらの手順を繰り返します。
アクセス・テスター: これらの手順を繰り返してポリシー・マネージャのglobalparams.xmlファイルのTurnOffNestedGroupEvaluationパラメータの値をtrueに設定し、ポリシー・マネージャWebサーバーを再起動します。デプロイメント内の各ポリシー・マネージャに対して、これらの手順を繰り返します。
PolicyManager_install_dir\access\oblix\apps\common\bin\globalparams.xml
PolicyManager_install_dirは、ポリシー・マネージャがインストールされているディレクトリです。
詳細は、『Oracle Access Managerアクセス管理ガイド』のユーザー認証の構成に関する章を参照してください。globalparams.xmlファイルの詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
『Oracle Access Managerアクセス管理ガイド』に記載されているように、認証ルールまたは認可ルール内でobmygroupsパラメータを構成できます。このパラメータは、アクセス・システムを他のアプリケーションと統合する場合に役立ちます。このパラメータは、ユーザーのグループ・メンバーシップをディレクトリ内で検索します。これにより、ユーザーのロール・ベース情報が提供されます。次に例を示します。
ディレクトリ内の少数のグループのみのメンバーにアクセス権が提供される一連のURLとして、アプリケーションを定義できます。
obmygroupsパラメータを設定してグループ・メンバーシップ情報をアプリケーションに提供することで、アプリケーションが直接ディレクトリに対して問合せを実行したり、グループ（静的、動的、ネストされているのいずれか）を特定する必要がなくなります。
obmygroupsパラメータを設定して、ユーザーが所属するグループに基づいて、アプリケーションがナビゲーションや外観をカスタマイズできるようにします。
特定のメニュー・アイテムおよび機能をグループ・メンバーシップに基づいて設定できます。
obmygroupsパラメータを構成する場合、デフォルトではOracle Access Managerによってアクセス・システム検索ベースのすべてのグループ・オブジェクトが検索され、ユーザーとグループの関係のキャッシュがアクセス・サーバーに作成されます。このキャッシュはグループ問合せキャッシュと呼ばれます。問合せに適用されるOracle Access Manager ACLはありません。ユーザーがこれらのグループのクラス属性に対する読取り権限を持つかどうかに関係なく、ユーザーが所属するすべてのグループが提供されます。Oracle Access Managerは、obmygroupsが含まれるアクションを使用したポリシーで保護される各リソースに対して、グループ問合せキャッシュ全体を評価します。ユーザーが属するかどうかを確認するために、キャッシュ内のすべてのグループをチェックする必要があります。この検索は大量のリソースを消費します。
グループ問合せキャッシュは、10分ごとにタイムアウトになります。Oracle Access Manager 10g（10.1.4.3）までは、アクセス・サーバーのグループ・キャッシュ・タイムアウト値を調整したり、アクセス・サーバーのグループ・キャッシュ内の要素の最大数を設定したりすることはできませんでした。認可アクションでobmygroupsを設定する場合やアクセス・サーバーのグループ・キャッシュを構成する場合は、次のガイドラインに従ってください。
常にLDAPフィルタを使用してobmygroupsを使用するアクションを構成します。次に例を示します。
obmygroups:ldap:///o=company,c=us??sub?(group_type=role)
一般的に最適な方法は、認可アクションのかわりに認証ルールでobmygroupsを指定することです。
できるかぎりアクションをCookieとして設定し、余分なコストをかけずに同じWebサーバー上のその他のアプリケーションでデータが使用できるようにしてください。
obmygroupsを認可ルール内で使用する場合、最小限のリソース（URL）に使用を制限してください。
動的グループを使用しない場合は、動的グループの評価機能をオフにします。
詳細は、「アクセス・システムで動的グループの評価機能をオフにする手順」を参照してください。
ネストされたグループを使用しない場合は、ネストされたグループの評価機能をオフにします。
詳細は、「アクセス・システムでネストされたグループの評価機能をオフにする手順」を参照してください。
Oracle Access Manager 10g（10.1.4.3）に導入された新しいアルゴリズムを使用して、静的グループ、動的グループおよびネストされたグループの、ObMyGroupsを含む評価のパフォーマンスを向上できます。
「ObMyGroups評価のパフォーマンスの向上」を参照してください。
アクセス・サーバーのグループ・キャッシュの詳細情報を構成する手順
「アクセス・サーバーのグループ・キャッシュ・タイムアウトおよび最大要素数の構成」を参照してください。
ObMyGroupsの詳細は、『Oracle Access Managerアクセス管理ガイド』のユーザー認証の構成に関する章を参照してください。
認証ルールまたは認可ルール内でobmygroupsパラメータを構成する場合、デフォルトではOracle Access Managerによってアクセス・システム検索ベースのすべてのグループ・オブジェクトが検索され、ユーザーとグループの関係のキャッシュがアクセス・サーバーに作成されます。検索されるグループの数によっては、ObMyGroups処理に時間がかかることがあります。
Oracle Access Manager 10g（10.1.4.3）では、ObMyGroupsを含む評価のパフォーマンスが改善されています。たとえば、大規模なグループには、何千人もの静的メンバーを含めることができます。以前のリリースでは、アクセス・サーバーによって、すべての属性を含むグループ・エントリ全体が読み取られます。また、アクセス・サーバーによってobmygroups評価ときおよびグループベースの認可ときにエントリがキャッシュされます。ただし、最新のリリースでは、必要な属性（uniquemember、groupfilterなど）以外のすべての属性の取得はLDAP問合せに依存します。また、エントリ全体のキャッシングが無効になっているため、LDAP問合せ内の属性のみがキャッシュされます。
これに加えて、10g（10.1.4.3）では、ObMyGroups: TurnOffNewAlgorithmForObmyGroupsを含むグループの評価機能で使用できる新しいアルゴリズムを構成できます。このアルゴリズムは、静的グループ、動的グループおよびネストされたグループのときと同様に作動します。
次の3つのシナリオで、新しいパラメータによってパフォーマンスが向上されます。
ObMyGroups評価の改善
ネストされたグループ・メンバーシップの評価の改善
循環グループ評価
新しいアルゴリズムは、デフォルトで有効になっています。すべての場合に、新しいアルゴリズムによって、最初にグループ キャッシュをチェックしてユーザーがすでに評価されているかを確認するボトムアップ・アプローチが使用されます。それぞれの特定のシナリオにおけるパフォーマンスの改善の詳細は次のとおりです。
ObMyGroups評価の改善: 本来は、アクセス・サーバーによって、ObMyGroupsおよびグループベース認可の評価のために共通のロジックが共有されました。10g（10.1.4.3）では、ObMyGroups HeaderVar用のグループ・メンバーシップの評価プロセスが最適化されています。TurnOffDynamicGroupEvaluationの値をtrueに設定すると、動的グループの評価がスキップされ、この値をfalseに設定すると、動的グループの評価が実行されます。
ネストされたグループ・メンバーシップの評価の改善: 10g（10.1.4.3）では、ObMyGroups用のグループ・メンバーシップの評価プロセスが最適化されています。TurnOffNestedGroupEvaluationの値をtrueに設定すると、ネストされたグループの評価がスキップされ、この値をfalseに設定すると、ネストされたグループの評価が実行されます。
ネストされた循環グループ評価: 以前の10gアルゴリズムを使用する場合、アクセス・サーバーはネストされたグループを評価するときに、循環依存の1つのレベルをチェックしてグループが自分自身を一意のメンバーとして含んでいるかを決定しました。ネストされた循環グループの評価中に、アクセス・サーバーが応答しなくなる場合があります。10g（10.1.4.3）アルゴリズムにより、処理は効率化され、アクセス・サーバーが応答しない現象を引き起こす問題は解消されます。
次の表に、アクセス・サーバーのglobalparams.xmlファイルのTurnOffNewAlgorithmForObmyGroupsに設定できる値を示します。
表3-2 TurnOffNewAlgorithmForObmyGroupsパラメータの値
| 値 | 説明 |
|---|---|
|
true |
以前のリリースで提供した元のアルゴリズムを使用します。 |
|
false |
デフォルトの値はfalseであるため、新しいアルゴリズムが使用されます。 |
|
パラメータなし |
デフォルトの値が想定され、新しいアルゴリズムが使用されます。 |
TurnOffNewAlgorithmForObmyGroupsパラメータを再構成する手順
エディタで次のファイルを開きます。
AccessServer_install_dir\access\oblix\apps\common\bin\globalparams.xml
AccessServer_install_dirは、アクセス・サーバーがインストールされているディレクトリです。
元の10gアルゴリズムの使用: TurnOffNewAlgorithmForObmyGroupsパラメータの値をtrueに設定して新しいアルゴリズムをオフにします。
10g（10.1.4.3）のデフォルトのアルゴリズムのリストア: 以前のリリースのアルゴリズムを使用していて、10g（10.1.4.3）アルゴリズムをリストアしたい場合、TurnOffNewAlgorithmForObmyGroupsパラメータの値をfalseに設定します（またはパラメータなし状態であることを確認します）。次に例を示します。
<SimpleList> <NameValPair ParamName="TurnOffNewAlgorithmForObmyGroups" Value="false" /> </SimpleList>
アクセス・サーバーを再起動します。
デプロイメント内の各アクセス・サーバーに対して、これらの手順を繰り返します。
10g（10.1.4.3） アルゴリズムを使用してネストされたグループのパフォーマンスをさらに向上させるには、次のパラメータと値をglobalparams.xmlファイルに追加します。
<SimpleList>
<NameValPair ParamName="NestedQueryLDAPFilterSize" Value="10" />
</SimpleList>
|
注意: 10はNestedQueryLDAPFilterSizeのデフォルト値です。次のガイドラインに従って値を選択します。
|
ObMyGroupsおよびグループ・メンバーシップを評価するときに、効率的なパフォーマンスのために、アクセス・サーバーによっていくつかのキャッシュにグループの情報が格納されます。ただし、古いデータを定期的にフラッシュする必要があります。システム・コンソールには、アクセス・サーバーのグループ・キャッシュをフラッシュするGUI項目はありません。Oracle Access Manager 10g（10.1.4.3）までは、アクセス・サーバーのグループ・キャッシュ・タイムアウト値を調整したり、アクセス・サーバーのグループ・キャッシュ内の要素の最大数を設定したりすることはできませんでした。
アクセス・サーバーのグループ・キャッシュのデフォルト値を表3-3に示します。
表 3-3 アクセス・サーバーのグループ・キャッシュのデフォルト値
| キャッシュ名 | デフォルト・タイムアウト | デフォルト最大ユーザー要素数 |
|---|---|---|
|
ユーザー・ルール・キャッシュ |
2400秒 |
100,000要素 |
|
ユーザー・グループ・キャッシュ |
2400秒 注意: 現在はデフォルト値はありませんが、2400秒をデフォルト値とすることができます。 |
10,000要素 |
|
グループ定義キャッシュ |
2400秒 |
100,000要素 |
|
グループ問合せキャッシュ |
600秒 |
100,000要素 |
ただし、このリリースでは、キャッシュ・タイムアウト値を設定できるおよびグループ・キャッシュ内の最大要素数を定義できるように2つのパラメータが提供されています。Oracle Access Managerは、グループを評価するためにいくつかの内部キャッシュとともにグループ・キャッシュ・タイムアウトと最大要素数のパラメータも使用します。詳細は、次の項目を参照してください。
GroupCacheTimeoutパラメータを使用すると、アクセス・サーバーのグループ・キャッシュ内の要素の有効時間を指定できます。このパラメータを、アクセス・サーバーのglobalparams.xmlファイル（または、アクセス・テスターを使用する場合ポリシー・マネージャ）に追加する必要があります。
表3-3に、デフォルト動作が定義されています。
GroupCacheTimeoutパラメータに指定できる値を表3-4に示します。
表3-4 GroupCacheTimeoutの値
| 値 | 説明 |
|---|---|
|
正の整数 |
タイムアウトを秒単位で指定 |
|
0 |
要素がタイムアウトしないように指定 |
|
-1 |
デフォルト値。下位互換性を保証 |
|
負の整数、パラメータなしまたは無効な値 |
このパラメータを無効にし、キャッシュごとにデフォルト値をリストア |
エディタでアクセス・サーバーのglobalparams.xmlファイルを開きます。
AccessServer_install_dir\access\oblix\apps\common\bin\globalparams.xml
AccessServer_install_dirは、アクセス・サーバーがインストールされているディレクトリです。
表3-4を参照して、globalparams.xmlでGroupCacheTimeoutパラメータの値を設定します。
アクセス・サーバーを再起動します。
デプロイメント内の各アクセス・サーバーに対して、これらの手順を繰り返します。
アクセス・テスター: これらの手順を繰り返してポリシー・マネージャのglobalparams.xmlファイルのGroupCacheTimeoutパラメータの値を設定し、ポリシー・マネージャWebサーバーを再起動します。デプロイメント内の各ポリシー・マネージャに対して、これらの手順を繰り返します。
PolicyManager_install_dir\access\oblix\apps\common\bin\globalparams.xml
このPolicyManager_install_dirは、ポリシー・マネージャがインストールされているディレクトリです。
新しい値によってパフォーマンスが低下する場合は、表3-3に示すデフォルト値をリストアします。
GroupCacheMaxElementパラメータは、アクセス・サーバーのグループ・キャッシュに格納できる最大要素数を指定します。
表3-3に、デフォルト動作が定義されています。
正の整数値を使用して、キャッシュに格納できる最大要素数を指定します。GroupCacheMaxElementパラメータに指定できる値を表3-5に示します。
表3-5 GroupCacheMaxElementの値
| 値 | 説明 |
|---|---|
|
正の整数 |
最大要素数を指定 |
|
0 |
無限の要素を格納できるように指定 |
|
-2 |
デフォルト値（下位互換性を保証） |
|
パラメータなし、または無効な値 |
このパラメータを無効にし、キャッシュごとにデフォルト値をリストア |
エディタでアクセス・サーバーのglobalparams.xmlファイルを開きます。
AccessServer_install_dir\access\oblix\apps\common\bin\globalparams.xml
AccessServer_install_dirは、アクセス・サーバーがインストールされているディレクトリです。
表3-5を参照して、globalparams.xmlでGroupCacheMaxElementパラメータの値を設定します。
アクセス・サーバーを再起動します。
デプロイメント内の各アクセス・サーバーに対して、これらの手順を繰り返します。
アクセス・テスター: これらの手順を繰り返してポリシー・マネージャのglobalparams.xmlファイルのGroupCacheMaxElementパラメータの値を設定し、ポリシー・マネージャWebサーバーを再起動します。デプロイメント内の各ポリシー・マネージャに対して、これらの手順を繰り返します。
PolicyManager_install_dir\access\oblix\apps\common\bin\globalparams.xml
このPolicyManager_install_dirは、ポリシー・マネージャがインストールされているディレクトリです。
新しい値によってパフォーマンスが低下する場合は、表3-3に示すデフォルト値をリストアします。
ポリシー・マネージャのglobalparams.xmlファイルにldapFilterSizeLimitInBytesというパラメータを構成できます。このパラメータは、LDAP検索フィルタのサイズを制御します。globalparams.xmlに明示的に値を設定しないか1未満の値を設定した場合、デフォルト値の1024（1Kb）が設定されます。
詳細は、『Oracle Access Managerカスタマイズ・ガイド』のパラメータ・ファイルに関する付録を参照してください。
Oracle Access Managerでは、パフォーマンスを向上させるためにキャッシュの数をチューニングできます。詳細は、次の項目を参照してください。
改良されたキャッシュ・フラッシュ操作の詳細は、第5章を参照してください。
ポリシー・キャッシュには、ポリシー・ドメインに関する情報（URL以外）、ポリシーの説明、表示名が格納されます。ポリシー・キャッシュの要素には、次のものがあります。
ルール
ルールに関連するアクション
ルールに関連するフィルタ、グループ、ロール
ルールに対するポリシー条件
すべてのポリシー・ドメイン
すべてのポリシー
すべての認証スキーム
「ポリシー・キャッシュ内の最大要素」と「ポリシー・キャッシュ・タイムアウト」パラメータを設定することにより、ポリシー・キャッシュのチューニングを行います。
|
注意: これらのパラメータは、『Oracle Access Managerアクセス管理ガイド』にも記載されています。 |
必要な要件を判断するには、すべてのポリシー・ドメインとポリシー内の認可ルールの合計数を算出します。そのためには、次のフィルタを使用してOblixディレクトリ・ツリーを検索します。
"(objectclass=oblixpolicyrule)"
ポリシー・キャッシュ内の要素数を決定する場合、ルールの数が今後増えていくことを考慮する必要があります。
アクセス・サーバーのポリシー・キャッシュ要素に対するメモリー要件を算出するには、ポリシーの格納に使用されるディレクトリのメモリー要件を確認します。
この値は、アクセス・サーバーに設定する値とほぼ同じになります。
ポリシー・ドメイン、ルール、またはポリシーが作成または変更される場合、管理者は各ページの「キャッシュの更新」に対する権限を持ちます。これらのページが保存されると、関連するポリシー・キャッシュがただちにフラッシュされ、即時に変更が反映されます。
ポリシーを変更する際に管理者が「キャッシュの更新」ボタンを押さないかぎり、セキュリティ対策として、またはキャッシュのクリーンアップ方法として、定期的にキャッシュのタイムアウトを実行することができます。アクセス・システムのキャッシュを自動的にフラッシュする方法については、『Oracle Access Managerアクセス管理ガイド』を参照してください。
ユーザー・キャッシュのチューニングに使用するパラメータは、「ユーザー・キャッシュ内の最大要素」と「ユーザー・キャッシュのタイムアウト」から指定します。
ユーザー・キャッシュには、監査アクションとHTTPアクションで使用されるすべてのユーザー属性と値が格納されます。バルク・ユーザー属性値を変更しない場合の最小時間を指定する必要があります。この値が大きすぎる場合、キャッシュがフラッシュされるまで、リスク管理の観点から重要と考えられる値がOracle Access Managerに渡されなくなる可能性があります。これは、変更を行った後で管理者がキャッシュの更新を行わなかった場合に問題となることがあります。管理者、委任ID管理者、またはユーザーがディレクトリ内のユーザー値を変更した場合、実際にはキャッシュ内の値がフラッシュされるまで変更は反映されないのにもかかわらず、すでに変更は反映されているものと考えてしまう可能性があるためです。
それとは反対に、ユーザーがサイトにアクセスしている間にデータがフラッシュされてしまうような小さなタイムアウト値やキャッシュ・サイズを指定することも避けてください。ディレクトリに対して余分な参照が実行されてしまうためです。
ユーザー値を更新する場合の適切な間隔を見積るには、平均セッション時間を24時間の範囲で追跡します。「ユーザー・キャッシュのタイムアウト」の値には、この平均セッション時間と同じかそれよりも少し大きな値を設定します。
URL接頭辞キャッシュにより、「アクセス・サーバー構成」ページに指定した「URL接頭辞のリロード間隔」値に基づいてURL接頭辞のフラッシュ間隔が設定されます。URL接頭辞のリロード間隔を指定することにより、追加の保護対策として自動フラッシュを実行できます。URL接頭辞がポリシー・ドメインやポリシーに追加された場合、管理者は「キャッシュの更新」ボタンをクリックしてキャッシュの自動フラッシュを実行できます。
URL接頭辞のリロード間隔により、URLがディレクトリ・サーバーからリロードされるまでに経過する時間が（秒単位）指定されます。「アクセス・サーバー構成」ページの「URL接頭辞のリロード間隔（秒単位）」フィールドに、このアクセス・サーバーが新しいURLを認識する頻度を表す数字 （キャッシュの自動フラッシュ間の時間）を入力します。
URL接頭辞のリロード間隔のデフォルト値は7200秒（2時間）です。たとえば、10分ごとにキャッシュをフラッシュするには、「URL接頭辞のリロード間隔（秒単位）」フィールドに、600を入力します。600秒= 10分です。この場合、URLは10分ごとにディレクトリ・サーバーからリロードされます。これは、特定のURL接頭辞キャッシュ・フラッシュのリクエストがアクセス・サーバーに届かなかった場合に役立ちます。
WebGateにより、認証に関する情報と、リソースが保護されているかどうかの情報がキャッシュされます。WebGateキャッシュをチューニングする場合、タイムアウト間隔内で予想される一意のURLの合計数を参照します。
認証スキームが短い間隔で変更されることはほとんどありません。URL接頭辞が変更中や追加中である可能性も低いと考えられます。管理者がURL接頭辞の追加、変更、削除を行う場合、そのページ上にはキャッシュの即時フラッシュを行うために使用できる「キャッシュの更新」ボタンが配置されています。
WebGateキャッシュのタイムアウトのデフォルト値はゼロ（0）です。この場合、キャッシュの自動更新は行われず、管理者が「キャッシュの更新」ボタンを押した場合のみキャッシュがフラッシュされます。このデフォルト値を変更する場合、URLがキャッシュから自動的にフラッシュされるまでの適切な間隔を指定してください。
URLを保護する必要があるかどうかを判断する場合に、WebGateによってURLをキャッシュすることにより、アクセス・サーバーやディレクトリ・サーバーを参照しないようにすることができます。「キャッシュ内の最大要素」のデフォルト値は100,000です。このパラメータの適切な値を求めるには、Webサーバーによって保護されているURLの数と、それに関連するHTTP操作を確認します。
Webブラウザにより、URLに対する内部制限は4096バイトに指定されています。ほとんどのURLは、4096バイト未満です。キャッシュの上限値を決定する場合、URLの平均的なサイズをどう設定するかにより、4096バイトにするかそれよりも小さいサイズにするかを選択します。
1つのキャッシュ要素当たりのメモリー要件の算出手順:
1つのキャッシュ要素当たりのメモリー= URL（4096バイト）+オーバーヘッド（128バイト）= 4224バイト
最大キャッシュ要素に対するメモリー要件の算出手順:
必要なメモリー= 100,000要素* 4224バイト/要素= 422,400,000バイト= 422 MBメモリー
WebGateがオンになっているWebサーバーのニーズとURLの平均サイズに応じて要素の最大数が小さくなる場合、メモリー要件も小さくなることがあります。
Oracle Access Managerにより、寿命の短い内部DBAgentキャッシュが維持されます。このキャッシュには、ユーザー・マネージャ、グループ・マネージャおよび組織マネージャのプロファイルの表示や変更操作中に、アイデンティティ・サーバーによってディレクトリ・サーバーから情報が取得される際に読み取られる、すべての構造型オブジェクト・クラスおよび補助型オブジェクト・クラスの属性の全リストが格納されています。
大きい属性の値のキャッシングによって、パフォーマンスが影響される可能性があります。OSDキャッシュとは違って、DBAgentキャッシュに直接アクセスすることはできません。ただし、次の条件を満たす不要な属性の読取り機能を無効にするようにDBAgentキャッシを設定することで、パフォーマンスを向上させることができます。
大きい値がある属性（たとえば、description）
常に必要なわけではない属性（表示または変更する必要のない属性）
次の場所に格納されているアイデンティティ・サーバーのglobalparams.xmlファイルに特定の属性のリストを作成することにより、ブラウザ・ウィンドウでのプロファイルの表示と変更操作のときに不要な属性値の読取りとキャッシングを排除することができます。
IdentityServer_install_dir/identity/oblix/apps/common/bin/globalparams.xml
リストは（このリストは定義された属性を排除するためネガティブ・リストと呼ばれる）negativeListForEntityAttributesパラメータに関連しています。 リストには、ブラウザからのプロファイルの表示と変更操作のときに読み取られないまたはキャッシュされない特定の属性が識別 されます。ネガティブ・リストに含める属性値を表示せずにプロファイル・ページを表示できます。ディレクトリ・サーバーのログには、リストに含まれていない属性のみが表示されます。
次にリストの例を示します。
<ValList
xmlns="http://www.oblix.com"
ListName="negativeListForEntityAttributes">
<ValListMember
Value="oblocationtitle"></ValListMember>
<ValListMember
Value="obdescription"></ValListMember>
</ValList>
評価で使用される属性をネガティブ・リストに含めないことをお薦めします。こうした属性がリストに含まれる場合、正しくない構成の結果、評価に失敗する可能性があります。たとえば、次の属性を含めないでください。
obgroupsubscriptiontype
obgroupdynamicfilter
objectclass
obgrouptype
その他類似の属性（これは完全なリストではありません）
READ LDAP操作のときに、negativeListForEntityAttributesパラメータを使用して一部のエントリ（ネガティブ・リストの属性を除く）が取得され、DBAgentキャッシュにキャッシュされます。ただし、これはブラウザベース・リクエストにのみ適用されます。
|
注意: ブラウザを使用する場合、ユーザー・マネージャ、グループ・マネージャおよび組織マネージャによるプロファイルの表示操作や変更操作のとき、ディレクトリ・サーバーからネガティブ・リストの属性の読取りは行いません。ただし、IdentityXMLは、ネガティブ・リストに含まれている属性も含め、すべての属性の値の読取りとキャッシュを行います。 |
IdentityXMLからのリクエストの場合、リクエストの一部として行われるすべてのREAD LDAP操作ではネガティブ・リスト内の属性は無視され、「ALL」属性の値が読み取られ、DBAgentキャッシュに格納されます。
デフォルトでは、リストはありません。つまり、どの属性も排除されません。不要な属性を排除するには、明示的にリストを作成する必要があります。このリストをglobalparams.xmlファイルの末尾に追加できます。
パネルの表示と変更操作から属性を排除するためにネガティブ・リストを作成する手順
次のパスから、globalparams.xmlファイルを探します。
IdentityServer_install_dir/identity/oblix/apps/common/bin/globalparams.xml
エディタでファイルを開いて、ファイルの末尾に排除する属性のリストを追加します。次に例を示します。
<ValList
xmlns="http://www.oblix.com"
ListName="negativeListForEntityAttributes">
<ValListMember
Value="oblocationtitle"></ValListMember>
<ValListMember
Value="obdescription"></ValListMember>
</ValList>
ファイルを保存します。
アイデンティティ・サーバーを再起動します。
ネットワーク全体のパフォーマンスやネットワーク待機時間は、システム・パフォーマンスを左右する主要な要因です。ネットワーク待機時間を減らした場合、Oracle Access Managerのパフォーマンスが向上します。
その他のアプリケーションのデプロイ用にロード・バランサを使用している場合でも、Oracle Access Managerのコンポーネント間でロード・バランサのデプロイを行う必要はありません。むしろ、行うべきではありません。アクセス・サーバーまたはアイデンティティ・サーバーと次に示すコンポーネントの間にロード・バランサを配置しないでください。
WebGatesまたはアクセスゲート
WebPass
ディレクトリ・サーバー
Oracle Access Managerは、LDAPプロトコルを使用して更新操作を行います。また、LDAPとネットワークの停止、レプリケーション、およびそれに関連する操作を行う際に、キープ・アライブ機能とフェイルオーバー機能を提供します。Oracle Access Managerの組込み機能には、多くの場合、ロード・バランサによって提供される同様の機能と同等かそれ以上の性能があります。
Oracle Access Managerのコンポーネント間にロード・バランサを配置した場合、パフォーマンスが低下することがあります。たとえば、ロード・バランサが接続をアイドル状態だと判断してその接続を終了する場合があります。その際、Oracle Access Managerに対するレスポンスはトリガーされません（Oracle Access Managerは、このレスポンスを検出して対応を行います）。この場合、システムが停止する可能性があります。
ネットワークのチューニングを行う場合のガイドラインを次に示します。
SSLアクセラレータかロード・バランサをOracle Access Managerシステムの外部に追加することにより、ネットワークのパフォーマンスを改善することができます。
Oracle Access ManagerなどのWebベース・アプリケーションのパフォーマンスと可用性を改善する場合、Webサーバーやアプリケーション・サーバーの前方にロード・バランサを配置するのが最善の方法です。ただし、Oracle Access Managerのコンポーネント間にロード・バランサを配置することはお薦めしません。
WebGateの構成ページから（または、10.1.4以前のバージョンのOracle Access ManagerのWebGateStatic.lstファイル内で）、DenyOnNotProtectedフラグの値をtrueに設定します。
これにより、アクセス・サーバーとディレクトリ間のやり取りを減らすことができます。DenyOnNotProtectedフラグによりWebGate自身のキャッシュが確認され、URLが保護されているかどうかが判断されます。
ネットワーク上でトラフィック量の多いデバイス間の待機時間を減らします。
アイデンティティ・サーバーとアクセス・サーバーは、ディレクトリよりもクライアント・アプリケーションのほうに近づけて配置できます。通常の操作の場合、アクセス・サーバーとディレクトリ間よりも、WebGatesとアクセス・サーバー間のほうがトラフィック量は多くなります。同様に、アイデンティティ・サーバーとディレクトリ間よりも、WebPassインスタンスとアイデンティティ・サーバー間のほうがトラフィック量は多くなります。これらのサーバーの場合、起動時にディレクトリとの相互作用が最も大きくなります。起動後は、これらのサーバーに必要な構成情報は、それぞれのサーバーのキャッシュから読み取ることができます。ただし、管理者がワークフローの定義とテストのためにシステム構成を行っている場合は例外です。この場合、アクセス・サーバーとアイデンティティ・サーバーをホスティング・サイトに配置すると、管理者に対するレスポンス時間を短縮できます。
リソースに負荷が集中する操作には、ログイン・フォーム、パスワード管理、プラグインなどがあります。
パフォーマンスを最適化するために調べる必要がある問題は、次のとおりです。
パフォーマンス・チューニングに利用するために、外部コンポーネントへのコールの処理にかかる時間を記録できます。たとえば、どのアイデンティティ・サーバーが最も多くのWebPassインスタンスからの最も多くのリクエストを処理しているかを調べるとします。
情報ログを使用して、より高い負荷を処理しているコンポーネントや、リクエスト処理に特に時間のかかっているコンポーネントを特定できます。詳細は、『Oracle Access Manager IDおよび共通管理ガイド』のロギングに関する章を参照してください。
ログイン・フォームは、Webサーバー全体の負荷を増大させます。サーバーのサイズとフォームの内容によっては、追加のWebサーバーが必要になる場合があります。フォームの内容が動的なものや図形などの場合、パフォーマンスが低下します。ログインの数が多すぎる場合は、ネットワーク待機時間が発生することがあります。
Oracle Access Managerプラグインと.exeファイルは、パフォーマンスに影響することがあります。Oracle Access Manager用のカスタマイズを開発する場合、カスタマイズによって発生する影響に注意してください。
次の手順に従って、パフォーマンスへの影響を最小限に抑えます。
アクションによってオーバーヘッドが発生するため、アイデンティティ・イベントAPI用のアクションを作成する場合、アクションに追加できるすべてのイベントを特定し、その中からパフォーマンスに与える影響が小さいと思われる最も使用頻度の少ないアクションを選択してください。
アクションの実行順序を検討します。
たとえば、ユーザーが特定のアクションを実行した場合に、SMTPサーバー経由で電子メール・メッセージを送信する.exeファイルを開発するとします。このプログラムの内容によっては、SMTPサーバーからリプライを受信するまで、アイデンティティ・サーバーは他のアクションを実行できなくなる可能性があります。SMTPサーバーが停止した場合、パフォーマンスに重大な影響が出る可能性があります。
EXEとLIBを比較する場合、LIBアクションはCまたはC++のソース・コードからコンパイルされたバイナリ・コード・モジュールであるため、LIBアクションのほうが実行速度は速いということに注意してください。ただし、実行する機能によって実行速度は異なります。
EXECタイプのプラグインは、外部プロセスを発生させるため使用しないでください。
たとえば、IdentityXMLを使用してアイデンティティ・イベントAPIプラグインでアイデンティティ・サーバー内のその他のイベントをトリガーさせる場合は、システムの負荷を分散させるために、イベントAPIプラグインをトリガーするアイデンティティ・サーバー・インスタンス以外のアイデンティティ・サーバー・インスタンスにリクエストが送られるようにしてください。また、パフォーマンスと安定性のために、CまたはC++を使用するアイデンティティ・イベント・プラグインを共有オブジェクト（.soファイル）とみなしてください。
すべてのアイデンティティ・イベント・プラグインがスレッド・セーフであることを確認してください。
アイデンティティ・イベントAPIプラグインは永続性がないため、プラグイン関数で使用されるすべてのグローバル変数およびローカル変数を初期化する必要があります。
複数のイベント・プラグイン関数に単一のライブラリを使用して、実行時のイメージ・サイズを最小限に抑えてください。
要件が変更された場合に操作を変更して適応させるために、構成ファイルの使用がプラグインでサポートされていることを確認してください。
プラグインの開発およびOracle Access Manager APIの使用に関する詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
