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

Oracle Access Managerの概要と、Access Managerの高可用性環境の設計とデプロイの方法についての説明。

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

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

プライマリAccess Managerコンポーネントおよびアーキテクチャの概要。

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

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

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

次に示すのは、Access Manager単一インスタンス・アーキテクチャで説明されているコンポーネントです。

  • ユーザー・エージェント: 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を管理および構成します。

  • アクセス・サーバー: 資格証明コレクタおよびOAMプロキシ・コンポーネントが含まれます。

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

一般的なAccess Managerデプロイメントは、ユーザー・エージェント、保護されたリソースおよびアクセス・サーバーなどのシステム・エンティティから構成されます。

Access Managerデプロイメントに必要なシステム・エンティティとその特性のリスト。

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

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

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

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

  • WebLogic 12c 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と統合し、パフォーマンス・メトリックとデプロイメント・トポロジを表示します。

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

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

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

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

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

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

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

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

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

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

DOMAIN_HOME/output

クライアント・エージェントの構成ファイルが格納されます。

Access Managerの外部依存性

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

表7-2 Access Managerの外部依存性

依存関係 説明

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

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

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

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

OCSPレスポンダ・サービス

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

RDBMSポリシー・ストア

  • ポリシー(認証および認可)リポジトリ

  • OAMポリシー・エンジンによって抽象化されるRDBMSアクセス

Oracle Identity Managerポリシー・ストア(Oracle Identity Managerベースのパスワード管理が有効化されている場合)

構成、メタデータなどを格納するために使用されるOblixスキーマ要素を含むLDAPリポジトリ

アイデンティティ・フェデレーション

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

OCSPレスポンダ・サービス

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

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

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

Domain_HOME/servers/serverName/logs/ serverName-diagnostic.log

Access Managerの高可用性の概要

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

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

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

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

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

図7-2では、ハードウェア・ロード・バランサが着信認証リクエストを受信し、そのリクエストをWeb層のWEBHOST1またはWEBHOST2にルーティングしています。これらのホストにはOracle HTTP Serverがインストールされています。次に、Oracle HTTP Serverによって、WebLogicプラグインmod_wl_ohs.confが使用されてWebLogic管理対象サーバーにリクエストが転送されます。「Oracle HTTP Serverの構成」を参照してください。

ロード・バランシング・ルーターは、HTTPトラフィックに対してのみセッション・スティックネスを使用する必要があります。OAPトラフィックは、ロード・バランシング・ルーターを使用しません。そのため、OAPトラフィックに対してはセッション・スティックネスは必要ありません。

他のOracle HTTP Serverからアクセスされ、さらにはアクセスが制限されているリソースを持つアプリケーションには、WebGateおよびカスタム・エージェントを構成する必要があります。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コンソールをデプロイします。

ディレクトリ層で、仮想IPidstore.example.comはIDstoreリクエストをアクティブ/アクティブのIDstoreクラスタを構成するLDAPHOST1とLDAPHOST2にルーティングします。たとえば、仮想IPoud.example.comはOracle Unified Directoryリクエストをアクティブ/アクティブのOracle Unified Directoryクラスタを構成するOUDHOST1とOUDHOST2にルーティングします。

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

Access Manager 12cでは、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によって致命的として処理され、起動操作は中断されます。

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

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

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

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

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

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

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

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

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

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

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

WebLogic Serverのクラッシュ

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

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

ノート:

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

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

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

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

ノード障害

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

データベース障害

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

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

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

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

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

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

ディレクトリ 要件

ORACLE_HOME

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

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

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

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

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

  • ORACLE_HOME名が同一であること

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

DOMAIN_HOMEおよびAPPLICATION_DIRECTORY

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

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

wlsserver_10.n

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

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

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

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

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

Access Managerの高可用性の構成ステップ

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

動的クラスタの使用を参照してください。

Access Managerの構成の前提条件

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

たとえば、

  • インフラストラクチャのjarであるjdk8/bin/java -jar fmw_12.2.1.4.0_infrastructure.jarをインストールし、デフォルトのインストール・ディレクトリ・パスを手動で/tmp/Middleware/ORACLE_HOMEから/tmp/Middleware/へ変更します
  • IDMのjarであるjdk8/bin/java -jar fmw_12.2.1.4.0_idm.jarをインストールし、インストール・ディレクトリに/tmp/Middleware/を選択します。

  • /tmp/Middleware/oracle_common/bin/rcuにあるRCUを実行します

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

作成するスキーマは、インストールおよび構成する製品により異なります。RCUを実行するには、「リポジトリ作成ユーティリティの起動」を参照してください。

詳細は、『Oracle Fusion Middlewareのインストールのプランニング』および『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。

Oracle WebLogic Serverのインストール

Oracle WebLogic Serverのインストールについては、『Oracle WebLogic ServerおよびCoherenceのインストールと構成』を参照してください。

ノート:

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

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

『Oracle Identity and Access Managementのインストールおよび構成』Oracle Access Managementソフトウェアのインストールと構成に関する項を参照してください。

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

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

boot.propertiesファイルを作成するには:

  1. OAMHOST1で、次に移動します。
    ORACLE_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の管理』Oracle Fusion Middlewareの起動と停止に関する項を参照してください。

  4. 次のコマンドを使用してノード・マネージャを起動します。
    cd WL_HOME/server/bin ./startNodeManager.sh
  5. ORACLE_HOME/user_projects/domains/domainName/binディレクトリにあるstartWebLogic.shスクリプトを使用して、OAMHOST1の管理サーバーを起動します。
  6. 変更に成功したことを確認します。ブラウザを開き、weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。
    • WebLogic Server管理コンソール:

      http://oamhost1.example.com:7001/console
      
    • Oracle Enterprise Manager Fusion Middleware Control:

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

OAMHOST1の起動

次の各項では、OAMHOST1の起動ステップについて説明します。

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

    OAMHOST1>ORACLE_HOME/user_projects/domains/domainName/bin/startNodeManager.sh
    
OAMHOST1上のAccess Managerの起動

OAMHOST1上のAccess Managerを起動するステップは、次のとおりです。

  1. 次のURLで、WebLogic管理者資格証明を使用してWebLogic管理コンソールにログインします。
    http://oamhost1.example.com:7001/console
    
  2. 次の手順に従い、WebLogic Server管理コンソールを使用してWLS_OAM1管理対象サーバーを起動します。
    1. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。
    2. 「サーバー」をクリックします。
    3. 「サーバーのサマリー」ページで、「制御」タブを開きます。
    4. 「WLS_OAM1」を選択して「起動」をクリックします。
    5. 「はい」をクリックし、サーバーを起動することを確認します。
    6. 次に、「OAM_POLICY_MGR1」を選択して「起動」をクリックします。
    7. 「はい」をクリックし、サーバーを起動することを確認します。

OAMHOST1の検証

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

http://OAMHOST1.example.com:14150/access
http://OAMHOST1.example.com:14100/oam/server/logout

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

OAMHOST2でのOAMの構成

OAMHOST1で構成を完了したら、それをOAMHOST2に伝播します。OAMHOST1でpackスクリプトを使用してドメインをパックし、OAMHOST2でunpackスクリプトを使用してドメインを解凍します。

スクリプトは両方とも、ORACLE_HOME/oracle_common/common/binディレクトリにあります。

OAMHOST1で、次のように入力します。

pack.sh -domain=$ORACLE_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=$ORACLE_HOME/user_projects/domains/IDM_Domain \
    -template=/tmp/idm_domain.jar

OAMHOST2の起動

次の各項では、OAMHOST2を起動するステップについて説明します。ステップには次の項目が含まれます。

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

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

OAMHOST1> $ORACLE_HOME/oracle_common/common/bin/setNMProps.sh
ノード・マネージャの起動

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

OAMHOST2>ORACLE_HOME/user_projects/domains/domainName/bin/startNodeManager.sh
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」をクリックし、サーバーを起動することを確認します。

OAMHOST2の検証

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

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

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

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

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

Oracle HTTP Server構成の更新

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

OHSDomain/config/fmwconfig/components/OHS/<instancename>/moduleconf/

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

NameVirtualHost *:7777
<VirtualHost *:7777>
 
    ServerName login.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 OAM_JSESSIONID
        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 OAM_JSESSIONID
        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 OAM_JSESSIONID
        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 OAM_JSESSIONID
        WebLogicCluster oam_policy_mgr1.example.com:14100,oam_policy_
         mgr2.example.com:14100
        
    </Location>

</VirtualHost>
Oracle HTTP Serverの再起動

WEBHOST1上のOracle HTTP Serverを再起動します。

OHSDomain/bin/stopComponent.sh ohs1
OHSDomain/bin/startComponent.sh ohs1

WEBHOST2上のOracle HTTP Serverを再起動します。

OHSDomain/bin/stopComponent.sh ohs2
OHSDomain/bin/startComponent.sh ohs2
OAM Serverにロード・バランサを認識させる

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

Access Managerにロード・バランサを認識させるには:

  1. 次のURLで、Oracle Access Managementコンソールにweblogicユーザーとしてログインします。
    http://OAMHOST1.example.com:7001/oamconsole
    
  2. 「構成」タブをクリックします。
  3. 「Access Managerの設定」リンクをクリックします。
  4. 次の情報を入力します。
    • OAMサーバー・ホスト: login.example.com

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

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

  5. 「適用」をクリックします。
  6. 管理対象サーバーWLS_OAM1およびWLS_OAM2を再起動します。

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

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

ノート:

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

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

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

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

  1. 環境変数JAVA_HOMEIDM_HOMEおよびORACLE_HOMEを設定します。

    IDM_HOMEIDM_ORACLE_HOMEに設定します。

    ORACLE_HOMEIAM_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は、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。OUDではなく、バックエンド・ディレクトリを指定します。)

    • IDSTORE_BINDDN アイデンティティ・ストア・ディレクトリの管理ユーザー

    • IDSTORE_USERSEARCHBASE ユーザーを配置するアイデンティティ・ストアの場所。

    • IDSTORE_GROUPSEARCHBASE グループを配置するアイデンティティ・ストアの場所。

    • IDSTORE_SEARCHBASE ユーザーおよびグループを格納するディレクトリの場所。

    • IDSTORE_SYSTEMIDBASE Oracle Identity Managerリコンシリエーション・ユーザーを配置するディレクトリの場所。

    • IDSTORE_SYSTEMIDBASE メイン・ユーザー・コンテナに配置する必要のないユーザーを配置できるディレクトリにあるコンテナの場所。これはほとんど発生しません。たとえば、Oracle Virtual DirectoryアダプタのバインドDNユーザーにも使用されるOracle Identity Managerリコンシリエーション・ユーザーがあげられます。

  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. ログ・ファイルを確認して、エラーや警告を修正します。
LDAPにおけるユーザーとグループの作成

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

  1. 環境変数JAVA_HOMEIDM_HOMEおよびORACLE_HOMEを設定します。
    • IDM_HOMEIDM_ORACLE_HOMEに設定します。

    • ORACLE_HOMEIAM_ORACLE_HOMEに設定します。

  2. 次の例に示すような項目を含む、プロパティ・ファイルoam.propsを作成します。
    IDSTORE_HOST: host.example.com
    IDSTORE_PORT: 9389
    IDSTORE_BINDDN: cn=directory manager
    IDSTORE_PASSWD: secret12
    IDSTORE_USERNAMEATTRIBUTE: cn
    IDSTORE_LOGINATTRIBUTE: uid
    IDSTORE_USERSEARCHBASE: ou=people,dc=example,dc=com
    IDSTORE_GROUPSEARCHBASE: ou=groups,dc=example,dc=com
    IDSTORE_SEARCHBASE: dc=example,dc=com
    IDSTORE_SYSTEMIDBASE: cn=systemids,dc=example,dc=com
    IDSTORE_OAMSOFTWAREUSER: oamSoftwareUser
    IDSTORE_PWD_OAMSOFTWAREUSER: example_pwd
    IDSTORE_OAMADMINUSER: oamAdminUser
    IDSTORE_PWD_OAMADMINUSER: example_pwd
    IDSTORE_PWD_OBLIXANONYMOUSUSER: example_pwd
    IDSTORE_PWD_ANONYMOUSUSER: example_pwd
    OAM11G_IDSTORE_ROLE_SECURITY_ADMIN: OAMAdministrators
    POLICYSTORE_SHARES_IDSTORE: true
  3. idmConfigToolコマンドを使用して、アイデンティティ・ストアを構成します。このコマンドは、IAM_ORACLE_HOME/idmtools/binにあります。

    次の例に、コマンドの構文を示します。

    $ORACLE_HOME/idmtools/bin/idmConfigTool.sh -prepareIDStore mode=OAM input_file=prepareIDStore.properties log_level=ALL log_file=log_idstore1.out dump_params=true

    このコマンドを実行すると、IDストアへの接続に使用しているアカウントのパスワードを求めるプロンプトがシステムによって表示されます。

  4. ログ・ファイルを確認して、エラーや警告を修正します。
ユーザー・アイデンティティ・ストアの作成

ユーザー・アイデンティティ・ストアを作成するには:

  1. 次のURLのOracle Access Managementコンソールに移動します。
    http://adminvhn.example.com:7001/oamconsole
    
  2. WebLogic管理ユーザーを使用してログインします。
  3. 「構成」タブを選択し、「ユーザー・アイデンティティ・ストア」をクリックします。
  4. OAM IDストアで、「作成」をクリックします。次の情報を入力します。
    • ストア名: LDAP_DIR

    • ストア・タイプ: OUD

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

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

    • 場所: 場所を入力します(たとえばoud.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. 「適用」をクリックします。
  6. 「接続テスト」をクリックし、LDAPサーバーへの接続を検証します。
システム・ストアおよびデフォルト・ストアへのLDAPの設定

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

  1. 「構成」タブで、「ユーザー・アイデンティティ・ストア」をクリックします。
  2. デフォルト・ストアとしてLDAP_DIRを選択します。
  3. システム・ストアとしてLDAP_DIRを選択します。
  4. 「アクセス・システム管理者」の追加[+]アイコンをクリックします。
  5. 検索名フィールドにOAM*を入力して、「検索」をクリックします。
  6. 検索結果から「OAMAdministrators」を選択して、「選択済の追加」をクリックします。
  7. 「適用」をクリックします。
  8. 「システム管理者の検証」ウィンドウで、OAM管理者のユーザー名とパスワード(たとえば、oamadmin)を入力します。
  9. 「検証」をクリックします。
  10. 「接続テスト」をクリックして接続をテストします。
外部LDAPを使用する認証の設定

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

LDAP認証モジュールが外部LDAPを使用するように更新するには:

  1. 「アプリケーション・セキュリティ」タブで、「認証モジュール」を選択し、「検索」をクリックします。
  2. 「LDAP」をクリックします。
  3. 「オープン」「アクション」メニューで選択します。
  4. 「ユーザー・アイデンティティ・ストア」LDAP_DIRに設定します。
  5. 「適用」をクリックします。
  6. 管理対象サーバーの管理サーバー、WLS_OAM1およびWLS_OAM2を再起動します。
WebLogic管理者へのLDAPグループの追加

Access Managerでは、管理サーバー内に格納されているMBeanへのアクセスが必要です。LDAPユーザーがWebLogicコンソールとFusion Middleware Controlにログインできるようにするには、WebLogic管理権限をユーザーに割り当てる必要があります。Access ManagerでこれらのMbeanを呼び出すために、IAMAdministratorsグループのユーザーにはWebLogic管理権限が必要です。

シングル・サインオンが実装されている場合は、LDAPグループのIDM AdministratorsにWebLogic管理権限を提供することで、これらのアカウントの1つを使用してログインして、WebLogic管理アクションを実行できます。

LDAPグループのIAMAdministratorsおよびWLSAdminsをWebLogic管理者に追加するには:
  1. WebLogic管理サーバー・コンソールにログインします。
  2. コンソールの左ペインで「セキュリティ・レルム」をクリックします。
  3. 「セキュリティ・レルムのサマリー」ページの表「レルム」で「myrealm」をクリックします。
  4. 「myrealm」の「設定」ページで、「ロールとポリシー」タブをクリックします。
  5. 「レルム・ロール」ページの表「ロール」の「グローバル・ロール」エントリを開きます。
  6. 「ロール」リンクをクリックして、「グローバル・ロール」ページに移動します。
  7. 「グローバル・ロール」ページで、「管理」ロールをクリックして「グローバル・ロールの編集」ページに移動します。
  8. 「グローバル・ロールの編集」ページで、「ロール条件」表の「条件の追加」ボタンをクリックします。
  9. 「述部の選択」ページで、条件のドロップダウン・リストから「グループ」を選択し、「次へ」をクリックします。
  10. 「引数の編集」ページのグループ引数フィールドにIAMAdministratorsを指定し、「追加」をクリックします。
  11. グループWLSAdminsについても同様に繰り返します。
  12. 「終了」をクリックして、「グローバル・ロールの編集」ページに戻ります。
  13. 「ロール条件」表には、IAMAdministratorsおよびWLSAdminsグループがロール条件として表示されます。
  14. 「保存」をクリックして、OAMAdministratorsおよびIDM Administratorsグループへの管理ロールの追加を終了します。

Access Managerの構成の検証

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

WebLogic管理者へのLDAPグループの追加を参照してください。

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

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

Access Managerのスケール・アップ

OAMをスケール・アップするには:

  1. http://hostname.example.com:7001/consoleで管理コンソールにログインします。「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を開きます。
  2. 「チェンジ・センター」で「ロックして編集」をクリックします。
  3. 拡張するホスト上のサーバーを選択します(たとえば: WLS_OAM1)。
  4. 「クローン」をクリックします。
  5. 次の情報を入力します。
    • サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3です。

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

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

  6. 「OK」をクリックします。
  7. 新しく作成したサーバーWLS_OAM3をクリックします。
  8. SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。

    ノート:

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

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

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

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

  11. 構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
新しい管理対象サーバーの登録

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

  1. Oracle Access Managementコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminユーザーとしてログインします。
  2. 「構成」タブをクリックします。「サーバー・インスタンス」をクリックします。
  3. 「アクション」メニューから「作成」を選択します。
  4. 次の情報を入力します。
    • サーバー名: WLS_OAM3

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

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

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

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

    • モード: オープン

  5. 編集の確認を要求するプロンプトが表示されたら、「適用」をクリックします。
  6. OAM_ORACLE_HOMEプロパティ<ORACLE_HOME>/oamがサーバー・ノード(OAM1、OAM2など)の起動時に設定されることを確認します。この環境では、startWeblogicスクリプトがJavaプロセスの起動中に-DOAM_ORACLE_HOME=<ORACLE_HOME>/oamを渡すように編集されています。
新しいOAM管理対象サーバーでのWebGateの構成

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

  1. ノード・マネージャが新しいAccess ServerのWLS_OAM3で実行されていることを確認します。
  2. 管理コンソールを使用して管理対象サーバーを起動します。「管理対象サーバーの起動」を参照してください
  3. 新しい管理対象サーバーをWebGateに通知します。「新しい管理対象サーバーをWebGateに通知」を参照してください
管理対象サーバーを起動します

管理コンソールを使用して管理対象サーバーを起動するには:

  1. ディレクトリをOAMドメイン・ホームに変更します。たとえば、DOMAIN_HOME/bin

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

    ./startManagedWebLogic.sh WLS_OAM3 http://hostname:7001
    
  3. プロンプトで、WebLogicのユーザー名とパスワードを入力します。[Enter]を押します。

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

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

新しい管理対象サーバーをWebGateに通知するには:

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

  2. 「アプリケーション・セキュリティ」タブをクリックし、「エージェント」をクリックして「SSOエージェント」ページを表示します

  3. 「SSOエージェント」ページで、「検索」をクリックします。

  4. 「検索」をクリックします。

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

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

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

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

ノート:

この手順を繰り返して、すべての構成されたWebGateエージェントに通知します。

Access Managerのスケール・アウト

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

  1. Oracle WebLogic Serverを新しいホストにインストールします。Oracle WebLogic Serverのインストールを参照してください。
  2. 新しいホストにIdentity Managementコンポーネントをインストールします。「Access Manager Application Tierのインストールと構成」を参照してください。
  3. http://hostname.example.com:7001/oamconsoleで管理コンソールにログインします。
  4. 管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「マシン」を開きます。
  5. 「マシン」表で「新規」をクリックします。
  6. 「マシン・アイデンティティ」というラベルの付いた「新しいマシンの作成」画面で、次の情報を入力します。
    • 名前: 新しいノードのホスト名(たとえば、host.example.com)

    • マシンのOS: オペレーティング・システムを選択します(たとえば、UNIX)

  7. 「次」をクリックします。
  8. 「ノード・マネージャのプロパティ」というラベルの付いた「新しいマシンの作成」画面で、次の情報を入力します
    • タイプ: デフォルトのSSLをそのまま使用

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

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

  9. 「終了」をクリックします。
  10. 「ドメイン構造」で「サーバー」を開きます。
  11. 拡張するホスト上のサーバーを選択します(たとえば: WLS_OAM1)。
  12. 「クローン」をクリックします。
  13. 「サーバー・アイデンティティ」というラベルの付いた「サーバーのクローンを作成」画面で、次の情報を入力します。
    • サーバー名: サーバーの新しい名前(たとえばWLS_OAM3)

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

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

  14. 「OK」をクリックします。
  15. 「サーバー」表で、作成したばかりの新しいクローンをクリックします(たとえばWLS_OAM3)。
  16. 「マシン」オプションで、作成したばかりの新しいマシン名にサーバーを割り当てます。これは管理対象サーバーが実行されるマシンです。
  17. 「保存」をクリックします。
  18. 「SSL」タブをクリックします。
  19. 「詳細設定」をクリックします。
  20. 「ホスト名の検証」「なし」に設定します。
  21. 「保存」をクリックします。
  22. ORACLE_HOME/oracle_common/common/binにあるpack.shおよびunpack.shスクリプトを実行し、OAMHOST1のドメインを圧縮して、それぞれ新しいホストで解凍します。
    pack.sh -domain=ORACLE_HOME/user_projects/domains/domainName -template =/tmp/idm_domain.jar -template_name="OAM Domain" 
    unpack.sh -domain=ORACLE_HOME/user_projects/domains/domainName -template =/tmp/idm_domain.jar 
管理対象サーバーのOAMへの登録

新しい管理対象サーバーをOAMサーバーとして登録するには:

  1. Oracle Access Managementコンソール(http://OAMHOST1.example.com:7001/oamconsole)にoamadminユーザーとしてログインします。
  2. 「構成」タブをクリックします。「サーバー・インスタンス」をクリックします。
  3. 「アクション」メニューから「作成」を選択します。
  4. 次の情報を入力します。
    • サーバー名: WebLogicコンソールでOAMサーバー・ノードのクローンを作成したときに入力したサーバー名と同じ名前を入力します。

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

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

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

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

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

  5. 「適用」をクリックします。
  6. <DOMAIN_HOME>/config/fmwconfigにあるoam-config.xmlを、動的に追加されるノードのIP範囲を設定するように編集します。

    次の例の設定マップは、SetWellKnownAddress>AuthorizedSubnets >Range1 >From [value of start ip range]]>To [value of end ip range]です。

    <Setting Name="AuthorizedSubnets" Type="htf:map">
    <Setting Name="Range1" Type="htf:map">
    <Setting Name="From" Type="htf:map">
    <Setting Name="Key"
    Type="xsd:string">oam.coherence.auth.range.from.1</Setting>
    <Setting Name="Value"
    Type="xsd:string">10.229.139.20</Setting>
    </Setting>
    <Setting Name="To" Type="htf:map">
    <Setting Name="Key"
    Type="xsd:string">oam.coherence.auth.range.to.1</Setting>
    <Setting Name="Value"
    Type="xsd:string">10.229.139.40</Setting>
    </Setting>
    </Setting>
    </Setting>
  7. OAM_ORACLE_HOMEプロパティ<ORACLE_HOME>/oamがサーバー・ノード(OAM1、OAM2など)の起動時に設定されることを確認します。この環境では、startWeblogicスクリプトがJavaプロセスの起動中に-DOAM_ORACLE_HOME=<ORACLE_HOME>/oamを渡すように編集されています。
新しいOAM Access ServerでのWebGateの構成

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

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

  2. 「アプリケーション・セキュリティ」タブをクリックします。

  3. 「エージェント」をクリックして「SSOエージェント」ページを表示します

  4. 「SSOエージェント」ページで、「検索」をクリックします。

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

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

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

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

WebGate構成の更新の検証

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

  1. WebGateが前回更新されたWebサーバーにログインします。
  2. ディレクトリOHSDomain/config/fmwconfig/components/OHS/<instancename>/webgate/configに移動します
  3. テキスト・エディタでObAccessClient.xmlを開きます。primary_server_listまたはsecondary_server_listで、新しいOAM Access Serverサーバーが更新されていることを確認します。

ノート:

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

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

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

Web層では、ORACLE_INSTANCE/config/OHS/component name/moduleconfディレクトリにadmin_vh.confsso_vh.confおよびigdinternal_vh.confを含む複数の構成ファイルがあります。それぞれに、ロケーション・ブロックのエントリが数多く含まれます。ブロックが2つのサーバー・インスタンスを参照しているときに3つ目を追加する場合、そのブロックを新しいサーバーを使用して更新する必要があります。

新しいサーバーをこのファイル内のWebLogicClusterディレクティブに追加します。たとえば、次のものを変更します:

<Location /oam>
   SetHandler weblogic-handler
   WebLogicCluster OAMHOST1.example.com:14100,OAMHOST2.example.com:14100
</Location>

変更後:

<Location /oam>
   SetHandler weblogic-handler
   WebLogicCluster OAMHOST1.example.com:14100,OAMHOST2.example.com:14100,OAMHOST1.example.com:14101
</Location>

ユニキャスト構成を使用したOracle Identity and Access Managementクラスタのデプロイ

デプロイメント環境でマルチキャストIPが無効になっている場合は、ユニキャスト構成でOracle Identity and Access Managementクラスタをデプロイできます。

デプロイメント環境で、セキュリティ上の理由からマルチキャストIPが無効になっている場合、またはデプロイメントにクラウド・インフラストラクチャを使用している場合、デフォルトの構成(マルチキャスト)でOracle Identity and Access Managementをデプロイすることはできません。Oracle Identity and Access Management 12cは、JavaGroupまたはJGroupライブラリに依存するEHキャッシュを使用していて、マルチキャスト構成をメッセージのブロードキャストのデフォルトとしてサポートしているため、実現できません。

EHキャッシュのユニキャスト構成を行うには、次のステップを実行します:

  1. ホスト・マシンおよび使用可能なポートのリストを取得して、次のJGroup構成を準備します。
    例:
    connect=TCP(bind_port=7800): TCPPING(initial_hosts=<Node1 IP>[7800],<Node2 IP>[7800];port_range=10;timeout=3000; num_initial_members=3): pbcast.NAKACK(use_mcast_xmit=false;retransmit_timeout=10000):pbcast.GMS(print_local_addr=true;join_timeout=3000)
  2. EMコンソールで、「アイデンティティとアクセス」を展開し、「OIM」をクリックします。
  3. 「oim(version_number)」を右クリックして「システムMBeanブラウザ」を選択します。

    ここで、version_numberOracle Identity and Access Managementの現在のバージョン番号です。

  4. 「oracle.iam」を展開し、「サーバー:oim」「アプリケーション:oim」「XMLConfig」「構成」「XMLConfig.CacheConfig」の順に選択し、「キャッシュ」をクリックします。
  5. 右ペインで、「属性」タブに移動し、「クラスタ化」属性値をtrueに設定します。
  6. 左ペインで、「キャッシュ」フォルダを展開し、「XMLConfig.CacheConfig.XLCacheProvider」を選択して、「XLCacheProvider」をクリックします。
  7. 右ペインで、「属性」タブに移動し、MulticastAddress:の値をemptyに設定し、MulicastConfig属性値をステップ1で識別した同等のJGroup文字列に設定します。
  8. 「oracle.iam」で、「Server:oim」をクリックして「Application:oim」を選択し、「XMLConfig」をクリックして「Config」を選択し、「XMLConfig.DeploymentConfig」をクリックして「DeploymentConfig」を選択し、「アプリケーション定義のMBean: XMLConfig.DeploymentConfig:DeploymentConfig」をクリックして、「デプロイメント構成デプロイメント・モード」の値をclusterとして指定します。
  9. 「適用」をクリックします。
  10. ユニキャストIPV4を使用する場合は、JVMプロパティがすべてのノードのSetDomainEnvスクリプトで設定されているかどうかを確認します。そうでない場合は、JVMプロパティを設定し、SetDomainEnvスクリプトに次のパラメータを追加します:
    EXTRA_JAVA_PROPERTIES="-Djava.net.preferIPv4Stack=true ${EXTRA_JAVA_PROPERTIES}"
    export EXTRA_JAVA_PROPERTIES
  11. すべてのOracle Identity and Access Management管理対象サーバーを再起動します。