プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Identity and Access Management高可用性ガイド
11g リリース2 (11.1.2.3)
E61957-01
  目次へ移動
目次
前
前 		 次
次		  

6 Oracle Access Management Access Managerコンポーネントの高可用性の構成

この章では、Oracle Access Management Access Manager (Access Manager)の概要、およびAccess Managerの高可用性環境の設計およびデプロイ方法について説明します。

Access Managerによって、すべての認証および認可サービスの一元的な提供が可能になります。詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Management Access Managerの概要に関する説明を参照してください。

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

6.1 Access Managerコンポーネント・アーキテクチャ

図6-1は、Access Managerコンポーネントのアーキテクチャを示しています。

図6-1 Access Managerの単一インスタンス・アーキテクチャ

図6-1の説明が続きます
「図6-1 Access Managerの単一インスタンス・アーキテクチャ」の説明

図6-1は、次のコンポーネントを示しています。

  • ユーザー・エージェント: Webブラウザ、Javaアプリケーション、およびWebサービス・アプリケーションが含まれます。ユーザー・エージェントは、HTTPを使用してアクセス・サーバーと管理および構成ツールにアクセスします。

  • 保護されたリソース: アクセスが制限されたアプリケーションまたはWebページのことです。WebGateまたはカスタム・エージェントは、保護されたリソースへのアクセスを制御します。

  • 管理および構成ツール: Oracle Access Managementコンソール、Oracle Enterprise Manager Fusion Middleware ControlとOracle Enterprise Manager Grid Control、およびWebLogic Scripting Tool (WLST)を使用してAccess Managerを管理および構成します。

  • アクセス・サーバー: 資格証明コレクタ、OSSOプロキシおよびOAMプロキシ・コンポーネントが含まれます。Coherence分散オブジェクト・キャッシュを使用して、アクセス・サーバー間で構成ファイルの変更を伝播します。

6.1.1 Access Managerコンポーネントの特性

Access Managerデプロイメントは、次のシステム・エンティティで構成されます。

  • Access Managerエージェント - アクセスを保証するAccess Server拡張機能は、アクセス・サーバーが管理するポリシーに従って制御されます。エージェントがその機能を実行するには、アクセス・サーバー・コンポーネントが必要です。アクセス・サーバーが使用できない場合、保護されるサーバーへのアクセスは拒否され、ユーザーはシステムからロックアウトされます。

  • 保護されたリソース(パートナ・アプリケーション) - Access Managerが保護するアプリケーション。これらのリソースへのアクセスは、Access Managerのアクセス制御ポリシーに依存し、保護されたリソースのアクセス・パスにデプロイされたAccess Managerエージェントによって強制されます。

  • アクセス・サーバー - サーバー側コンポーネント。コア・ランタイム・アクセス管理サービスを提供します。

  • JMX Mbean: ランタイムMBeanは、アクセス・サーバー・パッケージの一部としてパッケージ化されています。構成Mbeanは、スタンドアロンWARファイルとしてパッケージ化されています。

  • WebLogic 11g SSPIプロバイダは、Access Java Access JDKとともにSSPIインタフェースを実現するJavaクラスで構成されています。AccessGateは、Pure Java Access JDKを使用して構築されています。

  • Oracle Access Managementコンソール: 管理コンソールをホストするアプリケーションであり、Access Managerデプロイメントを管理するためのサービスを提供します。

  • WebLogic Scripting Tool: アクセス・サーバー・パッケージに含まれているJavaクラス。Access Managerデプロイメントの管理の一部は、コマンド行からサポートされます。

  • Fusion Middleware ControlおよびEnterprise Manager Grid Control: Access Managerは、Enterprise Manager Grid Controlと統合し、パフォーマンス・メトリックとデプロイメント・トポロジを表示します。

  • Coherence分散オブジェクト・キャッシュ: Access Managerコンポーネントは、このインフラストラクチャに依存して、変更をリアルタイムに伝播します。

  • Access Managerプロキシ - Apache MINAサーバーのカスタム・バージョン。Java Serverクラスに加えてMessageDrivenBeansおよびResourceAdaptersを含めます。

  • Oracle Single Sign-On (OSSO)プロキシは、アクセス・サーバー・パッケージに含まれているJavaクラスで構成されています。

  • データ・リポジトリ: Access Managerは、アイデンティティ、ポリシー、パートナ、セッション、一時データを含む様々なタイプの情報を処理します。

    • アイデンティティ・データ用LDAP

    • 構成およびパートナ・データ用ファイル

    • セッションおよび一時データ用Coherenceインメモリー

    • ポリシー・データはファイルまたはRDBMSに格納されます

  • Oracle Access Manager WebGateは、Webサーバーにデプロイすることを意図したCベースのエージェントです。

  • Oracle Single Sign-On Apacheモジュールは、Oracle HTTP Server Webサーバーにデプロイすることを意図したCベースのエージェントです。

6.1.2 Access Managerの構成アーティファクト

Access Managerの構成アーティファクトには、次が含まれています。

表6-1 Access Managerの構成アーティファクト

構成アーティファクト 説明

DOMAIN_HOME/config/fmwconfig/oam-config.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がアイデンティティ・ストア、データベースおよびその他のエンティティへの接続に使用するパスワードを格納します。これは、エンド・ユーザー用のパスワードではありません。

6.1.3 Access Managerの外部依存性

次の表に、Access Managerの外部ランタイム依存性を示します。

表6-2 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(OAAM)

OAAMの拡張認証スキームが選択されている場合の依存性

Identity Federation

Identity Federationの認証スキームが選択されている場合の依存性

LDAPベースのアイデンティティ・ストア

  • ユーザー・アイデンティティ・リポジトリ

  • ユーザー/ロールAPIによって抽象化されるLDAPアクセス

    Access Managerは、常に1つのアイデンティティ・ストア(物理サーバーまたはロード・バランサIP)に接続します。プライマリが停止した場合、Access Managerはロード・バランサに再接続し、ロード・バランサによってセカンダリに接続します。

OCSPレスポンダ・サービス

リアルタイムX.509認証検証

6.1.3.1 Access Managerのログ・ファイルの場所

Access ManagerはWebLogic Server上にデプロイします。そのデプロイ先のWebLogic Serverのサーバー・ログ・ファイルに、ログ・メッセージは記録されます。デフォルトのサーバー・ログの場所は次のとおりです。

WL_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

6.2 Access Managerの高可用性の概要

この項では、Access Managerを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。

6.2.1 Access Managerの高可用性アーキテクチャ

図6-2は、Access Managerの高可用性アーキテクチャを示しています。

図6-2 Access Managerの高可用性アーキテクチャ

図6-2の説明が続きます
「図6-2 Access Managerの高可用性アーキテクチャ」の説明

図6-2では、ハードウェア・ロード・バランサが着信認証リクエストを受信し、そのリクエストを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アプリケーションをホストする管理対象サーバーをデプロイします。これらの管理対象サーバーは、アクセス・サーバーがアクティブ/アクティブ的に動作できるように、クラスタにおいて構成されます。

管理サーバーはOAMHOST1上で実行され、WebLogic管理コンソール、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Access Managementコンソールをデプロイします。

ディレクトリ層で、仮想IP ovd.example.comは、Oracle Virtual DirectoryリクエストをOVDHOST1とOVDHOST2にルーティングします。OVDHOST1とOVDHOST2は、アクティブ/アクティブのOracle Virtual Directoryクラスタを構成します。仮想IP oid.example.comは、Oracle Internet DirectoryリクエストをOIDHOST1とOIDHOST2にルーティングするように設定されます。OIDHOST1とOIDHOST2は、アクティブ/アクティブのOracle Internet Directoryクラスタを構成します。

Oracle RACデータベースは、データ層における高可用性を提供します。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソースまたはGridLinkデータ・ソース内に構成されています。

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ポリシー・エンジンのブートストラップの後、データベースが到達不能でも、Access Managerインスタンスは再起動でき、OAMポリシー・エンジンはそのローカルにキャッシュされたポリシーに対して処理を継続します。

  • Access Managerポリシー管理インタフェース(Oracle Access ManagementコンソールおよびCLIツール内)は、OAMポリシー・エンジン管理サービス・インタフェースからみてデータベースが到達不能である場合に失敗します。操作は後で再試行できますが、管理操作に対して自動化された再試行は提供されていません。

  • データベース・リポジトリでポリシーが変更されると、OAMサーバー・ランタイムのOAMポリシー・エンジン・レイヤーが、(Access Managerの構成で構成される)構成可能なOAMポリシー・エンジン・データベース・ポーリング間隔内でその変更を取得し、アクティブ化します。ポリシー変更の肯定応答を、各OAMサーバー・ランタイムから受信する必要がありますが、それ以外の場合は、そのポリシー変更はアクティブ化に成功したとみなされません。管理者は、Oracle Access Managementコンソールを使用して、サービスから、ポリシー・アクティブ化が失敗したAccess Managerインスタンスを削除できます。

6.2.2 障害からの保護および予想される動作

WebLogic Serverインフラストラクチャにより、Identity Managementサービス・インフラストラクチャ・システムは、あらゆるプロセス障害から保護されます。また、次の機能もAccess Managerの高可用性構成を障害から保護します

  • バック・チャネルOAPバインディングでは、フェイルオーバーのためにプライマリ/セカンダリ・モデルが使用されます。フロント・チャネルHTTPバインディングでは、フェイルオーバーのためにロード・バランシング・ルーターが使用されます。

  • セッションの状態は、Coherence分散オブジェクト・キャッシュで保持され、それは、すべてのセッションの状態情報についてレプリケーションとフェイルオーバーを提供します。Coherenceキャッシュに格納されたデータは、データベースに非同期的に書き込まれます。このデータは、すべてのアクセス・サーバーが再起動されても保持されます。ただし、書込みの非同期的な性質により少量のデータが失われる可能性があります。

  • アクセス・サーバーで障害が発生した場合、そのサーバーへの永続接続を持つWebGateは、接続がタイムアウトするまで待機し、その後にセカンダリ(バックアップ)アクセス・サーバーに切り替えます。未処理のリクエストは、セカンダリ・サーバーにフェイルオーバーされます。

  • Access Manager Access Serverは、ハートビート・チェックをサポートしています。また、管理対象サーバー上のWebLogicノード・マネージャは、アプリケーションを監視して、そのアプリケーションを再起動できます。

  • WebLogic Serverノードに障害が発生すると、構成、再試行のタイムアウトおよび再試行の回数に基づいて外部接続のフェイルオーバーが行われます。Access Managerエージェントとアクセス・サーバーのフェイルオーバーはタイムアウトに基づいています。

  • ロード・バランシング・ルーターまたはプロキシ・サーバーがWebLogic Serverノードの障害を検出した場合、後続のクライアント接続は、アクティブ・インスタンスにルーティングされ、そのセッション状態を取得して処理を継続します。

  • 接続の存続時間が期限切れした場合、保留中のリクエストは接続が終了する前に完了します。接続オブジェクトはプールに戻されます。

  • 別のサービスから例外を受信した場合、Access Managerは、外部接続リクエストを再試行します。再試行回数は設定が可能です。

6.2.2.1 WebLogic Serverのクラッシュ

管理対象サーバーで障害が発生すると、ノード・マネージャはこのサーバーの再起動をローカルで試行します

Oracle HTTP Serverからの処理中のリクエストはタイムアウトして、新しいリクエストは他の管理対象サーバーに送られます。障害が発生したノードでサーバーが正常に再起動されると、Oracle HTTP Serverは、受信したリクエストのサーバーへのルーティングを再開します。


注意:

Access Managerサーバーは、アクセス・サーバーがそのリクエストにサービスを提供できるかどうかを判別するため、ハートビート・チェックをサポートします。次のチェックを行います。

  • LDAPストアにアクセスできるかどうか。

  • ポリシー・ストアにアクセスできるかどうか。

ハートビート・チェックに成功した場合、アクセス・サーバーはリクエストの処理が可能であり、リクエストがそれに送信されます。ハートビート・チェックで問題がある場合、リクエストはアクセス・サーバーにルーティングされません。

6.2.2.2 ノード障害

ノード障害は、WebLogic Serverの障害と同じ方法で処理されます。

6.2.2.3 データベース障害

Access Managerサービス・インフラストラクチャは、マルチ・データ・ソースにより障害から保護されます。Oracle RACデータベース・インスタンスで障害が発生した場合に、使用可能なデータベース・インスタンスとの接続が再確立されます。マルチ・データ・ソースを使用すると、Oracle RACデータベース内の複数のインスタンスへの接続を構成できます。

マルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

6.3 高可用性のディレクトリ構造の前提条件

高可用性デプロイメントでは、製品インストールとファイルが特定のディレクトリに存在する必要があります。標準のディレクトリ構造を用いることで、ノード全体の構成および製品の統合が容易になります。

次の表に、高可用性のディレクトリ構造の前提条件を示します。

表6-3 ディレクトリ構造の前提条件

ディレクトリ 要件

MW_HOME

製品ごとに独自のMW_HOMEが必要です。たとえば、OAMとOIMは別々のMW_HOMEに配置される必要があります。

MW_HOMEの内容は、すべてのノードで同一であることが必要です。すべてのノードで、MW_HOMEが次の条件を満たしている必要があります。

  • ファイル・システム内に同じパスで存在すること

  • 同一の製品が格納されていること

  • 該当する製品の同一バージョンが格納されていること

  • ORACLE_HOME名が同一であること

  • 同一のパスがインストールされていること

DOMAIN_HOMEおよびAPPLICATION_DIRECTORY

これらのディレクトリのパスは、すべてのノードで同じにする必要があります。

これらのディレクトリは、MW_HOMEとは別のファイル・システムの場所に配置してください。MW_HOME/user_projectsディレクトリには配置しないでください

wlsserver_10.n

OAMおよびOIMのインストールごとに、別々のWebLogic Serverインストールが必要です。

インストール・ディレクトリの説明は、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』のインストール・ディレクトリの特定に関する項を参照してください。

高可用性のディレクトリ構造の設定には、次の3つのオプションがあります。

  • 共有記憶域を使用してMW_HOMEディレクトリを格納する方法。これが推奨されるオプションです。NASによってエクスポートされたNFS、またはSAN/NASを指しているクラスタ・ファイル・システムを使用します。

  • ローカル記憶域を使用し、1つのノード上でインストール、アップグレードおよびパッチ適用手順のすべてを実行してから、他のノードにレプリケートする方法(rsyncなどを使用)。

  • ローカル記憶域を使用し、各ノード上でインストールおよびパッチ適用手順のすべてを繰り返す方法。

6.4 Access Managerの高可用性の構成手順

この項では、Access Managerで高可用性を得るためのデプロイメントを設定する高度な手順について説明します。このデプロイメントには、2つのOracle HTTP Serverが含まれており、それらは、リクエストを2つのOAMサーバーに配布します。これらのOAMサーバーは、Oracle Real Application Clusters (Oracle RAC)データベースおよび、(オプションで)外部LDAPストアと対話します。1つのコンポーネントで障害が発生しても、残りのコンポーネントは引き続き機能します。

この項には次のトピックが含まれます:

6.4.1 Access Managerの構成の前提条件

Access Managerを高可用性のために構成する前に、次の操作を実行しておく必要があります。

6.4.2 リポジトリ作成ユーティリティの実行によるデータベース・スキーマの作成

作成するスキーマは、インストールおよび構成する製品により異なります。インストールする製品と互換性のあるバージョンのリポジトリ作成ユーティリティ(RCU)を使用します。RCU実行の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・プランニング・ガイド』および『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

6.4.3 Oracle WebLogic Serverのインストール

Oracle WebLogic Serverをインストールするには、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。


注意:

64ビットのプラットフォームで汎用jarファイルを使用してOracle WebLogic Serverをインストールすると、JDKはOracle WebLogic Serverと同時にインストールされません。Oracle WebLogic Serverをインストールする前に、JDKを個別にインストールする必要があります。

6.4.4 Access Manager Application Tierのインストールと構成

『Oracle Identity and Access Managementインストレーション・ガイド』の「Identity and Access Managementのインストールおよび構成」を参照してください。

6.4.5 データベース・セキュリティ・ストアの構成

ドメインの構成後、管理サーバーを起動する前に、データベース・セキュリティ・ストアを構成する必要があります。詳細は、『Oracle Identity and Access Managementインストレーション・ガイド』のOracle Identity and Access Managementドメインのデータベース・セキュリティ・ストアの構成に関する項を参照してください。

6.4.6 OAMHOST1での管理サーバー用boot.propertiesの作成

boot.propertiesファイルを使用すると、administratorのユーザー名とパスワードの入力を求められることなく管理サーバーを起動できます。

boot.propertiesファイルを作成する手順は次のとおりです。

  1. OAMHOST1で、次に移動します。

    MW_HOME/user_projects/domains/domainName/servers/AdminServer/security

    例:

    cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security

  2. テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をこのファイルに入力します。

    username=adminUser
password=adminUserPassword

    注意:

    管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、できるだけ速やかにサーバーを起動してエントリを暗号化します。

  3. 管理サーバーが実行されている場合は停止します。

    WebLogicサーバーの起動と停止は、『管理者ガイド』のOracle Fusion Middlewareの起動と停止に関する項を参照してください。

  4. MW_HOME/user_projects/domains/domainName/binディレクトリにあるstartWebLogic.shスクリプトを使用して、OAMHOST1の管理サーバーを起動します。

  5. 変更に成功したことを確認します。ブラウザを開き、weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。

    • WebLogic Server管理コンソール:

      http://oamhost1.example.com:7001/console

    • Oracle Enterprise Manager Fusion Middleware Control:

      http://oamhost1.example.com:7001/em

6.4.7 OAMHOST1の起動

この項では、OAMHOST1の起動手順について説明します。

6.4.7.1 OAMHOST1でのノード・マネージャ・プロパティ・ファイルの作成

コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これを行うには、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行します。例:

OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh

6.4.7.2 ノード・マネージャの起動

次のコマンドを発行してノード・マネージャを起動します。

OAMHOST1> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

6.4.7.3 OAMHOST1上のAccess Managerの起動

OAMHOST1上のAccess Managerを起動する手順は、次のとおりです。

  1. 次のURLを使用して、WebLogic管理コンソールにログインします。

    http://oamhost1.example.com:7001/console

  2. WebLogic管理者のユーザー名とパスワードを指定します。

  3. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

  4. 「制御」タブをクリックします。

  5. サーバーWLS_OAM1をクリックします。

  6. 「起動」をクリックします。

  7. 「OK」をクリックし、サーバーを起動することを確認します。

6.4.8 OAMHOST1の検証

実装を検証するには、次のOracle Access Managementコンソールに接続します。

http://OAMHOST1.example.com:7001/oamconsole

OAM管理コンソールのログイン・ページが開き、WebLogic administratorアカウントを使用してログインできる場合、実装は有効です。

6.4.9 OAMHOST2でのOAMの構成

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

6.4.10 OAMHOST2の起動

この項では、OAMHOST2を起動する手順について説明します。手順には次の項目が含まれます。

6.4.10.1 OAMHOST2でのノード・マネージャ・プロパティ・ファイルの作成

コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。MW_HOME/oracle_common/common/binディレクトリにあるスクリプトsetNMProps.shを実行します。例:

OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh

6.4.10.2 ノード・マネージャの起動

次のコマンドを発行してノード・マネージャを起動します。

OAMHOST2> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

6.4.10.3 OAMHOST2上のAccess Managerの起動

OAMHOST2でAccess Managerを起動するには、次の手順を実行します。

  1. 次のURLを使用して、WebLogic管理コンソールにログインします。

    http://oamhost1.example.com:7001/console

  2. WebLogic管理者のユーザー名とパスワードを指定します。

  3. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

  4. 「制御」タブをクリックします。

  5. サーバーWLS_OAM2をクリックします。

  6. 「起動」をクリックします。

  7. 「OK」をクリックし、サーバーを起動することを確認します。

6.4.11 OAMHOST2の検証

OAMサーバーに接続することによって実装を検証します。

http://OAMHOST2.example.com:14100/oam/server/logout

OAMから正常にログアウトしたことを示すページが表示されると、実装は有効です。

6.4.12 Oracle HTTP Serverと連携するためのAccess Managerの構成

Oracle HTTP Serverと連携するようにAccess Managerを構成するには、次の手順を実行します。

6.4.12.1 Oracle HTTP Server構成の更新

WEBHOST1およびWEBHOST2で、次のディレクトリにoam.confというファイルを作成します。

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ファイルを作成して次の行を追加します。

NameVirtualHost *:7777
<VirtualHost *:7777>
 
    ServerName sso.example.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
        WLCookieName OAMSESSIONID
        WebLogicCluster oamhost1.example.com:14100,oamhost2.example.com:14100
    </Location>

    <Location /oamfed>
        SetHandler weblogic-handler
        Debug ON
        WLLogFile /tmp/weblogic.log
        WLProxySSL ON
        WLProxySSLPassThrough ON
        WLCookieName OAMSESSIONID
        WebLogicCluster oamhost1.example.com:14100,oamhost2.example.com:14100
        
    </Location>

    <Location /sts>
        SetHandler weblogic-handler
        WLLogFile /tmp/weblogic.log
        WLProxySSL ON
        WLProxySSLPassThrough ON
        WLCookieName OAM_JSESSIONID
        WebLogicCluster oamhost1.example.com:14100,oamhost2.example.com:14100
        
    </Location>

    <Location /access>
        SetHandler weblogic-handler
        Debug ON
        WLLogFile /tmp/weblogic.log
        WLProxySSL ON
        WLProxySSLPassThrough ON
        WLCookieName OAMSESSIONID
        WebLogicCluster amahost1.example.com:14150,amahost2.example.com:14150
        

    <Location /oamsso>
        SetHandler weblogic-handler
        Debug ON
        WLLogFile /tmp/weblogic.log
        WLProxySSL ON
        WLProxySSLPassThrough ON
        WLCookieName OAMSESSIONID
        WebLogicCluster oam_policy_mgr1.example.com:14100,oam_policy_
         mgr2.example.com:14100
        
    </Location>

</VirtualHost>

6.4.12.2 Oracle HTTP Serverの再起動

WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

WEBHOST1>opmnctl stopall
WEBHOST1>opmnctl startall

WEBHOST2>opmnctl stopall
WEBHOST2>opmnctl startall

6.4.12.3 OAM Serverにロード・バランサを認識させる

デフォルトでは、Access Managerではローカル・サーバーのログイン・ページにリクエストに送信します。高可用性デプロイメントでは、この設定を変更してログイン・ページ・リクエストがローカル・バランサに送信されるようにする必要があります。

Access Managerにロード・バランサを認識させる手順は、次のとおりです。

  1. 次のURLで、Oracle Access Managementコンソールにweblogicユーザーとしてログインします。

    http://OAMHOST1.example.com:7001/oamconsole

  2. 「構成」タブをクリックします。

  3. 「Access Managerの設定」リンクをクリックします。

  4. 次の情報を入力します。

    • OAMサーバー・ホスト: sso.example.com

    • OAMサーバー・ポート: 7777

    • OAMサーバー・プロトコル: http

  5. 「適用」をクリックします。

  6. 管理対象サーバーWLS_OAM1およびWLS_OAM2を再起動します。

6.4.13 外部LDAPストアを使用するためのAccess Managerの構成

デフォルトでは、Access Managerでは、組込みLDAPサーバーにある独自コンポーネントを使用します。高可用性環境では、ディレクトリ・ストアとして外部LDAPディレクトリをお薦めします。


注意:

この手順に従う前に環境およびLDAPストアをバックアップすることをお薦めします。

6.4.13.1 Access Manager用のディレクトリ・スキーマの拡張

アイデンティティ・ストアを事前構成することで、ディレクトリ・タイプに関係なくバックエンド・ディレクトリのスキーマを拡張します。

Access Managerのためにディレクトリ・スキーマを拡張するには、OAMHOST1上で次の手順を実行します。

  1. 環境変数MW_HOME、JAVA_HOME、IDM_HOMEおよびORACLE_HOMEを設定します。

    IDM_HOMEをIDM_ORACLE_HOMEに設定します。

    ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。

  2. 次の項目を含む、プロパティ・ファイルextend.propsを作成します。

    IDSTORE_HOST : idstore.example.com

    IDSTORE_PORT : 389

    IDSTORE_BINDDN : cn=orcladmin

    IDSTORE_USERNAMEATTRIBUTE: cn

    IDSTORE_LOGINATTRIBUTE: uid

    IDSTORE_USERSEARCHBASE:cn=Users,dc=example,dc=com

    IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=us,dc=oracle,dc=com

    IDSTORE_SEARCHBASE: dc=example,dc=com

    IDSTORE_SYSTEMIDBASE: cn=systemids,dc=example,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リコンシリエーション・ユーザーがあげられます。
      

      • 

    

    3. 

  3. 

    IAM_ORACLE_HOME/idmtools/binにあるidmConfigToolコマンドを使用して、アイデンティティ・ストアを構成します。
    

    コマンド構文は次のとおりです。
    

    idmConfigTool.sh -preConfigIDStore 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

    

    4. 

  4. 

    ログ・ファイルを確認して、エラーや警告を修正します。
    

    5. 








6.4.13.2 LDAPでのユーザーとグループの作成


Access Managerが必要とするユーザーをアイデンティティ・ストアに追加する手順は、次のとおりです。


    

  1. 

    環境変数MW_HOME、JAVA_HOME、IDM_HOMEおよびORACLE_HOMEを設定します。
    

      

    • 

      IDM_HOMEをIDM_ORACLE_HOMEに設定します。
      

      • 

    • 

      ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。
      

      • 

    

    2. 

  2. 

    次の項目を含む、プロパティ・ファイルoam.propsを作成します。
    

    IDSTORE_HOST : idstore.example.com

    

    IDSTORE_PORT : 389

    

    IDSTORE_BINDDN : cn=orcladmin

    

    IDSTORE_USERNAMEATTRIBUTE: cn

    

    IDSTORE_LOGINATTRIBUTE: uid

    

    IDSTORE_USERSEARCHBASE: cn=Users,dc=example,dc=com

    

    IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=example,dc=com

    

    IDSTORE_SEARCHBASE: dc=example,dc=com

    

    POLICYSTORE_SHARES_IDSTORE: true

    

    OAM11G_IDSTORE_ROLE_SECURITY_ADMIN:OAMAdministrators

    

    IDSTORE_OAMSOFTWAREUSER:oamLDAP

    

    IDSTORE_OAMADMINUSER:oamadmin
IDSTORE_SYSTEMIDBASE:cn=systemids,dc=example,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サーバーに接続するために使用されます。
      

      • 

    

    3. 

  3. 

    idmConfigToolコマンドを使用して、アイデンティティ・ストアを作成します。このコマンドは、IAM_ORACLE_HOME/idmtools/binにあります。
    

    コマンド構文は次のとおりです。
    

    idmConfigTool.sh -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

    

    4. 

  4. 

    ログ・ファイルを確認して、エラーや警告を修正します。
    

    5. 



idmConfigToolコマンドの詳細は、Oracle Fusion Middleware Oracle Identity Management Suite統合概要を参照してください。








6.4.13.3 ユーザー・アイデンティティ・ストアの作成


ユーザー・アイデンティティ・ストアを作成する手順は、次のとおりです。


    

  1. 

    次のURLのOracle Access Managementコンソールに移動します。
    

    http://adminvhn.example.com:7001/oamconsole

    2. 

  2. 

    WebLogic管理ユーザーを使用してログインします。
    

    3. 

  3. 

    「構成」→「データソース」を選択します。「構成」タブで、アイデンティティ・ストアをクリックします。
    

    4. 

  4. 

    「ユーザー・アイデンティティ・ストア」を選択して、「追加」をクリックします。OAM IDストアで、「作成」をクリックします。次の情報を入力します。
    

      

    • 

      ストア名: LDAP_DIR
      

      • 

    • 

      ストア・タイプ: OVD
      

      • 

    • 

      説明: ディレクトリ・ストアの説明を入力します
      

      • 

    • 

      SSLの有効化: これは、SSLを使用してディレクトリと通信する場合に選択します
      

      • 

    • 

      場所: 場所を入力します(例: ovd.example.com:389)
      

      • 

    • 

      バインドDN: LDAPストアを検索する権限を与えるユーザーを入力します。例: cn=orcladmin
      

      • 

    • 

      パスワード: oracleadminパスワードを入力します
      

      • 

    • 

      ユーザー名属性: たとえば、uidとします。
      

      • 

    • 

      ユーザー検索ベース: LDAPストアのユーザーの場所を入力します。例: cn=Users,dc=example,dc=com
      

      • 

    • 

      グループ名属性: 例: orclguid
      

      • 

    • 

      グループ検索ベース: LDAPストアのグループの場所を入力します。例: cn=Groups,dc=example,dc=com
      

      • 

    • 

      OAM管理者ロール: OAMAdministrators
      

      • 

    

    5. 

  5. 

    「適用」をクリックします。
    

    6. 

  6. 

    「接続テスト」をクリックし、LDAPサーバーへの接続を検証します。
    

    7. 








6.4.13.4 システム・ストアおよびデフォルト・ストアへのLDAPの設定


LDAPアイデンティティ・ストアを定義したら、それをプライマリ認証ストアとして設定する必要があります。Oracle Access Managementコンソールで次の手順を実行します。


    

  1. 

    「構成」タブで、「システム構成」タブをクリックします。
    

    2. 

  2. 

    ナビゲーション・ペインから「データ・ソース」を選択して、「ユーザー・アイデンティティ・ストア」をクリックします。
    

    3. 

  3. 

    「LDAP_DIR」をクリックします。
    

    4. 

  4. 

    「オープン」を「アクション」メニューで選択します。
    

    5. 

  5. 

    「デフォルト・ストアとして設定」をクリックします。
    

    6. 

  6. 

    「システム・ストアとして設定」をクリックします。
    

    7. 

  7. 

    「アクセス・システム管理者」の追加[+]アイコンをクリックします。
    

    8. 

  8. 

    検索名フィールドにOAM*を入力して、「検索」をクリックします。
    

    9. 

  9. 

    検索結果から「OAMAdministrators」を選択して、「選択済の追加」をクリックします。
    

    10. 

  10. 

    「適用」をクリックします。
    

    11. 

  11. 

    「システム管理者の検証」ウィンドウで、OAM管理者のユーザー名とパスワード(例: oamadmin)を入力します。
    

    12. 

  12. 

    「検証」をクリックします。
    

    13. 

  13. 

    「接続テスト」をクリックして接続をテストします。
    

    14. 








6.4.13.5 外部LDAPを使用する認証の設定


デフォルトでは、Access Managerは、ユーザーの検証に統合LDAPストアを使用します。LDAP認証モジュールを更新して、そのモジュールが新しい外部LDAPストアに対してユーザーを認証できるようにします。


LDAP認証モジュールが外部LDAPを使用するように更新する手順は、次のとおりです。


    

  1. 

    「アプリケーション・セキュリティ」タブで、「システム構成」タブをクリックします。
    

    2. 

  2. 

    「Access Managerの設定」を選択します。「認証モジュール」をクリックして、「検索」をクリックします。
    

    3. 

  3. 

    「LDAP」をクリックします。
    

    4. 

  4. 

    「オープン」を「アクション」メニューで選択します。
    

    5. 

  5. 

    「ユーザー・アイデンティティ・ストア」をLDAP_DIRに設定します。
    

    6. 

  6. 

    「適用」をクリックします。
    

    7. 

  7. 

    管理対象サーバーの管理サーバー、WLS_OAM1およびWLS_OAM2を再起動します。
    

    8. 














注意:

oamadminを使用してOIFを管理する場合は、OAM管理者ロールを追加する必要があります。詳細は、第6.4.13.3項「ユーザー・アイデンティティ・ストアの作成」を参照してください。		


















6.4.14 Access Managerの構成の検証


Oracle Access Managementコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminとしてログインすることにより、構成を検証します。








6.4.15 構成ファイルの同期を保つためのOracle Coherenceの構成


高可用性環境では、Oracleは構成ファイルの同期を保ちます。Oracle Coherenceは、デフォルトではポート9095を使用しますが、これをOracle Access Managementコンソールで変更できます。


http://admin.example.com/oamconsoleでコンソールにログインし、次の手順を実行します。


    

  1. 

    「構成」タブをクリックします。
    

    2. 

  2. 

    「サーバー」、「検索」の順にクリックします。
    

    3. 

  3. 

    ポートを変更する管理対象サーバーをダブルクリックします。
    

    4. 

  4. 

    「コヒーレンス」タブをクリックします。
    

    5. 

  5. 

    「ローカル・ポート」の値を目的の値に変更します。
    

    6. 

  6. 

    「適用」をクリックします。
    

    7. 

  7. 

    管理サーバーと、更新された管理対象サーバーと同じクラスタに配置されている管理対象サーバーすべてを再起動します。
    

    8. 









6.4.16 Access Managerトポロジのスケール・アップ


すでに1つ以上のサーバー・インスタンスが実行されているノードに、新しいAccess Manager管理対象サーバーを追加するには、スケール・アップします。


この項には次のトピックが含まれます:






6.4.16.1 Access Managerのスケール・アップ


OAMをスケール・アップするには、次の手順を実行します。


    

  1. 

    http://hostname.example.com:7001/consoleで管理コンソールにログインします。「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を開きます。
    

    2. 

  2. 

    「チェンジ・センター」で、「ロックして編集」をクリックします。
    

    3. 

  3. 

    拡張するホスト上のサーバーを選択します(例: WLS_OAM1)。
    

    4. 

  4. 

    「クローンの作成」をクリックします。
    

    5. 

  5. 

    次の情報を入力します。
    

      

    • 

      サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3です。
      

      • 

    • 

      サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。
      

      • 

    • 

      サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意である必要があります。
      

      • 

    

    6. 

  6. 

    「OK」をクリックします。
    

    7. 

  7. 

    新しく作成したサーバーWLS_OAM3をクリックします。
    

    8. 

  8. 

    SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。
    

    


    

    


    


    注意:
    
SSLリスニング・ポート14101を有効にします。    		

    
    

    

    

    

    9. 

  9. 

    「保存」をクリックします。
    

    10. 

  10. 

    新しい管理対象サーバーのホスト名の検証を無効化します。これはWLS_OAM3管理対象サーバーを起動および検証する前に実行する必要があります。管理サーバーとOAMHOSTnのノード・マネージャとの通信用のサーバー証明書を構成した後で、これを再度有効化できます。
    

    新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されているので、この手順を実行する必要はありません。
    

    ホスト名の検証を無効化するには、「ホスト名の検証」を「なし」に設定して、「保存」をクリックします。
    

    11. 

  11. 

    構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
    

    12. 









6.4.16.2 新しい管理対象サーバーの登録


新しい管理対象サーバーをOAMサーバーとして構成するには、Oracle Access Managementコンソールを使用します。


    

  1. 

    Oracle Access Managementコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminユーザーとしてログインします。
    

    2. 

  2. 

    「構成」タブをクリックします。「サーバー・インスタンス」をクリックします。
    

    3. 

  3. 

    「アクション」メニューから「作成」を選択します。
    

    4. 

  4. 

    次の情報を入力します。
    

      

    • 

      サーバー名: WLS_OAM3
      

      • 

    • 

      ホスト: サーバーを実行するホスト。
      

      • 

    • 

      ポート: 管理対象サーバーが作成されたときに割り当てられたリスニング・ポート(例: 14100)
      

      • 

    • 

      プロキシ・サーバーID: AccessServerConfigProxy
      

      • 

    • 

      ポート: OAMプロキシを実行するポート。これはホストに対して一意です(例: 5575)
      

      • 

    • 

      モード: オープン
      

      • 

    

    5. 

  5. 

    「コヒーレンス」タブをクリックします。
    

    「ローカル・ポート」をそのホストで一意の値に設定します。
    

    「適用」をクリックします。
    

    6. 

  6. 

    編集の確認を要求するプロンプトが表示されたら、「適用」をクリックします。
    

    7. 









6.4.16.3 新しいOAM管理対象サーバーでのWebGateの構成


新しいOAM管理対象サーバーにWebGateを構成するには、次の手順を実行します。


    

  1. 

    ノード・マネージャが新しいAccess ServerのWLS_OAM3で実行されていることを確認します。
    

    2. 

  2. 

    管理コンソールを使用して管理対象サーバーを起動します。「管理対象サーバーの起動」を参照してください。
    

    3. 

  3. 

    新しい管理対象サーバーをWebGateに通知します。「新しい管理対象サーバーをWebGateに通知」を参照してください。
    

    4. 




管理対象サーバーの起動


管理コンソールを使用して管理対象サーバーを起動するには、次の手順を実行します。


    

  1. 

    新しいノードWLS_OAM3にログインします。
    

    2. 

  2. 

    ディレクトリをORACLE_BASE/OAM_DOMAIN/binに変更します。例:
    

    /u01/app/oracle/admin/oam/user_projects/domains/oam_domain/bin

    3. 

  3. 

    管理対象サーバーを起動します。たとえば、次のように入力します。
    

    ./startManagedWebLogic.sh WLS_OAM3 http://hostname:7001

    4. 

  4. 

    プロンプトで、WebLogicのユーザー名とパスワードを入力します。「入力」をクリックします。
    

    5. 

  5. 

    管理対象サーバーが実行されていることを確認します。startManagedWebLogicログを確認し、管理コンソールの「環境」の下にある「サーバー」をクリックして、「サマリー」ページを表示します。ページをリフレッシュして更新内容を確認します。
    

    6. 




新しい管理対象サーバーをWebGateに通知


新しい管理対象サーバーをWebGateに通知するには、次の手順を実行します。


    

  1. 

    Oracle Access Managementコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminユーザーとしてログインします。
    

    2. 

  2. 

    「構成」タブをクリックします。
    

    3. 

  3. 

    「起動パッド」から、「アプリケーション管理」で、「アプリケーション・セキュリティ」タブの下にある「エージェント」をクリックして開きます。「検索」をクリックします。
    

    4. 

  4. 

    変更するWebGateをクリックします。
    

    5. 

  5. 

    「追加」+アイコンをクリックして、新しいサーバーをプライマリまたはセカンダリ・サーバー・リストに追加します。
    

    6. 

  6. 

    サーバー名をリストから選択します。
    

    7. 

  7. 

    「適用」をクリックします。
    

    8. 











6.4.17 Access Managerのスケール・アウト


新しいノードに、新しいAccess Manager管理対象サーバーを追加するには、スケール・アウトします。スケール・アウトはスケール・アップとよく似ていますが、新しいノードにソフトウェアをインストールする必要がある点が異なります。


    

  1. 

    Oracle WebLogic Serverを新しいホストにインストールします。第6.4.3項「Oracle WebLogic Serverのインストール」を参照してください。
    

    2. 

  2. 

    新しいホストにIdentity Managementコンポーネントをインストールします。第6.4.4項「Access Manager Application Tierのインストールと構成」を参照してください。
    

    3. 

  3. 

    http://hostname.example.com:7001/oamconsoleで管理コンソールにログインします。
    

    4. 

  4. 

    管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「マシン」を開きます。
    

    5. 

  5. 

    「マシン」表で「新規」をクリックします。
    

    6. 

  6. 

    「マシン・アイデンティティ」というラベルの付いた「新しいマシンの作成」画面で、次の情報を入力します。
    

      

    • 

      名前: 新しいノードのホスト名(例: host.example.com)
      

      • 

    • 

      マシンのOS: オペレーティング・システムを選択します(例: UNIX)
      

      • 

    

    7. 

  7. 

    「次へ」をクリックします。
    

    8. 

  8. 

    「ノード・マネージャのプロパティ」というラベルの付いた「新しいマシンの作成」画面で、次の情報を入力します
    

      

    • 

      タイプ: デフォルトのSSLをそのまま使用
      

      • 

    • 

      リスニング・アドレス: localhostを、WLS_OAM3が実行されるホスト名で置き換えます。
      

      • 

    • 

      ポート: リスニング・ポートが、他のノード上で実行されるノード・マネージャのポートと一致することを確認します(例: WLS_OAM3)。
      

      • 

    

    9. 

  9. 

    「終了」をクリックします。
    

    10. 

  10. 

    「ドメイン構造」で「サーバー」を開きます。
    

    11. 

  11. 

    拡張するホスト上のサーバーを選択します(例: WLS_OAM1)。
    

    12. 

  12. 

    「クローンの作成」をクリックします。
    

    13. 

  13. 

    「サーバー・アイデンティティ」というラベルの付いた「サーバーのクローンを作成」画面で、次の情報を入力します。
    

      

    • 

      サーバー名: サーバーの新しい名前(例: WLS_OAM3)
      

      • 

    • 

      サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。
      

      • 

    • 

      サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。
      

      • 

    

    14. 

  14. 

    「OK」をクリックします。
    

    15. 

  15. 

    「サーバー」表で、作成したばかりの新しいクローンをクリックします(例: WLS_OAM3)。
    

    16. 

  16. 

    「マシン」オプションで、作成したばかりの新しいマシン名にサーバーを割り当てます。これは管理対象サーバーが実行されるマシンです。
    

    17. 

  17. 

    「保存」をクリックします。
    

    18. 

  18. 

    「SSL」タブをクリックします。
    

    19. 

  19. 

    「詳細」をクリックします。
    

    20. 

  20. 

    「ホスト名の検証」を「なし」に設定します。
    

    21. 

  21. 

    「保存」をクリックします。
    

    22. 





6.4.17.1 管理対象サーバーのOAMへの登録


新しい管理対象サーバーをOAMサーバーとして登録するには、次の手順を実行します。


    

  1. 

    Oracle Access Managementコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminユーザーとしてログインします。
    

    2. 

  2. 

    「構成」タブをクリックします。「サーバー・インスタンス」をクリックします。
    

    3. 

  3. 

    「アクション」メニューから「作成」を選択します。
    

    4. 

  4. 

    次の情報を入力します。
    

      

    • 

      サーバー名: WebLogicコンソールでOAMサーバー・ノードのクローンを作成したときに入力したサーバー名と同じ名前を入力します。
      

      • 

    • 

      ホスト: サーバーを実行するホスト(OAMHOST3)。
      

      • 

    • 

      ポート: 管理対象サーバーを作成したときに割り当てられたリスニング・ポート。
      

      • 

    • 

      OAMプロキシ・ポート: OAMプロキシを実行するポート。これは当該ホストについて一意のポートです。
      

      • 

    • 

      プロキシ・サーバーID: AccessServerConfigProxy
      

      • 

    • 

      モード: 適切なモード(オープン、簡易または証明書)を選択します
      

      • 

    

    5. 

  5. 

    「適用」をクリックします。
    

    6. 








6.4.17.2 新しいOAM Access ServerでのWebGateの構成


Access Serverを起動します。このサーバーを使用するには、その存在をWebGateに通知する必要があります。


    

  1. 

    Oracle Access Managementコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminユーザーとしてログインします。
    

    2. 

  2. 

    起動パッドで「アプリケーション・セキュリティ」タブを選択します。
    

    3. 

  3. 

    「エージェント」をクリックし、「検索」をクリックします。
    

    4. 

  4. 

    変更するWebGateをクリックします。
    

    5. 

  5. 

    「サーバー・リスト」セクションで「追加」(+)アイコンをクリックして、新しいOAM Access Server (WLS_OAM3)をプライマリまたはセカンダリ・サーバー・リストに追加します。
    

    6. 

  6. 

    サーバー名をリストから選択します。
    

    7. 

  7. 

    「適用」をクリックします。
    

    8. 




WebGate構成の更新の検証


WebGate構成を検証するには、次の手順を実行します


    

  1. 

    WebGateが前回更新されたWebサーバーにログインします。
    

    2. 

  2. 

    WEB_HOME/config/OHS/ohs1/webgate/configディレクトリに移動します
    

    3. 

  3. 

    テキスト・エディタでObAccessClient.xmlを開きます。primary_server_listまたはsecondary_server_listで、新しいOAM Access Serverサーバーが更新されていることを確認します。
    

    4. 














注意:

WebGate構成が更新されない場合は、Webサーバーをリサイクルして、Webゲート・エージェント・プロファイルの更新内容をObAccessClient.xmlファイルに抽出します。		











Oracle HTTP Server構成ファイルの編集


これで新しい管理対象サーバーが作成され、起動されたので、Web層から各種の要求がそのサーバーに送られるようになります。ただし、新しい管理対象サーバーをWebサーバーに通知することをお薦めします。


このためには、各Web層のOAM.confファイルを更新します。このファイルは、ORACLE_INSTANCE/config/OHS/component name/moduleconfディレクトリにあります。


新しいサーバーをこのファイル内のWebLogicClusterディレクティブに追加します。次に変更前の例を示します。


<Location /OAM_admin>
    SetHandler weblogic-handler
    WebLogicCluster
 OAMhost1.example.com:14200,OAMhost2.example.com:14200
</Location>



変更後は次のようになります。


<Location /OAM_admin>
    SetHandler weblogic-handler
    WebLogicCluster
OAMhost1.example.com:14200,OAMhost2.example.com:14200,OAMhost3.example.com:14300
</Location>































 
前
 前 		
次
 次		











 
目次へ移動
 目次