Oracle Access Managementのパフォーマンス・チューニング

Oracle Access Managementについて

Oracle Access Managementには、Web周辺のセキュリティ機能およびWebシングル・サインオン、アイデンティティ・コンテキスト、認証および認可、ポリシー管理、テスト、ロギング、監査などを提供するあらゆる範囲のサービスが含まれています。

Oracle Access ManagementはJavaプラットフォームのEnterprise Edition (Jakarta EE)に基づいた、エンタープライズ・レベルのセキュリティ・アプリケーションで、機密情報へのアクセスを制限したり、認証や認可のサービスを一元化します。Oracle Identity Managementスタックの多くの既存のアクセス・テクノロジは、Oracle Access Managementに集約されています。

リリース11.1.2以降のOracle Access Managementには、次のサービスが含まれます。

Oracle Access Management Access Manager (以前はOracle Access Managerという名前のスタンドアロン製品)
Oracle Access Management Identity Federation (以前はOracle Identity Federationという名前のスタンドアロン製品)

これらのサービスの管理の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』を参照してください。

ノート:

Oracle Fusion Middleware 11.1.2よりも前のリリースでは、この章で説明するサービスの一部(Oracle Identity FederationやOracle Secure Token Serviceなど)はスタンドアロン製品として個別にチューニングされていました。

親トピック: Oracle Access Managementのパフォーマンス・チューニング

Oracle Access Managementサービスのパフォーマンスに関する考慮事項

効果的なパフォーマンス・チューニングを行うには、最初のステップは、Oracle Access Management環境内でパフォーマンスに影響を与える可能性がある領域を識別します。この項では、見直す必要がある、いくつかの一般的な領域について説明します。必ず各自のユースケース・シナリオおよびパフォーマンス要件を検討して、適用可能な構成を判断してください。

Oracle Access Managementサービスのチューニングを開始する前に、次の各項と、「主なパフォーマンス分野」で説明した推奨事項に目を通してください。

親トピック: Oracle Access Managementのパフォーマンス・チューニング

現在の環境の理解

Access Managementサービスをチューニングする前に、表11-1で説明されているチューニングの推奨事項を検討してください。

表11-1 現在の環境の理解: チューニングに関する考慮事項

チューニングに関する考慮事項	説明
ユーザー数	全体のユーザー規模、グループ数、メンバーシップ数、属性数、データ型、およびLDAPとデータベースの構成パラメータを把握する必要があります。規模に関するデータを使用したパフォーマンスの向上の詳細は、「パフォーマンス計画」を参照してください。
毎日のアクティビティ使用量	Access Manager: 24時間の間にアクティブになっているユーザー数、および予想されるトラフィックを把握することは重要です。使用量が急激に増加する時間帯がある場合、パフォーマンスの問題を回避するために、追加のチューニングが必要になることがあります。パフォーマンス・データの収集の詳細は、「モニタリング」を参照してください。 Identity Federation: 24時間の間に処理されるフェデレーテッドSSOリクエストの数、および予想されるトラフィックを把握することは重要です。使用量が急激に増加する時間帯がある場合、パフォーマンスの問題を回避するために、追加のチューニングが必要になることがあります。
ハードウェア・リソースおよびトポロジ	負荷の高い環境にデプロイされる対話型アプリケーションの場合と同様、許容されるパフォーマンスを実現するには、サーバーのサイズ設定および構成を適切に行うことが重要です。パフォーマンス・チューニングにおける重要な要素は、使用するハードウェアでボトルネックを回避できるだけの処理能力を提供することです。ハードウェア・リソースの最適化の詳細は、「十分なハードウェア・リソースの確保」を参照してください。
パートナおよびプロトコル	Identity Federationをチューニングする場合、重要な考慮事項は、どのパートナが構成されるか、それらのパートナがどのようにモデル化されるか、およびどのフェデレーション・プロトコルが使用されるかを把握することです。特に、このインスタンスのパートナ数およびそれらに割り当てられる保護ポリシーを把握する必要があります。
JVMおよびガベージ・コレクション	Access Managementサービスの最適なパフォーマンスを実現するには、JVMヒープ・サイズおよびガベージ・コレクションを正しくチューニングする必要があります。ノート: サイズの大きなプラグインまたはCRL (10MB以上)をOAMコンソールUIを介してアップロードする場合、OutOfMemoryの問題に対処できるようにOAMサーバーのヒープ・サイズが適切にチューニングされていることを確認する必要があります。たとえば、OAMログに次のエラー・メッセージが記録されている場合、`-Xmx`と`XX:MaxPermSize`を増やします。 `javax.management.RuntimeErrorException: GC overhead limit exceeded` サーバー・モードで実行中のJVMで、並列、コンカレント・マークおよびスイープGCの各モードを使用します。さらに、ヒープ・サイズを大きい値に設定して、最小と最大には同じ値を使用する`(-Xms=-Xmx)`ことをお薦めします。

親トピック: Oracle Access Managementサービスのパフォーマンスに関する考慮事項

ネットワーク待機時間の制御

ネットワーク全体のパフォーマンスは、システム・パフォーマンスを左右する主要な要因です。ネットワーク・レイテンシが短縮されると、ネットワーク・パフォーマンスが向上する場合があります。

ネットワーク・レイテンシを制御するには、次のことを検討します。

OAMサーバーの近くにデータベース・リポジトリを配置します。OAMサーバーをリモート・サーバーにインストールすると、待機時間が長くなる場合があります。最適なパフォーマンスを維持するには、アプリケーション層とデータベース層の間の待ち時間を5ミリ秒以下に抑えてください。
SSLアクセラレータかロード・バランサをOracle Access Managerシステムの外部に追加することにより、ネットワークのパフォーマンスを改善できます。
Oracle Access ManagerなどのWebベース・アプリケーションのパフォーマンスと可用性を改善する場合、Webサーバーやアプリケーション・サーバーの前方にロード・バランサを配置するのが最善の方法です。ただし、Oracle Access Managerのコンポーネント間にロード・バランサを配置することはお薦めしません。
Access Managerサーバーをディレクトリではなくクライアント・アプリケーションの近くに配置します。

通常操作の場合、WebGateとAccess Managerサーバーとの間のトラフィック量は多くなることがあります。このような管理対象サーバーをアプリケーションの近くに配置することによって、ネットワーク内のトラフィックが多い部分に配置されたデバイス間で、待機時間が短縮される場合があります。

LDAPとネットワークの停止、レプリケーションおよび関連アクティビティに対処するために、Access Managerではキープ・アライブ、フェイルオーバーおよびフェイルバック機能が提供されます。Oracle Access Managerに組み込まれている機能は、多くの場合、ロード・バランサによって提供される同様の機能と同程度か、またはそれらよりも優れています。

ノート:

高速のフェイルオーバーを確保することに加えて、高速のフェイルオーバーの設定を調整します。デフォルト値はOS TCP/IP設定に依存しており、この設定はWebgateが実行されているOSに対して調整する必要があります。

ロード・バランサを使用すると、Access ManagerサーバーのOAP (Oracle Access Protocol)通信情報を仮想化して管理できます。制約を伴う次の要件に対して、Webgateとサーバーとの間でロード・バランサを使用することのメリットを比較する必要があります。

OAP接続は永続的であり、アイドル状態になっている場合でも、構成可能な期間の間はそれらの接続をオープンしておく必要があります。
ロード・バランサが接続を終了する前に、接続をリサイクルするようにWebgateを構成する必要があります。ただし、ロード・バランサがTCPリセットをWebgateとサーバーの両方に送信でき、確実に接続がクリーンアップされる場合は除きます。
ロード・バランサは、各WGのOAP接続を(接続元のIPに応じて)アクティブなAccess Managerサーバー間で均一に分散する必要があります。これを行わなかった場合、ロード・バランシングに失敗する可能性があります。

注意:

制約を伴う前述の要件が満たされなかった場合、Access Managerのパフォーマンスに悪影響を及ぼし、停止につながる可能性があります。

高負荷によるLDAPタイムアウトが、ほとんどないことを確認します。それには、LDAPサーバーに適切にパッチが適用されており、OAM LDAP問合せ(バインド、ユーザー/グループ検索、検索問合せ)をシミュレートする負荷テストが実行されていることを確認する必要があります。負荷によってLDAPタイムアウトが発生すると、OAMサーバーのSSO待機時間が長くなり、OAMサーバーが停止する可能性が高くなります。

一時的な待機時間の増加(たとえば、LDAP問合せの待機時間の増加、Coherence待機時間の増加によるサーバー処理など)は、Webgateの応答時間を長くします。特にピーク負荷時に、受信したユーザー・リクエストを(キューイングまたはスロットルによって)処理するのに十分な容量がWeb層にないと、Web層全体がブロックされ、新しいリクエストを受け付けられない状況が発生することがあります。この場合、エンド・ユーザーは、ログインしてビジネス・アプリケーションにアクセスすることができません。

親トピック: Oracle Access Managementサービスのパフォーマンスに関する考慮事項

DMSパフォーマンス・インストゥルメンテーションの有効化

パフォーマンス・チューニングの目的で、Dynamic Monitoring Service (DMS)パフォーマンス・インストゥルメンテーションを有効にして、機能と運用に関するメトリックの待機時間およびスループットを確認することを検討してください。DMSは、より高い負荷を処理しているコンポーネントや、サービス・リクエストに通常よりも時間がかかっているコンポーネントを特定できます。様々なコンポーネントへのコールの処理にかかる全体的な時間の確認の詳細は、「DMSメトリックの表示」を参照してください。

ノート:

Enterprise Manager Grid Controlを使用している場合は、最も重要なOAMメトリックに基づいてダッシュボード・レポートを作成し、定期的に電子メールで送信します。

親トピック: Oracle Access Managementサービスのパフォーマンスに関する考慮事項

Oracle Access Management Access Managerのチューニング

Oracle Access Management Access Manager (Access Manager)は、重要なアクセス制御サービスを一元化するエンタープライズ・レベルのソリューションであり、認証、認可、Webシングル・サインオン、ポリシー管理、強制エージェント管理、セッション制御、システム監視、レポート、ロギングおよび監査の機能を提供する統合ソリューションです。

Access Managerの使用の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Management Access Managerの概要に関する項を参照してください

Oracle Access Management。

親トピック: Oracle Access Managementのパフォーマンス・チューニング

Access Managerのチューニングに関する基本的な考慮事項

Access Managerの使用状況およびパフォーマンスの問題に応じて、次の基本的なパラメータのチューニングを検討してください。チューニングに関するその他の考慮事項については、「主なパフォーマンス分野」を参照してください。

親トピック: Oracle Access Management Access Managerのチューニング

Web層のチューニング

Access Managerの最適なパフォーマンスを維持するには、Webアプリケーションのサーバーをチューニングする必要があります。この項では、次のチューニング構成について説明します。

Oracle HTTP Serverのチューニング
Oracle HTTP Server (OHS)をチューニングし、Oracle Fusion MiddlewareのWebサーバー・コンポーネントとして、そのパフォーマンスを最適化できます。
Access Manager Webgateのチューニング
OAMエージェントのチューニング

親トピック: Access Managerのチューニングに関する基本的な考慮事項

Oracle HTTP Serverのチューニング

Oracle HTTP Server (OHS)をチューニングし、Oracle Fusion MiddlewareのWebサーバー・コンポーネントとして、そのパフォーマンスを最適化できます。

ノート:

構成例および推奨設定は解説用のものです。各自のユースケース・シナリオを検討し、パフォーマンスの向上が可能な構成オプションを判断してください。

親トピック: Web層のチューニング

Access Manager Webgateのチューニング

Webgateは、Access Managerのすぐに使用できるアクセス・クライアントです。このWebサーバーのアクセス・クライアントは、WebリソースのHTTPリクエストを捕捉して、これらをAccess Managerサーバーに転送します。Access Managerには、様々なWebサーバーのWebgateが同梱されています。

WebgateサーバーからAccess Managerサーバーへの接続数を増やすには、次のパラメータのチューニングを検討します。接続数を増やすことによって、サーバーがより多くの同時リクエストを処理できるようになります。

パラメータ	説明
`Max Connections`	このAccess ManagerエージェントがすべてのAccess Managerサーバーと確立できる最大接続数。
`Maximum Number Of Connections`	Access Managerエージェントが特定のAccess Managerサーバーと確立できる最大接続数。

これらのパラメータの設定の詳細は、『Oracle Access Management管理者ガイド』のエージェントとアプリケーションの登録に関する項を参照してください。

親トピック: Web層のチューニング

OAMエージェントのチューニング

OAMエージェントを登録してから、次のパラメータを推奨値にチューニングします。

パラメータ	推奨事項
`Cache Pragma Header`	`no-cache`のデフォルトを削除し、このフィールドを空にします。
`Cache Control Header`:	`no-cache`のデフォルトを削除し、このフィールドを空にします。
`AAA Timeout Threshold`	デフォルトは-1で、タイムアウトしないことを意味します。これを的確な数値に変更してください。この値が低すぎると、OIMサーバーからの応答を受信する前にソケット接続がクローズされる可能性があります。この値が高すぎると、レスポンスの待機中に接続がハングすることがあります。
Max Number of Connections for Each Server	「サーバー・リスト」の各サーバーで、「接続の最大数」を1から10に変更します。

これらのパラメータを検索するには、次のメニューに移動します: 「OAM 14c管理コンソール」→「SystemConfig」(タブ)→「アプリケーション・セキュリティ」→「SSOエージェント」→(エージェントを検索して選択)。

これらのパラメータの詳細は、『Oracle Access Management管理者ガイド』のコンソールの登録済OAMエージェント構成パラメータの概要に関する項を参照してください。

親トピック: Web層のチューニング

ポリシー・コンポーネントの管理

Access Managerの処理によるオーバーヘッドを制限するには、セキュリティを必要としないすべてのリソースを、保護されていないリソースではなく、除外されたリソースとしてモデル化する必要があります。このようなリソースを、除外されたリソースとしてモデル化することによって、ADFアプリケーションに大きなメリットがもたらされる場合があります。除外されたリソースは、保護されていないリソースのようなリクエストごとの対話ではなく、WebgateとAccess Managerサーバーとの間で1回かぎりの対話を使用します。

詳細は、『Oracle Access Management管理者ガイド』の共有ポリシー・コンポーネントの管理に関する項を参照してください。

最適なパフォーマンスが得られるように認証ポリシーを設計するには、次の作業を行います。

authZで必要なすべての属性のインベントリを取得し、AuthN時にプリフェッチします。
補助リスト内の属性を組み合せて、AuthN時におけるLDAPロードを減らします。

次の点に注意してください。

$user.attr.uidからのユーザーIDの戻り値に対するOAMポリシー・レスポンスを、すべて$user.useridに変更します。これは、前者が認可時にオンデマンドで計算されるのに対し、後者はログイン時に計算されるからです。

OAM_REMOTE_USERは、デフォルトで移入されます。
最適なパフォーマンスが得られるように認可ポリシーを設計するには、次の作業を行います。
- $session namespaceを使用します。認可に使用する属性は、ログイン時に取得してユーザーのOAMセッションに格納する必要があります。これにより、authZの待機時間が一定に保たれ、OAMからレスポンスを得られるようになります。その結果、ユーザーの操作性が向上します。
  
  たとえば、ismemberof、loa、およびその他の属性関連のポリシー・レスポンスを変更することで、authZ時ではなく、認証時に値を取得するようにします。
```
[Authentication Policies]ismemberof -> SESSION -> $user.attr.ismemberof
loa -> SESSION -> $user.attr.loa
uid ->SESSION -> $user.userid

 [Authorization Policies]Responses:
uid: $user.userid
ismemberof: $session.attr.ismemberof
loa: $session.attr.cmsRoles
```
- 属性に関係している認可ポリシーでは、$user.attr namespaceを使用してオンザフライで属性を問い合せるのではなく、$session namespaceに格納した属性を使用します。
- 各ユーザーを明示的に列挙するのではなく、グループに基づいたポリシーを使用します。

親トピック: Access Managerのチューニングに関する基本的な考慮事項

共通設定のチューニング

ドメイン内のすべてのOAMサーバーおよびサービスは、共通の設定を共有しています。これらの設定は、「起動パッド」でチューニングできます。これらの設定の検索方法は、『Oracle Access Management管理者ガイド』の共通設定の管理に関する項を参照してください。

この項では、次の共通設定の値のチューニングについて説明します。

親トピック: Access Managerのチューニングに関する基本的な考慮事項

グローバル・セッション設定

次のパラメータの推奨値:

Session Lifetime = 5m

Maximum Number of Sessionsは、0から8の間で設定します。この設定のデフォルトは8です。通常、デフォルトで十分ですが、この数値はできるだけ低く設定してください。このパラメータを0に設定すると、同時に実行されるセッションの数が無制限になることに留意してください。これはお薦めしません。

これらのパラメータの説明は、『Oracle Access Management管理者ガイド』のグローバル・セッション・ライフサイクル設定に関する項を参照してください。

親トピック: 共通設定のチューニング

デフォルトおよびシステム・アイデンティティ・ストア

LDAPストアは、Access Managerが保持する接続プールによってアクセスされます。アイデンティティ・ストアの定義には、公開されるプール・パラメータが含まれます。Middleware ControlおよびDMSスパイ・サーブレットは、操作ごとの数および待機時間を公開できるため、それらを使用してボトルネックを特定できます。

タイムアウト値(デフォルトでは無制限)を明示的に指定することを検討し、プール内の初期接続数および最大接続数がデプロイメントに適した数になるようにしてください。

高度なチューニングの推奨事項については、unresolvable-reference.html#GUID-A67DC278-35D9-4000-9B8C-A106C2A74F07を参照してください。

これらの設定を検索する方法の詳細は、『Oracle Access Management管理者ガイド』のユーザー・アイデンティティ・ストアの登録設定の定義に関する項を参照してください。

親トピック: 共通設定のチューニング

Access Managerのチューニングに関する高度な考慮事項

Access Managerのチューニングに関する次の考慮事項は、ガイドとして提供されます。必ず各自のユースケース・シナリオを検討して、これらの構成をデプロイメントで使用できるかどうかを判断してください。

親トピック: Oracle Access Management Access Managerのチューニング

Oracle Coherenceのチューニング

Oracle Access Managerは、Oracle Coherenceを使用して、分散インストール内でセッション状態をレプリケートします。Coherenceを使用して、Oracle Access ManagerコンソールとAccess Managerサーバーの間の状態変更を通信します。

この項の内容は、次のとおりです。

最適化間隔の更新

親トピック: Access Managerのチューニングに関する高度な考慮事項

最適化間隔の更新

oam-config.xmlファイルで、OptimizedSessionUpdatesIntervalInMillis要素の値は、「アイドル・タイムアウト」パラメータに構成された値(デフォルトでは15分)より小さくする必要があります。

構成ファイルで、OptimizedSessionUpdatesIntervalInMillis要素は次のようになります。


      <Setting Name="DBSMEConfig" Type="htf:map">    
      <Setting Name="SessionCreationLockAcquirePercentage" Type="xsd:integer">60</Setting>
      <Setting Name="SessionPurgeLockExpiryIntervalSeconds" Type="xsd:long">3000</Setting>  
      <Setting Name="SessionCreationLockExpiryIntervalSeconds" Type="xsd:long">10</Setting>
      <Setting Name="SessionConcurrencyHardLimit" Type="xsd:long">5</Setting>    
      <Setting Name="OptimizedSessionUpdatesIntervalInMillis" Type="xsd:long">180000</Setting>
      </Setting>

ノート:

この構成は、XPath /DeployedComponent/Server/NGAMServer/Profile/Smeの下に置いてください。

構成された間隔に基づいて、認可中のセッション更新が最適化されます。これは、前述の制限内である必要があります。予期しない動作を避けるために、最小間隔値を構成することをお薦めします。ほとんどのケースでは、デフォルト値の3分(180000ミリ秒)で十分です。

親トピック: Oracle Coherenceのチューニング

JavaメッセージBeanのプール・サイズの設定

デフォルトでは、Access Manager Proxyは100個のWebgateリクエストを同時に処理するように設定されます。

必要な場合は、プール設定を調整し、デプロイメントに対するWebgateリクエストの最大ロードを反映することを検討してください。これを行うには、max-beans-in-free-pool要素を適切な値に設定します。

「Web層のチューニング」で説明したWeb層の設定に基づいて、max-beans-in-free-poolの適切な値を計算することもできます。この値には、Max Number of connections (Webgate)、ServerLimit (Oracle HTTP Server)およびNumber of Webgatesを掛け合せたものよりも大きい数を指定する必要があります。

親トピック: Access Managerのチューニングに関する高度な考慮事項

サーバー・キャッシュのチューニング

Access Managerのパフォーマンスを向上させるには、次のサーバー・キャッシュをチューニングします。

アイデンティティ・ストア・キャッシュのチューニング

親トピック: Access Managerのチューニングに関する高度な考慮事項

アイデンティティ・ストア・キャッシュのチューニング

認可ポリシー管理は、ユーザーまたはグループへの権限付与のオーサリングを許可します。管理者は、特定のユーザーまたはグループを選択し、アクセス権を付与または拒否して、特定のアイデンティティ・ストア内を検索できます。検索結果は、Access Manager認可ポリシーのアイデンティティ制約コンポーネントのプリンシパルとして格納されている値など、ユーザーおよびグループの正規識別子を提供します。コンソールには、オリジナルの名前およびアイデンティティ・ストアが表示されます。

パフォーマンスを最大化するには、次のアイデンティティ・ストア・キャッシュの構成設定を見直します。

グループ・メンバーシップ・キャッシュ

グループ・メンバーシップ・キャッシュには、実質的には別のグループのメンバーシップである、間接的なメンバーシップのデータが格納されます。構成可能なパラメータは、エントリの数とエントリ存続時間です。レスポンスに対してチェックされるグループや、レスポンスとしてエクスポートされるグループがデプロイメントに含まれている場合、キャッシュをチューニングする必要があります。このようなグループの例としては、アイデンティティ制約内に設定されるグループなどがあります。

注意: グループ・メンバーシップ・キャッシュは、ループ検出を行うことなく、ネストされたグループのLDAPツリー全体を再帰的に検索することによって、データが移入されます。Access Managerサーバーのパフォーマンスが低下している場合は、このキャッシュを無効にすることを検討してください。
ユーザー属性キャッシュ

ユーザー属性は、一度フェッチされると常にキャッシュされます。認証中の属性のプリフェッチは、アイデンティティ・ストアのSUPPLEMENTAL_RETURN_ATTRIBUTESパラメータの値に属性リストを指定することによって制御されます。

あわせて更新するため、属性のリスト選択をユーザーには要求せず、現在の行で決定している属性値を必要とする場合、追加属性の戻り値が便利です。

ノート:

Authzポリシーで使用されているすべてのLDAP属性条件を、ログイン時に取得してキャッシュする必要があります。これによりauthzの待機時間およびスループットが改善され、LDAP層での負荷が低減されます。

親トピック: サーバー・キャッシュのチューニング

Webgateキャッシュのチューニング

WebGateにより、認証に関する情報と、リソースが保護されているかどうかの情報がキャッシュされます。WebGateキャッシュをチューニングする場合、タイムアウト間隔内で予想される一意のURLの合計数を設定します。デフォルトのURL数は0です。この場合、キャッシュの自動更新は行われず、管理者が手動でキャッシュを更新した場合のみキャッシュがフラッシュされます。これは、一部のシナリオでは優れたパフォーマンスを得られるオプションになりますが、個々のユースケースには適用できない場合があります。

詳細は、『Oracle Access Management管理者ガイド』のOAMエージェント・メトリックの確認に関する項を参照してください。

この項では次のトピックを記載しています:

親トピック: Access Managerのチューニングに関する高度な考慮事項

Webgateキャッシュの概要

Webgateは、パフォーマンスの向上を図るためにリソース、認証、認可に関する様々な情報をキャッシュします。キャッシュされた情報を使用することで、14cサーバーに何度もアクセスして同じ情報をリクエストすることが回避されます。表11-2に示すのは、Webgateがこのような情報を保持するために使用するキャッシュです。

表11-2 Webgateキャッシュのタイプ

キャッシュ・タイプ	説明
認証スキームに対するリソース	このキャッシュは、使用される認証スキームに関する情報を保持します。デフォルト: 100000要素
認証スキーム	このキャッシュは、使用される認証スキームに関する情報を保持します。デフォルト: 25要素通常、「認証スキーム」のキャッシュ要素に必要なメモリーは、1要素ごとに2KB未満です。関連項目: 「キャッシュのタイムアウト値のチューニング」。
認可ポリシーに対するリソース 14c Webgateのみ	このキャッシュは、アクセスするリソースと、関連する認可ポリシーに関する情報を保持します。デフォルト: 100000要素関連項目: 「キャッシュの最大要素数のチューニング」および「キャッシュのタイムアウト値のチューニング」。
認可結果 14c Webgateのみ	このキャッシュは、ユーザー・セッションに関連する認可に関する情報を保持します。デフォルト: 1000要素関連項目: 「認可結果キャッシュのチューニング」。

キャッシュ・タイプ

説明

認証スキームに対するリソース

このキャッシュは、使用される認証スキームに関する情報を保持します。

デフォルト: 100000要素

認証スキーム

このキャッシュは、使用される認証スキームに関する情報を保持します。

デフォルト: 25要素

通常、「認証スキーム」のキャッシュ要素に必要なメモリーは、1要素ごとに2KB未満です。

関連項目: 「キャッシュのタイムアウト値のチューニング」。

認可ポリシーに対するリソース

14c Webgateのみ

このキャッシュは、アクセスするリソースと、関連する認可ポリシーに関する情報を保持します。

デフォルト: 100000要素

認可結果

14c Webgateのみ

このキャッシュは、ユーザー・セッションに関連する認可に関する情報を保持します。

デフォルト: 1000要素

関連項目: 「認可結果キャッシュのチューニング」。

14c Webgateの診断ページについて

このページには、現在有効なキャッシュ構成パラメータについて役に立つ情報が表示されます。また、キャッシュされた要素数、現在までのヒット数とミス数、個々のキャッシュの現在のメモリー使用状況など、キャッシュについてのランタイム情報も表示されます。このページには、次のURLでアクセスします。

http://webserver:port/ohs/modules/webgate.cgi?progid=1

Oracle Webgate 10.1.4.3.0をバンドル・パッチ13 (BP13)にアップグレードすると、「診断」ページの出力は空白ページになります。バンドル・パッチ13以降、「診断」ページはデフォルトで無効です。

このページを有効にするには、Webgate登録ごとに、Webgateのユーザー・パラメータのリストにパラメータと値enableDiagnosticPage=trueを追加します。Webgateインスタンスがすでに登録されている場合は、次の手順を実行します。

「OAM Console」→「システム構成」→「Access Manager」→「SSOエージェント」→「OAMエージェント」に移動し、Webgateプロファイルを検索して選択します。
リストの最後に"User Defined Parameters" : enableDiagnosticPage=trueを追加します。
「適用」をクリックすると、ポップアップ・ウィンドウに新しいアーティファクトが配置された場所が示されます。
OHS構成インスタンスに新しくObAccessClient.xmlをコピーします。
OHSインスタンスを再起動して、「診断」ページが表示されていることを確認します。

ノート:

Webgateのパラメータに対する変更がWebgate上に反映されるのは、次の構成のリフレッシュ後です。14cエージェントの場合、構成がリフレッシュされるデフォルトの間隔は10分です。

キャッシュの最大要素数のチューニング

デフォルトでは、認証スキームに対するリソースと認可ポリシーに対するリソースのキャッシュは100000要素を格納するように作成されます。通常、これらのキャッシュの要素に必要なメモリーは、1要素ごとに1KB未満です。そのため、各キャッシュの要素数が100000とすると、キャッシュに必要な通常のメモリーはそれぞれ100000KB (100MB)となります。

メモリー要件と実際のデプロイメント、使用するWebサーバー、アプリケーションで一意なURLの数を考慮して、キャッシュされる要素の最大数を増減した方がよい場合があります。

ノート:

必要に応じて「最大キャッシュ要素」のパラメータ値を変更してください。この値を-1に設定すると、すべてのWebgateキャッシュが無効になります。

12cと14cのどちらのWebgateでも、最大キャッシュ要素パラメータを変更して、キャッシュされる要素の最大数をチューニングできます。このパラメータを更新するには、Webgateの再起動が必要です。

次のようにして、キャッシュされる要素の最大数をチューニングします。

Oracle Access Managerコンソールで、必要なWebgate登録ページを探して開きます。
必要に応じて「最大キャッシュ要素」のパラメータを設定します。
WebgateのWebサーバーを再起動します。

認可結果キャッシュのチューニング

デフォルトでは、認可結果キャッシュは1000要素を格納するように作成されます。認可結果キャッシュの要素には、ユーザー・セッション識別子、認可ポリシー識別子、処理されたポリシー・レスポンスなど関連する認可結果が格納されます。したがって、認可結果キャッシュの要素は大きくなり、通常でも1要素ごとに2KBのメモリーを必要とします。

メモリー要件と、実際のデプロイメントにおける同時ユーザー・セッション数を考慮して、キャッシュされる要素の数を増やした方がよい場合があります。

次のようにして、キャッシュされる要素の数をチューニングします。

Oracle Access Managerコンソールで、必要な14c Webgate登録ページを探して開きます。
「ユーザー定義パラメータ」で、必要に応じてmaxAuthorizationResultCacheElemsを追加または更新します。
WebgateのWebサーバーを再起動します。

キャッシュのタイムアウト値のチューニング

デフォルトでは、次のキャッシュはタイムアウト値を1800秒つまり30分に設定して作成されます。

認証スキームに対するリソース
認証スキーム
認可ポリシーに対するリソース

これらのキャッシュの要素は失効時間付きで格納され、失効するとキャッシュが強制的にフラッシュされます。

デプロイメントにおける認証スキーム、認証ポリシーおよび認可ポリシーに対する更新頻度を考慮して、デフォルトのタイムアウト値を増減した方がよい場合があります。

次のようにして、キャッシュのタイムアウトをチューニングします。

Oracle Access Managerコンソールで、必要なWebgate登録ページを探して開きます。
必要に応じて「キャッシュ・タイムアウト」のパラメータを設定します。
WebgateのWebサーバーを再起動します。

認可結果キャッシュのタイムアウトのチューニング

デフォルトでは、認可結果キャッシュのタイムアウト値は15秒に設定されます。認可結果キャッシュの要素は失効時間付きで格納され、失効すると強制的にフラッシュされます。タイムアウト値を低くすると、認可結果は短時間だけキャッシュされるようになります。

ユーザー・セッションの平均時間と、ユーザー・セッションが作成される頻度を考慮して、デフォルトのタイムアウト値を変更した方がよい場合があります。他のキャッシュおよびパラメータとは異なり、このパラメータを更新する際にWebgateの再起動は不要です。更新された値は14c Webgateによって動的に取得され、すぐに適用されます。

ノート:

authorizationResultCacheTimeoutを0に設定すると、認可キャッシュが無効になります。

次のようにして、認可結果キャッシュのタイムアウトをチューニングします。

Oracle Access Managerコンソールで、必要な14c Webgate登録ページを探して開きます。
「ユーザー定義パラメータ」で、必要に応じてauthorizationResultCacheTimeoutを追加または更新します。
WebgateのWebサーバーを再起動します。

親トピック: Webgateキャッシュのチューニング

コンポーネント間のネットワーク・トラフィックの削減

WebgateによるOAMサーバー構成のポーリングを使用すると、WebgateとOAMサーバーの間でも、Oracle Access Managerの登録済データ・ストアとOAMサーバーとの間でもトラフィックが削減されます。

手順の概要: WebgateによるOAMサーバー構成のポーリング

Webgateが非アクティブな状態が60秒続くと、その構成情報に対するポーリングの頻度を低下させます。

ポーリング頻度は、パラメータInactiveReconfigPeriodによって決まります。これは、Webgate構成ページで設定されるユーザー定義のパラメータです。InactiveReconfigPeriodの値は分で指定します。Webgateは、10秒以内の再開アクティビティを挟んで、再構成ポーリングを1分に1回ずつ繰り返し実行するようになります。
起動時には、Webgateはブートストラップ構成をチェックし、重要なパラメータが変更されているかどうかを確認します。

これによって、ほとんどの場合再初期化プロセスが不要になり、OAMサーバーからの一時的なロードが削減されます。
WebgateおよびAccessClientの構成は、OAMサーバーにキャッシュされます。

デフォルトのキャッシュ・タイムアウトは59秒です。これは、Apache以外のアクセス・クライアントではシステム動作になんら影響を与えません。Apache WebサーバーでWebgateを使用する場合は、ディレクトリ・サーバーに対する不要なヒットが回避されます。キャッシュのパラメータは、Webgate登録ページで設定できます。
- 「最大キャッシュ要素」は、キャッシュの最大数を設定します(デフォルトは9999)。
- 「キャッシュ・タイムアウト」は、キャッシュ内の任意の要素の最大存続期間を決定します(デフォルト値は59秒です)。

WebgateとOAMサーバー間およびOAMサーバーとデータベース間のオフタイム・ネットワーク・トラフィックを削減する方法は2つあります。

Webgate構成およびAccessClient構成のOAMサーバー・キャッシュのデフォルト構成キャッシュ・タイムアウトの変更(ステップ3で説明)
Webgateによる構成情報ポーリング頻度の変更(次項で説明)

親トピック: Webgateキャッシュのチューニング

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 Access Management管理者ガイド』のWebgate登録の検索に関する項の手順に従って、目的のWebgate登録ページを検索します。
Webgate登録ページで、ユーザー定義パラメータとしてInactiveReconfigPeriodパラメータを追加します。
InactiveReconfigPeriodには、値を分単位で指定します。
Webgate登録ページに変更を適用します。

親トピック: Webgateキャッシュのチューニング

リクエスト・キャッシュ・タイプの変更

デフォルトのリクエスト・キャッシュ・タイプはCOOKIEに設定されています。これは、Cookieを使用して、認証されていないリクエストの状態をキャッシュすることを意味します。

タイプをBASICに変更すると、パフォーマンスが向上する場合がありますが、次のことを考慮する必要があります。認証フローに使用されているサーバーで、認証フローの実行中に障害が発生した場合、そのフローにおけるユーザーの現在の状態は次のリクエストで失われます。これは、ロード・バランサがその状態を別のサーバーに送信するためです。

タイプをFORMに変更すると、アクセス先のURLが長い場合、パフォーマンスが向上する可能性があります。

親トピック: Access Managerのチューニングに関する高度な考慮事項

認証プラグインのチューニング

認証プラグインは、パフォーマンスに影響することがあります。Access Managerのカスタマイズを開発する場合は、パフォーマンスへの影響を最小限に抑えるために、次のことを検討してください:

アクションの実行順序を検討します。
可能なかぎり、プラグインのフットプリントおよび外部の依存関係を最小限に抑えます。

親トピック: Access Managerのチューニングに関する高度な考慮事項

Access Managerの追加のチューニングを必要とする特殊なユースケース

この項では、「Access Managerのチューニングに関する基本的な考慮事項」に加えて、特殊なチューニングが必要になるユースケースについて説明します。

Access Managerセッションの管理

親トピック: Oracle Access Management Access Managerのチューニング

Access Managerセッションの管理

デフォルトでは、特定のユーザーIDに対して同時に確立できるのは、最大8セッションのみです。この制限値を増やすことはできますが、制限値を増やすと機能のセキュリティが低下し、最終的には無防備な状態になることに注意してください。また、機能に関連するパフォーマンス・コストも制限値とともに増加します。そのため、20を超えるユーザー・セッションを同時に確立する必要がある場合は、制限値を0に設定することによって、この機能を無効にすることを検討してください。

親トピック: Access Managerの追加のチューニングを必要とする特殊なユースケース

監査設定

OAMは、多数の監査情報を生成することがあります。業務が最も忙しい時間帯には、OPSS AuditLoaderが情報を監査データベースに移動する速度よりも、OAMが監査情報を生成する速度のほうが速くなります。

SSOがセキュリティ・サービスであることを考慮して、監査フィルタの値をMEDIUMまたはALLに設定することをお薦めします。また、ゼロ・データ損失を回避するために、監査バス・ストップ・ディレクトリに最大サイズ制限が指定されていないこと(maxDirSize=0)を確認します。さらに、業務が最も忙しい時間帯にAuditLoaderに遅延が発生している場合でも、監査データが継続的に監査データベースに移動されていることを監視して確認します。

親トピック: Access Managerの追加のチューニングを必要とする特殊なユースケース

モニター・アカウントの管理

Enterpriseは、自動モニターを使用してエンド・ユーザーの待機時間を測定し、しきい値を超えた場合はアラートを生成します。

次のベスト・プラクティスを使用することをお薦めします。

モニターは、作業が完了したらログアウトする必要があります。これにより、メモリー内にセッションが集積しないようになります。
複数のモニターに同じユーザー資格証明を使用しないでください。これにより、単一のユーザーが短時間に多数のセッションを作成することを回避できます。
定期的にモニター・セッションを削除します。これは、OAMコンソールを介して実行するか、またはASDKを使用してプログラムを記述することにより実行します。また、これによって、モニターに対応するために、セッションの最大数を大きい値に設定する必要もなくなります。
問題が発生した場合には、モニターを頻繁に実行することを避けてください。

通常、モニターは、例外が記録された時(たとえば、ログイン待機時間がしきい値を超えた場合など)に頻繁に実行されるように設定します。特に負荷のピーク時にこのような状況が発生すると、システムにさらに負荷をかけることになり、回避できない障害が生じる可能性を高めます。

親トピック: Access Managerの追加のチューニングを必要とする特殊なユースケース

Kerberos待機時間の問題

デフォルトでは、Kerberos認証にはUDPプロトコルが使用されます。ただし、OAMサーバーとKerberosサーバー間の接続をサブネットに広げる必要がある場合、または業務時間内にパケット損失が増加した場合、UDPは適切に動作しません。このため、UDPではなくTCPを使用するようにKerberosを構成することをお薦めします。

これを実行するには、/etc/krb5.confファイルでudp_preference_limit=1を設定します。

親トピック: Access Managerの追加のチューニングを必要とする特殊なユースケース

REST接続を介したOracle Access Protocolの問題

RESTを介したOracle Access Protocol (OAP)により、HTTPインフラストラクチャを使用してリクエストをルーティングおよびロード・バランシングできます。これは、リリース12.2.1.4.0以降、WebGateで導入された新機能です。負荷がかかると、WebGateログまたはHTTP Serverログ(あるいはその両方)に接続エラーが表示される場合があります。

接続エラーを減らすために、次のベスト・プラクティスをお薦めします:

HTTP Serverに、受信リクエストを受信するのに十分なアイドルまたは予備のサーバー・スレッドがあることを確認します。
OAM WebLogic Serverのwm/OAPOverRestWMワーク・マネージャの容量を増やします。
必要に応じて、HTTP ServerおよびWebLogic Serverに割り当てられるRAMを増やします。

親トピック: Access Managerの追加のチューニングを必要とする特殊なユースケース

Oracle Access Management Identity Federationのチューニング

Oracle Access Management Identity Federation (Identity Federation) 11gR2は、Oracle Access Managerサーバーに組み込まれたアイデンティティ・フェデレーション・サーバーです。すべての構成は、スタンドアロンの11gR1バージョンとは異なり、Oracle Access Manager内で行われます。Identity Federationは、既存のアイデンティティおよびアクセス管理システムとともに迅速にデプロイ可能な、自己完結型の柔軟なマルチプロトコル・フェデレーション・サーバーを提供します。ベンダー、顧客およびビジネス・パートナとの間でアイデンティティを安全に共有でき、アイデンティティや資格証明を追加で維持管理、運用するための追加コストも発生しません。

Oracle Access Management Identity Federationの管理の詳細は、『Oracle Access Management管理者ガイド』のOracle Access ManagementのIdentity Federationの概要に関する項を参照してください。

Identity Federationのチューニングに関する基本的な考慮事項
Identity Federationのチューニングに関する高度な考慮事項
Identity Federationの追加のチューニングを必要とする特殊なユースケース

親トピック: Oracle Access Managementのパフォーマンス・チューニング

Identity Federationのチューニングに関する基本的な考慮事項

次の各項では、Identity Federationのチューニング中にも考慮する必要がある、基本的なチューニング構成について説明します:

親トピック: Oracle Access Management Identity Federationのチューニング

ロード・バランサおよびHTTP Serverのチューニング

Oracle Fusion Middlewareリリース11gR2から、Identity Federationの一部の機能がAccess Managerに埋め込まれています。Identity Federationのパフォーマンスを最適化するには、Access Managerの「Web層のチューニング」で説明した、ロード・バランサおよびHTTP Serverのチューニングに関するガイドラインに従います。

親トピック: Identity Federationのチューニングに関する基本的な考慮事項

SOAP接続のチューニング

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接続の最大数

親トピック: Identity Federationのチューニングに関する基本的な考慮事項

データ層接続のチューニング

LDAPストアは、接続プールによってアクセスされます。アイデンティティ・ストアの定義には、公開されるプール・パラメータが含まれます。「デフォルトおよびシステム・アイデンティティ・ストア」で説明したとおり、Middleware ControlおよびDMSスパイ・サーブレットは、操作ごとの数および待機時間を公開できます。Identity Federationは、RDBMSを使用してセッション・データおよび実行時データを格納します。サーバーは、キャッシュ・メカニズムを使用して実行時のパフォーマンスを向上させます。これにより、最近使用したオブジェクトへの参照をメモリー内に保持できるため、データベースへの読取りアクセスが不要になります。RDBMSでは、非同期書込みおよび削除メカニズムを使用することもできます。

ノート:

通常、次のパラメータは変更する必要はありません。説明を確認し、その調整によってデプロイメントのパフォーマンスが向上するかどうかを判断してください。

RDBMSセッションのキャッシュおよび非同期書込みを最適化するには、表11-3の説明に従ってパラメータを構成します。

表11-3 非同期書込みの設定

パラメータ	説明
`rdbmsasynchronousmanagerinterval`	非同期のスレッド・マネージャに対する実行間隔
`rdbmsasynchronousmanagersleep`	非同期のスレッド・マネージャのスリープ間隔で、実行が発生したかどうかを確認します。
`rdbmsasynchronousqueuesize`	同じタイプのRDBMS操作(セッションの作成、アーティファクトの作成など)が含まれるキューのサイズノート: `rdbmsasynchronousqueuesize`のサイズを正しく設定することは重要です。大きすぎる場合、データベースへの非同期書込みで遅延が発生し、SSO操作が失敗する可能性があります。
`rdbmsasynchronousqueuesleep`	キューがいっぱいの場合に、コール元スレッドがキューに操作の追加をリトライできるまでのスリープ時間
`rdbmsasynchronousqueueretries`	キューに操作の追加を試みる際のリトライ数
`rdbmsasynchronousthreadcore`	RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールでのデフォルトのスレッド数
`rdbmsasynchronousthreadkeepalive`	RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールでの外部スレッドの最大保持時間
`rdbmsasynchronousthreadmax`	RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールでの最大スレッド数 `rdbmsasynchronousthreadmax`をシステムのサイズに基づいて最大システム・ロードに対処するよう調整する必要があります。
`rdbmsasynchronousthreadpolicy`	RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールのスレッド・ポリシー
`rdbmsasynchronousthreadqueuesize`	RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールのスレッド・キューのサイズ

表11-4に、アーティファクトおよび一時キャッシュに対するRDBMSのメモリー・キャッシュ設定を示します。

表11-4 キャッシュ設定

パラメータ	説明
`RDBMS Artifact memory`	RDBMS非同期モジュールとともに使用されるRDBMSアーティファクトのメモリー・キャッシュ設定:
`artifactrdbmscachetimeout`	メモリー・キャッシュでの存続時間
`artifactrdbmsretries`	失敗を返すまでのRDBMSでのエントリ検出の最大リトライ数
`artifactrdbmssleep`	操作の参照をリトライする間のスリープ時間
`RDBMS Memory cache`	RDBMSのメモリー・キャッシュ設定(アーティファクトを除く):
`transientrdbmscachesize`	キャッシュ・サイズ
`transientrdbmscachetimeout`	無効になり、それによってオブジェクトの検索時にRDBMSの参照操作が強制されるまでのキャッシュ内オブジェクトの存続時間
RDBMSクリーン・アップ・スレッドの間隔	期限切れのエントリがOIF DB表から削除されるまでのスレッドのスリープ間隔

親トピック: Identity Federationのチューニングに関する基本的な考慮事項

Identity Federationのチューニングに関する高度な考慮事項

この項では、使用環境に適用できる可能性がある、チューニングに関する高度な推奨事項について説明します。次の推奨事項を確認し、それらの変更によってIdentity Federationデプロイメントが改善されるかどうかを判断してください。

親トピック: Oracle Access Management Identity Federationのチューニング

Oracle Coherenceのチューニング

Access Manager 11gR2に含まれるIdentity Federationは、Oracle Coherenceを使用して、分散インストール内でセッション状態をレプリケートします。詳細は、「Oracle Coherenceのチューニング」を参照してください。

親トピック: Identity Federationのチューニングに関する高度な考慮事項

アイデンティティ・ストアのチューニング

「サーバー・キャッシュのチューニング」の説明に従ってアイデンティティ・ストアをチューニングすることによって、Access Manager 11.1.2.0.0に含まれるIdentity Federationにメリットがもたらされます。

親トピック: Identity Federationのチューニングに関する高度な考慮事項

プロトコル・バインディングのチューニング

この項では、プロトコル・バインディング・オプションについて説明します。

XMLデジタル署名

Identity Federationは、メッセージの真正性、およびメッセージが改ざんされていないことを保証するために、XMLデジタル署名を使用します。

可能であれば、アサーションまたはレスポンス(あるいはその両方)に署名して、変更が加えられるのを防止してください。メッセージにXMLデジタル署名がない場合、アーカイブされる監査済メッセージには、メッセージの真正性および整合性を証明するデータは含まれません。

次の場合、アサーションまたはレスポンス(あるいはその両方)に署名しないようにIdentity FederationまたはSecurity Token Serviceを構成したほうがよいことがあります:
- パフォーマンスを改善する必要がある場合
- SOAP通信に対してSSL認証を行うSSLが有効になっている場合
- XMLデジタル署名を無効にすることが企業のセキュリティ規定に合致している場合
XML暗号化

フェデレーテッド・シングル・サインオンを使用すると、トークンおよび要素レベルの暗号化によって、メッセージ交換の機密性が提供されます。暗号化の使用を無効にすると、Identity Federationの待機時間およびスループットが改善されます。

親トピック: Identity Federationのチューニングに関する高度な考慮事項

ブラウザのシングル・サインオンのPOSTプロファイルおよびアーティファクト・プロファイルのチューニング

SAML仕様で定義されたシングル・サインオン・プロファイルには次の2種類があります。

POSTプロファイル

POSTプロファイルでは、アサーションはユーザーのブラウザを介して遷移します。したがって、アサーションまたはレスポンス(あるいはその両方)に署名して、内容が変更されていないことを保証する必要があります。
アーティファクト・プロファイル

アーティファクト・プロファイルでは、アイデンティティ・プロバイダがIdPのローカル・ストア内のアサーションを参照するランダムな識別子を作成します。(アサーションは、アイデンティティ・プロバイダからサービス・プロバイダへ直接提供されます。)この識別子は、ユーザーのブラウザを介してサービス・プロバイダに提示されます。サービス・プロバイダは、アイデンティティ・プロバイダにアクセスして識別子の参照を解除し、対応するアサーションを取得します。

SPからIdPへのSOAP接続が、SSLサーバー証明書を使用したSSLプロトコルで暗号化されている場合、SPはIdPを認証し、通信内容が改ざんされていないことを証明します。この場合は、トランスポート層でメッセージの真正性および整合性を実現しているため、SAMLのレスポンスおよびアサーションに対するXMLデジタル署名はオプションです。

メッセージにXMLデジタル署名がない場合、アーカイブされる監査済メッセージには、メッセージの真正性および整合性を証明するデータは含まれません。

アーティファクト・プロファイルを使用すると、サービス・プロバイダとアイデンティティ・プロバイダの間で余分なラウンドトリップが発生するため、アーティファクト・プロファイルを使用しないことによって、パフォーマンスが向上する場合があります。

アウトバウンドSOAP接続

親トピック: Identity Federationのチューニングに関する高度な考慮事項

アウトバウンドSOAP接続

OAM Federationは、各種バインディング、中でもSOAPバインディングを使用して、リモートSAMLサーバーと通信できます。OAMは、SOAPプロトコルを使用してリモート・サーバーにメッセージを送信する必要がある場合、接続を直接オープンしてSOAPメッセージを送信します。

次の接続設定を構成できます:

soapmaxconnections - OAM FederationがSOAPメッセージを送信する際にオープンできる同時接続の最大数。

soapmaxconnectionsperhost - OAM FederationがSOAPメッセージを特定のプロバイダに送信する際にオープンできる同時接続の最大数。

soapsockettimeout - データ待機のタイムアウトであるデフォルトのソケット・タイムアウト(SO_TIMEOUT) (ミリ秒単位)。タイムアウト値がゼロの場合、無限タイムアウトとみなされます。

soapconnectiontimeout- 接続が確立されるまでのタイムアウトを設定します。値が0の場合、タイムアウトは使用されません。

前述のプロパティは、WLST cmdを使用して設定できます。たとえば、putLongProperty ("/fedserverconfig/{PropertyName}", {Value})です。

親トピック: ブラウザのシングル・サインオンのPOSTプロファイルおよびアーティファクト・プロファイルのチューニング

Identity Federationの追加のチューニングを必要とする特殊なユースケース

この項では、追加のチューニングによってメリットを得られる可能性がある、いくつかの特殊なユースケースについて説明します。

メッセージへの署名とトークンへの署名

親トピック: Oracle Access Management Identity Federationのチューニング

メッセージへの署名とトークンへの署名

サービス・プロバイダとアイデンティティ・プロバイダとの間のメッセージ交換は、署名される場合があります。リクエストやレスポンスが多くの中間点を通過する場合、メッセージの署名によってセキュリティがさらに強化されます。メッセージの署名を無効にすると、パフォーマンスが向上する場合がありますが、それによるセキュリティ・リスクを他のセキュリティ・メカニズムによって軽減できない場合は、署名を無効にしないでください。

親トピック: Identity Federationの追加のチューニングを必要とする特殊なユースケース

Oracle Access Managementのデータベース・チューニング

この項では、OAMデータベースのチューニング・プロセスについて説明します。

親トピック: Oracle Access Managementのパフォーマンス・チューニング

自動オプティマイザ統計収集

これが実行されることを確認します(AM_SESSION表にデータがあります)。通常、このデータには、作業時間中のデータが含まれます。この表にデータが含まれる時点で実行されるように、自動オプティマイザ統計収集ジョブを構成する必要があります。午前0時またはオフ・ピーク時間に実行されるように構成すると、間違った統計が収集され、OAMサーバーのパフォーマンス低下の原因になる場合があります。

ジョブの詳細を確認するには、次の手順に従ってください。

dbaとして接続して、問合せを実行します。
select * from dba_autotask_client where client_name = 'auto optimizer stats collection'

親トピック: Oracle Access Managementのデータベース・チューニング

構成ユーティリティ・コマンドを使用したAM_SESSION表のパーティション化

デフォルトでは、AM_SESSION表はパーティション化されません。

システムで高負荷が予想される場合は、安定性のためにAM_SESSION表をパーティション化することをお薦めします。また、AM_SESSION表に対する問合せが適切に実行されるように、データベース統計を定期的に収集する必要があります。

次の構成ユーティリティ・コマンドを実行して、AM_SESSION表をパーティション化または非パーティション化します。

java -cp $MW_HOME/idm/oam/server/tools/config-utility/config-utility.jar:$MW_HOME/oracle_common/modules/oracle.jdbc/ojdbc8.jar oracle.security.am.migrate.main.ConfigCommand $DOMAIN_HOME createAMSessionTable /scratch/config.properties

次の行は、構成ユーティリティ・コマンドの実行に必要な他のデフォルト・プロパティとともに、プロパティ・ファイル(/scratch/config.properties)に含める必要があります。

oam.sessionTable.type=<value>

ここで、<value>は次のいずれかにする必要があります。

PARTITIONED - AM_SESSION表のパーティション化
NON-PARTITIONED - パーティション化されていないAM_SESSION表の使用

親トピック: Oracle Access Managementのデータベース・チューニング

ピーク負荷からのリカバリ・メカニズムとしての非アクティブ・セッションのパージ

次に示すのはサンプルREST APIです。

Method: POST Path: https://oam-policy-admin-host:oam-policy-admin-port/oam/services/rest/access/api/v1/sme/purge?allInactiveSessions=true

ノート:

この操作は、メンテナンス・ウィンドウまたは低負荷のウィンドウ(真夜中など)でのみ実行する必要があります。次の条件が満たされていることを確認する必要があります。

AM_SESSION表がパーティション化されています。
当日に高い負荷が確認されています。
数日中に高い負荷が予想されます。

ピーク負荷の予想が1日の中でごく短い期間である場合、この操作を実行しないでください。適切なチューニングを行うことで、パフォーマンスが最適になります。

親トピック: Oracle Access Managementのパフォーマンス・チューニング

11 Oracle Access Managementのパフォーマンス・チューニング

Oracle Access Managementについて

Oracle Access Managementサービスのパフォーマンスに関する考慮事項

現在の環境の理解

ネットワーク待機時間の制御

DMSパフォーマンス・インストゥルメンテーションの有効化

Oracle Access Management Access Managerのチューニング

Access Managerのチューニングに関する基本的な考慮事項

Web層のチューニング

Oracle HTTP Serverのチューニング

Access Manager Webgateのチューニング

OAMエージェントのチューニング

ポリシー・コンポーネントの管理

共通設定のチューニング

グローバル・セッション設定

デフォルトおよびシステム・アイデンティティ・ストア

Access Managerのチューニングに関する高度な考慮事項

Oracle Coherenceのチューニング

最適化間隔の更新

JavaメッセージBeanのプール・サイズの設定

サーバー・キャッシュのチューニング

アイデンティティ・ストア・キャッシュのチューニング

Webgateキャッシュのチューニング

Webgateキャッシュの概要

コンポーネント間のネットワーク・トラフィックの削減

Webgateのポーリング頻度の変更

リクエスト・キャッシュ・タイプの変更

認証プラグインのチューニング

Access Managerの追加のチューニングを必要とする特殊なユースケース

Access Managerセッションの管理

監査設定

モニター・アカウントの管理

Kerberos待機時間の問題

REST接続を介したOracle Access Protocolの問題

Oracle Access Management Identity Federationのチューニング

Identity Federationのチューニングに関する基本的な考慮事項

ロード・バランサおよびHTTP Serverのチューニング

SOAP接続のチューニング

データ層接続のチューニング

Identity Federationのチューニングに関する高度な考慮事項

Oracle Coherenceのチューニング

アイデンティティ・ストアのチューニング

プロトコル・バインディングのチューニング

ブラウザのシングル・サインオンのPOSTプロファイルおよびアーティファクト・プロファイルのチューニング

アウトバウンドSOAP接続

Identity Federationの追加のチューニングを必要とする特殊なユースケース

メッセージへの署名とトークンへの署名

Oracle Access Managementのデータベース・チューニング

自動オプティマイザ統計収集

構成ユーティリティ・コマンドを使用したAM_SESSION表のパーティション化

ピーク負荷からのリカバリ・メカニズムとしての非アクティブ・セッションのパージ