1. パフォーマンスのチューニング・ガイド
  2. Oracle IdentityおよびAccess Management
  3. Oracle Access Managementのパフォーマンス・チューニング

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

この章では、Oracle Access Management 14cリリース14.1.2.0.0インストールを構成するサービスのチューニングおよびサイズ設定のガイドラインを示します。

親トピック: Oracle Identity and 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 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など)はスタンドアロン製品として個別にチューニングされていました。

親トピック: 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をチューニングする場合、重要な考慮事項は、どのパートナが構成されるか、それらのパートナがどのようにモデル化されるか、およびどのフェデレーション・プロトコルが使用されるかを把握することです。特に、このインスタンスのパートナ数およびそれらに割り当てられる保護ポリシーを把握する必要があります。

保護されたアプリケーション

どのアプリケーションが保護されるか、およびその保護がどのようにモデル化されるかを把握することは、チューニング時の重要な考慮事項になります。特に、アプリケーションの保護方法を理解する必要があります。この方法には、WebGate (10g、11gまたは11gPS1)、mod_osso、カスタム・アクセス・ゲートまたはこれらの組合せがあります。

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アプリケーションのサーバーをチューニングする必要があります。この項では、次のチューニング構成について説明します。

親トピック: 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に変更します。

これらのパラメータを検索するには、次のようにします。「OAM11g Admin」コンソール→「SystemConfig」(タブ)→「Access Managerの設定」→「ssoAgents」→「OAM」エージェント→(エージェントを検索し選択)

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

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

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

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

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

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

  • authZで必要なすべての属性のインベントリを取得し、AuthN時にプリフェッチします。

  • 補助リスト内の属性を組み合せて、AuthN時におけるLDAPロードを減らします。

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

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

    OAM_REMOTE_USERは、デフォルトで移入されます。

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

    • $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に格納した属性を使用します。

    • 各ユーザーを明示的に列挙するのではなく、グループに基づいたポリシーを使用します。

共通設定のチューニング

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

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

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

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

Session Lifetime = 5m

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

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

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

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

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

チューニングに関する高度な推奨事項の詳細は、「データ層接続のチューニング」を参照してください。

これらの設定を検索する方法の詳細は、『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サーバーの間の状態変更を通信します。

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

最適化間隔の更新

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ミリ秒)で十分です。

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認可ポリシーのアイデンティティ制約コンポーネントのプリンシパルとして格納されている値など、ユーザーおよびグループの正規識別子を提供します。コンソールには、オリジナルの名前およびアイデンティティ・ストアが表示されます。

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

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

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

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

  • ユーザー属性キャッシュ

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

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

    ノート:

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

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

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

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

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

Webgateキャッシュの概要

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

<<<AccessClientsも使用>>>

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

キャッシュ・タイプ 説明

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

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

デフォルト: 100000要素

認証スキーム

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

デフォルト: 25要素

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

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

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

11g Webgateのみ

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

デフォルト: 100000要素

関連項目: 「キャッシュの最大要素数のチューニング」および「キャッシュのタイムアウト値のチューニング」。

認可結果

11g Webgateのみ

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

デフォルト: 1000要素

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

11g 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上に反映されるのは、次の構成のリフレッシュ後です。11gエージェントの場合、構成がリフレッシュされるデフォルトの間隔は10分です。

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

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

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

ノート:

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

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

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

  1. コンソールで、必要な10gまたは11gのWebgate登録ページを探して開きます。

  2. 必要に応じて「最大キャッシュ要素」のパラメータを設定します。

  3. WebgateのWebサーバーを再起動します。

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

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

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

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

  1. コンソールで、必要な11gのWebgate登録ページを探して開きます。

  2. 「ユーザー定義パラメータ」で、必要に応じてmaxAuthorizationResultCacheElemsを追加または更新します。

  3. WebgateのWebサーバーを再起動します。

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

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

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

  • 認証スキーム

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

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

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

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

  1. コンソールで、必要な10gまたは11gのWebgate登録ページを探して開きます。

  2. 必要に応じて「キャッシュ・タイムアウト」のパラメータを設定します。

  3. WebgateのWebサーバーを再起動します。

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

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

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

ノート:

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

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

  1. コンソールで、必要な11gのWebgate登録ページを探して開きます。

  2. 「ユーザー定義パラメータ」で、必要に応じてauthorizationResultCacheTimeoutを追加または更新します。

  3. WebgateのWebサーバーを再起動します。

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

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

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

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

    ポーリング頻度は、パラメータInactiveReconfigPeriodによって決まります。これは、Webgate構成ページで設定されるユーザー定義のパラメータです。InactiveReconfigPeriodの値は分で指定します。Webgateは、10秒以内の再開アクティビティを挟んで、再構成ポーリングを1分に1回ずつ繰り返し実行するようになります。

  2. 起動時には、Webgateはブートストラップ構成をチェックし、重要なパラメータが変更されているかどうかを確認します。

    これによって、ほとんどの場合再初期化プロセスが不要になり、OAMサーバーからの一時的なロードが削減されます。

  3. WebgateおよびAccessClientの構成は、OAMサーバーにキャッシュされます。

    デフォルトのキャッシュ・タイムアウトは59秒です。これは、Apache以外のアクセス・クライアントではシステム動作になんら影響を与えません。Apache WebサーバーでWebgateを使用する場合は、ディレクトリ・サーバーに対する不要なヒットが回避されます。キャッシュのパラメータは、Webgate登録ページで設定できます。

    • 「最大キャッシュ要素」は、キャッシュの最大数を設定します(デフォルトは9999)。

    • 「キャッシュ・タイムアウト」は、キャッシュ内の任意の要素の最大存続期間を決定します(デフォルト値は59秒です)。

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

  • Webgate構成およびAccessClient構成のOAMサーバー・キャッシュのデフォルト構成キャッシュ・タイムアウトの変更(ステップ3で説明)

  • 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サーバーをポーリングします。

構成ポーリング頻度を変更する手順

  1. 『Oracle Access Management管理者ガイド』のWebgate登録の検索に関する項の手順に従って、目的のWebgate登録ページを検索します。

  2. Webgate登録ページで、ユーザー定義パラメータとしてInactiveReconfigPeriodパラメータを追加します。

  3. InactiveReconfigPeriodには、値を分単位で指定します。

  4. Webgate登録ページに変更を適用します。

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

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

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

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

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

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

  • アクションの実行順序を検討します。

  • 可能なかぎり、プラグインのフットプリントおよび外部の依存関係を最小限に抑えます。

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

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

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

Access Managerセッションの管理

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

監査設定

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

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

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

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

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

  1. モニターは、作業が完了したらログアウトする必要があります。これにより、メモリー内にセッションが集積しないようになります。

  2. 複数のモニターに同じユーザー資格証明を使用しないでください。これにより、単一のユーザーが短時間に多数のセッションを作成することを回避できます。

  3. 定期的にモニター・セッションを削除します。これは、OAMコンソールを介して実行するか、またはASDKを使用してプログラムを記述することにより実行します。また、これによって、モニターに対応するために、セッションの最大数を大きい値に設定する必要もなくなります。

  4. 問題が発生した場合には、モニターを頻繁に実行することを避けてください。

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

Kerberos待機時間の問題

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

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

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を増やします。

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の概要」を参照してください。

親トピック: 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のチューニングに関するガイドラインに従います。

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

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

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デプロイメントが改善されるかどうかを判断してください。

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

Oracle Coherenceのチューニング

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の待機時間およびスループットが改善されます。

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

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

  • POSTプロファイル

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

  • アーティファクト・プロファイル

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

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

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

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

アウトバウンド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})です。

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

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

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

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

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

チューニング

(Security Token Service)は、アイデンティティおよびセキュリティ・コンテキストのシームレスな伝播を可能にすることによって、アプリケーションとWebサービスとの間の信頼を仲介する一元的なメカニズムを提供します。

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

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

Security Token Serviceのチューニングに関する基本的な考慮事項

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

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

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

Security Token Serviceのパフォーマンスを最適化するには、Access Managerの「Web層のチューニング」で説明した、ロード・バランサおよびHTTP Serverのチューニングに関するガイドラインに従います。

アウトバウンドSOAP接続のチューニング

Security Token Serviceは、Security Assertion Markup Language (SAML)リクエストの送信およびSAMLレスポンスの受信に、Simple Object Access Protocol (SOAP)を使用します。パフォーマンスを最適化するには、次のSOAP接続を構成します。

  • 同時にオープンできるSOAP接続の最大合計数

  • 特定のリモート・サーバーに対して同時にオープンできるSOAP接続の最大数

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

Security Token Serviceは、RDBMSを使用して実行時データを格納します。サーバーは、キャッシュ・メカニズムを使用して実行時のパフォーマンスを向上させます。これにより、最近使用したオブジェクトへの参照をメモリー内に保持できるため、データベースへの読取りアクセスが不要になります。さらに、RDBMSに対する非同期書込みおよび削除メカニズムがあります。「データ層接続のチューニング」を参照し、表11-3および表11-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ポリシーのチューニング

Security Token Serviceのパフォーマンスを最適化するには、WS-Securityポリシーを構成する際に、次の推奨事項について検討します。

  • Integrity、ConfidentialityおよびRequiredElementsアサーションを最適に使用します。

  • セキュリティ・バインディング・プロパティを最適に使用します。

  • TransportBindingをSymmetricBinding上で使用します。SymmetricBindingはAsymmetricBindingの前に検討する必要があります。

  • WSプロバイダのトークンを暗号化しないようにします。

Oracle Access Management Mobile and Socialのチューニング

Oracle Access Management Mobile and Social (Mobile and Social)は、保護されているリソースへのアクセスを必要とするユーザーと、リソースを保護するバックエンドのアイデンティティ管理サービスおよびアクセス管理サービスの間の新しい中間サービスです。Mobile and Socialには簡易なクライアント・ライブラリが用意されており、開発者はこれを使用して、機能豊富な認証、認可およびアイデンティティ機能を登録済アプリケーションに簡単に追加できます。バックエンドでは、Mobile and Socialのプラガブルなアーキテクチャにより、システム管理者は、ユーザーがインストールしたソフトウェアを更新しなくても、アイデンティティ管理サービスおよびアクセス管理サービスを追加、変更および削除できます

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

Mobile and Socialのチューニングに関する基本的な考慮事項

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

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

Access Management認証サービス・プロバイダのチューニング

Mobile and Socialには、Access Manager SDKコンポーネントを使用してサーバーに接続する、そのまま使用可能な認証サービス・プロバイダが含まれます。Mobile and Socialを最適化するには、「Oracle Access Management Access Managerのチューニング」の説明に従ってAccess Managerをチューニングすることを検討してください。

Access Managerの構成パラメータに加えて、Mobile and Socialの構成パラメータを1つチューニングする必要があります。

表11-5 Mobile and Socialのチューニング・パラメータ

パラメータ 説明

OAM_SERVER_x_MAX_CONN

Access Managementサーバーに対して提供される接続の最大数を構成するには、次のステップを実行します。

  1. Access Manager 11g R2コンソールで、「システム構成」タブをクリックし、左パネルの「Mobile and Social」を選択します

  2. 認証サービス・プロバイダで、目的のAccess Managerサービス・プロバイダを選択します

  3. パフォーマンス要件にあわせて、OAM_SERVER_x_MAX_CONNの値を適切に変更します。

  4. 変更内容を保存します。

ノート: このパラメータには、Access ManagerでWebGateエージェントの最大接続数として定義したものと同じ値を設定する必要があります。異なる値を設定した場合は、Access Managerサーバーの設定が優先されます。

ユーザー・プロファイル・サービス・プロバイダのチューニング

Mobile and Socialのユーザー・プロファイル・サービスは、IDSおよびlibOVDを使用してユーザーのリポジトリに接続します。本番デプロイメントにあわせてチューニングできる、IDSおよびlibOVDに関する2つの構成パラメータを次に示します。これらのパラメータは、Mobile and Socialリモート・コンソールから変更できます。

表11-6 ユーザー・プロファイル・サービス・プロバイダのチューニング・パラメータ

パラメータ 説明

接続プールの初期サイズ

カテゴリ: LDAPアダプタ・プロパティ

デフォルト: 5

推奨事項: デフォルト値を使用します。

接続プールの最大サイズ

カテゴリ: LDAPアダプタ・プロパティ

デフォルト: 10

推奨事項: Oracle Virtual Directory LDAPアダプタのLDAP接続プールのサイズをチューニングし、LDAPアダプタを積極的に使用するOracle Virtual Directoryリスナーに構成されているスレッドの総数以上になるようにします。

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

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

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

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

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

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

  1. dbaとして接続して、問合せを実行します。

  2. 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のパフォーマンス・チューニング