| Oracle® Fusion Middlewareパフォーマンスおよびチューニング・ガイド 11gリリース2 (11.1.2) B71702-01 |
|
 前 |
 次 |
この章では、Oracle Access Management 11gリリース11.1.2インストールを構成するサービスのチューニングおよびサイズ設定のガイドラインを示します。
Oracle Access Managementには、Web周辺のセキュリティ機能およびWebシングル・サインオン、アイデンティティ・コンテキスト、認証および認可、ポリシー管理、テスト、ロギング、監査などを提供するあらゆる範囲のサービスが含まれています。
Oracle Access ManagementはJavaプラットフォームのEnterprise Edition (Java EE)に基づいた、エンタープライズ・レベルのセキュリティ・アプリケーションで、機密情報へのアクセスを制限したり、認証や認可のサービスを一元化します。Oracle Identity Managementスタックの多くの既存のアクセス・テクノロジは、Oracle Access Managementに集約されています。
リリース11.1.2以降のOracle Access Managementには、次のサービスが含まれます。
Oracle Access Management Access Manager (以前はOracle Access Managerという名前のスタンドアロン製品)
Oracle Access Management Security Token Service (以前はOracle Secure Token Serviceという名前のスタンドアロン製品)
Oracle Access Management Identity Federation (以前はOracle Identity Federationという名前のスタンドアロン製品)
Oracle Access Management Mobile and Social (以前はOracle Identity Connectという名前のスタンドアロン製品)
これらのサービスの管理の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』を参照してください。
|
注意: Oracle Fusion Middleware 11.1.2よりも前のリリースでは、この章で説明するサービスの一部(Oracle Identity FederationやOracle Secure Token Serviceなど)はスタンドアロン製品として個別にチューニングされていました。 これらのサービスの11.1.1スタンドアロン・バージョンのチューニングの詳細は、Oracle Fusion Middleware 11gリリース1 (11.1.1.6.0)ドキュメント・ライブラリの『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』を参照してください。 |
効果的なパフォーマンス・チューニングを行うには、まずOracle Access Management環境内でパフォーマンスに影響を与える可能性がある領域を識別します。この項では、見直す必要がある、いくつかの一般的な領域について説明します。必ず各自のユースケース・シナリオおよびパフォーマンス要件を検討して、適用可能な構成を判断してください。
Oracle Access Managementサービスのチューニングを開始する前に、次の各項と、第2章「主なパフォーマンス分野」で説明した推奨事項に目を通してください。
Access Managementサービスをチューニングする前に、次のことを検討してください。
|
ユーザー数 |
全体のユーザー規模、グループ数、メンバーシップ数、属性数、データ型、およびLDAPとデータベースの構成パラメータを把握する必要があります。規模に関するデータを使用したパフォーマンスの向上の詳細は、「パフォーマンス計画」を参照してください。 |
|
毎日のアクティビティ使用量 |
Access Manager: 24時間の間にアクティブになっているユーザー数、および予想されるトラフィックを把握することは重要です。使用量が急激に増加する時間帯がある場合、パフォーマンスの問題を回避するために、追加のチューニングが必要になることがあります。パフォーマンス・データの収集の詳細は、「Oracle Fusion Middlewareの監視」を参照してください。 Identity Federation: 24時間の間に処理されるフェデレーテッドSSOリクエストの数、および予想されるトラフィックを把握することは重要です。使用量が急激に増加する時間帯がある場合、パフォーマンスの問題を回避するために、追加のチューニングが必要になることがあります。 |
|
ハードウェア・リソースおよびトポロジ |
負荷の高い環境にデプロイされる対話型アプリケーションの場合と同様、許容されるパフォーマンスを実現するには、サーバーのサイズ設定および構成を適切に行うことが重要です。パフォーマンス・チューニングにおける重要な要素は、使用するハードウェアでボトルネックを回避できるだけの処理能力を提供することです。ハードウェア・リソースの最適化の詳細は、「十分なハードウェア・リソースの確保」を参照してください。 |
|
パートナおよびプロトコル |
Identity Federationをチューニングする場合、重要な考慮事項は、どのパートナが構成されるか、それらのパートナがどのようにモデル化されるか、およびどのフェデレーション・プロトコルが使用されるかを把握することです。特に、このインスタンスのパートナ数およびそれらに割り当てられる保護ポリシーを把握する必要があります。 |
|
保護されたアプリケーション |
どのアプリケーションが保護されるか、およびその保護がどのようにモデル化されるかを把握することは、チューニング時の重要な考慮事項になります。特に、アプリケーションの保護方法を理解する必要があります。この方法には、WebGate (10g、11gまたは11gPS1)、mod_osso、カスタム・アクセス・ゲートまたはこれらの組合せがあります。 |
|
JVMおよびガベージ・コレクション |
Access Managementサービスの最適なパフォーマンスを実現するには、JVMヒープ・サイズおよびガベージ・コレクションを正しくチューニングする必要があります。詳細は、「Java仮想マシン(JVM)のチューニング」の「ガベージ・コレクションの構成」および「ヒープ・サイズ値の指定」を参照してください。 |
|
システム時刻の同期化 |
プロトコルの対話中に交換されるセキュリティ・トークンは、時間の影響を受けます。問題を回避するには、トポロジ全体のシステム時間を同期する必要があります。Identity Federationではクロック・スキューがサポートされるため、この問題はある程度まで軽減されます。 |
|
メッセージ・プロファイル |
WS-Trustは、様々なメッセージ交換パターンを使用して異なるトークン・タイプをリクエストできる、非常に柔軟なプロトコルです。Oracle Access Management Security Token Serviceをチューニングする場合、メッセージ交換パターンを把握することは、非常に重要な考慮事項になります。 |
ネットワーク全体のパフォーマンスは、システム・パフォーマンスを左右する主要な要因です。ネットワーク待機時間が短縮されると、ネットワーク・パフォーマンスが向上する場合があります。
LDAPとネットワークの停止、レプリケーションおよび関連アクティビティに対処するために、Access Managerではキープ・アライブ、フェイルオーバーおよびフェイルバック機能が提供されます。Oracle Access Managerに組み込まれている機能は、多くの場合、ロード・バランサによって提供される同様の機能と同程度か、またはそれらよりも優れています。
ロード・バランサを使用すると、Access ManagerサーバーのOAP (Oracle Access Protocol)通信情報を仮想化して管理できます。制約を伴う次の要件に対して、Webgateとサーバーとの間でロード・バランサを使用することのメリットを比較する必要があります。
OAP接続は永続的であり、アイドル状態になっている場合でも、構成可能な期間の間はそれらの接続をオープンしておく必要があります。
ロード・バランサが接続を終了する前に、接続をリサイクルするようにWebgateを構成する必要があります。ただし、ロード・バランサがTCPリセットをWebgateとサーバーの両方に送信でき、確実に接続がクリーンアップされる場合は除きます。
ロード・バランサは、各WGのOAP接続を(接続元のIPに応じて)アクティブなAccess Managerサーバー間で均一に分散する必要があります。これを行わなかった場合、ロード・バランシングに失敗する可能性があります。
|
注意: 制約を伴う前述の要件が満たされなかった場合、Access Managerのパフォーマンスに悪影響を及ぼし、停止につながる可能性があります。 |
ネットワーク待機時間を制御するには、次のことを検討します。
SSLアクセラレータかロード・バランサをOracle Access Managerシステムの外部に追加することにより、ネットワークのパフォーマンスを改善できます。
Oracle Access ManagerなどのWebベース・アプリケーションのパフォーマンスと可用性を改善する場合、Webサーバーやアプリケーション・サーバーの前方にロード・バランサを配置するのが最善の方法です。ただし、Oracle Access Managerのコンポーネント間にロード・バランサを配置することはお薦めしません。
Access Managerサーバーをディレクトリではなくクライアント・アプリケーションの近くに配置します。
通常操作の場合、WebGateとAccess Managerサーバーとの間のトラフィック量は多くなることがあります。このような管理対象サーバーをアプリケーションの近くに配置することによって、ネットワーク内のトラフィックが多い部分に配置されたデバイス間で、待機時間が短縮される場合があります。
パフォーマンス・チューニングの目的で、Dynamic Monitoring Service (DMS)パフォーマンス・インスツルメンテーションを有効にして、機能と運用に関するメトリックの待機時間およびスループットを確認することを検討してください。DMSは、より高い負荷を処理しているコンポーネントや、リクエスト処理に通常よりも時間がかかっているコンポーネントを特定できます。様々なコンポーネントへのコールの処理にかかる全体的な時間の確認の詳細は、「DMSメトリックの表示」を参照してください。
Oracle Access Management Access Manager (Access Manager)は、重要なアクセス制御サービスを一元化するエンタープライズ・レベルのソリューションであり、認証、認可、Webシングル・サインオン、ポリシー管理、強制エージェント管理、セッション制御、システム監視、レポート、ロギングおよび監査の機能を提供する統合ソリューションです。
Access Managerの使用の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Management Access Managerの概要に関する項を参照してください。
Access Managerの使用状況およびパフォーマンスの問題に応じて、次の基本的なパラメータのチューニングを検討してください。チューニングに関するその他の考慮事項については、「主なパフォーマンス分野」を参照してください。
Access Managerの最適なパフォーマンスを維持するには、Webアプリケーションのサーバーをチューニングする必要があります。この項では、次のチューニング構成について説明します。
通常、Access Manager WebgateはOracle HTTP Serverにインストールされます。Access Managerのパフォーマンスを最適化するには、各自のユースケース・シナリオを見直し、最適なHTTP Serverのチューニング方法を判断します。
少なくとも、次の表25-1に示すhttpd.confファイルのOracle HTTP Serverパラメータをチューニングすることを検討してください。
表25-1 Webgateに対するOracle HTTP Serverチューニング・パラメータとその説明
| パラメータ | 説明 |
|---|---|
|
|
|
|
|
GETリクエストの受信にかかる合計時間 |
|
|
ここで指定した秒数の間後続のリクエストがないと、HTTP Serverは接続をクローズします。リクエストが受信されると、
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OHSのLockFileディレクティブを、共有ドライブではなくローカル・ディスク上の場所に変更することを検討します。これにより、Oracle HTTP Server ReserveプロキシおよびOracle HTTP Server Webgateサーバー上のロックに関する既知の問題を回避できます。 |
httpd.confファイルの変更の詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のOracle HTTP Serverの構成に関する項を参照してください。
Webgateは、Access Managerでそのまま使用できるアクセス・クライアントです。このWebサーバー・アクセス・クライアントは、WebリソースへのHTTPリクエストを捕捉し、それらをAccess Managerサーバーに転送します。Access Managerには、様々なWebサーバーのWebgateが同梱されています。パフォーマンスを最適化するには、Access ManagerサーバーへのWebgate接続のチューニングを検討してください。
WebgateサーバーからAccess Managerサーバーへの接続数を増やすには、次のパラメータのチューニングを検討します。接続数を増やすことによって、サーバーがより多くの同時リクエストを処理できるようになります。
| パラメータ | 説明 |
|---|---|
|
|
このAccess ManagerエージェントがすべてのAccess Managerサーバーと確立できる最大接続数。 |
|
|
Access Managerエージェントが特定のAccess Managerサーバーと確立できる最大接続数。 |
これらのパラメータの設定の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のエージェントとアプリケーションの登録に関する項を参照してください。
Access Managerの処理によるオーバーヘッドを制限するには、セキュリティを必要としないすべてのリソースを、保護されていないリソースではなく、除外されたリソースとしてモデル化する必要があります。このようなリソースを、除外されたリソースとしてモデル化することによって、ADFアプリケーションに大きなメリットがもたらされる場合があります。除外されたリソースは、保護されていないリソースのようなリクエストごとの対話ではなく、WebgateとAccess Managerサーバーとの間で1回かぎりの対話を使用します。
詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の共有ポリシー・コンポーネントの管理に関する項を参照してください。
LDAPストアは、Access Managerが保持する接続プールによってアクセスされます。アイデンティティ・ストアの定義には、公開されるプール・パラメータが含まれます。Middleware ControlおよびDMSスパイ・サーブレットは、操作ごとの数および待機時間を公開できるため、それらを使用してボトルネックを特定できます。タイムアウト値(デフォルトでは無制限)を明示的に指定することを検討し、プール内の初期接続数および最大接続数がデプロイメントに適した数になるようにしてください。
詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のユーザー・アイデンティティ・ストアの管理に関する項を参照してください。
Access Managerのチューニングに関する次の考慮事項は、ガイドとして提供されます。必ず各自のユースケース・シナリオを検討して、これらの構成をデプロイメントで使用できるかどうかを判断してください。
Oracle Access Managerは、Oracle Coherenceを使用して、分散インストール内でセッション状態をレプリケートします。Coherenceを使用して、Oracle Access ManagerコンソールとAccess Managerサーバーの間の状態変更を通信します。
Oracle Coherenceでは、より大きいサイズのバッファを許可するようにオペレーティング・システム(OS)を構成することを推奨しています。バッファのサイズを2MB以上に増やすことを検討してください。
詳細は、『Oracle Coherence管理者ガイド』のパフォーマンス・チューニングに関する項を参照してください。
デフォルトでは、Access Manager Proxyは100個のWebgateリクエストを同時に処理するように設定されます。必要な場合は、プール設定を調整し、デプロイメントに対するWebgateリクエストの最大ロードを反映することを検討してください。これを行うには、max-beans-in-free-pool要素を適切な値に設定します。このデプロイメント構成は、WebLogic Server管理コンソールから行うことができます。詳細は、「接続プールの構成」を参照してください。
max-beans-in-free-poolの適切な値を選択するには、「Web層のチューニング」で説明したWeb層の設定に基づいて値を計算します。この値には、Max Number of connections (Webgate)、ServerLimit (Oracle HTTP Server)およびNumber of Webgatesを掛け合せたものよりも大きい数を指定する必要があります。
Access Managerのパフォーマンスを向上させるには、次のサーバー・キャッシュをチューニングします。
認可ポリシー管理は、ユーザーまたはグループへの権限付与のオーサリングを許可します。管理者は、特定のユーザーまたはグループを選択し、アクセス権を付与または拒否して、特定のアイデンティティ・ストア内を検索できます。検索結果は、Access Manager認可ポリシーのアイデンティティ制約コンポーネントのプリンシパルとして格納されている値など、ユーザーおよびグループの正規識別子を提供します。コンソールには、オリジナルの名前およびアイデンティティ・ストアが表示されます。
パフォーマンスを最適化するには、次のアイデンティティ・ストア・キャッシュの構成設定を見直します。
グループ・メンバーシップ・キャッシュ
グループ・メンバーシップ・キャッシュには、実質的には別のグループのメンバーシップである、間接的なメンバーシップのデータが格納されます。構成可能なパラメータは、エントリの数とエントリ存続時間です。レスポンスに対してチェックされるグループや、レスポンスとしてエクスポートされるグループがデプロイメントに含まれている場合、キャッシュをチューニングする必要があります。このようなグループの例としては、アイデンティティ制約内に設定されるグループなどがあります。
注意: グループ・メンバーシップ・キャッシュは、ループ検出を行うことなく、ネストされたグループのLDAPツリー全体を再帰的に検索することによって、データが移入されます。Access Managerサーバーのパフォーマンスが低下している場合は、このキャッシュを無効にすることを検討してください。
ユーザー属性キャッシュ
ユーザー属性は、一度フェッチされると常にキャッシュされます。認証中の属性のプリフェッチは、アイデンティティ・ストアのSUPPLEMENTAL_RETURN_ATTRIBUTESパラメータの値に属性リストを指定することによって制御されます。
あわせて更新するため、属性のリスト選択をユーザーには要求せず、現在の行で決定している属性値を必要とする場合、追加属性の戻り値が便利です。
WebGateにより、認証に関する情報と、リソースが保護されているかどうかの情報がキャッシュされます。WebGateキャッシュをチューニングする場合、タイムアウト間隔内で予想される一意のURLの合計数を設定します。デフォルトのURL数は0です。この場合、キャッシュの自動更新は行われず、管理者が手動でキャッシュを更新した場合のみキャッシュがフラッシュされます。これは、一部のシナリオでは優れたパフォーマンスを得られるオプションになりますが、個々のユースケースには適用できない場合があります。
ここでは、次の内容について説明します。
詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOAMエージェント・メトリックの確認に関する項を参照してください。
Webgateは、パフォーマンスの向上を図るためにリソース、認証、認可に関する様々な情報をキャッシュします。キャッシュされた情報を使用することで、11gサーバーに何度もアクセスして同じ情報をリクエストすることが回避されます。表25-2に示すのは、Webgateがこのような情報を保持するために使用するキャッシュです。
表25-2 Webgateキャッシュのタイプ
| キャッシュ・タイプ | 説明 |
|---|---|
|
認証スキームに対するリソース |
このキャッシュは、使用される認証スキームに関する情報を保持します。 デフォルト: 100000要素 |
|
認証スキーム |
このキャッシュは、使用される認証スキームに関する情報を保持します。 デフォルト: 25要素 通常、「認証スキーム」のキャッシュ要素に必要なメモリーは、1要素ごとに2KB未満です。 関連項目: 「キャッシュのタイムアウト値のチューニング」 |
|
認可ポリシーに対するリソース 11g Webgateのみ |
このキャッシュは、アクセスするリソースと、関連する認可ポリシーに関する情報を保持します。 デフォルト: 100000要素 |
|
認可結果 11g Webgateのみ |
このキャッシュは、ユーザー・セッションに関連する認可に関する情報を保持します。 デフォルト: 1000要素 |
11g Webgateの診断ページについて
このページには、現在有効なキャッシュ構成パラメータについて役に立つ情報が表示されます。また、キャッシュされた要素数、現在までのヒット数とミス数、個々のキャッシュの現在のメモリー使用状況など、キャッシュについてのランタイム情報も表示されます。このページには、次のURLでアクセスします。
http://webserver:port/ohs/modules/webgate.cgi?progid=1
|
注意: Webgateのパラメータに対する変更がWebgate上に反映されるのは、次の構成のリフレッシュ後です。11gエージェントの場合、構成がリフレッシュされるデフォルトの間隔は10分です。 |
キャッシュの最大要素数のチューニング
デフォルトでは、認証スキームに対するリソースと認可ポリシーに対するリソースのキャッシュは100000要素を格納するように作成されます。通常、これらのキャッシュの要素に必要なメモリーは、1要素ごとに1KB未満です。そのため、各キャッシュの要素数が100000とすると、キャッシュに必要な通常のメモリーはそれぞれ100000KB(100MB)となります。
メモリー要件と実際のデプロイメント、使用するWebサーバー、アプリケーションで一意なURLの数を考慮して、キャッシュされる要素の最大数を増減した方がよい場合があります。
|
注意: 必要に応じて「最大キャッシュ要素」のパラメータ値を変更してください。この値を-1に設定すると、すべてのWebgateキャッシュが無効になります。 |
10gと11gのどちらのWebgateでも、キャッシュされる要素の最大数をチューニングするには、「最大キャッシュ要素」のパラメータを変更します。このパラメータを更新するには、Webgateの再起動が必要です。
キャッシュされる要素の最大数をチューニングするには:
Oracle Access Managementコンソールで、必要な10gまたは11gのWebgate登録ページを探して開きます。
必要に応じて「最大キャッシュ要素」のパラメータを設定します。
WebgateのWebサーバーを再起動します。
認可結果キャッシュのチューニング
デフォルトでは、認可結果キャッシュは1000要素を格納するように作成されます。認可結果キャッシュの要素には、ユーザー・セッション識別子、認可ポリシー識別子、処理されたポリシー・レスポンスなど関連する認可結果が格納されます。したがって、認可結果キャッシュの要素は大きくなり、通常でも1要素ごとに2KBのメモリーを必要とします。
メモリー要件と、実際のデプロイメントにおける同時ユーザー・セッション数を考慮して、キャッシュされる要素の数を増やした方がよい場合があります。
キャッシュされる要素の数をチューニングするには:
Oracle Access Managementコンソールで、必要な11g Webgate登録ページを探して開きます。
「ユーザー定義パラメータ」で、必要に応じてmaxAuthorizationResultCacheElemsを追加または更新します。
WebgateのWebサーバーを再起動します。
キャッシュのタイムアウト値のチューニング
デフォルトでは、次のキャッシュはタイムアウト値を1800秒つまり30分に設定して作成されます。
認証スキームに対するリソース
認証スキーム
認可ポリシーに対するリソース
これらのキャッシュの要素は失効時間付きで格納され、失効するとキャッシュが強制的にフラッシュされます。
デプロイメントにおける認証スキーム、認証ポリシーおよび認可ポリシーに対する更新頻度を考慮して、デフォルトのタイムアウト値を増減した方がよい場合があります。
キャッシュのタイムアウトをチューニングするには:
Oracle Access Managementコンソールで、必要な10gまたは11gのWebgate登録ページを探して開きます。
必要に応じて「キャッシュ・タイムアウト」のパラメータを設定します。
WebgateのWebサーバーを再起動します。
認可結果キャッシュのタイムアウトのチューニング
デフォルトでは、認可結果キャッシュのタイムアウト値は15秒に設定されます。認可結果キャッシュの要素は失効時間付きで格納され、失効すると強制的にフラッシュされます。タイムアウト値を低くすると、認可結果は短時間だけキャッシュされるようになります。
ユーザー・セッションの平均時間と、ユーザー・セッションが作成される頻度を考慮して、デフォルトのタイムアウト値を変更した方がよい場合があります。他のキャッシュおよびパラメータとは異なり、このパラメータを更新する際にWebgateの再起動は不要です。更新された値は11g Webgateによって動的に取得され、すぐに適用されます。
|
注意: authorizationResultCacheTimeoutを0に設定すると、認可キャッシュが無効になります。 |
認可結果キャッシュのタイムアウトをチューニングするには:
Oracle Access Managementコンソールで、必要な11g Webgate登録ページを探して開きます。
「ユーザー定義パラメータ」で、必要に応じてauthorizationResultCacheTimeoutを追加または更新します。
WebgateのWebサーバーを再起動します。
WebgateによるOAMサーバー構成のポーリングを使用すると、WebgateとOAMサーバーの間でも、Oracle Access Managerの登録済データ・ストアとOAMサーバーとの間でもトラフィックが削減されます。
手順の概要: WebgateによるOAMサーバー構成のポーリング
Webgateが非アクティブな状態が60秒続くと、その構成情報に対するポーリングの頻度を低下させます。
ポーリング頻度は、パラメータInactiveReconfigPeriodによって決まります。これは、Webgate構成ページで設定されるユーザー定義のパラメータです。InactiveReconfigPeriodの値は分で指定します。Webgateは、10秒以内の再開アクティビティを挟んで、再構成ポーリングを1分に1回ずつ繰り返し実行するようになります。
起動時には、Webgateはブートストラップ構成をチェックし、重要なパラメータが変更されているかどうかを確認します。
これによって、ほとんどの場合再初期化プロセスが不要になり、OAMサーバーからの一時的なロードが削減されます。
デフォルトのキャッシュ・タイムアウトは59秒です。これは、Apache以外のアクセス・クライアントではシステム動作になんら影響を与えません。Apache WebサーバーでWebgateを使用する場合は、ディレクトリ・サーバーに対する不要なヒットが回避されます。キャッシュのパラメータは、Webgate登録ページで設定できます。
「最大キャッシュ要素」は、キャッシュの最大数を設定します(デフォルトは9999)。
「キャッシュ・タイムアウト」は、キャッシュ内の任意の要素の最大存続期間を決定します(デフォルト値は59秒です)。
WebgateとOAMサーバー間およびOAMサーバーとデータベース間のオフタイム・ネットワーク・トラフィックを削減する方法は2つあります。
Webgate構成のOAMサーバー・キャッシュのデフォルト構成キャッシュ・タイムアウトの変更(ステップ3で説明)
Webgateによる構成情報ポーリング頻度の変更(次項で説明)
WebgateとOAMサーバーの間、およびOAMサーバーとデータベースの間のオフタイム・ネットワーク・トラフィックを削減する方法の1つは、InactiveReconfigPeriodパラメータを使用してWebgateのポーリング頻度を変更することです。
デフォルト値は1分です。Webgateが非アクティブな状態(たとえば、認証リクエストが処理されないなど)が60秒を超えて続くと、構成情報に対するポーリングの頻度が低下します。Webgateは、10秒以内の再開アクティビティを挟んで、再構成ポーリングを1分に1回ずつ繰り返し再開するようになります。
-2に設定すると、Webgateはポーリングを行いません。
0より大きい値に設定すると、指定した間隔でポーリングが実行されます。
-1に設定し、Webgateの非アクティブな状態が1分間続くと、Webgateはポーリングを停止します。Webgateがアクティブな状態に戻ると、構成ポーリングが再開されます。
たとえば、OAMサーバーにより、共有シークレットの値がディレクトリから10分間隔で読み取られ、キャッシュに格納されて、Webgateに戻されます。アイドル状態で、Webgateは、InactiveReconfigPeriod値を使用してOAMサーバーから共有シークレットを読み取ります。この値が設定されていない場合、更新された共有シークレットの値が10分後に戻されますが、Webgateは、1分間隔で共有シークレット(構成)の値についてOAMサーバーをポーリングします。
『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のWebgate登録の検索に関する項の手順に従って、目的のWebgate登録ページを検索します。
Webgate登録ページで、ユーザー定義パラメータとしてInactiveReconfigPeriodパラメータを追加します。
InactiveReconfigPeriodには、値を分単位で指定します。
Webgate登録ページに変更を適用します。
デフォルトのリクエスト・キャッシュ・タイプはCOOKIEに設定されています。これは、Cookieを使用して、認証されていないリクエストの状態をキャッシュすることを意味します。
タイプをBASICに変更すると、パフォーマンスが向上する場合がありますが、次のことを考慮する必要があります。認証フローに使用されているサーバーで、認証フローの実行中に障害が発生した場合、そのフローにおけるユーザーの現在の状態は次のリクエストで失われます。これは、ロード・バランサがその状態を別のサーバーに送信するためです。
タイプをFORMに変更すると、アクセス先のURLが長い場合、パフォーマンスが向上する可能性があります。
認証プラグインは、パフォーマンスに影響することがあります。Access Managerのカスタマイズを開発する場合は、パフォーマンスへの影響を最小限に抑えるために、次のことを検討してください。
アクションの実行順序を検討します。
可能なかぎり、プラグインのフットプリントおよび外部の依存関係を最小限に抑えます。
この項では、「Access Managerのチューニングに関する基本的な考慮事項」に加えて、特殊なチューニングが必要になるユースケースについて説明します。
デフォルトでは、特定のユーザーIDに対して同時に確立できるのは、最大8セッションのみです。この制限値を増やすことはできますが、制限値を増やすと機能のセキュリティが低下し、最終的には無防備な状態になることに注意してください。また、機能に関連するパフォーマンス・コストも制限値とともに増加します。そのため、20を超えるユーザー・セッションを同時に確立する必要がある場合は、制限値を0に設定することによって、この機能を無効にすることを検討してください。
詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のAccess Managerセッションの管理に関する項を参照してください。
Oracle Access Management Identity Federation (Identity Federation) 11gR2は、Oracle Access Managerサーバーに組み込まれたアイデンティティ・フェデレーション・サーバーです。すべての構成は、スタンドアロンの11gR1バージョンとは異なり、Oracle Access Manager内で行われます。Identity Federationは、既存のアイデンティティおよびアクセス管理システムとともに迅速にデプロイ可能な、自己完結型の柔軟なマルチプロトコル・フェデレーション・サーバーを提供します。ベンダー、顧客およびビジネス・パートナとの間でアイデンティティを安全に共有でき、アイデンティティや資格証明を追加で維持管理、運用するための追加コストも発生しません。
Oracle Access Management Identity Federationの管理の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Management Identity Federationの概要に関する項を参照してください。
次の項では、Identity Federationのチューニング中にも考慮する必要がある、基本的なチューニング構成について説明します。
Oracle Fusion Middlewareリリース11gR2から、Identity Federationの一部の機能がAccess Managerに埋め込まれています。Identity Federationのパフォーマンスを最適化するには、Access Managerの「Web層のチューニング」で説明した、ロード・バランサおよびHTTP Serverのチューニングに関するガイドラインに従います。
Identity Federationは、Security Assertion Markup Language (SAML)リクエストの送信およびSAMLレスポンスの受信に、Simple Object Access Protocol (SOAP)を使用します。パフォーマンスを最適化するには、次のSOAP接続を構成します。
Identity FederationおよびSecurity Token Serviceで同時にオープンできるSOAP接続の最大合計数
Identity FederationおよびSecurity Token Serviceで特定のリモート・サーバーに対して同時にオープンできるSOAP接続の最大数
LDAPストアは、接続プールによってアクセスされます。アイデンティティ・ストアの定義には、公開されるプール・パラメータが含まれます。第25.3.1.3項で説明したとおり、Middleware ControlおよびDMSスパイ・サーブレットは、操作ごとの数および待機時間を公開できます。Identity Federationは、RDBMSを使用してセッション・データおよび実行時データを格納します。サーバーは、キャッシュ・メカニズムを使用して実行時のパフォーマンスを向上させます。これにより、最近使用したオブジェクトへの参照をメモリー内に保持できるため、データベースへの読取りアクセスが不要になります。さらに、RDBMSに対する非同期書込みおよび削除メカニズムがあります。
|
注意: 通常、次のパラメータは変更する必要はありません。説明を確認し、その調整によってデプロイメントのパフォーマンスが向上するかどうかを判断してください。 |
RDBMSセッションのキャッシュおよび非同期書込みを最適化するには、表25-3の説明に従ってパラメータを構成します。
表25-3 非同期書込みの設定
| パラメータ | 説明 |
|---|---|
|
|
非同期のスレッド・マネージャに対する実行間隔 |
|
|
非同期のスレッド・マネージャのスリープ間隔で、実行が発生したかどうかを確認します。 |
|
|
同じタイプのRDBMS操作(セッションの作成、アーティファクトの作成など)が含まれるキューのサイズ 注意: |
|
|
キューがいっぱいの場合に、コール元スレッドがキューに操作の追加をリトライできるまでのスリープ時間 |
|
|
キューに操作の追加を試みる際のリトライ数 |
|
|
RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールでのデフォルトのスレッド数 |
|
|
RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールでの外部スレッドの最大保持時間 |
|
|
RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールでの最大スレッド数
|
|
|
RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールのスレッド・ポリシー |
|
|
RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールのスレッド・キューのサイズ |
表25-4に、アーティファクトおよび一時キャッシュに対するRDBMSのメモリー・キャッシュ設定を示します。
表25-4 キャッシュ設定
| パラメータ | 説明 |
|---|---|
|
RDBMS非同期モジュールとともに使用されるRDBMSアーティファクトのメモリー・キャッシュ設定: |
|
|
|
メモリー・キャッシュでの存続時間 |
|
|
失敗を返すまでのRDBMSでのエントリ検出の最大リトライ数 |
|
|
操作の参照をリトライする間のスリープ時間 |
|
RDBMSのメモリー・キャッシュ設定(アーティファクトを除く): |
|
|
|
キャッシュ・サイズ |
|
|
無効になり、それによってオブジェクトの検索時にRDBMSの参照操作が強制されるまでのキャッシュ内オブジェクトの存続時間 |
|
RDBMSクリーン・アップ・スレッドの間隔 |
期限切れのエントリがOIF DB表から削除されるまでのスレッドのスリープ間隔 |
この項では、使用環境に適用できる可能性がある、チューニングに関する高度な推奨事項について説明します。次の推奨事項を確認し、それらの変更によってIdentity Federationデプロイメントが改善されるかどうかを判断してください。
Access Manager 11gR2に含まれるIdentity Federationは、Oracle Coherenceを使用して、分散インストール内でセッション状態をレプリケートします。詳細は、「Oracle Coherenceのチューニング」を参照してください。
「サーバー・キャッシュのチューニング」の説明に従ってアイデンティティ・ストアをチューニングすることによって、Access Manager 11.1.2.0.0に含まれるIdentity Federationにメリットがもたらされます。
この項では、プロトコル・バインディング・オプションについて説明します。
XMLデジタル署名
Identity Federationは、メッセージの真正性、およびメッセージが改ざんされていないことを保証するために、XMLデジタル署名を使用します。
可能であれば、アサーションまたはレスポンス(あるいはその両方)に署名して、変更が加えられるのを防止してください。メッセージにXMLデジタル署名がない場合、アーカイブされる監査済メッセージには、メッセージの真正性および整合性を証明するデータは含まれません。
次の場合、アサーションまたはレスポンス(あるいはその両方)に署名しないようにIdentity FederationまたはSecurity Token Serviceを構成したほうがよいことがあります。
パフォーマンスを改善する必要がある場合
SOAP通信に対してSSL認証を行うSSLが有効になっている場合
XMLデジタル署名を無効にすることが企業のセキュリティ規定に合致している場合
XML暗号化
フェデレーテッド・シングル・サインオンを使用すると、トークンおよび要素レベルの暗号化によって、メッセージ交換の機密性が提供されます。暗号化の使用を無効にすると、Identity Federationの待機時間およびスループットが改善されます。
SAML仕様で定義されたシングル・サインオン・プロファイルには次の2種類があります。
POSTプロファイル
POSTプロファイルでは、アサーションはユーザーのブラウザを介して遷移します。したがって、アサーションまたはレスポンス(あるいはその両方)に署名して、内容が変更されていないことを保証する必要があります。
アーティファクト・プロファイル
アーティファクト・プロファイルでは、アイデンティティ・プロバイダがIdPのローカル・ストア内のアサーションを参照するランダムな識別子を作成します。(アサーションは、アイデンティティ・プロバイダからサービス・プロバイダへ直接提供されます。)この識別子は、ユーザーのブラウザを介してサービス・プロバイダに提示されます。サービス・プロバイダは、アイデンティティ・プロバイダにアクセスして識別子の参照を解除し、対応するアサーションを取得します。
SPからIdPへのSOAP接続が、SSLサーバー証明書を使用したSSLプロトコルで暗号化されている場合、SPはIdPを認証し、通信内容が改ざんされていないことを証明します。この場合は、トランスポート層でメッセージの真正性および整合性を実現しているため、SAMLのレスポンスおよびアサーションに対するXMLデジタル署名はオプションです。
メッセージにXMLデジタル署名がない場合、アーカイブされる監査済メッセージには、メッセージの真正性および整合性を証明するデータは含まれません。
アーティファクト・プロファイルを使用すると、サービス・プロバイダとアイデンティティ・プロバイダの間で余分なラウンドトリップが発生するため、アーティファクト・プロファイルを使用しないことによって、パフォーマンスが向上する場合があります。
Oracle Access Management Security Token Service (Security Token Service)は、アイデンティティおよびセキュリティ・コンテキストのシームレスな伝播を可能にすることによって、アプリケーションとWebサービスとの間の信頼を仲介する一元的なメカニズムを提供します。
Security Token Serviceの管理の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Management Security Token Serviceの概要に関する項を参照してください。
次の項では、Security Token Serviceのチューニング中にも考慮する必要がある、基本的なチューニング構成について説明します。
Security Token Serviceのパフォーマンスを最適化するには、Access Managerの「Web層のチューニング」で説明した、ロード・バランサおよびHTTP Serverのチューニングに関するガイドラインに従います。
Security Token Serviceは、Security Assertion Markup Language (SAML)リクエストの送信およびSAMLレスポンスの受信に、Simple Object Access Protocol (SOAP)を使用します。パフォーマンスを最適化するには、次のSOAP接続を構成します。
同時にオープンできるSOAP接続の最大合計数
特定のリモート・サーバーに対して同時にオープンできるSOAP接続の最大数
Security Token Serviceは、RDBMSを使用して実行時データを格納します。サーバーは、キャッシュ・メカニズムを使用して実行時のパフォーマンスを向上させます。これにより、最近使用したオブジェクトへの参照をメモリー内に保持できるため、データベースへの読取りアクセスが不要になります。さらに、RDBMSに対する非同期書込みおよび削除メカニズムがあります。第25.4.1.3項を参照し、表25-3および表25-4に記載されているチューニング・パラメータを確認してください。これらのパラメータは、Security Token Serviceに対しても設定する必要があります。
また、LDAP資格証明の検証がSecurity Token Serviceの検証テンプレート内で有効になったときに、Security Token ServiceからLDAP接続が作成されるため、次のパラメータを使用して、そのLDAPインスタンスへの接続をチューニングする必要があります。
LDAP非アクティブ時間を設定します。これにより、LDAP接続がアクティブでないために削除されるまでプールに保持しておく期間をSecurity Token Serviceに指示します。
長期的には、非アクティブの状態が長く続いたためにLDAPサーバーが接続をクローズすることがあります。チェックしないままだと、これがエラーの原因となり、パフォーマンスに影響を与える可能性があります。
LDAP読取りタイムアウトを設定します。LDAPサーバーは応答しなくなることがありますが、その場合、スレッド/ユーザーはレスポンスまたはエラーを待つことになります。
サーバーが応答していないときにエラーを長時間待つことがないよう、Security Token ServiceでLDAP接続に対する読取りタイムアウト・プロパティを設定します。読取りタイムアウトの時間内にLDAPサーバーが応答しない場合は、エラーが生成されます。Security Token Serviceは、接続をクローズし、新しい接続をオープンして、LDAPコマンドを再発行します。
高可用性(HA)LDAPフラグを設定します。
STSがHAモードでデプロイされたLDAPサーバーと統合されている場合、STSの構成の際に、LDAPサーバーがHAモードであることを指定する必要があります。
この項では、使用環境に適用できる可能性がある、チューニングに関する高度な推奨事項について説明します。次の推奨事項を確認し、それらの変更によってSecurity Token Serviceデプロイメントが改善されるかどうかを判断してください。
Security Token Serviceのパフォーマンスを最適化するには、WS-Securityポリシーを構成する際に、次の推奨事項について検討します。
Integrity、ConfidentialityおよびRequiredElementsアサーションを最適に使用します。
セキュリティ・バインディング・プロパティを最適に使用します。
TransportBindingをSymmetricBinding上で使用します。SymmetricBindingはAsymmetricBindingの前に検討する必要があります。
WSプロバイダのトークンを暗号化しないようにします。
Oracle Access Management Mobile and Social (Mobile and Social)は、保護されているリソースへのアクセスを必要とするユーザーと、リソースを保護するバックエンドのアイデンティティ管理サービスおよびアクセス管理サービスの間の新しい中間サービスです。Mobile and Socialには簡易なクライアント・ライブラリが用意されており、開発者はこれを使用して、機能豊富な認証、認可およびアイデンティティ機能を登録済アプリケーションに簡単に追加できます。バックエンドでは、Mobile and Socialのプラガブルなアーキテクチャにより、システム管理者は、ユーザーがインストールしたソフトウェアを更新しなくても、アイデンティティ管理サービスおよびアクセス管理サービスを追加、変更および削除できます。
次の項では、Mobile and Socialのチューニング中にも考慮する必要がある、基本的なチューニング構成について説明します。
Mobile and Socialには、Access Manager SDKコンポーネントを使用してOracle Access Managementサーバーに接続する、そのまま使用可能なOracle Access Management認証サービス・プロバイダが含まれます。Mobile and Socialを最適化するには、第25.3項「Oracle Access Management Access Managerのチューニング」の説明に従ってAccess Managerをチューニングすることを検討してください。
Access Managerの構成パラメータに加えて、Mobile and Socialの構成パラメータを1つチューニングする必要があります。
表25-5 Mobile and Socialのチューニング・パラメータ
| パラメータ | 説明 |
|---|---|
|
|
Access Managementサーバーに対して提供される接続の最大数を構成するには、次の手順を実行します。
注意: このパラメータには、Access ManagerでWebGateエージェントの最大接続数として定義したものと同じ値を設定する必要があります。異なる値を設定した場合は、Access Managerサーバーの設定が優先されます。 |
Mobile and Socialのユーザー・プロファイル・サービスは、IDSおよびlibOVDを使用してユーザーのリポジトリに接続します。本番デプロイメントに合わせてチューニングできる、IDSおよびlibOVDに関する2つの構成パラメータを次に示します。これらのパラメータは、Mobile and Social管理コンソールから変更できます。
表25-6 ユーザー・プロファイル・サービス・プロバイダのチューニング・パラメータ
| パラメータ | 説明 |
|---|---|
|
接続プールの初期サイズ |
カテゴリ: LDAPアダプタ・プロパティ デフォルト値: 5 推奨事項: デフォルト値を使用します。 |
|
接続プールの最大サイズ |
カテゴリ: LDAPアダプタ・プロパティ デフォルト値: 10 推奨事項: Oracle Virtual Directory LDAPアダプタのLDAP接続プールのサイズをチューニングし、LDAPアダプタを積極的に使用するOracle Virtual Directoryリスナーに構成されているスレッドの総数以上になるようにします。 |
libOVDの構成パラメータの詳細は、第24章「Oracle Virtual Directoryのパフォーマンス・チューニング」を参照してください。
