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 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トラフィックに対してのみセッション・スティックネスを使用する必要があります。

他のOracle HTTP Serverからアクセスされ、さらにはアクセスが制限されているリソースを持つアプリケーションには、WebGateおよびカスタム・エージェントが必要です。WEBHOST3上のWebGateは、HTTP RESTコールを使用してアプリケーション層のOAMHOST1およびOAMHOST2上のアクセス・サーバーと通信します。WEBHOST3はアプリケーションWebサーバーであり、認証のためにHTTPリダイレクトによってリクエストをロード・バランサへ、そしてWEBHOST1およびWEBHOST2にルーティングします。高可用性デプロイメントにするために、WEBHOST3と同じコンポーネントを持つホストをもう1つ(たとえばWEBHOST4)を構成できます。

OAMHOST1およびOAMHOST2は、Oracle Access Serverアプリケーションをホストする管理対象サーバーをデプロイします。これらの管理対象サーバーは、アクセス・サーバーがアクティブ/アクティブ的に動作できるように、クラスタにおいて構成されます。

管理サーバーは、仮想HOSTNAMEを使用してOAMHOST1上で実行され、Oracle Enterprise Managerおよび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では、WebLogic ServerドメインごとにサポートされるAccess Managerクラスタは1つのみです。

単一インスタンスの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

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であるjdk17.0.12またはjdk21.0.4/bin/java -jar fmw_14.1.2.0.0_infrastructure.jarをインストールし、デフォルトのインストール・ディレクトリ・パスを手動で/tmp/Middleware/ORACLE_HOMEから/tmp/Middleware/へ変更します

  • IDMのjarであるjdk17.0.12またはjdk21.0.4/bin/java -jar fmw_14.1.2.1.0_idm_generic.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の起動

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

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

  • ノード・マネージャが実行されていない場合、次のコマンドをOAMHOST1で実行してこれを起動します。

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

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

  1. 次のURLで、WebLogic管理者資格証明を使用してWebLogicリモート・コンソールにログインします。

    ノート:

    WebLogicホスト・コンソールを起動する前に、デプロイしておく必要があります。ホストされたWebLogicリモート・コンソールのデプロイを参照してください。 

    for HTTP:
http://hostname:port/rconsole
or for HTTPS:
 https://hostname:port/rconsole
  2. 次の手順に従い、WebLogic Serverリモート・コンソールを使用してWLS_OAM1管理対象サーバーを起動します。
    1. モニタリング・ツリーで、「環境」に移動します。
    2. 「サーバー」をクリックします。
    3. 「WLS_OAM1」を選択して「起動」をクリックします。
    4. 次に、「OAM_POLICY_MGR1」を選択して「起動」をクリックします。

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を起動するステップについて説明します。ステップには次の項目が含まれます。

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

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

/u01/oracle/config/domains/access/startNodeManager.sh
OAMHOST2上のAccess Managerの起動

OAMHOST2でAccess Managerを起動するには:

  1. 次のURLを使用して、WebLogicリモート・コンソールにログインします。
    http://hostname:port/rconsole
  2. WebLogic管理者のユーザー名とパスワードを指定します。
  3. モニタリング・ツリーで、「環境」、「サーバー」の順に移動します。
  4. サーバーWLS_OAM2をクリックします。
  5. 「起動」をクリックします。

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サーバー・プロトコル: http(s)

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

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

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

ノート:

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

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

アイデンティティ・ストアを事前構成することで、ディレクトリ・タイプに関係なくバックエンド・ディレクトリのスキーマを拡張します。Access Managerのディレクトリ・スキーマを拡張するには、『Oracle Identity Management Suite統合ガイド』のOracle Access ManagerとLDAPの統合に関する項を参照してください。

Oracle Access ManagerとLDAPの統合

Access Managerが必要とするユーザーをアイデンティティ・ストアに追加するには、『Oracle Identity Management Suite統合ガイド』のOracle Access ManagerとLDAPの統合に関する項のステップに従います。

WebLogic管理者へのLDAPグループの追加

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

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

LDAPグループOAMAdministratorsおよびWLSAdminsをWebLogic管理者に追加するには:
  1. WebLogicリモート・コンソールにログインします。
  2. セキュリティ・データ・ツリーをクリックします。
  3. 左ペインで、「レルム」→「myrealm」→「ロール・マッパー」→「XACMLRoleMapper」→「グローバル」→「ロール」を展開します。
  4. 「管理」ロールをクリックします。
  5. 「条件の追加」をクリックし、「述部リスト」で「グループ」を選択します。
  6. 「グループ引数名」にOAMAdministratorsを指定し、「OK」をクリックします。
  7. WLSAdmins LDAPグループがある場合は、WLSAdminsグループに対してステップ5と6を繰り返します。
  8. OAMAdministrators LDAPグループがある場合は、OAMAdministratorsグループに対してステップ5と6を繰り返します。
  9. 「保存」をクリックして、管理ロールの追加を終了します。

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への登録

ノート:

これは、WebGatesとOAMサーバーの間にレガシー通信を使用している場合にのみ必要です。OAP over RESTを使用している場合は、このステップは必要ありません。

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

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

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

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

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

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

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

    • モード: 適切なモード(「Open」または「Cert」)を選択します。

  5. 「適用」をクリックします。
  6. 「OAM構成プロパティの変更」の説明に従って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の構成

ノート:

これは、WebGatesとOAMサーバーの間にレガシー通信を使用している場合にのみ必要です。OAP over RESTを使用している場合は、このステップは必要ありません。

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.conf、sso_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は、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_numberはOracle 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管理対象サーバーを再起動します。