ヘッダーをスキップ
Oracle Application Serverベスト・プラクティス・ガイド
10g（10.1.4.0.1）
B31976-02
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

2 Oracle Access Manager

この章では、Oracle Access Managerのベスト・プラクティスについて説明します。この章の内容は次のとおりです。

2.1 一般的なベスト・プラクティス

この項では、Oracle Access Managerの一般的なベスト・プラクティスについて説明します。この項の内容は次のとおりです。

2.1.1 複数環境にOracle Access Managerをデプロイしてサービスの停止時間を最小限に抑える

Oracle Access Managerは通常、少なくとも次の4つの異なる環境にデプロイします。

  • 開発: 初期の開発と構成を行う環境で、ソフトウェアの新しいパッチやバージョンの適用もこの環境で行われます。

  • 統合: 一般的には、アプリケーションの統合をテストおよび検証するために制御された環境です。

  • QA（または本番前）: パフォーマンス、フェイルオーバーおよび冗長性という特性が、本番環境とほぼ同じに構成された環境です。この環境を使用すると、本番で想定する動作をテストしたり、トラブルシューティング時に本番環境で生じた問題を再現できます。

  • 本番

    ロールアウト時およびアップグレード時に、本番環境でのサービスの停止時間を最小限に抑えるには、これらの環境を明確に区分します。ベスト・プラクティスは、すべての環境をOracle Access Managerソフトウェアの同じパッチ・レベルに正確に維持することで不整合を回避し、環境間での動作の相違が生じる可能性を最小限に抑えることです。

実装の詳細


関連項目:

『Oracle Access Managerデプロイメント・ガイド』の第1章「容量計画」

2.1.2 Oracle Access ManagerのAccess ServerとIdentity Serverを専用ハードウェアにデプロイして信頼性を向上させる

Oracle Access ManagerのAccess ServerとIdentity Serverは、別々の専用ハードウェアで実行することをお薦めします。たとえば、ユーザーが15,000人以内の標準的なデプロイでは、Identity ServerとAccess Serverの実行にそれぞれ2台ずつ、合計4台のサーバーが使用されます。Webサーバーの各ペアの前にはIP交換技術を配置し、ロード・バランシングとフェイルオーバーを実現します。

実装の詳細


関連項目:

『Oracle Access Managerデプロイメント・ガイド』の第1章「容量計画」

2.1.3 構成データとポリシー・データを別々のディレクトリに格納してデプロイおよびアップグレードの柔軟性を高める

実現可能であれば、Oracle Access Managerの構成データとポリシー・データは、ユーザーおよびグループ・データとは別のディレクトリに格納します。これによって、アップグレード時の柔軟性が向上し、ユーザーおよびグループ・ディレクトリへの影響が最小化されます。通常、ユーザーおよびグループ・ディレクトリは企業ディレクトリとして共有されるため、ワークフロー・ドリブン型プロセスが企業ディレクトリに大きな負荷をかける場合、構成データとポリシー・データを分離すると特に効果的です。また、論理的なディレクトリ・インスタンスを別々に構成することで、各ディレクトリを個別にチューニングおよび管理でき、全体のパフォーマンスを向上させることもできます。

ハードウェアまたはトポロジ関連の問題が原因でディレクトリを別々にできない場合は、最低でも専用の接尾辞を作成して、そこにOracle Access Managerの構成データとポリシー・データを保持する必要があります。

実装の詳細


関連項目:

『Oracle Access Managerデプロイメント・ガイド』の第2章「パフォーマンスのチューニング」

2.1.4 ドメイン・コントローラを直接ポイントして潜在的なデータ非一貫性の問題を回避する

Microsoft Active Directory環境にデプロイするときは常に、ドメイン・コントローラを直接ポイントして、潜在的なデータ非一貫性の問題を回避するようにしてください。

ユーザーおよびグループ・ディレクトリとしてMicrosoft Active Directoryを使用するときは、DNSエイリアスではなく、ドメイン・コントローラを直接ポイントしていることを確認してください。これによって、一時的な非一貫性によって生じる問題が回避されます。たとえば、このやり方によって、動的DNSまたはラウンド・ロビンのエイリアス機能が、接続先を低速なリモート・サーバーまたは古いデータを持つサーバーに変更する可能性を回避できます。Active Directory環境で高可用性を実装するには、各ドメイン・コントローラをディレクトリ接続として構成し、Oracle Access Managerの読取りおよび書込みパフォーマンスをチューニングします。

この推奨事項は、サブドメインが複数あるActive Directoryフォレストにも適用されます。そのためには、ルート・ドメインに加えてサブドメインのそれぞれに別々のディレクトリ・プロファイルを作成し、各サブドメインが適切なドメイン・コントローラ・サーバー（複数可)をポイントするように構成してください。

実装の詳細


関連項目:

『Oracle Access Manager IDおよび共通管理ガイド』の付録A「Active Directoryへのデプロイ」

2.1.5 Microsoft Active Directoryへの接続時はADSIではなくLDAP over SSLを使用する

Windows上でMicrosoft Active Directoryに対してOracle Access Managerをデプロイする場合は、ADSIとLDAP over SSLのどちらの使用がより適切かを検討することが重要です。通常、特にトランザクション・ボリュームが大きい環境では、ADSIよりもLDAP over SSLの方がパフォーマンスおよびスケーラビリティに優れています。また、LDAP over SSLを使用すると、Oracle Access Manager（Access Server、Identity ServerおよびPolicy Manager）を特定のActive Directoryインスタンスに依存させることができます。一方、ADSIを使用する場合は、Oracle Access Managerの接続先となる特定のActive Directoryインスタンスがその場で決定されます。使用可能なすべてのActive Directoryドメイン・コントローラの全体的な応答やパフォーマンスが著しく異なる場合は、このようなインスタンスの選択が望ましくない場合があります。

実装の詳細


関連項目:

『Oracle Access Manager IDおよび共通管理ガイド』の付録A「Active Directoryへのデプロイ」

2.1.6 Microsoft Active Directory上へのデプロイ時にActive Directoryの適切な構成パラメータを微調整してパフォーマンスを最適化する

Microsoft Active Directory環境でデプロイする場合は、Active Directoryの構成パラメータを適切に設定して、Oracle Access Managerの全体的なパフォーマンスを最適化することが重要です。表2-1に、最も関連のあるActive Directory構成パラメータの一覧を示します。

表2-1 Active Directoryの構成パラメータ

Active Directoryの構成パラメータ 説明 デフォルト値 Oracle Access Managerへの影響

MaxActiveQueries

1台のドメイン・コントローラで同時に実行可能なLDAP検索操作の最大数を指定します。この制限数に達すると、LDAPサーバーからビジー・エラーが返されます。

注意: この制御には、MaxPoolThreads値との間に誤った相互作用があります。MaxPoolThreadsはプロセッサごとの制御であるのに対して、MaxActiveQueriesでは絶対値が定義されます。Windows Server 2003以降、MaxActiveQueriesは適用されなくなりました。Windows Server 2003バージョンのNtdsutil.exeではMaxActiveQueriesを設定できません。

20

すべてのサービス・スレッドでの同時検索操作を可能にするため、この値はOracle Access Manager内のサービス・スレッドの合計数よりも大きく指定する必要があります。

Oracle Access Manager内のサービス・スレッドの合計数は、ID ServerおよびAccess Server内のスレッド数と、Policy ManagerをホストするWebサーバー内のスレッド数の合計です。

MaxConnections

1台のドメイン・コントローラで同時に受入れ可能なLDAP接続の最大数を指定します。この制限数に達したドメイン・コントローラに対して接続が行われると、別の接続が解除されます。

5000

この値は、Oracle Access ManagerでActive Directoryドメイン・コントローラとの間に確立される接続数以上に指定する必要があります。

MaxConnIdleTime

LDAPサーバーで接続を閉じるまで待機する、クライアントの最大アイドル時間を秒単位で指定します。接続のアイドル時間が指定値を超えると、LDAPサーバーからLDAP切断通知が返されます。

900秒

Oracle Access Managerで最大セッション時間が設定されている場合は、それより少しでも大きい値を指定することはできません。

MaxPageSize

各オブジェクトのサイズにかかわらず、1回の検索結果で返されるオブジェクトの最大数を制御する値を指定します。このオブジェクト数を超える可能性のある検索を実行するには、クライアントでページ検索制御を指定する必要があります。これにより、返される結果がMaxPageSize値以下のグループにグループ分けされます。つまり、MaxPageSizeは1回の検索結果で返されるオブジェクト数を制御します。

1,000

この値は、任意のOracle Access Managerコンポーネントによる検索リクエストで返されるエントリ数よりも大きく指定する必要があります。

Oracle Access Managerコンポーネントでは、次の2つの場合に検索操作が実行されます。

  • ユーザーが、他のユーザーまたはグループ、およびその他のエンティティに関する検索をリクエストしたとき

  • Oracle Access Managerコンポーネントで、リクエストの処理中に構成データの内部検索が実行されたとき

空白でも検索は可能ですが（一般的にシステム内のすべてのユーザー・エンティティが返される検索）、その場合は、システム内のユーザー数よりも大きい値が指定されます。

このようなユーザー検索が一般的に制限されている場合や、この種類のリクエストを誰も実行しない場合、この値はOracle Access Managerの構成データにある次の2つのノードの下の最大ノード数より大きくする必要があります。

  • obapp=PSC,o=Oblix,<config_base>

  • obcontainerId=workflowInstances,o=Oblix, ,<config_base>

MaxPoolThreads

ドメイン・コントローラでネットワーク入出力のリスニング専用に指定する、プロセッサごとの最大スレッド数。この値によって、LDAPリクエストで同時に動作できるプロセッサごとの最大スレッド数も決定されます。

プロセッサごとに4スレッド

ID ServerまたはAccess Serverで単一のプロセッサ・サーバーを実行している場合は、Oracle Access Managerによって確立される接続数よりも大きい値を指定する必要があります。これにより、すべての操作をドメイン・コントローラで同時に実行できます。

MaxQueryDuration

ドメイン・コントローラで1回の検索を実行できる最大秒数。この制限に達すると、ドメイン・コントローラからtimeLimitExceededエラーが返されます。長時間かかる検索では、ページ検索制御を指定する必要があります。

120秒

このドメイン・コントローラをポイントするディレクトリ・プロファイルのデータベース・インスタンスで指定されている時間制限値よりも大きい値を指定する必要があります。そうしないと、データベース・インスタンス自体で指定されている時間制限に達する前に、Active DirectoryからOracle Access Managerに対してtimeLimitExceededエラーが送信される場合があります。

実装の詳細


関連項目:

『Oracle Access Manager IDおよび共通管理ガイド』の付録A「Active Directoryへのデプロイ」

2.1.7 環境のサイズ指定とチューニングによる本番へのデプロイのサポート

本番環境にOracle Access Managerをデプロイする前に、綿密かつ詳細な負荷テストとベンチマーク分析を実行する必要があります。これによって、システム全体の動作の高度なチューニングと予測が可能になります。

パフォーマンス値に基づいて、パフォーマンスをチューニングします。たとえば、キャッシュ設定、タイムアウト値、ディレクトリ接続数などを変更したり、Identity ServerまたはAccess Server上のスレッド数を増やすことができます。

実装の詳細


関連項目:

パフォーマンス結果に基づいてこれらのパラメータを設定する方法の詳細は、『Oracle Access Managerデプロイメント・ガイド』の第2章「パフォーマンスのチューニング」を参照してください。

2.1.8 専用のWebサーバーに管理インタフェースをホストして環境を保護する

Oracle Access Managerの管理インタフェースのホストには、内部用の高度にセキュアなWebサーバーを1台または2台、専用に用意するのがベスト・プラクティスです。管理インタフェースは、IDシステム・コンソールとアクセス・システム・コンソールで構成されます。このベスト・プラクティスは、アプリケーションWebサーバーに障害が発生した場合に、認証システムおよび認可システムの保護に役立ちます。

実装の詳細


関連項目:

『Oracle Access Managerデプロイメント・ガイド』の第1章「容量計画」

2.1.9 コンポーネント間でSSLトランスポートを使用することによる環境のセキュア化

本番環境では、簡易モードまたは証明書モードを使用して、Oracle Access Managerコンポーネント間のすべてのトランスポートを、SSL暗号化トランスポートでセキュアにします。イントラネットおよびエクストラネットの通信はすべて、暗号化する必要があります。

簡易モードまたは証明書モードでSSLを有効化するときは、WebGate、AccessGateおよびWebPassをホストするサーバーだけでなく、Access ServerまたはIdentity Serverをホストするサーバーのクロックの絶対的な時間差を、1分以内に調整する必要があります。夏時間やタイムゾーンでも同様に、クロック間の時間差をGMTで1分以内にする必要があります。Network Time Protocol（NTP）を使用して、サーバーのクロックを確実に同期化させることをお薦めします。

実装の詳細


関連項目:

『Oracle Access Manager IDおよび共通管理ガイド』の第8章「トランスポート・セキュリティのモード変更」

2.1.10 監査証跡をデータベースに格納して監査データの利便性を最大限に高める

可能であれば、Oracle Access Managerのすべての監査データの記録および格納にデータベースを使用します。これによって監査情報が保護されるだけでなく、監査証跡やレポートの生成が容易になります。

実装の詳細


関連項目:

『Oracle Access Manager IDおよび共通管理ガイド』の第10章「ロギング」

2.1.11 環境管理を簡略化する手順の採用

次に示すようないくつかの手順を採用することで、Oracle Access Manager環境の管理を簡略化できます。

  • すべての環境で、ファイル・システムのレイアウトを標準化します。たとえば、すべての環境で、Oracle Access Manager固有のファイルはすべて、同じディレクトリ・パスに配置します。

  • 実現可能であれば、すべての環境で、Webサーバーとディレクトリ・サーバーは、同じバージョンを使用します。

  • /customディレクトリを作成し、すべてのカスタム・コードをそこに格納します。/customディレクトリは、Oracle Access Managerコンポーネントのインストール・ディレクトリ内には作成しないでください。Oracle Access Managerコンポーネントの再インストールまたは削除時には、すべてのサブディレクトリが削除されるため、/customディレクトリを別にしておくことは重要です。

  • 最重要手順として、環境に対して変更やカスタマイズを行った場合は、すべてドキュメント化しておきます。

実装の詳細


関連項目:

『Oracle Access Managerアップグレード・ガイド』の第1章「アップグレードの概要と計画」

2.2 アクセス・システムのベスト・プラクティス

この項では、アクセス・システムのベスト・プラクティスについて説明します。この項の内容は次のとおりです。

2.2.1 IP検証、HTTPSおよびセキュアなCookieを使用してCookie再生攻撃のリスクを軽減する

IP検証を常時有効化することで、Cookie再生攻撃のリスクを軽減することをお薦めします。リバース・プロキシ・トポロジを使用してデプロイする場合など、例外が必要なときは、許可されたIPアドレスのみを例外リストに含めるようにしてください。IP検証は絶対に無効化しないでください。

Cookie再生攻撃のリスクを回避するには、HTTPSを介してコンテンツをセキュアにデプロイすることもできます。これによって、不正なクライアントによるObSSOCookieの盗聴を防止できます。また、フォーム、基本、外部の各チャレンジ・メソッドのチャレンジ・パラメータにパラメータssoCookie:secureを指定することで、認証時に設定されたObSSOCookieがSSL経由でのみ送信可能になります。これによって、ObSSOCookieが非セキュアなWebサーバーに返信されなくなります。このパラメータを設定するには、保護対象のすべてのWebサーバーを、SSL対応として構成する必要があります。SSL対応のWebサーバーは、SSL非対応のWebサーバーへのシングル・サインオンを実行しません。ブラウザは、SSL対応Webサーバーから取得したセキュアなCookieを、同じドメイン内のSSL非対応Webサーバーに返しません。

実装の詳細


関連項目:

『Oracle Access Managerアクセス管理ガイド』の第5章「ユーザー認証の構成」

2.2.2 ネストされたグループを認可に使用しないことでグループ・メンバーシップのパフォーマンスを向上させる

デフォルトでは、Access Serverは、静的、動的およびネストされたグループのメンバーシップをチェックして認可を決定します。ネストされたグループの場合、メンバーシップの評価には極端に高いコストがかかります。ネストされたグループを使用しない場合は、ネストされたグループのメンバーシップ評価を無効にするとパフォーマンスが向上します。ネストされたグループのメンバーシップ評価を無効にするには、globalparams.xmlファイルのTurnOffNestedGroupEvaluationパラメータを手動でTrueに設定します。

実装の詳細


関連項目:

『Oracle Access Managerデプロイメント・ガイド』の第2章「パフォーマンスのチューニング」

2.2.3 認可フィルタのかわりに動的グループを構成して認可管理を簡略化する

一般的には、認可ルールの指定には、認可フィルタではなく動的グループを使用してください。動的グループを使用することで、フィルタ（グループの仮想メンバーの決定）の管理と、認可ルールの管理を分離できます。これによって、認可済ロールの管理を、アクセス・ポリシーの構成担当者とは別のクラスの管理者に委譲できます。また、グループ管理によって、認可ルールのフィルタでは不可能な、変更の追跡と変更の承認が可能になります。

実装の詳細


関連項目:

『Oracle Access Managerアクセス管理ガイド』の第5章「ユーザー認証の構成」

2.2.4 ObMyGroupsを使用する場合のパフォーマンスの考慮事項

特殊なObMyGroupsアクション値の使用が、アクセス・システムとアプリケーションをさらに統合し、ログイン・ユーザーにロールベースの情報を提供するための強力なアプローチとなる場合があります。特に、表示するメニュー項目や機能を決定するために、特定のユーザーが所属するグループをアプリケーションで認識する必要がある場合などは、このアプローチが有効です。

認証または認可アクションとしてObMyGroupsを使用する場合は、ユーザー・グループ・メンバーシップの解決によって、LDAPディレクトリやAccess Serverのシステム、さらにはアクセス対象となるWebサーバーおよびアプリケーションで生じる可能性のあるパフォーマンスの影響を考慮する必要があります。

通常、Access Serverの観点からは、ユーザー/グループの評価はコストのかかる操作です。これらは常に、適格なLDAPフィルタを使用して構成することを強くお薦めします。たとえば、obmygroups:ldap:///o=company,c=us??sub?(group_type=role)のように入力します。

検索対象グループの数によっては、ObMyGroupsの処理にかなりの時間がかかる場合があります。ObMyGroupsは、認可アクションよりも認証ルールで指定することをお薦めします。また可能であれば、アクションをCookieにして、同じWebサーバーの他のアプリケーションで追加料金なしでデータを利用できるようにしてください。ObMyGroupsを認可ルールで使用する場合は、可能なかぎり少ないリソース（URL）で使用するように制限してください。

ロールアウト前に、ObMyGroupsアクションに関する具体的な使用例を含めて、完全なパフォーマンス・テストを設計し、実行することを強くお薦めします。これにより、特定環境での実際のパフォーマンスおよび応答時間のベンチマーク、調整および理解が可能になります。

実装の詳細


関連項目:

  • 『Oracle Access Managerアクセス管理ガイド』の第5章「ユーザー認証の構成」

  • 『Oracle Access Managerデプロイメント・ガイド』の第2章「パフォーマンスのチューニング」

2.2.5 管理の簡略化を図るためリバース・プロキシへのWebGateのデプロイを検討する

リバース・プロキシへのWebGateのデプロイには、いくつかの利点があります。次に、それらを説明します。

  • すべてのリクエストをプロキシ経由で転送することで、1つの論理コンポーネントからすべてのWebコンテンツを保護できます。これは、Oracle Access Managerによってサポートされないプラットフォームにも当てはまります。たとえば、MacOS、Solaris x86、メインフレームなど様々なプラットフォーム上で、iPlanetやApacheなど異なるタイプのWebサーバーが使用されていても、これらのサーバー上のすべてのコンテンツを保護できます。リバース・プロキシは未サポートのWebサーバーに対する回避策となり、未サポートのWebサーバーやAccessGateをサポートしないプラットフォーム用に独自のAccessGateを記述する必要がなくなります。

  • WebGateはリバース・プロキシにのみインストールすればよく、あらゆるWebサーバーへのインストールは不要です。これによって、管理ポイントが1つに集約されます。他のWebサーバー上にフットプリントを構築しなくても、リバース・プロキシを通じてすべてのWebサーバーのセキュリティを管理できます。

  • リバース・プロキシによって、アーキテクチャに柔軟性がもたらされます。リバース・プロキシでは、デプロイ済のアプリケーションに変更を加えることなく、同じアプリケーションをイントラネットとエクストラネットに公開できます。

プロキシ使用には、追加の設定作業が必要になるという大きな落とし穴があります。リバース・プロキシの背後にあるWebサーバーにWebGateをデプロイする場合は、次の作業が必要です。

  • 認証にリバース・プロキシを使用するWebサーバーは、リバース・プロキシからのリクエストのみを受け入れるようにします。このWebサーバーにデプロイされたWebGateは、フロントエンドの役割を果たすリバース・プロキシ・サーバー（1つまたは複数）からのリクエストにIP検証を強制しないよう構成する必要があります。WebGateのIP検証リストに、リバース・プロキシ・サーバー（1つまたは複数）のIPアドレスを構成します。セキュリティ上のリスクが生じるため、WebGateのIP検証をオフにしないことをお薦めします。

  • Policy Managerに構成された仮想ホストを更新し、アクセス・システムがリバース・プロキシに送信されたリクエストを捕捉できるようにします。

  • バックエンド・システムを直接ポイントするURLをユーザーが入力してプロキシを迂回することを防止します。リバース・プロキシを迂回して制限されたコンテンツに直接アクセスできないようにするには、サーバーのアクセス制御リスト（ACL）に制御文を追加します。または、ファイアウォールのフィルタを構成します。

  • すべてのユーザー・リクエストがプロキシによって処理されるため、その負荷を処理可能な数のプロキシ・サーバーをデプロイする必要があります。

  • すべての既存URLを、リバース・プロキシ・サーバーのホスト名およびポート番号にリダイレクトします。通常、この作業では、絶対HTMLのリンクが中断リンクになるのを防止するなどの目的で、コンテンツの検査とURLのリライトができるようにリバース・プロキシを構成する必要があります。この機能は大半のリバース・プロキシに備わっており、アクセス・システムとは関係ありません。フロントエンドを持つアプリケーションに表示するURLリンクは、絶対URL（http://hostname.domain:port/path/resource）または擬似的な相対URL（つまり、/path/resource）ではなく、相対URL（../../sub-path/resource）のみで構成することがベスト・プラクティスです。エンド・ユーザーのブラウザがリバース・プロキシの背後にデプロイされているときに絶対URLを使用すると、ブラウザ上に表示されるリンクは中断されます。

実装の詳細


関連項目:

『Oracle Access Managerアクセス管理ガイド』の第3章「WebGateおよびAccess Serverの構成」

2.2.6 ドキュメント保護ポリシーを設計してWebGateによるAccess Serverのコールを最小限に抑える

たとえば、Webサーバー上のドキュメントをすべて保護するポリシーを指定する場合、採用できるアプローチとしては次の2つがあります。

  • ドキュメント・ツリーのルートからすべてのドキュメントを保護し、指定したドキュメントへのアクセスを個別に許可する

  • DenyOnNotProtectedフラグを設定し、指定したドキュメントへのアクセスを個別に許可する

一般的には、2番目のアプローチのほうがパフォーマンスが高くなります。Webドキュメントをルートから保護すると、WebGateはリクエストごとに、ユーザーがリソースにアクセスする権限があるかどうかをAccess Serverに常に問い合せる必要があります。これはAccess Serverに余分な負荷をもたらします。DenyOnNotProtectedフラグを使用すると、特定のURLがアクセス・システムによって保護されているかどうかの情報を、WebGateがAccess Serverからキャッシュします。その結果、Access Serverへの問合せが不要になり、保護されていないリソースへの以降のリクエストに対して簡単にアクセスを拒否でき、サーバーのオーバーヘッドが軽減されます。

実装の詳細


関連項目:

『Oracle Access Manager IDおよび共通管理ガイド』の第3章「WebGateおよびAccess Serverの構成」

2.2.7 フォームベース認証の構成時にベスト・プラクティスを使用してログイン・エラーを防止する

Oracle Access Managerにフォームベース認証を実装するときは、ログイン・エラーを防止できるようなコードを開発します。これには、フォーム内の入力フィールドを検証するコードを埋め込み、不適切な形式の資格証明がポストされないようにすることも含まれます。たとえば、ユーザー名およびパスワードのフィールドが空白でないことをチェックできます。また、次のようなHTMLコードを使用して、コンテンツをキャッシュしないようにできます。

<meta http-equiv="pragma" content="no-cache">

実装の詳細


関連項目:

『Oracle Access Managerアクセス管理ガイド』の付録A「フォームベースの認証」

2.2.8 APIベースのプラグインをコーディングしてAccess Serverのクラッシュを回避する

次のガイドラインに従うことで、Access Serverが不安定になるリスクを軽減できます。

  • Access Serverはマルチスレッド対応のため、Access ServerにデプロイされるAPIベースのプラグインはスレッド・セーフにしてください。

  • すべての認証および認可のAPIプラグインが永続的であることを確認し、接続プーリングとキャッシングを実装することでパフォーマンスを向上させます。

  • プラグイン機能で使用されるグローバル変数とローカル変数をすべて初期化します。

  • すべての認証および認可のプラグインが、構成情報を指定する目的で、Access Serverから入力パラメータを取ることをお薦めします。

実装の詳細


関連項目:

『Oracle Access Managerカスタマイズ・ガイド』の第6章「プラグインによるアクセス制御のカスタマイズ」

2.2.9 ベスト・プラクティスを使用してAccess Manager SDK（AccessGate）クライアントをセキュアにする

Access APIクライアントの構成には、無効なクライアントによるAccess Serverへの接続を防止する、Access ServerとAccessGate構成間の秘密のパスワードが含まれます。このパスワードを保護するには、SSLを実装して、Access ServerとAccess APIクライアント間の通信を暗号化する必要があります。また、シングル・サインオンのトークン（通常はObSSOCookieの内容）をパスワードとして扱い、外部のアプリケーションにそれを渡さないようにします。

実装の詳細


関連項目:

『Oracle Access Managerカスタマイズ・ガイド』の第6章「プラグインによるアクセス制御のカスタマイズ」

2.3 IDシステムのベスト・プラクティス

この項では、IDシステムのベスト・プラクティスについて説明します。この項の内容は次のとおりです。

2.3.1 検索を回避してID管理のパフォーマンスを向上させる

可能なかぎり、検索ベースを最小限に維持します。かわりに、ユーザー・オブジェクトのクラス属性にACLを適用します。これによってパフォーマンスが向上することはすでにわかっています。また、検索ベースの構成には置換構文を使用しないようにします。これはパフォーマンスに悪影響を及ぼすことがわかっています。"...(...=*something*)..."のようなサブストリング検索を含む検索ベースまたはACLは使用しないでください。また、User、Group、Orgの各オブジェクト・クラスに、複数の検索ベースを設定しないでください。

実装の詳細


関連項目:

『Oracle Access Manager IDおよび共通管理ガイド』の第3章「IDシステムでスキーマのデータを使用可能にする」

2.3.2 Group Managerアプリケーションの「メンバーの管理」ページを使用して大規模グループを効率的に管理する

グループ管理には、「メンバーの管理」ページを使用します。このページで、グループ・プロファイル・ページの一部としてメンバーのセマンティック属性を定義するのとは対照的に、（メンバーが1000人以上の静的グループとして定義される）大規模なグループの管理が最適化されています。このページを使用することで、大規模グループを管理するときのパフォーマンスが大幅に向上します。

実装の詳細


関連項目:

『Oracle Access Manager IDおよび共通管理ガイド』の第4章「ユーザー、グループおよびOrganization Managerの構成」

2.3.3 Oracle Access Managerのデプロイ全体に単一のアイドル・タイムアウトを構成してユーザー動作に不整合が生じないようにする

一般的に、Oracle Access Managerのタイムアウト値は、すべてのアプリケーションのタイムアウトの最小値に構成する必要があります。タイムアウトは、アプリケーションではなく、WebGateまたはWebサーバーによって強制されます。そのため、この構成には、アプリケーションがOracle Access Managerよりも前にタイムアウトし、セッション関連の問題をアプリケーション内で処理する必要が生じるのを回避する目的があります。

一般的に、タイムアウト値の選択には、いくつかの検討事項があります。たとえば、既存のOracle Access Managerセッション（またはヘッダー変数）からセッションを再生成できるアプリケーションは、Oracle Access Managerよりも早くタイムアウトしてかまいません。実際、Oracle Access ManagerのIDシステムは、WebGateよりもセッションのタイムアウトを短く構成することが推奨されるアプリケーションの好例です。ただし、一般的には、これらのタイムアウト値は近接した数値に構成する必要があります。

このルールの1つの例外はAccessGateです。AccessGateは通常、BEAのWebLogic実装をサポートするなどの目的でWebGateの下流にデプロイされます。この場合は、AccessGateのアイドル・タイムアウトをWebGateよりも大きくすることで、新規のブラウザ・セッションが下流のAccessGateによって拒否されるという問題を回避することをお薦めします。AccessGateでは、アイドル・タイムアウトと最大タイムアウトを同一に構成することをお薦めします。

実装の詳細


関連項目:

『Oracle Access Managerアクセス管理ガイド』の第3章「WebGateおよびAccess Serverの構成」

2.3.4 追跡をオフにしてワークフローのパフォーマンスを向上させる

ワークフローに他の入力ステップや承認ステップが不要な場合は、WfInstanceNotRequiredパラメータを有効にすることをお薦めします。このパラメータによって、ディレクトリ・サーバーのオーバーヘッドの原因となるワークフロー追跡データの生成と格納が無効になります。

実装の詳細

このパラメータを変更する手順は次のとおりです。

  1. 次のファイルのWFInstanceNotRequiredフラグをtrueに設定します。

    install-path/identity/oblix/data/common/workflowdbparams.xml

  2. Identity Serverを再起動します。


関連項目:

『Oracle Access Managerデプロイメント・ガイド』の第2章「パフォーマンスのチューニング」

2.3.5 ワークフローのチケットを定期的にクリーンアップしてディレクトリのパフォーマンスを向上させる

ディレクトリ・サーバーに格納されているワークフローのチケット数を監視し、手動またはスクリプトベースのユーティリティによって、古いチケットを定期的に削除します。

実装の詳細


関連項目:

『Oracle Access Managerデプロイメント・ガイド』の第2章「パフォーマンスのチューニング」

2.3.6 パフォーマンスを考慮したイベントAPIプラグインを構築する

EXECタイプのプラグインは、外部プロセスを生成するため構築しないようにします。IdentityXMLを使用してIDイベントAPIプラグインからIdentity Serverの他のイベントをトリガーする必要がある場合は、そのリクエストが、イベントAPIプラグインをトリガーしているIdentity Serverインスタンス以外のインスタンスに転送されるようにします。これによって、システムの負荷が分散されます。また、パフォーマンスおよび安定性上の理由から、C/C++を使用するイベントAPIプラグインは共有オブジェクト（.soファイル）として構築します。

IDイベントAPIプラグインの開発時に適用可能なその他のベスト・プラクティスは次のとおりです。

  • IDイベントAPIプラグインはすべて、スレッドセーフにします。

  • IDイベントAPIプラグインは永続的でないため、プラグイン機能で使用されるグローバル変数とローカル変数をすべて初期化する必要があります。

  • イベントAPIプラグインの複数の機能に単一のライブラリを使用して、実行時のイメージ・サイズを最小化します。

  • 要件の変更時にプラグインの動作を変更および適合化できるように、プラグインによる構成ファイルの使用を可能にします。

実装の詳細


関連項目:

『Oracle Access Manager開発者ガイド』の第3章「IDイベント・プラグインAPI」

2.3.7 PresentationXMLを使用して埋込み可能なユーザー・インタフェース要素のルック・アンド・フィールをカスタマイズする

Oracle Access Manager IDシステムでは、eXtensible Stylesheet Language（XSL）スタイルシートおよびeXtensible Markup Language（XML）データが結合され、ユーザーに表示されるほとんどすべてのページが動的に作成されます。PresentationXMLとして知られるこの機能を利用すると、開発者は柔軟性の高い設計が可能となり、静的なHTMLコンテンツが不要になります。

PresentationXMLによるアプローチをお薦めするのは、ルック・アンド・フィール、タグのレイアウト、ナビゲーションの拡張など、フロントエンドのユーザー・インタフェースへの対処を意図している場合です。一方、データベース上のデータに基づいた値の事前埋込みや、他の入力値に基づいた値の計算処理、外部システムとの通信など、バックエンドのロジックにはお薦めできません。

実装の詳細


関連項目:

『Oracle Access Managerカスタマイズ・ガイド』の第2章「PresentationXMLによるGUIの設計」

2.3.8 PresentationXMLの開発にXML/XSLエディタを使用して開発とテストをスピードアップする

開発とテストをスピードアップするには、XMLSpyなどの強力なXMLエディタやXSLエディタを使用します。これらのエディタには統合開発環境（IDE）が組み込まれているため、XSLプログラミングのプロセスが簡略化およびスピードアップされます。

実装の詳細


関連項目:

『Oracle Access Managerカスタマイズ・ガイド』の第2章「PresentationXMLによるGUIの設計」のスタイル・シートをカスタマイズするための環境の設定に関する項

2.3.9 必ずデフォルトのスタイルシートのコピーから作業を始める

スタイルシートを変更または使用する前に、Oracle Access Managerのデフォルト（style0）のスタイルに基づいたスタイルを新規作成します。Identity ServerおよびWebPass内にあるすべての関連グラフィック、スタイルシートおよびJavaScriptをレプリケートし、デフォルトのスタイルが変更されないようにします。

実装の詳細


関連項目:

『Oracle Access Managerカスタマイズ・ガイド』の第2章「PresentationXMLによるGUIの設計」

2.3.10 PresentationXMLにJavaScriptコードを実装するときの注意事項

PresentationXMLを介してフロントエンドのページにJavaScriptコードを挿入する必要が生じた場合は、すべてのJavaScriptコードをファイルにカプセル化してから、そのファイルをXSLファイルに含めるのがベスト・プラクティスです。このファイルは、配置時に、適切なWebPassインストール・ディレクトリに配置する必要があります。

PresentationXMLにJavaScriptコードを含めるときは、WebPassインストール・ディレクトリにあるメインのmisc.jsファイルを変更しないでください。このファイルはクライアント側での処理に使用され、すべてのOracle Access Managerコンポーネントに共通です。このファイルを変更すると、すべてのコンポーネントに悪影響を及ぼす危険性があります。

実装の詳細


関連項目:

『Oracle Access Managerカスタマイズ・ガイド』の第2章「PresentationXMLによるGUIの設計」

  戻る
戻る 		 次へ
次へ
  目次
目次		 索引
索引