| Oracle Access Managerデプロイメント・ガイド 10g（10.1.4.3） B55479-01 |
|
 戻る |
 次へ |
このマニュアルは、Oracle Access Managerのデプロイを正常に行うための方法、手順およびガイドラインを提供します。この章では、Oracle Access Managerデプロイメントの概要を説明します。含まれる項目は次のとおりです。
Oracle Access Managerの一般的な概要については、『Oracle Access Manager概要』を参照してください。
Oracle Access Managerのデプロイメント・タイプは、アイデンティティ・システムのみ、またはアイデンティティ・システムとアクセス・システムの結合のいずれかであるといえます。
Oracle Access Managerアイデンティティ・システムは、次の3層で構成されます。
一般的に、Oracle Access Managerアイデンティティ・システムは、CPUに負担が集中する1つのシステムです。アイデンティティ・システムのパフォーマンスは、CPUの能力が上がると著しく向上します。
Oracle Access Managerアクセス・システムは、アイデンティティ・システムなしではデプロイできません。アクセス・システムは、次の3層で構成されます。
プレゼンテーション層: WebGateおよびカスタム・アクセス・ゲート
アプリケーション層: ポリシー・マネージャおよびアクセス・サーバー
データ層: バックエンドのLDAPディレクトリ
一般的に、Oracle Access Managerアクセス・システムは、メモリーに負担が集中する1つのシステムです。アクセス・システムのパフォーマンスは、システム・メモリーが増強されると著しく向上します。
アイデンティティ・システムのみをデプロイする場合およびアイデンティティ・システムとアクセス・システムの結合をデプロイする場合のいずれでも、複数のデプロイメント・シナリオが考えられます。詳細は、「デプロイメントのシナリオおよび環境」を参照してください。
多くの企業では、複数のデプロイメントを提供しており、それぞれのデプロイメントに特定の対象者と目的があります。複数のデプロイメントを提供することで、サービスへの支障が最小限に抑えられます。たとえば、次のような独立したデプロイメントが1つの企業に1つまたは複数ある可能性があります。
デプロイメントおよびテスト・デプロイメント
このデプロイメントでは、完全に構成された操作可能なOracle Access Managerシステムを構成してテストします。開発サーバーまたはテスト・サーバーでは、必要なRAMの量が少なくなります。ユーザー全体ではなく、小規模な開発チームのみでこれらのシステムを使用している場合は、アイデンティティ・サーバーと同じホスト・コンピュータ上でWebサーバーを実行できます。
ステージング・デプロイメント
このデプロイメントでは、本番環境と開発環境に影響を及ぼすことなく、新規アプリケーションの導入、ソフトウェアのアップグレード、パフォーマンスのベンチマークを実行します。このデプロイメントは本番環境とよく似ています。ただし、このステージング・デプロイメントは、本番デプロイメントの縮小版である場合があります。その場合は、使用するRAMの量が少なくなります。
本番デプロイメント
これは、エンド・ユーザーからのアクセスが可能な、完全にデプロイされたシステムです。レプリケートされたディレクトリとOracle Access Manager固有のロード・バランシング機能を使用することをお薦めします。Oracle Access Managerサーバーをフェイルオーバーとロード・バランシング用に構成し、Webサーバー用に個別のコンピュータを使用することもできます。
これらの例はほんの一部です。企業には、品質保証チームや統合チームのニーズを対象にしたその他のデプロイメント・シナリオも含まれる可能性があります。
デプロイメント・シナリオが1つか複数かにかかわらず、それぞれのシナリオは2つのカテゴリのいずれかに分類されます。詳細は、「デプロイメントのカテゴリ」を参照してください。
Oracle Access Managerのデプロイメントは、2つの主要なカテゴリに分類されます。これらのカテゴリは、エクストラネット（B2B、G2C、B2C）デプロイメントおよびイントラネット（B2E、G2E）デプロイメントです。これらは汎用カテゴリであり、デプロイメント・デモグラフィックの関連パターンを提供します。
詳細は、次の項目を参照してください。
エクストラネット・デプロイメントとは、次のようなデプロイメントを指します。
ユーザー数が比較的多い（2万人以上）。
比較的少数のアプリケーション（20未満）でユーザー全体が処理されている。
アプリケーションがNetPoint（Oracle Access Manager）と統合されており、通常、ポータルと統合されている。
エクストラネット・デプロイメントの最も一般的な特徴は、次のとおりです。
アクセス・システムよりアイデンティティ・システムのほうが複雑である。
一般的にアイデンティティ・イベント・プラグイン（カスタマイズ）に関連するワークフロー（自己登録、セルフサービス、委任管理）が大量にある。
委任管理要件が複雑である。通常は（少なくとも4つのレベルの管理ロール/アクセスの）様々なユーザー・タイプと、ACL、グループおよびその他のオブジェクトへの依存が関連しています。
ユーザー・インタフェースがカスタマイズされている（XSLスタイルシート、PresentationXMLおよびIdentityXMLを使用して行う）。これは、要件の大部分は多数のユーザーのアイデンティティ管理に重点をおいており、1つの主要ドライバが使いやすいためです。ほとんどの実装では、IdentityXML上に構築されたフロントエンド・ユーザー・インタフェースが公開されます。
ロスト・パスワード管理などの機能がかなり一般的に構成されている。
ソフトウェア・フットプリントが比較的小さく（たとえば、一般的に少数のサーバー（各層に2～4）のみが少数のデータ・センター間で分散される）、停止時間に対する許容度が非常に低い。これは、一般的にOracle Access Managerに依存するアプリケーションが業務に不可欠であるためです。
一般的に、ディレクトリ環境がOracle Access ManagerとOracle Access Managerがサポートするアプリケーション専用である。そのため、操作の観点から、Oracle Access Managerとともにディレクトリ・サービスの制御性が若干高まります。アプリケーション側の（通常、共通の業務内容に属する）利害関係者は、比較的少数です。
このように非常に複雑な環境で、サービスへの支障を最小限に抑えながら10g（10.1.4）へのアップグレードを実行することは、容易ではない場合があります。
一般的なイントラネット・デプロイメント環境は、次のとおりです。
ポータルが内部に直接接続しており、ユーザー数が比較的少ない（2万人未満）。
NetPoint（別名Oracle Access Manager）と統合された比較的多数のアプリケーション（20以上）でユーザー全体が処理されている。
イントラネット・デプロイメントの最も一般的な特徴は、次のとおりです。
一般的に、次の場所または方法で、アクセス・システムのカスタマイズ率がより高い。
ログイン・ページのフロントエンド（ログイン・フロントエンド）。
または、カスタム構築のアクセス・ゲートを使用。
または、バックエンド。APIを使用して開発された、カスタマイズ済の認証プラグインまたは認可プラグインを使用。
アプリケーション・レベルでの大幅な統合により、認証およびシングル・サインオン（SSO）を最も重視して、比較的多数のアプリケーション（20以上）が保護されている。
Oracle Access Managerコネクタをサーバーに使用して、多数のOracle WebLogicとIBM WebSphereアプリケーション・サーバーが統合されている。
通常、アイデンティティ・システムは、広範囲にはデプロイされないか、もしくは管理者ユーザー・コミュニティ（たとえばヘルプ・デスク、IT部門またはシステム管理者）のみにデプロイされる。
パスワード管理機能は一般的に構成または使用されない。これは、多くの場合Oracle Access ManagerがNOS（AD）と同じバックエンド・ストアに依存し、自己登録ワークフローがほとんど発生しないためです。
これらの環境では、多数のWebサーバーおよびアプリケーション・サーバーが使用され、WebGateとアクセス・サーバーの比率が10対1の範囲内であり、特にWebGate/アクセス・ゲート層でフットプリントが大きい傾向にある。
アクセス・サーバー層では、イントラネット・デプロイメントがグローバルに行われ、地理的に分散される傾向があり、各ロケーションで少数のサーバーがデプロイされる。
通常、ディレクトリ環境は共有される。これは、このディレクトリが従業員ディレクトリあるいはNOSディレクトリ（AD）であるためです。つまり、このディレクトリに関連付けられる依存関係の数は多くなります（メタディレクトリ、プロビジョニング・ソリューション、NOSログオン、ホワイト・ページなど）。そのため、ディレクトリの変更や操作による影響は、厳密に管理されます。多くの利害関係者を変更制御プロセスの中で対等にする必要があるため、厳重な操作ウィンドウを使用できます。アプリケーションの前面では、サーバーの可用性がより柔軟になりやすく、業務内容、地理またはセキュリティ要件ごとにアプリケーションがクラスタ化される傾向があります。そのため、影響を分離できます。
すべてのデプロイメントは、単一サイトまたは複数のサイトにインストールできます。アイデンティティ・システムのみまたはアイデンティティ・システムとアクセス・システムの結合、イントラネットまたはエクストラネットのいずれの場合でも同様です。
Oracle Access Managerは、様々なオペレーティング・システム、ディレクトリ・サーバー・Webサーバー・コンパイラおよびブラウザをサポートしている他、多数のアプリケーション・サーバー、ポータル・サーバー、システム管理製品およびアプリケーション・パッケージとの統合をサポートしています。最新のサポート情報は、次のサイトの「Oracle Technology Network（OTN）」を参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
「Oracle Technology Network」の次のサイトに移動します。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
「Oracle Access Manager Certification」を探し、そのリンクをクリックします。
この項で説明する内容は次のとおりです。
すべての本番環境で、Oracle Access Managerコンポーネント間での簡易モードまたは証明書モードを使用したすべてのトランスポートを保護することを推奨します。イントラネットおよびエクストラネットのすべての通信は、暗号化する必要があります。
簡易モードまたは証明書モードでSSLを有効にする場合は、WebGate、アクセス・ゲートおよびWebPassをホストするサーバーのクロック、およびアクセス・サーバーまたはアイデンティティ・サーバーをホストするサーバーのクロックの絶対時間の差が1分以内であることを確認してください。夏時間およびタイムゾーンのクロックの差がグリニッジ標準時で1分以内であることも確認してください。サーバーのクロックを確実に同期化するには、Network Time Protocol（NTP）を使用することをお薦めします。
Oracle Access Managerが簡易モードで実行されている場合は、アイデンティティ・サーバーおよびアクセス・サーバーの両方で、SSLによる暗号化を提供するためにOracle Access Managerで生成される自己署名証明書をデフォルトで年1回リフレッシュする必要があります。更新頻度は構成可能です。ただし、その場合は次の指示に従ってください。
WebPassを実行するWebサーバーの簡易証明書を更新します。
ポリシー・マネージャが簡易モードで動作するために必要な証明書を更新します。
obSSOCookieが2つの異なる環境にあるコンピュータ間で共有されていないことを確認します。
これにより、両方の環境に存在するユーザーは、ソース環境からシングル・サインオンを使用できるようになります。obSSOCookieの更新は、環境間で移行する場合の重要なセキュリティ対策の1つです。
|
重要: 異なる環境間でSSOを切断する方法は他にもありますが、ドメインの変更もその1つです。たとえば、dev.company.comからstaging.company.comに変更して、異なる環境間の共有シークレットを更新します。 |
インストールおよび設定の完全な詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。インストール後のトランスポート・セキュリティ・モードの変更の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
各コンポーネントは、安定性のある、適切にインストールされたプラットフォームで実行する必要があります。すべてのデプロイメント内およびすべてのデプロイ間で、ディレクトリ・サーバーのバージョンおよびWebサーバーのバージョンを標準とすることをお薦めします。また、デプロイメントのホスト・コンピュータ、IPアドレス、トランスポート・セキュリティ・モード、検索ベースおよびディレクトリ・プロファイルを記録することをお薦めします。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
それぞれのOracle Access Managerデプロイメント内でLDAPディレクトリ・サーバー専用のコンピュータを使用し、ファイル・システムのレイアウトを標準化することをお薦めします。詳細は、「LDAPディレクトリおよびデータの推奨事項」を参照してください。
/customizationsディレクトリを作成してデプロイメントへのすべての変更を記録することをお薦めします。詳細は、「カスタマイズの推奨事項」を参照してください。
Oracle Access Managerサーバーとは、Oracle Access Managerアイデンティティ・サーバーおよびOracle Access Managerアクセス・サーバー・コンポーネントを指す総称です。
信頼性を高めるために、アイデンティティ・サーバーおよびアクセス・サーバーを、独立した専用のハードウェアにインストールして操作することをお薦めします。つまり、アイデンティティ・サーバーまたはアクセス・サーバーごとに専用のコンピュータが必要です。たとえば、ユーザー数が15,000人以下の小規模なOracle Access Managerデプロイメントがあるとします。使用できるサーバー・クラスのコンピュータが4台あり、そのうち2台にアイデンティティ・サーバー、残りの2台にアクセス・サーバーをインストールします。また、Webサーバーの各ペアの前面にIP切替えテクノロジを使用してロード・バランシングとフェイルオーバーを提供します。
デプロイメントの負荷が軽く、プライマリ・アイデンティティ・サーバーおよびアクセス・サーバーの合計使用率が85%以下の場合は、クロスオーバー・デプロイメントを使用してハードウェアを節約できます。この場合は、プライマリ・アイデンティティ・サーバーおよびセカンダリ・アクセス・サーバーを1台のコンピュータにインストールし、セカンダリ・アイデンティティ・サーバーとプライマリ・アクセス・サーバーを別のコンピュータにインストールできます。フェイルオーバーは構成済です。
内部に直接接続しており、厳重に保護されている1つまたは2つのWebサーバーを、Oracle Access Managerの管理インタフェース（アイデンティティ・システム・コンソールおよびアクセス・システム・コンソール）のホスト専用にすることをお薦めします。これは、アプリケーションのWebサーバーで障害が発生した場合に、認可および認証のシステムを保護するのに役立ちます。
WebPassインスタンスは、一連の専用Webサーバーにインストールすることをお薦めします。これらのサーバーにIdentityXML（SOAP）コールを処理させる場合には、特にお薦めします。
アイデンティティ・システムとアクセス・システムの結合をデプロイする場合は、WebPassとWebGateの両方を同じWebサーバー・インスタンスに対してインストールすることをお薦めします。こうすることで、WebPassを通過するアクションへ、認証およびシングル・サインオン（SSO）がWebGateから提供されるようになります。たとえば、ユーザーが自己登録を実行するときや、管理者がアイデンティティ・システム・コンソールにアクセスするときです。
また、「標準化の推奨事項」で説明しているように、デプロイメント内でWebサーバーのバージョンを標準とすることをお薦めします。
キャパシティ・プランニングおよびサイズ設定のガイドラインは、第2章を参照してください。パフォーマンス・チューニングの推奨事項は、第3章を参照してください。
一般的に、次の要素は、LDAPディレクトリ・サーバーおよびOracle Access Manager自体の全体的なパフォーマンスに影響を及ぼします。ただし、次の要素に関して行う決定は、それぞれの業務の要件によって主導されます。
DIT構造: 平板か深層かによって、検索操作のパフォーマンスに影響を及ぼします。
レプリケーション: 頻度、マルチマスター、ネットワーク待機
ディスク・サイズおよびI/Oレスポンス時間
属性操作（検索および索引処理）、もしくはLDAPアクセスおよびエラー・ロギングのディスクI/Oの競合
属性の索引処理
接続オーバーヘッド: 寿命の長い接続が推奨されます（特にLDAPS使用の場合）。現在の多くのネットワーク・ルーターおよびスイッチには（従来のファイアウォールのような）接続状態表が含まれており、システム間の接続を処理できます。そのため、トランザクション（タイムアウト+接続リカバリ+操作レスポンス時間）の大量のオーバーヘッドが生じます。
それぞれのOracle Access Managerデプロイメント内でLDAPディレクトリ・サーバー専用のコンピュータを使用し、ファイル・システムのレイアウトを標準化することをお薦めします。たとえば、それぞれのデプロイメントで、Oracle Access Manager固有のファイルをすべて、特定の1つのディレクトリ・パスに保存することを検討してください。すべてのデプロイメントで、同じバージョンのWebサーバーおよびディレクトリ・サーバーを使用することをお薦めします。
また、Oracle Access Managerの構成およびポリシー・データを、ユーザー・データやグループ・データとは別のディレクトリに格納することを検討してください。こうすることで、より新しいリリースへのアップグレードをより柔軟に行うことができ、ユーザー・ディレクトリおよびグループ・ディレクトリ（通常、共有のエンタープライズ・ディレクトリ）への影響が最小限に抑えられます。データの分離は、特に、ディレクトリ上で大量の負荷が発生するワークフロー駆動のプロセスに対して有効です。また、個別の論理ディレクトリ・インスタンスを構成することで、各ディレクトリのチューニングと管理を個別に行い、全体的なパフォーマンスを向上させることができます。
|
注意: ハードウェアやトポロジの問題によってディレクトリを分離できない場合は、専用の接尾辞を作成してOracle Access Managerの構成およびポリシー・データを保持することを検討してください。 |
また、「標準化の推奨事項」で説明しているように、デプロイメント内でディレクトリ・サーバーのバージョンを標準とすることをお薦めします。
詳細は、「LDAPディレクトリ・サーバーの考慮事項」を参照してください。キャパシティ・プランニングおよびサイズ設定のガイドラインは、第2章を参照してください。パフォーマンス・チューニングの推奨事項は、第3章を参照してください。ディレクトリ・サーバーの要件の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
可能なかぎり、すべてのOracle Access Manager監査データの記録および格納を1つのデータベースで行うことをお薦めします。これにより、監査情報が保護され、監査証跡およびレポートを簡単に生成できるようになります。
ロギングおよび監査の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
一般的に、Oracle Access Managerのタイムアウト値は、すべてのアプリケーション・タイムアウトの最低値に構成する必要があります。タイムアウトを実行するのはアプリケーションではなく、WebGateまたはWebサーバーです。ここでの目的は、Oracle Access Managerがタイムアウトする前にアプリケーションがタイムアウトしないようにすることです。アプリケーションが先にタイムアウトすると、アプリケーション内でセッションの問題が発生し、潜在的に動作に矛盾が生じる可能性があります。
タイムアウト値を選択する際の考慮事項は多数あります。たとえば、既存のOracle Access Managerセッション（またはヘッダー変数）からセッションを再生成できるアプリケーションは、Oracle Access Managerより先にタイムアウトしてもかまいません。実際に、アイデンティティ・システムは、セッション・タイムアウトがWebGateで推奨されているより短いアプリケーションの適例です。
ただし、一般的には、これらのすべてのタイムアウト値を近い値にする必要があります。このルールに当てはまらないのはアクセス・ゲートです。アクセス・ゲートは、たとえばBEA WebLogicの実装をサポートして、通常WebGateから下流へデプロイされます。この場合は、新規のブラウザ・セッションが下流のアクセス・ゲートによって拒否される問題を回避するために、アクセス・ゲートのアイドル・タイムアウトをWebGateより長くすることをお薦めします。アクセス・ゲートでは、アイドル・タイムアウトと最大タイムアウトを同じに構成することをお薦めします。
詳細は、『Oracle Access Managerアクセス管理ガイド』のWebGateおよびアクセス・サーバーの構成に関する章を参照してください。
Oracle Access Managerは、独自のデプロイメントおよびユーザーに合せて調整できます。たとえば、IdentityXML、PresentationXMLおよびAccess Manager APIを使用して、フロントエンド・カスタマイズを作成できます。また、Identity Event API、Authentication API、Authorization API（カスタム・アクセス・ゲートおよびプラグインを含む）を使用して、バックエンド・カスタマイズを作成できます。
すべてのOracle Access Managerコンポーネント・インストール・ディレクトリの外にある1つのディレクトリにすべてのカスタマイズ情報が格納されるように、/customizationsディレクトリを作成することをお薦めします。これは、Oracle Access Managerを再インストールまたはアップグレードする際に重要です。すべてのサブディレクトリは、これらのプロセスの中で削除されるためです。
それぞれのデプロイメント内で行った変更やカスタマイズは、すべて記録することをお薦めします。また、カスタマイズが期待どおりに動作することを確認できるように、カスタマイズの動作を検証するテスト・スクリプトを開発してください。スクリプトは、カスタマイズをより大規模なデプロイメントに再デプロイしたり、より新しいOracle Access Managerのリリースにアップグレードするタスクを単純化するのに役立ちます。
この項および「埋込み可能なユーザー・インタフェース要素の外観のカスタマイズ」に記載されている考慮事項を確認します。
Oracle Access Managerデプロイメント全体への依存が最も小さい小規模のテスト・デプロイメントまたは開発デプロイメント（理想としてはサンドボックス・タイプの設定）にOracle Access Managerをインストールして設定します。
詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
決定性のテスト・スクリプトを開発してカスタマイズの作成前および作成後に実行し、完全なエンドツーエンド・トランザクションを実行して、すべてが期待どおりに動作することを確認します。
テスト・スクリプトは、実行する特定のカスタマイズによって異なります。たとえば、スクリプトによって、認可と認証が必要な単一のページおよびワークフロー・リクエスト（すべて単一のページ・リクエストによってトリガーされる）を要求する場合があります。
コードをコンパイルするかカスタマイズをデプロイして、任意のデプロイメントでのカスタマイズの構成方法を説明する一連の手順を開発します。
Oracle Access Manager Software Developer KitおよびAPIの使用に関する詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
すべてのカスタマイズ（たとえばスタイル、アクセス・ゲートまたはプラグイン）をテストして、期待どおりに動作することを確認します。
テストが成功した場合は、この情報を本番環境に移行する前にさらにテストするために、コンパイルされたすべてのバイナリおよびカスタマイズをより大規模なデプロイメントに再デプロイします。
Oracle Access Managerを本番にデプロイする前に、全体的な長期の負荷テストおよびベンチマーク解析を実行することをお薦めします。これにより、システム全体の動作の細かいチューニングおよび予測が可能になります。パフォーマンスの数値に基づいてパフォーマンスをチューニングできます。たとえば、キャッシュ設定、タイムアウト値およびディレクトリ接続数を変更したり、アイデンティティ・サーバーやアクセス・サーバーのスレッド数を増加できます。
パフォーマンス・チューニングの推奨事項は、第3章を参照してください。
この項では、すべてのアイデンティティ・システム（アクセス・システムと結合されたデプロイメントのアイデンティティ・システムを含む）のデプロイメントに関する一般的な推奨事項を説明します。
キャパシティ・プランニングの詳細は、第2章を参照してください。パフォーマンス・チューニングの詳細は、第3章を参照してください。
Oracle Access Manager IDは、Extensible Style Language（XSL）スタイルシートおよびExtensible Markup Language（XML）データを組み合せて、ユーザーに表示されるほとんどのページを動的に作成します。この機能はPresentationXMLと呼ばれ、開発者が柔軟に設計することを可能にし、静的HTMLコンテンツの必要性を回避します。
PresentationXMLは、フロントエンドのユーザー・インタフェースの問題、たとえば外観、タグのレイアウト、ナビゲーションの拡張などに対処することを目的とする場合に推奨される方法です。バックエンドのロジック、たとえばデータベースのデータに基づく値の事前入力、他の入力値に基づく値の算出、外部システムとの通信などには適していません。
推奨事項は次のとおりです。
スタイルシートを変更または使用する前に、Oracle Access Managerのデフォルト（style0）スタイルに基づいて、新しいスタイルを作成してください。デフォルト・スタイルを変更せずに残すために、アイデンティティ・サーバーおよびWebPassの関連するグラフィック、スタイルシートおよびJavaScriptsをすべてレプリケートしてください。
新しいスタイルの作成の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。アイデンティティ・システムのページのカスタマイズ、スタイルのコピー、デプロイメント全体でのスタイルのテストと伝播の詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
PresentationXMLの開発時に開発およびテストを効率的に行うには、XMLSpyなどの強力なXMLエディタまたはXSLエディタを使用してください。これらのエディタでは、XSLプログラミングのプロセスを単純および迅速に行える統合開発環境（IDE）が提供されます。
デプロイメント全体でのスタイルのテストおよび伝播に関する詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
PresentationXMLにJavascriptコードを実装する際には注意が必要です。
PresentationXMLを使用してフロントエンド・ページにJavaScriptコードを挿入する必要が出てきた場合は、すべてのJavaScriptコードをファイル内にカプセル化してから、そのファイルをXSLファイルに含めることが最善です。デプロイメントの実行時には、このファイルを適切なWebPassインストール・ディレクトリにデプロイする必要があります。
PresentationXMLにJavaScriptコードを含める場合は、WebPassインストール・ディレクトリにあるメインのmisc.jsファイルを変更しないでください。このファイルはクライアント側の処理に使用され、すべてのOracle Access Managerコンポーネントに共通します。変更するとすべてのコンポーネントに悪影響を及ぼします。
PresentationXMLを使用したインタフェースのカスタマイズに関する詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
1台のコンピュータのアイデンティティ・サーバー・インスタンスを削除して別のコンピュータに再インストールする必要がある場合は、元のアイデンティティ・サーバー・インスタンス名を再利用できます。ただし、Oracle Access Managerが新しいインスタンスを認識し、元のインスタンスを探すことがないように、特定の手順を行う必要があります。
システム・コンソールからアイデンティティ・サーバー名を削除しない場合は、設定後にログインすると、アプリケーションが設定されていませんというメッセージが表示されることがあります。インスタンスのアンインストール後にアイデンティティ・サーバー・インスタンス名を再利用する場合の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
この項では、アクセス・システムを含むすべてのデプロイメントに関する一般的な推奨事項を説明します。
キャパシティ・プランニングの詳細は、第2章を参照してください。パフォーマンス・チューニングの詳細は、第3章を参照してください。
Cookieのリプライ攻撃の危険性を緩和するために、IP検証を常に有効にしておくことをお薦めします。例外が必要な場合、たとえばリバース・プロキシのトポロジを使用してデプロイする場合などは、例外リストに許可されたIPアドレスのみが含まれていることを確認してください。IP検証はできるかぎりオフにしないでください。
Cookieリプライ攻撃の危険性を回避するために、HTTPSを使用してコンテンツを安全にデプロイすることもできます。これにより、未認可のクライアントへのObSSOCookieの漏えいを防止できます。また、認可時に設定されるObSSOCookieがSSLでのみ送信されるように、フォーム、基本または外部チャレンジ・メソッドのチャレンジ・パラメータに対してssoCookieを指定します。これにより、セキュアでないWebサーバーにObSSOCookieが送信されるのを防止できます。このパラメータを設定するには、SSLに対して構成するすべてのWebサーバーが保護されている必要があります。SSL Webサーバーでは、非SSL Webサーバーを使用したシングル・サインオンは実行されません。ブラウザによって、SSL Webサーバーから取得したセキュアなcookieが同じドメインにある非SSL Webサーバーに戻されません。
詳細は、『Oracle Access Managerアクセス管理ガイド』のユーザー認証の構成に関する章を参照してください。
一般的に、認可フィルタのかわりに動的グループを使用して認可ルールを指定することをお薦めします。動的グループを使用すると、フィルタの管理（グループの仮想メンバーは誰か）を認可ルールの管理から切り離すことができます。これによって、認可済ロールの管理をアクセス・ポリシーの構成者とは別の管理者クラスに委任できるようになります。また、グループ管理によって、認可ルール・フィルタでは行われない、変更および変更の承認の追跡が可能になります。
詳細は、『Oracle Access Managerアクセス管理ガイド』のユーザー認証の構成に関する章を参照してください。
リバース・プロキシにWebGateをデプロイすることには、多数の利点があります。こうした属性には、次のものがあります。
プロキシを介してすべてのリクエストをダイレクトすることで、単一の論理コンポーネントのすべてのWebコンテンツを保護できます。
これは、Oracle Access Managerでサポートされないプラットフォームでも同様です。異なるタイプのWebサーバー（iPlanetやApacheなど）が異なるプラットフォーム（MacOS、Solaris x86、メインフレームなど）にある場合は、これらのサーバーのすべてのコンテンツを保護できます。リバース・プロキシは、サポートされていないWebサーバーの次善策といえます。サポートされていないWebサーバーやアクセス・ゲートがサポートされないプラットフォームに対してカスタム・アクセス・ゲートを記述する必要がなくなります。
WebGateは、Webサーバーごとにインストールするのではなく、リバース・プロキシのみにインストールできます。
これにより、単一の管理ポイントが作成されます。リバース・プロキシを介してすべてのWebサーバーのセキュリティを管理できます。その他のWebサーバーではフットプリントは確立されません。
リバース・プロキシによって、アーキテクチャの柔軟性が提供され、イントラネットおよびエクストラネット上で同じアプリケーションを公開できるようになります。すでにデプロイされているアプリケーションへの変更は不要です。
プロキシ使用の主な短所は、設定に関わる余分な作業です。リバース・プロキシで保護されたWebサーバーにWebGateをデプロイする場合は、次の作業が必要です。
認証にリバース・プロキシを使用するすべてのWebサーバーで、リバース・プロキシからのリクエストのみが受け入れられることを確認します。
このWebサーバーにデプロイされたWebGateを構成して、リバース・プロキシ・サーバーまたはフロントエンドの役割をするサーバーから受信したリクエストに対するIP検証が実行されないようにする必要があります。リバース・プロキシ・サーバーまたはWebGateのIP検証リストに含まれているサーバーのIPアドレスを構成する必要があります。WebGateのIP検証はオフにしないことをお薦めします。オフにするとセキュリティ上の問題が発生します。
リバース・プロキシに送信されたリクエストがアクセス・システムによってインターセプトされるように、ポリシー・マネージャで構成された仮想ホストを更新します。
バックエンド・システムを直接示すURLを入力して、ユーザーによるプロキシの迂回を防止します。サーバーにアクセス制御リスト（ACL）文を追加して、ユーザーによるリバース・プロキシのバイパスおよび制限されているコンテンツへの直接的アクセスを防止します。かわりに、ファイアウォール・フィルタを構成することもできます。
プロキシではすべてのユーザー・リクエストが処理されるため、システムが負荷を処理できるように十分なプロキシ・サーバーをデプロイする必要があります。
既存のすべてのURLをリバース・プロキシ・サーバーのホスト名およびポート番号にリダイレクトします。
そのためには通常、コンテンツの検査とURLのリライトが行われるようにリバース・プロキシを構成する必要があります。これによって、たとえば、HTMLの絶対リンクがリンク切れになるのを回避できます。これは、ほとんどのリバース・プロキシで可能で、アクセス・システムから独立した機能です。絶対URL（http://hostname.domain:port/path/resource）や擬似相対URL（/path/resource）ではなく、相対URL（../../sub-path/resource）のみが含まれるように、フロントエンドのアプリケーションに公開されるURLリンクを構成するのが最善の方法です。絶対URLは、リバース・プロキシで保護してデプロイされた場合に、エンド・ユーザーのブラウザ上のリンクを切断する可能性があります。
詳細は、『Oracle Access Managerカスタマイズ・ガイド』のWebGateおよびアクセス・サーバーの構成に関する章を参照してください。
Webサーバー上のすべてのドキュメントを保護するポリシーを指定する場合、有効な方法が2つあります。
ドキュメント・ツリーのルートからのすべてのドキュメントを保護して、指定されたドキュメントへのアクセスを特別に許可します。
一般的に、2番目の方法では、より高いパフォーマンスが得られます。ルートからのWebドキュメントを保護する場合、ユーザーがリソースへのアクセスを許可されていれば、WebGateは常にリクエストごとにアクセス・サーバーに対して問合せを行う必要があります。これによってアクセス・サーバーにはさらに負荷がかかります。DenyOnNotProtectedフラグを使用する場合、WebGateは、アクセス・システムによって特定のURLが保護されているかどうかについて、アクセス・サーバーからの情報をキャッシュします。その結果、保護されていないリソースに対する後続のリクエストへのアクセスを、アクセス・サーバーに問い合せずに単純に拒否できます。そのため、サーバーのオーバーヘッドが減少します。
詳細は、『Oracle Access Managerアクセス管理ガイド』のWebGateおよびアクセス・サーバーの構成に関する章を参照してください。
Oracle Access Managerでフォーム・ベース認証を実装する場合は、ログイン・エラーを回避するようにコードを開発してください。これには、不正な資格証明のポストを回避するためにフォームの入力フィールドを検証するコードを埋め込むことも含まれます。たとえば、ユーザー名およびパスワードのフィールドが空白でないことをチェックできます。さらに、コンテンツのキャッシングを防止するHTMLコード（たとえば<meta http-equiv="pragma" content="no-cache">）を使用してください。
詳細は、『Oracle Access Managerアクセス管理ガイド』のフォーム・ベース認証に関する章を参照してください。
すべてのデプロイメント・タスクを開始する前に、担当者およびそのチームが図1-1に提示されているすべての項目および後続の概要について理解しておくことを強くお薦めします。
この章の内容を確認して、デプロイメントの概要および一般的な推奨事項を理解します。詳細は、次の項目を参照してください。
「プランニング・デリバラブル」を参照して、それぞれのデプロイメントに対して作成する必要があるプランニング・ドキュメントの詳細を確認します。
第2章の「Oracle Access Manager参照サーバーのフットプリント」および「中規模から大規模のサンプル・デプロイメント」を参照して、各デプロイメントの容量およびサイズ設定の要件を調べる方法と戦略を確認します。
第3章で、パフォーマンス・チューニングの推奨事項およびツールと方法を確認します。
第4章を参照して、Oracle Access ManagerのサーバーとWebコンポーネント間、およびOracle Access Managerのサーバーとディレクトリ間のフェイルオーバーとロード・バランシングの構成の詳細を確認します。
第5章を参照して、クローニングされ同期化されたコンポーネントの詳細およびシステム構成情報のキャッシングの詳細を確認します。
第6章を参照して、再構成可能な要素および再構成の方法の詳細を確認します。
第7章を参照して、タイムゾーン間でのクロックの同期化の詳細を確認します。
第8章を参照して、より新しいOracle Access Managerのリリースへのデータの移行およびアップグレードに関する詳細を確認します。
プランニングのアクティビティには、各デプロイメントの詳細な計画を定義して記録するドキュメントの準備が含まれます。
デプロイメントの詳細の決定: デプロイメントごとに、次の情報を指定する計画を定義します。
デプロイメントのタイプおよび層: 「Oracle Access Managerデプロイメントのタイプおよび層の概要」の説明に従って、デプロイメント・タイプ（アイデンティティ・システムのみ、もしくはアイデンティティ・システムとアクセスシステムの結合）を決定し、記録します。
デプロイメント・シナリオ: 「デプロイメントのシナリオおよび環境」の説明に従って、各デプロイメント・シナリオを決定し、記録します。
デプロイメント・カテゴリ: 各デプロイメントをイントラネット・デプロイメントまたはエクストラネット・デプロイメントのどちらにするかを決定します。それぞれの特徴および依存性は、「デプロイメントのカテゴリ」を参照してください。
デプロイメント・サイズおよびコンポーネントの配布: サイト数が1つか複数かにかかわらず、インストールするコンポーネントの数と場所を決定し、記録します。キャパシティ・プランニングの詳細は、第2章を参照してください。
標準化: 各コンポーネントは、安定性のある、適切にインストールされたプラットフォームで実行し、次の推奨事項に従う必要があります。
管理アクセス: スキーマおよびその他の操作では、ディレクトリおよびOracle Access Managerファイルへの書込み権限を持つ管理アクセスが要求されます。各デプロイメントの管理者として選ばれたユーザーに連絡します。
カスタマイズ: それぞれの環境およびユーザーに合せてOracle Access Managerを調整するために、「カスタマイズの推奨事項」の説明に従ってカスタマイズした構成を作成できます。各デプロイメントに必要なカスタマイズのタイプを調べます。
プランニング・ドキュメントの作成: 表1-1の内容を参考にして、デプロイメントの決定事項をドキュメントに記録します。
表1-1 一般的なデプロイメントの詳細
| デプロイメントの詳細 | 説明 |
|---|---|
|
タイプ |
アイデンティティ・システムのみ、または結合されたアイデンティティ・システムとアクセス・システム |
|
シナリオ |
テスト、品質保証、本番、またはその他 |
|
カテゴリ |
イントラネットまたはエクストラネット |
|
管理者 |
Oracle Access Managerマスター管理者 マスター・アイデンティティ管理者 マスター・アクセス管理者 Oracle Access Managerで使用されるディレクトリ・バインド資格証明 |
|
ディレクトリ・プロファイル |
トランスポート・セキュリティ: オープンまたはSSL有効 マスターまたはレプリカ構成 フェイルオーバー構成 詳細は、次を参照。 |
|
Oracle Access Managerセキュリティ |
トランスポート・セキュリティ・モード: 簡易、証明書、またはオープン |
|
アイデンティティ・システム |
アイデンティティ・サーバー・インスタンス WebPassインスタンス フェイルオーバー構成 詳細は、次を参照。 |
|
アクセス・システム |
ポリシー・マネージャ・インスタンス アクセス・サーバー・インスタンス WebGateインスタンス フェイルオーバー構成 詳細は、次を参照。 |
|
サード・パーティ統合アプリケーション |
サポート対象サード・パーティ・アプリケーションの実装の詳細は、『Oracle Access Manager統合ガイド』を参照。 |
|
カスタマイズ |
IdentityXML、PresentationXMLおよびAccess Manager APIを使用して作成するフロントエンド・カスタマイズ Identity Event API、Authentication API、Authorization APIを使用するバックエンド・カスタマイズ Oracle Access Manager Software Developer Kitを使用して作成するカスタム・アクセス・ゲートおよびプラグイン 詳細は、次を参照。
|
インストール準備ワークシートの入力: 『Oracle Access Managerインストレーション・ガイド』に含まれている準備ワークシートを使用して、インストールの詳細を確認および記録します。
デプロイメントへのすべての変更の記録: デプロイメント内でのすべての変更は必ず記録します。次の変更も含まれます。
ファイルまたはデータベースの監査用に構成されたアイデンティティ・サーバー（およびアクセス・サーバー）
すべてのアイデンティティ・イベント・プラグインの識別
PresentationXMLおよびXSLスタイルシートのカスタマイズ
ファイル・ベースの変更（たとえば、globalparams.xmlまたは.lstファイルへの変更）
アクセス・サーバーのカスタマイズされた認可プラグインまたは認証プラグイン
アクセス管理フラグのステータス
各アクセス・ゲート、WebGateおよびポリシー・マネージャの詳細。HTTP Cookieドメイン、優先ホスト名、キャッシュ・タイムアウトおよびキャッシュ・サイズ、フェイルオーバーしきい値、カスタムIdentityXMLクライアント、WebGateで保護されるWebPassまたはWebサーバー・ファームの参照に使用されるすべての仮想IPおよびDNSの別名など。
デプロイメントを開始する前に、次に示す一般的なガイドラインに従ってください。
戦略的に考え、戦術的に行動する: 長期的な視野で、必ずしも戦術的な締切りに縛られたり制限されないロードマップを使用して、戦略的観点からソリューションの計画と設計を行います。計画を測定および達成が可能なフェーズに分割します。各フェーズは、戦略的目標の達成に貢献するもので、マイルストンごとに投資利益率（ROI）が提供されます。
専門家の助言を求める: 計画、要件の収集および設計の段階では、専門家を雇うことにきわめて大きな価値があります。業界での長年の経験があり、様々な垂直市場でプロジェクトを完成させてきた専門家に相談します。専門家を雇うための時間とコストは、危険性の緩和、業界のベスト・プラクティスの導入、および成功のために有効な戦略の定義によって相殺されます。業界の専門知識には、通常、次の2つの要素があります。
業種別専門知識: 確立されたポリシー、手順および標準に関する知識、政府の規制と指針の順守の熟知、情報セキュリティのベスト・プラクティス、セキュリティの管理と操作、および技術インフラに関する知識です。
技術的専門知識: 業務要件、技術インフラ、Oracleのテクノロジおよびアプリケーション・セキュリティ、アイデンティティ管理、アクセス管理、Webサービス・セキュリティ、情報保証およびプライバシ管理に対処するためにテクノロジを最大限に利用することです。
知識に投資する: 設計を開始する前に、デプロイメントのサポートに必要なテクノロジおよび製品に関する知識を担当チームが習得していることを確認します。進化するインフラストラクチャをチームの各メンバーが個々にサポートおよび管理できるように、知識の獲得と移転のための具体的な研修を行うことを強くお薦めします。この投資はデプロイメント成功の鍵になります。
このマニュアルに含まれている推奨事項に加えて、『Oracle Application Serverベスト・プラクティス・ガイド』も参照してください。『Oracle Application Serverベスト・プラクティス・ガイド』に含まれる推奨事項では、このマニュアルで説明する範囲よりさらに望ましい結果を得るために、ツールと手動プロセスを併用する場合があります。
『Oracle Application Serverベスト・プラクティス・ガイド』は3か月ごとに更新されます。このガイドは、次に示すテクノロジ分野を含むOracle Identity and Access Management Suiteに焦点を当てています。
Oracle Access Manager: Oracle Access Manager固有のすべての推奨事項は、このガイドの中で繰り返し説明しています。
Oracle Internet Directory
Oracle Virtual Directory
セキュリティ
Oracle Application Server高可用性
