Oracle Identity and Access Managementは、エンタープライズ・リソース間でユーザー・アイデンティティのエンドツーエンド・ライフサイクルを企業が管理できるようにします。アプリケーションをより高速にデプロイでき、エンタープライズ・リソースに対してもっとも詳細な保護を適用できるなど、その他にもいろいろできます。この章では、アクティブ/アクティブ構成における高可用性のためのIdentity and Access Management (IAM)製品の構成方法を説明します。
Oracle Identity and Access Management 11gリリース2 (11.1.2)には次のコンポーネントが含まれており、この章で説明します。
Oracle Identity Manager(OIM)
Oracle Access Management Access Manager (OAM)
Oracle Adaptive Access Manager(OAAM)
Oracle Access Management Security Token Service (STS)
Oracle Access Management Identity Federation (IF)
Oracle Entitlements Server(OES)
Oracle Access Management Mobile and Social
Oracle Privileged Account Manager (OPAM)
Oracle Identity Navigator(OIN)
この章の内容は次のとおりです。
第8章「Identity Managementコンポーネントの高可用性の構成」では、11gリリース2にアップデートしていない、使用可能な11gリリース1のIdentity Managementコンポーネントについて説明しています。これらのコンポーネントには、次のものが含まれます。
Oracle Internet Directory(OID)
Oracle Virtual Directory
Oracleディレクトリ統合プラットフォーム
Oracle Directory Services
この項では、Oracle Identity Managerの概要およびOracle Identity Managerの高可用性環境の設計とデプロイについて説明します。
Oracle Identity Managerは、アプリケーションおよびディレクトリからユーザー・アカウントを追加、更新および削除するプロセスを自動化するユーザー・プロビジョニングおよび管理ソリューションです。また、誰が何にアクセスしたかを示すきめ細かいレポートを提供することで、法規制コンプライアンスの向上にも寄与します。Oracle Identity Managerは、スタンドアロン製品として、またはOracle Identity and Access Management Suiteの一部として使用可能です。
ユーザー・アイデンティティのプロビジョニングを自動化すると、ITの管理コストを削減し、セキュリティを高めることができます。プロビジョニングは、法規制コンプライアンスにおいても重要な役割を果たします。Oracle Identity Managerの主要機能には、パスワード管理、ワークフローとポリシーの管理、アイデンティティ調整、レポートと監査、アダプタによる拡張性などがあります。
Oracle Identity Managerの機能は、次のとおりです。
ユーザー管理
ワークフローおよびポリシー
パスワード管理
監査とコンプライアンスの管理
ユーザー・プロビジョニング
組織とロールの管理
Oracle Identity Managerの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドを参照してください。
この項の内容は次のとおりです。
図9-1は、Oracle Identity Managerのアーキテクチャを示しています。
Oracle Identity Manager Serverは、Java EE標準に準拠した、スタンドアロンの自己完結型アイデンティティ管理ソリューションです。ユーザー管理、ワークフローおよびポリシー、パスワード管理、監査およびコンプライアンス管理、ユーザー・プロビジョニング、および組織およびロール管理機能を提供します。
Oracle Identity Managerは、標準Java EEアプリケーションであり、Oracle WebLogic Server上にデプロイされ、データベースを使用してランタイムおよび構成データを格納します。MDSスキーマには構成情報が含まれ、OIMスキーマにはランタイムおよびユーザー情報が格納されます。
Oracle Identity Managerは、RMIを使用してSOA管理対象サーバーに接続し、SOA EJBを呼び出します。
Oracle Identity Managerは、Oracle SOA Suiteのヒューマン・ワークフロー・モジュールを使用して、そのリクエスト・ワークフローを管理します。Oracle Identity Managerは、SOA用のフロントエンドURLであるSOAサーバーのT3 URLを使用してSOAに接続します。クラスタ化されたSOAサーバーでは、ロード・バランサまたはWebサーバーのURLを使用することをお薦めします。ワークフローが完了すると、SOAはOIMFrontEndURLを使用してOracle Identity Manager Webサービスをコールバックします。Oracle SOAは、Oracle Identity Managerとともにデプロイされます。
いくつかのOracle Identity ManagerモジュールはJMSキューを使用します。各キューは、個別のメッセージドリブンBean(MDB)によって処理されます。MDBもOracle Identity Managerアプリケーションの一部です。メッセージ・プロデューサもOracle Identity Managerアプリケーションの一部です。
Oracle Identity Managerは、埋込みOracle Entitlements Serverを使用しますが、これもOracle Identity Managerエンジンの一部です。Oracle Entitlements Server(OES)は、Oracle Identity Manager内部で認可の確認に使用されます。たとえば、ポリシー制約の1つで、特定のロールを持つユーザーのみがユーザーの作成を許可されると決定されているとします。これは、Oracle Identity Managerユーザー・インタフェースを使用して定義します。
Oracle Identity Managerは、スケジュール済アクティビティのためにクォーツ・ベースのスケジューラを使用します。バックグラウンドで実行される様々なスケジュール済アクティビティがあります。たとえば、スケジュール済タスクの1つは、ユーザーの終了日後にそのユーザーを無効化することです。
Oracle Identity Managerは、すべてのレポート作成機能のためにOracle BI Publisherと連携します。BI Publisherは、異なるドメインまたは同じドメインに配置され、単純な静的なURL統合のみで統合されます。BI PublisherとOracle Identity Managerランタイム・コンポーネントとの間に相互作用はありません。BI Publisherは、レポート作成のために同じOIMデータベース・スキーマを使用するように構成されます。
LDAPSyncが外部ディレクトリ・サーバー(Oracle Internet Directory、ODSEE、Microsoft Active Directoryなど)と直接通信できるようにすると、高可用性とフェイルオーバー機能をサポートするためにIdentity Virtualization Library (libOVD)の構成が必要になります。
libOVDを構成するには、WLSTコマンドのaddLDAPHost
を使用します。libOVDを管理する場合は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のIdentity Virtualization Library (libOVD)アダプタの管理に関する説明でWLSTコマンドのリストを参照してください。
Oracle Identity Managerは、Oracle WebLogic ServerにnostageアプリケーションとしてデプロイされるJava EEアプリケーションです。Oracle Identity Managerサーバーは、それがデプロイされたWebLogic Serverの起動時に初期化されます。アプリケーションの初期化の一部として、クォーツ・ベースのスケジューラも起動されます。初期化が完了すると、システムはクライアントからリクエストを受信できるようになります。
Remote ManagerおよびDesign Consoleは別にスタンドアロンのユーティリティとして起動する必要があります。
Oracle Identity Managerは、外部的に管理されるアプリケーションとしてOracle WebLogic Serverにデプロイされます。WebLogic Serverはデフォルトで、Oracle Identity Managerアプリケーションに対する他のライフサイクル・イベントの起動、停止、監視および管理を行います。
Oracle Identity Managerは、標準Java EEアプリケーションであり、アプリケーション・サーバー・コンポーネントが起動した後に起動します。また、Oracle Identity Managerでは、Oracle Identity Managerコンポーネント・メカニズムの一部である認証システムも使用され、それはWebLogic JNDIが初期化されてアプリケーションが起動する前に起動されます。これは、OIM ORACLE_HOMEからロードされます。
Oracle Identity Managerでは、クォーツ・ベースのスケジューラが使用されます。クォーツは、すべてのWebLogic Serverインスタンスでスケジューラ・スレッドを起動します。データベースが、スケジュール済アクティビティの選択と実行のための中央記憶域として使用されます。スケジューラ・インスタンスの1つがジョブを選択した場合、その他のインスタンスがその同じジョブを選択することはありません。
Oracle Identity Managerは、データベースから、サーバー・インスタンスのメモリー内のキャッシュに特定のシステム構成値をキャッシュします。これらのキャッシュは独立してロードされ、サーバー間で共有されません。システム構成が変更されるとキャッシュがクリーンアップされ、これはクラスタ内のすべてのサーバーに通知されます。Oracle Identity Managerは、この目的のためにOSCache、JGroupsを使用します。JGroupsはマルチキャスト・アドレスを使用します。有効なマルチキャスト・アドレスは、インストール中にランダムに生成され、Oracle Identity Managerメタデータ・リポジトリ・ファイルにシードされます。
WebLogicノード・マネージャは、サーバー・プロセスを監視し、障害発生時にそのプロセスを再起動するように構成できます。
Oracle Enterprise Manager Fusion Middleware Controlは、アプリケーションの監視および構成の変更に使用します。
Oracle Identity Managerのライフサイクル・イベントは、次に示すコマンドライン・ツールおよびコンソールを1つ以上使用して管理できます。
Oracle WebLogic Scripting Tool(WLST)
WebLogic Server管理コンソール
Oracle Enterprise Manager Fusion Middleware Control
Oracle WebLogicノード・マネージャ
Oracle Identity Managerサーバーの構成は、MDSリポジトリに格納され、MBeanを使用して管理されます。oim-config.xmlファイルがメイン構成ファイルです。OIM構成は、Oracle Enterprise Manager Fusion Middleware ControlまたはコマンドラインMDSユーティリティを介してMBeanブラウザを使用して管理します。oim-config.xmlファイルは、MDSリポジトリの/db/oim-config.xmlの場所に格納されています。
MDSユーティリティの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のMDSユーティリティに関する説明を参照してください。
JMSは、インストーラによってすぐに使用可能な状態に構成されます。JMSキュー、接続プール、データ・ソースなど必要なものはすべて、WebLogicアプリケーション・サーバー上に構成されます。次のキューが、Oracle Identity Managerをデプロイするときに作成されます。
oimAttestationQueue
oimAuditQueue
oimDefaultQueue
oimKernelQueue
oimProcessQueue
oimReconQueue
oimSODQueue
Design ConsoleおよびRemote Managerの構成は、xlconfig.xml
に格納されます。
Oracle Identity Managerは、Oracle WebLogic管理対象サーバーにデプロイされるJava EEアプリケーションです。Oracle Identity Managerは、Oracle SOA Suiteのワークリストおよびヒューマン・ワークフロー・モジュールを使用して、そのリクエスト・フローを管理します。Oracle Identity Managerは、外部リポジトリと対話して、構成およびランタイム・データを格納します。Oracle Identity Managerでは、初期化およびランタイム時に、これらのリポジトリが使用可能である必要があります。Oracle Identity Managerの資格証明はすべて、OIMリポジトリに格納されます。Oracle Identity Managerサーバーの機能に必要な外部コンポーネントは次のとおりです。
WebLogic Server
管理サーバー
管理対象サーバー
データ・リポジトリ
構成リポジトリ(MDSスキーマ)
ランタイム・リポジトリ(OIMスキーマ)
ユーザー・リポジトリ(OIMスキーマ)
SOAリポジトリ(SOAスキーマ)
外部LDAPストア(LDAP同期を使用する場合)
BI Publisher
Design Consoleは、管理者が、開発とカスタマイズのために使用するツールです。Design Consoleは、Oracle Identity Managerエンジンと直接通信し、Oracle Identity Managerサーバーが依存するものと同じコンポーネントに依存します。
Remote Managerは、オプションの独立したスタンドアロン・アプリケーションであり、ローカル・システムのカスタムAPIを呼び出します。そのため、それらのカスタムAPIのJARファイルがそのクラスパスに含まれている必要があります。
Oracle Identity Managerは、Oracle WebLogic ServerにデプロイされるJava EEアプリケーションです。サーバーに関連するログ・メッセージはすべて、サーバーのログ・ファイルに記録され、Oracle Identity Managerに固有のメッセージはすべて、アプリケーションがデプロイされたWebLogic Serverの診断ログ・ファイルに記録されます。
WebLogic Serverのログ・ファイルは、次のディレクトリに配置されます。
DOMAIN_HOME/servers/serverName/logs
主なログ・ファイルは、serverName.log、serverName.outおよびserverName-diagnostic.logの3つですが、ここでserverNameはWebLogic Serverの名前です。たとえば、WebLogic Server名がwls_OIM1の場合、診断ログ・ファイル名はwls_OIM1-diagnostic.logになります。
このログ・ファイルは、Oracle Enterprise Manager Fusion Middleware Controlを使用して表示できます。
この項では、Oracle Identity Managementの高可用性の概要およびOracle Identity Managerの高可用性環境の設計とデプロイについて説明します。
注意: Oracle Identity Managerを高可用性構成にデプロイする場合は、次のことに注意してください。
|
図9-2は、アクティブ/アクティブ構成で高可用性アーキテクチャにデプロイされたOracle Identity Managerを示しています。
OIMHOST1では、次のインストールが実行されています。
Oracle Identity ManagerインスタンスはWLS_OIM1管理対象サーバーにインストールされており、SOAインスタンスはWLS_SOA1管理対象サーバーにインストールされています。
Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
WebLogic管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。
OIMHOST2では、次のインストールが実行されています。
Oracle Identity ManagerインスタンスはWLS_OIM2管理対象サーバーにインストールされており、SOAインスタンスはWLS_SOA2管理対象サーバーにインストールされています。
Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
OIMHOST1およびOIMHOST2上のWLS_OIM1およびWLS_OIM2管理対象サーバーのインスタンスは、OIM_Clusterクラスタとして構成されています。
OIMHOST1およびOIMHOST2上のWLS_SOA1およびWLS_SOA2管理対象サーバーのインスタンスは、SOA_Clusterクラスタとして構成されています。
WebLogic管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。OIMHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。
図9-2のOracle Identity Managerの高可用性構成では、次の仮想ホスト名が使用されています。
OIMVHN1は、WLS_OIM1管理対象サーバーのリスニング・アドレスにマップし、WLS_OIM1管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。WLS_OIM1管理対象サーバーが実行されているノード(デフォルトではOIMHOST1)で有効化されます。
OIMVHN2は、WLS_OIM2管理対象サーバーのリスニング・アドレスにマップし、WLS_OIM2管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。WLS_OIM2管理対象サーバーが実行されているノード(デフォルトではOIMHOST2)で有効化されます。
SOAVHN1は、WLS_SOA1管理対象サーバーのリスニング・アドレスで、WLS_SOA1管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。WLS_SOA1管理対象サーバーが実行されているノード(デフォルトではOIMHOST1)で有効化されます。
SOAVHN2は、WLS_SOA2管理対象サーバーのリスニング・アドレスで、WLS_SOA2管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。WLS_SOA2管理対象サーバーが実行されているノード(デフォルトではOIMHOST2)で有効化されます。
VHNは、Oracle Real Application Clusters(Oracle RAC)データベース・ホストの仮想IPアドレスを指します。
高可用性アーキテクチャでは、Oracle Identity Managerは、Oracle WebLogicクラスタにデプロイされます。このクラスタには、クラスタのメンバーとして少なくとも2つのサーバーが存在します。
デフォルトでは、WebLogic Serverによって、このアプリケーションに対する様々なライフサイクル・イベントの起動、停止、監視および管理が行われます。Oracle Identity Managerアプリケーションは、基盤となるOracle WebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。
Oracle Identity Managerのライフサイクル・イベントは、次に示すコマンドライン・ツールおよびコンソールを1つ以上使用して管理できます。
WebLogic Server管理コンソール
Oracle Enterprise Manager Fusion Middleware Control
Oracle WebLogic Scripting Tool(WLST)
高可用性環境では、1つのOracle Identity Managerインスタンスの構成変更により、他のすべてのインスタンスの構成が変更されます。これは、すべてのOracle Identity Managerインスタンスが同じ構成リポジトリを共有しているためです。
この項では、Oracle Identity Managerで高可用性を得るためのデプロイメントを設定する高度な手順について説明します。
この項には、高可用性を得るためのOracle Identity Managementの構成に関する次の項目があります。
Oracle Identity Managerを高可用性のために構成する前に、次の操作を実行しておく必要があります。
データベースに OIMスキーマを作成するためにリポジトリ作成ユーティリティを実行します。手順は、第9.1.3.1.1項「データベースにOIMスキーマを作成するためのRCUの実行」を参照してください。
OIMHOST1およびOIMHOST2にWebLogicサーバーをインストールします。手順は、第9.1.3.1.2項「Oracle WebLogic Serverのインストール」を参照してください。
OIMHOST1およびOIMHOST2にOracle SOA Suiteをインストールします。手順は、第9.1.3.1.3項「OIMHOST1およびOIMHOST2へのOracle SOA Suiteのインストール」を参照してください。
OIMHOST1およびOIMHOST2にOracle Identity Managementソフトウェアをインストールします。手順は、第9.1.3.1.4項「OIMHOST1およびOIMHOST2へのOracle Identity Managerのインストール」を参照してください。
高可用性LDAP実装が使用可能であることを確認します。
注意: この項は、LDAPSyncが有効なOracle Identity Managerインストール、およびOracle Access Managementと統合されているOracle Identity Managerインストールでのみ必要です。 LDAPSyncオプションの有効化や、Oracle Access Managementとの統合を計画していない場合は、この項をスキップできます。 |
Oracle Internet Directoryのインストールと構成の詳細は、第8.3.3項「Oracle Internet Directoryの高可用性の構成手順」を参照してください。Oracle Virtual Directoryのインストールと構成の詳細は、第8.4.3項「Oracle Virtual Directoryの高可用性の構成手順」を参照してください。Oracle Identity Managerは、Oracle Internet Directoryと直接通信しないことに注意してください。それは、Oracle Virtual Directoryと通信し、Oracle Virtual DirectoryがOracle Internet Directoryと通信します。
wlfullclient.jar
ファイルを、OIMHOST1およびOIMHOST2で作成します。
Oracle Identity Managerでは、特定の操作にwlfullclient.jar
ライブラリが必要です。たとえば、Design Consoleでは、サーバー接続にこのライブラリを使用します。このライブラリは出荷されていないため、手動で作成する必要があります。このライブラリは、環境のアプリケーション層にあるすべてのマシンのMW_HOME/wlserver_10.3/server/lib
ディレクトリの下に作成することをお薦めします。このライブラリは、OIDHOST1、OIDHOST2、OVDHOST1、OVDHOST2などのディレクトリ層マシンに作成する必要はありません。詳細は、Oracle Fusion Middleware Oracle WebLogic Serverスタンドアロン・クライアントのプログラミングのWebLogicフル・クライアントの開発に関する説明を参照してください。
wlfullclient.jarファイルを作成するには、次の手順を実行します。
MW_HOME/wlserver_10.3/server/lib
ディレクトリに移動します。
JAVA_HOMEをMW_HOME/jdk160_18
に設定し、JAVA_HOME/bin
ディレクトリがパスに含まれていることを確認します。
次のファイルを実行することによって、wlfullclient.jar
ファイルを作成します。
java -jar wljarbuilder.jar
OIMHOST1およびOIMHOST2にOracle Identity ManagerおよびSOAインスタンスをインストールする前に、リポジトリ作成ユーティリティ(RCU)を使用して、Oracle Identity Managerで使用するスキーマのコレクションを作成しておく必要があります。
RCUは、Oracle Fusion Middleware 11gキットの部品として付属する専用のCDに収録されています。
RCUを実行し、Oracle RACデータベース・リポジトリにOracle Identity Managerスキーマを作成するには、次の手順を実行します。
次のコマンドを発行します。
prompt> RCU_HOME/bin/rcu &
「ようこそ」画面で、「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」操作を選択してコンポーネント・スキーマを既存のデータベースにロードします。
「次へ」をクリックします。
「データベース接続の詳細」画面で、既存のデータベースの接続情報を次のように入力します。
データベース・タイプ: Oracle Database
ホスト名: データベースを実行しているコンピュータの名前。Oracle RACデータベースの場合は、VIP名またはノード名を指定します。例: OIMDBHOST1-VIPまたはOIMDBHOST2-VIP
ポート: データベースのポート番号。例: 1521
サービス名: データベースのサービス名。例: oim.mycompany.com
ユーザー名: SYS
パスワード: SYSユーザーのパスワード
ロール: SYSDBA
「次へ」をクリックします。
グローバルな前提条件が完了したら、「前提条件チェック」画面で「OK」をクリックします。
「コンポーネントの選択」画面で、新しい接頭辞を作成して、このデプロイメントに関連するコンポーネントを選択します。
接頭辞の新規作成: ha
コンポーネント:
「アイデンティティ管理」の下では、次のように指定します。
Oracle Identity Manager - OIM
Oracle Platform Security Services - OPSS
デフォルトで、「Metadata Services - MDS」が選択されていることに注意してください。
「SOAおよびBAMインフラストラクチャ」の下で:
SOAインフラストラクチャ: デフォルトで、SOAINFRAが選択済です。
ユーザー・メッセージング・サービス: デフォルトで、ORASDPMが選択済です。
「次へ」をクリックします。
コンポーネントの前提条件が完了したら、「前提条件チェック」画面で「OK」をクリックします。
「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力します。
「次へ」をクリックします。
「表領域のマップ」画面で、コンポーネントの表領域を選択します。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。
WebLogic Serverをインストールする前に、お使いのマシンが、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』に指定されているシステム、パッチ、カーネルなどの要件を満たしていることを確認します。
インストーラを起動し、OIMHOST1およびOIMHOST2で次の手順を実行します。
「ようこそ」画面で、「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で、「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。
ORACLE_BASE/product/fmw
注意: ORACLE_BASEは、Oracle製品のインストール先であるベース・ディレクトリです。推奨値は |
「次へ」をクリックします。
セキュリティ・アップデートが通知されるようにするために、「セキュリティ更新のための登録」画面で連絡先情報を入力します。
「次へ」をクリックします。
「インストール・タイプの選択」画面で、「カスタム」を選択します。
「次へ」をクリックします。
「製品とコンポーネントの選択」画面で、「Oracle JRockit SDK」のみを選択し、「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、ディレクトリORACLE_BASE/product/fmw/wlserver_10.3
を受け入れます。
「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「Quickstartの実行」の選択を解除します。
「完了」をクリックします。
次の手順を実行して、Oracle Fusion MiddlewareコンポーネントをOIMHOST1およびOIMHOST2にインストールします。
Linuxプラットフォームで、/etc/oraInst.loc
ファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.loc
ファイルが存在しない場合、この手順をスキップできます。
次のようにOracle Fusion Middlewareコンポーネントのインストーラを起動します。
HOST1> runInstaller
インストーラで、JRE/JDK
の場所を入力するよう求められたら、WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE
/product/fmw/jrockit_160_14_
<バージョン>のように入力します。
次のように実行します。
「ようこそ」画面で、「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を入力します。
Oracle Middlewareホーム: MW_HOME
のリストから前にインストールしたMiddlewareホームを選択します。次に例を示します。
/u01/app/oracle/product/fmw
Oracleホーム・ディレクトリ:
ORACLE_HOME
にOracle SOA Suiteをインストールするときに、Oracleホーム・ディレクトリ名としてsoa
を入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
プロンプトが表示されたら、LinuxおよびUNIXインストールでは、root
ユーザーとして、スクリプトoracleRoot.sh
を実行します。
「インストール完了」画面で「終了」をクリックします。
次の手順を実行して、Oracle Fusion MiddlewareコンポーネントをOIMHOST1およびOIMHOST2にインストールします。
Linuxプラットフォームで、/etc/oraInst.loc
ファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.loc
ファイルが存在しない場合、この手順をスキップできます。
次のようにOracle Fusion Middlewareコンポーネントのインストーラを起動します。
HOST1> runInstaller
インストーラで、JRE/JDK
の場所を入力するよう求められたら、WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE
/product/fmw/jrockit_160_
<バージョン>のように入力します。
次のように実行します。
「ようこそ」画面で、「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を入力します。
Oracle Middlewareホーム: MW_HOME
のリストから前にインストールしたMiddlewareホームを選択します。次に例を示します。
/u01/app/oracle/product/fmw
Oracleホーム・ディレクトリ:
ORACLE_HOME
にOracle Identity and Access Management Suiteをインストールするときは、Oracleホーム・ディレクトリ名としてiam
を入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
「インストール完了」画面で「終了」をクリックします。
OIMHOST1にドメインを作成するには、次の手順を実行します。
このコマンドを実行して、構成ウィザードを起動します。
MW_HOME/oracle_common/common/bin/config.sh
「ようこそ」画面で、「WebLogicドメインの作成」を選択します。
「次へ」をクリックします。
「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。
リストから、次のように選択します。
Oracle Identity Manager
Oracle SOA Suite、Oracle Enterprise Manager、Oracle Platform Security Service、Oracle JRF、Oracle JRF WebServices AsynchronousサービスおよびOracle WSM Policy Managerが自動的に選択されます。
Oracle Enterprise Manager
Oracle JRFが自動的に選択されます。
「ドメイン名と場所の指定」画面で、ドメインおよびそのすべてのアプリケーションの名前と場所を入力します。
次の項目を入力します。
ドメイン名: IDMDomain
ドメインの場所: デフォルトを受け入れます。
アプリケーションの場所: デフォルトを受け入れます。
「次へ」をクリックします。
管理サーバーのユーザー名とパスワードの構成画面で、次のように入力します。
名前: weblogic
User Password: weblogic
ユーザーのパスワードを入力します。
Confirm User Password: weblogic
ユーザーのパスワードを入力します。
Description: ユーザーの説明を入力します。
「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、「本番モード」および「JRockit SDK 1.6.n」を選択します。
「次へ」をクリックします。
「JDBCコンポーネント・スキーマの構成」画面で、次に示すコンポーネント・スキーマを選択します。
SOAインフラストラクチャ
ユーザー・メッセージング・サービス
OIM MDSスキーマ
OWSM MDSスキーマ
SOA MDSスキーマ
OIMインフラストラクチャ
OPSSスキーマ
「次のパネルで選択したコンポーネント・スキーマをRACマルチ・データ・ソース・スキーマとして構成します。」の横のチェック・ボックスを選択します。
「次へ」をクリックします。
「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、マルチ・データ・ソース・スキーマをすべて選択し、次の項目を入力します。
サービス名: oim.mycompany.com
最初のRACノードの場合は、次のように入力します。
ホスト名: OIMDBHOST1-VIP.mycompany.com
インスタンス名: oimdb1
ポート: 1521
2つ目のRACノードの場合は、次のように入力します。
ホスト名: OIMDBHOST2-VIP.mycompany.com
インスタンス名: oimdb2
ポート: 1521
各スキーマを個別に選択し、スキーマのユーザー名とパスワードを表9-1に示すように入力します。
表9-1 各マルチ・データ・ソース・スキーマのスキーマ所有者とパスワードの入力
スキーマ名 | スキーマ所有者 | パスワード |
---|---|---|
SOAインフラストラクチャ |
HA_SOAINFRA |
<パスワードを入力> |
ユーザー・メッセージング・サービス |
HA_ORASDPM |
<パスワードを入力> |
OIM MDSスキーマ |
HA_MDS |
<パスワードを入力> |
OWSM MDSスキーマ |
HA_MDS |
<パスワードを入力> |
SOA MDSスキーマ |
HA_MDS |
<パスワードを入力> |
OIMスキーマ |
HA_OIM |
<パスワードを入力> |
「次へ」をクリックします。
「コンポーネント・スキーマのテスト」画面で、すべてのスキーマを選択して「接続のテスト」をクリックします。すべてのスキーマに対するテストが正常に完了したことを確認します。
「次へ」をクリックします。
「オプションの構成を選択」画面で、次を選択します。
管理サーバー
JMS分散宛先 (OIMのインストールされたドメインでのみ必要)
管理対象サーバー、クラスタ、およびマシン
JMSファイル・ストア (OIMのインストールされたドメインでのみ必要)
「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: oimhost1.mycompany.com
リスニング・ポート: 7001
SSLリスニング・ポート: 適用なし
SSL有効: 選択を解除
「次へ」をクリックします。
「JMS分散宛先タイプの選択」画面で、リストされているすべてのJMSシステム・リソースが共通分散宛先であることを確認します。そのようになっていない場合は、ドロップダウン・ボックスから「UDD」を選択します。エントリが表9-2に示すように設定されていることを確認します。
表9-2 JMSシステム・リソースに対して選択する値
JMSシステム・リソース | 共通/重み設定された分散宛先 |
---|---|
UMSJMSSystemResource |
UDD |
SOAJMSModule |
UDD |
OIMJMSModule |
UDD |
BPMJMSModule |
UDD |
「次へ」をクリックします。
「オーバーライドの警告」ボックスに次のメッセージが表示されます。
「CFGFWK-40915: 共通分散宛先(UDD)への変換対象として少なくとも1つのJMSシステム・リソースが選択されています。この変換は、JMSシステム・リソースがクラスタに割り当てられている場合にのみ行われます。」
「警告」ボックスで「OK」をクリックします。
「管理対象サーバーの構成」画面を初めて表示した場合、構成ウィザードによって2つのデフォルト管理対象サーバー(oim_server1とsoa_server1)が作成されています。デフォルトの管理対象サーバーの詳細を変更し、2つ目の管理対象サーバーを追加します。次の手順に従います。
oim_server1エントリについては、そのエントリを次の値に変更します。
名前: WLS_OAM1
リスニング・アドレス: OIMVHN1
リスニング・ポート: 14000
soa_server1エントリについては、そのエントリを次の値に変更します。
名前: WLS_SOA1
リスニング・アドレス: SOAVHN1
リスニング・ポート: 8001
2つ目のOIMサーバーに対して、「追加」をクリックし、次の情報を入力します。
名前: WLS_OIM2
リスニング・アドレス: OIMVHN2
リスニング・ポート: 14000
2つ目のSOAサーバーに対して、「追加」をクリックし、次の情報を入力します。
名前: WLS_SOA2
リスニング・アドレス: SOAVHN2
リスニング・ポート: 8001
「次へ」をクリックします。
注意: さらに管理対象サーバーを追加するには、2つ目の管理対象サーバーを追加するための手順に従ってください。 |
「クラスタの構成」画面で、「追加」をクリックして2つのクラスタを作成します。
OIMクラスタに関して次の情報を入力します。
名前: oim_cluster
クラスタのメッセージング・モード: unicast
クラスタ・アドレス: oimhost1:14000,oimhost2:14000
SOAクラスタに関して次の情報を入力します。
名前: soa_cluster
クラスタのメッセージング・モード: unicast
クラスタ・アドレス: oimhost1:8001,oimhost2:8001
他のフィールドはすべてデフォルト設定のままにして、「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタと関連付けます。右のウィンドウでクラスタ名をクリックします。
サーバーの下の管理対象サーバーをクリックし、矢印をクリックしてそれをクラスタに割り当てます。
WLS_OIM1およびWLS_OIM2管理対象サーバーをoim_clusterのメンバーになるように割り当てます。
WLS_SOA1およびWLS_SOA2管理対象サーバーをsoa_clusterのメンバーになるように割り当てます。
「次へ」をクリックします。
「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。
ホストでUnixオペレーティング・システムを使用する場合は、「Unix」タブを、それ以外の場合は、「マシン」をクリックします。
次の情報を指定します。
名前: ホスト名です。ここでは、DNS名を使用することをお薦めします。
ノード・マネージャ・リスニング・アドレス: ここにマシンのDNS名を入力します。
ノード・マネージャ・ポート: ノード・マネージャが使用するポートを入力します。
「次へ」をクリックします。
注意: UNIXでは、「マシン」タブの下のデフォルト・ローカル・マシン・エントリを削除します。 |
「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを割り当てます。次の手順を実行します。
右側のウィンドウでマシンをクリックします。
左側のウィンドウで、そのマシン上で実行する管理対象サーバーをクリックします。
矢印をクリックし、その管理対象サーバーをそのマシンに割り当てます。
すべての管理対象サーバーが適切なマシンに割り当てられるまで、この手順を繰り返します。
一般的な例は、次のようになります。
Host1: Admin Server、WLS_OIM1、およびWLS_SOA1
Host2: WLS_OIM2およびWLS_SOA2
「次へ」をクリックします。
「JMSファイル・ストアの構成」画面で、JMSファイル・ストアのディレクトリの場所を更新します。次の値を入力します。
名前 | ディレクトリ |
---|---|
UMSJMSFileStore_auto_1 |
|
BPMJMSServer_auto_1 |
|
BPMJMSServer_auto_1 |
|
BPMJMSServer_auto_2 |
|
SOAJMSFileStore_auto_1 |
|
SOAJMSFileStore_auto_2 |
|
OIMJMSFileStore_auto_1 |
|
OIMJMSFileStore_auto_2 |
|
「構成のサマリー」画面で、「作成」をクリックしてドメインを作成します。
データベース・セキュリティ・ストアには、セキュリティ・ポリシー、監査メタデータ、資格証明、キー、およびOPSSによって管理されるその他のセキュリティ・アーティファクトが格納されます。トポロジ内のポリシーが重複しないように動作することで、ドメイン構成(単一、複数または拡張)に関係なく高可用性を円滑化します。
ドメインの構成後、管理サーバーを起動する前に、データベース・セキュリティ・ストアを構成する必要があります。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Identity and Access Managementドメインに対するデータベース・セキュリティ・ストアの構成に関する項を参照してください。
この項では、OIMHOST1で実行するインストール後の手順について説明します。次のトピックが含まれます:
この項では、OIMHOST1上の管理サーバー用boot.propertiesファイルを作成する方法を説明します。boot.propertiesファイルによって、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できます。
次の手順に従って、boot.propertiesファイルを作成します。
OIMHOST1で、次のディレクトリを作成します。
MW_HOME/user_projects/domains/domainName/servers/AdminServer/security
例:
$ mkdir -p MW_HOME/user_projects/domains/domainName/servers/AdminServer/security
テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。
username=adminUser password=adminUserPassword
注意: 管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。 セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。 |
WebLogic管理コンソールを使用して管理対象サーバーを起動する前に、ノード・マネージャではStartScriptEnabledプロパティがtrueに設定されていることが必要です。
これを行うには、次のディレクトリの下にあるsetNMProps.shスクリプトを実行します。
MW_HOME/oracle_common/common/bin
次のディレクトリの下にあるstartNodeManager.shスクリプトを使用してOIMHOST1上のノード・マネージャを起動します。
MW_HOME/wlserver_10.3/server/bin
次の手順に従い、管理サーバーを起動し、その起動を確認します。
次のコマンドを実行し、OIMHOST1上の管理サーバーを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
Webブラウザを開いて次のページにアクセスし、管理サーバーの起動が正常に行われたことを確認します。
次の場所にある管理コンソール:
http://oimhost1.mycompany.com:7001/console
Oracle Enterprise Manager Fusion Middleware Control:
http://oimhost1.mycompany.com:7001/em
weblogic
ユーザーの資格証明を使用して、これらのコンソールにログインします。
この項では、Oracle Identity ManagerとSOA管理対象サーバーの起動前の構成方法について説明します。
この項の内容は次のとおりです。
Oracle Identity Managerを構成する前に、次のタスクが実行済であることを確認します。
注意: この項は、LDAPSyncが有効なOracle Identity Managerインストール、およびOracle Access Managementと統合されているOracle Identity Managerインストールでのみ必要です。 LDAPSyncオプションの有効化や、Oracle Access Managementとの統合を計画していない場合は、この項をスキップできます。 |
Oracle Identity Manager用のディレクトリ・スキーマの拡張
アイデンティティ・ストアを事前構成することで、ディレクトリ・タイプに関係なくバックエンド・ディレクトリのスキーマを拡張します。
アイデンティティ・ストアを事前構成するには、OIMHOST1で次の手順を実行します。
環境変数MW_HOME
、JAVA_HOME
およびORACLE_HOME
を設定します。
ORACLE_HOME
をIAM_ORACLE_HOME
に設定します。
次の項目を含む、プロパティ・ファイルextend.props
を作成します。
IDSTORE_HOST : idstore.mycompany.com
IDSTORE_PORT : 389
IDSTORE_BINDDN: cn=orcladmin
IDSTORE_USERNAMEATTRIBUTE: cn
IDSTORE_LOGINATTRIBUTE: uid
IDSTORE_USERSEARCHBASE: cn=Users,dc=mycompany,dc=com
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=mycompany,dc=com
IDSTORE_SEARCHBASE: dc=mycompany,dc=com
IDSTORE_SYSTEMIDBASE: cn=systemids,dc=mycompany,dc=com
説明:
IDSTORE_HOST
およびIDSTORE_PORT
は、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。非OIDディレクトリを使用している場合は、Oracle Virtual Directoryのホストを指定します(これは、IDSTORE.mycompany.comになるはずです)。
IDSTORE_BINDDN
は、アイデンティティ・ストア・ディレクトリの管理ユーザーです。
IDSTORE_USERSEARCHBASE
は、ユーザーが格納されるディレクトリの場所です。
IDSTORE_GROUPSEARCHBASE
は、グループが格納されるディレクトリの場所です。
IDSTORE_SEARCHBASE
は、ユーザーおよびグループを格納するディレクトリの場所です。
IDSTORE_SYSTEMIDBASE
は、メイン・ユーザー・コンテナに配置する必要のないユーザーを配置できるディレクトリにあるコンテナの場所です。このような事態はほとんどありませんが、その一例としてOracle Virtual DirectoryアダプタのバインドDNユーザーにも使用されるOracle Identity Managerリコンシリエーション・ユーザーがあげられます。
idmConfigTool
コマンドを使用して、アイデンティティ・ストアを作成します。このコマンドは、IAM_ORACLE_HOME/idmtools/bin
にあります。
Linuxのコマンド構文:
idmConfigTool.sh -preConfigIDStore input_file=configfile
Windowsのコマンド構文:
idmConfigTool.bat -preConfigIDStore input_file=configfile
例:
idmConfigTool.sh -preConfigIDStore input_file=extend.props
このコマンドを実行すると、IDストアへの接続に使用しているアカウントのパスワードを求めるプロンプトがシステムによって表示されます。
次に、コマンドの出力例を示します。
./preconfig_id.sh Enter ID Store Bind DN password : Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_template.ldif Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_acl_template.ldif Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/systemid_pwdpolicy.ldif Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idstore_tuning.ldifApr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oid_schema_extn.ldif The tool has completed its operation. Details have been logged to automation.log
ログ・ファイルを確認して、エラーや警告を修正します。
Oracle Identity Manager用のユーザーとグループの作成
oimadmin
ユーザーをアイデンティティ・ストアに追加する手順を実行して、そのユーザーをOracle Identity Manager管理者グループに割り当てます。また、リコンシリエーションを実行するために、標準の場所cn=Users
以外にもユーザーを作成します。Oracle Virtual Directoryを使用したディレクトリに直接接続するときには、このユーザーをバインドDNとして選択することをお薦めします。
注意: このコマンドでは、アイデンティティ・ストアに予約用のコンテナも作成します。 |
xelsysadm
ユーザーをアイデンティティ・ストアに追加して、そのユーザーを管理グループに割り当てるには、OIMHOST1
で次のタスクを実行します。
環境変数MW_HOME
、JAVA_HOME
、IDM_HOME
およびORACLE_HOME
を設定します。
IDM_HOME
をIDM_ORACLE_HOME
に設定します。
ORACLE_HOME
をIAM_ORACLE_HOME
に設定します。
次の項目を含む、プロパティ・ファイルoim.props
を作成します。
IDSTORE_HOST : idstore.mycompany.com
IDSTORE_PORT : 389
IDSTORE_BINDDN : cn=orcladmin
IDSTORE_USERNAMEATTRIBUTE: cn
IDSTORE_LOGINATTRIBUTE: uid
IDSTORE_USERSEARCHBASE:cn=Users,dc=mycompany,dc=com
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=us,dc=oracle,dc=com
IDSTORE_SEARCHBASE: dc=mycompany,dc=com
POLICYSTORE_SHARES_IDSTORE: true
IDSTORE_SYSTEMIDBASE: cn=systemids,dc=mycompany,dc=com
IDSTORE_OIMADMINUSER: oimadmin
IDSTORE_OIMADMINGROUP:OIMAdministrators
説明:
IDSTORE_HOST
およびIDSTORE_PORT
は、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。OVDではなく、バックエンド・ディレクトリを指定します。
IDSTORE_BINDDN
は、アイデンティティ・ストア・ディレクトリの管理ユーザーです。
IDSTORE_OIMADMINUSER
は、Oracle Identity Managerコンソールにログインするために使用する、管理ユーザーの名前です。
IDSTORE_OIMADMINGROUP
は、Oracle Identity Manager管理ユーザーを保持するために作成するグループの名前です。
IDSTORE_USERSEARCHBASE
は、ユーザーを配置するアイデンティティ・ストアの場所です。
IDSTORE_GROUPSEARCHBASE
は、グループを配置するアイデンティティ・ストアの場所です。
IDSTORE_SYSTEMIDBASE
は、Oracle Identity Managerリコンシリエーション・ユーザーを配置するディレクトリの場所です。
POLICYSTORE_SHARES_IDSTORE
は、ポリシー・ストアとアイデンティティ・ストアが同じディレクトリに存在する場合にはtrueを設定します。そうでない場合は、falseを設定します。
idmConfigToolコマンドを使用してアイデンティティ・ストアを構成します。このコマンドは、IAM_ORACLE_HOME/idmtools/bin
にあります。
Linuxコマンドの構文:
idmConfigTool.sh -prepareIDStore mode=OIM input_file=configfile
Windowsコマンドの構文:
idmConfigTool.bat -prepareIDStore mode=OIM input_file=configfile
例:
idmConfigTool.sh -preConfigIDStore input_file=oim.props
このコマンドを実行すると、アイデンティティ・ストアへの接続に使用しているアカウントのパスワードを求めるプロンプトがシステムによって表示されます。また、システムは、そのアカウントに割り当てるパスワードの入力も要求します。
IDSTORE_OIMADMINUSER oimadmin
oimadmin
は、Oracle Identity Manager構成の一部として作成したアカウントと同じ値を設定するようにお薦めします。
次に、コマンドの出力例を示します。
Enter ID Store Bind DN password : *** Creation of oimadmin *** Apr 5, 2011 4:58:51 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_user_template.ldif Enter User Password for oimadmin: Confirm User Password for oimadmin: Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_group_template.ldif Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_group_member_template.ldif Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_groups_acl_template.ldif Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_reserve_template.ldif *** Creation of Xel Sys Admin User *** Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oam_user_template.ldif Enter User Password for xelsysadm: Confirm User Password for xelsysadm: The tool has completed its operation. Details have been logged to /home/oracle/idmtools/oim.log
ログ・ファイルを確認して、エラーや警告を修正します。
Oracle Virtual Directoryでのアダプタの作成
Oracle Identity Managerは、Oracle Virtual Directoryを使用して外部LDAPストアに接続します。Oracle Identity ManagerがOracle Internet Directoryなどの外部LDAPストアに接続できるようにするには、ユーザー・アダプタと変更ログ・アダプタをOracle Virtual Directoryに作成する必要があります。次の手順に従って、アダプタを作成します。
注意: Oracle Internet Directoryのみを実装する場合は、Oracle Virtual Directoryにアダプタを作成する必要はありません。 |
ユーザー・アダプタ
OVDHOST1
とOVDHOST2
上で実行されているOracle Virtual Directoryインスタンスそれぞれにユーザー・アダプタを作成します。
Oracle Directory Services Managerを使用して、Oracle Virtual Directoryにユーザー・アダプタを作成する手順は次のとおりです。
ブラウザを開き、ODSMコンソール(http://admin.mycompany.com/odsm
)を表示します。
注意: Oracle Directory Services Managerは、図9-2には記載されていませんが、Oracle Internet DirectoryとOracle Virtual Directoryを管理するために必要です。Oracle Directory Services Managerが環境に存在している必要があります。 |
OVDHOST1
とOVDHOST2
上で実行されているOracle Virtual Directoryインスタンスそれぞれへの接続がまだ存在していない場合は、作成します。
適切な接続エントリを使用して、各Oracle Virtual Directoryインスタンスに接続します。
ホームページで、「アダプタ」タブをクリックします。
アダプタ・ウィンドウの上部にある「アダプタの作成」をクリックして、「新規アダプタ・ウィザード」を起動します。
「新規アダプタ・ウィザード」で次のパラメータを指定して、新しいアダプタを作成します。
注意: 前にユーザー・アダプタを作成した場合は、アダプタを作成する手順をスキップし、アダプタを編集する手順に従います。 |
画面 | フィールド | 値/手順 |
---|---|---|
タイプ |
アダプタ・タイプ |
|
アダプタ名 |
|
|
アダプタ・テンプレート |
|
|
接続 |
DNS設定を使用 |
いいえ |
ホスト |
|
|
ポート |
|
|
サーバー・プロキシ・バインドDN |
|
|
プロキシ・パスワード |
|
|
接続テスト |
テストが正常に行われたことを確認します。 |
|
ネームスペース |
リモート・ベース |
|
マップされたネームスペース |
|
|
概要 |
概要に誤りがないことを確認し、「終了」をクリックします。 |
ユーザー・アダプタを次のように編集します。
OIMユーザー・アダプタを選択します。
「プラグイン」タブをクリックします。
「ユーザー管理」プラグインをクリックし、プラグイン表で「編集」をクリックします。プラグインの編集ウィンドウが表示されます。
「パラメータ」表で、次のようにパラメータ値を更新します。
パラメータ | 値 |
---|---|
directoryType |
oid |
pwdMaxFailure |
10 |
oamEnabled |
true |
「OK」をクリックします。
「適用」をクリックします。
変更ログ・アダプタ
OVDHOST1
とOVDHOST2
上で実行されているOracle Virtual Directoryインスタンスそれぞれに変更ログ・アダプタを作成します。次の手順に従い、Oracle Directory Services Managerを使用してOracle Virtual Directoryに変更ログ・アダプタを作成します。
ブラウザを開き、ODSMコンソール(http://admin.mycompany.com/odsm
)を表示します。
OVDHOST1
とOVDHOST2
上で実行されているOracle Virtual Directoryインスタンスそれぞれへの接続がまだ存在していない場合は、作成します。
適切な接続エントリを使用して、Oracle Virtual Directoryインスタンスに接続します。
ホームページで、「アダプタ」タブをクリックします。
アダプタ・ウィンドウの上部にある「アダプタの作成」をクリックして、「新規アダプタ・ウィザード」を起動します。
「新規アダプタ・ウィザード」および次のパラメータを使用して、新規アダプタを作成します。
画面 | フィールド | 値/手順 |
---|---|---|
タイプ |
アダプタ・タイプ |
LDAP |
アダプタ名 |
OIM変更ログ・アダプタ |
|
アダプタ・テンプレート |
|
|
接続 |
DNS設定を使用 |
いいえ |
ホスト |
|
|
ポート |
|
|
サーバー・プロキシ・バインドDN |
|
|
プロキシ・パスワード |
|
|
接続テスト |
テストが正常に行われたことを確認します。 |
|
ネームスペース |
リモート・ベース |
|
マップされたネームスペース |
|
|
概要 |
概要に間違いがないことを確認してから、「終了」をクリックします。 |
変更アダプタを編集する手順は、次のとおりです。
OIM変更ログ・アダプタを選択します。
「プラグイン」タブをクリックします。
「デプロイ済プラグイン」表で、「変更ログ」プラグインをクリックしてから、「編集」をプラグイン表でクリックします。プラグインの編集ウィンドウが表示されます。
「パラメータ」表で、パラメータ値を更新します。
「OK」をクリックします。
「適用」をクリックします。
変更ログ・アダプタを編集してプロパティを追加または変更し、それらが次の表に示す値に一致するようにします。mapObjectclass
、modifierDNFilter
、sizeLimit
、およびtargetDNFilter
プロパティをアダプタに追加する必要があります。
パラメータ | 値 |
---|---|
directoryType |
|
mapAttribute |
|
requiredAttribute |
|
modifierDNFilter |
|
sizeLimit |
|
targetDNFilter |
調整が必要な検索ベース。この値は、OIMのインストール時に指定したLDAP SearchDNと同一である必要があります。 |
mapUserState |
|
oamEnabled |
|
Oracle Internet DirectoryとOracle Virtual Directoryの起動と停止
次のインスタンスを起動および停止します。
OVDHOST1
とOVDHOST2
上で実行されているOracle Virtual Directoryインスタンス。
OIDHOST1
とOIDHOST2
上で実行されているOracle Internet Directoryインスタンス。
手順は、第8.7項「コンポーネントの起動と停止」を参照してください。
Oracle Identity ManagerおよびSOA管理対象サーバーを起動する前に、Oracle Identity Managerサーバー・インスタンスを構成しておく必要があります。これらの構成手順を実行するのは、一度のみ(たとえば、ドメインを最初に作成するとき)です。Oracle Identity Management構成ウィザードによって、OIMメタデータがデータベースにロードされ、インスタンスが構成されます。
続行する前に、次の事項が正しいことを確認してください。
管理サーバーが起動されて、実行中であること。
環境変数DOMAIN_HOME
およびWL_HOME
が現在のシェル内で設定されていないこと。
Oracle Identity Managementの構成ウィザードは、Identity ManagementのOracleホームの下にあります。次のように入力します。
IAM_ORACLE_HOME
/bin/config.sh
次の手順を実行します。
「ようこそ」画面で、「次へ」をクリックします。
構成するコンポーネント画面で、OIMサーバーを選択します。トポロジに必要な場合は、OIM Remote Managerを選択します。
「次へ」をクリックします。
「データベース」画面で、次の値を入力します。
接続文字列: OIMデータベースの接続文字列。例:
oimdbhost1-vip.mycompany.com:1521:oimdb1^oimdbhost2-vip.mycompany.com:1521:oimdb2@oim.mycompany.com
OIMスキーマ・ユーザー名: HA_OIM
OIMスキーマのパスワード: password
MDSスキーマ・ユーザー名: HA_MDS
MDSスキーマのパスワード: password
「次へ」を選択します。
WebLogic管理サーバー画面で、WebLogic管理サーバーについて次の詳細を入力します。
URL: WebLogic管理サーバーに接続するためのURLです。例: t3://oimhost1.mycompany.com:7001
ユーザー名: weblogic
パスワード: weblogic
ユーザーのパスワードです。
「次へ」をクリックします。
「OIMサーバー」画面で、次の値を入力します。
OIM管理者パスワード: OIM管理者のパスワード。これは、xelsysadm
ユーザーのパスワードです。このパスワードは、事前にidmconfigtoolで入力したパスワードと同じにします。
パスワードの確認: パスワードを確認するためのものです。
OIM HTTP URL: OIMサーバーのプロキシURL。これは、OIM用のOHSサーバーのフロントエンドに配置されているハードウェア・ロード・バランサのURLです。たとえば、http://oiminternal.mycompany.com:80
です。
キー・ストア・パスワード: キー・ストア・パスワードです。パスワードには大文字と数字をそれぞれ1文字含める必要があります。例: MyPassword1
「次へ」をクリックします。
環境に必要な場合は、LDAP同期とOAM画面で、BI Publisherの構成を選択し、BI Publisher URLに値を指定します。環境においてBI Publisherに接続するためのURLを入力します。
LDAP同期の有効化を選択します。
注意:
|
「次へ」をクリックします。
「LDAPサーバー」画面で、次のLDAPサーバーの詳細を指定します。
ディレクトリ・サーバー・タイプ: ディレクトリ・サーバーのタイプです。OID、ACTIVE_DIRECTORY、IPLANETまたはOVDを選択します。デフォルトはOIDです。
ディレクトリ・サーバーID: ディレクトリ・サーバーのIDです。
サーバーURL: LDAPサーバーにアクセスするためのURLです。例: Oracle Virtual Directory Serverを使用する場合はldap://ovd.mycompany.com:389
、Oracle Internet Directoryを使用する場合はldap://oid.mycompany.com:389
。
サーバーのユーザー: サーバーに接続するためのユーザー名前。例: cn=orcladmin
·
サーバー・パスワード: LDAPサーバーに接続するためのパスワード。
サーバー検索DN: 検索DN。たとえば、dc=mycompany,dc=com
です。
「次へ」をクリックします。
LDAPサーバー(続き)画面で、次のLDAPサーバー詳細を入力します。
LDAPロールコンテナ: ロール・コンテナのDNです。これは、OIMロールが格納されているコンテナです。例: cn=Groups,dc=mycompany,dc=com
LDAPユーザーコンテナ: ユーザー・コンテナのDNです。これは、OIMユーザーが格納されているコンテナです。たとえば、cn=Users,dc=mycompany,dc=com
です。
ユーザー予約コンテナ: ユーザー予約コンテナのDNです。
注意: 「Oracle Identity Manager用のユーザーとグループの作成」の手順の |
「次へ」をクリックします。
Remote Manager画面で、次の値を指定します。
注意: この画面は、ステップ2でRemote Managerユーティリティを選択した場合にのみ表示されます。 |
サービス名: HA_RManager
RMIレジストリ・ポート: 12345
リスニング・ポート(SSL): 12346
「構成サマリー」画面で、サマリー情報を確認します。
「構成」をクリックし、Oracle Identity Managerインスタンスを構成します。
「構成の進行状況」画面で、構成が正常に完了すると、「次へ」をクリックします。
「構成が完了しました」画面で、構成されたOracle Identity Managerインスタンスの詳細を確認します。
「終了」をクリックし、Configuration Assistantを終了します。
第8.7項「コンポーネントの起動と停止」の説明に従い、WebLogic管理サーバーを停止します。
第8.7項「コンポーネントの起動と停止」の説明に従い、WebLogic管理サーバーを起動します。
この項では、管理対象サーバーの構成後の手順について説明します。
この項の内容は次のとおりです。
次の手順に従い、SOA管理対象サーバーのCoherence構成を更新します。
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの設定ページが表示されます。
「サーバーの起動」タブをクリックします。
「引数」フィールドで、WLS_SOA1とWLS_SOA2について次のように入力します。
WLS_SOA1について、改行を入れず、1行で次のように入力します。
-Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost1vhn1
WLS_SOA2について、改行を入れず、1行で次のように入力します。
-Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost2vhn1
「保存」をクリックして、変更をアクティブ化します。
この変更を有効にするには、SOAサーバーの再起動が必要です。
次の手順に従い、OIMHOST1上のWLS_SOA1およびWLS_OIM1管理対象サーバーを起動します。
OIMHOST1上のWebLogic管理サーバーを停止します。この操作にはWebLogic管理コンソールを使用します。
$DOMAIN_HOME/bin
ディレクトリの下にあるstartWebLogic.sh
スクリプトを使用して、OIMHOST1上のWebLogic管理サーバーを起動します。例:
/u01/app/oracle/admin/OIM/bin/startWebLogic.sh > /tmp/admin.out 2>1&
WebLogic管理コンソールを表示して、WebLogic管理サーバーが正常に起動されたことを確認します。
WebLogic管理コンソールを使用して、WLS_SOA1管理対象サーバーを起動します。
WebLogic管理コンソールを使用して、WLS_OIM1管理対象サーバーを起動します。
Webブラウザを使用してOracle Identity Managerコンソールを起動することによって、OIMHOST1上のOracle Identity Managerサーバー・インスタンスを検証します。
Oracle Identity ManagerコンソールのURLは、次のとおりです。
http://identityvhn1.mycompany.com:14000/oim
xelsysadm
パスワードを使用してログインします。
OIMHOST1で構成を完了したら、その構成をOIMHOST2に伝播できます。これを行うには、OIMHOST1上のドメインをパックし、それをOIMHOST2上で解凍します。
次の手順に従い、OIMHOST1上のドメインをパックし、それをOIMHOST2上で解凍します。
OIMHOST1上で、MW_HOME/oracle_common/common/bin
ディレクトリにあるpack
ユーティリティを呼び出します。
pack.sh -domain=MW_HOME/user_projects/domains/OIM_Domain - template =/u01/app/oracle/admin/templates/oim_domain.jar - template_name="OIM Domain" -managed=true
前の手順で作成したoim_domain.jar
ファイルは、次のディレクトリにあります。
/u01/app/oracle/admin/templates
このoim_domain.jar
ファイルをOIMHOST1からOIMHOST2上の一時ディレクトリにコピーします。
OIMHOST2上で、MW_HOME/oracle_common/common/bin
ディレクトリにあるunpack
ユーティリティを呼び出し、その一時ディレクトリにあるoim_domain.jar
ファイルの場所を指定します。
unpack.sh -domain=MW_HOME/user_projects/domains/OIM_Domain - template=/tmp/oim_domain.jar
この項では、OIMHOST2で実行するインストール後の手順について説明します。これらの項目が含まれます。
WebLogic管理コンソールを使用して管理対象サーバーを起動する前に、ノード・マネージャでStartScriptEnabled
プロパティがtrueに設定されていることが必要です。
これを行うには、次のディレクトリの下にあるsetNMProps.sh
スクリプトを実行します。
MW_HOME/oracle_common/common/bin
次のディレクトリの下にあるstartNodeManager.shスクリプトを使用してOIMHOST2上のノード・マネージャを起動します。
MW_HOME/wlserver_10.3/server/bin
次の手順に従い、OIMHOST2上のWLS_SOA2およびWLS_OIM2管理対象サーバーを起動します。
WebLogic管理コンソールを表示して、WebLogic管理サーバーが正常に起動されたことを確認します。
WebLogic管理コンソールを使用して、WLS_SOA2管理対象サーバーを起動します。
WebLogic管理コンソールを使用して、WLS_OIM2管理対象サーバーを起動します。WLS_OIM2管理対象サーバーを起動する前に、WLS_SOA2管理対象サーバーを起動してください。
Webブラウザを使用してOracle Identity Managerコンソールを起動することによって、OIMHOST2上のOracle Identity Managerサーバー・インスタンスを検証します。
Oracle Identity ManagerコンソールのURLは、次のとおりです。
http://identityvhn2.mycompany.com:14000/oim
xelsysadm
パスワードを使用してログインします。
統合環境では、Oracle Identity ManagerはOHSによってフロントエンド処理されます。すべてのSOAサーバーのデフォルト・コンポジットを更新する必要があります。SOAサーバーのデフォルト・コンポジットの更新手順は、Oracle Fusion Middleware Oracle Identity Management統合ガイドのSOAサーバーのデフォルト・コンポジットの更新に関する説明を参照してください。
注意: この項は、LDAPSyncが有効なOracle Identity Managerインストール、およびOracle Access Managementと統合されているOracle Identity Managerインストールでのみ必要です。 LDAP同期オプションの有効化や、Oracle Access Managementとの統合を計画していない場合は、この項をスキップできます。 |
現在のリリースでは、LDAPConfigPostSetup
スクリプトを使用すると、LDAPSync関連の増分リコンシリエーション・スケジューラ・ジョブがすべて有効になります。これらのジョブはデフォルトでは無効です。LDAP構成ポストセットアップ・スクリプトは、IAM_ORACLE_HOME
/server/ldap_config_util
ディレクトリの下にあります。スクリプトを実行する手順は、次のとおりです。
IAM_ORACLE_HOME
/server/ldap_config_util
ディレクトリの下にあるldapconfig.props
ファイルを編集して、次の値を指定します。
パラメータ | 値 | 説明 |
---|---|---|
|
|
Oracle Identity Manager管理対象サーバーのリスト。 |
|
次の例のような、Oracle Virtual DirectoryインスタンスのURLを指定します。 |
アイデンティティ・ストアのURL。Oracle Virtual Directoryを使用してIDストアにアクセスする場合のみ必要です。 |
|
|
アイデンティティ・ストアへの接続に使用するユーザーの名前。アイデンティティ・ストアがOracle Virtual Directoryに存在する場合のみ必要です。このユーザーは、 |
|
|
Oracle Virtual Directoryを使用してアイデンティティ・ストアにアクセスしない場合は必要です。 |
注意:
|
ファイルを保存します。
次のように、JAVA_HOME
、WL_HOME
、APP_SERVER
、OIM_ORACLE_HOME
およびDOMAIN_HOME
環境変数を設定します。
JAVA_HOME
をMW_HOME
/jrockit_
versionに設定
WL_HOME
をMW_HOME
/wlserver_10.3
に設定
APP_SERVER
をweblogic
に設定
OIM_ORACLE_HOME
をIAM_ORACLE_HOME
に設定
DOMAIN_HOME
をMSERVER_HOME
に設定
LDAPConfigPostSetup.shを実行します。このスクリプトでは、LDAPの管理者パスワードとOracle Identity Managerの管理者パスワードが要求されます。例:
IAM_ORACLE_HOME/server/ldap_config_util/LDAPConfigPostSetup.sh path_to_property_file
例:
IAM_ORACLE_HOME/server/ldap_config_util/LDAPConfigPostSetup.sh IAM_ORACLE_HOME/server/ldap_config_util
この高可用性トポロジでは、管理対象サーバーWLS_OIM1、WLS_SOA1、WLS_OIM2、WLS_SOA2に対してサーバー移行を構成することをお薦めします。サーバー全体の移行を使用する利点と推奨する理由については、第3.9項「サーバー全体の移行」を参照してください。
OIMHOST1上のWLS_OIM1およびWLS_SOA1管理対象サーバーは、OIMHOST1で障害が発生した場合に、OIMHOST2で自動的に再起動するように構成されます。
OIMHOST2上のWLS_OIM2およびWLS_SOA2管理対象サーバーは、OIMHOST2で障害が発生した場合に、OIMHOST1で自動的に再起動するように構成されます。
このような構成では、WLS_OIM1、WLS_SOA1、WLS_OIM2およびWLS_SOA2サーバーは、WebLogicサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。
次の手順を実行すると、WLS_OIM1、WLS_SOA1、WLS_OIM2、およびWLS_SOA2管理対象サーバーのサーバー移行を行うことができ、これにより、サーバーまたはプロセスの障害時に、管理対象サーバーは別のノードにフェイルオーバーできます。
ステップ1: サーバー移行リース表のユーザーと表領域を設定する
ステップ3: ノード・マネージャのプロパティ・ファイルを編集する
ステップ5: サーバー移行ターゲットを構成する
ステップ6: サーバー移行をテストする
最初の手順では、サーバー移行リース表のユーザーと表領域を設定します。
注意: 同じドメイン内の他のサーバーがすでにサーバー移行で構成されている場合、同じ表領域とデータ・ソースを使用できます。この場合、データベース・リース用にデータ・ソースおよびマルチ・データ・ソースを再作成する必要はありませんが、これらをサーバー移行用に構成しているクラスタにターゲット指定しなおす必要があります。 |
leasing
という名前の表領域を作成します。たとえば、sysdbaユーザーとしてSQL*Plusにログオンして次のコマンドを実行します。
SQL> create tablespace leasing logging datafile 'DB_HOME/oradata/orcl/leasing.dbf' size 32m autoextend on next 32m maxsize 2048m extent management local;
leasing
という名前のユーザーを作成し、リース表領域に割り当てます。
SQL> create user leasing identified by welcome1; SQL> grant create table to leasing; SQL> grant create session to leasing; SQL> alter user leasing default tablespace leasing; SQL> alter user leasing quota unlimited on LEASING;
leasing.ddlスクリプトを使用してリース表を作成します。
WL_HOME/server/db/oracle/817ディレクトリまたはWL_HOME/server/db/oracle/920ディレクトリのleasing.ddlファイルを自身のデータベース・ノードにコピーします。
leasingユーザーとしてデータベースに接続します。
SQL*Plusでleasing.ddlスクリプトを実行します。
SQL> @Copy_Location/leasing.ddl;
マルチ・データ・ソースの設定プロセスで、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバルleasingマルチ・データ・ソースの両方について作成します。データ・ソースを作成するときには、次の点に留意してください。
このデータ・ソースが非XAデータ・ソースであることを確認します。
マルチ・データ・ソースの名前の形式は、<MultiDS>-rac0、<MultiDS>-rac1などです。
Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。
データ・ソースは、グローバル・トランザクションのサポートを必要としません。したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。
これらのデータ・ソースをクラスタにターゲット指定します。
データ・ソースの接続プールの初期容量が0(ゼロ)に設定されていることを確認します。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データソース名」、「接続プール」タブの順にクリックし、「初期容量」フィールドに0(ゼロ)を入力します。
マルチ・データ・ソースの作成
マルチ・データ・ソースを作成する手順は、次のとおりです。
管理者の資格証明を使用して、管理コンソールにログインします。
「ドメイン構造」ウィンドウで「サービス」ノードを開き、次に、「データ・ソース」ノードを開きます。
「チェンジ・センター」で「ロックして編集」をクリックします。
「新規」をクリックしてから、「マルチ・データ・ソース」をクリックします。
名前として、leasing
と入力します。
JNDI名として、jdbc/leasing
と入力します。
アルゴリズムとして、「フェイルオーバー」(デフォルト)を選択します。「次」をクリックします。
ターゲット・クラスタを選択します。「次へ」をクリックします。
「非XAドライバ」(デフォルト)を選択します。「次へ」をクリックします。
「新しいデータ・ソースの作成」をクリックします。
名前として、leasing-rac0
と入力します。JNDI名として、jdbc/leasing-rac0
と入力します。データベースのタイプとして、oracle
と入力します。ドライバのタイプとして、「Oracle Driver (Thin) for RAC server-Instance connection Version 10,11」を選択します。
注意: リース表のマルチ・データ・ソースを作成する場合は、名前を<MultiDS>-rac0や<MultiDS>-rac1などの形式で入力します。 |
「次へ」をクリックします。
「グローバル・トランザクションのサポート」の選択を解除します。「次へ」をクリックします。
leasingスキーマのサービス名、データベース名(racdb1
やracdb2
などのRACノードのインスタンス名)、ホスト・ポートおよびパスワードを入力します。「次へ」をクリックします。
「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。「次へ」をクリックします。
注意: 作成するデータ・ソースすべての作成を完了するまで、「終了」をクリックしないでください。作成したデータ・ソースが表示されない場合は、「終了」をクリックするのが早すぎたことを示しています。「終了」をクリックすると、データ・ソースをターゲット指定する画面が管理コンソールに表示されなくなります。 |
データ・ソースをクラスタにターゲット指定します。
データ・ソースを選択して、右の画面に追加します。
Oracle RACデータベースの2番目のインスタンスについて「新しいデータ・ソースの作成」をクリックして、そのターゲットをクラスタに設定してから、Oracle RACデータベースの2番目のインスタンスについても同じ手順を繰り返します。
2つ目のデータ・ソースをマルチ・データ・ソースに追加します。
保存して、「変更のアクティブ化」をクリックします。
nodemanager.properties
ファイルを編集して、サーバー移行を構成するノードごとに次のプロパティを追加する必要があります。
Interface=eth0 NetMask=255.255.255.0 UseMACBroadcast=true
Interface
: 浮動IPのインタフェース名(eth0
など)を指定します。
注意: サブ・インタフェース( |
注意: Windowsの場合、Interfaceには、ネットワーク・インタフェース名を設定する必要があります。例: |
NetMask
: 浮動IPのインタフェースのネット・マスクを指定します。ネット・マスクは、インタフェース上のネット・マスクと同じである必要があります(255.255.255.0
は一例です)。実際の値は、ネットワークにより異なります。
UseMACBroadcast
: ARPパケットの送信時にノードのMACアドレスを使用するかどうか、つまり、arping
コマンドで-b
フラグを使用するかどうかを指定します。
これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力(ノード・マネージャが起動されているシェル)で確認します。ノード・マネージャの出力で、次のようなエントリが表示されることを確認します。
... StateCheckInterval=500 Interface=eth0 NetMask=255.255.255.0 ...
注意: サーバーのプロパティ(起動プロパティ)が適切に設定されており、ノード・マネージャがサーバーをリモートで起動できる場合、次の手順は必要ありません。 |
nodemanager.properties
ファイルで次のプロパティを設定します。
StartScriptEnabled
: このプロパティをtrue
に設定して、ノード・マネージャが管理対象サーバーで起動するようにします。
WL_HOME/server/binディレクトリにあるstartNodeManager.sh
スクリプトを実行して、OIMHOST1とOIMHOST2でノード・マネージャを起動します。
注意: 共有記憶域のインストールからノード・マネージャを実行している場合、同じ |
サーバー移行を構成するノードごとにwlsifconfig.sh
スクリプトの環境とスーパーユーザー権限を設定する手順は、次のとおりです。
注意: Windowsでは、このスクリプトは |
PATH環境変数に次のファイルが含まれていることを確認します。
wlsifconfig.sh
スクリプトに対するsudo構成権限を付与します。
パスワード・プロンプトを使用しないで機能するsudoを構成します。
セキュリティ上の理由から、wlsifconfig.sh
スクリプトの実行に必要なコマンドのサブセットに限定することをお薦めします。たとえば、wlsifconfig.sh
スクリプトの環境とスーパーユーザー権限を設定するには、次の手順を実行します。
WebLogicユーザー(oracle
)に、パスワードによる制限なしのsudo権限を付与し、/sbin/ifconfig
バイナリおよび/sbin/arping
バイナリの実行権限を付与します。
WebLogicユーザーがこのスクリプトを実行できることを確認します。sudo実行権限をoracle
およびifconfig
とarping
に付与するエントリを記述した/etc/sudoers
の例を次に示します。
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
注意: この手順で使用できるsudoとシステム権限はシステム管理者にお問い合せください。 |
まず、クラスタのメンバーに対して使用可能なすべてのノードを割り当て、サーバー移行で構成される各サーバー用の候補サーバーを(適切な順に)指定します。クラスタ内の移行でクラスタ移行を構成する手順は次のとおりです。
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。
「名前」列で、移行を構成するクラスタをクリックします。
「移行」タブをクリックします。
「ロックして編集」をクリックします。
「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
サーバー移行の候補となるマシンを設定します。このタスクは、次の手順に従って、すべての管理対象サーバーについて実行する必要があります。
管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開いて、「サーバー」を選択します。
ヒント: 「サーバーのサマリー」ページの「この表のカスタマイズ」をクリックして、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動し、サーバーが実行されているマシンを表示します。サーバーが自動的に移行される場合、これは実際の構成とは異なります。 |
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックしてから、「変更のアクティブ化」をクリックします。
追加の管理対象サーバーに対して、前述の手順を繰り返します。
管理サーバー、ノード・マネージャ、サーバー移行が構成されたサーバーを再起動します。
サーバー移行が適切に機能していることを確認する手順は次のとおりです。
OIMHOST1から次の処理を実行します。
WLS_OIM1管理対象サーバーを停止します。これには、次のコマンドを実行します。
OIMHOST1> kill -9 pid
pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。
OIMHOST1> ps -ef | grep WLS_OIM1
ノード・マネージャのコンソールを確認します。WLS_OIM1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。
ノード・マネージャがWLS_OIM1の2回目の再起動を試行するのを待ちます。この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
OIMHOST2から次の処理を実行します。
ローカルのノード・マネージャのコンソールを確認します。OIMHOST1でのWLS_OIM1の再起動が前回試行されてから30秒間経過した後に、WLS_OIM1の浮動IPが表示されサーバーをこのノードで再起動することを示すメッセージがOIMHOST2のノード・マネージャにより表示されます。
同じIPでsoa-infraコンソールにアクセスします。
前述の手順に従い、WLS_OIM2、WLS_SOA1、およびWLS_SOA2管理対象サーバーのサーバー移行をテストします。
表9-4は、管理対象サーバーと、障害が発生した場合のそれらの移行先のホストを示しています。
表9-4 WLS_OIM1、WLS_OIM2、WLS_SOA1、WLS_SOA2サーバー移行
管理対象サーバー | 移行元 | 移行先 |
---|---|---|
WLS_OIM1 |
OIMHOST1 |
OIMHOST2 |
WLS_OIM2 |
OIMHOST2 |
OIMHOST1 |
WLS_SOA1 |
OIMHOST1 |
OIMHOST2 |
WLS_SOA2 |
OIMHOST2 |
OIMHOST1 |
管理コンソールからの検証
移行は管理コンソールで確認することもできます。
管理者の資格証明を使用して、管理コンソール(http://oimhost1.mycompany.com:7001/console)にログインします。
左側のコンソールで、「ドメイン」をクリックします。
「監視」タブをクリックし、「移行」サブタブをクリックします。
「移行の状態」表に、移行の状態に関する情報が表示されます。
注意: サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。 |
OIMHOST1とOIMHOST2の両方から参照できる共有ディレクトリに、すべての永続ストアの場所を構成します。JMSメッセージは、各サーバーのローカル・ファイル・システムのファイル・システムで永続化されているため、WebLogicサーバー移行のためにはJMS永続ストア用の共有記憶域が必要です。共有記憶域がない場合、移行先サーバーからは保留中のJMSメッセージにアクセスできなくなります。
共有のベース・ディレクトリを使用するように、すべての永続ストアを変更する手順は、次のとおりです。
管理者の資格証明を使用して、管理コンソール(http://oimhost1.mycompany.com:7001/console)にログインします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。「永続ストアの概要」ページが表示されます。
表BPM、SOA、OIMおよびUMSの「名前」列から、永続ストアのハイパーリンクを選択します。その永続ストアの「設定」ページが表示されます。
「構成」タブの「ディレクトリ」フィールドに、クラスタ内の他のサーバーで使用可能な永続記憶域ソリューション(NASやSANなど)の場所を入力します。この場所を指定することで、保留中のJMSメッセージを送信できます。
場所は、次のディレクトリ構造に従う必要があります。
WLS_SOA1およびWLS_SOA2サーバーについては、次のようなディレクトリ構造を使用します。
ORACLE_BASE/admin/domainName/soaClusterName/jms
WLS_OIM1およびWLS_OIM2サーバーについては、次のようなディレクトリ構造を使用します。
ORACLE_BASE/admin/domainName/oimClusterName/jms
注意: WLS_OIM1およびWLS_OIM2サーバーは、このディレクトリにアクセスできる必要があります。 WLS_SOA1およびWLS_SOA2 サーバーは、このディレクトリにアクセスできる必要があります。 このディレクトリは、サーバーを再起動する前に存在している必要があります。 |
「保存してアクティブ化」をクリックします。
サーバーを再起動して、永続ストア内の変更を有効化します。
各Oracle WebLogic管理対象サーバーにはトランザクション・ログがあり、サーバーによって調整された、未完了の可能性のある、進行中のトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、クラスタ内のすべてのサーバーからアクセス可能な場所にトランザクション・ログを格納します。共有記憶域がないと、サーバーに障害が発生したときにクラスタ内の他のサーバーがトランザクション・リカバリを実行できず、操作の再試行が必要になることがあります。
注意: 可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。 |
Oracle Identity ManagerおよびSOAサーバーのデフォルトの永続ストアの場所を設定する手順は次のとおりです。
管理者の資格証明を使用して、管理コンソール(http://oimhost1.mycompany.com:7001/console)にログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)を選択します。選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。
「サービス」タブをクリックします。
ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。パスのディレクトリ構造は、次のようにする必要があります。
WLS_SOA1およびWLS_SOA2サーバーについては、次のようなディレクトリ構造を使用します。
ORACLE_BASE/admin/domainName/soaClusterName/tlogs
WLS_OIM1およびWLS_OIM2サーバーについては、次のようなディレクトリ構造を使用します。
ORACLE_BASE/admin/domainName/oimClusterName/tlogs
「保存」をクリックします。
注意: トランザクション回復サービスの移行機能を有効化するには、クラスタ内の管理対象サーバーで利用可能な永続記憶域ソリューション上の場所を指定します。WLS_SOA1、WLS_SOA2、WLS_OIM1、およびWLS_OIM2は、このディレクトリにアクセスできる必要があります。 |
WEBHOST1およびWEBHOST2にOracle HTTP Serverをインストールする手順は、第8.6.3.4.1項「Web Tier用のOracle HTTP Serverのインストール」を参照してください。
この項では、Oracle Identity Managerを構成してOracle Web Tierと連携する方法について説明します。
次のタスクが実行済であることを確認します。
Oracle Web TierをWEBHOST1とWEBHOST2にインストールしました。
Oracle Identity ManagerがOIMHOST1およびOIMHOST2にインストールされ、構成済であること。
ロード・バランサがWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(sso.mycompany.com
)で構成済であること。
ロード・バランサがWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(oiminternal.mycompany.com
)で構成済であること。
ロード・バランサのVIPの構成の詳細は、第8.2.5.4項「ロード・バランサの仮想サーバー名とポートの構成」を参照してください。
WEBHOST1
とWEBHOST2
上の各Webサーバーで、oim.conf
と呼ばれるファイルをORACLE_INSTANCE
/config/OHS/component/moduleconf
ディレクトリに作成します。このファイルには次の情報が記載されている必要があります。
# oim admin console(idmshell based) <Location /admin> SetHandler weblogic-handler WLCookieName oimjsessionid WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000 WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log" WLProxySSL ON WLProxySSLPassThrough ON </Location> # oim self and advanced admin webapp consoles(canonic webapp) <Location /oim> SetHandler weblogic-handler WLCookieName oimjsessionid WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000 WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log" WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /identity> SetHandler weblogic-handler WLCookieName oimjsessionid WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000 WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log" WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /sysadmin> SetHandler weblogic-handler WLCookieName oimjsessionid WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000 WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log" WLProxySSL ON WLProxySSLPassThrough ON </Location> # SOA Callback webservice for SOD - Provide the SOA Managed Server Ports <Location /sodcheck> SetHandler weblogic-handler WLCookieName oimjsessionid WebLogicCluster oimvhn1.mycompany.com:8001,oimvhn2.mycompany.com:8001 WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log" WLProxySSL ON WLProxySSLPassThrough ON </Location> # Callback webservice for SOA. SOA calls this when a request is approved/rejected # Provide the SOA Managed Server Port <Location /workflowservice> SetHandler weblogic-handler WLCookieName oimjsessionid WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000 WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log" WLProxySSL ON WLProxySSLPassThrough ON </Location> # xlWebApp - Legacy 9.x webapp (struts based) <Location /xlWebApp> SetHandler weblogic-handler WLCookieName oimjsessionid WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000 WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log" WLProxySSL ON WLProxySSLPassThrough ON </Location> # Nexaweb WebApp - used for workflow designer and DM <Location /Nexaweb> SetHandler weblogic-handler WLCookieName oimjsessionid WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000 WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log" WLProxySSL ON WLProxySSLPassThrough ON </Location> # used for FA Callback service. <Location /callbackResponseService> SetHandler weblogic-handler WLCookieName oimjsessionid WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000 WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log" WLProxySSL ON WLProxySSLPassThrough ON </Location> # spml xsd profile <Location /spml-xsd> SetHandler weblogic-handler WLCookieName oimjsessionid WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000 WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log" WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /HTTPClnt> SetHandler weblogic-handler WLCookieName oimjsessionid WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000 WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log" WLProxySSL ON WLProxySSLPassThrough ON </Location>
ORACLE_INSTANCE/config/OHS/component/moduleconf
にvirtual_hosts.conf
というファイルを作成します。このファイルは、次の情報を含む必要があります。
NameVirtualHost *:7777 <VirtualHost *:7777> ServerName http://sso.mycompany.com:7777 RewriteEngine On RewriteOptions inherit UseCanonicalName On </VirtualHost> <VirtualHost *:7777> ServerName http://oiminternal.mycompany.com:80 RewriteEngine On RewriteOptions inherit UseCanonicalName On </VirtualHost>
WEBHOST1
とWEBHOST2
の両方でファイルを保存します。
第8.7項「コンポーネントの起動と停止」の説明に従い、WEBHOST1
およびWEBHOST2
上のOracle HTTP Serverインスタンスを停止してから起動します。
Oracle HTTP Serverが適切に構成されていることを検証する手順は次のとおりです。
Webブラウザで、Oracle Identity Managerコンソール用の次のURLを入力します。
http://sso.mycompany.com:7777/identity
Oracle Identity Managerコンソール・ログイン・ページが表示されます。
xelsysadm
ユーザーの資格証明を使用してOracle Identity Managerコンソールにログインします。
高可用性環境では、WebLogicノード・マネージャはOracle WebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。
高可用性環境では、ハードウェア・ロード・バランサを使用して、複数のOracle Identity Managerインスタンス間のリクエストをロード・バランシングします。Oracle Identity Managerインスタンスのいずれかに障害が発生した場合は、ロード・バランサによって障害が検出され、障害が発生していないインスタンスにリクエストがルーティングされます。
高可用性環境では、状態情報と構成情報は、クラスタ内のすべてのメンバーが共有するデータベースに格納されます。
状態情報が共有データベースに格納されており、クラスタ内のすべてのメンバーがこの情報を使用できるため、障害が発生していないOracle Identity Managerインスタンスでは、障害が発生したインスタンスで開始された未完了のトランザクションの処理をシームレスに継続します。
Oracle Identity Managerインスタンスのいずれかで障害が発生すると、そのデータベースとLDAP接続は解放されます。アクティブ/アクティブ・デプロイメント内にある障害が発生していないインスタンスは、独自の接続を行い、障害が発生したインスタンス上にある未完了のトランザクションの処理を継続します。
Oracle Identity Managerを高可用性構成にデプロイする場合は、次のことに注意してください。
Oracle Identity ManagerはOracle RACデータベースにデプロイできますが、Oracle RACのフェイルオーバーは、このリリースではOracle Identity Managerに対して透過的ではありません。Oracle RACのフェイルオーバーが発生すると、エンド・ユーザーは、各自のリクエストを再送信する必要がある場合があります。
Oracle Identity Managerは常に、SOAクラスタ内で少なくとも1つのノードが使用可能であることを必要とします。SOAクラスタが使用可能でない場合、エンド・ユーザーのリクエストは失敗します。Oracle Identity Managerノードは、失敗したSOA呼出しに対して再試行しません。そのため、SOA呼出しが失敗すると、エンド・ユーザーは再試行する必要があります。
アクティブ/アクティブOracle Identity Manager構成において、Oracle Identity Managerでユーザーを作成していて(Oracle Identity Managerにログインし、「管理」タブをクリックして、「ユーザーの作成」リンクをクリックし、フィールドに必要な情報を入力してから、「保存」をクリックします)、そのリクエストを処理中のOracle Identity Managerサーバーに障害が発生した場合、Oracle Identity Managerログ・ファイルに次のようなResourceConnectionValidationxceptionが記述されることがあります。
[2010-06-14T15:14:48.738-07:00] [oim_server2] [ERROR] [] [XELLERATE.SERVER] [tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: xelsysadm] [ecid: 004YGJGmYrtEkJV6u3M6UH00073A0005EI,0:1] [APP: oim#11.1.1.3.0] [dcid: 12eb0f9c6e8796f4:-785b18b3:12938857792:-7ffd-0000000000000037] [URI: /admin/faces/pages/Admin.jspx] Class/Method: PooledResourceConnection/heartbeat encounter some problems: Operation timed out[[ com.oracle.oim.gcp.exceptions.ResourceConnectionValidationxception: Operation timed out at oracle.iam.ldapsync.impl.repository.LDAPConnection.heartbeat(LDAPConnection.ja va:162) at com.oracle.oim.gcp.ucp.PooledResourceConnection.heartbeat(PooledResourceConnec tion.java:52) . . .
この例外を受け取った場合でも、ユーザーは正常に作成されます。
Oracle Identity Manager高可用性トポロジは、スケール・アウトやスケール・アップができます。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。
この場合は、SOAコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードには、既存の管理対象サーバーのMiddlewareホーム、Oracleホーム(SOA)およびドメイン・ディレクトリが含まれます。
新しいWLS_OIMおよびWLS_SOAサーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用できます。OIMおよびSOAのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。
トポロジをスケール・アップするには、次の手順を実行します。
管理コンソールを使用して、WLS_OIM1またはWLS_SOA1のクローンを新しい管理対象サーバーに作成します。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
管理対象サーバーのクローンを作成するには:
管理コンソールから「環境」→「サーバー」を選択します。
クローンを作成する管理対象サーバー(WLS_OIM1やWLS_SOA1など)を選択します。
「クローンの作成」を選択します。
新しい管理対象サーバーにWLS_OIMn
またはWLS_SOAn
という名前を付けます。n
は新しい管理対象サーバーを識別する番号を示します。
この後の手順では、すでにWLS_SOA1およびWLS_OIM1を実行しているOIMHOST1に新しいサーバーを追加することを想定しています。
リスニング・アドレスとして、この新しい管理対象サーバー用に使用するホスト名またはIPを割り当てます。このサーバーでお薦めしているサーバー移行を実行する予定の場合は、別のノードへの移動を可能にするために、このアドレスはVIP(別称: 浮動IP)である必要があります。このVIPは、実行されている管理対象サーバーとは別のものを使用してください。
新しい管理対象サーバーにSOA、OIM、BPMおよびUMSのJMSサーバーを作成します。
管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_nのような名前を付けます。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms
注意: このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。 |
SOAの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_n)。このJMSサーバーに対して、SOAJMSFileStore_nを使用します。SOAJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n
注意: このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。 新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
UMSの新しいJMSサーバーを作成します(たとえば、UMSJMSServer_n)。このJMSサーバーに対して、UMSJMSFileStore_nを使用します。UMSJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
新しいOIMJMSServerの新しい永続ストアを作成します(たとえば、OIMJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_n
注意: このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。 新しいOIM JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
OIMの新しいJMSサーバーを作成します(たとえば、OIMJMSServer_n)。このJMSサーバーに対して、OIMJMSFileStore_nを使用します。OIMJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_OIMn)にターゲット指定します。
新たに作成されたSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列でハイパーリンクとして表示されている)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。SOAJMSのサブデプロイメント・モジュールが表示されます。
注意: このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたSOAJMSServerXXXXXXという形式のランダム名です。 |
サブデプロイメント「SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、SOAJMSServer_nと呼ばれる、SOAの新しいJMSサーバーを追加します。「保存」をクリックします。
新たに作成されたUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。UMSJMSのサブデプロイメント・モジュールが表示されます。
注意: このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたUCMJMSServerXXXXXXという形式のランダム名です。 |
サブデプロイメント「UMSJMSServerXXXXXX」をクリックします。このサブデプロイメントに、UMSJMSServer_nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。
新たに作成されたOIM JMSサーバーが含まれるように、OIMJMSModuleのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「OIMJMSSystemResource」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。OIMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。OIMJMSのサブデプロイメント・モジュールが表示されます。
注意: このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OIM1とWLS_OIM2)のJMS構成から生成されたOIMJMSServerXXXXXXという形式のランダム名です。 |
サブデプロイメント「OIMMSServerXXXXXX」をクリックします。このサブデプロイメントに、OIMJMSServer_nと呼ばれる、OIMの新しいJMSサーバーを追加します。「保存」をクリックします。
第5.13.8項「コンポジットのデプロイでのOracle Coherenceの構成」の説明に従って、コンポジットをデプロイする場合のOracle Coherenceを構成します。
注意: サーバーに対して変更が必要なのは、ローカル・ホスト・フィールドのみです。ローカル・ホストを、新しく追加されたサーバーのリスニング・アドレスに置き換えます。例: Dtangosol.coherence.localhost=SOAHOST1VHNn |
新しいサーバーに対してトランザクション永続ストアを構成します。これは、他のノードからアクセス可能な共有記憶域の場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_SOAn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとSOAHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
ホスト名の検証を無効化するには、次の手順を実行します。
Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。表の「名前」列で「WLS_SOAn」を選択します。
「SSL」タブをクリックします。「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。「保存」をクリックします。
管理コンソールから新しい管理対象サーバーを起動して、テストします。
クラスタ内の既存の管理対象サーバーを停止します。
新たに作成した管理対象サーバーWLS_SOAnが起動していることを確認します。
新たに作成した管理対象サーバー上のアプリケーション(http://vip:port/soa-infra)にアクセスします。アプリケーションが機能している必要があります。
管理コンソールにログインします。「サービス」→「外部JNDIプロバイダ」リンクを選択します。「ForeignJNDIProvider-SOA」を選択し、新しいサーバーを既存の値に追加します。
新しい管理対象サーバーに対してサーバー移行を構成します。
注意: これはスケール・アップ操作であるため、ノード・マネージャ、サーバー移行に対して構成された環境および新しいSOA管理対象サーバーの浮動IPがあらかじめノードに用意されている必要があります。 |
サーバー移行を構成する手順は次のとおりです。
管理コンソールにログインします。
左側のペインで「環境」を開き、「サーバー」を選択します。
移行を構成するサーバー(ハイパーリンクとして示されています)を選択します。このサーバーの「設定」ページが表示されます。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。ノードの既存のサーバーと同じ移行ターゲットを選択します。
たとえば、すでにWLS_SOA1が実行されているSOAHOST1上の新しい管理対象サーバーには、SOAHOST2を選択します。すでにWLS_SOA2が実行されているSOAHOST2上の新しい管理対象サーバーには、SOAHOST1を選択します。
移行時に管理対象サーバーを同時に実行できるように、適切なリソースが使用可能になっていることを確認してください。
「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
新しく作成したWLS_OIMn管理対象サーバーに対してサーバー移行を構成するために、このリストの手順を繰り返します。
この新規サーバーのサーバー移行をテストするには、新規サーバーの追加先となったノードで、次の手順を実行します。
管理対象サーバーWLS_SOAnを停止します。
そのためには、管理対象サーバーのPIDに対してkill -9
pidを実行します。ノードのPIDを調べるには、ps -ef | grep WLS_SOAn
を入力します。
ノード・マネージャ・コンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。
ノード・マネージャがWLS_SOAnの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。
トポロジのスケール・アウトでは、SOAで構成された新しい管理対象サーバーを新しいノードに追加します。
この項の手順を実行する前に、次の要件が満たされていることを確認してください。
SOAで構成された管理対象サーバーを実行しているノードがトポロジ内に存在していること。
新しいノードがWebLogic ServerとSOAの既存のホーム・ディレクトリにアクセスできること。(新しい管理対象サーバーWLS_SOAまたはWLS_WSMを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic ServerやSOAバイナリをインストールする必要はありませんが、packとunpackを実行して、新しいノードでドメイン構成をブートストラップする必要があります。)
注意: 共有記憶域にインストールが存在しない場合は、第5.13項「Oracle SOAインフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」の説明に従って、新しいノードにWebLogic ServerとSOAをインストールする必要があります。 |
注意: ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して共有記憶域内のインストールを「追加」する場合は、ORACLE_HOME/oui/bin/attachHome.shを使用します。WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、user_home/bea/beahomelistファイルを編集します。次の手順を参照してください。 |
トポロジをスケール・アウトするには、次の手順を実行します。
新しいノードで、SOAのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。
SOAHOSTn>cd ORACLE_BASE/product/fmw/soa/ SOAHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>
Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE/product/fmwを追加します。
Oracle WebLogic管理コンソールにログインします。
新しいノードに使用する新しいマシンを作成し、このマシンをドメインに追加します。
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。
管理コンソールを使用し、WLS_SOA1のクローンを作成して新しい管理対象サーバーにします。このサーバーにWLS_SOAnという名前を付けます。nは番号です。
注意: これらの手順では、管理対象サーバーが実行されていないノードnに新しいサーバーを追加することを想定しています。 |
新しい管理対象サーバーでその管理対象サーバーのリスニング・アドレスに使用するホスト名またはIPを割り当てます。
このサーバーに対してサーバー移行の使用を計画している場合は(推奨)、このアドレスにサーバーのVIP(浮動IPともいう)を割り当てる必要があります。このVIPは、既存の管理対象サーバーとは別のものを使用してください。
新しい管理対象サーバーにSOA、OIM(該当する場合)およびUMSのJMSサーバーを作成します。
管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_nのような名前を付けます。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_n
注意: このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。 |
SOAの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_n)。このJMSサーバーに対して、SOAJMSFileStore_nを使用します。SOAJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n
注意: このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。 新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
UMSの新しいJMSサーバーを作成します(たとえば、UMSJMSServer_n)。このJMSサーバーに対して、UMSJMSFileStore_nを使用します。UMSJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
新しいOIMJMSServerの新しい永続ストアを作成します(たとえば、OIMJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_n
注意: このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。 新しいOIM JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
OIMの新しいJMSサーバーを作成します(たとえば、OIMJMSServer_n)。このJMSサーバーに対して、OIMJMSFileStore_nを使用します。OIMJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_OIMn)にターゲット指定します。
新たに作成されたSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列でハイパーリンクとして表示されている)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。SOAJMSのサブデプロイメント・モジュールが表示されます。
注意: このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたSOAJMSServerXXXXXXという形式のランダム名です。 |
サブデプロイメント「SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、SOAJMSServer_nと呼ばれる、SOAの新しいJMSサーバーを追加します。「保存」をクリックします。
新たに作成されたUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。UMSJMSのサブデプロイメント・モジュールが表示されます。
注意: このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたUCMJMSServerXXXXXXという形式のランダム名です。 |
サブデプロイメント「UMSJMSServerXXXXXX」をクリックします。このサブデプロイメントに、UMSJMSServer_nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。
新たに作成されたOIM JMSサーバーが含まれるように、OIMJMSModuleのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「OIMJMSSystemResource」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。OIMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。OIMJMSのサブデプロイメント・モジュールが表示されます。
注意: このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OIM1とWLS_OIM2)のJMS構成から生成されたOIMJMSServerXXXXXXという形式のランダム名です。 |
サブデプロイメント「OIMMSServerXXXXXX」をクリックします。このサブデプロイメントに、OIMJMSServer_nと呼ばれる、OIMの新しいJMSサーバーを追加します。「保存」をクリックします。
次のようにpackコマンドをSOAHOST1で実行し、テンプレート・パックを作成します。
SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
SOAHOST1> ./pack.sh -managed=true/
-domain=MW_HOME/user_projects/domains/soadomain/
-template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale
次のコマンドをSOAHOST1で実行し、作成したテンプレート・ファイルをSOAHOSTnにコピーします。
SOAHOST1> scp soadomaintemplateScale.jar oracle@SOAHOSTN:/
ORACLE_BASE/product/fmw/soa/common/bin
次のようにSOAHOSTnでunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。
SOAHOSTn> cd ORACLE_BASE/product/fmw/soa/common/bin SOAHOSTN> ./unpack.sh / -domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar
第5.13.8項「コンポジットのデプロイでのOracle Coherenceの構成」の説明に従って、コンポジットをデプロイする場合のOracle Coherenceを構成します。
注意: サーバーに対して変更が必要なのは、ローカル・ホスト・フィールドのみです。ローカル・ホストを、新しく追加されたサーバーのリスニング・アドレスに置き換えます。例: Dtangosol.coherence.localhost=SOAHOST1VHNn |
新しいサーバーに対してトランザクション永続ストアを構成します。これは、他のノードからアクセス可能な共有記憶域の場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_SOAn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとSOAHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
ホスト名の検証を無効化するには、次の手順を実行します。
Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_SOAn」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、すでに存在しているノードの共有記憶域にあるインストールを使用し、次のように新しいノードのホスト名をパラメータとして渡します。
SOAHOSTn> WL_HOME/server/bin/startNodeManager new_node_ip
管理コンソールから新しい管理対象サーバーを起動して、テストします。
クラスタ内の既存の管理対象サーバーを停止します。
新たに作成した管理対象サーバーWLS_SOAnが起動していることを確認します。
新たに作成した管理対象サーバー上のアプリケーション(http://vip:port/soa-infra)にアクセスします。アプリケーションが機能している必要があります。
新しい管理対象サーバーに対してサーバー移行を構成します。
注意: この新しいノードでは既存の共有記憶域インストールを使用しているため、ノードではすでに、ノード・マネージャと、ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限などの、サーバー移行用に構成された環境が使用されています。新しいノードには、すでに新しいSOA管理対象サーバーの浮動IPが存在します。 |
次の手順を実行してサーバー移行を構成します。
管理コンソールにログインします。
左側のペインで「環境」を開き、「サーバー」を選択します。
移行を構成するサーバー(ハイパーリンクとして示されています)を選択します。このサーバーの「設定」ページが表示されます。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
注意: マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードのリソースが追加の管理対象サーバーの持続に十分対応できるように、必須の容量計画を立てる必要があります。 |
「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
この新しいサーバーのサーバー移行をテストします。新しいサーバーを追加したノードで次の手順を実行します。
管理対象サーバーWLS_SOAnを停止します。
そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDは、ps -ef | grep WLS_SOAnを使用して確認できます。
ノード・マネージャ・コンソールを確認します。WLS_SOA1の浮動IPが無効になっていることを示すメッセージが表示されています。
ノード・マネージャがWLS_SOAnの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。これで、サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
この項では、Oracle Access Management Access Manager (Access Manager)の概要、およびAccess Managerの高可用性環境の設計およびデプロイ方法について説明します。
Access Managerによって、すべての認証および認可サービスの一元的な提供が可能になります。提供されるコア・サービスは、有効なセッション・トークンのチェック、セッション・トークンが無効であるか見つからない場合の資格証明の要求、セッション・トークンの発行、リソース・リクエストのインターセプト、およびリソースへのアクセスを制御するためのアクセス制御ポリシーの評価です。Access Managerは、Pure Javaサーバーの機能を備えていますが、Oracle Single Sign-On 10gおよびOracle Access Manager 10gエージェント・コンポーネントも引き続き使用します。Access Managerの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Management Access Managerの概要に関する説明を参照してください。
この項の内容は次のとおりです。
図9-3は、Access Managerコンポーネントのアーキテクチャを示しています。
図9-2は、次のコンポーネントを示しています。
ユーザー・エージェント: これらには、Webブラウザ、Javaアプリケーション、およびWebサービス・アプリケーションが含まれます。ユーザー・エージェントは、HTTPを使用してアクセス・サーバーと管理および構成ツールにアクセスします。
保護されたリソース: 保護されたリソースとは、それへのアクセスが制限されたアプリケーションまたはWebページのことです。保護されたリソースへのアクセスは、WebGateまたはカスタム・エージェントによって制御されます。
管理および構成ツール: Access Managerは、Oracle Access Managementコンソール、Oracle Enterprise Manager Fusion Middleware Control、Oracle Enterprise Manager Grid ControlおよびWebLogic Scripting Tool (WLST)を使用して管理および構成します。
アクセス・サーバー: アクセス・サーバーには、資格証明コレクタ、OSSOプロキシおよびOAMプロキシ・コンポーネントが含まれます。Coherence分散オブジェクト・キャッシュは、アクセス・サーバー間で構成ファイルの変更を伝播するために使用されます。
Access Managerデプロイメントは、次のシステム・エンティティで構成されます。
Access Managerエージェント: Access Managerエージェントは、アクセス・サーバーの拡張機能であり、アクセス・サーバーで管理されているポリシーに従ってアクセスが制御されるようにする役割を担います。
エージェントがその機能を実行するには、アクセス・サーバー・コンポーネントが必要です。アクセス・サーバーが使用できない場合、保護されるサーバーへのアクセスは許可されないため、ユーザーはシステムからロックアウトされます。
保護されたリソース(パートナ・アプリケーション): Access Managerによって保護されたアプリケーションです。これらのリソースへのアクセスは、Access Managerのアクセス制御ポリシーに従って行われ、保護されたリソースのアクセス・パスにデプロイされたAccess Managerエージェント(WebサーバーにデプロイされたAccess Managerエージェントなど)によって制御されます。
アクセス・サーバー: コア・ランタイム・アクセス管理サービスを提供するサーバー・サイド・コンポーネントです。
JMX Mbean: ランタイムMBeanは、アクセス・サーバー・パッケージの一部としてパッケージ化されています。構成Mbeanは、スタンドアロンWARファイルとしてパッケージ化されています。
WebLogic 11g SSPIプロバイダは、Access Java Access JDKとともにSSPIインタフェースを実現するJavaクラスで構成されています。AccessGateは、Pure Java Access JDKを使用して構築されています。
Oracle Access Managementコンソール: 管理コンソールをホストするJ2EEアプリケーションであり、Access Managerデプロイメントを管理するための管理や構成などのサービスを提供します。
WebLogic Scripting Tool(WLST)は、アクセス・サーバー・パッケージに含まれているJavaクラスで構成されています。Access Managerデプロイメントの管理の一部は、コマンドラインからサポートされます。
Fusion Middleware ControlおよびEnterprise Manager Grid Control: Access Managerは、Enterprise Manager Grid Controlと統合し、パフォーマンス・メトリックとデプロイメント・トポロジを表示します。
Coherence分散オブジェクト・キャッシュ: Access Managerコンポーネントは、このインフラストラクチャに依存して、変更をリアルタイムに伝播します。
Access Manager Proxyは、Apache MINAサーバーのカスタマイズ・バージョン(JCAアーキテクチャに基づく)であり、Javaサーバー・クラスに加えてMessageDrivenBeanおよびResourceAdapterが含まれています。
Oracle Single Sign-On(OSSO)プロキシは、アクセス・サーバー・パッケージに含まれているJavaクラスで構成されています。
データ・リポジトリ: Access Managerは、アイデンティティ、ポリシー、パートナ、セッション、一時データを含む様々なタイプの情報を処理します。
アイデンティティ・データ用LDAP
構成およびパートナ・データ用ファイル
セッションおよび一時データ用Coherenceインメモリー
ポリシー・データはファイルまたはRDBMSに格納されます
Oracle Access Manager 10g WebGateは、Webサーバーにデプロイすることを意図したCベースのエージェントです。
Oracle Single Sign-On Apacheモジュールは、Oracle HTTP Server Webサーバーにデプロイすることを意図したCベースのエージェントです。
Access Manager 11g WebGateは、Webサーバーにデプロイすることを意図したCベースのエージェントです。
認証ユーザー・セッション情報は、Coherence分散オブジェクト・キャッシュを介して永続化されます。Access Managerに対しては、Coherence分散オブジェクト・キャッシュ・インメモリー・モードを使用します。
Access Managerによって、ログイン処理中に、認証されていないユーザーに対して一時状態が作成されることがあります。この状態は、通常、Access Managerノード間でレプリケートされません。ログイン処理中のノードの障害の影響を防止するために、オプションでその状態を暗号化されたクライアントCookieに格納することができます。
認証されていないユーザーの一時状態をログイン処理中に格納するには、次の手順に従ってOAMサーバー・パラメータRequestCacheTypeをBASICからCOOKIEに変更します。
次のコマンドを実行して、WLSTの環境を設定します。
DOMAIN_HOME/bin/setDomainEnv.sh
次のコマンドを発行して、WLSTを起動します。
Start WLST by issuing this command:
ORACLE_HOME/common/bin/wlst.sh
ドメインに接続します。
wls:/IDM_Domain/serverConfig> connect()
WebLogic管理ユーザー名とパスワードを入力し、管理サーバーのURLを次の形式で入力します。
t3://OAMHOST1.mycompany.com:7001
次のコマンドを発行します。
wls:/IDM_Domain/serverConfig> configRequestCacheType(type="COOKIE")
次のコマンドを発行して、コマンドが動作したことを確認します。
wls:/IDM_Domain/serverConfig> displayRequestCacheType()
Access Manager管理対象サーバーを再起動します。
Access Managerのリクエスト・フローの手順を次に説明します。
ユーザーが、Access Managerによって保護されたWebリソースに、Webブラウザを使用してアクセスを試みます。
Access Managerエージェント脚注1 によって、そのリクエストはインターセプトされ、ユーザーが認証済セッションを持っているかどうかの確認が試みられます。
これは、ユーザーの最初のアクセスであるため、ユーザーは認証のためにAccess Manager 11gアクセス・サーバーにリダイレクトされます。
アクセス・サーバーの資格証明コレクタ脚注2 ・コンポーネントによってログイン・フォームが表示されます。脚注3 ユーザーは、自身の資格証明をアクセス・サーバーに送信します。
アクセス・サーバーによって、ユーザーの資格証明が検証され、セキュリティ・トークン(Cookie)が生成されます。ユーザーは、ステップ1でアクセスを試みたリソースにリダイレクトされます。
Access Managerエージェントによってリクエストがインターセプトされ、セキュリティ・トークン(Cookie)が抽出されます。
Access Managerエージェントによってアクセス・サーバーにバック・チャネル呼出し脚注4 (TCPを介したOAP)が行われ、セッションが検証され、リクエストが認可されます。
アクセス・サーバーによって、そのWebリソースの構成済ポリシーに対してユーザーの権限が検証されます。
アクセス・サーバーは、WebGateリクエストに応答し、そのアクセスが許可されることを示します。
Access Managerエージェントによって、リクエストの通過が許可されます。脚注5
ユーザーは、手順1でアクセスを試みたWebリソースにアクセスできるようになります。
アクセス・サーバーと管理コンソールは、WebLogic Serverの提供するユーザー・インタフェースおよびコマンドライン・ツールから起動できます。
アクセス・サーバーは、障害の検出のためにロード・バランサで使用できるヘルス・チェック・リクエスト(HTTPを介したpingリクエスト)をサポートしています。
Access Managerエージェントは、保護されたアプリケーション環境に常駐するネイティブ・アプリケーションです。OAMの一部として提供されているツールはありませんが、環境固有のツールが使用可能な場合は、それが前述の目的で使用されます。
Access Managerは、サーバー・サイド・メトリック用(DMSを使用)にインスツルメント処理されており、この情報はWebLogic管理コンソールに公開されます。コンポーネントの監視のかわりとして、DMSメトリック収集を使用してエージェントおよびサーバー・コンポーネント・メトリックを監視できます。さらに、Access Managerは、きめ細かいリアルタイム・アクティビティ・トレースをサポートしており、それもコンポーネントの監視のかわりとして使用できます。
アクセス・サーバーは、起動時にバックエンド・リポジトリへの接続を初期化します。リポジトリに到達不能な場合、アクセス・サーバーはリポジトリへの接続を再試行します。この接続の再試行には指数関数的に増加するタイムアウトが使用されます。タイムアウトの上限は構成可能です。
アクセス・サーバーは、バックエンド接続が停止した場合はローカルにキャッシュしたデータに基づいてサービスの継続性を提供します。これは、キャッシュが失効するか、バックエンド接続が復活するまで継続されます。
Access Managerの構成アーティファクトには、次のファイルが含まれています。
DOMAIN_HOME/config/fmwconfig/oam-configuration.xml
構成ファイル。インスタンス固有の情報が含まれています。
DOMAIN_HOME/config/fmwconfig/oam-policy.xml
DOMAIN_HOME/config/fmwconfig/.oamkeystore
これは、対称鍵および非対称鍵の格納に使用されます。
DOMAIN_HOME/config/fmwconfig/component_events.xml
監査定義に使用されます。
DOMAIN_HOME/config/fmwconfig/jazn-data.xml
管理コンソールの権限に使用されます。
DOMAIN_HOME/config/fmwconfig/servers/インスタンス名/logging.xml
ロギング構成に使用されます。このファイルは、手動では編集しないでください。
DOMAIN_HOME/config/fmwconfig/servers/インスタンス名/dms_config.xml
トレース・ロギングに使用されます。このファイルは、手動では編集しないでください。
DOMAIN_HOME/config/fmwconfig/cwallet.sso
OAMがアイデンティティ・ストア、データベースおよびその他のエンティティへの接続に使用するストア・パスワードに使用されます。これは、エンド・ユーザー用のパスワードではありません。
Access Managerは、次の項目に対して外部ランタイム依存性があります。
LDAPベースのアイデンティティ・ストア
ユーザー・アイデンティティ・リポジトリ
ユーザー/ロールAPIによって抽象化されるLDAPアクセス
注意: Access Managerは、常に1つのアイデンティティ・ストアに接続しますが、そのアイデンティティ・ストアは物理サーバーまたはロード・バランサIPです。プライマリが停止した場合、Access Managerはロード・バランサに再接続し、ロード・バランサによってセカンダリに接続します。 |
OCSPレスポンダ・サービス
リアルタイムX.509認証検証
RDBMSポリシー・ストア
ポリシー(認証および認可)リポジトリ
OAMポリシー・エンジンによって抽象化されるRDBMSアクセス
Oracle Identity Manager(OIMベースのパスワード管理が有効化されている場合)
Oracle Identity Managerはパスワード管理サービスを提供します。これはOracle Access Manager 10g Identity Serverにかわるものです。
Oracle Identity Managerポリシー・ストア(Oracle Identity Managerベースのパスワード管理が有効化されている場合)
構成、メタデータなどを格納するために使用されるOblixスキーマ要素を含むLDAPリポジトリ
Oracle Adaptive Access Manager(Oracle Adaptive Access Managerの拡張認証スキームが選択されている場合)
Identity Federation(Identity Federationの認証スキームが選択されている場合)
この項では、Access Managerを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。
図9-4は、Access Managerの高可用性アーキテクチャを示しています。
図9-4では、着信認証リクエストは、ハードウェア・ロード・バランサによって受信されてから、Web層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。次に、Oracle HTTP Serverによって、WebLogicプラグインmod_wl_ohs.conf
が使用されてWebLogic管理対象サーバーにリクエストが転送されます。分散型資格証明コレクタにより、Webゲートが資格証明を収集し、OAPプロトコルによりAccess Managerサーバーに送信することが可能になります。
ロード・バランシング・ルーターは、HTTPトラフィックに対してのみセッション・スティックネスを使用する必要があります。OAPトラフィックは、ロード・バランシング・ルーターを使用しません。そのため、OAPトラフィックに対してはセッション・スティックネスは必要ありません。
他のOracle HTTP Serverからアクセスされ、さらにはアクセスが制限されているリソースを持つアプリケーションには、WebGate、Oracle Single Sign-On Serverエージェント(mod_ossoエージェント)、OpenSSOポリシー・エージェントまたはカスタム・エージェントを構成する必要があります。WEBHOST3上のWebGateは、OAPを使用してアプリケーション層のOAMHOST1およびOAMHOST2上のアクセス・サーバーと通信します。WEBHOST3は、アプリケーションWebサーバーであり、認証のためにHTTPリダイレクトを使用して、リクエストをロード・バランサへ、そしてWEBHOST1およびWEBHOST2にルーティングします。高可用性デプロイメントにするために、オプションでWEBHOST3と同じコンポーネントを持つホストをもう1つ(たとえばWEBHOST4)を構成できます。
OAMHOST1およびOAMHOST2は、Oracle Access Serverアプリケーションをホストする管理対象サーバーをデプロイします。これらの管理対象サーバーは、アクセス・サーバーがアクティブ/アクティブ的に動作できるように、クラスタにおいて構成されます。
Oracle WebLogic管理サーバーはOAMHOST1上で実行され、WebLogic管理コンソール、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Access Managementコンソールをデプロイします。管理サーバーは、OAMHOST2上でアクティブ/パッシブ・モードで実行するように構成できます。つまり、OAMHOST1が使用不可になった場合に、管理サーバーをOAMHOST2上で手動で起動できます。
ディレクトリ層で、仮想IP ovd.mycompany.com
は、Oracle Virtual DirectoryリクエストをOVDHOST1とOVDHOST2にルーティングするように設定されます。OVDHOST1とOVDHOST2は、アクティブ/アクティブのOracle Virtual Directoryクラスタを構成します。仮想IP oid.mycompany.com
は、Oracle Internet DirectoryリクエストをOIDHOST1とOIDHOST2にルーティングするように設定されます。OIDHOST1とOIDHOST2は、アクティブ/アクティブのOracle Internet Directoryクラスタを構成します。
Oracle RACデータベースは、データ層における高可用性を提供します。
Access Manager 11gでは、WebLogic ServerドメインごとにサポートされるAccess Managerクラスタは1つのみです。Access Managerクラスタは、複数のWebLogic Serverドメインにわたることはできません。
単一インスタンスのAccess Managerデプロイメントは、次の高可用性要件を満たします。
ロード処理
外部接続管理と監視
リカバリ
フォルト包含
フォルト診断
管理サーバーのオフライン
複数インスタンスのAccess Managerデプロイメントは、さらに次の高可用性要件を満たします。
冗長性
クライアント接続のフェイルオーバー/継続性
クライアントのロード・バランシング
状態管理
インバウンドHTTP接続の場合は、外部ロード・バランシング・ルーターの使用をお薦めします。LDAPサーバー(またはOAMポリシー・エンジンPDP/PIP)へのアウトバウンド外部接続はロード・バランシングされ、接続フェイルオーバーに対してもサポートされます。Access Managerエージェント、通常Webゲートは、複数のアクセス・サーバーにわたる接続をロード・バランシングできます。
Access Managerエージェントは、アクセス・サーバーへの永続TCP接続を開きます。これには、TCP接続の早すぎる終了を回避するためにファイアウォール接続タイムアウトを十分大きい値にする必要があります。
アクセス・サーバーとAccess Manager管理コンソールは、ポリシー評価および管理のために、OAMポリシー・エンジンと連動します。OAMポリシー・エンジンは、ポリシー・リポジトリとしてのデータベースに内部依存します。データベースの相互作用はOAMポリシー・エンジン内にカプセル化され、Access Managerからは、その接続構成情報のみを管理できます。Access ManagerとOAMポリシー・エンジン間の相互作用の高可用性の特性は、次のとおりです。
データベース接続情報は、Access Managerインスタンス間で同期されるAccess Manager構成ファイルで構成されます。
データベース通信はOAMポリシー・エンジン内で管理され、通常、Access ManagerとOAMポリシー・エンジンの相互作用からは分離されます。ただし、OAMサーバー・インスタンスの最初の起動は、データベースに到達不能な場合、失敗します。OAMポリシー・エンジンのブートストラップの障害はAccess Managerによって致命的として処理され、起動操作は中断されます。
一時的なデータベースの使用不能は、OAMポリシー・エンジン・ポリシー評価サービスによって透過的に許容され、Access Managerサーバー・ランタイムは中断されることなく継続的に機能します。最初のOAMポリシー・エンジンのブートストラップの後、データベースが到達不能でも、Oracle Access Managerインスタンスは再起動でき、OAMポリシー・エンジンはそのローカルにキャッシュされたポリシーに対して処理を継続します。
Access Managerポリシー管理インタフェース(Oracle Access ManagementコンソールおよびCLIツール内)は、OAMポリシー・エンジン管理サービス・インタフェースからみてデータベースが到達不能である場合に失敗します。操作は後で再試行できますが、管理操作に対して自動化された再試行は提供されていません。
データベース・リポジトリでポリシーが変更されると、OAMサーバー・ランタイムのOAMポリシー・エンジン・レイヤーが、(Access Managerの構成で構成される)構成可能なOAMポリシー・エンジン・データベース・ポーリング間隔内でその変更を取得し、アクティブ化します。ポリシー変更の肯定応答を、各OAMサーバー・ランタイムから受信する必要がありますが、それ以外の場合は、そのポリシー変更はアクティブ化に成功したとみなされません。管理者は、Oracle Access Managementコンソールを使用して、サービスから、ポリシー・アクティブ化が失敗したAccess Managerインスタンスを削除できます。
高可用性アーキテクチャでは、OAMサーバーは、Oracle WebLogicクラスタにデプロイされますが、このクラスタには、その一部として少なくとも2つのサーバーが存在します。
デフォルトでは、WebLogic Serverによって、このアプリケーションに対する様々なライフサイクル・イベントの起動、停止、監視および管理が行われます。Access Managerアプリケーションは、基盤となるOracle WebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。
高可用性環境では、WebLogicノード・マネージャはWebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。
Access Managerが使用する標準Java EEアーティファクトは、Access ManagerがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソースなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、Access Managerコンポーネントで使用されるライブラリを同期します。
さらに、Access Managerのアプリケーション・レベルの構成は、Access Managerリポジトリに格納されます。すべてのクラスタ・メンバーへのAccess Managerの構成変更の伝播は、Coherence分散オブジェクト・キャッシュを活用する配布メカニズムに基づきます。すべてのAccess Managerコンポーネントは、変更イベントをCoherenceレイヤーから通知されて取得します。変更の原子性を確保するために、Access Managerコンポーネントには、変更が行われるたびにそれらの構成全体がリロードされます。
Access Managerの構成は、クラスタ内のすべてのインスタンスに適用されます。Access Managerでサポートされる前述の構成(インスタンス固有の構成)の例外は、Access Managerプロキシ・ホスト、Access Managerプロキシ・ポートおよびインスタンス固有のCoherence構成(Well Knownアドレス(WKA)が使用されている場合)のみです。プロキシ・ホストのIPアドレスおよびプロキシ・ポートは、構成ファイルに格納されます。Access Managerプロキシ・ポートは、エージェントからのOAPリクエストのエンドポイントです。Coherence WKAのIPアドレスも、構成ファイルに格納されます。Coherence WKAは、Access Manager固有のトラフィックを受信する権限を付与されたCoherenceノードを判別するために使用されます。oam-configuration.xml
ファイルは、この構成情報を格納する構成ファイルです。
アクセス・サーバー・インスタンスの追加および削除は、クラスタ内の他のAccess Manager Access Serverインスタンスに対して透過的です。ただし、特定のアクセス・サーバーの削除が、エージェントのロード・バランシングとフェイルオーバーの特性に影響を与えないように注意してください。
Access Manager Access Serverを再起動しても、クラスタ内の他の実行中のコンポーネントやメンバーには影響ありません。
この項では、Oracle Identity Managementの高可用性クラスタ・デプロイメントによって、コンポーネントを障害から保護する仕組みと、コンポーネントの障害が発生したときに予想される動作について説明します。
WebLogic Serverインフラストラクチャにより、Identity Managementサービス・インフラストラクチャ・システムは、あらゆるプロセス障害から保護されます。
また、次の機能もAccess Managerの高可用性構成を障害から保護します。
バック・チャネルOAPバインディングでは、フェイルオーバーのためにプライマリ/セカンダリ・モデルが使用されます。フロント・チャネルHTTPバインディングでは、フェイルオーバーのためにロード・バランシング・ルーターが使用されます。
セッションの状態は、Coherence分散オブジェクト・キャッシュで保持され、それは、すべてのセッションの状態情報についてレプリケーションとフェイルオーバーを提供します。Coherenceキャッシュに格納されたデータは、データベースに非同期的に書き込まれます。このデータは、すべてのアクセス・サーバーが再起動されても保持されます。ただし、書込みの非同期的な性質により少量のデータが失われる可能性があります。
アクセス・サーバーで障害が発生した場合、そのサーバーへの永続接続を持つWebGateは、接続がタイムアウトするまで待機し、その後にセカンダリ(バックアップ)アクセス・サーバーに切り替えます。未処理のリクエストは、セカンダリ・サーバーにフェイルオーバーされます。
Access Manager Access Serverは、ハートビート・チェックをサポートしています。また、管理対象サーバー上のWebLogicノード・マネージャは、アプリケーションを監視して、そのアプリケーションを再起動できます。
WebLogic Serverノードに障害が発生すると、構成、再試行のタイムアウトおよび再試行の回数に基づいて外部接続のフェイルオーバーが行われます。Access Managerエージェントとアクセス・サーバーのフェイルオーバーはタイムアウトに基づいています。
ロード・バランシング・ルーターまたはプロキシ・サーバーがWebLogic Serverノードの障害を検出した場合、後続のクライアント接続は、アクティブ・インスタンスにルーティングされ、そのセッション状態を取得して処理を継続します。
接続の存続時間が期限切れした場合、保留中のリクエストは接続が終了する前に完了します。接続オブジェクトはプールに戻されます。
別のサービスから例外を受信した場合、Access Managerは、外部接続リクエストを再試行します。再試行回数は設定が可能です。
WLS_OAMxサーバーで障害が発生すると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。
HTTP Serverからの処理中のリクエストはタイムアウトして、新しいリクエストは他のWLS_OAMxサーバーに送られます。障害が発生したノードでサーバーが正常に再起動されると、Oracle HTTP Serverは、受信したリクエストのサーバーへのルーティングを再開します。
注意: Access Managerサーバーは、アクセス・サーバーがそのリクエストにサービスを提供できるかどうかを判別するため、ハートビート・チェックをサポートします。次のチェックを行います。
ハートビート・チェックに成功した場合、アクセス・サーバーはリクエストの処理が可能であり、リクエストがそれに送信されます。ハートビート・チェックで問題がある場合、リクエストはアクセス・サーバーにルーティングされません。 |
ノード障害は、WebLogic Serverの障害と同じ方法で処理されます。
Access Managerサービス・インフラストラクチャは、マルチ・データ・ソースの使用によりデータベースの障害から保護されます。通常、これらのマルチ・データ・ソースは、システムの初期設定時に構成されます(Oracle Fusion Middleware構成ウィザードで、インストール時にこれらのマルチプールを直接定義できます)。これらのソースによって、Oracle RACデータベース・インスタンスで障害が発生した場合に、使用可能なデータベース・インスタンスとの接続が再確立されることが保証されるようになります。マルチ・データ・ソースを使用すると、Oracle RACデータベース内の複数のインスタンスへの接続を構成できます。
Oracle RACおよびMDSリポジトリでのマルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。
この項では、Access Managerで高可用性を得るためのデプロイメントを設定する高度な手順について説明します。このデプロイメントには、2つのOracle HTTP Serverが含まれており、それらは、リクエストを2つのOAMサーバーに配布します。これらのOAMサーバーは、Oracle Real Application Clusters (Oracle RAC)データベースおよび、(オプションで)外部LDAPストアと対話します。1つのコンポーネントで障害が発生しても、残りのコンポーネントは引き続き機能します。
この項の内容は次のとおりです。
Access Managerを高可用性のために構成する前に、次の操作を実行しておく必要があります。
リポジトリ作成ユーティリティを実行して、データベースにAccess Managerのスキーマを作成します。第9.2.3.2項「リポジトリ作成ユーティリティの実行によるデータベース・スキーマの作成」を参照してください。
OAMHOST1およびOAMHOST2にOracle WebLogic Serverをインストールします。第9.2.3.3項「Oracle WebLogic Serverのインストール」を参照してください。
OAMHOST1およびOAMHOST2にOracle Identity Management実行可能ファイルをインストールします。第9.2.3.4項「Access Manager Application Tierのインストールと構成」を参照してください。
高可用性LDAP実装が使用可能であることを確認します。Oracle Internet Directoryのインストールと構成の詳細は、第8.3.3項「Oracle Internet Directoryの高可用性の構成手順」を参照してください。Oracle Virtual Directoryのインストールと構成の詳細は、第8.4.3項「Oracle Virtual Directoryの高可用性の構成手順」を参照してください。
作成するスキーマは、インストールおよび構成する製品により異なります。インストールする製品と互換性のあるバージョンのリポジトリ作成ユーティリティ(RCU)を使用します。RCUを実行するには、Oracle Fusion Middlewareインストレーション計画ガイドおよびOracle Fusion Middlewareリポジトリ作成ユーティリティ・ユーザーズ・ガイドを参照してください。
Oracle WebLogic Serverをインストールする前に、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』で指定されているように、ご使用のマシンのシステム、パッチ、カーネルの要件、およびその他の要件が満たされていることを確認します。
インストーラを起動し、次の手順を実行します。
「ようこそ」画面で、「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で、「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。
ORACLE_BASE/product/fmw
注意: ORACLE_BASEは、Oracle製品のインストール先であるベース・ディレクトリです。推奨値は |
「次へ」をクリックします。
セキュリティ・アップデートが通知できるようにするために、連絡先情報を入力します。
「次へ」をクリックします。
「インストール・タイプの選択」画面で、「カスタム」を選択します。
「次へ」をクリックします。
「製品とコンポーネントの選択」画面で、「Oracle JRockit SDK」のみを選択し、「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、ディレクトリORACLE_BASE/product/fmw/wlserver_10.3
を受け入れます。
「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「Quickstartの実行」の選択を解除します。
「完了」をクリックします。
この項では、Oracle Fusion MiddlewareコンポーネントをOAMHOST1およびOAMHOST2にインストールする方法について説明します。
この項では、Oracle Identity Managementソフトウェアを、前に作成したMiddlewareホーム・ディレクトリにインストールする手順について説明します。OAMHOST1およびOAMHOST2上で手順を実行します。
Linuxプラットフォームで、/etc/oraInst.loc
ファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.loc
ファイルが存在しない場合、この手順をスキップできます。
次のようにOracle Fusion Middlewareのインストーラを起動します。
OAMHOST1> runInstaller
インストーラで、JRE/JDKの場所を入力するように求められたら、WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE/product/fmw/jrockit_160_
<バージョン>のように入力します。
次のように実行します。
「ようこそ」画面で、「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を入力します。
Oracle Middlewareホーム: MW_HOME
のリストから前にインストールしたMiddlewareホームを選択します。次に例を示します。
/u01/app/oracle/product/fmw
Oracleホーム・ディレクトリ: idm
を入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
「インストール完了」画面で「終了」をクリックします。
この項では、OAMHOST1にOracle Identity Managementドメインを作成します。
次のコマンドを実行して、構成ウィザードを起動します。
MW_HOME/oracle_common/common/bin/config.sh
次のように実行します。
「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」画面で、次を選択します。
「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。
次の製品を選択します。
Oracle Enterprise Manager
Oracle JRF(デフォルトで選択)
Oracle Access Management
Oracle Platform Security Service
「次へ」をクリックします。
「ドメイン名と場所の指定」画面で、次を入力します。
ドメイン名: IDM_Domain
ドメインの場所: デフォルトを受け入れます。
アプリケーション・ディレクトリ: デフォルトを受け入れます。
「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。
WebLogicドメインの起動モード: 「本番モード」を選択します。
JDKの選択: 「JROCKIT SDK1.6.0_<バージョン>」を選択します。
「JDBCコンポーネント・スキーマの構成」画面で、すべてのデータ・ソースを選択し、「次のパネルで選択したデータ・ソースをRACマルチ・データ・ソースとして構成します。」を選択します。
「次へ」をクリックします。
「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、最初のデータ・ソースであるOAMインフラストラクチャを選択し、次の項目を入力します。
データ・ソース: OAM
サービス名: oam.mycompany.com
ユーザー名: OAM_OAM(OAMがRCU接頭辞として使用されていたと想定)
パスワード: 前述のアカウント用のパスワード
右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。
ホスト名: OAMDBHOST1
インスタンス名: oamdb1
ポート: 1521
再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。
ホスト名: OAMDBHOST2
インスタンス名: oamdb2
ポート: 1521
「次へ」をクリックします。
「コンポーネント・スキーマのテスト」画面で、データ・ソースの検証が試行されます。
データ・ソースの検証が成功した場合、「次へ」をクリックします。
失敗した場合は、「前へ」をクリックし、問題を修正して、やり直します。
「オプションの構成を選択」画面で、次を選択します。
管理サーバー
管理対象サーバー、クラスタ、およびマシン
「次へ」をクリックします。
「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: OAMHOST1.mycompany.com
リスニング・ポート: 7001
SSLリスニング・ポート: 適用なし
SSL有効: 選択を解除
「次へ」をクリックします。
「管理対象サーバーの構成」画面で、トポロジのOAMHOSTごとにエントリを作成します。つまり、OAMHOST1上で実行されているOAMサーバーに対して1つと、OAMHOST2上で実行されているOAMサーバーに対して1つ作成します。
OAM_SERVERエントリを選択し、そのエントリを次の値に変更します。
名前: WLS_OAM1
リスニング・アドレス: OAMHOST1.mycompany.com
リスニング・ポート: 14100
2つ目のOAM_SERVERに対して、「追加」をクリックし、次の情報を入力します。
名前: WLS_OAM2
リスニング・アドレス: OAMHOST2.mycompany.com
リスニング・ポート: 14100
「次へ」をクリックします。
「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成します。
名前としてOAM_Clusterを入力します。
その他すべてのフィールドはデフォルトの設定のままにします。
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、次のように管理対象サーバーをクラスタに関連付けます。
右のウィンドウでクラスタ名OAM_Clusterをクリックします。
管理対象サーバーWLS_OAM1をクリックし、矢印をクリックしてそれをクラスタに割り当てます。
管理対象サーバーWLS_OAM2に対しても同様に繰り返します。
「次へ」をクリックします。
「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。ホストでUNIXベースのオペレーティング・システムを使用する場合は、「Unix」タブをクリックします。それ以外の場合は、「マシン」タブをクリックします。次の情報を指定します。
名前: ホスト名です。ベスト・プラクティスは、DNS名(OAMHOST1)を使用することです。
ノード・マネージャ・リスニング・アドレス: マシンのDNS名(OAMHOST1.mycompany.com)
ノード・マネージャ・ポート: ノード・マネージャが使用するポート。
OAMHOST2に対しても次のように手順を繰り返します。
名前: ホスト名です。ベスト・プラクティスは、DNS名(OAMHOST2)を使用することです。
ノード・マネージャ・リスニング・アドレス: マシンのDNS名(OAMHOST2.mycompany.com)
ノード・マネージャ・ポート: ノード・マネージャが使用するポート。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを指定します。
右のウィンドウでマシンOAMHOST1をクリックします。
左のウィンドウで管理対象サーバーWLS_OAM1をクリックします。
矢印をクリックし、その管理対象サーバーをホストOAMHOST1に割り当てます。
右のウィンドウでマシンOAMHOST2をクリックします。
左のウィンドウで管理対象サーバーWLS_OAM2をクリックします。
矢印をクリックし、その管理対象サーバーをホストOAMHOST2に割り当てます。
「次へ」をクリックします。
「構成のサマリー」画面で、「作成」をクリックし、作成プロセスを開始します。
注意: 構成を変更するためにconfig.shスクリプトを2回実行することはできないため、構成に追加の変更を行う場合は、Fusion Middleware ControlのMBeansブラウザの使用などの別のツールを使用する必要があります。 |
ドメインの構成後、管理サーバーを起動する前に、データベース・セキュリティ・ストアを構成する必要があります。詳細は、第9.1.3.3項「ドメイン用のデータベース・セキュリティ・ストアの構成」を参照してください。
この項では、OAMHOST1上の管理サーバーに対してboot.properties
ファイルを作成する方法について説明します。boot.properties
ファイルを使用すると、administrator
のユーザー名とパスワードの入力を求められることなく管理サーバーを起動できます。
boot.properties
ファイルを作成する手順は次のとおりです。
OAMHOST1で、次のディレクトリに移動します。
MW_HOME
/user_projects/domains/domainName
/servers/AdminServer/security
例:
cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security
テキスト・エディタを使用して、boot.properties
という名前のファイルをsecurity
ディレクトリの下に作成します。次の行をファイルに入力します。
username=adminUser
password=adminUserPassword
注意: 管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。 セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。 |
管理サーバーが実行されている場合は停止します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。
MW_HOME
/user_projects/domains/
domainName
/bin
ディレクトリにあるstartWebLogic.shスクリプトを使用して、OAMHOST1の管理サーバーを起動します。
Webブラウザを開いて次のページにアクセスし、変更が正常に行われたことを確認します。
WebLogic Server管理コンソール:
http://oamhost1.mycompany.com:7001/console
Oracle Enterprise Manager Fusion Middleware Control:
http://oamhost1.mycompany.com:7001/em
weblogic
ユーザーの資格証明を使用して、これらのコンソールにログインします。
この項では、OAMHOST1の起動手順について説明します。
コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/bin
ディレクトリにあるsetNMProps.sh
スクリプトを実行することによって行います。例:
OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh
次のコマンドを発行してノード・マネージャを起動します。
OAMHOST1> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh
OAMHOST1上のAccess Managerを起動する手順は、次のとおりです。
次のURLを使用して、WebLogic管理コンソールにログインします。
http://oamhost1.mycompany.com:7001/console
WebLogic管理者のユーザー名とパスワードを指定します。
「ドメイン構造」メニューで「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
サーバーWLS_OAM1をクリックします。
「起動」をクリックします。
「OK」をクリックし、サーバーを起動することを確認します。
実装を検証するには、次のURLにあるOracle Access Managementコンソールに接続します。
http://OAMHOST1.mycompany.com:7001/oamconsole
OAM管理コンソールのログイン・ページが開き、WebLogic administrator
アカウントを使用してログインできる場合、実装は有効です。
OAMHOST1で構成を完了したら、それをOAMHOST2に伝播できます。これを実行するには、OAMHOST1でpack
スクリプトを使用してドメインをパックし、OAMHOST2でunpack
スクリプトを使用してドメインを解凍します。
スクリプトは両方とも、MW_HOME/oracle_common/common/bin
ディレクトリにあります。
OAMHOST1で、次のように入力します。
pack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
-template=/tmp/idm_domain.jar -template_name="OAM Domain" -managed=true
これにより、/tmp
ディレクトリにidm_domain.jar
というファイルが作成されます。このファイルをOAMHOST2にコピーします。
OAMHOST2で、次のように入力します。
unpack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
-template=/tmp/idm_domain.jar
この項では、OAMHOST2を起動する手順について説明します。
コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/bin
ディレクトリにあるsetNMProps.sh
スクリプトを実行することによって行います。例:
OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh
次のコマンドを発行してノード・マネージャを起動します。
OAMHOST2> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh
OAMHOST2上のAccess Managerを起動する手順は、次のとおりです。
次のURLを使用して、WebLogic管理コンソールにログインします。
http://oamhost2.mycompany.com:7001/console
WebLogic管理者のユーザー名とパスワードを指定します。
「ドメイン構造」メニューで「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
サーバーWLS_OAM2をクリックします。
「起動」をクリックします。
「OK」をクリックし、サーバーを起動することを確認します。
次のURLを使用してOAMサーバーに接続することによって実装を検証します。
http://OAMHOST2.mycompany.com:14100/oam
OAMログイン・ページが表示される場合、実装は有効です。この時点では、アクションが失敗したことを示すエラーがページに表示されることに注意してください。これは、ログイン・リクエストとしてではなくページに直接アクセスしたためであり、正常な動作です。
この項では、Oracle HTTP Serverと連携するためのAccess Managerの構成手順について説明します。
WEBHOST1およびWEBHOST2で、次のディレクトリにoam.conf
というファイルを作成します。
ORACLE_INSTANCE/config/OHS/ohs1/moduleconf
次の行を指定してファイルを作成します。
NameVirtualHost *:7777 <VirtualHost *:7777> ServerName sso.mycompany.com:7777 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit <Location /oam> SetHandler weblogic-handler Debug ON WLLogFile /tmp/weblogic.log WLProxySSL ON WLProxySSLPassThrough ON oamhost1.mycompany.com:14100,oamhost2.mycompany.com:14100 WebLogicCluster </Location> <Location /oamfed> SetHandler weblogic-handler Debug ON WLLogFile /tmp/weblogic.log WLProxySSL ON WLProxySSLPassThrough ON WebLogicCluster oamhost1.mycompany.com:14100,oamhost2.mycompany.com:14100 </Location> </VirtualHost>
WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。
WEBHOST1>opmnctl stopall WEBHOST1>opmnctl startall WEBHOST2>opmnctl stopall WEBHOST2>opmnctl startall
デフォルトでは、Access Managerではローカル・サーバーにあるログイン・ページにリクエストに送信します。高可用性デプロイメントでは、この設定を変更してログイン・ページ・リクエストがローカル・バランサに送信されるようにする必要があります。
Access Managerにロード・バランサを認識させる手順は、次のとおりです。
次のURLで、Oracle Access Managementコンソールにweblogic
ユーザーとしてログインします。
http://IDMHOST1.mycompany.com/oamconsole
「システム構成」タブをクリックします。
Access Managerの設定を開きます。
Access Managerの設定をダブルクリックします。
次の情報を入力します。
OAMサーバー・ホスト: sso.mycompany.com
OAMサーバー・ポート: 7777
OAMサーバー・プロトコル: http
「適用」をクリックします。
管理対象サーバーWLS_OAM1およびWLS_OAM2を再起動します。
デフォルトでは、Access Managerでは、組込みLDAPサーバーにある独自コンポーネントを使用します。高可用性構成では、ディレクトリ・ストアとして外部LDAPディレクトリを使用することをお薦めします。この項では、外部LDAPストアの設定方法について説明します。
注意: この項で説明する手順を実行する前に、環境およびLDAPストアをバックアップしておくことをお薦めします。 |
アイデンティティ・ストアを事前構成することで、ディレクトリ・タイプに関係なくバックエンド・ディレクトリのスキーマを拡張します。
Access Managerのためにディレクトリ・スキーマを拡張するには、OAMHOST1上で次のタスクを実行します。
環境変数MW_HOME
、JAVA_HOME
、IDM_HOME
およびORACLE_HOME
を設定します。
IDM_HOME
をIDM_ORACLE_HOME
に設定します。
ORACLE_HOME
をIAM_ORACLE_HOME
に設定します。
次の項目を含む、プロパティ・ファイルextend.props
を作成します。
IDSTORE_HOST : idstore.mycompany.com
IDSTORE_PORT : 389
IDSTORE_BINDDN : cn=orcladmin
IDSTORE_USERNAMEATTRIBUTE: cn
IDSTORE_LOGINATTRIBUTE: uid
IDSTORE_USERSEARCHBASE:cn=Users,dc=mycompany,dc=com
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=us,dc=oracle,dc=com
IDSTORE_SEARCHBASE: dc=mycompany,dc=com
IDSTORE_SYSTEMIDBASE: cn=systemids,dc=mycompany,dc=com
説明:
IDSTORE_HOST
およびIDSTORE_PORT
は、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。(OVDではなく、バックエンド・ディレクトリを指定します。)
IDSTORE_BINDDN
は、アイデンティティ・ストア・ディレクトリの管理ユーザーです。
IDSTORE_USERSEARCHBASE
は、ユーザーを配置するアイデンティティ・ストアの場所です。
IDSTORE_GROUPSEARCHBASE
は、グループを配置するアイデンティティ・ストアの場所です。
IDSTORE_SEARCHBASE
は、ユーザーおよびグループを格納するディレクトリの場所です。
IDSTORE_SYSTEMIDBASE
は、Oracle Identity Managerリコンシリエーション・ユーザーを配置するディレクトリの場所です。
IDSTORE_SYSTEMIDBASE
は、メイン・ユーザー・コンテナに配置する必要のないユーザーを配置できるディレクトリにあるコンテナの場所です。このような事態はほとんどありませんが、その一例としてOracle Virtual DirectoryアダプタのバインドDNユーザーにも使用されるOracle Identity Managerリコンシリエーション・ユーザーがあげられます。
idmConfigTool
コマンドを使用して、アイデンティティ・ストアを作成します。このコマンドは、IAM_ORACLE_HOME/idmtools/bin
にあります。
Linuxコマンドの構文:
idmConfigTool.sh -preConfigIDStore input_file=configfile
Windowsコマンドの構文:
idmConfigTool.bat -prepareIDStore input_file=configfile
例:
idmConfigTool.sh -preConfigIDStore input_file=extend.props
このコマンドを実行すると、アイデンティティ・ストアへの接続に使用しているアカウントのパスワードを求めるプロンプトがシステムによって表示されます。
次に、コマンドの出力例を示します。
Enter ID Store Bind DN password : Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_template.ldif Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_acl_template.ldif Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/systemid_pwdpolicy.ldif Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idstore_tuning.ldifApr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oid_schema_extn.ldif The tool has completed its operation. Details have been logged to automation.log
ログ・ファイルを確認して、エラーや警告を修正します。
Access Managerが必要とするユーザーをアイデンティティ・ストアに追加する手順は、次のとおりです。
環境変数MW_HOME
、JAVA_HOME
、IDM_HOME
およびORACLE_HOME
を設定します。
IDM_HOME
をIDM_ORACLE_HOME
に設定します。
ORACLE_HOME
をIAM_ORACLE_HOME
に設定します。
次の項目を含む、プロパティ・ファイルoam.props
を作成します。
IDSTORE_HOST : idstore.mycompany.com
IDSTORE_PORT : 389
IDSTORE_BINDDN : cn=orcladmin
IDSTORE_USERNAMEATTRIBUTE: cn
IDSTORE_LOGINATTRIBUTE: uid
IDSTORE_USERSEARCHBASE: cn=Users,dc=mycompany,dc=com
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=mycompany,dc=com
IDSTORE_SEARCHBASE: dc=mycompany,dc=com
POLICYSTORE_SHARES_IDSTORE: true
OAM11G_IDSTORE_ROLE_SECURITY_ADMIN:OAMAdministrators
IDSTORE_OAMSOFTWAREUSER:oamLDAP
IDSTORE_OAMADMINUSER:oamadmin IDSTORE_SYSTEMIDBASE:cn=systemids,dc=mycompany,dc=com
説明:
IDSTORE_HOST
およびIDSTORE_PORT
は、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。
IDSTORE_BINDDN
は、アイデンティティ・ストア・ディレクトリの管理ユーザーです。
IDSTORE_USERSEARCHBASE
は、ユーザーが格納されるディレクトリの場所です。
IDSTORE_GROUPSEARCHBASE
は、グループが格納されるディレクトリの場所です。
IDSTORE_SEARCHBASE
は、ユーザーおよびグループを格納するディレクトリの場所です。
POLICYSTORE_SHARES_IDSTORE
は、ポリシー・ストアとアイデンティティ・ストアが同じディレクトリに存在する場合にはtrueを設定します。そうでない場合は、falseを設定します。
IDSTORE_OAMADMINUSER
は、Access Manager管理者として作成するユーザーの名前です。
IDSTORE_OAMSOFTWAREUSER
は、LDAPに作成されるユーザーで、Access Managerが実行中にLDAPサーバーに接続するために使用されます。
idmConfigTool
コマンドを使用して、アイデンティティ・ストアを作成します。このコマンドは、IAM_ORACLE_HOME/idmtools/bin
にあります。
Linuxコマンドの構文:
idmConfigTool.sh -prepareIDStore mode=OAM input_file=configfile
Windowsコマンドの構文:
idmConfigTool.bat -prepareIDStore mode=OAM input_file=configfile
例:
idmConfigTool.sh -prepareIDStore mode=OAM input_file=oam.props
このコマンドを実行すると、IDストアへの接続に使用しているアカウントのパスワードを求めるプロンプトがシステムによって表示されます。
次に、コマンドの出力例を示します。
Enter ID Store Bind DN password : Apr 5, 2011 3:53:28 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oblix_schema_add.ldif Apr 5, 2011 3:54:12 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oblix_schema_index_add.ldif Apr 5, 2011 3:55:10 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oblix_pwd_schema_add.ldif Apr 5, 2011 3:55:11 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oim_pwd_schema_add.ldif *** Creation of Oblix Anonymous User *** Apr 5, 2011 3:55:11 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oam_10g_anonymous_user_template.ldif Enter User Password for oblixanonymous: Confirm User Password for oblixanonymous: Apr 5, 2011 3:55:53 AM oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: -> LOADING:
/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oam_group_member_template.ldif The tool has completed its operation. Details have been logged to automation.log
ログ・ファイルを確認して、エラーや警告を修正します。
idmConfigToolコマンドの詳細は、Oracle Fusion Middleware Oracle Identity Management Suite統合概要を参照してください。
ユーザー・アイデンティティ・ストアを作成する手順は、次のとおりです。
次のURLのOracle Access Managementコンソールに移動します。
http://adminvhn.mycompany.com:7001/oamconsole
WebLogic管理ユーザーを使用してログインします。
「システム構成」→「データソース」を選択します。
「ユーザー・アイデンティティ・ストア」を選択して、「追加」をクリックします。次の情報を入力します。
ストア名: LDAP_DIR
ストア・タイプ: OVD
説明: ディレクトリ・ストアの説明を入力します
SSLの有効化: これは、SSLを使用してディレクトリと通信する場合に選択します
場所: 場所を入力します(例: ovd.mycompany.com:389)
バインドDN: LDAPストアを検索する権限を与えるユーザーを入力します。例: cn=orcladmin
パスワード: oracleadminパスワードを入力します
ユーザー名属性: たとえば、uidとします。
ユーザー検索ベース: LDAPストアのユーザーの場所を入力します。例: cn=Users,dc=mycompany,dc=com
グループ名属性: 例: orclguid
グループ検索ベース: LDAPストアのグループの場所を入力します。例: cn=Groups,dc=mycompany,dc=com
OAM管理者ロール: OAMAdministrators
「適用」をクリックします。
「接続テスト」をクリックし、LDAPサーバーへの接続を検証します。
LDAPアイデンティティ・ストアを定義したので、プライマリ認証ストアとして設定する必要があります。これを行うには、Oracle Access Managementコンソールで次の手順を実行します。
「システム構成」タブをクリックします。
ナビゲーション・ペインから「データ・ソース - ユーザー・アイデンティティ・ストア」を選択します。
「LDAP_DIR」をクリックします。
「オープン」を「アクション」メニューで選択します。
「デフォルト・ストアとして設定」をクリックします。
「システム・ストアとして設定」をクリックします。
「アクセス・システム管理者」の追加[+]アイコンをクリックします。
検索名フィールドにOAM*を入力して、「検索」をクリックします。
検索結果から「OAMAdministrators」を選択して、「選択済の追加」をクリックします。
「適用」をクリックします。
「システム管理者の検証」ウィンドウで、OAM管理者のユーザー名とパスワード(例: oamadmin)を入力します。
「検証」をクリックします。
「接続のテスト」をクリックして、接続をテストします。
デフォルトでは、Access Managerは、ユーザーの検証に統合LDAPストアを使用します。LDAP認証モジュールを更新して、そのモジュールが新しい外部LDAPストアに対してユーザーを認証できるようにします。
LDAP認証モジュールが外部LDAPを使用するように更新する手順は、次のとおりです。
「システム構成」タブをクリックします。
「Access Managerの設定」→「認証モジュール」→「LDAP認証モジュール」を選択します。
「LDAP」をクリックします。
「オープン」を「アクション」メニューで選択します。
「ユーザー・アイデンティティ・ストア」をLDAP_DIR
に設定します。
「適用」をクリックします。
管理対象サーバーの管理サーバー、WLS_OAM1およびWLS_OAM2を再起動します。
http://oamhost1.mycompany.com:7001/oamconsoleでOracle Access Managementコンソールにoamadmin
としてログインすることで、構成を検証します。
高可用性環境では、Oracleでは、Oracle Coherenceを使用して構成ファイルの同期を保ちます。Oracle Coherenceは、デフォルトではポート9095を使用しますが、これはOracle Access Managementコンソールを使用して変更できます。
URL (http://admin.example.com/oamconsole)を使用して、コンソールにログインし、次の手順を実行します。
「システム構成」タブをクリックします。
ナビゲータでサーバーを展開します。
ポートを変更する管理対象サーバーをダブルクリックします。
「コヒーレンス」タブをクリックします。
「ローカル・ポート」の値を目的の値に変更します。
「適用」をクリックします。
管理サーバーと、更新された管理対象サーバーと同じクラスタに配置されている管理対象サーバーすべてを再起動します。
この項では、Access Managerの高可用性トポロジをスケール・アップおよびスケール・アウトする方法について説明します。すでに1つ以上のサーバー・インスタンスが実行されているノードに、新しいAccess Manager管理対象サーバー・インスタンスを追加するには、スケール・アップ操作を実行します。新しいノードに、新しいAccess Manager管理対象サーバー・インスタンスを追加するには、スケール・アウト操作を実行します。
OAMをスケール・アップする手順は、次のとおりです。
Oracle WebLogic Server管理コンソール(http://oamhost1.mycompany.com:7001/console
)にログインします。
管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
拡張するホスト上のサーバーを選択します(例: WLS_OAM1
)。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3
です。
サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意である必要があります。
「OK」をクリックします。
新しく作成したサーバーWLS_OAM3をクリックします。
SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAM3
管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。OAMHOST
n
上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。
Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。表の「名前」列で「WLS_OAM3」を選択します。
「SSL」タブをクリックします。「詳細」をクリックします。
「ホスト名の検証」を「なし
」に設定します。「保存」をクリックします。
構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
新しい管理対象サーバーをOAMに登録します。この時点で、Oracle Access Managementコンソールで、新しい管理対象サーバーをOAMサーバーとして構成する必要があります。
Oracle Access Managementコンソール(http://oamhost1.mycompany.com:7001/oamconsole
)にoamadmin
ユーザーとしてログインします。
「システム構成」タブをクリックします。「サーバー・インスタンス」をクリックします。
「作成」を「アクション」メニューで選択します。
次の情報を入力します。
サーバー名: WLS_OAM3
ホスト: サーバーを実行するホスト。
ポート: 管理対象サーバーが作成されたときに割り当てられたリスニング・ポート
OAMプロキシ・ポート: OAMプロキシを実行するポート。これは当該ホストについて一意のポートです。
プロキシ・サーバーID: AccessServerConfigProxy
モード: Open
「コヒーレンス」タブをクリックします。
ホストで一意な値に「ローカル・ポート」を設定します。
「適用」をクリックします。
「適用」をクリックします。
これでアクセス・サーバーを起動できます。このアクセス・サーバーを使用するには、その存在をWebgateに通知する必要があります。この手順は次のとおりです。
Oracle Access Managementコンソール(http://oamhost1.mycompany.com:7001/oamconsole
)にoamadmin
ユーザーとしてログインします。
「システム構成」タブをクリックします。
エージェント→OAMエージェント→10gエージェント」(10g WebGatesの場合)、またはエージェント→OAMエージェント→11gエージェント(11g WebGatesの場合)を開きます。
変更するWebGateをダブルクリックします。
「追加」+アイコンをクリックして、新しいサーバーをプライマリまたはセカンダリ・サーバー・リストに追加します。
サーバー名をリストから選択します。
「適用」をクリックします。
スケール・アウトはスケール・アップとよく似ていますが、最初に新しいノードにソフトウェアをインストールする必要がある点が異なります。
第9.2.3.3項「Oracle WebLogic Serverのインストール」の手順に従い、新しいホストにOracle WebLogic Serverをインストールします。
新しいホストにIdentity Managementコンポーネントをインストールします。第9.2.3.4項「Access Manager Application Tierのインストールと構成」を参照してください。
Oracle WebLogic Server管理コンソール(http://oamhost1.mycompany.com:7001/oamconsole
)にログインします。
管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
拡張するホスト上のサーバーを選択します(例: WLS_OAM1
)。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3
です。
サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。
「OK」をクリックします。
新規作成したサーバーである「WLS_OAM3」をクリックします。
SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAM3
管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。OAMHOST
n
上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。
Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。
「環境」ノードを「ドメイン構造」ペインで開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
次のコマンドを使用してOAMHOST1
上のドメインをパックします。
pack.sh -domain=ORACLE_BASE/admin/IDM_Domain/aserver/IDM_Domain -template =/tmp/idm_domain.jar -template_name="OAM Domain" -managed=true
pack.sh
スクリプトは、MW_HOME
/oracle_common/common/bin
にあります。
次のコマンドを使用して新しいホスト上でドメインを解凍します。
unpack.sh -domain=ORACLE_BASE/admin/IDM_Domain/mserver/IDM_Domain -template=/tmp/idm_domain.jar -template_name="OAM Domain" -app_dir=ORACLE_BASE/admin/IDM_Domain/mserver/applications
unpack.sh
スクリプトは、MW_HOME
/oracle_common/common/bin
にあります。
コンソールから管理対象サーバーを起動する前に、OAMHOST3
上にノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME
/oracle_common/common/bin
にあるsetNMProps.sh
スクリプトを実行することによって行います。次のように入力します。
MW_HOME/oracle_common/common/bin/setNMProps.sh
新しい管理対象サーバーをOAMに登録します。この時点で、Oracle Access Managementコンソールで、新しい管理対象サーバーをOAMサーバーとして構成する必要があります。
Oracle Access Managementコンソール(http://oamhost1.mycompany.com:7001/oamconsole)にoamadmin
ユーザーとしてログインします。
「システム構成」タブをクリックします。「サーバー・インスタンス」をクリックします。
「作成」を「アクション」メニューで選択します。
次の情報を入力します。
サーバー名: WLS_OAM3
ホスト: サーバーを実行するホスト、OAMHOST3
。
ポート: 管理対象サーバーが作成されたときに割り当てられたリスニング・ポート。
OAMプロキシ・ポート: OAMプロキシを実行するポート。これは当該ホストについて一意のポートです。
プロキシ・サーバーID: AccessServerConfigProxy
モード: Open
「適用」をクリックします。
Access Serverを起動します。このサーバーを使用するには、その存在をWebgateに通知する必要があります。
Oracle Access Managementコンソール(http://oamhost1.mycompany.com:7001/oamconsole
)にoamadmin
ユーザーとしてログインします。
「システム構成」タブをクリックします。
「エージェント」→「OAMエージェント」→「10gエージェント」を展開します。
変更するWebGateをダブルクリックします。
「追加」+アイコンをクリックして、新しいサーバーをプライマリまたはセカンダリ・サーバー・リストに追加します。
サーバー名をリストから選択します。
「適用」をクリックします。
Web層を更新します。これで、新しい管理対象サーバーが作成されて起動され、Web層はリクエストをその管理対象サーバーに転送するようになります。ただし、ベスト・プラクティスは、新しい管理対象サーバーが作成されたことをWebサーバーに通知することです。
このためには、各Web層のOAM.conf
ファイルを更新します。このファイルは、ORACLE_INSTANCE
/config/OHS/
component name
/moduleconf
ディレクトリにあります。
新しいサーバーをこのファイル内のWebLogicCluster
ディレクティブに追加します。次に変更前の例を示します。
<Location /OAM_admin> SetHandler weblogic-handler WebLogicCluster OAMhost1.mycompany.com:14200,OAMhost2.mycompany.com:14200 </Location>
前述の行を次のように変更します。
<Location /OAM_admin> SetHandler weblogic-handler WebLogicCluster OAMhost1.mycompany.com:14200,OAMhost2.mycompany.com:14200,OAMhsot3.mycompany.com:14300 </Location>
この項では、Oracle Adaptive Access Managerの概要およびOracle Adaptive Access Managerの高可用性環境の設計およびデプロイ方法について説明します。
Oracle Adaptive Access Managerは、プラットフォームのプレゼンテーション層、ビジネス・ロジック層、およびデータ層を分けた、J2EEベースの複数層デプロイメント・アーキテクチャに構築されています。層がこのように分離されているため、Oracle Adaptive Access Managerは、お客様のパフォーマンス要件に合せてすばやくスケールできます。このアーキテクチャでは、Java、XML、およびオブジェクト・テクノロジを組み合せた、最も柔軟なサポートされているクロス・プラットフォームJ2EEサービスを利用できます。Oracle Adaptive Access Managerは、このアーキテクチャによって、スケーラブルでフォルト・トレラントなソリューションとなっています。
この項の内容は次のとおりです。
図9-5は、Oracle Adaptive Access Managerの単一インスタンスのアーキテクチャを示しています。
図9-5 Oracle Adaptive Access Managerの単一インスタンス・アーキテクチャ
図9-5に示すOracle Adaptive Access Managerの単一インスタンス・アーキテクチャでは、エンド・ユーザーは、カスタマWebアプリケーションにアクセスし、それがSOAPを使用してOAAM Serverアプリケーションおよびそのポリシーと通信します。かわりに、OAAMプロキシを設定して、エンド・ユーザーがそのマシンと通信し、それがHTTP(S)を使用してOAAM_Serverアプリケーションと通信することもできます。認可されたエンド・ユーザーは、カスタマWebアプリケーションにアクセスできます。OAAM_ADMINコンポーネントは、OAAM_SERVERアプリケーションの管理と構成のために使用されます。OAAM_Serverアプリケーションの管理と構成を担当する管理者は、Webブラウザを使用してOAAM_ADMINアプリケーションにアクセスします。Oracle RACデータベースにはポリシーと構成情報が格納されます。
Oracle Adaptive Access Managerは、次の2つのコンポーネントで構成されています。
OAAM_ADMIN: このコンポーネントは、OAAM_SERVERアプリケーションの管理と構成のために使用されます。このコンポーネントは、Oracle JAVA ADF FrameworkのIdentity Managementシェルを使用して開発されており、J2EEコンテナにWebアプリケーションとしてデプロイされます。これは、EARファイルとしてパッケージされています。
OAAM_SERVER: このコンポーネントは、1つのWebアプリケーション内にOAAM AdminサブコンポーネントとOAAM Serverサブコンポーネントが含まれています。OAAM_SERVERコンポーネントはEARファイルとしてパッケージ化されており、Javaクラスに加えてサーブレットとJSPで構成されています。OAAM_SERVERのサブコンポーネントについては、次にレイヤー別に説明します。
プレゼンテーション・レイヤー: 通常、JSP、サーブレットなどのサービスを提供するWebアプリケーション。プレゼンテーション・レイヤーは、厳密認証機能を提供します。これはビジネス・レイヤーによって提供されるインタフェース(SOAPまたはJavaネイティブ)を使用してそのサービスにアクセスします。
ビジネス・ロジック・レイヤー: リスク分析エンジンを実装するコア・アプリケーション・ロジックが含まれています。このレイヤーは、プレゼンテーション・レイヤーのためのJavaおよびSOAPインタフェースを提供します。Javaインタフェースを使用する場合、ビジネス・ロジック・レイヤーとプレゼンテーション・レイヤーを1つのWebアプリケーションの一部とすることができます。SOAPインタフェースの場合は、これらのレイヤーは異なるアプリケーションとしてデプロイされます。
データ・アクセス・レイヤー: サポートされているリレーショナル・データベースに接続するためのデータ・アクセス・コンポーネントが含まれています。Oracle Adaptive Access Managerは、リレーショナル・データベースにJavaオブジェクトを格納するための強力で柔軟なフレームワークを提供するOracle TopLinkを使用します。
次に示すコンポーネントも、Oracle Adaptive Access Manager 11gデプロイメントで使用できます。
Fusion Middleware ControlおよびEnterprise Manager Grid Control: Oracle Adaptive Access Managerは、Enterprise Manager Grid Controlと統合し、パフォーマンス・メトリックとデプロイメント・トポロジを表示します。Oracle Adaptive Access Managerは、DMSおよびDiscovery Mbeanを使用してEnterprise Managerと統合します。Enterprise Managerは、コンポーネント・トレースの向上と、監査の構成のためにも使用されます。
Enterprise Managerは、ドメイン内の各管理対象サーバーのログ・ファイルの表示するため、およびトレースをデバッグ・レベル、トレース・レベル、および情報レベルに高めるためにも使用できます。
データ・リポジトリ: Oracle Adaptive Access Managerは、RDBMSデータベースをそのデータ・ストアとして使用します。Oracle Adaptive Access Managerがサポートし、機能するデータベース・トポロジは、次のとおりです。
Oracle Real Application Cluster
Oracle Data Guard
レプリケーション・ストリーム
データベース・パーティション化
Oracle Adaptive Access Managerは、RCUを使用してデータベースにそのスキーマを作成します。
OAAM_Serverコンポーネントには、OAAM ServerサブコンポーネントとOAAM Adminサブコンポーネントが含まれています。
OAAM Serverは、HTTPセッションに状態を格納するステートフル・アプリケーションです。
OAAM Adminは、データベースにそのセッション情報を格納するステートフル・アプリケーションです。
OAAM_Adminコンポーネントは、ADFおよびアイデンティティ管理UIシェルベース・アプリケーションです。それは、ステートレス・アプリケーションであり、そのアプリケーションの状態は、ADFフレームワークによって保持されます。
Oracle Adaptive Access Manager管理コンソールを使用して次のランタイム・タスクを実行できます。
カスタマ・ケア・アプリケーション・タスク
ポリシー、グループ、およびプロパティを含むシステム構成タスク
セッション・データ情報の表示
システム統計ダッシュボードの表示
たとえば、次の管理フローを実行できます。
最近のユーザー問合せ:
最近のログインとセッションの詳細を表示します。
問合せを実行します。
「セッション詳細」をクリックします。
ログアウトします。
手動によるCSRとエージェント・エースの作成:
カスタマ・ケアをリセットするには、ログインします。
ケースを作成します。
カスタマをリセットします。
ログアウトします。
Oracle Adaptive Access Manager Serverを使用してランタイム処理も実行できます。
Oracle Adaptive Access Manager Serverでは、次のランタイム処理が実行されます。
Oracle Adaptive Access Managerが、デプロイされ、カスタマのアプリケーションと統合されています。
ユーザーがカスタマのアプリケーションにアクセスし、ユーザー資格証明を入力します。
OAAMで構成されたシステムとルールに基づき、次のように様々なログイン・フローがあります。
ユーザー登録: 登録フロー
フローR1: (新規ユーザーとして)ログインし、パスワードを入力してデバイスをパーソナライズし、質問登録をスキップしてログアウトします。
フローR2: ログインし、パスワードを入力し、登録をスキップしてログアウトします。
フローR3: ログインし、パスワードを入力してデバイスをパーソナライズし、質問登録を続行してログアウトします。
フローR4: ログインし、パスワードを入力してデバイスをパーソナライズし、質問登録を続行して無効なアンサーを入力し、検証してログアウトします。
フローR5: (新規デバイスに新規ユーザーとして)ログインし、パスワードを入力してデバイスをパーソナライズし、質問登録を続行してログアウトします。
ログイン・フロー:
フローL1: ログインし、誤ったパスワードを入力します(「ログイン」画面)。
フローL2: ログインし、正しいパスワードを入力し、チャレンジオンが表示される場合は正しい答えを入力し、ログインします。
フローL3: ログインし、正しいパスワードを入力し、チャレンジオンが表示され、誤った答えを入力し、チャレンジオンが再表示され、正しい答えを入力し、ログインします。
フローL4: ログインし、正しいパスワードを入力し、チャレンジオンが表示され、誤った答えを入力し、チャレンジオンが再表示され、誤った答えを入力し、チャレンジオンが再表示され、正しい答えを入力し、ログインします。
フローL5: ログインし、正しいパスワードを入力し、チャレンジオンが表示され、誤った答えを入力し、チャレンジオンが再表示され、誤った答えを入力し、ログインがブロックされます。
フローL6: ログインし、正しいパスワードを入力し、ログインがブロックされます(「ログイン」画面)。
フローL7: ログインし、正しいパスワードを入力し、ログインします。
フローLNU1: (新規ユーザーとしてログイン)ログインし、正しいパスワードを入力し、ログインします。
フローLND1: (既存のユーザー)新しいデバイスでログインし、正しいパスワードを入力し、ログインします。
フローLNUD1: (新規ユーザー)新しいデバイスでログインし、正しいパスワードを入力し、ログインします。
セッション内トランザクション・フロー: ログインし、パスワードを入力し、トランザクションを作成し、トランザクションを更新し、ログアウトします。
OAAMは、次のデータ要素を追跡し、登録します。
ユーザー・ログイン
ユーザー名
デバイス(Cookie、ブラウザ・ヘッダー、提供されたフラッシュ・データ)
IPアドレス
トランザクション・データ
OAAMは、ログイン動作に基づいて適切なポリシーをトリガーします。
Oracle Adaptive Access Manager Serverと管理コンソールは、J2EEアプリケーションとして、WebLogic Serverのユーザー・インタフェースおよびコマンドライン・ツールを使用して起動できます。
Oracle Adaptive Access Manager Serverは、障害の検出のためにロード・バランサが使用できるヘルス・チェック・リクエスト(HTTPを介したpingリクエスト)をサポートしています。
Oracle Adaptive Access Managerは、サーバー・サイド・メトリック用(DMSを使用)にインスツルメント処理されており、この情報は管理コンソールに公開されます。DMSメトリック収集が有効化されている場合、エージェントおよびサーバー・コンポーネント・メトリックの監視は、コンポーネントの監視のかわりとして使用できます。さらに、Oracle Adaptive Access Managerは、きめ細かいリアルタイム・アクティビティ・トレースをサポートしており、それもコンポーネントの監視のかわりとして使用できます。
Oracle Adaptive Access Managerは、その構成情報をデータベースに格納します。これらの構成プロパティを変更するには、Oracle Adaptive Access Manager管理コンソールを使用します。
Oracle Adaptive Access Managerは、構成情報をファイル・システムや展開したEARファイルに格納することはありません。
Oracle Adaptive Access Managerは、デプロイメント・ステージングのnostageモードをサポートします。つまり、すべてのデプロイメント・ファイルはローカルです。
Oracle Adaptive Access Managerは、RDBMSデータベースに外部依存し、それに構成情報を格納します。
Oracle Adaptive Access Managerは、Oracle RACデータベースのためにWebLogic Serverマルチ・データ・ソースを使用します。
Oracle Adaptive Access Managerは、標準Oracle TopLinkオブジェクト・キャッシュ・メカニズムを使用します。
Oracle Adaptive Access Managerは、標準セッション・オブジェクト・シリアライズを使用して、オブジェクトの永続状態を保持します。
Oracle Adaptive Access Managerは、どのようなホスト名、IPアドレス、またはポートにも依存しません。コンテナ固有のポートまたはホスト名で機能します。
Oracle Adaptive Access Managerは、WebLogic Server上にデプロイされるJ2EEアプリケーションです。すべてのログ・メッセージは、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。サーバー・ログのデフォルトの場所は次のとおりです。
WL_HOME
/user_projects/domains/domainName
/servers/serverName
/logs/serverName
-diagnostic.log
この項では、Oracle Adaptive Access Managerを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。
図9-6は、Oracle Adaptive Access Managerの高可用性アーキテクチャを示しています。
図9-6 Oracle Adaptive Access Managerの高可用性アーキテクチャ
図9-6では、受信リクエストは、ハードウェア・ロード・バランサによって受信されてから、Web層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。次に、Oracle HTTP Serverによって、WebLogicプラグインmod_wl_ohs.conf
が使用されてOAAMHOST1およびOAAMHOST2上のWebLogic管理対象サーバーにリクエストが転送されます。
OAAMHOST1とOAAMHOST2には、Oracle Adaptive Access Manager ServerアプリケーションとOracle Adaptive Access Manager Adminアプリケーションをホストする管理対象サーバーが含まれています。これらの管理対象サーバーは、アクセス・サーバーがアクティブ/アクティブ的に動作できるように、クラスタにおいて構成されます。
WebLogic管理サーバーは、OAAMHOST1上で実行され、WebLogic管理コンソールとOracle Enterprise Manager Fusion Middleware Controlを含んでいます。管理サーバーは、OAAMHOST2上でアクティブ/パッシブ・モードで実行するように構成できます。つまり、OAAMHOST1が使用不可になった場合に、管理サーバーをOAAMHOST2上で手動で起動できます。
ディレクトリ層で、仮想IP ovd.mycompany.com
は、Oracle Virtual DirectoryリクエストをOVDHOST1とOVDHOST2にルーティングするように設定されます。OVDHOST1とOVDHOST2は、アクティブ/アクティブのOracle Virtual Directoryクラスタを構成します。仮想IP oid.mycompany.com
は、Oracle Internet DirectoryリクエストをOIDHOST1とOIDHOST2にルーティングするように設定されます。OIDHOST1とOIDHOST2は、アクティブ/アクティブのOracle Internet Directoryクラスタを構成します。
Oracle RACデータベースは、データ層における高可用性を提供します。
図9-6は、OAAMの高可用性構成アーキテクチャを示しています。図では、ロード・バランサによって、WEBHOST1およびWEBHOST2上の2つのOracle HTTP Serverインスタンスを介してOAAMHOST1およびOAAMHOST2にリクエストがルーティングされます。OAAM管理サーバー・インスタンスおよびOAAM管理対象サーバー・インスタンスは、OAAMHOST1およびOAAMHOST2にインストールされ、これらのインストールは、OAAM Serverクラスタ(OAAM_Cluster)およびOAAM Adminクラスタ(OAAM_Admin_Cluster)として構成されます。OAAM ServerクラスタはOAAM Serverデータ・ソースを使用し、OAAM AdminクラスタはOAAM Adminデータ・ソースを使用して、Oracle RACデータベースと通信します。
1つのWebLogic ServerドメインでサポートされるOracle Adaptive Access Manager ServerクラスタとOracle Adaptive Access Manager Administrationクラスタはそれぞれ1つです。さらに、Oracle Adaptive Access Manager関連のクラスタは、複数のWebLogic Serverドメインにわたることはできません。
単一インスタンスのOracle Adaptive Access Managerデプロイメントは、次の高可用性要件を満たします。
ロード処理
外部接続管理と監視
リカバリ
フォルト包含
フォルト診断
Oracle Adaptive Access Manager AdminまたはServerのオフライン
複数インスタンスのOracle Adaptive Access Managerデプロイメントは、次の追加の高可用性要件を満たします。
冗長性
クライアント接続のフェイルオーバー/継続性
クライアントのロード・バランシング
状態管理
インバウンドHTTP接続の場合は、外部ロード・バランシング・ルーターの使用をお薦めします。
Webセッションは、Oracle Adaptive Access Manager管理コンソールおよびサーバーへの永続TCP接続を開きます。これには、TCP接続の早すぎる終了を回避するために、ロード・バランシング・ルーターとファイアウォール接続タイムアウトを十分大きい値にする必要があります。
各Oracle Adaptive Access Manager管理コンソールおよびサーバー・インスタンスは、他のインスタンスのピアです。すべての初期化は、サーバーがリクエストを受信できるようになる前に行われることと、組込みのスロットル機能のために、サージ状態はOracle Adaptive Access Manager 11gR1アクセス・サーバーのパフォーマンス特性に大きな影響を与えることなく正常に処理されます。
クラスタが停止した場合、新しいリクエストは拒否され、既存のリクエストはOracle Adaptive Access Manager管理コンソールおよびサーバー・アプリケーションが停止する前に完了できます。強制シャットダウンが行われた場合、Oracle Adaptive Access Manager 11gR1は、その強制シャットダウンによって破損または無効になったデータをリカバリします。
Oracle Adaptive Access Managerコンポーネントは、Pure J2EEアプリケーションであり、それ自体に起動および停止の機能はありません。かわりに、それらは、コンテナ固有の起動および停止機能に依存します。
Oracle Adaptive Access Managerコンポーネントは、WebLogic Server管理対象サーバー・ノードにデプロイされます。ノード・マネージャを使用してコンポーネントを再起動します。
Oracle Adaptive Access Managerは、構成全体をデータベースに格納するため、構成変更のすべてのクラスタ・メンバーへの伝播は透過的です。すべてのOracle Adaptive Access Managerコンポーネントは、変更イベントを内部レイヤーから通知されて取得します。変更の原子性を確保するために、Oracle Adaptive Access Managerコンポーネントには、変更が行われるたびにそれらの構成全体がリロードされます。
Oracle Adaptive Access Managerの構成は、クラスタ内のすべてのインスタンスに適用されます。
Oracle Adaptive Access Manager管理コンソールおよびサーバー・インスタンスの追加および削除は、クラスタ内の他のOracle Adaptive Access Managerインスタンスに対して透過的です。
Oracle Adaptive Access Managerクラスタには、任意の数のインスタンスを含めることができます。1つのクラスタ当たりのインスタンス数に制限はありません。
オンライン・アプリケーション・デプロイメントによって問題が発生することはありません。
次の機能が、Oracle Adaptive Access Managerの高可用性構成を障害から保護します。
クラスタのセッションの状態は、メモリー内に保持され、それは、すべてのセッションの状態情報についてレプリケーションとフェイルオーバーを提供します。
Oracle Adaptive Access Managerサーバーは、ハート・ビート・チェック(HTTPを介したpingリクエスト)をサポートしています。さらに、管理対象サーバー上のWebLogicノード・マネージャは、アプリケーションを監視し、アプリケーションが実行されていない場合は再起動することができます。Oracle Adaptive Access Managerサーバーを再起動しても、他の実行中のコンポーネントやクラスタ・メンバーには影響ありません。
WebLogic Serverノードで障害が発生した場合、外部接続のフェイルオーバーは、構成、再試行のタイムアウトおよび再試行回数に基づいて行われます。
ロード・バランシング・ルーターまたはプロキシ・サーバーがWebLogic Serverノードの障害を検出した場合、後続のクライアント接続は、アクティブ・インスタンスにルーティングされ、それはその後の処理のためにそのセッション状態を取得します。
Oracle Adaptive Access Managerセッションが、Oracle RACデータベース・ノードの障害に直接影響を与えることはありません。それは、WebLogic Serverがそのデータベース接続の状態を保持しているためです。
この項では、Oracle Adaptive Access Managerで最大限の高可用性を得るためのデプロイメントを設定する高度な手順について説明します。このデプロイメントには、2つのOracle HTTP Serverが含まれており、それらは、リクエストを2つのOAAMサーバーに配布します。これらのOAAMサーバーは、Oracle Real Application Clusters(Oracle RAC)データベースと対話します。1つのコンポーネントで障害が発生しても、残りのコンポーネントは引き続き機能します。
この項の内容は次のとおりです。
第9.3.3.4項「Oracle Adaptive Access Manager Application Tierのインストールと構成」
第9.3.3.13項「Oracle HTTP Serverと連携するためのOracle Adaptive Access Managerの構成」
第9.3.3.15項「Oracle Adaptive Access Managerトポロジのスケール・アップとスケール・アウト」
注意: Oracle Adaptive Access Managerのオフラインをインストールおよび構成するには、Oracle Adaptive Access Managerインストールおよび構成ガイドのAdaptive Access Managerのオフラインのインストールと構成に関する説明を参照してください。 |
Oracle Adaptive Access Managerを高可用性のために構成する前に、次の操作を実行しておく必要があります。
データベースにOAAMスキーマを作成するためにリポジトリ作成ユーティリティを実行します。第9.3.3.2項「データベースにOAAMスキーマを作成するためのリポジトリ作成ユーティリティの実行」を参照してください。
OAAMHOST1およびOAAMHOST2にOracle WebLogic Serverをインストールします。第9.3.3.3項「Oracle WebLogic Serverのインストール」を参照してください。
OAAMHOST1およびOAAMHOST2にOracle Identity Management実行可能ファイルをインストールし、構成します。第9.3.3.4項「Oracle Adaptive Access Manager Application Tierのインストールと構成」を参照して手順に従います。
作成するスキーマは、インストールおよび構成する製品により異なります。インストールする製品と互換性のあるバージョンのリポジトリ作成ユーティリティ(RCU)を使用します。RCUを実行するには、Oracle Fusion Middlewareインストレーション計画ガイドおよびOracle Fusion Middlewareリポジトリ作成ユーティリティ・ユーザーズ・ガイドを参照してください。
Oracle WebLogic Serverをインストールする前に、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』で指定されているように、ご使用のマシンのシステム、パッチ、カーネルの要件、およびその他の要件が満たされていることを確認します。
Oracle WebLogic ServerをOAAMHOST1およびOAAMHOST2にインストールするには、インストーラを起動後、次の手順を実行します。
「ようこそ」画面で、「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で、「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。
ORACLE_BASE/product/fmw
注意: ORACLE_BASEは、Oracle製品のインストール先であるベース・ディレクトリです。推奨値は |
「次へ」をクリックします。
セキュリティ・アップデートが通知されるようにするために、「セキュリティ更新のための登録」画面で連絡先情報を入力します。
「次へ」をクリックします。
「インストール・タイプの選択」画面で、「カスタム」を選択します。
「次へ」をクリックします。
「製品とコンポーネントの選択」画面で、「Oracle JRockit SDK」のみを選択し、「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、ディレクトリORACLE_BASE/product/fmw/wlserver_10.3
を受け入れます。
「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「Quickstartの実行」の選択を解除します。
「完了」をクリックします。
次の手順を実行して、Oracle Fusion MiddlewareコンポーネントをOAAMHOST1およびOAAMHOST2にインストールします。
Linuxプラットフォームで、/etc/oraInst.loc
ファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.loc
ファイルが存在しない場合、この手順をスキップできます。
次のようにOracle Fusion Middlewareのインストーラを起動します。
OAAMHOST1> runInstaller
インストーラで、JRE/JDKの場所を入力するように求められたら、WebLogic Serverのインストールで作成したOracle SDKの場所を入力し(例: ORACLE_BASE/product/fmw/jrockit_160_
<バージョン>)、次の手順を実行します。
「ようこそ」画面で、「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を入力します。
Oracle Middlewareホーム: MW_HOME
のリストから前にインストールしたMiddlewareホームを選択します。次に例を示します。
/u01/app/oracle/product/fmw
Oracleホーム・ディレクトリ:
IDM_ORACLE_HOME
にOracle Identity Management Suiteをインストールするときは、Oracleホーム・ディレクトリ名としてidm
を入力します。
IAM_ORACLE_HOME
にOracle Identity and Access Management Suiteをインストールするときは、Oracleホーム・ディレクトリ名としてiam
を入力します。SOA_ORACLE_HOME
にOracle SOA Suiteをインストールするときは、Oracleホーム・ディレクトリ名としてsoa
を入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストールと構成」をクリックします。
「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」画面で、次を選択します。
「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。
次の製品を選択します。
Oracle Enterprise Manager
Oracle JRF(デフォルトで選択)
Oracle Adaptive Access Manager - サーバー
Oracle Adaptive Access Manager管理サーバー
「次へ」をクリックします。
「ドメイン名と場所の指定」画面で、次を入力します。
ドメイン名: IDM_Domain
ドメイン・ディレクトリ: デフォルトを受け入れます。
アプリケーション・ディレクトリ: デフォルトを受け入れます。
「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。
WebLogicドメインの起動モード: 「本番モード」を選択します。
JDKの選択: 「JROCKIT SDK1.6.0_<バージョン>」を選択します。
「JDBCコンポーネント・スキーマの構成」画面で、すべてのデータ・ソースを選択し、「次のパネルで選択したデータ・ソースをRACマルチ・データ・ソースとして構成します。」を選択します。
「次へ」をクリックします。
「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、最初のデータ・ソースであるOAAM Admin Serverを選択し、次の項目を入力します。
データ・ソース: OAAM Admin Server
サービス名: oaam.mycompany.com
ユーザー名: OAAM_OAAM(OAAMがRCU接頭辞として使用されていたと想定)
パスワード: 前述のアカウント用のパスワード
右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。
ホスト名: OAAMDBHOST1
インスタンス名: oaamdb1
ポート: 1521
再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。
ホスト名: OAAMDBHOST2
インスタンス名: oaamdb2
ポート: 1521
このデータ・ソースの選択を解除します。次のデータ・ソースであるOAAM Admin MDSスキーマを選択し、次の情報を入力します。
データ・ソース: OAAM Admin MDSスキーマ
サービス名: oaam.mycompany.com
ユーザー名: OAAM_MDS(OAAMがRCU接頭辞として使用されていたと想定)
パスワード: OAAM_MDSアカウント用パスワードです。
右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。
ホスト名: OAAMDBHOST1
インスタンス名: oaamdb1
ポート: 1521
再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。
ホスト名: OAAMDBHOST2
インスタンス名: oaamdb2
ポート: 1521
このデータ・ソースの選択を解除します。次のデータ・ソースであるOAAM Serverを選択し、次の情報を入力します。
データ・ソース: OAAM Server
サービス名: oaam.mycompany.com
ユーザー名: OAAM_OAAM(OAAMがRCU接頭辞として使用されていたと想定)
パスワード: OAAM_OAAMアカウント用パスワードです。
右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。
ホスト名: OAAMDBHOST1
インスタンス名: oaamdb1
ポート: 1521
再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。
ホスト名: OAAMDBHOST2
インスタンス名: oaamdb2
ポート: 1521
このデータ・ソースの選択を解除します。次のデータ・ソースであるOWSM MDSスキーマを選択し、次の情報を入力します。
データ・ソース: OWSM MDSスキーマ
サービス名: oaam.mycompany.com
ユーザー名: OAAM_MDS(OAAMがRCU接頭辞として使用されていたと想定)
パスワード: OAAM_MDSアカウント用パスワードです。
右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。
ホスト名: INFRADBHOST1
インスタンス名: oaamdb1
ポート: 1521
再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。
ホスト名: INFRADBHOST2
インスタンス名: oaamdb2
ポート: 1521
このデータ・ソースの選択を解除します。
「次へ」をクリックします。
「コンポーネント・スキーマのテスト」画面で、データ・ソースの検証が試行されます。
データ・ソースの検証が成功した場合、「次へ」をクリックします。
失敗した場合は、「前へ」をクリックし、問題を修正して、やり直します。
「オプションの構成を選択」画面で、次を選択します。
管理サーバー
管理対象サーバー、クラスタ、およびマシン
「次へ」をクリックします。
「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: 管理サーバーの仮想ホスト名を入力します(例: OAAMHOST1.mycompany.com)。
リスニング・ポート: 7001
SSLリスニング・ポート: 適用なし
SSL有効: 選択を解除
「次へ」をクリックします。
「管理対象サーバーの構成」画面で、トポロジのOAAMHOSTごとに2つのエントリを作成します。つまり、OAAM Serverに対して1つと、OAAM Admin Serverに対して1つ作成します。
OAAM_SERVERエントリを選択し、そのエントリを次の値に変更します。
名前: WLS_OAAM1
リスニング・アドレス: OAAMHOST1.mycompany.com
リスニング・ポート: 14300
SSLリスニング・ポート: 14301
SSL有効: 選択
2つ目のOAAM_SERVERに対して、「追加」をクリックし、次の情報を入力します。
名前: WLS_OAAM2
リスニング・アドレス: OAAMHOST2.mycompany.com
リスニング・ポート: 14300
SSLリスニング・ポート: 14301
SSL有効: 選択
OAAM_ADMIN_SERVERエントリを選択し、そのエントリを次の値に変更します。
名前: WLS_OAAM_ADMIN1
リスニング・アドレス: OAAMHOST1.mycompany.com
リスニング・ポート: 14200
SSLリスニング・ポート: 14201
SSL有効: 選択
2つ目のOAAM_ADMIN_SERVERに対して、「追加」をクリックし、次の情報を入力します。
名前: WLS_OAAM_ADMIN2
リスニング・アドレス: OAAMHOST2.mycompany.com
リスニング・ポート: 14200
SSLリスニング・ポート: 14201
SSL有効: 選択
その他すべてのフィールドはデフォルトの設定のままにします。
「次へ」をクリックします。
「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成します。
名前としてOAAM_Clusterを入力します。
「追加」をクリックして2番目のクラスタを作成します。
名前としてOAAM_Admin_Clusterを入力します。
その他すべてのフィールドはデフォルトの設定のままにします。
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、次のように管理対象サーバーをクラスタに関連付けます。
右のウィンドウでクラスタ名OAAM_Clusterをクリックします。
管理対象サーバーWLS_OAAM1をクリックし、矢印をクリックしてそれをクラスタに割り当てます。
管理対象サーバーWLS_OAAM2に対しても同様に繰り返します。
続いて、次のように操作します。
右のウィンドウでクラスタ名OAAM_Admin_Clusterをクリックします。
管理対象サーバーWLS_OAAM_ADMIN1をクリックし、矢印をクリックしてそれをクラスタに割り当てます。
管理対象サーバーWLS_OAAM_ADMIN2に対しても同様に繰り返します。
「次へ」をクリックします。
「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。ホストでUNIXベースのオペレーティング・システムを使用する場合は、「Unix」タブをクリックします。それ以外の場合は、「マシン」タブをクリックします。次の情報を指定します。
名前: ホスト名です。ベスト・プラクティスは、DNS名(OAAMHOST1)を使用することです。
ノード・マネージャ・リスニング・アドレス: マシンのDNS名(OAAMHOST1.mycompany.com)
ノード・マネージャ・ポート: ノード・マネージャが使用するポート。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを指定します。
OAAMHOST1について、次のように操作します。
右のウィンドウでマシンOAAMHOST1をクリックします。
左のウィンドウで管理対象サーバーWLS_OAAM1をクリックします。
矢印をクリックし、その管理対象サーバーをホストOAAMHOST1に割り当てます。
左のウィンドウで管理対象サーバーWLS_OAAM_ADMIN1をクリックします。
矢印をクリックし、その管理対象サーバーをホストOAAMHOST1に割り当てます。
OAAMHOST2について、次のように操作します。
右のウィンドウでマシンOAAMHOST2をクリックします。
左のウィンドウで管理対象サーバーWLS_OAAM2をクリックします。
矢印をクリックし、その管理対象サーバーをホストOAAMHOST2に割り当てます。
左のウィンドウで管理対象サーバーWLS_OAAM_ADMIN2をクリックします。
矢印をクリックし、その管理対象サーバーをホストOAAMHOST2に割り当てます。
「次へ」をクリックします。
「構成のサマリー」画面で、「作成」をクリックし、作成プロセスを開始します。
ドメインの構成後、管理サーバーを起動する前に、データベース・セキュリティ・ストアを構成する必要があります。詳細は、第9.1.3.3項「ドメイン用のデータベース・セキュリティ・ストアの構成」を参照してください。
この項では、OAAMHOST1上の管理サーバーに対してboot.properties
ファイルを作成する方法について説明します。boot.properties
ファイルを使用すると、administrator
のユーザー名とパスワードの入力を求められることなく管理サーバーを起動できます。
boot.properties
ファイルを作成する手順は次のとおりです。
管理サーバーを起動します。
OAAMHOST1で、次のディレクトリに移動します。
MW_HOME
/user_projects/domains/domainName
/servers/AdminServer/security
例:
cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security
テキスト・エディタを使用して、boot.properties
という名前のファイルをsecurity
ディレクトリの下に作成します。次の行をファイルに入力します。
username=adminUser
password=adminUserPassword
注意: 管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。 セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。 |
管理サーバーが実行されている場合は停止します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。
MW_HOME
/user_projects/domains/
domainName
/bin
ディレクトリにあるstartWebLogic.shスクリプトを使用して、OAAMHOST1上の管理サーバーを起動します。
Webブラウザを開いて次のページにアクセスし、変更が正常に行われたことを確認します。
WebLogic Server管理コンソール:
http://oaamhost1.mycompany.com:7001/console
Oracle Enterprise Manager Fusion Middleware Control:
http://oaamhost1.mycompany.com:7001/em
weblogic
ユーザーの資格証明を使用して、これらのコンソールにログインします。
OAAMコンソールへのアクセスに使用する管理ユーザーを作成します。そのためには、次の手順を実行してください。
次のURLを使用して、WebLogic管理コンソールにログインします。
http://oaamhost1.mycompany.com:7001/console
「ドメイン構造」メニューで、「セキュリティ・レルム」→「myrealm」を選択します。
「ユーザーとグループ」タブをクリックします。
「ユーザー」サブタブをクリックします。
新規をクリックします。
次の値を入力します。
名前: ユーザーの名前。例: oaam_admin
プロバイダ: デフォルト認証システム
パスワード/確認: ユーザーのパスワード
「OK」をクリックします。
ユーザーを作成したら、そのユーザー名をクリックします。
「グループ」サブタブをクリックします。
ユーザーを次のグループに割り当てます。
OAAMCSRGroup
OAAMCSRManagerGroup
OAAMInvestigatorGroup
OAAMInvestigationManagerGroup
OAAMRuleAdministratorGroup
OAAMEnvAdminGroup
OAAMSOAPServicesGroup
「保存」をクリックします。
この項では、OAAMHOST1の起動手順について説明します。
コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/bin
ディレクトリにあるsetNMProps.sh
スクリプトを実行することによって行います。例:
OAAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh
次のコマンドを発行してノード・マネージャを起動します。
OAAMHOST1> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh
OAAMHOST1上のOracle Adaptive Access Managerを起動する手順は、次のとおりです。
次のURLを使用して、WebLogic管理コンソールにログインします。
http://oaamhost1.mycompany.com:7001/console
WebLogic管理者のユーザー名とパスワードを指定します。
「ドメイン構造」メニューで「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
サーバーWLS_OAAM1およびWLS_OAAM_ADMIN1をクリックします。
「起動」をクリックします。
「OK」をクリックし、サーバーを起動することを確認します。
次のURLにあるOAAM管理サーバーに接続することによって実装を検証します。
http://OAAMHOST1.mycompany.com:14200/oaam_admin
OAAM管理コンソールのログイン・ページが表示され、第9.3.3.7項「Oracle Adaptive Access Manager管理ユーザーの作成」で作成したoaamadmin
アカウントを使用してログインできる場合、実装は有効です。
次の場所にあるOAAMサーバーに接続することによって実装を検証します:
http://OAAMHOST1.mycompany.com:14300/oaam_server
OAAMサーバーのログイン・ページが表示されると、実装は有効です。
OAAMHOST1で構成を完了したら、それをOAAMHOST2に伝播できます。これを実行するには、OAAMHOST1でpack
スクリプトを使用してドメインをパックし、OAAMHOST2でunpack
スクリプトを使用してドメインを解凍します。
スクリプトは両方とも、MW_HOME/oracle_common/common/bin
ディレクトリにあります。
OAAMHOST1で、次のように入力します。
pack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
-template=/tmp/idm_domain.jar -template_name="OAAM Domain" -managed=true
これにより、/tmp
ディレクトリにidm_domain.jar
というファイルが作成されます。このファイルをOAAMHOST2にコピーします。
OAAMHOST2で、次のように入力します。
unpack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
-template=/tmp/idm_domain.jar
OAAMHOST2を起動します。
この項では、OAAMHOST2の起動手順について説明します。
コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/bin
ディレクトリにあるsetNMProps.sh
スクリプトを実行することによって行います。例:
OAAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh
次のコマンドを発行してノード・マネージャを起動します。
OAAMHOST2> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh
OAAMHOST2上のOracle Adaptive Access Managerを起動する手順は、次のとおりです。
次のURLを使用して、WebLogic管理コンソールにログインします。
http://oaamhost2.mycompany.com:7001/console
WebLogic管理者のユーザー名とパスワードを指定します。
「ドメイン構造」メニューで「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
サーバーWLS_OAAM2およびWLS_OAAM_ADMIN2をクリックします。
「起動」をクリックします。
「OK」をクリックし、サーバーを起動することを確認します。
次のURLにあるOAAM管理サーバーに接続することによって実装を検証します。
http://OAAMHOST2.mycompany.com:14200/oaam_admin
OAAM管理コンソールのログイン・ページが表示され、第9.3.3.7項「Oracle Adaptive Access Manager管理ユーザーの作成」で作成したoaamadminアカウントを使用してログインできる場合、実装は有効です。
次の場所にあるOAAMサーバーに接続することによって実装を検証します:
http://OAAMHOST2.mycompany.com:14300/oaam_server
OAAMサーバーのログイン・ページが表示されると、実装は有効です。
この項では、Oracle HTTP Serverと連携するためのOracle Adaptive Access Managerの構成手順について説明します。
WEBHOST1およびWEBHOST2で、次のディレクトリにoaam.conf
というファイルを作成します。
ORACLE_INSTANCE/config/OHS/ohs1/moduleconf
次の行を指定してファイルを作成します。
NameVirtualHost *:7777 <VirtualHost *:7777> ServerName oaam.mycompany.com:7777 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit <Location /oaam_server> SetHandler weblogic-handler WebLogicCluster oaamhost1.mycompany.com:14300,oaamhost2.mycompany.com:14300 </Location> <Location /oaam_admin> SetHandler weblogic-handler WebLogicCluster oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200 WebLogicPort 7001 </Location> </VirtualHost>
WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。
WEBHOST1>opmnctl stopall WEBHOST1>opmnctl startall WEBHOST2>opmnctl stopall WEBHOST2>opmnctl startall
Oracle HTTP Serverは、WebLogicのプロキシとして機能するため、デフォルトでは、特定のCGI環境変数はWebLogicに渡されません。これらには、ホストとポートが含まれます。WebLogicには、内部URLを適切に生成できるように仮想サイト名およびポートを使用していることを指示する必要があります。
そのためには、次のWebLogic管理コンソールにログインします。
http://oaamhost1.mycompany.com:7001/console
次の手順を実行します。
ホーム・ページから「クラスタ」を選択するか、「ドメイン構造」メニューから「環境」→「クラスタ」を選択します。
「チェンジ・センター」ウィンドウで「ロックして編集」をクリックし、編集可能にします。
クラスタ名(oaam_cluster)をクリックします。
「一般」タブで、「拡張プロパティ」セクションのボックスを選択して、WebLogicプラグインを「有効」に設定します。
「保存」をクリックします。
「HTTP」を選択して、次の値を入力します。
フロントエンド・ホスト: oaam.mycompany.com
フロントエンドHTTPポート: 7777
フロントエンドHTTPSポート: SSL通信を使用している場合は、ロード・バランサ上のSSLポートまたはOracle HTTP Server SSLポートに設定します。
これにより、WebLogic内で作成されたHTTPS URLはすべて、ロード・バランサ上のポート443または80に送られます。
「保存」をクリックします。
ホーム・ページから「クラスタ」を選択するか、「ドメイン構造」メニューから「環境」→「クラスタ」を選択します。
クラスタ名(oaam_admin_cluster)をクリックします。
「一般」タブで、「拡張プロパティ」セクションのボックスを選択して、WebLogicプラグインを「有効」に設定します。
「保存」をクリックします。
「HTTP」を選択して、次の値を入力します。
フロントエンド・ホスト: oaam.mycompany.com
フロントエンドHTTPポート: 7777
フロントエンドHTTPSポート: SSL通信を使用している場合は、ロード・バランサ上のSSLポートまたはOracle HTTP Server SSLポートに設定します。
「保存」をクリックします。
「チェンジ・センター」ウィンドウで「変更のアクティブ化」をクリックし、変更を保存します。
管理対象サーバーWLS_OAAM1、WLS_OAAM2、WLS_OAAM_ADMIN1、およびWLS_OAAM_ADMIN2を次のようにして再起動します。
次のURLを使用して、WebLogic管理コンソールにログインします。
http://oaamhost1.mycompany.com:7001/console
WebLogic管理者のユーザー名とパスワードを指定します。
「ドメイン構造」メニューで「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
サーバーWLS_OAAM1、WLS_OAAM2、WLS_OAAM_ADMIN1およびWLS_OAAM_ADMIN2をクリックします。
「停止 - ただちに強制停止」を選択します。
「はい」をクリックし、サーバーを停止することを確認します。
「ドメイン構造」メニューで「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
サーバーWLS_OAAM1、WLS_OAAM2、WLS_OAAM_ADMIN1およびWLS_OAAM_ADMIN2をクリックします。
「起動」をクリックします。
「はい」をクリックし、サーバーを起動することを確認します。
管理サーバーを再起動します。
Oracle Adaptive Access Manager管理コンソール(http://oaam.mycompany.com:7777/oaam_admin
)に、作成したoaamadmin
アカウントを使用してログインします。
Oracle Adaptive Access Managerサーバー(http://oaam.mycompany.com:7777/oaam_server
)に、作成したoaamadmin
アカウントおよびパスワード・テストを使用してログインします。
この項では、Oracle Adaptive Access Managerの高可用性トポロジをスケール・アップおよびスケール・アウトする方法について説明します。すでに1つ以上のサーバー・インスタンスが実行されているノードに、新しいOracle Adaptive Access Manager管理対象サーバー・インスタンスを追加するには、スケール・アップ操作を実行します。新しいノードに、新しいOracle Adaptive Access Manager管理対象サーバー・インスタンスを追加するには、スケール・アウト操作を実行します。
OAAMをスケール・アップするには、OAAMサーバーとOAAM管理サーバーの両方について同じ手順を実行します。
Oracle WebLogic Serverコンソール(http://oaamhost1.mycompany.com:7001/console
)にログインします。次のように実行します。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノード→「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「ロックして編集」を「チェンジ・センター」メニューでクリックします。
拡張するホスト上の既存サーバーを選択します(例: WLS_OAAM1
やWLS_OAAM_ADMIN1
)。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前です(例: WLS_OAAM3
)。
サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。
「OK」をクリックします。
新規作成サーバーの「WLS_OAAM3」をクリックします。
SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAAM3
管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。OAAMHOST
n
のノード・マネージャとOracle WebLogic管理サーバーとの間における通信用のサーバー証明書を構成した後で、これを再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。
Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「環境」ノードを「ドメイン構造」ペインで開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_OAAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし
」に設定します。
「保存」をクリックします。
構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
スケール・アウトはスケール・アップとよく似ていますが、最初に新しいノードにソフトウェアをインストールする必要がある点が異なります。次の手順を実行します。
第9.3.3.3項「Oracle WebLogic Serverのインストール」の手順に従い、新しいホストにOracle WebLogic Serverをインストールします。
新しいホストにOracle Fusion Middleware Identity Managementコンポーネントをインストールします。第9.3.3.4項「Oracle Adaptive Access Manager Application Tierのインストールと構成」を参照してください。
WebLogicコンソール(http://oaamhost1.mycompany.com:7001/console
)にログインします。
管理コンソールの「ドメイン構造」ペインで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「ロックして編集」を「チェンジ・センター」メニューでクリックします。
拡張するホスト上の既存サーバーを選択します(例: WLS_OAAM1
やWLS_OAAM_ADMIN1
)。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前です(例: WLS_OAAM3
)。
サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。
「OK」をクリックします。
新規作成サーバーの「WLS_OAAM3」をクリックします。
SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAAM3
管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。OAAMHOST
n
のノード・マネージャとOracle WebLogic管理サーバーとの間における通信用のサーバー証明書を構成した後で、これを再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。
Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「環境」ノードを「ドメイン構造」ペインで開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_OAAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし
」に設定します。
「保存」をクリックします。
構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
次のコマンドを使用してOAAMHOST1
上のドメインをパックします。
pack.sh -domain=ORACLE_BASE/admin/IDM_Domain/aserver/IDM_Domain -template =/tmp/idm_domain.jar -template_name="OAAM Domain" -managed=true
pack.sh
スクリプトは、MW_HOME
/oracle_common/common/bin
にあります。
次のコマンドを使用して新しいホスト上でドメインを解凍します。
unpack.sh -domain=ORACLE_BASE/admin/IDM_Domain/mserver/IDM_Domain -template=/tmp/idm_domain.jar -template_name="OAAM Domain" -app_dir=ORACLE_BASE/admin/IDM_Domain/mserver/applications
unpack.sh
スクリプトは、MW_HOME
/oracle_common/common/bin
にあります。
コンソールから管理対象サーバーを起動する前に、スクリプトsetNMProps.sh
を実行してOAAMHOST2
上にノード・マネージャのプロパティ・ファイルを作成しておく必要があります。setNMProps.sh
スクリプトは、MW_HOME
/oracle_common/common/bin
にあります。次のように入力します。
OAAMHOST2> $MW_HOME/oracle_common/common/bin/setNMProps.sh
新しいホストでノード・マネージャと新しい管理対象サーバーを起動します。
これで、新しい管理対象サーバーが作成されて起動され、Web層はリクエストをその管理対象サーバーに転送するようになります。ただし、ベスト・プラクティスは、新しい管理対象サーバーが作成されたことをWebサーバーに通知することです。
このためには、各Web層のoaam.conf
ファイルを更新します。このファイルは、ORACLE_INSTANCE
/config/OHS/
component_name
/moduleconf
ディレクトリにあります。
新しいサーバーをこのファイル内のWebLogicCluster
ディレクティブに追加します。次に例を示します。
<Location /oaam_admin> SetHandler weblogic-handler WebLogicCluster oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200 </Location>
前述の行を次のように変更します。
<Location /oaam_admin> SetHandler weblogic-handler WebLogicCluster oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200,oaamhost3.mycompany.com:14300 </Location>
この項では、Oracle Access Management Security Token Serviceの高可用性について説明します。
Security Token Serviceは、共有Webサービス(JAX-WS)であり、様々なIdentityドメインとインフラストラクチャ層との間での信頼を仲介する機能が統合された標準ベースのメカニズムを提供します。Security Token Serviceは、Webサービス・コンシューマ(WSC)とWebサービス・プロバイダ(WSP)との間での信頼を仲介し、プロバイダとコンシューマに対してセキュリティ・トークンのライフサイクル管理サービスを提供します。Security Token Serviceでは、標準化されたインタフェースのセットを使用することで、各種のシステム間を橋渡しするために必要な作業を単純化できます。
Security Token Serviceの高可用性デプロイメントは、Oracle Access Management Access Managerに依存します。Access Managerアプリケーションには、Oracle Security Token Serviceのサーバー・ランタイムが含まれています。Security Token Serviceの高可用性デプロイメントは、Access Managerがなければ成り立ちません。Access ManagerとSecurity Token Serviceは、どちらもOAM J2EEアプリケーションEARファイルに同梱されていて、WebLogicドメイン内の同じ管理対象サーバーにまとめてインストールされ、デプロイされます。さらに、Security Token Serviceは、Oracle Access Managementコンソールに統合されます。
Security Token Serviceの管理と構成の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の次のいずれかの項目をを参照してください。
Security Token Serviceの主な用語と概要
Security Token Serviceについて
Security Token Serviceのデプロイメントについて
Security Token Serviceの管理について
Security Token Serviceの実装シナリオ
Security Token Serviceの設定値と設定の管理
Security Token Serviceの証明書と鍵の管理
テンプレート、エンドポイントおよびポリシーの管理
Token Serviceパートナとパートナ・プロファイルの管理
パッチの適用については、Oracle Access Managerの管理の第11.1.1.3.0項から第11.1.1.6.0項を参照してください。
この項の内容は次のとおりです。
次の図は、高可用性アーキテクチャのSecurity Token Serviceを示しています。
この図は、Access ManagerとSecurity Token Serviceコンポーネントの2ノード・デプロイメントを示しています。この項では、Security Token Serviceの高可用性デプロイメントについて詳しく説明します。これの一部としてデプロイされるAccess Managerの全体的な高可用性アーキテクチャについては、第9.2.2.1項「Access Managerの高可用性アーキテクチャ」を参照してください。
Security Token Serviceは、WS-Trustプロトコルのサポートを実装するサーバー側コンポーネントです。
ロード・バランサはトークン・リクエストを受信すると、そのリクエストをSecurity Token Service(STS)にルーティングします。
RACデータベースは、Access ManagerによってCoherenceバックエンド・ストアとして使用されるデータベースと同じです。
Oracle Access Managementコンソールは、Security Token Serviceデプロイメントを管理するためのサービスを提供するJ2EEアプリケーションです。OAMデプロイメントの一部として、管理コンソールをWeblogic管理サーバーにデプロイする必要があります。
Security Token Serviceの場合、各WebLogic Serverドメインで1つのSecurity Token Serviceクラスタがサポートされます。OAMとSecurity Token Serviceのクラスタは、WebLogic Serverドメイン間にまたがることはできません。
Security Token Serviceは、主にOASIS WS-Trustプロトコルを基盤とします。ただし、Security Token Serviceは、SOAPメッセージに含まれるその他のWS-*プロトコルの処理を、JAX-WSスタックに委任します。
HTTP/SOAPのインバウンド接続には、外部ロード・バランサを使用することをお薦めします。LDAPに対するアウトバウンド外部接続は、接続フェイルオーバーのサポートとともにロード・バランシングされます。
WS-Trustプロトコルを実装するWebサービス・クライアントは、トークンの発行および検証のために、Security Token Serviceと対話します。STSサーバーと対話するように設計されたクライアント(OWSMクライアントなど)は、リライイング・パーティへのWebサービス・コールの一環として、Security Token Serviceを呼び出すことができます。
このクライアント接続は、次のように処理されます。
Webサービス・クライアントは、httpまたはhttpsによってSOAPメッセージを送信します。
WSSプロトコルによって、メッセージを保護します。ペイロードには、実行する操作、発行または検証するトークンの種類、およびトークンの特性についての追加情報を示すWS-Trustリクエスト(RST)が格納されます。
サーバーはリクエストを処理して、そのリクエストをサーバーが受信したチャネルと同じチャネルでレスポンスを送信します。
WSSプロトコルによって、メッセージを保護します。処理が成功したときには、ペイロードにWS-Trustレスポンス(RSTRC)が格納されます。エラーが発生したときには、SOAP障害が格納されます。
Security Token Serviceアクセス・サーバーの各インスタンスは、他のインスタンスのピアになりますがインスタンス間の通信はありません。サーバーがリクエストを受信できるようになる前に、すべての初期化が組込のスロット機能と同時に行われるため、WebLogic ServerはSecurity Token Serviceアクセス・サーバーのパフォーマンス特性に大きな影響を与えることなく急増する条件を適切に処理します。
クラスタが停止すると、Security Token Serviceは新しいリクエストを拒否し、アクセス・サーバーのアプリケーションが停止する前に既存のリクエストを完了できるようにします。強制停止が行われた場合、Security Token Serviceはその強制停止によって破損または無効になったデータをリカバリできます。
構成の変更は、Coherence分散オブジェクト・キャッシュを利用する分散メカニズムに基づいて、すべてのクラスタ・メンバー伝播されます。Coherenceレイヤーは、すべてのSecurity Token Serviceコンポーネントに変更イベントを通知します。その後、このコンポーネントはそれらの変更を取り込みます。Access Managerコンポーネントには、変更が行われるたびにそれらの構成全体がリロードされます。
注意: アクセス・サーバーのインスタンスの追加または削除は、クラスタ内の他のSecurity Token Serviceインスタンスに対して透過的になります。特定のSecurity Token Serviceサーバーの削除が、ロードに影響しないことを確認してください。 |
この項では、Security Token Serviceコンポーネントの特性と、次の項目について説明します。
起動時に、Access ManagerとSecurity Token Service Serverは、バックエンド・リポジトリへの接続を初期化します。このリポジトリにアクセスできない場合、Access ManagerとSecurity Token Serviceサーバーは、指数関数的に増加するタイムアウトを使用してリポジトリへの接続を再試行します(このタイムアウトは上限を構成できます)。
Access ManagerとSecurity Token Service Serverは、バックエンドの接続が停止したときには、ローカルにキャッシュしたデータに基づいてサービスの持続性を提供します。サービスは、キャッシュの有効性が失われるか、バックエンドの接続が回復するまで持続されます。
次の図は、Security Token Serviceのランタイム・プロセスを示しています。
Security Token Serviceのランタイム・プロセスは、次の説明のように動作します。
Webサービス・コンシューマ(WSC)は、WSPが要求するセキュリティ・トークのタイプについてのWeb Services-Trust(WS-Trust)Request Security Token(RST)メッセージを送信します。クライアントの認証は、トランスポート・レイヤーの認証を使用するか、WSSトークンをRSTメッセージにバインドすることで行われます。
Security Token Service(STS)はRSTメッセージを検証し、リクエストを認証してから、要求された操作の権限を付与します。
RSTメッセージによって指定されたメタデータに応じて、適切なセキュリティ・トークンが生成されます。ポリシー主導型の交換ユースケースでは、STSが適切なトークン生成ポリシーを検索し、該当するセキュリティ・トークンを生成します。
STSは、生成されたセキュリティ・トークンを格納するRSTメッセージを生成し、このメッセージをレスポンスとしてWSCに送信します。
注意: WSPによるセキュリティ・トークンの検証は、トークンのタイプに応じて異なります。STSが信頼の仲介者としてのみ機能する場合は、Kerberosなどの基幹セキュリティ・インフラストラクチャに対する検証が実行されます。 |
アクセス・サーバー(Security Token Serviceのデプロイ先)と管理コンソールは、どちらもJ2EEアプリケーションであるため、アプリケーション・サーバーが提供するユーザー・インタフェースやコマンドライン・ツールから起動できます。
J2EEのコンポーネントとサブコンポーネントには、次のものがあります。
STS: イベント・ベースのデザイン・パターンであり、Security Token Service 11g-PS1の中核部分を実装します。WARアプリケーションとしてAccess Manager EARファイルにパッケージ化されています。WSプロバイダ・サーブレットとJavaクラスが含まれています。STS Webアプリケーションは、/stsルート・パスにバインドされます。
管理コンソール: ADF/IDMシェルに基づくスタンドアロン・コンソールであり、.EARファイルとしてパッケージ化されています。
JMX Mbeans: アクセス・サーバー・パッケージにパッケージ化されています。コンフィグMbeanは、スタンドアロンのJARファイルとしてパッケージ化されています。
WSLTコマンド: Access Manager/Security Token Serviceパッケージに含まれているJavaクラスで構成されています。
OWSMエージェント: WSSプロトコルのサポートを提供するWebサービスのインターセプタです。JRFに含まれます。
ORAProvider: JRF Webサービス・プロバイダです。
Security Token Serviceは、ステートレスのJ2EEアプリケーションですが、ユーザー名トークン用のNonceキャッシュがあり、Security Token Serviceはリプレイ攻撃を防止するために、Nonceが存在する場合は、提示されたユーザー名トークンを記録します。
Access ManagerとSecurity Token Serviceは一組になるように構築され、構成やロギングなどのプロセスに同一のモジュールを使用します。Security Token Serviceの構成アーティファクトには、次のファイルが含まれます。
DOMAIN_HOME/config/fmwconfig/oam-config.xml — インスタンス固有の情報を格納する構成ファイルです。
DOMAIN_HOME/config/fmwconfig/oam-policy.xml — OES Micro SMが使用されていない場合にのみ存在します。
DOMAIN_HOME/config/fmwconfig/servers/instanceName/logging.xml — ロギング構成です。
DOMAIN_HOME/config/fmwconfig/cwallet.sso — アイデンティティ・ストア、データベースおよびその他のエンティティへの接続に使用するパスワードを格納します。これは、エンド・ユーザー用のパスワードではありません。
DOMAIN_HOME/config/fmwconfig/.oamkeystore — Access Manager/Security Token Serviceが所有する鍵と証明書を格納するキーストアです。
DOMAIN_HOME/config/fmwconfig/amtruststore — X509証明書の検証に使用されるトラスト・アンカーを格納するキーストアです。
DOMAIN_HOME/config/fmwconfig/amcrl.jar — 証明書失効に使用するCRLを格納するzipファイルです。
DOMAIN_HOME/config/fmwconfig/default-keystore.jks — OWSMエージェントが使用する鍵と証明書を格納するOWSMキーストアです。また、WSS操作のためのX.509証明書の検証に使用されるトラステッド・アンカーも格納されます。
DOMAIN_HOME/config/fmwconfig/.cohstore.jks - Coherence SSL通信で使用されるトラスト・ストアです。
Security Token Serviceは、次の項目に対して外部依存性があります。
LDAPベースのアイデンティティ・ストア
ユーザー・アイデンティティ・リポジトリ
ユーザー/ロールAPIによって抽象化されるLDAPアクセス
注意: Access Managerは、常に1つのアイデンティティ・ストアに接続しますが、そのアイデンティティ・ストアは物理サーバーまたはロード・バランサIPです。プライマリが停止した場合、Access Managerはロード・バランサに再接続し、ロード・バランサによってセカンダリに接続します。 |
OCSPレスポンダ・サービス
リアルタイムX.509認証検証
RDBMSポリシー・ストア/Coherenceストア
ポリシー(認証および認可)リポジトリ
OAMポリシー・エンジンによって抽象化されるRDBMSアクセス
OPSSセキュリティ・ストア
Security Token Serviceの高可用性は、Access Managerの一部として構成されます。Security Token Serviceシステムのすべての構成は、Oracle Access Managementコンソールを使用して実行します。詳細は、第9.2.3項「Access Managerの高可用性の構成手順」を参照してください。
個別のSecurity Token Serviceサーバー上のSecurity Token Serviceのエンドポイントが稼働状態であり実行中であることを検証できます。これを実行するには、Security Token ServiceのエンドポイントのWSDLドキュメント(http(s)://[hostname:port]/sts/[ENDPOINT]/WSDL)に直接アクセスします。
[ENDPOINT]の部分は、既存の公開エンドポイントに置換してください。
この項では、高可用性環境におけるSecurity Token Serviceのフェイルオーバーの特性について説明します。
Access Manager Access Serverは、ハートビート・チェック(HTTPによるPingリクエスト)をサポートしています。さらに、管理対象サーバー上のWebLogicノード・マネージャは、アプリケーションを監視して、そのアプリケーションを必要に応じて再起動できます。
WebLogic Serverノードに障害が発生すると、構成、再試行のタイムアウトおよび再試行の回数に基づいて外部接続のフェイルオーバーが行われます。Access Managerエージェントとアクセス・サーバーのフェイルオーバーはタイムアウトに基づいています。
ロード・バランシング・ルーターまたはプロキシ・サーバーがWebLogic Serverノードの障害を検出すると、後続のクライアント接続はアクティブなインスタンスにルーティングされます。このインスタンスは、セッション状態をCoherence分散オブジェクト・キャッシュから取得して処理を継続します。
フロント・チャネルHTTPバインディングでは、フェイルオーバーのためにロード・バランシング・ルーターが使用されます。
別のサービスから例外を受信した場合、Access Managerは、外部接続リクエストを再試行します。再試行の回数は構成可能であり、no retries
のオプションもあります。
詳細は次のトピックを参照してください。
Access Manager Access ServerとSecurity Token Service Access Serverは、HTTPでPingリクエストを送信する方式によるハートビート・チェックをサポートしています。また、管理対象サーバー上のWebLogicノード・マネージャでは、アプリケーションを監視して、イベントが実行されていない場合にはアプリケーションを再起動できます。Access Manager Access Serverを再起動しても、その他のクラスタ・コンポーネントまたはメンバーに影響はありません。
Security Token Serviceは、デフォルトで有効化されています。Security Token Serviceを無効化するには、Oracle Access Managementコンソールを使用します。『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の使用可能なサービスの有効化または無効化に関する説明を参照してください。
Security Token Serviceのログは、管理対象サーバーのログ・ファイルに記録されます。ただし、logging.xmlを編集すると、Security Token Service情報を、<DomainHome>/config/fmwconfig/servers/<servername>/sts/log/
フォルダの個別のログ・ファイル(diagnostic.log
)に記録できます。
Security Token Serviceをトラブルシューティングするために、Security Token Serviceのログ・ファイルを作成する手順は、次のとおりです。
ファイルDomainHome/config/fmwconfig/servers/
servername/logging.xml
を開きます。
次を、適切なセクションに追加します。
<log_handler name='sts-handler' class='oracle.core.ojdl.logging.ODLHandlerFactory'> <property name='path' value='sts/log'/> <property name='maxFileSize' value='10485760'/> <property name='maxLogSize' value='104857600'/> </log_handler> <logger name='oracle.security.fed' level='TRACE:32'> <handler name='sts-handler'/> </logger>
すべてのログ・メッセージは、アプリケーションがデプロイされたWebLogic Serverのサーバー・ログ・ファイルに記録されます。サーバー・ログのデフォルトの場所は次のとおりです。
WL_HOME
/user_projects/domains/domainName
/servers/serverName
/logs/serverName
-diagnostic.log
Security Token Serviceサーバーは、リプレイ攻撃などの偽のリクエストを検出できますが、リプレイ攻撃は、リクエストからトークン・データを不正入手しようとして、同じトークンで別のリクエストを送信した場合に発生することがあります。この場合には、サーバーは2番目の偽のリクエストを検出します。2番目に発行された<Env: Body>
に同一のトークンを持つリクエストは、Security Token Serviceサーバーに送られます。このサーバーは、UNTトークン・キャッシュを確認して、リプレイ攻撃を示すリクエストを拒否します。
この項では、Oracle Access Management Identity Federation 11gR2の高可用性について説明します。Identity Federationの詳細は、Oracle Fusion Middleware Oracle Identity Management統合ガイドのAccess Managerとの統合に関する説明を参照してください。
この項の内容は次のとおりです。
Identity Federationサービスは、複数ドメインのアイデンティティ・ネットワークのOracle Access Management Access Managerに対してシングル・サインオン機能を提供します。もっとも広範なフェデレーション標準のセットがサポートされ、これにより、ソリューション・セットでその他のOracle Identity Management製品が実装されているかどうかに関係なく、異種環境とビジネス結合に属するユーザーのフェデレーションが可能になります。
Identity Federation 11gリリース2のみで、サービス・プロバイダ(SP)機能がサポートされます。アイデンティティ・プロバイダ(IDP)サポートでは、Identity Federation 11gリリース1を使用してください。
Identity Federationは、SPとして機能することで、帯域外の複数のセキュリティ・ドメイン間でユーザー同期をせずに、ユーザー認証をIDPにオフロードする間もリソース管理を可能にします。IDPで認証されると、SPは、ローカル・アクセス・ポリシーに応じて、そのSPのアプリケーションに対するユーザーのアクセスを許可または拒否できます。
ユーザーがそのIDPに対するアカウントを持っていない場合、フェデレーションは終了し、そのユーザーのドメイン間でのシングル・サインオンは自動的に無効化されます。
Identity Federationの主要な機能には、次のサポートが含まれます。
SAML 1.x、SAML 2.0などの複数の主要なフェデレーション・プロトコル
プロトコルを超えたシングル・サインオンおよびサインアウト
X.509証明書検証
Access Managerとのネイティブ統合
Access ManagerによりサポートされるすべてのLDAPディレクトリとの統合
Identity FederationのAccess Managerとの統合方法の詳細は、『Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド』のAccess Manager 11gR2との統合に関する項を参照してください。
Identity Federationは、クロス・ドメイン・シングル・サインオンにSP機能を提供するOracle Access Managementコンポーネントです。Oracle Access Managementによるリモートアイデンティティ・プロバイダ・パートナへのユーザー認証の委任が可能になります。SAML 1.x、SAML 2.0などの広範なフェデレーション標準のセットをサポートします。
Identity Federationは、WebLogic Server上にデプロイされるAccess Manager J2EEアプリケーションの一部です。
Identity FederationはAccess Server内で動作するため、ランタイム・プロセスはAccess Managerと同じです。詳細は、第9.2.1.1.3項「Access Managerプロセスのライフサイクル」を参照してください。
Identity FederationのプロセスのライフサイクルはAccess Managerと同じです。詳細は、第9.2.1.1.3項「Access Managerプロセスのライフサイクル」を参照してください。
Identity Federationのリクエスト・フローの詳細は、Oracle Fusion Middleware Oracle Identity Management統合ガイドのプロセス・フローに関する説明を参照してください。
Identity Federationの構成アーティファクトには、次のファイルが含まれます。
DOMAIN_HOME/config/fmwconfig/oam-config.xml — インスタンス固有の情報を格納する構成ファイルです。
DOMAIN_HOME/config/fmwconfig/oam-policy.xml — OES Micro SMが使用されていない場合にのみ存在します。
DOMAIN_HOME/config/fmwconfig/servers/instanceName/logging.xml — ロギング構成です。
DOMAIN_HOME/config/fmwconfig/cwallet.sso — アイデンティティ・ストア、データベースおよびその他のエンティティへの接続に使用するパスワードを格納します。これは、エンド・ユーザー用のパスワードではありません。
DOMAIN_HOME/config/fmwconfig/.oamkeystore — OAM/Identity Federationが所有する鍵と証明書を格納するキーストアです。
DOMAIN_HOME/config/fmwconfig/amtruststore — X509証明書の検証に使用されるトラスト・アンカーを格納するキーストアです。
DOMAIN_HOME/config/fmwconfig/amcrl.jar — 証明書失効に使用するCRLを格納するzipファイルです。
DOMAIN_HOME/config/fmwconfig/default-keystore.jks — OWSMエージェントが使用する鍵と証明書を格納するOWSMキーストアです。また、WSS操作のためのX.509証明書の検証に使用されるトラステッド・アンカーも格納されます。
DOMAIN_HOME/config/fmwconfig/servers/servername/dms_config.xml — イベント構成ファイルです。
DOMAIN_HOME/config/fmwconfig/component_events.xml — 監査定義です。
DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml — 管理コンソールの権限です。
DOMAIN_HOME/config/fmwconfig/cacerts.jks — 認証局証明書を格納するキーストアです。
Identity Federationサーバーの機能に必要な外部コンポーネントは次のとおりです。
WebLogic Server
管理サーバー
管理対象サーバー
LDAPベースのアイデンティティ・ストア
ユーザー・アイデンティティ・リポジトリ
ユーザー/ロールAPIによって抽象化されるLDAPアクセス
注意: Access Managerは、常に1つのアイデンティティ・ストアに接続しますが、そのアイデンティティ・ストアは物理サーバーまたはロード・バランサIPです。プライマリが停止した場合、Access Managerはロード・バランサに再接続し、ロード・バランサによってセカンダリに接続します。 |
OCSPレスポンダ・サービス
リアルタイムX.509認証検証
RDBMSポリシー・ストア/Coherenceストア
ポリシー(認証および認可)リポジトリ
Access Managerポリシー・エンジンによって抽象化されるRDBMSアクセス
Oracle Entitlements Server (OAM経由)
フェデレーション・データ・キャッシュ
セッションおよびランタイム情報用。このために、メモリー・ストアまたはRDBMSストアを使用するようにIdentity Federationを構成できます。ただし、高可用性環境では、RDBMSストアを使用する必要があります。
データ・リポジトリ
フェデレーションに関連するセッション情報、ユーザーがサイン・インしたパートナおよびプロトコル・データはセッションおよびキャッシュに格納されます。このデータのために、メモリー・ストアまたはRDBMSストアを使用するようにIdentity Federationを構成できます。高可用性環境では、RDBMSストアを使用する必要があります。
WebLogic Serverのログ・ファイルのデフォルトの場所は次のとおりです。
WEBLOGIC_SERVER_HOME
/user_projects/domains/domainName
/servers/serverName
/logs/serverName
-diagnostic.log
ログ・ファイルを表示するには、Oracle Enterprise Manager Fusion Middleware Controlを使用します。
この項では、Identity Federationを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。
この項の内容は次のとおりです。
図9-10は、Identity Federationのアクティブ/アクティブ構成での高可用性アーキテクチャを示しています。
図9-10では、ハードウェアのロード・バランサが着信認証リクエストを受信し、それらをWeb層のWebサーバーにルーティングしています。これらのホストにはOracle HTTP Serverがインストールされています。Oracle HTTP Serverによって、WebLogicプラグインmod_wl_ohs.conf
が使用されてWebLogic管理対象サーバーにリクエストが転送されます。
ロード・バランシング・ルーターは、HTTPトラフィックに対してのみセッション・スティックネスを使用する必要があります。
Oracle Access Serverアプリケーションをホストする2つの管理対象サーバーは、アクセス・サーバーがアクティブ/アクティブ・モードで動作できるように、クラスタで構成されます。
アクセスされるリソースがフェデレーション・スキームによって保護される場合、OAMはフェデレーション・エンジンを使用してユーザーを認証します。
フェデレーション・エンジンによって使用されるLDAPディレクトリは、クラスタ内にデプロイされます。
Oracle RACデータベースは、データ層における高可用性を提供します。
WebLogic管理サーバーは、管理対象サーバーの1つと同じホスト上で実行され、WebLogic管理コンソール、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Access Managementコンソールをデプロイします。2つ目の管理対象サーバーが動作するホスト・マシン上で、管理サーバーをアクティブ/パッシブ・モードで実行するように構成できます。この構成では、最初の管理サーバーが使用できなくなった場合に、2番目のホスト上の管理サーバーを手動で起動できます。
Identity Federationクラスタは、OAMクラスタと同じ方法で起動および停止します。詳細は、第9.2.2.1.1項「クラスタの起動と停止」を参照してください。
1つのクラスタ・メンバーによって加えられた構成変更は、その構成が共有データベースに格納されているため、すべてのメンバーに自動的に伝播されます。詳細は、第9.2.2.1.2項「クラスタワイドの構成変更」を参照してください。
Identity FederationはOAMの一部のため、前提条件はOAMと同じです。詳細は、第9.2.3.1項「Access Managerの構成のための前提条件」を参照してください。
注意: Identity Federationを高可用性デプロイメントで使用する場合は、クラスタ・ノードのシステム・クロックを同期する必要があります。 |
OAMサーバー上で動作する機能として、Identity Federationの高可用性をOAMの高可用性の一部として構成します。OAMの高可用性を構成するには、第9.2.3項「Access Managerの高可用性の構成手順」を参照してください。Identity Federationの高可用性の構成時には、次の特別な考慮事項に注意してください。
OAMとIdentity Federation構成のホスト名とポートには、ロード・バランサのホストとポートを設定することをお薦めします。このように設定しない場合、シングル・サインオンおよびログアウト操作でエラーが発生します。また、別のホスト上にリストアされた後に、対応するエージェントの構成を更新する必要がないように、OAM構成で仮想化されたホスト名を使用することをお薦めします。
ProviderIdは、SPを一意に識別する文字列です。クラスタ内のすべてのサーバーのProviderIdは同一である必要があります。インストール時のProviderIdのデフォルトは、http://host:port/oam/fed/
です。必要に応じて、インストール後にこの値を変更または設定しますが、運用時には変更しないでください。
セッション・データが格納されているRACデータベースへの接続を調整できます。
アーティファクト・プロファイルを使用する場合は、WLSTを使用してSOAP接続の詳細を調整します。
設定可能なIdentity Federationパラメータは次のとおりです。
発信SOAP接続
チューニング可能な発信SOAP接続のパラメータは次のとおりです。
最大合計接続数
ホスト当たりの最大接続数
RDBMS一時ストアの非同期設定
表9-5は、RDBMS一時ストアの非同期設定を示します。
表9-5 RDBMS一時ストアの非同期設定
設定値 | 説明 |
---|---|
rdbmsasynchronousmanagerinterval |
非同期のスレッド・マネージャに対する実行間隔 |
rdbmsasynchronousmanagersleep |
非同期のスレッド・マネージャのスリープ間隔で、実行が発生したかどうかを確認します。 |
rdbmsasynchronousqueuesize |
同じタイプのRDBMS操作(セッションの作成、アーティファクトの作成)が含まれるキューのサイズ |
rdbmsasynchronousqueuesleep |
キューがいっぱいの場合に、コール元スレッドがキューに操作の追加をリトライできるまでのスリープ時間 |
rdbmsasynchronousqueueretries |
キューがいっぱいの場合に、キューに操作の追加を試みる際のリトライ数 |
rdbmsasynchronousthreadcore |
RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールでのデフォルトのスレッド数 |
rdbmsasynchronousthreadkeepalive |
RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールでの外部スレッドの最大保持時間 |
rdbmsasynchronousthreadmax |
RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールでの最大スレッド数 |
rdbmsasynchronousthreadpolicy |
RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールのスレッド・ポリシー |
rdbmsasynchronousthreadqueuesize |
RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールのスレッドのキュー・サイズ |
RDBMSアーティファクトのメモリー・キャッシュ設定
表9-6は、RDBMS非同期モジュールとともに使用されるRDBMSアーティファクトのメモリー・キャッシュ設定を示します。
表9-6 RDBMSアーティファクトのメモリー・キャッシュ設定
設定値 | 説明 |
---|---|
artifactrdbmscachetimeout |
メモリー・キャッシュでの存続時間 |
artifactrdbmsretries |
失敗を返すまでのRDBMSでのエントリ検出の最大リトライ数 |
artifactrdbmssleep |
操作の参照をリトライする間のスリープ時間 |
RDBMSのメモリー・キャッシュ設定
表9-7は、RDBMSのメモリー・キャッシュ設定(アーティファクト設定を除く)を示します(表9-6を参照)。
表9-7 RDBMSのメモリー・キャッシュ設定
設定値 | 説明 |
---|---|
transientrdbmscachesize |
キャッシュ・サイズ |
transientrdbmscachetimeout |
無効になるか、オブジェクトの検索時にRDBMSの参照操作が強制されるまでのキャッシュ・オブジェクトの存続時間 |
RDBMSクリーン・アップ・スレッドの間隔
RDBMSクリーンアップのスレッド間隔の設定はrdbmscleanupinterval
で、これは、Identity Federationデータベース表から期限切れのエントリを削除するスレッドのスリープ間隔を示します。
この項では、高可用性環境にデプロイされたIdentity Federationインスタンスのフェイルオーバー操作の実行手順と、予想される動作について説明します。
Identity Federationインスタンスのフェイルオーバーのテストを実行し、Identity Federationのステータスを確認するには、次の手順に従います。
管理サーバーのコンソールにログインします。「ホーム」→「セキュリティ・レルムのサマリー」→「myrealm」→「ユーザーとグループ」→「レルム・ロール」→「グローバル・ロールの編集」の順に移動します。グループOAMAdminstrators
を追加します。
OAM管理コンソールにログインします。「システム構成」→「共通設定」→「使用可能なサービス」の順に移動して、Identity Federationを有効化します。
IDPインスタンス(Oracle Identity Federation 11gリリース1インスタンス)とSPとして機能するこのIdentity Federation 11gリリース2インスタンス間に、Identity Federationを設定します。
OAM 11gR2と統合し、OIFSchemeでリソースを保護します。『Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド』のAccess Manager 11gR2との統合に関する項の手順に従います。
2つの管理対象サーバーのうちの1つを停止し、保護されたリソースへのアクセスを試みます。
IDPログイン・ページが表示されたら、前述の手順で停止した管理対象サーバーを再起動して、動作中の管理対象サーバーを停止し、操作の完了を試みます。
Identity Federationに関する問題をトラブルシューティングするには、次のヒントを使用します。
Identity Federationのメッセージは、次のような管理対象サーバーのログ・ファイルに記録されます。
WEBLOGIC_SERVER_HOME
/user_projects/domains/domainName
/servers/serverName
/logs/serverName
-diagnostic.log
Identity Federationサーバー構成のホスト名とポートには、ロード・バランサのホストとポートが設定されていることを確認します(このように設定しない場合、シングル・サインオン操作でエラーが発生します)。
IDPとSPを実行する各コンピュータのシステム・クロックの時間が異なると、シングル・サインオンの際にエラーが発生します。これを修正するには、同じ時間になるようにシステム・クロックの時間を設定するか、Oracle Enterprise Manager Fusion Middleware Controlの「サーバー・プロパティ」ページを使用してサーバー・ドリフトを調整します。
ProviderId
はIDP/SPを一意に識別する文字列であり、クラスタ内のすべてのサーバーで同一である必要があります。インストール時のProviderId
文字列のデフォルトは、http://
host
:
port
/oam/fed
です。ProviderId
を変更する必要がある場合は、運用時ではなく、インストール後に変更してください。
この項では、Oracle Entitlements Serverの概要およびOracle Entitlements Serverコンポーネントの高可用性環境の設定方法について説明します。
Oracle Entitlements Serverはきめ細やかな認可製品で、これにより組織はリソースへのアクセスと使用を制御するポリシーを定義して管理することで、そのリソースを保護することができます。ポリシーでは、誰が、どのリソースに、いつ、どのように行うことができるかを指定することによって、アクセス権限を定義します。ポリシーでは、ソフトウェア・コンポーネントやビジネス・オブジェクトを含む、すべてのタイプのリソースを制御できます。
Oracle Entitlements Serverコンポーネントのアーキテクチャの図および説明については、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのOracle Entitlements Serverアーキテクチャの概要に関する説明を参照してください。
Oracle Entitlements Server機能の詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのOracle Entitlements Server 11gR2の機能に関する説明を参照してください。
この項の内容は次のとおりです。
この項では、Oracle Entitlements Serverを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。
この項の内容は次のとおりです。
この項では、Oracle Entitlements Serverコンポーネントの次のような高可用性アーキテクチャのシナリオについて説明します。
この項の内容は次のとおりです。
第9.6.1.1.3項「Webサービスに対するプロキシ・モードでのセキュリティ・モジュール/制御プッシュ・モードの高可用性でのRMIセキュリティ・モジュール」
第9.6.1.1.4項「Webサービスに対するプロキシ・モードでのセキュリティ・モジュール/制御プル・モードの高可用性でのRMIセキュリティ・モジュール」
第9.6.1.1.5項「Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュールの高可用性」
図9-11は、アクティブ/アクティブ構成で高可用性アーキテクチャにデプロイされたOracle Entitlements Serverの管理サーバーを示しています。
図9-11 Oracle Entitlements Serverの管理サーバーの高可用性アーキテクチャ
OESHOST1には、次のインストールがあります。
Oracle Entitlements ServerインスタンスはWLS_OES1管理対象サーバーにインストールされており、APMインスタンスはWLS_OES1管理対象サーバーにインストールされています。
Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソースまたはGridLinkデータ・ソース内に構成されています。
WebLogic Serverの管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。
OESHOST2には、次のインストールがあります。
Oracle Entitlements ServerインスタンスはWLS_OES2管理対象サーバーにインストールされており、APMインスタンスはWLS_OES2管理対象サーバーにインストールされています。
Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
OESHOST1およびOESHOST2上のWLS_OES1およびWLS_OES2管理対象サーバーのインスタンスは、OES_CLUSTERクラスタとして構成されています。
WebLogic Serverの管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。OESHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。
2つのOracle Entitlements Serverの管理サーバーが登録サーバーとバックアップ登録サーバーとして機能するように、Oracle Entitlements Serverのセキュリティ・モジュールを制御プッシュ・モードで構成できます。登録サーバーが停止した場合、Oracle Entitlements Serverのセキュリティ・モジュールをバックアップ・サーバーに切り替えることができ、Oracle Entitlements Serverの管理サーバーから分散ポリシーを取得できます。フェイルオーバー・シナリオおよび動作の詳細は、第9.6.1.4項「フェイルオーバーに関する考慮事項」を参照してください。
セキュリティ・モジュールが埋め込まれ、異なるポリシー情報ポイント(PIP)間でフェイルオーバーするよう構成できるように、セキュリティ・モジュールをデプロイできます。PIPはデータ・リポジトリであり、認可の決定用にポリシーを評価するときに使用するために取得できる情報のソースです。PIPの詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのポリシー情報ポイントに関する説明を参照してください。
デプロイメント・オプションについては次の項目を参照してください。
複数のLDAP/JDBC URLを使用するOracle Entitlements Server PIP
図9-12は、高可用性デプロイメントでの埋込みセキュリティ・モジュール・インスタンスを示しています。LDAPおよびDBベースのPIPの両方を使用して、外部リソース間でフェイルオーバーするために、外部リソースの複数のエンドポイントを構成できます。DBベースのPIPでは、マルチソースのデータ・ソースも構成できます。
図9-12は、セキュリティ・モジュール(PDP)がLDAP 1またはDatabase 1をプライマリPIPとして使用するOracle Entitlements Serverのデプロイメントを示しています。フェイルオーバー時には、セキュリティ・モジュールはLDAP2およびDatabase 2にフェイルオーバーされます。
RACおよびロード・バランサを使用するOracle Entitlements Server PIP
Oracle Entitlements Serverの高可用性デプロイメントのもう1つのオプションでは、セキュリティ・モジュール(PDP)はロード・バランサとともにRACデータベースまたはLDAPサーバーを使用します。フェイルオーバー時には、図9-13に示すとおり、セキュリティ・モジュールはRACにフェイルオーバーされます。
図9-13 RACおよびロード・バランサを使用するOracle Entitlements Server PIP
Oracle Entitlements Serverでは、クライアントが認可サービスをリモートで起動できるプロキシ・モードがサポートされます。Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのセキュリティ・モジュールのプロキシ・モードの使用を参照してください。セキュリティ・モジュールのプロキシ・モードでのデプロイには、次の3つのデプロイメント・オプションがあります。
WebLogic Serverデプロイメント上のWebサービスのセキュリティ・モジュール
図9-14は、WebLogic Server上のWebサービスのセキュリティ・モジュールを示します。
図9-14 WebLogic Serverデプロイメント上のWebサービスのセキュリティ・モジュール
スタンドアロンのWebサービスのセキュリティ・モジュールのデプロイメント
図9-15は、スタンドアロンのWebサービスのセキュリティ・モジュールのデプロイメントを示します。
RMIのセキュリティ・モジュールのデプロイメント
図9-16は、RMIのセキュリティ・モジュールのデプロイメントを示します。
Webサービスに対するプロキシ・モードでのセキュリティ・モジュールおよび制御プル・モードでのRMIセキュリティ・モジュールをデプロイするためのオプションは、次のとおりです。
WebLogic Server上のWebサービスのセキュリティ・モジュール
図9-17は、WebLogic Server上のWebサービスのセキュリティ・モジュールを示します。
スタンドアロンのWebサービスのセキュリティ・モジュール
図9-18は、スタンドアロンのWebサービスのセキュリティ・モジュールのデプロイメントを示します。
RMIのセキュリティ・モジュール
図9-19は、RMIのセキュリティ・モジュールのデプロイメントを示します。
Webサービスのセキュリティ・モジュールのプロキシ・クライアントおよびRMIのセキュリティ・モジュールのプロキシ・クライアントの構成の詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのPDPプロキシに関する説明を参照してください。
OES WebLogic Serverの高可用性には、次の2つのデプロイメント・オプションがあります。
「Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュール、制御プッシュ・モード」
「Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュールの高可用性、制御プル・モードまたは非制御モード」
Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュール、制御プッシュ・モード
次の図は、制御プッシュ・モードのOracle Entitlements Server WebLogic Serverのセキュリティ・モジュールを示します。
図9-20 Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュール、制御プッシュ・モード
Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュールの高可用性、制御プル・モードまたは非制御モード
次の図は、制御プル・モードまたは非制御モードのWebLogic Serverのセキュリティ・モジュールを使用したOracle Entitlements Server を示します。
図9-21 Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュールの制御プル・モード/非制御モード
セキュリティ・モジュールが制御プルまたは非制御分散のOPSSセキュリティ・ストアからポリシーを読み取る場合、アプリケーションによるデータベースへのアクセスでは、Oracleが推奨する高可用性方法を使用してください。
すべての高可用性のシナリオで、ロード・バランサをデプロイできます。
ユーザー対APM通信に対するAuthorization Policy Manager (APM)の前面。ポリシー・ストアに永続化されないデータの損失を防ぐためにスティッキーな接続をお薦めします。
クライアント対セキュリティ・モジュール通信に対するWebサービスのセキュリティ・モジュールの前面。キャッシュを最大限に使用するためにスティッキーな接続をお薦めします。
注意: Oracle Entitlements Serverには、ロード・バランサに対するタイムアウト要件はありません。 |
この項では、Oracle Entitlements Serverのフェイルオーバーに関する考慮事項について説明します。
表9-8 Oracle Entitlements Serverのフェイルオーバーのシナリオと動作
フェイルオーバーのシナリオ | フェイルオーバーの動作 |
---|---|
OESポリシー・ストアの障害 |
マルチソースのデータ・ソースが使用されている場合、制御プルおよび非制御モードのAPMおよびセキュリティ・モジュールは、作業インスタンスに切り替わります。ポリシー・ストアのインスタンスが失われた場合も、トランザクションは処理されます。
|
OES管理サーバーの障害 |
|
Webサービスのセキュリティ・モジュールまたはRMIのセキュリティ・モジュールの障害 |
セキュリティ・モジュールのプロキシは、構成されているリトライ数に達するまでリクエストをリトライします。 |
DBまたはLDAP属性ソースの障害 |
セキュリティ・モジュール(OESクライアント)は、構成されているリトライ数に達するまでデータの読取りを継続します。 |
この項では、Oracle Entitlements Serverのアクティブ/アクティブ・クラスタにおける様々な障害からの保護について説明します。
Oracle Entitlements Serverのフェイルオーバーは透過的ではありません。WebLogic Serverインスタンスのフェイルオーバー時は、Oracle Entitlements Serverを使用して接続を再確立する必要があります。
ノード障害は、WebLogic Serverのクラッシュと同じ方法で処理されます。
Oracle Entitlements Serverは、システムの初期設定時に構成したマルチ・データ・ソースの使用によって、データベースの障害から保護されます。マルチ・データ・ソースによって、Oracle RACデータベース・インスタンスで障害が発生した場合に、使用可能なデータベース・インスタンスとの接続が再確立されることが保証されるようになります。マルチ・データ・ソースを使用すると、Oracle RACデータベース内の複数のインスタンスへの接続を構成できます。
高可用性アーキテクチャでは、Oracle Entitlements ServerをOracle WebLogicクラスタにデプロイしますが、このクラスタには、その一部として少なくとも2つのサーバーが存在します。
デフォルトでは、WebLogic Serverによって、このアプリケーションに対する様々なライフサイクル・イベントの起動、停止、監視および管理が行われます。Oracle Identity Managerアプリケーションは、基盤となるOracle WebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。
Oracle Entitlements Serverのライフサイクル・イベントは、次に示すコマンドライン・ツールおよびコンソールを1つ以上使用して管理できます。
WebLogic Server管理コンソール
Oracle Enterprise Manager Fusion Middleware Control
Oracle WebLogic Scripting Tool(WLST)
高可用性環境では、すべてのOracle Entitlements Serverインスタンスが同じ構成リポジトリを共有するため、Oracle Entitlements Serverの1つのインスタンスの構成を変更するとその他すべてのインスタンスの構成も変更されます。ほぼすべてのOracle Entitlements Serverデプロイメントで、クラスタ構成が使用されます。唯一の例外はOracle Entitlements Serverの管理サーバーで、通常、これはクラスタ化されません。
LDAPとOracle Entitlements Serverデータベース間の同期は、調整と呼ばれるプロセスによって処理されますが、このプロセスは、主にバックグラウンドで実行されるスケジュール済プロセスです。このプロセスは手動で実行することもできます。
同期プロセス中にLDAPが停止した場合、Oracle Entitlements Serverによって取得されていないデータは、調整タスクの次回の実行時に取得されます。
この項では、Oracle Entitlements Serverで高可用性を得るためのデプロイメントを設定する高度な手順について説明します。
Oracle Entitlements Server管理サーバーの高可用性デプロイメントは、一般的なOracleアプリケーションと同じです。
Oracle Entitlements Serverの管理サーバー・ユーザー・インタフェースにアクセスするユーザーに対して高可用性を設定するには、WebLogicクラスタを使用します。
管理サーバー・ユーザー・インタフェースに対して高可用性データベースを設定するには、マルチ・ソース・データベース、Oracle RACおよびその他の一般的な要素を使用します。
この項の内容は次のとおりです。
第9.6.2.4項「制御プッシュ・モードのOESのセキュリティ・モジュールをOracle Entitlements Server管理サーバーを使用して高可用性に構成」
第9.6.2.5項「プロキシ・モードのOracle Entitlements Serverのセキュリティ・モジュールをPDPを使用して高可用性に構成」
第9.6.2.7項「WebLogicでのOracle Entitlements Server Webサービスのセキュリティ・モジュールの高可用性の構成」
第9.6.2.8項「Oracle Entitlements Server WebLogicセキュリティ・モジュールの高可用性の構成」
Oracle Entitlements Serverの高可用性を構成する前に、次の手順を完了します。
リポジトリ作成ユーティリティを使用して、Oracle Entitlements ServerスキーマをOracle RACデータベースに作成します。スキーマの作成の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Entitlements Serverのインストールと構成ロードマップに関する説明を参照してください。
OESHOST1およびOESHOST2にWebLogic Serverをインストールします。詳細は、第9.1.3.1.2項「Oracle WebLogic Serverのインストール」を参照してください。
OESHOST1およびOESHOST2にOracle Entitlements Serverの管理ソフトウェアをインストールします。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Entitlements Server管理サーバーのインストールに関する説明を参照してください。
Oracle Entitlements Serverクライアントをインストールします。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Entitlementsクライアントのインストールに関する説明を参照してください。
OESHOST1でOES管理サーバー用WebLogicドメインを構成するには、次の手順を実行します。
<MW_HOME>/oracle_common/common/bin/config.sh
スクリプトを実行します(Windowsの場合はconfig.cmd
)。Oracle Fusion Middleware構成ウィザードの「ようこそ」画面が表示されます。
「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。「拡張ソースの選択」画面が表示されます。
「拡張ソースの選択」画面で、「管理対象サーバー[iam]のOracle Entitlements Server」を選択します。構成ウィザードによって、「Oracle JRF」、「Oracle Platform Security Service」および「Basic WebLogic Server Domain」が自動的に選択されます。
「次へ」をクリックします。
「ドメイン名と場所の指定」画面で、作成しているドメインのドメイン名と場所を入力します。「次へ」をクリックします。「管理者ユーザー名およびパスワードの構成」画面が表示されます。
管理者のユーザー名とパスワードを構成します。デフォルトのユーザー名はweblogic
です。「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、WebLogicドメインの起動モードとJDKを選択します。
「JDBCコンポーネント・スキーマの構成」画面で、すべてのスキーマのJDBCプロパティを構成し、「次へ」をクリックします。
「JDBCコンポーネント・スキーマのテスト」画面で、「すべて選択」をクリックして「接続のテスト」をクリックします。「次」をクリックします。
データ・ソースの検証が成功した場合、「次へ」をクリックします。
データ・ソースの検証に失敗した場合は、「前へ」をクリックして問題を修正し、もう一度実行します。
「オプションの構成を選択」画面で、「管理対象サーバー、クラスタ、およびマシン」を選択します。「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: All Local Addresses
リスニング・ポート: 7001
SSLリスニング・ポート: 7002
SSL有効を選択
「次へ」をクリックします。
「管理対象サーバーの構成」画面では、この画面を初めて表示したときに、oes_server1
という管理対象サーバーが自動的に作成されます。oes_server1の名前を変更し、このエントリに対する属性を更新できます。
例:
名前: oes_server1
リスニング・アドレス: OESHOST1.mycompany.com
リスニング・ポート: 14600
SSLポート: 14601
2つ目のOES_SERVERでは、「追加」をクリックして、次の値を入力します。
名前: oes_server2
リスニング・アドレス: OESHOST2.mycompany.com
リスニング・ポート: 14600
SSLポート: 14601
SSL有効を選択
「次へ」をクリックします。
「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成します。
名前oes_cluster
を入力します。「クラスタのメッセージング・モード」に「unicast」を選択し、クラスタ・アドレスをmanaged server1:port,managed server2: portの形式で入力します。
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタに関連付けます。
右のウィンドウで、クラスタ名「oes_cluster」をクリックします。
管理対象サーバー「oes_server1」をクリックしてから、矢印をクリックして、その管理対象サーバーをクラスタに割り当てます。
管理サーバーoes_server2について、前述の手順を繰り返します。
「次へ」をクリックします。
「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。
ホストでUnixオペレーティング・システムを使用する場合は、「Unix」タブを、それ以外の場合は、「マシン」をクリックします。Windowsでは「マシン」タブをクリックし、次に「追加」をクリックして、次のマシンを追加します。
管理サーバー・ホストの場合:
名前: ホストの名前。ここでは、DNS名を使用することをお薦めします。
ノード・マネージャ・リスニング・アドレス: マシンのIPアドレスは、マシンのDNS名と同じにすることをお薦めします。
ノード・マネージャ・リスニング・ポート: ノード・マネージャが使用するポートを入力します。
その他すべての値はデフォルト設定のままにします。
OESHOST1およびOESHOST2について前述の手順を繰り返し、次の値を入力します。その他すべての値はデフォルト設定のままにします。
名前: ホスト名です。DNS名を使用することをお薦めします。
ノード・マネージャ・リスニング・アドレス: マシンのIPアドレスは、マシンのDNS名と同じにすることをお薦めします。
ノード・マネージャ・リスニング・ポート: ノード・マネージャが使用するポートを入力します。
Unixオペレーティング・システムでは、「マシン」タブの下にあるデフォルト・ローカル・マシンのエントリを削除します。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを割り当てます。次の手順を実行します。
右側のウィンドウでマシンをクリックします。
左側のウィンドウで、そのマシン上で実行する管理対象サーバーをクリックします。
矢印をクリックし、その管理対象サーバーをそのマシンに割り当てます。
すべての管理対象サーバーを適切なマシンに割り当てるまで、この手順を繰り返します。
次のように、サーバーをマシンに割り当てます。
ADMINHOST: 管理サーバー
OESHOST1: oes_server1
OESHOST2: oes_server2
「次へ」をクリックします。
「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、「次へ」をクリックします。クラスタ「oes_cluster」を選択します。「アプリケーション」を選択し、次に「DMSアプリケーション」、「wsil-wls」、「oracle.security.apm」、「oracle.oes.admin.pd.ssl」、「oracle.oes.admin.enroll」を選択します。
「AdminServer」を選択します。「アプリケーション」を選択し、次にFMWの「ようこそ」ページの「アプリケーション」、「DMS Application」および「wsil-wls」を選択します。
クラスタ「oes_cluster」を選択し、次にすべてのサービスを選択します。
「次」をクリックします。
「構成のサマリー」画面で、「作成」をクリックします。
OPSSセキュリティ・ストア構成の最初のRACデータベース・インスタンスが動作していることを確認します。
OPSSセキュリティ・ストアを構成します。『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOES管理サーバーのセキュリティ・ストアの構成に関する説明を参照してください。
この項の内容は次のとおりです。
管理ホスト(OESHOST1など)でノード・マネージャを起動するには、次の手順を実行します。
MW_HOME/wlserver_10.3/server/bin/
ディレクトリにあるstartNodeManager.sh
スクリプトを実行します。
setNMProps.sh
スクリプトを実行して、StartScriptEnabledプロパティをtrueに設定します。
cd MW_HOME/oracle_common/common/bin
ノード・マネージャ・プロセスを強制終了してノード・マネージャを停止するか、Windowsでサービスを停止します。
ノード・マネージャを起動します。
次の手順を実行して、管理サーバーが適切に構成されていることを確認します。
新しいドメインで./startWeblogic.sh
を使用して、WebLogic管理サーバーを起動します。
ブラウザで、次のようなOracle WebLogic Server管理コンソールのURLを入力します。
http://
<OESHOST1>:7001/console
WebLogic管理者(たとえば、weblogic
)としてログインします。
packおよびunpackコマンドを使用し、管理サーバーが使用するドメイン・ディレクトリをOESHOST1の管理対象サーバーが使用するドメイン・ディレクトリから分離します。
OESHOST1で独立ドメイン・ディレクトリを作成する手順は次のとおりです。
次のようにpackコマンドを実行し、テンプレート・パックを作成します。
cd MW_HOME/oracle_common/common/bin
./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=domaintemplate.jar -template_name=domain_template
次のようにunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。
cd MW_HOME/oracle_common/common/bin
./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=domaintemplate.jar
リモート・ホストの管理対象サーバー(OESHOST2など)を起動する前に、リモート・ホストでunpackを実行します。
第9.6.2.3.3項「管理サーバーと同じノードでの管理対象サーバー用独立ドメイン・ディレクトリの作成」で作成したファイルdomaintemplate.jar
をOESHOST2にコピーします。
次のコマンドを使用して、OESHOST2のホストでunpackを実行します。
cd MW_HOME/oracle_common/common/bin
./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=domaintemplate.jar
リモート・ホストでノード・マネージャを起動するには、次の手順を実行します。
OESHOST2でノード・マネージャを起動して、MW_HOME/wlserver_10.3/server/bin
ディレクトリにあるstartNodemanager.sh
スクリプトを使用してnodemanager.properties
ファイルを作成します。
setNMProps.sh
スクリプトを実行して、StartScriptEnabled
プロパティをtrueに設定します。
cd MW_HOME/oracle_common/common/bin
./setNMProps.sh
ノード・マネージャを停止および起動します。
WebLogic管理サーバーを再起動します。
ブラウザで、次のようなOracle WebLogic Server管理コンソールのURLを入力します。
http://
<OESHOST1>:7001/console
WebLogic管理者(たとえば、weblogic
)としてログインします。
WebLogic Serverの管理コンソールからoes_server1およびoes_server2管理対象サーバーを起動します。
注意: また、ドメイン・ディレクトリのサブフォルダbinで
|
URL(http://
<OESHOST1>:14600/apm
)でAPMコンソールを開いて、OESHOST1のOES管理サーバー・インスタンスを検証します。
WebLogicユーザー名およびパスワードを使用してログインします。
http://
<OESHOST2>:14600/apm
をWebブラウザで指定してAPMコンソールを開き、OESHOST2のOES管理サーバー・インスタンスを検証します。
制御プッシュ・モードのOracle Entitlements Serverのセキュリティ・モジュールを高可用性で構成するには、OESセキュリティ・モジュールの構成ユーザー・インタフェースを使用して高可用性パラメータを設定します。
適切なセキュリティ・モジュール・インスタンスのディレクトリのbinディレクトリに変更して、コマンドラインから次のスクリプトを実行します。
cd $OES_CLIENT_HOME/oes_sm_instances/SM_Name/bin
Linuxではoessmconfig.sh
、Windowsではoessmconfig.bat
を実行して、SMConfig UIを開始します。
SMConfig UIの使用の詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのSMConfig UIの開始に関する説明を参照してください。
jps-config.xml
ファイルに次のパラメータを設定します。
oracle.security.jps.runtime.pd.client.backupRegistrationServerURL
oracle.security.jps.runtime.pd.client.registrationRetryInterval
次の例は、RegistrationServerURL
に障害が発生した場合にバックアップとして使用されるbackupRegistrationServerURL
を示します。
<property name="oracle.security.jps.runtime.pd.client.backupRegistrationServerURL" value="https://slc00bqz:14601/pd-server"/>
詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのJavaセキュリティ・モジュールの構成に関する説明を参照してください。
プロキシ・モードのセキュリティ・モジュールをPDPを使用して高可用性に構成するには、次の手順を実行します。
プロキシ・モードのセキュリティ・モジュールを構成するには、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのセキュリティ・モジュールのプロキシ・モードの使用を参照してください。
PDPアドレス(例: oracle.security.jps.pdp.proxy.PDPAddress
)に、カンマ区切りの値を追加することで変更します。
例:
oracle.security.jps.pdp.proxy.PDPAddress=http://ws1:9410,http://ws2:9410
詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのJPDPプロキシ・クライアントの構成に関する説明を参照してください。
ポリシー情報ポイントの高可用性を構成するには、次の手順を実行します。
適切なセキュリティ・モジュール・インスタンスのディレクトリのbinディレクトリに変更して、コマンドラインから次のスクリプトを実行します。
cd $OES_CLIENT_HOME/oes_sm_instances
/SM_Name/bin
Linuxではoessmconfig.sh
、Windowsではoessmconfig.bat
を実行して、SMConfig UIを開始します。
詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのSMConfig UIの開始に関する説明を参照してください。
ポリシー情報ポイントの高可用性用に次の属性リトリーバ・パラメータを設定します。詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドの属性リトリーバの構成に関する説明を参照してください。
注意:
|
WebLogicのOracle Entitlements Server Webサービスのセキュリティ・モジュールを、WebLogicクラスタを使用して高可用性に構成できます。
WebLogicのOracle Entitlements Server Webサービスのセキュリティ・モジュールを構成するには、次の手順を実行します。
OESHOST1で、次の手順を行います。
OESCLIENT_HOME/oessm/bin/config.sh
を実行して、Webサービスのセキュリティ・モジュールとWebLogic Serverドメインを作成します。
例:
./config.sh -smType ws -onWLS -smConfigId <ws_name> -serverLocation <wls_home> -pdServer <oes_admin_server> -pdPort <oes_admin_ssl_port>
「ようこそ」画面で「WebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。リストから「WebLogic上の管理対象サーバー用のOracle Entitlements Server Webサービスのセキュリティ・モジュール」を選択します。
「次へ」をクリックします。
「ドメイン名と場所の指定」画面で、ドメインおよびそのすべてのアプリケーションの名前と場所を入力します。
ドメイン名: <domain name>
ドメインの場所: デフォルトのエントリを受け入れます。
「管理サーバーのユーザー名とパスワードの構成」画面で、次のように入力します。
名前: weblogic
ユーザー・パスワード: WebLogicユーザーのパスワード
ユーザー・パスワードの確認: WebLogicユーザーのパスワード
説明: WebLogicユーザーの説明
「サーバーの起動モードおよびJDKの構成」画面で、「本番モード」および「JDK」を選択します。
「オプションの構成を選択」画面で、「AdminServer」および「管理対象サーバー」を選択します。「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: All Local Addresses
リスニング・ポート: 7001
SSLリスニング・ポート: 7002
SSL有効を選択して「次へ」をクリックします。
「管理対象サーバーの構成」画面で、デフォルトの管理対象サーバーwsonwls_server1
が作成されます。wsonwls_server1
の詳細を変更し、2つ目の管理対象サーバーを追加します。
wsonwls_server1
では、次の値を入力します。
名前: wsonwls_server1
リスニング・アドレス: WSSMHOST1
リスニング・ポート: 14610
SSLリスニング・ポート: 14611
2つ目の管理対象サーバーでは、「追加」をクリックして、次の値を入力します。
名前: wsonwls_server2
リスニング・アドレス: WSSMHOST2
リスニング・ポート: 14610
SSLリスニング・ポート: 14611
「クラスタの構成」画面で、「追加」をクリックしてwssm_cluster
を入力します。「クラスタのメッセージング・モード」に「unicast」を選択し、クラスタ・アドレスをmanaged_ server1:port,managed_server2: portのように入力します。
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタに関連付けます。
右のウィンドウで、クラスタ「wssm_cluster」
をクリックします。
管理対象サーバー「wsonwls_server1」
をクリックしてから、矢印をクリックして、その管理対象サーバーをクラスタに割り当てます。
管理サーバーwsonwls_server2
について、前述の手順を繰り返します。
「次へ」をクリックします。
「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。
ホストでUnixオペレーティング・システムを使用する場合は、「Unix」タブを、それ以外の場合は、「マシン」をクリックします。Windowsでは「マシン」タブをクリックし、次に「追加」をクリックして、次のマシンを追加します。
管理サーバー・ホストの場合:
名前: ホストの名前。ここでは、DNS名を使用することをお薦めします。
ノード・マネージャ・リスニング・アドレス: マシンのIPアドレスは、マシンのDNS名と同じにすることをお薦めします。
ノード・マネージャ・リスニング・ポート: ノード・マネージャが使用するポートを入力します。
その他すべての値はデフォルト設定のままにします。
WSSMHOST1およびWSSMOESHOST2について前述の手順を繰り返し、次の値を入力します。その他すべての値はデフォルト設定のままにします。
名前: ホスト名です。DNS名を使用することをお薦めします。
ノード・マネージャ・リスニング・アドレス: マシンのIPアドレスは、マシンのDNS名と同じにすることをお薦めします。
ノード・マネージャ・リスニング・ポート: ノード・マネージャが使用するポートを入力します。
Unixオペレーティング・システムでは、「マシン」タブの下にあるデフォルト・ローカル・マシンのエントリを削除します。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを次の手順で割り当てます。
右側のウィンドウでマシンをクリックします。
左側のウィンドウで、そのマシン上で実行する管理対象サーバーをクリックします。
矢印をクリックし、その管理対象サーバーをそのマシンに割り当てます。
すべての管理対象サーバーを適切なマシンに割り当てるまで、この手順を繰り返します。
次のように、サーバーをマシンに割り当てます。
ADMINHOST: 管理サーバー
WSSMHOST1: wsonwls_server1
WSSMHOST2: wsonwls_server2
「次へ」をクリックします。
「構成のサマリー」画面で、「作成」をクリックします。
新しいドメインで./startWeblogic.sh
を使用して、WebLogic管理サーバーを起動します。
管理対象サーバーを起動します。作成したドメイン・ディレクトリのサブフォルダbin
に切り替え、./startManagedWebLogic.sh
管理対象サーバー名 http://wlsadminserver host:wls_adminserver_portを入力します。
例:
./startManagedWeblogic.sh wsonwls_server1 http://localhost:7001
OESHOST2で、次の手順を行います。
packおよびunpackコマンドを使用し、OES WebサービスSMが使用するドメイン・ディレクトリをOESHOST1の管理対象サーバーが使用するドメイン・ディレクトリから分離します。
ドメイン・ディレクトリの分離の手順は、第9.6.2.8項「Oracle Entitlements Server WebLogicセキュリティ・モジュールの高可用性の構成」を参照してください。
Oracle Entitlements Server WebLogicセキュリティ・モジュールを、WebLogicクラスタを使用して高可用性に構成できます。
Oracle Entitlements Server WebLogicセキュリティ・モジュールを構成するには、次の手順を実行します。
OESHOST1で、次の手順を行います。
OESCLIENT_HOME/oessm/bin/config.sh
を実行して、WebLogicセキュリティ・モジュールとWebLogic Serverドメインを作成します。
例:
./config.sh -smType wls -smConfigId <wls_name> -serverLocation <wls_home> -pdServer <oes_admin_server> -pdPort <oes_admin_ssl_port>
「ようこそ」画面で「WebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。リストから「WebLogic上の管理対象サーバー用のOracle Entitlements Server WebLogicのセキュリティ・モジュール」を選択します。
「次へ」をクリックします。
「ドメイン名と場所の指定」画面で、ドメインおよびそのすべてのアプリケーションの名前と場所を入力します。
ドメイン名: <domain name>
ドメインの場所: デフォルトのエントリを受け入れます。
「管理サーバーのユーザー名とパスワードの構成」画面で、次のように入力します。
名前: weblogic
ユーザー・パスワード: WebLogicユーザーのパスワード
ユーザー・パスワードの確認: WebLogicユーザーのパスワード
説明: WebLogicユーザーの説明
「サーバーの起動モードおよびJDKの構成」画面で、「本番モード」および「JDK」を選択します。
「オプションの構成を選択」画面で、「AdminServer」および「管理対象サーバー」を選択します。「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: All Local Addresses
リスニング・ポート: 7001
SSLリスニング・ポート: 7002
SSL有効を選択して「次へ」をクリックします。
「管理対象サーバーの構成」画面で、デフォルトの管理対象サーバーwlssm_server1
が作成されます。デフォルトの管理対象サーバーの詳細を変更し、2つ目の管理対象サーバーを追加します。
デフォルトの管理対象サーバーでは、次の値を入力します。
名前: wlssm_server1
リスニング・アドレス: WLSSMHOST1
リスニング・ポート: 14610
SSLリスニング・ポート: 14611
2つ目の管理対象サーバーでは、「追加」をクリックして、次の値を入力します。
名前: wlssm_server2
リスニング・アドレス: WLSSMHOST2
リスニング・ポート: 14610
SSLリスニング・ポート: 14611
「クラスタの構成」画面で、「追加」をクリックしてwlssm_cluster
を入力します。「クラスタのメッセージング・モード」に「unicast」を選択し、クラスタ・アドレスをmanaged_ server1:port,managed_server2: portのように入力します。
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタに関連付けます。
右のウィンドウで、クラスタ「wlssm_cluster」
をクリックします。
管理対象サーバー「wlssm_server1」
をクリックしてから、矢印をクリックして、その管理対象サーバーをクラスタに割り当てます。
管理サーバーwlssm_server2
について、前述の手順を繰り返します。
「次へ」をクリックします。
「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。
ホストでUnixオペレーティング・システムを使用する場合は、「Unix」タブを、それ以外の場合は、「マシン」をクリックします。Windowsでは「マシン」タブをクリックし、次に「追加」をクリックして、次のマシンを追加します。
管理サーバー・ホストの場合:
名前: ホストの名前。ここでは、DNS名を使用することをお薦めします。
ノード・マネージャ・リスニング・アドレス: マシンのIPアドレスは、マシンのDNS名と同じにすることをお薦めします。
ノード・マネージャ・リスニング・ポート: ノード・マネージャが使用するポートを入力します。
その他すべての値はデフォルト設定のままにします。
WLSSHOST1およびWLSSMOESHOST2について前述の手順を繰り返し、次の値を入力します。その他すべての値はデフォルト設定のままにします。
名前: ホスト名です。DNS名を使用することをお薦めします。
ノード・マネージャ・リスニング・アドレス: マシンのIPアドレスは、マシンのDNS名と同じにすることをお薦めします。
ノード・マネージャ・リスニング・ポート: ノード・マネージャが使用するポートを入力します。
Unixオペレーティング・システムでは、「マシン」タブの下にあるデフォルト・ローカル・マシンのエントリを削除します。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを割り当てます。次の手順を実行します。
右側のウィンドウでマシンをクリックします。
左側のウィンドウで、そのマシン上で実行する管理対象サーバーをクリックします。
矢印をクリックし、その管理対象サーバーをそのマシンに割り当てます。
すべての管理対象サーバーを適切なマシンに割り当てるまで、この手順を繰り返します。
次のように、サーバーをマシンに割り当てます。
ADMINHOST: 管理サーバー
WLSSMHOST1: wlssm_server1
W:SSMHOST2: wlssm_server2
「次へ」をクリックします。
「構成のサマリー」画面で、「作成」をクリックします。
新しいドメインで./startWeblogic.sh
を使用して、WebLogic管理サーバーを起動します。
管理対象サーバーを起動します。作成したドメイン・ディレクトリのサブフォルダbin
に切り替え、./startManagedWebLogic.sh
管理対象サーバー名 http://wlsadminserver host:wls_adminserver_portを入力します。
例:
./startManagedWeblogic.sh wlssm_server1 http://localhost:7001
packおよびunpackコマンドを使用し、WebLogic Serverセキュリティ・モジュールが使用するドメイン・ディレクトリをOESHOST1の管理対象サーバーが使用するドメイン・ディレクトリから分離します。
OESHOST1で独立ドメイン・ディレクトリを作成する手順は次のとおりです。
次のようにpackコマンドを実行し、テンプレート・パックを作成します。
cd MW_HOME/oracle_common/common/bin
./pack.sh -managed=true -domain=
domain_path -template==domaintemplate.jar -template_name=
domain_template
次のようにunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。
cd MW_HOME/oracle_common/common/bin
./unpack.sh -domain=
new_domain_path -template=domaintemplate.jar
たとえば管理対象サーバー(OESHOST2など)を起動する前に、リモート・ホストでunpackを実行します。
手順1のファイルdomaintemplate.jar
をOESHOST2にコピーします。
次のコマンドを使用して、OESHOST2のホストでunpackを実行します。
cd MW_HOME/oracle_common/common/bin
./unpack.sh -domain=
domain_path -template==domaintemplate.jar
管理対象サーバーの起動後、作成したドメイン・ディレクトリのサブフォルダbin
に切り替えます。./startManagedWebLogic.sh
管理対象サーバー名 http://wlsadminserver host:wls_adminserver_portを入力します。
例:
./startManagedWeblogic.sh wlssm_server2 http://localhost:7001
ポリシー・ストアへの接続は、制御プル・モードおよび非制御モードのOracle Entitlements Serverセキュリティ・モジュールで使用されます。SMConfig UIの制限によって、セキュリティ・モジュール・インスタンスの作成時にJDBCプロパティを構成する必要があります。
RACデータ・ソースをWebLogic Serverセキュリティ・モジュールまたはWebLogic Server上のWebサービスのセキュリティ・モジュールで使用するには、セキュリティ・モジュール・インスタンスの作成後に、次の手順を実行します。
セキュリティ・モジュールがデプロイされているドメインのWebLogic管理コンソールにログインします。Oracle Entitlements Serverの管理サーバーと同じデータベース情報を使用して、RACデータ・ソースを構成します。
SMConfig UIで、セキュリティ・モジュール構成を編集します。
OES_CLIENT_HOME/oes_sm_instances
/SM_Name/bin
を実行します。
Linuxではoessmconfig.sh
、Windowsではoessmconfig.bat
を実行します。
「JNDI名によるデータベース構成」を選択して、* データソースJNDI名フィールドにRACデータ・ソースJNDI名を入力します。「保存して閉じる」をクリックします。
この項では、Oracle Web Tierと連携するためのOracle Entitlements Serverの構成方法について、次の項目について説明します。
次のタスクが実行済であることを確認します。
Oracle Web TierをWEBHOST1とWEBHOST2にインストールしました。
WEBHOST1およびWEBHOST2にOracle HTTP Serverをインストールする手順は、第8.5.3.5.1項「Web Tier用のOracle HTTP Serverのインストール」を参照してください。
Oracle Entitlements Serverを、OESHOST1およびOESHOST2上にインストールし、構成しました。
ロード・バランサをWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(sso
.mycompany.com
)で構成しました。
ロード・バランサをWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(oesinternal
.mycompany.com
)で構成しました。
WEBHOST1とWEBHOST2上の各Webサーバーで、oes.conf
と呼ばれるファイルをORACLE_INSTANCE/config/OHS/component/moduleconf
ディレクトリに作成します。このファイルには次の情報が記載されている必要があります。
NameVirtualHost *:7777 <VirtualHost *:7777> ServerName http://sso.mycompany.com:7777 RewriteEngine On RewriteOptions inherit UseCanonicalName On # OES admin console <Location /apm> SetHandler weblogic-handler WebLogicCluster oeshost1.mycompany.com:14600, oeshost2.mycompany.com:14600 </Location>
このファイルをWEBHOST1とWEBHOST2の両方に保存します。
第8.7項「コンポーネントの起動と停止」の説明に従い、WEBHOST1およびWEBHOST2上のOracle HTTP Serverインスタンスを停止してから起動します。
Oracle HTTP Serverが適切に構成されていることを検証する手順は次のとおりです。
Webブラウザで、Oracle Identity Managerコンソール用の次のURLを入力します。
http://sso.mycompany.com:7777/apm
APMのログイン・ページで、weblogicユーザーの資格証明を使用してログインします。
この項では、Oracle Access Management Mobile and Socialの高可用性フレームワークについて説明します。内容は次のとおりです。
Oracle Access Management Mobile and Social (Mobile and Social)は、既存のIdentity Managementインフラストラクチャをモバイルおよびソーシャル・ネットワークに接続する軽量のセキュリティおよびアイデンティティ・ソリューションです。Mobile and Socialを使用することで、制御されたビューを外側の世界に安全に公開できます。Mobile and Socialでは、ソーシャル・メディアのユーザー・アイデンティティを管理されたエンタープライズ内のエンタープライズ・アプリケーションおよびポータルで使用するためのメカニズムが提供されています。Mobile and Socialは、OAMおよびIGFを含む既存のIDM製品と統合されます。Mobile and Socialの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Management Mobile and Socialに関する説明を参照してください。
図9-23は、Mobile and Socialコンポーネントのアーキテクチャを示しています。
Oracle Access Management Mobile and Socialサービスは、保護されているリソースへのアクセスを必要とするユーザーと、リソースを保護するバックエンドのアクセス管理サービスおよびアイデンティティ管理サービスの間の橋渡しの役割を果たします。Mobile and Socialでは簡易クライアント・ライブラリが提供され、開発者はこれを使用することで、機能豊富な認証、認可およびアイデンティティ機能を登録済アプリケーションに簡単に追加することができます。バックエンドのMobile and Socialサーバーのプラガブルなアーキテクチャにより、システム管理者は、ユーザーがインストールしたソフトウェアをアップデートしなくても、アイデンティティ管理サービスおよびアクセス管理サービスを追加、変更および削除することができます。
モバイル・サービス・コンポーネントでは、セッション情報は記録されません。インターネット・アイデンティティ・サービスでは、短期間のトークンがメモリーに保持され、期限が切れると破棄されます。
Mobile and Socialは、Access Suite J2EEアプリケーション内のコンポーネントです。Mobile and SocialはAccess Suiteの一部としてデプロイおよび構成されるため、インストール、構成、サーバー・インスタンスはAccess Suiteと関連付けられます。
モバイル・サービスおよびインターネット・アイデンティティ・サービスの一部として、Mobile and Socialでは、クライアントで起動するHTTPインタフェースを提供しています。Mobile and Socialは、リクエストを処理してレスポンスを返しますが、クライアントはこれを使用して追加のリクエストを行う場合があります。Mobile and Socialはステートレスであり、クライアントから個別に送信されたすべてのリクエストを処理できます。Mobile and Socialでは、OAMなどの製品や、ソーシャル・ネットワーク認証およびディレクトリ・サーバーを使用したユーザー・プロファイル・サービスを使用した、モバイル・デバイスの登録サービスおよびユーザー認証サービスが提供されます。
Mobile and Socialは、Access Suiteサーバーの起動の一部として起動されます。MBeanサーバーは、Mobile and Socialの構成をロードします。
管理コンソールまたはWLSTコマンドを使用して、構成ファイルを編集します。表9-9に、Mobile and Socialの構成ファイルとその場所を示します。
A Mobile and Socialインストールでは、次のコンポーネントがoam-server.ear
の一部としてデプロイされます。
oic_rest.war
oic_rp.war
表9-10に、Mobile and Socialサービスのデプロイメントの場所を示します。
Mobile and Socialサービスは、モバイル・サービスとインターネット・アイデンティティ・サービスの2つのサブコンポーネントで構成されます。モバイル・サービスでは、認証、ユーザー・プロファイルおよび認可サービス用にRepresentational State Transfer (REST)インタフェースが提供されます。インターネット・アイデンティティ・サービスでは、ソーシャル・ネットワーク認証との統合が提供されます。
Mobile and Socialの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のモバイル・サービスの概要に関する説明を参照してください。
この項では、Mobile and Socialの高可用性アーキテクチャおよびその要素について説明します。内容は次のとおりです。
図9-23は、アクティブ/アクティブ構成で高可用性アーキテクチャにデプロイされたMobile and Socialを示しています。
図9-23は、複数インスタンスのデプロイメントをサポートする標準的なクライアント・サーバー・アーキテクチャを示しています。ほとんどの場合、リクエストはステートレスで、永続性は必要ありません。Mobile and Socialサービスは、OAM/OIDなどの他の製品に依存しており、それらに独自の高可用性機能がある場合があります。状態が保持される場合(インターネット・アイデンティティ認証リクエスト)、高可用性はスティッキーなロード・バランシングを介して実現されます。
セッションのデータベース永続性やランタイム・データがないため、リクエストはどのサーバーにも送信されることができます。ロード・バランサは、Round Robinなどのポリシー・セットに基づいて、リクエストをMobile and Socialサービス1または2に返します。
アプリケーションでインターネット・アイデンティティ・サービスが起動されると、リクエストを処理するために、Google、Facebookまたはインターネット・アイデンティティ・プロバイダに制御が移ります。アイデンティティ・プロバイダからレスポンスが返されるときは、そのリクエストを開始した同じサーバーにレスポンスが返される必要があります。複数のMobile and Socialノード・デプロイメントがあり、アクセスがロード・バランサを介して行われる場合は、Mobile and Socialへのリクエストは、ロード・バランサのスティッキー・セッション機能を使用して同じサーバーに固定される必要があります。IDPへのリクエストを開始したMobile and SocialがIDPレスポンスを受信した後に、Mobile and Socialは、そのリクエストに対してさらに処理を行うことができます。
Mobile and Socialアプリケーションは、クラスタ内のすべてのメンバーにデプロイされます。クラスタでのデプロイ成功時に、Mobile and Socialアプリケーションは他のクラスタ・メンバーに通知はしません。
この項では、ノード障害からの保護を提供するMobile and Socialアーキテクチャの要素について説明します。
ノード・フェイルオーバーが発生した場合、Mobile and Socialは、WebLogic Serverの標準のフェイルオーバー手順に従うことに注意してください。クライアントから受信したリクエストをMobile and Socialで完了する前にノード障害が発生した場合、クライアントは、HTTP接続タイムアウトを介してエラーを受信します。
この項の内容は次のとおりです。
Mobile and Socialコンポーネントは、WebLogic Server 10.3にデプロイされる標準のJ2EEアプリケーションで、ロード・バランシング向けの標準に準拠しています。次のことに注意してください。
Mobile and Social/RPのリクエストではスティッキーなセッション・ルーティングを使用する必要がありますが、外部ロード・バンランサはサポートされています。
コンポーネント間のロード・バランシングはありません。
永続接続がないため、タイムアウト要件はありません。
Mobile and Socialの高可用性アーキテクチャは、フェイルオーバー要件についてはWebLogic Serverの標準のクラスタ・サポートに依存します。このアーキテクチャでは、セッション状態はレプリケートされません。
Mobile and Socialは、Oracle Access Managerと同一の管理対象サーバーの一部です。
Mobile and Socialは個別に、あるいはOAM、STSおよびIdentity Federationなどの別のコンポーネントとともにデプロイできます。
次のMobile and Social構成の前提条件に注意してください。
無効になっている場合は、Mobile and Socialを有効化する必要があります。Oracle Access Managementコンソールにログインし、「システム構成」タブを選択して、「使用可能なサービス」を開き、Mobile and Socialのステータスに緑色のチェックが表示されていることを確認します。
ORACLE_INSTANCE/config/OHS/ohs1/moduleconf
のoam.conf
ファイルに次のマッピングを追加することによって、oic_rest
およびoic_rp
にOHSを構成する必要があります。
<Location /oic_rest> SetHandler weblogic-handler WebLogicCluster oamhost1.mycompany.com:14100,oamhost2.mycompany.com:14100 </Location> <Location /oic_rp> SetHandler weblogic-handler WebLogicCluster oamhost1.mycompany.com:14100,oamhost2.mycompany.com:14100 </Location>
Oracle Privileged Account Managerは、他のどのOracle Identity Managementコンポーネントにも管理されない特権アカウントを管理します。機密データにアクセスできる場合、機密データへのアクセス権限を付与できる場合または機密データへのアクセスとアクセス権限の付与の両方ができる場合に、アカウントは特権とみなされます。
Oracle Privileged Account Managerサーバーは、メタデータの格納にOracle Platform Security Services (OPSS)を使用しますが、その他のデータ・ストアは使用しません。
Oracle Privileged Account Managerの詳細とその機能については、『Oracle Fusion Middleware Oracle Privileged Account Manager管理者ガイド』のOracle Privileged Account Managerの理解に関する説明を参照してください。
この項の内容は次のとおりです。
Oracle Privileged Account Manager (OPAM)は、サーバーおよびWebアプリケーションとして動作するユーザー・インタフェース・コンポーネントで構成されます。OPAMサーバーは、WebLogic管理対象サーバー内で実行されます。OPAMユーザー・インタフェースはOracle Identity Navigator (OIN)の一部で、WebLogic管理サーバー内で実行されます。
OPAMデプロイメントのデフォルトの最も簡単な構成では、WebLogicドメイン内の単一のOPAM管理対象サーバーの実行が必要です。サーバーは、ドメインのOPSSセキュリティ・ストアをデータ・ストアとして使用します。デフォルトのOPSSセキュリティ・ストアの設定では、記憶域にXMLが使用されます。本番マシンでは、OPSSセキュリティ・ストアのバックエンドとしてLDAPまたはDatabaseの使用が推奨されますが、デフォルト構成を動作させるには、XMLストアで十分です。
次の図は、Oracle Privileged Account Managerのアーキテクチャとトポロジを示しています。
図9-24 Oracle Privileged Account Managerコンポーネント・アーキテクチャ
このアーキテクチャでは、次の点に注意してください。
Oracle Privileged Account Managerのコア・ロジックはすべてOracle Privileged Account Managerサーバーに存在します。この機能は、Representational State Transfer (RESTまたはRESTful)サービスを介して公開されますが、データはJavaScript Object Notation (JSON)でエンコードされます。
注意: Oracle Privileged Account Managerでは、Oracle Identity NavigatorのWebベースのユーザー・インタフェースおよびOracle Privileged Account Managerコマンドライン・ツールが提供されます。どちらのインタフェースも基本的に、Oracle Privileged Account Managerサーバーのクライアントです。 ただし、サードパーティはオープンなRESTfulサービスを利用することで、カスタム・アプリケーションなどの独自のクライアントに書き込むことができます。詳細は、『Oracle Fusion Middleware Oracle Privileged Account Manager管理者ガイド』のOracle Privileged Account ManagerのRESTfulインタフェースの使用に関する説明を参照してください。 |
Oracle Privileged Account Managerの認証は、WebLogicのJava Authentication & Authorization Service (JAAS)サポートに依存します。WebLogicでのJAASサポートの詳細は、Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティの理解のWebLogicセキュリティ・サービス・アーキテクチャに関する説明を参照してください。
Oracle Privileged Account Manager関連のコンポーネントとの、およびコンポーネント間のすべての通信(Oracle Privileged Account ManagerのWebベースのユーザ・インタフェース、コマンドライン・インタフェースおよびサーバーを含む)は、すべてSSL経由で行われます。
Oracle Privileged Account Managerは、Oracle Privileged Account ManagerがデプロイされているWebLogicドメインに構成されているIDストア、ポリシー・ストアおよび資格証明ストアに依存し、透過的に使用します。
Oracle Privileged Account Managerの実行時に必要となるすべてのパスワード(ターゲット・システムへのパスワード、アカウントの一時パスワードなど)は、資格証明ストア・フレームワークを介して資格証明ストアに格納されます。
詳細は、『Oracle Fusion Middleware Oracle Privileged Account Manager管理者ガイド』のDeployed in Oracle Fusion MiddlewareでのOracle Privileged Account Managerのデプロイに関する説明を参照してください。
Oracle Privileged Account ManagerのWebベースのユーザー・インタフェースは、Oracle Application Development Framework (ADF)を利用して、表示されます。ADFの詳細は、次のWebサイトを参照してください。
http://www.oracle.com/technetwork/developer-tools/adf/overview/index.html
Oracle Privileged Account Managerは、Identity Connector Framework (ICF)コネクタを使用してターゲットに接続します。詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のIdentity Connector Frameworkの理解に関する説明を参照してください。
この項の内容は次のとおりです。
OPAMサーバーは、WebLogic管理対象サーバーを実行するサーバー・コンポーネントです。OPAMユーザー・インタフェースは、WebLogic管理サーバーで実行されるコンポーネントです。OPAMサーバーは、OPAM GUIおよびコマンドライン・クライアントを含むクライアントとの通信に、RESTプロトコルを使用します。OPAMサーバーは、OPSSセキュリティ・ストアをデータ・ストアとして使用します。OPAMサーバーは、複数のサーバーがあるWebLogicクラスタにデプロイでき、WebLogicコンソールを使用して処理を管理します。
OPAMサーバーは、WebLogic ServerにデプロイされるJ2EEアプリケーションです。
起動時に、OPAM Lifecycle Listenerは、キーストアがそのドメインに存在するかどうかを確認します。
キーストアが存在しない場合は、OPAM Lifecycle Listenerは、ランダムに生成されたキーストアのパスワードを使用してキーストアを作成し、ドメイン名を別名としたキーストア・エントリを作成し、そのキーストア・パスワードを使用してCSFを更新します。
キーストアが存在する場合は、CSFからキーストア・パスワードを取得して、ドメイン名を別名とするエントリが存在するかどうかを確認します。
キーストアおよび目的のキーストアのCSFエントリが存在する場合は操作を行わないため、OPAMの高可用性環境はプロセスのライフサイクルに影響しません。
OPAMはサーブレット・モデルを使用し、クライアントは、RESTベースのHTTPS URLを使用して処理されます。
コンポーネントのライフサイクルは、その他の実行中のインスタンスに影響しません。
CSFの詳細は、『Oracle Fusion Middleware Oracle Privileged Account Manager管理者ガイド』のOracle Privileged Account Manager管理対象CSF資格証明に関する説明を参照してください。
OPAMサーバーは、RESTベースの通信を使用して、クライアントとの通信ではHTTP URLを使用します。セッションの状態情報は保存されません。各通信で操作を完了すると、セッションは保持されません。
OPAMサーバーの依存性の内容は次のとおりです。
OPSSセキュリティ・ストア、データ格納用
ICFコネクタ、ターゲット・システムとの通信用
外部IDストア、認証用(WebLogicで構成可能)
OPAMユーザー・インタフェースおよびOPAMコマンドライン・ツールはOPAMサーバーに依存します。HTTPS URLを使用するRESTであるクライアント接続は短期です。
OPAMを管理対象サーバーにデプロイした場合、Oracle Identity Navigatorは管理サーバーにデプロイされます。Oracle JRFは、管理サーバーと管理対象サーバーの両方にデプロイされます。表9-11は、OPAM製品アーティファクトのデプロイ先を示します。
WebLogic Serverのログおよび監査ログは、DOMAIN_HOMEに保存されます。
監査ログがWebLogicに構成されている場合は、監査データベースに保存されます。
クラスタ・レベルで、Connectorディレクトリ、時間制限などのOPAMプロパティを変更できます。
すべてのサーバーは、構成が保持されている共通ドメインのOPSSデータ・ストアに接続します。したがって、すべてのサーバーは共有データを取得します。
図9-25は、アクティブ/アクティブ構成で高可用性アーキテクチャにデプロイされたOracle Privileged Account Managerを示しています。
図9-25 高可用性アーキテクチャのOracle Privileged Account Manager
図9-25に示す構成では、Oracle Privileged Account Managerの各サーバーは、同じドメインの一部であり、同じOPSSセキュリティ・ストアを使用します。複数のサーバーがOPSSセキュリティ・ストアと対話するため、データベースをOPSSバックエンドとして使用することをお薦めします。
このクラスタ構成では、クラスタ内の別のサーバーから同じデータを使用できます。各管理対象サーバーには独自のポート構成があります。図9-25の構成には、ロード・バランサが含まれています。
OPAMHOST1には、次のインストールがあります。
WLS_OPAM1管理対象サーバーのOracle Privileged Account Managerインスタンス。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
WebLogic Serverの管理サーバー。通常の運用時は、これがアクティブ管理サーバーになります。
OPAMHOST2には、次のインストールがあります。
WLS_OPAM2管理対象サーバーのOracle Privileged Account Manager。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
WLS_OPAM2管理対象サーバーにあるインスタンスと、WLS_OPAM1管理対象サーバーにあるインスタンスは、CLUSTER_OPAMクラスタとして構成されています。
WebLogic Serverの管理サーバー。通常の運用時は、これがパッシブ管理サーバーになります。HOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。
デフォルトでは、WebLogic Serverによって、このアプリケーションに対するライフサイクル・イベントの起動、停止、監視および管理が行われます。Oracle Privileged Account Managerアプリケーションは、基盤となるOracle WebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。
高可用性環境では、WebLogicノード・マネージャはWebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。
高可用性環境では、状態情報と構成情報は、クラスタ内のすべてのメンバーが共有するデータベースに格納されます。
高可用性構成でのOracle Privileged Account Managerのノード障害には、次の特性があります。
ノード障害はクライアントに影響しません。
サーバーに障害が発生した場合、実行中のRESTベースの操作は停止しますが、フェイルオーバーされません。クライアントは使用可能なサーバーに接続して、リクエストをリトライまたは継続できます。デプロイメントにロード・バランスが含まれている場合は、リクエストは使用可能なサーバーに送信されます。
この項では、Oracle Privileged Account Managerの高可用性で最大限の高可用性を得るためのデプロイメントを設定する高度な手順について説明します。この項では、次の項目について説明します。
新しいWebLogicドメインにOracle Identity NavigatorとともにOracle Privileged Account Managerを構成し、その後Oracle Identity Navigatorの検出機能を実行する場合、この項の構成を実行してください。この機能は、Oracle Identity Manager、Oracle Access Management、Oracle Adaptive Access ManagerおよびOracle Privileged Account Managerの製品コンソールへのリンクを移入します。これにより、個々の製品コンソールURLを覚えていなくても、Oracle Identity Navigatorインタフェースからこれらの製品コンソールにアクセスできます。
この項の構成を実行することで、Oracle Privileged Account ManagerおよびOracle Identity Navigatorアプリケーションが新しいWebLogic管理サーバーにデプロイされます。
この項の構成は、次のものに依存しています。
Oracle WebLogic Server
Oracle Identity and Access Management 11gソフトウェアのインストール
詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Identity and Access Management (11.1.2.0.0)のインストールと構成に関する説明を参照してください。
この項の手順は次のとおりです。
Oracle Privileged Account ManagerおよびOracle Identity Navigatorの高可用性を最大化するように構成するには、次の手順を実行します。
Oracle WebLogic Serverをインストールし、Middlewareホームを作成します。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のWebLogic ServerおよびMiddlewareホームの要件に関する説明を参照してください。
Oracle Identity and Access Management 11gソフトウェアをインストールします。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Identity and Access Management (11.1.2.0.0)のインストールに関する説明を参照してください。
<IAM_Home>/common/bin/config.sh
スクリプトを実行します(Windowsでは<IAM_Home>\common\bin\config.cmd
)。Oracle Fusion Middleware構成ウィザードの「ようこそ」画面が表示されます。
注意: ここでは例として、 |
「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。「ドメイン・ソースの選択」画面が表示されます。
「ドメイン・ソースの選択」画面で、「次の製品をサポートするために、自動的に構成されたドメインを生成する」オプションが選択されていることを確認します。「Oracle Privileged Account Manager - 11.1.2.0.0 [IAM_Home]」を選択します。
注意: 「Oracle Privileged Account Manager - 11.1.2.0.0 [IAM_Home]」オプションを選択すると、「Oracle Identity Navigator」および「Oracle JRF」オプションもデフォルトで選択されます。 |
「次へ」をクリックします。「ドメイン名と場所の指定」画面が表示されます。
ドメイン名IDM_Domainを入力します。「ドメインの場所」および「アプリケーション・ディレクトリ」は、デフォルトのままにします。「次へ」をクリックします。「管理者ユーザー名およびパスワードの構成」画面が表示されます。
管理者のユーザー名とパスワードを構成します。デフォルトのユーザー名はweblogicです。「次へ」をクリックします。
Oracle Fusion Middleware構成ウィザードの「サーバーの起動モードおよびJDKの構成」画面で、JRockit SDK 1.6.0_
<version>と「本番モード」を選択します。
「JDBCコンポーネント・スキーマの構成」画面で、OPAMスキーマおよびOPSSスキーマのデータベース・スキーマの詳細を入力します。
(オプション)コンポーネント・スキーマのRAC構成に関するオプションを選択します。
「次へ」をクリックします。
「コンポーネント・スキーマのテスト」画面で、構成ウィザードによりデータ・ソースの検証が試行されます。すべてのスキーマに対するテストが正常に完了したことを確認します。
データ・ソースの検証が成功した場合、「次へ」をクリックします。
データ・ソースの検証に失敗した場合は、「前へ」をクリックして問題を修正し、もう一度実行します。
「オプション構成の選択」画面で、「管理サーバー」および「管理対象サーバー、クラスタ、およびマシン」、「デプロイメントとサービス」を選択します。「次」をクリックします。
「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: OPAMHOST1.mycompany.com
リスニング・ポート: 7001
次のパラメータは設定または変更しないでください。
SSLリスニング・ポート: 適用なし
SSL有効または無効
「次へ」をクリックします。
「管理対象サーバーの構成」画面で、トポロジのOPAMHOSTごとにエントリを作成しますが、つまり、OPAMHOST1上で実行されている OPAMサーバーに対して1つと、OPAMHOST2上で実行されているOPAMサーバーに対して1つ作成します。
OPAM_SERVERエントリを選択し、そのエントリを次の値に変更します。
名前: opamserver1
リスニング・アドレス: OPAMHOST1
.mycompany.com
リスニング・ポート: 18101
SSLポート: 18102
2つ目のOPAM_SERVERでは、「追加」をクリックして、次の値を入力します。
名前: opam_server2
リスニング・アドレス: OPAMHOST2
.mycompany.com
リスニング・ポート: 18101
SSLポート: 18102
「次へ」をクリックします。
「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成します。
名前OPAM_Cluster
を入力します。その他すべてのフィールドはデフォルト設定のままにします。
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタに関連付けます。
右のウィンドウで、クラスタ名「OPAM_Cluster」をクリックします。
管理対象サーバー「opam_server1」をクリックしてから、矢印をクリックして、その管理対象サーバーをクラスタに割り当てます。
管理サーバーopam_server2について、前述の手順を繰り返します。
「次へ」をクリックします。
「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。
ホストでUnixオペレーティング・システムを使用する場合は、「Unix」タブを、それ以外の場合は、「マシン」をクリックします。
次の情報を指定します。
名前: ホスト名です。ここでは、DNS名を使用することをお薦めします。
ノード・マネージャ・リスニング・アドレス: ここにマシンのDNS名を入力します。
ノード・マネージャ・ポート: ノード・マネージャが使用するポートを入力します。
OPAMHOST2について前述の手順を繰り返し、次の値を入力します。
名前: ホスト名です。DNS名OPAMHOST2
を使用することをお薦めします。
ノード・マネージャ・リスニング・アドレス: マシンのDNS名OPAMHOST.mycompany.com
を入力します。
ノード・マネージャ・ポート: ノード・マネージャが使用するポートを入力します。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを割り当てます。次の手順を実行します。
右側のウィンドウでマシンをクリックします。
左側のウィンドウで、そのマシン上で実行する管理対象サーバーをクリックします。
矢印をクリックし、その管理対象サーバーをそのマシンに割り当てます。
すべての管理対象サーバーが適切なマシンに割り当てられるまで、この手順を繰り返します。
例:
ホスト1: 管理サーバー、OPAMHOST1およびopam_server1
ホスト2: OPAMHOST2およびopam_server2
「次へ」をクリックします。
「構成のサマリー」画面で、「作成」をクリックします。
ドメインの構成後、管理サーバーを起動する前に、データベース・セキュリティ・ストアを構成する必要があります。詳細は、第9.1.3.3項「ドメイン用のデータベース・セキュリティ・ストアの構成」を参照してください。
管理サーバーを起動するには、次の手順を実行します。
DOMAIN_HOME/bin
ディレクトリに移動します。startWeblogic.sh
を実行します。
プロンプトで、WebLogic管理者のユーザー名とパスワードを入力します。
注意: 次の手順は、管理サーバーを最初に起動したときのみに実行します。 |
管理サーバーが起動したら、ORACLE_HOME/opam/bin
ディレクトリに移動します。opam-config.sh
を実行します。
注意: このスクリプトを実行する前に、 |
プロンプトで、WebLogicのユーザー名、パスワード、URL、ドメイン・ホームおよびMiddlewareホームを入力します。
opam-config.sh
が正常に実行されたら、管理サーバーを再起動します。
この項では、OPAMHOST1の起動手順について説明します。
コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。MW_HOME/oracle_common/common/bin
ディレクトリにあるsetNMProps.sh
スクリプトを実行します。
MW_HOME/oracle_common/common/bin/setNMProps.sh
コマンドMW_HOME/wlserver_10.3/server/bin/startNodeManager.sh
を使用して、ノード・マネージャを起動します。
OPAMHOST1上のOracle Privileged Account Managerを起動する手順は、次のとおりです。
次のURLを使用して、WebLogic管理コンソールにログインします。
http://opamhost1.mycompany.com:7001/console
WebLogic管理者のユーザー名とパスワードを入力します。
「ドメイン構造」メニューで「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
サーバー「opam_server1」をクリックします。
「起動」をクリックします。
「OK」をクリックします。
OPAMHOST1で構成を完了したら、それをOPAMHOST2に伝播できます。これを実行するには、OPAMHOST1でpackスクリプトを使用してドメインをパックし、OPAMHOST2でunpackスクリプトを使用してドメインを解凍します。
どちらのスクリプトも、MW_HOME/oracle_common/common/bin
ディレクトリにあります。
MW_HOME
およびORACLE_HOME
ディレクトリ構造がOPAMHOST1
ディレクトリ構造と同じであることを確認します。
OPAMHOST1で次のように入力して、/tmp
ディレクトリにファイルidm_domain.jar
を作成します。
pack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain
-template=/tmp/idm_domain.jar -template_name="OPAM Domain" -managed=true
idm_domain.jar
をOPAMHOST2にコピーするには、次のように入力します。
unpack.sh -domain=MW_HOME/user_projects/domains/IDM_Domain -template=/tmp/idm_domain.jar Copy jps-wls-trustprovider.jar from MW_HOME/oracle_common/modules/oracle.jps_11.1.1 to WLS_SERVER_HOME/server/lib/mbeantypes
この項では、OPAMHOST2の起動手順について説明します。
コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。ディレクトリMW_HOME/oracle_common/common/bin
にあるスクリプトsetNMProps.sh
を実行します。
コマンドMW_HOME/wlserver_10.3/server/bin/startNodeManager.sh
を使用して、ノード・マネージャを起動します。
OPAMHOST2でOracle Privileged Account Managerを起動します。第9.8.5.4.5項「OPAMHOST1でのOracle Privileged Account Managerの起動」を参照して、HOST1とserver1をHOST2とserver2に置き換えます。
Oracle HTTP Server (OHS)を使用してOPAMサーバーをロード・バランシングできます。OPAMサーバーでは通信にSSLを使用するため、OHSロード・バランサでSSLオプションを構成する必要があります。次の手順を実行します。
OPAMの管理対象サーバーおよび管理サーバーと通信できるように、OHSからのアウトバウンドSSL接続を有効化します。これを行うには、『Oracle Fusion Middleware管理者ガイド』のOracle HTTP Serverからのアウトバウンド・リクエストでのSSLの有効化に関する説明を参照してください。
OPAMの管理対象サーバーおよび管理サーバーへのSSL接続を有効化します。『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic ServerへのインバンドSSLに関する説明を参照してください。
Oracle Identity Management Navigatorは、Oracle Identity Management製品のスタート地点として機能するよう設計されている管理ポータルです。これは、個々の製品コンソールに代わるものではありません。1つのサイトからOracle Identity Managementの各コンソールにアクセスできるようにするためのものです。Oracle Identity Management Navigatorの詳細は、Oracle Fusion Middleware Oracle Identity Navigator管理者ガイドを参照してください。
Oracle Identity Navigatorは、WebLogic管理サーバーJVMにデプロイされるため、高可用性アクティブ/アクティブ・デプロイメントでは使用されません。
高可用性アクティブ/パッシブ・コールド・フェイルオーバー・クラスタでOracle Identity Navigatorを使用するには、第12.2.2.3項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」のアクティブ/パッシブ・コールド・フェイルオーバー・クラスタでのWebLogic Serverの設定手順に従います。
脚注の説明文
脚注 1: 使用されるエージェントはデプロイメント固有であり、デプロイメントによって(異なる機能を持つ)様々なタイプのエージェントを使用できます。