| Oracle Access Managerデプロイメント・ガイド 10g（10.1.4.3） B55479-01 |
|
 戻る |
 次へ |
クローニングとは、インストール済コンポーネントをテンプレートとして使用してリモート・システムに作成したコンポーネントのコピーのことです。キャッシュとは、最近使用した情報のコピーが保持されるメモリー内の領域のことです。この章の内容は次のとおりです。
クローニングはインストール済コンポーネントをテンプレートとしてリモート・システムに作成されたコンポーネントのコピーです。 これは、Oracle Access ManagerのコンポーネントをインストールするためにコマンドラインやインストールGUIを使用するかわりにすでにインストールされているコンポーネントの構成をクローニングすることによって実現できます。 クローニングを実行すると、インストール済コンポーネントをテンプレートとしてリモート・システムにコンポーネントのコピーが作成されます。
同期化を実行すると、2つの同じインストール済Oracle Access Managerコンポーネントの一方がもう一方よりも新しい場合、これらの2つのコンポーネントを一致させることができます。 同期化を使用して、同様のプラットフォーム上のインストールをアップグレードまたは修正することができます。
クローニングと同期化の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
Oracle Access Managerでは、頻繁に使用される情報はキャッシュから取り出され、ディレクトリ・サーバの情報はアクセスされません。 キャッシングにより、情報をすばやく取り出すことができます。 Oracle Access Managerは、パフォーマンスを向上させるために異なるタイプの情報に対して複数のキャッシュを使用します。
Oracle Access Managerシステム（OSD）は、構成の設定とグループ情報をキャッシュします。 「アイデンティティ・システム・キャッシュとキャッシュのフラッシュについて」で説明されているように、アイデンティティ・システムとアクセス・システムには異なるキャッシュが用意されています。
ここでは、次の内容について説明します。
キャッシュ内の要素数とキャッシュ・タイムアウトなど数多くの要因により、キャッシングはOracle Access Managerのパフォーマンスに影響を与えます。
キャッシュ内の最適な要素数は、次に示す2つの数値間のバランスによって決定されます。
キャッシュ内に必要な要素の数。 これは、キャッシュされる情報の内容とシステムの使用状況によって異なります。
キャッシングに使用できるRAM
キャッシュ内の要素数が増えるに従って、要求された情報が見つかる確率とパフォーマンスが向上する確率が高くなります。
キャッシュによるメモリー使用量が多く、コンポーネントを実行しているコンピュータのRAMが不十分な場合、オペレーティング・システムがページをメモリーからスワップする場合に時間がかかることがあります。 これにより、パフォーマンスが低下します。
最適なパフォーマンスのための最小キャッシュ・サイズは次のようになります。
N = XR
この代数の意味は次のとおりです。
N: キャッシュ内のエントリ数。 X: 1秒当たりの新規セッション数。 R: 秒単位の平均セッション長。 次に例を示します。
Oracle Access Managerコンポーネントのデフォルト・キャッシュ・サイズは、ほとんどのインストールに対して十分な値が設定されています。
キャッシュ・タイムアウトも、キャッシュ・フラッシュ操作のパフォーマンスに影響します。
キャッシュ・タイムアウトは、要素をキャッシュに保持する期間を指定します。期限が切れると要素はキャッシュから削除されるため、ディレクトリから取り出す必要があります。
情報が変更されているのにキャッシュは変更されていない場合、期限切れになった情報がキャッシュから削除されるまで、Oracle Access Managerのコンポーネントはこの古い情報を使用します。 この問題を避けるための1つの方法として、情報を変更した場合にキャッシュを更新する方法があります。 ユーザーの情報が他のソフトウェアを使用して変更された場合など、キャッシュを更新できない場合は、別の解決策としてキャッシュに適切なタイムアウトを設定する方法があります。
短いタイムアウトを設定すると、ユーザーに関する情報はより新しいものになりますが、アイデンティティ・サーバーとアクセス・サーバーがディレクトリからデータをフェッチする頻度を上げる必要があります。 これにより、パフォーマンスが低下することがあります。 長いタイムアウトを設定した場合、古い情報がより長期間キャッシュ内に残ることになります。
|
注意: 一般的に、キャッシュ・タイムアウト値を低く設定すると、キャッシュ内のデータはより新しくなります。 ただし、キャッシュ・タイムアウト値を0に設定すると、そのキャッシュは期限切れになりません。 |
表5-1は、アイデンティティ・システムのために指定できるキャッシュ・タイムアウトを示しています。
表5-1 アイデンティティ・システムのためのキャッシュのタイムアウト・パラメータ
| アイデンティティ・システムのタイムアウト・パラメータ | 説明 |
|---|---|
|
GroupCacheTimeout |
「グループ・オブジェクト・キャッシュの管理」で説明されているように、グループ・オブジェクトの有効時間を設定します。 |
|
oisClientTimeoutThreshold |
「アイデンティティ・サーバーのためのキャッシュ・フラッシュの構成」で説明されているように、アイデンティティ・サーバーのキャッシュ・フラッシュのための期間を設定します。 |
表5-2は、アクセス・システムのために指定できるキャッシュ・タイムアウトを示しています。
表5-2 アクセス・システムのためのキャッシュのタイムアウト・パラメータ
| アクセス・システムのタイムアウト・パラメータ | 説明 |
|---|---|
|
Time To Live |
「アクセス・サーバーによるパスワード検証の構成」で説明されているように、キャッシュされたパスワードのタイムアウトをスキーマごとに設定するために使用します。 |
|
Group Query Cache timeout |
以前は、このタイムアウトは構成不可だったため、このキャッシュはフラッシュできませんでした。 このキャッシュは、キャッシュ・タイムアウトの限界に達したときか、アクセス・サーバーを再起動したときのみ消去されました。 現在は、「アクセス・サーバーのグループ・キャッシュ・タイムアウトおよび最大要素数の構成」で説明されているように、構成が可能です。 |
|
Policy Cache Timeout |
ポリシー・キャッシュのタイムアウト値:
|
|
User Cache Timeout |
ユーザー・キャッシュのタイムアウト値:
|
|
WebGate Cache Timeout |
WebGateキャッシュのタイムアウト値:
|
|
WebGateとAccess Clientの構成用のキャッシュ・タイムアウト |
WebGateとアクセス・サーバー間、およびアクセス・サーバーとLDAPディレクトリ・サーバー間の閑散時のネットワーク・トラフィックを削減するには、有効な方法が2つあります。
|
アイデンティティ・サーバーは、主にキャッシュ・フラッシュをリクエストする際に、互いに通信することができます。 1つのサーバーでキャッシュが更新されると、そのサーバーは他のサーバーに対してキャッシュを更新するよう通知します。
アイデンティティ・システムには複数のキャッシュがあります。 表5-3で説明されているように、データが変更された場合、各サーバーはキャッシュ・フラッシュのリクエストを受信することができます。 アイデンティティ・システムとアクセス・システムは、異なるユーザー・キャッシュとグループ・キャッシュを使用します。 表5-6の「アクセス・システム・キャッシュ」を参照してください。
表5-3 アイデンティティ・システム・キャッシュとキャッシュのフラッシュ操作
| アイデンティティ・システム・キャッシュ | 説明 | キャッシュのフラッシュ |
|---|---|---|
|
構成データ システム・データまたはOracle Access Manager固有のデータ（OSD）とも呼ばれます。 |
オブジェクト・クラス、属性、タブおよびパネルが含まれています。 |
構成データが変更されると、自動的にフラッシュされます。 または、「アイデンティティ・システム・キャッシュの管理」の説明に従って、キャッシュを消去することができます。 |
|
設定時に入力された基本構成データ |
構成ベース（構成DN）と検索ベースが含まれています。 |
基本構成データが変更されると、自動的にフラッシュされます。 |
|
グループ・オブジェクト |
グループ・マネージャで指定されたグループ詳細が含まれています。 |
グループが変更されると自動的にフラッシュされます。 または、「グループ・オブジェクト・キャッシュの管理」で説明されているように、キャッシュ・フラッシュを明示的に要求することができます。 |
|
名前キャッシュ UidInfoCacheとも呼ばれます。 |
ユーザー・オブジェクトのDNとグループ・オブジェクトのDNが含まれています。 DN自体または名前などの属性フラグが変更されたオブジェクトを取得するとフラッシュされます。 |
DNまたは属性フラグ（たとえば、名前）が変更されると、自動的にフラッシュされます。 |
|
アクセス制御キャッシュ |
リソース操作、検索ベース、類似するキャッシュが含まれています。 |
ACLまたは検索ベースが変更されると、自動的にフラッシュされます。 |
|
監査キャッシュ |
マスター監査ポリシー、メッセージ形式などの情報が含まれています。 |
マスター監査ポリシー、メッセージ形式などの情報が変更されると、自動的にフラッシュされます。 |
|
ワークフロー・キャッシュ |
ワークフロー定義と参加者が含まれています。 |
ワークフローが変更されると、自動的にフラッシュされます。 |
|
ユーザー定義ポータルの挿入 |
ポータルのbackurl挿入、ボタン用のイメージ、画面上の文字が含まれています。 |
『Oracle Access Managerカスタマイズ・ガイド』に記載されているように、URLで明示的に呼び出されます。 |
アイデンティティ・システム・キャッシュの管理の詳細は、「アイデンティティ・システム・キャッシュの管理」を参照してください。
アクセス・システムは、パスワード・ポリシー、ポリシー・ドメイン、ユーザー資格情報、認証スキームに関する情報をキャッシュします。 Oracle Access Managerで実行される一部の操作は、アクセス・システムのアクセス・ポリシー評価に影響します。 たとえば、アイデンティティ・システムでユーザーを非アクティブの状態にした場合、このユーザーはアクセス・システムによって保護されるリソースにアクセスできなくなるため、この変更をアクセス・システムに対しても反映させる必要があります。 詳細は、「アクセス・システム・キャッシュについて」を参照してください。
Oracle Access Managerは、Oracle Access Managerアプリケーションで使用されるオブジェクト・クラス、属性、パネル、タブなど、特定のデータの構成情報をキャッシュします。 この情報は、起動時に自動的にキャッシュされます。
この項で説明する内容は次のとおりです。
OSDキャッシュの表示、リロード、消去を行う場合、マスター管理者である必要があります。 次の項では、システム・キャッシュの管理に関する詳細を説明します。
OSDキャッシュの表示を行う場合、マスター管理者である必要があります。
アイデンティティ・システム・コンソールを起動します。
「システム構成」タブをクリックし、「サーバー設定の表示」を選択します。
「サーバー設定の表示」ページの「キャッシュ」をクリックします。
「キャッシュ」ページの「キャッシュ内容の表示」をクリックします。
キャッシュされたOSD情報が表示されます。
OSDキャッシュを消去する手順は次のとおりです。 既存の情報を更新するには、最初にキャッシュを消去してから情報をリロードする必要があります。 OSDキャッシュの消去を行う場合、マスター管理者である必要があります。
OSDキャッシュを消去する手順
アイデンティティ・システム・コンソールを起動します。
「システム構成」タブをクリックし、「サーバー設定の表示」を選択します。
「サーバー設定の表示」ページの「キャッシュ」をクリックします。
「キャッシュ」ページの「メモリー・キャッシュの消去」をクリックします。
キャッシュが消去されます。
この項の内容は次のとおりです。
アイデンティティ・システムには、すべてのグループ関数、特に親（isMemberOf）グループ、子グループ、ネストされたグループの計算に関係する関数のパフォーマンスを高めるため、グループ・オブジェクト用のキャッシュが用意されています。
グループは、Oracle Access Managerがそのグループの最初のリクエストを作成したときのみキャッシュされます。 それ以降は、グループのリクエストがキャッシュにダイレクトされます。 グループを変更すると、このグループは親グループ、子グループ、またはネストされたグループと一緒にキャッシュから削除（フラッシュ）されます。
複数サーバー構成の場合、1つのアイデンティティ・サーバー上でグループが変更されると、他のすべてのアイデンティティ・サーバーは通知を受信し、変更されたグループとそのグループに依存するすべてのグループをキャッシュから削除します。 変更されたグループに対する別のリクエストをOracle Access Managerが受信すると、キャッシュ内にこのグループがリストアされます。 これにより、キャッシュにはこのグループの最新情報が保持されます。
グループを検索する場合、Oracle Access Managerはキャッシュではなくディレクトリを検索します。
グループ・キャッシュの管理には、groupdbparams.xml構成ファイルを使用します。
次の場所にあるファイルgroupdbparams.xmlに移動します。
IdentityServer_install_dir \identity\oblix\data\common
このIdentityServer_install_dirは、アイデンティティ・サーバーがインストールされているディレクトリです。
表5-4の説明に従って、キャッシュに関連する関数を制御するgroupdbparams.xmlファイルのパラメータ値を構成します。
表5-4 groupdbparams.xmlのパラメータ
| パラメータ | 説明 |
|---|---|
|
GroupCacheTimeout |
オブジェクトの有効時間（秒）。 デフォルトでは、グループ・キャッシュはタイムアウトしません。 デフォルト値は0です。 |
|
GroupCacheMax NumElements |
キャッシュ内に保存できるグループ・オブジェクトの最大数。 デフォルト値は10000です。キャッシュが最大サイズに達している場合、アクセスの少ないオブジェクトはアクセスの多いオブジェクトと置き換えられます。 このパラメータの値を設定する場合、システム・メモリーの制限事項を考慮してください。 |
|
GroupCacheDisabled |
キャッシュが使用できるかどうかを指定します。 デフォルト値はfalseです。 値がfalseの場合、キャッシュは使用できます。 値がtrueの場合、キャッシュは使用できません。 キャッシュが無効になっている場合、グループ・オブジェクトはすべてディレクトリから読み取られます。 |
|
GroupCacheRead FromMaster |
グループの読取りを強制的に行い、レプリケートされた環境のマスター・レプリカからのキャッシュによる読取りを可能にします。 これにより、コンシューマ・レプリカがマスター・レプリカから更新情報を受信する前にコンシューマ・レプリカからの読取りが発生した場合、キャッシュ内に古い情報が残らなくなります。 デフォルト値はfalseです。 値がtrueの場合、キャッシュはマスター・レプリカからの読取りを行います。 |
場合によっては、キャッシュからグループを削除してキャッシュの一貫性を維持することが必要になることがあります。 たとえば、キャッシュがグループの読取りリクエストを受信した際に、確実に更新されたグループが読み取られるようにする場合、Oracle Access Manager以外のアプリケーションを使用して変更されたグループを削除する必要が生じることがあります。
後述の手順に従い、マスターID管理者は、アイデンティティ・システム・コンソールを使用して、グループ・キャッシュ全体を消去できます。 もしくは、マスターID管理者は、flushGroupCacheという名前のIdentity XML関数を使用して、グループ・キャッシュを消去できます。 この方法の詳細は、『Oracle Access Manager開発者ガイド』のIdentityXMLに関する章を参照してください。
アイデンティティ・システム・コンソールからグループ・キャッシュを消去する手順
アイデンティティ・システム・コンソールから「グループ・マネージャ構成」タブをクリックします。
「グループ・マネージャ構成」ページの「グループ・キャッシュ」をクリックします。
「グループ・キャッシュ」ページの「グループ・キャッシュの消去」リンクをクリックします。
グループ・キャッシュが消去され、操作が成功したかどうかを示すメッセージが表示されます。
アイデンティティ・サーバーのキャッシュ・フラッシュは、globalparams.xmlファイルのoisClientTimeoutThresholdパラメータを使用することによって実現できます。 デフォルトでは、アイデンティティ・サーバーのキャッシュ・フラッシュは同期キャッシュ・フラッシュであり、60秒ごとに実行されます。 ただし、表5-5に示すように、アイデンティティ・サーバー・キャッシュを非同期的にフラッシュするように設定できます。
表5-5 globalparams.xmlのoisClientTimeoutThreshold値
| 値 | 説明 |
|---|---|
|
60 |
デフォルトでは、アイデンティティ・サーバーのキャッシュ・フラッシュは同期で60秒ごとに実行 |
|
-1 |
アイデンティティ・サーバーの非同期キャッシュ・フラッシュを実行 |
|
値なし |
アイデンティティ・サーバーの非同期キャッシュ・フラッシュを実行 |
|
パラメータなし |
アイデンティティ・サーバーの非同期キャッシュ・フラッシュを実行 |
同期モードでは、アイデンティティ・サーバーはキャッシュ・フラッシュのリクエストを送信し、応答を待ちます。 非同期モードでは、アイデンティティ・サーバーは応答を待ちません。
アイデンティティ・サーバーのキャッシュ・フラッシュを構成する手順
次のファイルを探します。
IdentityServer_install_dir/identity/oblix/apps/common/bin/globalparams.xml
表5-5のガイドラインに基づき、oisClientTimeoutThresholdパラメータを設定します。
ファイルを保存します。
各アイデンティティ・サーバーに対して、これらの手順を繰り返し実行します。
デプロイメントでアクセス・システムが含まれていない場合、この項をスキップできます。
アクセス・システムは、パスワード・ポリシー、ポリシー・ドメイン、ユーザー資格情報、認証スキームに関する情報をキャッシュします。 図5-1に、アクセス・システムにおけるキャッシングの仕組みを示します。 これは必ずしもデプロイメントの推奨事項ではありません。
次の項目では、アクセス・システム・キャッシュの詳細を説明します。
キャッシュ内の最大要素数を指定できます。 アクセス・システムにより、キャッシュ内の合計要素数がキャッシュに指定された最大数を超えないように制御されます。
たとえば、最大100,000の要素を格納するようにアクセス・サーバーのユーザー・キャッシュを設定したとします。 キャッシュが一杯になったときにユーザーがシステムに追加された場合、アクセス・システムは最も長期間使用されていないユーザーの要素を削除し、新しいユーザーに関する情報をキャッシュに追加します。
表5-6に示すように、アクセス・システムは、ポリシー・ドメイン、ポリシー、ユーザー、ホスト識別子、パスワード・ポリシーに関するデータをキャッシュします。 これらのいずれかの情報が更新され、「キャッシュの更新」ボックスが選択されている場合、アクセス・サーバーのキャッシュはただちに更新されます。
表5-6 アクセス・システム・キャッシュとキャッシュのフラッシュ操作
| アクセス・システム・キャッシュ | 説明 | キャッシュのフラッシュ |
|---|---|---|
|
アクセス・サーバーのキャッシュ |
||
|
ポリシー・キャッシュ |
ポリシー・ドメイン、ポリシー、認証ルール、認可ルール、監査ルール、ルールに関連するアクション、ルールに対するポリシー条件、認証スキームのための情報が含まれています。 詳細は、「ポリシー・キャッシュのチューニング」を参照してください。 |
任意のポリシー構成が変更され、「キャッシュの更新」が選択されると、自動的にキャッシュがフラッシュされます。 |
|
アクセス・サーバーのユーザー・データ・キャッシュ |
アクションおよびルールベースのアクセス評価の両方で必要となるユーザー・プロファイルの情報が含まれています。また、このキャッシュにユーザーのグループ・メンバーシップ・ステータス（たとえば、ユーザーがグループのメンバーであるかどうかなどの情報）も含まれています。 詳細は、「ユーザー・キャッシュのチューニング」を参照してください。 |
OISがAAAに通知される場合 |
|
URL接頭辞キャッシュ |
URL接頭辞がポリシー・ドメインやポリシーに追加され、「キャッシュの更新」が選択されていると、更新されます。 詳細は、「URL接頭辞キャッシュのチューニング」を参照してください。 |
「キャッシュの更新」が選択されていると、自動的にキャッシュがフラッシュされます。 |
|
ホスト識別子キャッシュ |
ホスト識別子が含まれています。 |
「キャッシュの更新」が選択されていると、自動的にキャッシュがフラッシュされます。 |
|
パスワード・ポリシー・キャッシュ |
パスワード・ポリシーが含まれています。 |
「キャッシュの更新」が選択されていると、自動的にキャッシュがフラッシュされます。 |
|
WebGateキャッシュ |
ユーザーの資格情報を検証する方法およびスキームのレベルのような認証スキームに関する詳細情報が含まれています。 リダイレクションURL（存在する場合） アクセス・ゲートに渡されるすべてのリソース（認証スキーム、URL、操作など）に関する保護情報。次のような情報が含まれます。
認可スキームに関する詳細情報。次のような情報が含まれます。
|
キャッシュ・フラッシュは、WebGateキャッシュのタイムアウトに対して設定した値によって異なります。 詳細は、「アクセス・ゲート・キャッシュ構成」を参照してください。 |
この項で説明する追加情報は次のとおりです。
アクセス・サーバーのポリシー・キャッシュには、ポリシー・ドメイン、ポリシー、認証、認可、監査ルール、アクションに関する情報が格納されます。
アクセス・サーバーは、実行時に効率的な検索を行うためにポリシー情報をキャッシュします。 ポリシー情報がキャッシュにない場合、アクセス・サーバーは情報をディレクトリから取得する必要があります。 データをディレクトリから取得する場合はアクセス・ゲートがアクセス・サーバーから情報を取得する場合よりも時間がかかるため、すべてのポリシー情報がキャッシュされているほうが効率的です。
キャッシュ・タイムアウト: ポリシー・マネージャやアクセス・システム・コンソールを使用してポリシー情報が変更された場合、「キャッシュの更新」を選択することによってアクセス・サーバーのキャッシュを即座に更新できます。 キャッシュの更新機能を使用しない場合は、ポリシー・キャッシュ・タイムアウトが重要になります。 キャッシュ・タイムアウトには、「キャッシュの更新」を使用しない（または使用できない）場合に、どれくらいの頻度でポリシー情報の更新が必要なのかを設定してください。 デフォルトのポリシー・キャッシュ・タイムアウトは2時間です。 予期しない内部的なイベントまたは外部的なイベントが発生する場合も、指定した期間の後に変更が保存されることを確認するので、これは重要なパラメータです。
最大要素数: すべての構成済ポリシー情報を保持するのに十分なメモリーがアクセス・サーバーのホストに設定されている場合、次のうち最も高い値に従って最大要素数を設定してください。
ポリシー・ドメインの合計数
デフォルトまたはそれ以外の認証ルールの合計数
デフォルトまたはそれ以外の認可ルールの合計数
デフォルトまたはそれ以外の監査ルールの合計数
この構成は、一般的なデプロイメントの場合に機能します。
アクセス・サーバーのユーザー・キャッシュには次に示すものに関する情報が含まれています。
ユーザー・プロファイル。アクションおよびルールベースのアクセス評価の両方で必要です。
ユーザーのグループ・メンバーシップ・ステータス。ユーザーがグループのメンバーであるかどうかなどの情報です。
アクセス・サーバーは、ユーザーのプロファイル情報とグループのメンバーシップ情報をキャッシュします。 プロファイル情報には、アクションに必要な情報と認可に必要な情報が両方とも含まれています。 たとえば、ポリシーの認可ルールでuserLevel属性が3より大きく設定されているユーザーへのアクセスを許可する場合、アクセス・サーバーのキャッシュにはuserLevel属性が格納されます。
同じように、アクセス・サーバーはユーザーがグループのメンバーであるかどうかに関する情報をキャッシュします。
ユーザーとグループの情報は、アイデンティティ・サーバーや他のアプリケーションを使用して更新できます。 ユーザーとグループの情報が変更されると、Oracle Access Managerのキャッシュは最新情報ではなくなります。 このため、ユーザー・キャッシュのタイムアウトが重要になります。
ユーザー・キャッシュのタイムアウトは、アクセス・システムに関連する部分のユーザー・プロファイルが変更される平均間隔に比例させてください。 アクセス・システムに関連する部分のユーザー・プロファイルは次のとおりです。
アクションでアクセス・ゲートに返される属性
アクセス制御に使用される属性
アクセス制御に使用される可能性がある動的グループ・メンバーシップの定義に使用される属性
要素の最大数は、アクセス・サーバーのユーザー・キャッシュ・タイムアウト時間内にシステムにアクセスする可能性のあるユーザー数と等しくする必要があります。
ユーザーまたはグループの情報が変更された場合に、アイデンティティ・サーバーを構成してアクセス・サーバーに自動的に通知することができます。 アクセス・サーバーのキャッシュは自動的にフラッシュされ、新しい情報によって更新されます。 ユーザーの情報が変更された場合、アイデンティティ・サーバーを構成してアクセス・サーバーに通知するには、アイデンティティ・サーバーのIdentityServer_install_dir/identity/oblix/data/commonにあるbasedbparams.xmlファイルにdoAccessServerFlushパラメータを設定できます。 現在、これは、グループ情報ではなくユーザー情報に対してのみサポートされています。 詳細は、『Oracle Access Managerカスタマイズ・ガイド』のパラメータに関する章を参照してください。
ポリシー・マネージャを使用してデータを変更すると、ディレクトリのデータが変更され、キャッシュをフラッシュするようアクセス・サーバーに通知されます。 アクセス・サーバーはそのキャッシュをフラッシュし、更新された情報をディレクトリ・サーバーから読み取ります。
レプリケートされたディレクトリ環境では、変更データがマスター・ディレクトリ・サーバーからレプリケートされたディレクトリ・サーバーに渡されます。 レプリケートされたディレクトリ・サーバーに変更データが反映されるまで、タイム・ラグが発生します。 ポリシー・マネージャがマスター・ディレクトリ・サーバーと通信し、レプリケートされたディレクトリ・サーバーとアクセス・サーバーが通信する場合、アクセス・サーバーはそのキャッシュをフラッシュし、レプリケートされたサーバーに変更データが反映される前にデータを読み取ることがあります。 したがって、アクセス・サーバーによって古いデータがキャッシュされる可能性があります。 このため、レプリケートされた環境では、古いデータに基づいたアクセス・サーバーによるポリシー評価は不正確なものになることがあります。 図5-2に、レプリケートされた環境を示します。
プロセスの概要: レプリケーション
アクセス管理者は、ポリシー・マネージャを使用してマスター・ディレクトリ・サーバーのデータを変更します。
ポリシー・マネージャからアクセス・サーバーに対して、キャッシュをフラッシュする信号が送信されます。
アクセス・サーバーはキャッシュをフラッシュし、レプリケートされたディレクトリ・サーバーからデータを読み取ります。
変更データが、マスター・ディレクトリ・サーバーからレプリケートされたディレクトリ・サーバーにレプリケートされます。
ポリシー評価を正確なものにし、アクセス・サーバーが確実に最新データを読み取るようにするには、splTimeoutパラメータを追加します。 このパラメータを使用すると、変更中の要素に対してタイムアウト（秒）を指定できます。 この場合、マスター・ディレクトリ・サーバーとレプリケートされたディレクトリ・サーバー間のレプリケーションで発生するタイム・ラグは許容されます。 splTimeoutパラメータは、アクセス・システム・コンソールの「アクセス・サーバー構成」ページに指定したキャッシュ・タイムアウトよりも優先されます。
splTimeoutパラメータに値を指定しなかった場合、アクセス・サーバーはポリシー・マネージャからフラッシュ信号を受信すると同時にキャッシュをフラッシュしてデータを読み取ります。
splTimeoutパラメータが次のディレクトリにあるglobalparams.xmlファイルに格納されています。
AccessServer_install_dir/access/oblix/apps/common/bin/globalparams.xml
このAccessServer_install_dirは、アクセス・サーバーがインストールされているディレクトリです。
レプリケートされた環境でポリシー評価を正確なものにする方法
プライマリ・アクセス・サーバーをホストするコンピュータで、globalparams.xmlファイルを探します。 次に例を示します。
AccessServer_install_dir/access/oblix/apps/common/bin/globalparams.xml
ファイルを開いてsplTimeoutパラメータを追加します。 次に例を示します。
<SimpleList>
<NameValPair
ParamName="splTimeout"
Value="400"></NameValPair>
</SimpleList>
ファイルを保存します。
アクセス・サーバーを再起動します。
デプロイメントでアクセス・サーバーごとにこの手順を繰り返します。
アクセス・ゲートを構成する場合、キャッシュ・タイムアウトの他に、キャッシュ内の最大要素数も指定できます。
各アクセス・ゲートは次の情報をキャッシュします。
認証スキームに関する詳細情報。次のような情報が含まれます。
アクセス・ゲートに渡されるすべてのリソース（認証スキーム、URL、操作など）に関する保護情報。次のような情報が含まれます。
認証スキームのキー
保護されたリソースのURL
リソースがシステムで保護されているかどうかの情報
リソースが保護されている場合、そのリソースに必要な認証方法
認可スキームに関する詳細情報。次のような情報が含まれます。
LDAPユーザー属性
ポリシー・ドメインの認可ルールに指定されているパラメータ
認証スキームまたは認可スキームの構成や変更を行う場合、「キャッシュの更新」を選択し、更新されたスキームによってアクセス・ゲート・キャッシュをただちに更新します。
情報がキャッシュされるURLの数は、アクセス・ゲートごとに構成できます。 すぐに使用できる構成の場合、URL要素は30秒ごとにタイムアウトします。 URLの保護ステータスや認証方法を変更する可能性があるポリシー変更を行う場合、「キャッシュの更新」を選択してアクセス・ゲート・キャッシュをただちに更新します。 つまり、アクセス・ゲートのキャッシュ・タイムアウト時間を短く設定する必要はありません。
システムに十分なメモリーがあるという前提の場合、キャッシュされるURLの最大数は、「キャッシュ・タイムアウト」フィールドに指定された時間内にアクセス・ゲートによって処理される個別のURLの数以上に設定する必要があります。
たとえば、http://www.myserver.comとhttp://myserverは個別のURLとして扱います。 URLに関する情報がキャッシュに存在しない場合、アクセス・ゲートはアクセス・サーバーに対するリクエストを作成します。 アクセス・サーバーから情報をフェッチする場合、ロケール・キャッシュから情報をフェッチするよりも時間がかかりますが、非常に長くかかるということはありません。
アクセス・サーバーとシステム・パフォーマンスは、情報をキャッシングすることによって向上します。これにより、ディレクトリ・サーバーにある各リクエストのための情報を読み取る必要がなくなります。 関連する情報が更新され、「キャッシュの更新」が有効な場合、アイデンティティ・サーバーはAccess Manager SDKを使用してプライマリ・アクセス・サーバーにキャッシュ・フラッシュのリクエストを送信します。 これを受けてプライマリ・アクセス・サーバーは、同じキャッシュ・フラッシュのリクエストをすべてのアクセス・サーバーに送信して、キャッシュから対応するエントリをフラッシュするようそれらに指示します。
ユーザー・キャッシュのフラッシュ
パスワード・ポリシーのフラッシュ
パスワード・リダイレクトURLのフラッシュ
ロスト・パスワード管理ポリシーのフラッシュ
Oracle Access Managerの以前のリリースでは、アイデンティティ・サーバーからアクセス・サーバーへのキャッシュ・フラッシュのリクエストに同期モードが使用されていました。 アイデンティティ・サーバーは同期モードでプライマリ・アクセス・サーバーにキャッシュ・フラッシュのリクエストを送信し、応答があるまで処理しません。
|
注意: ポリシー・マネージャからキャッシュ・フラッシュのリクエストがアクセス・サーバーに送信されるときも同様の状況が発生します。 たとえば、ポリシー・マネージャ内でポリシーが有効や無効になっている場合、アクセス・サーバーへのキャッシュ・フラッシュのリクエストが生成されます。 |
ただし、システム内の遅延によってユーザーに遅れが発生します。 設定したOISTimeoutThreshold内にレスポンスがなかった場合、WebPassからアイデンティティ・サーバーに対してリクエストが再送され、キャッシュ・フラッシュの新規サイクルが起動します。 WebPassからアイデンティティ・サーバーに対して同様なリクエストの再送が続くと、エンドユーザーに対してレスポンスなしの状況が発生する恐れがあります。
Oracle Access Manager 10g（10.1.4.3）では、パフォーマンスを効率化できる非同期キャッシュ・フラッシュのオプションが提供され、アクセス・システムで同期キャッシュ・フラッシュ操作に関連する遅延を回避します。 非同期式方式でも同期式方式でも、情報の流れは同じです。 ただし、非同期式方式では、スレッドはアクセス・サーバーからのレスポンスを待たずに、アイデンティティ・サーバーに通知します。 その代わり、リクエストはアクセス・サーバーに到着し、レスポンスは即座にアイデンティティ・サーバーに送信されます。
アクセス・システム・コンソールのアクセス・ゲート構成でsyncOperationModeの値を設定することによって、同期式または非同期式キャッシュ・フラッシュ方式を使用できます。 非同期式キャッシュ・フラッシュ方式を使用する方法は、「非同期アクセス・システム・キャッシュ・フラッシュの構成」を参照してください。
次に説明されているように、Oracle Access Managerコンポーネント間の通信のために混合セキュリティ・モードを使用して、アクセス・システム・キャッシュのフラッシュの実行中にパフォーマンスを改善することができます。
この項の内容は次のとおりです。
Oracle Access Managerをインストールして構成する場合、特定のトランスポート・セキュリティのガイドラインを参照する必要があります。 『Oracle Access Managerインストレーション・ガイド』のインストールの準備に関する章にあるトランスポート・セキュリティのガイドラインには、次の項目が記載されています。
すべてのアイデンティティ・システム・コンポーネント（アイデンティティ・サーバーおよびWebPassインスタンス）の間のトランスポート・セキュリティが一致している必要があります（すべてがオープン・モード、簡易モードまたは証明書モード）。
すべてのアクセス・システム・コンポーネント（ポリシー・マネージャ、アクセス・サーバーおよび関連するWebGate）の間のトランスポート・セキュリティが一致している必要があります（すべてがオープン・モード、簡易モードまたは証明書モード）。
キャッシュ・フラッシュが有効な場合、アイデンティティ・サーバーはアクセス・サーバーと通信します。 この場合、すべてのOracle Access Managerコンポーネントの間のトランスポート・セキュリティ・モードは同じである必要があります。
Oracle Access Manager 10g（10.1.4.2.0）では、アイデンティティ・サーバーとアクセス・サーバー間のキャッシュ・フラッシュのリクエストに対してにオープン・モードの通信を有効にし、他のリクエストには簡易モードまたは証明書モードを維持する方法が提供されています。 このタイプの構成は混合セキュリティ・モード（または、混合トランスポート・セキュリティ・モード）通信と呼ばれます。
Oracle Access Manager 10g（10.1.4.3）では、キャッシュ・フラッシュのリクエストのために混合方式通信を実装する効率的な方法が用意されています。
|
注意: キャッシュ・フラッシュのリクエストには、機密データは含まれません。 キャッシュ・フラッシュの実行中に、LDAP構成だけが読み取られます。 そのため、キャッシュ・フラッシュのリクエストにはオープン・モード通信が適しています。 混合セキュリティ・モードの通信では、キャッシュ・フラッシュのリクエスト以外のすべてのリクエストは、セキュアな通信のために簡易モードまたは証明書モードを使用します。 |
ユーザーまたはグループを変更すると、ユーザーまたはグループDNがキャッシュ・フラッシュのリクエストで送信されます。 ポリシーの変更に対して、キャッシュ・フラッシュのリクエストにはポリシー識別子が含まれます。
混合方式通信の構成に関する詳細は、「アクセス・サーバー・キャッシュのフラッシュ操作のための混合方式通信の構成によるパフォーマンスの向上」を参照してください。
アイデンティティ・サーバーをインストールして構成すると、Access Manager SDKは自動的にデプロイされます。 Access Manager SDKは、Identity XML を使用してユーザー・プロファイルおよびグループ・プロファイルが変更されると、アクセス・サーバーにキャッシュ・フラッシュのリクエストを送信する役割を担います。 この場合、XMLリクエストはWebPassを使用してアイデンティティ・サーバーに送信されます。 アクセス・サーバーのキャッシュ・フラッシュが有効な場合、アイデンティティ・サーバーによってリクエストが処理されると、アイデンティティ・サーバーはAccess Manager SDKを使用してキャッシュ・フラッシュのリクエストをアクセス・サーバーに送信し、キャッシュがフラッシュされます。
アクセス・サーバーのキャッシュ・フラッシュを有効にするには、IdentityServer_install_dir/identity/ oblix/data/common/basedbparams.xmlファイルにあるdoAccessServerFlushパラメータの値をtrueに設定する必要があります。 これにより、Access Manager SDKはアクセス・サーバー・キャッシュをフラッシュするリクエストを送信できます。 そうすると、アクセス・サーバーのキャッシュは自動的にフラッシュされ、最新の情報によって置き換えられます。 すべてのコンポーネントに最新情報があることを確認するのが最善の方法です。 詳細は、「アクセス・サーバー・キャッシュの自動フラッシュ」を参照してください。
ただし、キャッシュの自動フラッシュは最善の方法ですが、セキュアな通信モードを使用する複数のアクセス・サーバーがある場合は、パフォーマンスに関する問題が発生します。 次に示す状況では、パフォーマンス上の問題が発生する可能性があります。
アイデンティティ・システムがIdentityXMLを使用してユーザーまたはグループ・プロファイルを変更するとき、キャッシュ・フラッシュのリクエストが頻繁になる。
簡易または証明書のトランスポート・セキュリティ・モードで構成した各アクセス・サーバーに送信されたリクエストごとにSSLハンドシェークがある。
セキュアなマルチサーバー環境に必要なSSLハンドシェークによって、パフォーマンスが低下することがある。
最新のOracle Access Manager手順を使用すると、キャッシュの自動フラッシュとセキュアな通信を維持しながら障害を防止して、高いシステム・パフォーマンスを保つことがきます。 詳細は、「非同期アクセス・システム・キャッシュ・フラッシュの構成」を参照してください。
非同期キャッシュ・フラッシュ操作により、ユーザーおよびグループ情報に変更があるときに、アイデンティティ・システムをAccess Manager SDKを通して非同期モードでアクセス・サーバーに接続させることができます。 詳細は、「非同期アクセス・システム・キャッシュ・フラッシュの構成」を参照してください。
デプロイメントでアクセス・システムが含まれていない場合、この項をスキップできます。
この項では次の手順および情報を説明します。
アクセス・サーバーのユーザー・キャッシュをオフにする手順は次のとおりです。 このタスクの実行を行う場合、マスター・アクセス管理者である必要があります。
このキャッシュをオフにすると、メモリー使用量が減少します。 これにより、いつかのケースで効率が低下する可能性があります。 たとえば、アクセス・サーバーに対するリクエストが頻繁にあるときです。
ユーザー・キャッシュをオフにする手順
アクセス・システム・コンソールを起動します。
「アクセス・システム構成」に移動して「アクセス・サーバー構成」をクリックします。
「アクセス・サーバー構成」ページが表示されます。 このページには、構成済の各アクセス・サーバーの名前、ホストおよびポートが表示されます。
変更するアクセス・サーバーのリンクをクリックします。
「アクセス・サーバーの詳細」ページで「変更」をクリックします。
「アクセス・サーバーの変更」ページが表示されます。
「ユーザー・キャッシュ内の最大要素」の値を-1に設定します。
変更を保存します。
アイデンティティ・システムとアクセス・システムは、異なるユーザー・キャッシュとグループ・キャッシュを使用します。 管理者は、次の操作をすべて実行することができます。
ユーザーの非アクティブ化
ユーザー属性の変更
グループの削除
パスワード・ポリシーの変更
リダイレクトURLの変更
前述のいずれかの操作を実行すると、ディレクトリ・サーバーが新しい情報によって更新されます。 ただし、アクセス・サーバーがこれらの変更を認識しない可能性があります。 たとえば、Oracle Access Managerでユーザーを非アクティブの状態にした場合、このユーザーは保護されているリソースにアクセスできなくなるため、この変更をアクセス・システムに対しても反映させる必要があります。
アイデンティティ・システムの変更をアクセス・サーバーに確実に通知する場合、アクセス・サーバーのユーザー・キャッシュを手動でフラッシュすることができます。 または、ユーザーやグループの情報が変更された場合に、アイデンティティ・サーバーを構成してアクセス・サーバーにこの変更を通知することができます。 アクセス・サーバーのキャッシュは自動的にフラッシュされ、最新の情報によって置き換えられます。 アクセス・サーバーの自動キャッシュ・フラッシュのために、表5-7の説明に従ってアイデンティティ・サーバーのbasedbparams.xmlファイルにdoAccessServerFlushパラメータを設定する必要があります。
表5-7 basedbparams.xmlのdoAccessServerFlushパラメータ
| 値 | 説明 |
|---|---|
|
true |
アクセス・サーバーの自動キャッシュ・フラッシュを有効にします。 |
|
false |
アクセス・サーバーの自動キャッシュ・フラッシュを無効にします。 注意: これはデフォルト値です。 |
|
値なし |
デフォルト値はfalseとみなされます。 アクセス・サーバーの自動キャッシュ・フラッシュを無効にします。 |
|
パラメータなし |
デフォルト値はfalseとみなされます。 アクセス・サーバーの自動キャッシュ・フラッシュを無効にします。 |
|
注意: 動的フィルタや静的メンバーシップを使用してグループのメンバーシップを変更する場合、ユーザー・キャッシュの自動フラッシュは行われません。 また、ユーザーを非アクティブ化すると、資格情報マッピング・キャッシュを無効にする必要があります。 詳細は、「資格情報マッピング・キャッシュの管理」を参照してください。 |
Access Manager SDKのコンパイル済みコードをアクセス・サーバーの接続に使用するとき、アクセス管理サービスをオンに設定する必要があります。 キャッシュの自動フラッシュなどの機能は、アイデンティティ・サーバーにバンドルされているSDKを使用します。 キャッシュの自動フラッシュを実行するには、関連するアクセス・ゲートおよびアクセス・サーバーの構成プロファイルでアクセス管理サービスがオンに設定されていることを確認します。 WebGateのみがアクセス・サーバーに関連付けられている場合、アクセス管理サービスをオフに設定する必要があります。
ディレクトリ・サーバーでの変更の同期化: ユーザー・プロファイルまたはポリシー情報の変更はディレクトリ・サーバーで更新されます。 グローバル順序番号は、最新の変更を追跡するためにディレクトリ・サーバーで更新されます。 キャッシュ・フラッシュを実行する前に、アクセス・サーバーは番号をチェックします。 ただし、環境に複数のディレクトリ・サーバーが含まれている場合、対応するエントリの数が同期しない可能性があります。 詳細は、『Oracle Access Managerアクセス管理ガイド』の同期レコードの管理に関する情報を参照してください。
関連する変更が発生するとき、アクセス・サーバー・キャッシュを自動的にフラッシュする手順
IdentityServer_install_dir/identity/oblix/data/common/basedbparams.xmlファイルに移動します。
このIdentityServer_install_dirは、アイデンティティ・サーバーがインストールされているディレクトリです。
basedbparams.xmlファイルでdoAccessServerFlushパラメータを探し、値をtrueに設定します。
<NameValPair ParamName="doAccessServerFlush" Value="true"/>
このアクセス・サーバーに関連するアクセス・ゲートに対して、アクセス管理サービスがオンになっていることを確認してください。
アクセス・システム・コンソールから、「アクセス・システム構成」→「アクセス・ゲート構成」→「すべて」→「実行」をクリックします。
結果リストから該当するアクセス・ゲートのリンクをクリックし、「変更」をクリックします。
必要に応じてアクセス管理サービスをオンに設定して、「保存」をクリックします。
次のようにして、該当するアクセス・サーバーのアクセス管理サービスがオンになっていることを確認します。
アクセス・システム・コンソールから、「アクセス・システム構成」→「アクセス・サーバー構成」をクリックします。
結果リストから該当するアクセス・サーバーのリンクをクリックし、「変更」をクリックします。
必要に応じてアクセス管理サービスをオンに設定して、「保存」をクリックします。
アイデンティティ・サーバーを再起動します。
アクセス・サーバーを再起動します。
次に示すように、configureAccessGateコマンドライン・ツールを使用してダミー・アクセス・ゲートを追加します。
configureAccessGate -i IdentityServer_install_dir/identity/AccessServerSDK -t AccessGate
ファイルObAccessClient.xmlで、インストール中にアクセス・ゲートに対して構成したリスニング・ポートがポート番号に含まれていることを確認します。
IdentityServer_install_dir/AccessServerSDK/oblix/lib/ObAccessClient.xml
アクセス・サーバーの自動キャッシュのフラッシュを実装している場合、この項をスキップできます。
アクセス・サーバーの自動キャッシュのフラッシュを実装しない場合、キャッシュ・タイムアウトが発生するまでこれらのキャッシュに古い情報が格納されたままになります。 ただし、アクセス・システム・コンソールから、アクセス・サーバーのユーザー・キャッシュとパスワード・ポリシー・キャッシュを手動でフラッシュすることができます。 特定のパスワード・ポリシーまたはすべてのパスワード・ポリシーに関する保存情報を、アクセス・サーバー・キャッシュからフラッシュできます。 すべてのリダイレクトURLに関するキャッシュ情報をフラッシュすることもできます。
この項で説明する内容は次のとおりです。
アクセス・サーバーが複数あり、エラーやクラッシュが原因でサーバーが同期されない場合にこのタスクを実行します。 このタスクの実行を行う場合、マスター・アクセス管理者である必要があります。
アクセス・サーバーのユーザー・キャッシュを手動でフラッシュする手順
アクセス・システム・コンソールを起動します。
「アクセス・システム構成」→「ユーザー・アクセス構成」に移動し、「ユーザー・キャッシュのフラッシュ」をクリックします。
特定のユーザーのプロファイル情報とグループ情報をフラッシュするには、「ユーザーの選択」をクリックします。
「セレクタ」ページが表示されます。
ユーザーを検索するには、名前を入力して「実行」をクリックします。
検索結果が「セレクタ」の下にリストされます。
「追加」をクリックしてユーザーを選択します。リストされたすべてのユーザーを選択するには、「すべて追加」をクリックします。
ユーザー名が「選択」の下にリストされます。
「完了」をクリックして画面を閉じます。
選択されたユーザーの名前が「ユーザー・キャッシュのフラッシュ」画面に表示されます。
「キャッシュのフラッシュ」をクリックします。
確認を求めるダイアログ・ボックスが表示されます。
「OK」をクリックしてキャッシュされたユーザー情報を削除します。キャッシュされたユーザー情報を削除しない場合、「取消」をクリックします。
アクセス・サーバーが複数あり、エラーやクラッシュが原因でサーバーが同期されない場合にこのタスクを実行します。 このタスクの実行を行う場合、マスター・アクセス管理者である必要があります。
アクセス・システム・コンソールで、「アクセス・システム構成」→「共通情報の構成」をクリックして、「パスワード・ポリシー・キャッシュのフラッシュ」をクリックします。
パスワード・ポリシーの情報を変更した場合、「指定したパスワード・ポリシーのキャッシュされたすべての情報をフラッシュ」の下にあるリストから該当のポリシーを選択し、「キャッシュのフラッシュ」をクリックします。
パスワード・ポリシー評価順序の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
すべてのパスワード・ポリシーをフラッシュする場合、またはアイデンティティ・システムからパスワード・ポリシーを削除した場合、「キャッシュのフラッシュ」をクリックしてすべてのパスワード・ポリシーのキャッシュされた情報を削除します。
「パスワード・ポリシー管理」画面でリダイレクトURLを変更した場合、「リダイレクトURLのフラッシュ」をクリックします。
パスワード・リダイレクトURLの構成の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
「OK」をクリックして確認します。
デフォルトでは、資格情報マッピング・キャッシュは有効になっています。 この場合、プラグインはユーザーのキャッシュされた資格情報を使用します。
ユーザーが非アクティブの場合は、アイデンティティ・サーバーによるアクセス・サーバー資格情報マッピング・キャッシュの自動フラッシュは行われません。 非アクティブ化したユーザーが保護されているリソースにアクセスできなくするには、手動で資格情報マッピング・キャッシュを無効にする必要があります。 キャッシュがオフになっているとき、ユーザーをユーザー・プロファイル（DN）にマップする必要がある場合、資格情報マッピング・プラグインはLDAPディレクトリと直接通信します。
ログインしたユーザーを非アクティブ化しても、このユーザーはポリシー情報と以前の認証に基づいて引き続きリソースにアクセスできます。 ただし、資格情報マッピング・キャッシュを無効にすると、ユーザーのセッション・トークンの有効期限が切れるか、ユーザーがログアウトしたときに、このユーザーは保護されたリソースへのアクセスが次回の認証時に許可されなくなります。
資格情報マッピング・キャッシュを無効にするには、credential_mappingプラグインのobEnableCredentialCacheパラメータをfalseに設定します。表5-8に、パラメータに使用できる値を示します。
表5-8 credential_mappingプラグインのobEnableCredentialCacheパラメータ
| 値 | 意味 |
|---|---|
|
値なし |
資格情報マッピング・キャッシュをオンにする。 |
|
true |
資格情報マッピング・キャッシュをオンにする。 |
|
false |
資格情報マッピング・キャッシュをオフにする。 |
資格情報マッピング・キャッシュをオフにした場合のcredential_mapping認証プラグインの例を次に示します。
credential_mapping obMappingBase="%domain%",obMappingFilter="
(&(&(objectclass=user)(samaccountname=%userid%))
(|(!(obuseraccountcontrol=*)) (obuseraccountcontrol=ACTIVATED)))",
obdomain="domain",obEnableCredentialCache="false"
obEnableCredentialCacheパラメータを設定する手順
アクセス・システム・コンソールから、「アクセス・システム構成」→「認証管理」をクリックします。
変更する認証スキームを選択し、「変更」をクリックします。
「プラグイン」タブをクリックします。
obEnableCredentialCache="false"パラメータをcredential_mappingプラグインに追加します。
Oracle Access Manager 10g（10.1.4.3）には、複数のアクセス・サーバーの間に同期キャッシュ・フラッシュのリクエストを実行する時にソケットに対して待機時間を設定する新しい機能が用意されています。 この項の内容は次のとおりです。
syncOperationModeキャッシュ・フラッシュ・モードが構成されていない場合、すべてのキャッシュ・フラッシュのリクエストはデフォルトで非同期になります。 非同期式キャッシュ・フラッシュ方式を使用する方法は、「非同期アクセス・システム・キャッシュ・フラッシュの構成」を参照してください。
|
注意: この項では、説明のためアクセス・サーバーを取り上げます。 ただし、この項の内容はポリシー・マネージャとAccess Manager SDKの間の通信、アクセス・サーバーとWebGateの間の通信にも同様に適用されます。 |
メッセージ・チャネルはWebGateとアクセス・サーバー（ポリシー・マネージャとAccess Manager SDK）間のTCP/IP通信の管理に使用されます。 アクセス・サーバーも、キャッシュ・フラッシュのリクエストに対して他のアクセス・サーバーと通信するためにメッセージ・チャネルを使用します。
メッセージ・チャネルはTCP/IP通信のソケットを使用します。 ソケットはメッセージ・チャネルに含まれているTCP/IP通信のエンドポイントです。 キャッシュ・フラッシュ操作では、ソケットに対して2つのタイプの待機時間を指定できます。
無期限の待機時間
Oracle Access Managerの以前のリリースでは、WebGateとアクセス・サーバー間のキャッシュ・フラッシュをリクエストするために無期限の待機時間を使用しました。 （ソケットは、I/Oレスポンスに対して無限に待機します）。 この場合、プライマリ・アクセス・サーバーは、ピア・アクセス・サーバーからレスポンスを受信するため無期限に待機します。 アクセス・サーバーが停止すると、他のアクセス・サーバーにキャッシュ・フラッシュのリクエストが送信されません。 同期キャッシュ・フラッシュ・リクエストの処理により、アイデンティティ・サーバーもレスポンスを受信するまで停止します。
限定された待機期間
I/Oの完了のために指定した時間を構成できます。 予想される操作が指定された時間内に完了しない場合、エラーが報告されてリクエストが他のアクセス・サーバーに送信されます。 1つのアクセス・サーバーが停止しても、同期リクエストを使用するWebPassおよびポリシー・マネージャは停止しません。
|
注意: アクセス・サーバーが停止すると、キャッシュ・フラッシュのリクエストが他のアクセス・サーバーに送信され、エラーが記録されます。 |
同期キャッシュ・フラッシュのリクエストに対して、環境に基づいて特定の待機期間を指定することをお薦めします。 デフォルトでは、アクセス・サーバーとポリシー・マネージャは無期限に待機します。 各コンポーネントの（アクセス・サーバーまたはポリシー・マネージャ）globalparams.xmlファイルのCacheFlushTimeOutパラメータに対して正整数の値を設定することにより、この期間を制限できます。 値は秒単位で指定されて、ミリ秒単位に変換されます。
|
注意: デプロイメント環境に基づいてCacheFlushTimeOutパラメータをチューニングする必要があります。 |
表5-9で、パラメータおよび使用可能な値について説明します。
表5-9 globalparams.xmlのCacheFlushTimeOutパラメータ
| 値 | 説明 |
|---|---|
|
正の整数（たとえば、10） |
ピア・アクセス・サーバーからのレスポンスを待機する秒数 注意: 指定されたこのタイムアウト値は、1000をかけてミリ秒単位に変換され、アクセス・サーバーのクライアント・オブジェクトに割り当てられます。 |
|
負の整数（たとえば、-10） |
デフォルト値を想定 注意: 0未満の値は、値なしまたはパラメータなしと同じです。 |
|
値なし |
デフォルト値を想定 |
|
パラメータなし |
無期限の待機時間が受け入れられる。 これはデフォルト値です。 |
待機時間が指定されている場合、プライマリ・アクセス・サーバーのログ・ファイルに次の警告レベルのログ・メッセージが書き込まれます。
キャッシュ・フラッシュが失敗しました。失敗したAAA サーバー・リスト= (停止したアクセス・サーバーのリスト)
詳細は、次を参照してください。
キャッシュ・フラッシュ操作に対して待機時間を構成する手順: 待機時間のある複数のアクセス・サーバー間の同期キャッシュ・フラッシュ・リクエストの構成
閉じられたソケットが発生する場合のエラー処理の詳細: キャッシュ・フラッシュ中のメッセージ・チャネルの初期化のためのエラー処理
デプロイメント環境に基づいてCacheFlushTimeOutパラメータをチューニングする必要があります。 このタスクを実行するには、マスター・アクセス管理者である必要があります。
Access Manager SDKから発生する同期キャッシュ・フラッシュ・リクエストに対して、各アクセス・サーバーのglobalparams.xmlファイルにCacheFlushTimeOutパラメータを追加する必要があります。
ポリシー・マネージャから発生する同期キャッシュ・フラッシュ・リクエストに対して、ポリシー・マネージャのglobalparams.xmlファイルにCacheFlushTimeOutパラメータを追加する必要があります。
キャッシュ・フラッシュ・リクエストに対して待機時間を設定する手順
プライマリ・アクセス・サーバーをホストするコンピュータで、globalparams.xmlファイルを探します。 次に例を示します。
AccessServer_install_dir/access/oblix/apps/common/bin/globalparams.xml
ファイルを開いて、UserMgmtNodeEnabledセクションの下にCacheFlushTimeOutパラメータを追加します。 次に例を示します。
<SimpleList>
<NameValPair
ParamName="UserMgmtNodeEnabled"
Value="False"></NameValPair>
</SimpleList>
<SimpleList>
<NameValPair
ParamName="CcheFlushTimeout"
Value="10"></NameValPair>
</SimpleList>
ファイルを保存します。
アクセス・サーバーを再起動します。
デプロイメントでアクセス・サーバーごとにこの手順を繰り返します。
ポリシー・マネージャのglobalparams.xmlファイルを編集し、ポリシー・マネージャから発生するキャッシュ・フラッシュ・リクエストに対してこの手順を繰り返します。
メッセージ・チャネルは、WebGate、アクセス・サーバー、およびキャッシュ・フラッシュ・リクエストのアクセス・サーバー間のTCP/IP通信の管理に使用されます。 メッセージ・チャネルは個別のスレッドとして実行されます。 メッセージ・チャネルは、ピア・アクセス・サーバーとハンドシェークすることで自動的に初期化されます。 ハンドシェークの処理が終了すると、アクセス・サーバーにメッセージが送信されます。 設定期間でメッセージ・チャネルを使用する場合、これはすべてのリクエストに適用されます。
キャッシュ・フラッシュ中にアクセス・サーバーが停止すると、メッセージ・チャネルの初期化操作は失敗し、ソケットは閉じられます。 ソケットが閉じると、コンポーネントは読取りができなくなります。
Oracle Access Managerの以前のリリースでは、メッセージ・チャネルの初期化操作が失敗しても、閉じたソケットで操作は継続されました。 その結果、ソケット・エラーが発生します。 しかし、Oracle Access Manager 10g（10.1.4.3）では、WebGateおよびアクセス・サーバーが共有するネットワーク層が拡張されています。 その結果、閉じたソケットが原因となるメッセージ・チャネルの初期化失敗のエラーが回避されます。 現在は、メッセージ・チャネルはメッセージの送受信を停止し、次の警告レベルのログ・メッセージが記録されます。
警告レベルのエラー・メッセージ: 「ソケット操作の実行中にエラーが発生しました」
キャッシュ・フラッシュ・リクエスト中にアクセス・サーバーが停止し、同期キャッシュ・フラッシュ・リクエストに指定期間がある場合でさえ、WebGateおよびアクセス・サーバーは障害から回復します。
キャッシュ・フラッシュ操作でアイデンティティ・サーバーとアクセス・サーバーの間の混合方式通信を構成して、システム・パフォーマンスを向上させるには、2つの方法があります。 この項の内容は次のとおりです。
この項の内容は次のとおりです。
Oracle Access Manager 10g（10.1.4.2.0）からは、キャッシュ・フラッシュ・リクエスト以外のすべてのリクエストに対して、簡易または証明書のトランスポート・セキュリティを使用する方法が用意されています。 この方法は、『Oracle Access Manager Patchset Notes Release 10.1.4 Patchset 1 (10.1.4.2.0) For All Supported Operating Systems』で説明されています。
パフォーマンスを向上させるか、コンポーネント間のリクエストのルーティングを単純化するには、すべてのキャッシュ・フラッシュ・リクエストを処理するために単一のアクセス・サーバーを指定することができます。 キャッシュ・フラッシュ・リクエストを受信するために特定なアクセス・サーバーが指定されている場合、そのアクセス・サーバーはリクエストを受信すると同じキャッシュ・フラッシュ・リクエストを残りのすべてのアクセス・サーバーに送信します。 専用のアクセス・サーバーがキャッシュ・フラッシュ・リクエストを送信するときはオープン・モードの通信が使用され、他のリクエストに対しては簡易モードまたは証明書モードが使用されていることを確認することができます。
キャッシュ・フラッシュ・リクエストに対してセキュリティ・モードをオープン・モードに変更しても、アクセス・サーバーが最初に簡易モードまたは証明書モードで構成されている限り、Access Manager SDKまたはWebGateは簡易モードや証明書モードでアクセス・サーバーと通信します。 これにより、ほとんどの操作に対してセキュリティを確保できます。
一部の操作にオープン・モードを、他の操作にセキュアなモードを使用するようにアクセス・サーバーを構成する機能は、混合セキュリティ・モードと呼ばれます。
次のタスクの概要では、オープン・モードでキャッシュ・フラッシュ・リクエストを処理し、別のタイプのリクエストに対してはセキュアな通信を維持する環境を構成する方法について説明します。
タスクの概要: オープン・モードのキャッシュ・フラッシュ・リクエストに対してアクセス・サーバーを手動で構成し、他のリクエストに対してセキュアな通信を維持します。
簡易モードまたは証明書モードでアクセス・サーバーをインストールします（または、デプロイメントをアップグレードして、すべてのアクセス・サーバーを簡易モードまたは証明書モードで使用するように構成します）。
詳細は、『Oracle Access Managerインストレーション・ガイド』または『Oracle Access Managerアップグレード・ガイド』を参照してください。
「アクセス・サーバー構成」ページの関連項目を使用して、すべてのキャッシュ・フラッシュ・リクエストを処理するために1つのアクセス・サーバーまたはクラスタを指定します。
Access Manager SDKを処理するAccessGateに対して1つのプライマリ・サーバーのみをリスト表示すると、アイデンティティからのすべてのフラッシュ・リクエストに対して1つのアクセス・サーバーが指定できます。 「アクセス・ゲート構成」ページから、名前を選択して「変更」をクリックします。 「アクセス・ゲートの詳細」ページから、「すべてのアクセス・サーバーのリスト」をクリックして、AccessGateに対して1つのみが指定されていることを確認します。 アクセス・サーバー構成およびアクセス・ゲート構成の詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
|
注意: ポリシー・マネージャからのキャッシュ・フラッシュ・リクエストに対し、リクエストの受信に特定なアクセス・サーバーは指定できません。 ポリシー・マネージャは、LDAPディレクトリ・サーバーを使用してすべての使用可能なアクセス・サーバーにキャッシュ・フラッシュ・リクエストを送信します。 |
WebGateおよびアクセス・ゲートを、簡易モードまたは証明書モードを使用するそれぞれのアクセス・サーバーと通信するように構成します。
方法1か方法2を使用して、すべてのアクセス・サーバーを混合トランスポート・セキュリティ・モードに変換します。
次の項を参照して、必要に応じてタスクを実行します。
方法1を選択して混合セキュリティ・モードの通信を手動で有効にすると、次の重要な条件が適用されます。
混合セキュリティ・モードの通信を構成した後に、特定のWebGateに関連するアクセス・サーバーのリストを表示するとき、次のメッセージが表示される場合があります。
"Not Responding Transport security mismatch"。
このメッセージは無視することができます。 ただし、もう1つの条件があります。
方法1を使用して混合セキュリティ・モードを手動で構成した後に、アクセス・ゲートまたはWebGateを変更するには特定の方法に従う必要があります。 そうしないと、configurewebgateツールまたはconfigureaccessgateツールを実行するときに、WebGateはアクセス・サーバーと通信できません。 具体的には、アクセス・ゲートまたはWebGateを変更すると、以前のすべてのPreferred HTTP Host設定が削除されます。 この問題を避けるには、方法1を使用してアクセス・サーバーを構成した後、「方法1を使用して混合セキュリティ・モードを手動で有効化した後のWebGateの変更」に示されているタスクを実行します。
キャッシュ・フラッシュのリクエストに対してオープン・モードのトランスポート・セキュリティを使用し、他のリクエストに対してSSLまたは証明書モードのトランスポート・セキュリティを使用するには、以下の手順でアクセス・サーバーを構成します。 『Oracle Access Managerデプロイメント・ガイド』のキャッシングに関する章に説明されているように、セキュアな通信を主に使用している環境にキャッシュの自動フラッシュを実装している場合は、この手順が便利です。
|
注意: デプロイメントは10g（10.1.4.2.0）以降でなければなりません。 |
最初に、通信に簡易モードまたは証明書モードを使用するように各アクセス・サーバーが構成されていることと、すべてのWebGateまたはアクセス・ゲートが簡易モードまたは証明書モードでアクセス・サーバーと通信していることを確認します。 次に、すべてのアクセス・サーバーがオープン・トランスポート・セキュリティ・モードを使用するように構成し、再起動します。 アクセス・サーバーを再起動すると、セキュアな通信に必要な証明書が保持され、簡易モードまたは証明書モードでほとんどの情報の送受信が続けられます。 ただし、これらのアクセス・サーバーはキャッシュ・フラッシュ・リクエストに対してオープン・モードを使用しています。
混合セキュリティ・モードを使用するようにアクセス・サーバーを手動で構成する方法: 方法1
『Oracle Access Managerインストレーション・ガイド』の「インストールの準備」のトランスポート・セキュリティのガイドラインに従って、セキュアな通信（簡易モードまたは証明書モード）に対してデプロイメントが構成されていることを確認します。
トランスポート・セキュリティ: 簡易モードまたは証明書モード
configurewebgateまたはconfigureaccessgateツールを実行して、同じセキュア・モードですべてのアクセス・サーバーと通信するように、すべてのWebGates（およびアクセス・ゲート）を構成します。
アクセス・システム・コンソールで、簡易モードまたは証明書モードをオープン・モードに変更するように各アクセス・サーバーの構成を変更します。 次に例を示します。
トランスポート・セキュリティ: オープン
アクセス・サーバーを再起動して、キャッシュ・フラッシュ・リクエストでのオープン・モードの使用を有効にします。
すべてのアクセス・サーバーに対して、ステップ3と4を繰り返します。
「方法1のための注意点および条件」を参照します。
ステップ1～5を実行した後で、アクセス・ゲートまたはWebGateを更新するには、「方法1を使用して混合セキュリティ・モードを手動で有効化した後のWebGateの変更」を参照してください。
「方法1のための注意点および条件」に示した問題を回避するには、次の手順を使用します。
手順1を使用して手動で混合トランスポート・セキュリティ・モードを有効にした後に、アクセス・ゲートまたはWebGateを変更する方法
アクセス・ゲートまたはWebGateを変更する前に、セキュアなトランスポート・セキュリティ・モードを使用するためアクセス・システム・コンソールですべてのアクセス・サーバーを再構成します。
トランスポート・セキュリティ: 簡易モードまたは証明書モード
必要に応じて、アクセス・ゲートまたはWebGateを変更します。
アクセス・システム・コンソールで、トランスポート・セキュリティに対してオープン・モードを使用するためすべてのアクセス・サーバーを再構成します。
トランスポート・セキュリティ: オープン
アクセス・サーバーを再起動します。
方法1は有効ですが、10g（10.1.4.3）には、混合方式通信を有効にするための新しい方法が用意されています。 この新しい方法により、作業が効率化され、方法1に関連するいくつかの問題が回避されます。
次の項では、方法2について説明します。
Oracle Access Manager 10g（10.1.4.3）では、アクセス・サーバーとポリシー・マネージャ（ポリシー・キャッシュをオープン・モード）のglobalparams.xmlのsetAccessFlushInOpenModeパラメータを使用して、自動混合モード通信を提供します。
ファイルにこのパラメータがない場合や「true」に設定した場合、キャッシュ・フラッシュ・リクエストのパフォーマンスを向上させるために、キャッシュ・フラッシュ・メッセージ・チャネルがオープン・モードで作成されます。 それ以外の場合、アクセス・サーバーまたはポリシー・マネージャに構成したトランスポート・セキュリティが次のように使用されます。
表5-10 自動的な混合方式通信用のsetAccessFlushInOpenMode
| ステータス | 説明 |
|---|---|
|
パラメータなし |
パラメータは「 |
|
True |
すべてのアクセス・サーバーのキャッシュ・フラッシュのリクエストに対してオープン・モードが使用されます。 これはデフォルト値です。 |
|
False |
「アクセス・サーバー構成」ページ（またはポリシー・マネージャの設定ときに）で指定したトランスポート・セキュリティ・モードは、キャッシュ・フラッシュおよび他のすべてのリクエストのために使用されます。 |
タスクの概要: アクセス・システムのキャッシュ・フラッシュ操作のための自動的な混合方式通信の有効化
『Oracle Access Managerインストレーション・ガイド』の「インストールの準備」のトランスポート・セキュリティのガイドラインに従って、セキュアな通信（簡易モードまたは証明書モード）のために10g（10.1.4.3）デプロイメントが構成されていることを確認します。
トランスポート・セキュリティ: 簡易モードまたは証明書モード
トランスポート・セキュリティの設定の詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
自動的な混合方式: globalparams.xmlファイルはそのままにします。 デフォルトでは、アクセス・サーバーとポリシー・マネージャ・キャッシュ・フラッシュ操作のための自動的な混合方式通信が有効になっています。
自動的な混合方式のセキュリティの無効化: 「アクセス・システム・キャッシュ・フラッシュのリクエストを使用する自動混合モード・セキュリティのための方法2の使用」で説明されているように、globalparams.xmlファイルでは、コンポーネントのためにsetAccessFlushInOpenModeは「false」に設定します。
デフォルトでは、10g （10.1.4.3）でのアクセス・システムのキャッシュ・フラッシュ操作に対して自動混合モード・セキュリティが有効になっています。
|
注意: 自動混合モードを無効にし、構成したトランスポート・セキュリティを使用するには、setAccessFlushInOpenModeを「false」に設定します。 |
アクセス・システム・キャッシュ・フラッシュのリクエストのために自動混合モード・セキュリティを有効または無効にする方法
『Oracle Access Managerインストレーション・ガイド』の「インストールの準備」のトランスポート・セキュリティのガイドラインに従って、簡易モードまたは証明書モードでセキュアな通信のためにデプロイメントが構成されていることを確認します。
自動混合モードセキュリティ: 何もしない
自動混合モードセキュリティの無効化（省略可能）: アクセス・サーバーとポリシー・マネージャごとに次の手順に従います。
アクセス・サーバーをホストするコンピュータ上で、次のディレクトリ・パスにあるglobalparams.xmlファイルを探します。
component_install_dir\access\oblix\apps\common\bin\globalparams.xml
ファイルの最後にsetAccessFlushInOpenModeパラメータを追加し、値をfalseにします。 次に例を示します。
<SimpleList>
<NameValPair
ParamName="UserMgmtNodeEnabled"
Value="False"></NameValPair>
</SimpleList>
<SimpleList>
<NameValPair
ParamName="setAccessFlushInOpenMode"
Value="False"></NameValPair>
</SimpleList>
</CompoundList>
アクセス・サーバーを再起動し、変更された値を反映します（このファイルのパラメータは、アクセス・サーバーが起動するときに1回しか読み取られません)。
アクセス・サーバーごとにこの手順を繰り返します。
ポリシー・マネージャごとにこの手順を繰り返します。
この項の内容は次のとおりです。
Oracle Access Managerのロギング機能では、システム・パフォーマンスとシステムの状態を解析し、問題をトラブルシューティングできます。 コンポーネントの各インスタンスに格納されている構成ファイルを編集することにより、ロギングを設定できます。 アクセス・サーバーのためにロギングを設定するには、アクセス・サーバー・インスタンスごとに次のファイルを探して編集します。
AccessServer_install_dir\access\oblix\config\oblog_config.xml
|
重要: ログ構成ファイルのデフォルト・パスまたは名前を変更しないでください。 |
構成ファイルには、テキスト・エディタを使用して編集できるXML文が含まれています。 デフォルトのそれぞれのログ構成ファイルには、ユーザ独自の構成を作成するときに使用できるコメントとサンプルが含まれています。
LOG_WRITERパラメータを使用して、ログ出力をシステム・ログまたはファイルに送信できます。
ログ・ファイルは、コンポーネントのルート・インストール・ディレクトリに格納されています。
コンポーネント用のホストのシステム・ファイル。
同じホストに複数のコンポーネントがある場合は、すべてのコンポーネントにより、そのホストのシステム・ログ・ファイルにデータが送信されます。
複数のタイプのログ・ライターに特定のレベルのログまたは様々なレベルのログが送信できます。 たとえば、システム・ログにFatalデータを送信し、ファイルにDebugデータが送信できます。 またはシステム・ログとファイルの両方にFatalデータが送信できます。
ログ出力の完全な定義には、LOG_WRITERの値とLOGLEVELが含まれています。 この完全な定義は、log-handlerと呼ばれます。 次に例を示します。
<!--システム・ロガーにすべてのデバッグ・ログを書き込む。 -->
<ValNameList xmlns="http://www.oblix.com" ListName="LogDebug3Sys">
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_DEBUG3" />
<NameValPair ParamName="LOG_WRITER" Value="SysLogWriter" />
<NameValPair ParamName="LOG_STATUS" Value="On" />
</ValNameList>
LOGLEVEL_DEBUG3は大量のデータを記録します。これは、パフォーマンスに影響する機能をデバッグするために役立ちます。 LOGLEVEL_DEBUG3を使用し、ユーザーまたはポリシー情報を変更してキャッシュをフラッシュすると、出力ファイルにメッセージが記録されます。 構成したモード（混合モード）を使用する他のリクエストとともに、アクセス・サーバー間のキャッシュ・フラッシュ・リクエストがオープン・モードで送信されると、各アクセス・サーバーのログ・ファイルには次のメッセージが書き込まれます。
すべてのAAAサーバーに対するキャッシュ・フラッシュ・リクエストはオープン・モードで処理されます
このメッセージがアクセス・サーバー・ログにない場合は、キャッシュ・フラッシュのリクエストに対して混合モードが使用されていません。 その代わり、そのアクセス・サーバーに対して構成済のトランスポート・セキュリティ・モードが使用されています。
ログ構成ファイルへの変更を保存すると、変更は60秒ごとに自動的に取得されます。 詳細は、『Oracle Access Manager IDおよび共通管理ガイド』のロギングに関する章を参照してください。
混合モード通信メソッドを取得するには、次の手順でキャッシュ・フラッシュ・ロギングを有効にします。
キャッシュ・フラッシュ操作のロギングを有効にする方法
次のように、アクセス・サーバーのログ構成ファイルを探します。
AccessServer_install_dir\access\oblix\config\oblog_config.xml
テキスト・エディタでファイルを開き、DEBUG3にLOGLEVEL_を設定します。
<!--システム・ロガーにすべてのデバッグ・ログを書き込む。 -->
<ValNameList xmlns="http://www.oblix.com" ListName="LogDebug3Sys">
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_DEBUG3" />
LOG_WRITERの出力場所を定義します。 次に例を示します。
<ValNameList xmlns="http://www.oblix.com" ListName="LogDebug2Sys">
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_DEBUG3" />
<NameValPair ParamName="LOG_WRITER" Value="SysLogWriter" />
<NameValPair ParamName="LOG_STATUS" Value="On" />
</ValNameList>
ファイルを保存します。
ユーザーまたはポリシー情報を変更して、いつものようにロギングをテストします。
混合モード通信を示すメッセージのログ出力を確認します。
すべてのAAAサーバーに対するキャッシュ・フラッシュ・リクエストはオープン・モードで処理されます
デプロイメントにアクセス・システムが含まれていない場合、この項をスキップできます。
この項のタスクを実行するには、マスター・アクセス管理者である必要があります。 この項の内容は次のとおりです。
Oracle Access Manager 10g（10.1.4.3）には、アイデンティティ・サーバーとアクセス・サーバーの間の非同期キャッシュ・フラッシュの操作ができる新しいパラメータが用意されています。 フラッシュされるアクセス・サーバーのキャッシュは次のとおりです。
ユーザー・キャッシュのフラッシュ
パスワード・ポリシーのフラッシュ
パスワード・リダイレクトURLのフラッシュ
ロスト・パスワード管理ポリシーのフラッシュ
アクセス・ゲート構成のsyncOperationModeパラメータ値は、表5-11に示されているように、同期または非同期キャッシュ・フラッシュ操作があるかを決定します。 デフォルトでは、このパラメータ値はfalseになっています。
表5-11 アクセス・ゲート構成のsyncOperationModeパラメータ
| 値 | 説明 |
|---|---|
|
true |
アクセス・サーバーの同期キャッシュ・フラッシュを有効にします。 |
|
false |
非同期キャッシュ・フラッシュの操作を有効にして、アクセス・サーバーの同期キャッシュ・フラッシュを無効にします。 これはデフォルト値です。 |
|
値なし |
デフォルト値のfalseを想定します。 アクセス・サーバーの非同期キャッシュ・フラッシュを有効にして、同期キャッシュ・フラッシュを無効にします。 |
|
パラメータなし |
デフォルト値のfalseを想定します。 アクセス・サーバーの非同期キャッシュ・フラッシュを有効にして、同期キャッシュ・フラッシュを無効にします。 |
このタスクを実行するには、マスター・アクセス管理者である必要があります。 このタスクは、アクセス・サーバーおよびAccess Manager SDKの通信のために実行されます。
アイデンティティ・サーバーとアクセス・サーバーの間の非同期キャッシュ・フラッシュ操作を有効にする方法
アクセス・システム・コンソールから、「アクセス・システム構成」→「アクセス・ゲート構成」をクリックします。
「すべて」→「実行」をクリックし、該当するアクセス・ゲートのリンクをクリックし、「変更」をクリックします。
ユーザー定義パラメータに関する項では、次のパラメータと値を入力します。
Parameters: syncOperationMode
Value: true
「保存」をクリックします。
