情報のキャッシングとクローニングは、Oracle Access Manager環境のパフォーマンスを調整する場合に重要な役割を果します。この章の内容は次のとおりです。
Oracle Access Managerのコンポーネントをインストールする場合、コマンドラインやインストールGUIを使用するかわりにすでにインストールされているコンポーネントの構成をクローニングすると、コンポーネントを自動的にインストールできます。クローニングを実行すると、インストール済コンポーネントをテンプレートとしてリモート・システムにコンポーネントのコピーが作成されます。
同期化を実行すると、2つの同じインストール済Oracle Access Managerコンポーネントの一方がもう一方よりも新しい場合、これらの2つのコンポーネントを一致させることができます。同期化を使用して、同様のプラットフォーム上のインストールをアップグレードまたは修正することができます。
クローニングと同期化の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
キャッシュとは、最近使用した情報のコピーが保持されるメモリー内の領域のことです。Oracle Access Managerでは、頻繁に使用される情報がディレクトリからではなくキャッシュから取り出されます。これにより、情報をすばやく取り出すことができます。Oracle Access Managerは、パフォーマンスを向上させるために複数のキャッシュを使用します。
アイデンティティ・システムとアクセス・システムには、異なるキャッシュが用意されています。Oracle Access Managerのシステムは、構成の設定とグループ情報をキャッシュします。アクセス・システムは、パスワード・ポリシー、ポリシー・ドメイン、ユーザー資格情報、認証スキームに関する情報をキャッシュします。
Oracle Access Managerで実行される一部の操作は、アクセス・システムのアクセス・ポリシー評価に影響します。たとえば、アイデンティティ・システムでユーザーを非アクティブの状態にした場合、このユーザーはアクセス・システムによって保護されるリソースにアクセスできなくなるため、この変更をアクセス・システムに対しても反映させる必要があります。
キャッシュ内の最適な要素数は、次に示す2つの数値間のバランスによって決定されます。
キャッシュ内に必要な要素の数。これは、キャッシュされる情報の内容とシステムの使用状況によって異なります。
キャッシングに使用できるRAM
キャッシュ内の要素数が増えるに従って、要求された情報が見つかる確率とパフォーマンスが向上する確率が高くなります。
キャッシュによるメモリー使用量が多く、コンポーネントを実行しているマシンのRAMが不十分な場合、オペレーティング・システムがページをメモリーからスワップする場合に時間がかかることがあります。これにより、パフォーマンスが低下します。
最適なパフォーマンスのための最小キャッシュ・サイズは次のようになります。
N = XR
この代数の意味は次のとおりです。
N: キャッシュ内のエントリ数。X: 1秒当たりの新規セッション数。R: 秒単位の平均セッション長。
次に、例を示します。
X: 1秒当たり100セッション。R: 1セッション当たり600秒。N: キャッシュ内のエントリ60,000。
Oracle Access Managerコンポーネントのデフォルト・キャッシュ・サイズは、ほとんどのインストールに対して十分な値が設定されています。
ここでは、次の内容について説明します。
アイデンティティ・サーバーは、相互に通信することができます。主にキャッシュ・フラッシュをリクエストする際に、相互通信を行います。1つのサーバーでキャッシュが更新されると、そのサーバーは他のサーバーに対してキャッシュを更新するよう通知します。アイデンティティ・サーバーには複数のキャッシュがあります。データが変更された場合、各サーバーはキャッシュ・フラッシュのリクエストを受信することができます。
構成データ: オブジェクト・クラス、属性、タブ、パネルを指します。Oracle Access Manager固有のデータ(OSD)のキャッシュは、自動的にフラッシュされます。また、「OSDキャッシュを消去する手順」の説明に従ってキャッシュ・フラッシュを要求することができます。
グループ・オブジェクト: グループを変更した場合は、自動的にキャッシュがフラッシュされます。または、「グループ・オブジェクトのキャッシング」の説明に従って、キャッシュ・フラッシュを明示的に要求することができます。
ユーザー・オブジェクトのDN: これは名前キャッシュです。自動的にフラッシュされます。
属性の読取り権限と書込み権限: 自動的にキャッシュがフラッシュされます。
委任ID管理と監査: 自動的にキャッシュがフラッシュされます。
ワークフロー定義と参加者: 自動的にキャッシュがフラッシュされます。
設定時に入力された基本構成データ: 構成ベース(構成DN)と検索ベースです。自動的にキャッシュがフラッシュされます。
ユーザー定義ポータルの挿入: 『Oracle Access Managerカスタマイズ・ガイド』に記載されているように、URLで明示的に起動されます。
アイデンティティ・サーバーの非同期キャッシュ・フラッシュを構成する手順
次のファイルを編集します。
identity_server_installdir/oblix/apps/common/bin/globalparams.xml
このファイルに含まれているoisClientTimeoutThresholdパラメータを構成します。
このパラメータのデフォルト値は60秒です。このパラメータを指定しない場合または値が-1の場合は、同期キャッシュ・フラッシュが指定されます。
各アイデンティティ・サーバーに対して、次の手順を実行します。
キャッシュ・タイムアウトにより、要素をキャッシュに保持する期間が指定されます。期限が切れると要素はキャッシュから削除されるため、ディレクトリから取り出す必要があります。
情報が変更されているのにキャッシュは変更されていない場合、期限切れになった情報がキャッシュから削除されるまで、Oracle Access Managerのコンポーネントはこの古い情報を使用します。この問題を避けるための1つの方法として、情報を変更した場合にキャッシュを更新する方法があります。ユーザーの情報が他のソフトウェアを使用して変更された場合など、キャッシュを更新できない場合は、別の解決策としてキャッシュに適切なタイムアウトを設定する方法があります。
短いタイムアウトを設定すると、ユーザーに関する情報はより新しいものになりますが、アイデンティティ・サーバーとアクセス・サーバーがディレクトリからデータをフェッチする頻度を上げる必要があります。これにより、パフォーマンスが低下することがあります。長いタイムアウトを設定した場合、古い情報がより長期間キャッシュ内に残ることになります。
注意: 一般的に、キャッシュ・タイムアウト値を低く設定すると、キャッシュ内のデータはより新しくなります。ただし、キャッシュ・タイムアウト値を0に設定すると、そのキャッシュは期限切れになりません。 |
Oracle Access Managerは、Oracle Access Managerアプリケーションで使用されるオブジェクト・クラス、属性、パネル、タブなど、特定のデータの構成情報をキャッシュします。この情報は、起動時に自動的にキャッシュされます。
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-1の説明に従って、キャッシュに関連する関数を制御するgroupdbparams.xmlファイルのパラメータ値を構成します。
表5-1 groupdbparams.xmlのパラメータ
パラメータ | 説明 |
---|---|
GroupCacheTimeout |
オブジェクトの有効時間(秒)。 デフォルトでは、グループ・キャッシュはタイムアウトしません。 デフォルト値は0です。 |
GroupCacheMax NumElements |
キャッシュ内に保存できるグループ・オブジェクトの最大数。 デフォルト値は10000です。キャッシュが最大サイズに達している場合、アクセスの少ないオブジェクトはアクセスの多いオブジェクトと置き換えられます。 このパラメータの値を設定する場合、システム・メモリーの制限事項を考慮してください。 |
GroupCacheDisabled |
キャッシュが使用できるかどうかを指定します。 デフォルト値はfalseです。 値がfalseの場合、キャッシュは使用できます。値がtrueの場合、キャッシュは使用できません。キャッシュが無効になっている場合、グループ・オブジェクトはすべてディレクトリから読み取られます。 |
GroupCacheRead FromMaster |
グループの読取りを強制的に行い、レプリケートされた環境のマスター・レプリカからのキャッシュによる読取りを可能にします。これにより、コンシューマ・レプリカがマスター・レプリカから更新情報を受信する前にコンシューマ・レプリカからの読取りが発生した場合、キャッシュ内に古い情報が残らなくなります。 デフォルト値はfalseです。 値がtrueの場合、キャッシュはマスター・レプリカからの読取りを行います。 |
場合によっては、キャッシュからグループを削除してキャッシュの一貫性を維持することが必要になることがあります。たとえば、キャッシュがグループの読取りリクエストを受信した際に、確実に更新されたグループが読み取られるようにする場合、Oracle Access Manager以外のアプリケーションを使用して変更されたグループを削除する必要が生じることがあります。
マスターID管理者は、アイデンティティ・システム・コンソール、またはflushGroupCacheという名前のIdentity XML関数を使用して、グループ・キャッシュを消去できます。詳細は、『Oracle Access Manager開発者ガイド』のIdentityXMLに関する章を参照してください。
アイデンティティ・システム・コンソールからグループ・キャッシュを消去する手順
アイデンティティ・システム・コンソールを起動します。
「グループ・マネージャ構成」タブをクリックします。
「グループ・マネージャ構成」ページの「グループ・キャッシュ」をクリックします。
「グループ・キャッシュ」ページの「グループ・キャッシュの消去」リンクをクリックします。
グループ・キャッシュが消去され、操作が成功したかどうかを示すメッセージが表示されます。
Oracle Access Managerでユーザーが非アクティブの状態になっている場合、保護されたリソースに対するこのユーザーのアクセスを拒否することができます。ユーザーが非アクティブの状態になっている場合はアイデンティティ・サーバーによるアクセス・サーバー資格情報マッピング・キャッシュの自動フラッシュは行われないため、資格情報マッピング・キャッシュを手動でオフにする必要があります。
キャッシュがオフになっている状態でユーザーをユーザー・プロファイル(DN)にマップする必要がある場合、資格情報マッピング・プラグインは常にLDAPディレクトリと直接通信します。それ以外の場合、プラグインはユーザーのキャッシュされた資格情報を使用します。
デフォルトでは、資格情報マッピング・キャッシュは有効になっています。
このキャッシュを使用できないようにするには、credential_mappingプラグインのobEnableCredentialCacheパラメータをfalseに設定します。この場合、ログインしたユーザーを非アクティブ化しても、このユーザーはポリシー情報と以前の認証に基づいて引き続きリソースにアクセスできます。ただし、obEnableCredentialCacheをfalseに設定すると、ユーザーのセッション・トークンの有効期限が切れるか、ユーザーがログアウトした場合、このユーザーの次回認証時に保護されたリソースへのアクセスが許可されなくなります。
表5-2に、パラメータに使用できる値を示します。
表5-2 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プラグインに追加します。
アクセス・システムは、パスワード・ポリシー、ポリシー・ドメイン、ユーザー資格情報、認証スキームに関する情報をキャッシュします。
図5-1に、アクセス・システムにおけるキャッシングの仕組みを示します。これは必ずしもデプロイメントの推奨事項ではありません。
キャッシュ内の最大要素数を指定できます。アクセス・システムにより、キャッシュ内の合計要素数がキャッシュに指定された最大数を超えないように制御されます。
たとえば、最大100,000の要素を格納するようにアクセス・サーバーのユーザー・キャッシュを設定したとします。キャッシュが一杯になったときにユーザーがシステムに追加された場合、アクセス・システムは最も長期間使用されていないユーザーの要素を削除し、新しいユーザーに関する情報をキャッシュに追加します。
注意: WebGateとAccess Clientの構成は、アクセス・サーバー内にキャッシュされます。WebGateとアクセス・サーバー間、およびアクセス・サーバーとLDAPディレクトリ・サーバー間の閑散時のネットワーク・トラフィックを削減するには、キャッシュ・タイムアウトのデフォルト構成を変更します。コンポーネント間のネットワーク・トラフィック削減の詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。 |
アクセス・サーバーは、ポリシー・ドメイン、ポリシー、ユーザー、ホスト識別子、パスワード・ポリシーに関するデータなどの情報をキャッシュします。これらのいずれかの情報が更新された場合、「キャッシュの更新」ボックスを選択してただちにアクセス・サーバーのキャッシュを更新してください。
アクセス・サーバーのポリシー・キャッシュには、ポリシー・ドメイン、ポリシー、認証、認可、監査ルール、アクションに関する情報が格納されます。
アクセス・サーバーは、実行時に効率的な検索を行うためにポリシー情報をキャッシュします。ポリシー情報がキャッシュにない場合、アクセス・サーバーは情報をディレクトリから取得する必要があります。データをディレクトリから取得する場合はアクセス・ゲートがアクセス・サーバーから情報を取得する場合よりも時間がかかるため、すべてのポリシー情報がキャッシュされているほうが効率的です。
ポリシー・マネージャやアクセス・システム・コンソールを使用してポリシー情報が変更された場合、「キャッシュの更新」を選択することによってアクセス・サーバーのキャッシュを即座に更新できます。この機能を使用しない場合は、ポリシー・キャッシュ・タイムアウトが重要になります。キャッシュ・タイムアウトには、「キャッシュの更新」を使用しない(または使用できない)場合に、どれくらいの頻度でポリシー情報の更新が必要なのかを設定してください。デフォルトのポリシー・キャッシュ・タイムアウトは2時間です。
すべての構成済ポリシー情報を保持するのに十分なメモリーがアクセス・サーバーのマシンに設定されている場合、次のうち最も高い値に従って最大要素数を設定してください。
ポリシー・ドメインの合計数
デフォルトまたはそれ以外の認証ルールの合計数
デフォルトまたはそれ以外の認可ルールの合計数
デフォルトまたはそれ以外の監査ルールの合計数
この構成は、一般的なデプロイメントの場合に機能します。
アクセス・サーバーのユーザー・キャッシュには次に示すものに関する情報が含まれています。
ユーザー・プロファイル。アクションおよびルールベースのアクセス評価の両方で必要です。
ユーザーのグループ・メンバーシップ・ステータス。ユーザーがグループのメンバーであるかどうかなどの情報です。
アクセス・サーバーは、ユーザーのプロファイル情報とグループのメンバーシップ情報をキャッシュします。プロファイル情報には、アクションに必要な情報と認可に必要な情報が両方とも含まれています。たとえば、ポリシーの認可ルールでuserLevel属性が3より大きく設定されているユーザーへのアクセスを許可する場合、アクセス・サーバーのキャッシュにはuserLevel属性が格納されます。
同じように、アクセス・サーバーはユーザーがグループのメンバーであるかどうかに関する情報をキャッシュします。
ユーザーとグループの情報は、アイデンティティ・サーバーや他のアプリケーションを使用して更新できます。ユーザーとグループの情報が変更されると、Oracle Access Managerのキャッシュは最新情報ではなくなります。このため、ユーザー・キャッシュのタイムアウトが重要になります。
ユーザー・キャッシュのタイムアウトは、アクセス・システムに関連する部分のユーザー・プロファイルが変更される平均間隔に比例させてください。ユーザー・プロファイルの関連部分は次のとおりです。
アクションでアクセス・ゲートに返される属性
アクセス制御に使用される属性
アクセス制御に使用される可能性がある動的グループ・メンバーシップの定義に使用される属性
要素の最大数は、アクセス・サーバーのユーザー・キャッシュ・タイムアウト時間内にシステムにアクセスする可能性のあるユーザー数と等しくする必要があります。
ユーザーまたはグループの情報が変更された場合に、アイデンティティ・サーバーを構成してアクセス・サーバーに自動的に通知することができます。アクセス・サーバーのキャッシュは自動的にフラッシュされ、新しい情報によって更新されます。
次の項では、キャッシングの詳細について説明しています。
このキャッシュをオフにする手順は次のとおりです。
ユーザー・キャッシュをオフにする手順
アクセス・システム・コンソールを起動します。
「アクセス・システム構成」に移動して「アクセス・サーバー構成」をクリックします。
「アクセス・サーバー構成」ページが表示されます。このページには、構成済の各アクセス・サーバーの名前、ホストおよびポートが表示されます。
変更するアクセス・サーバーのリンクをクリックします。
「アクセス・サーバーの詳細」ページで「変更」をクリックします。
「アクセス・サーバーの変更」ページが表示されます。
「ユーザー・キャッシュ内の最大要素」の値を-1に設定します。
アイデンティティ・システムとアクセス・システムは、異なるユーザー・キャッシュとグループ・キャッシュを使用します。管理者は、次の操作をすべて実行することができます。
ユーザーの非アクティブ化
ユーザー属性の変更
グループの削除
パスワード・ポリシーの変更
リダイレクトURLの変更
前述のいずれかの操作を実行すると、ディレクトリ・サーバーが新しい情報によって更新されます。ただし、アクセス・サーバーがこれらの変更を認識しない可能性があります。たとえば、Oracle Access Managerでユーザーを非アクティブの状態にした場合、このユーザーは保護されているリソースにアクセスできなくなるため、この変更をアクセス・システムに対しても反映させる必要があります。アイデンティティ・システムの変更をアクセス・サーバーに確実に通知する場合、アクセス・サーバーのユーザー・キャッシュを手動でフラッシュすることができます。または、ユーザーやグループの情報が変更された場合に、アイデンティティ・サーバーを構成してアクセス・サーバーにこの変更を通知することができます。アクセス・サーバーのキャッシュは自動的にフラッシュされ、最新の情報によって置き換えられます。
注意: 動的フィルタや静的メンバーシップを使用してグループのメンバーシップを変更する場合、ユーザー・キャッシュの自動フラッシュは行われません。 |
アクセス・サーバー・キャッシュを自動的にフラッシュする手順
IdentityServer_install_dir/identity/oblix/data/common/basedbparams.xmlファイルに移動します。
このIdentityServer_install_dirは、アイデンティティ・サーバーがインストールされているディレクトリです。
basedbparams.xmlファイルでdoAccessServerFlushパラメータを探し、値をtrueに設定します。
アイデンティティ・サーバーを再起動します。
次に示すように、configureAccessGateコマンドライン・ツールを使用してダミー・アクセス・ゲートを追加します。
configureAccessGate -i IdentityServer_install_dir/identity/AccessServerSDK -t AccessGate
このアクセス・サーバーを使用するすべてのアクセス・ゲートに対して、アクセス管理サービスがオンになっていることを確認してください。
アクセス・システム・コンソールで、「アクセス・システム構成」→「アクセス・ゲート構成」→「すべて」→「実行」をクリックします。該当するアクセス・ゲートのリンクをクリックし、「変更」をクリックします。
必要に応じてアクセス管理サービスをオンに設定します。
次のようにして、アクセス・サーバーのアクセス管理サービスがオンになっていることを確認します。
アクセス・システム・コンソールで、「アクセス・システム構成」→「アクセス・サーバー構成」をクリックします。該当するアクセス・サーバーのリンクをクリックし、「変更」をクリックします。
必要に応じてアクセス管理サービスをオンに設定します。
アクセス・サーバーを再起動します。
アイデンティティ・サーバーのアクセス・ゲートのconfigureAccessGateコマンドを実行します。その後、ファイルObAccessClient.xmlで、インストール中にアクセス・ゲートに対して構成したリスニング・ポートがポート番号に含まれていることを確認します。
アクセス・サーバーの自動キャッシュのフラッシュを実装しない場合、キャッシュ・タイムアウトが発生するまでアクセス・サーバーのキャッシュに古い情報が格納されたままになります。ただし、アクセス・システム・コンソールから、アクセス・サーバーのユーザー・キャッシュとパスワード・ポリシー・キャッシュを手動でフラッシュすることができます。特定のパスワード・ポリシーまたはすべてのパスワード・ポリシーに関する保存情報を、アクセス・サーバー・キャッシュからフラッシュできます。すべてのリダイレクトURLに関するキャッシュ情報をフラッシュすることもできます。
アクセス・サーバーのユーザー・キャッシュを手動でフラッシュする手順
アクセス・システム・コンソールを起動します。
「アクセス・システム構成」→「ユーザー・アクセス構成」に移動し、「ユーザー・キャッシュのフラッシュ」をクリックします。
特定のユーザーのプロファイル情報とグループ情報をフラッシュするには、「ユーザーの選択」をクリックします。
「セレクタ」ページが表示されます。
ユーザーを検索するには、名前を入力して「実行」をクリックします。
検索結果が「セレクタ」の下にリストされます。
「追加」をクリックしてユーザーを選択します。リストされたすべてのユーザーを選択するには、「すべて追加」をクリックします。
ユーザー名が「選択」の下にリストされます。
「完了」をクリックして画面を閉じます。
選択されたユーザーの名前が「ユーザー・キャッシュのフラッシュ」画面に表示されます。
「キャッシュのフラッシュ」をクリックします。
確認を求めるダイアログ・ボックスが表示されます。
「OK」をクリックしてキャッシュされたユーザー情報を削除します。キャッシュされたユーザー情報を削除しない場合、「取消」をクリックします。
パスワード・ポリシー・キャッシュを手動でフラッシュする手順
アクセス・システム・コンソールを起動します。
「アクセス・システム構成」→「共通情報の構成」に移動し、「パスワード・ポリシー・キャッシュのフラッシュ」をクリックします。
パスワード・ポリシーの情報を変更した場合、「指定したパスワード・ポリシーのキャッシュされたすべての情報をフラッシュ」の下にあるリストから該当のポリシーを選択し、「キャッシュのフラッシュ」をクリックします。
パスワード・ポリシー評価順序の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
すべてのパスワード・ポリシーをフラッシュする場合、またはアイデンティティ・システムからパスワード・ポリシーを削除した場合、「キャッシュのフラッシュ」をクリックしてすべてのパスワード・ポリシーのキャッシュされた情報を削除します。
「パスワード・ポリシー管理」画面でリダイレクトURLを変更した場合、「リダイレクトURLのフラッシュ」をクリックします。
パスワード・リダイレクトURLの構成の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
「OK」をクリックして確認します。
ポリシー・マネージャを使用してデータを変更すると、ディレクトリのデータが変更され、キャッシュをフラッシュするようアクセス・サーバーに通知されます。アクセス・サーバーはそのキャッシュをフラッシュし、更新された情報をディレクトリ・サーバーから読み取ります。
レプリケートされたディレクトリ環境では、変更データがマスター・ディレクトリ・サーバーからレプリケートされたディレクトリ・サーバーに渡されます。レプリケートされたディレクトリ・サーバーに変更データが反映されるまで、タイム・ラグが発生します。ポリシー・マネージャがマスター・ディレクトリ・サーバーと通信し、レプリケートされたディレクトリ・サーバーとアクセス・サーバーが通信する場合、アクセス・サーバーはそのキャッシュをフラッシュし、レプリケートされたサーバーに変更データが反映される前にデータを読み取ることがあります。したがって、アクセス・サーバーによって古いデータがキャッシュされる可能性があります。このため、レプリケートされた環境では、古いデータに基づいたアクセス・サーバーによるポリシー評価は不正確なものになることがあります。図5-2に、レプリケートされた環境を示します。
プロセスの概要: レプリケーション
ポリシー・マネージャによってマスター・ディレクトリ・サーバーのデータが変更されます。
ポリシー・マネージャからアクセス・サーバーに対して、キャッシュをフラッシュする信号が送信されます。
アクセス・サーバーはキャッシュをフラッシュし、レプリケートされたディレクトリ・サーバーからデータを読み取ります。
変更データが、マスター・ディレクトリ・サーバーからレプリケートされたディレクトリ・サーバーにレプリケートされます。
ポリシー評価を正確なものにし、アクセス・サーバーが確実に最新データを読み取るようにするには、splTimeoutパラメータを使用します。splTimeoutパラメータを使用すると、変更中の要素に対してタイムアウトを指定できます。この場合、マスター・ディレクトリ・サーバーとレプリケートされたディレクトリ・サーバー間のレプリケーションで発生するタイム・ラグは許容されます。splTimeoutパラメータは、アクセス・システム・コンソールの「アクセス・サーバー構成」ページに指定したキャッシュ・タイムアウトよりも優先されます。
splTimeoutの値は、秒単位で指定します。
splTimeoutパラメータに値を指定しなかった場合、アクセス・サーバーはポリシー・マネージャからフラッシュ信号を受信すると同時にキャッシュをフラッシュしてデータを読み取ります。splTimeoutパラメータは、次の場所に格納されているファイル内に設定されています。
AccessServer_install_dir/access/oblix/apps/common/bin/globalparams.xml
このAccessServer_install_dirは、アクセス・サーバーがインストールされているディレクトリです。
アクセス・ゲートを構成する場合、キャッシュ・タイムアウトの他に、キャッシュ内の最大要素数も指定できます。
各アクセス・ゲートは次の情報をキャッシュします。
認証スキームに関する詳細情報。次のような情報が含まれます。
ユーザーの資格情報を検証する方法
スキームのレベル
認証スキームの作成とそのレベルの詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
リダイレクションURL(存在する場合)
アクセス・ゲートに渡されるすべてのリソース(認証スキーム、URL、操作など)に関する保護情報。次のような情報が含まれます。
認証スキームのキー
保護されたリソースのURL
リソースがシステムで保護されているかどうかの情報
リソースが保護されている場合、そのリソースに必要な認証方法
認可スキームに関する詳細情報。次のような情報が含まれます。
LDAPユーザー属性
ポリシー・ドメインの認可ルールに指定されているパラメータ
認証スキームまたは認可スキームの構成や変更を行う場合、「キャッシュの更新」を選択し、更新されたスキームによってアクセス・ゲート・キャッシュをただちに更新します。
情報がキャッシュされるURLの数は、アクセス・ゲートごとに構成できます。すぐに使用できる構成の場合、URL要素は30秒ごとにタイムアウトします。URLの保護ステータスや認証方法を変更する可能性があるポリシー変更を行う場合、「キャッシュの更新」を選択してアクセス・ゲート・キャッシュをただちに更新します。この場合、アクセス・ゲートのキャッシュ・タイムアウト時間を短く設定する必要はありません。
システムに十分なメモリーがあるという前提の場合、キャッシュされるURLの最大数は、「キャッシュ・タイムアウト」フィールドに指定された時間内にアクセス・ゲートによって処理される個別のURLの数以上に設定する必要があります。
たとえば、http://www.myserver.comとhttp://myserverは個別のURLとして扱います。URLに関する情報がキャッシュに存在しない場合、アクセス・ゲートはアクセス・サーバーに対するリクエストを作成します。アクセス・サーバーから情報をフェッチする場合、ロケール・キャッシュから情報をフェッチするよりも時間がかかりますが、非常に長くかかるということはありません。