11 Oracle Access Managerコンポーネントの高可用性の構成
Oracle Access Managerの概要と、Access Managerの高可用性環境の設計とデプロイの方法についての説明。
Access Managerによって、すべての認証および認可サービスの一元的な提供が可能になります。『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Managerの概要に関する項を参照してください。
- Access Managerコンポーネント・アーキテクチャ
プライマリAccess Managerコンポーネントおよびアーキテクチャの概要。 - Access Managerの高可用性の概要
- 高可用性のディレクトリ構造の前提条件
- Access Managerの高可用性の構成ステップ
親トピック: コンポーネントの手順
Access Managerコンポーネント・アーキテクチャ
プライマリAccess Managerコンポーネントおよびアーキテクチャの概要。
図11-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 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の構成アーティファクトには、次が含まれています。
表11-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の外部ランタイム依存性を示します。
表11-2 Access Managerの外部依存性
依存関係 | 説明 |
---|---|
LDAPベースのアイデンティティ・ストア |
|
OCSPレスポンダ・サービス |
リアルタイムX.509認証検証 |
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の高可用性の概要
この項では、Access Managerを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。
Access Managerの高可用性アーキテクチャ
図11-2は、Access Managerの高可用性アーキテクチャを示しています。
図11-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インスタンスを削除できます。
親トピック: 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ストアにアクセスできるかどうか。
-
ポリシー・ストアにアクセスできるかどうか。
ハートビート・チェックに成功した場合、アクセス・サーバーはリクエストの処理が可能であり、リクエストがそれに送信されます。ハートビート・チェックで問題がある場合、リクエストはアクセス・サーバーにルーティングされません。
親トピック: 障害からの保護および予想される動作
データベース障害
Access Managerサービス・インフラストラクチャは、マルチ・データ・ソースにより障害から保護されます。Oracle RACデータベース・インスタンスで障害が発生した場合に、使用可能なデータベース・インスタンスとの接続が再確立されます。マルチ・データ・ソースを使用すると、Oracle RACデータベース内の複数のインスタンスへの接続を構成できます。
マルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。
親トピック: 障害からの保護および予想される動作
高可用性のディレクトリ構造の前提条件
高可用性デプロイメントでは、製品インストールとファイルが特定のディレクトリに存在する必要があります。標準のディレクトリ構造を使用することで、ノード全体の構成と製品の統合が容易になります。
次の表に、高可用性のディレクトリ構造の前提条件を示します。
表11-3 ディレクトリ構造の前提条件
ディレクトリ | 要件 |
---|---|
ORACLE_HOME |
製品ごとに独自のORACLE_HOMEが必要です。たとえば、OAMとOIMは別々のORACLE_HOMEに配置される必要があります。 ORACLE_HOMEの内容は、すべてのノードで同一であることが必要です。すべてのノードで、ORACLE_HOMEが次の条件を満たしている必要があります。
|
DOMAIN_HOMEおよびAPPLICATION_DIRECTORY |
これらのディレクトリのパスは、すべてのノードで同じにする必要があります。 これらのディレクトリは、ORACLE_HOMEとは別のファイル・システムの場所に配置してください。ORACLE_HOME/ |
|
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の構成の前提条件
- リポジトリ作成ユーティリティの実行によるデータベース・スキーマの作成
- Oracle WebLogic Serverのインストール
- Access Manager Application Tierのインストールと構成
- OAMHOST1での管理サーバー用boot.propertiesの作成
- OAMHOST1の起動
- OAMHOST1の検証
- OAMHOST2でのOAMの構成
- OAMHOST2の起動
- OAMHOST2の検証
- Oracle HTTP Serverと連携するためのAccess Managerの構成
- 外部LDAPストアを使用するためのAccess Managerの構成
- Access Managerの構成の検証
- Access Managerトポロジのスケール・アップ
- Access Managerのスケール・アウト
Access Managerの構成の前提条件
Access Managerを高可用性のために構成する前に、次の操作を実行しておく必要があります。
-
OAMHOST1およびOAMHOST2にOracle WebLogic Serverをインストールします。Oracle WebLogic Serverのインストールを参照してください。
-
OAMHOST1およびOAMHOST2にOracle Identity Management実行可能ファイルをインストールします。「Access Manager Application Tierのインストールと構成」を参照してください。
-
リポジトリ作成ユーティリティを実行して、データベースにAccess Managerのスキーマを作成します。「リポジトリ作成ユーティリティの実行によるデータベース・スキーマの作成」を参照してください。
-
高可用性LDAP実装が使用可能であることを確認します。
次に例を示します。
- インフラストラクチャのjarである
jdk8/bin/java -jar fmw_12.2.1.3.0_infrastructure_generic.jar
をインストールし、デフォルトのインストール・ディレクトリ・パスを手動で/tmp/Middleware/ORACLE_HOME
から/tmp/Middleware/
へ変更します -
IDMのjarである
jdk8/bin/java -jar fmw_12.2.1.3.0_idm_generic.jar
をインストールし、インストール・ディレクトリに/tmp/Middleware/
を選択します。 -
/tmp/Middleware/oracle_common/bin/rcu
にあるRCUを実行します
親トピック: Access Managerの高可用性の構成ステップ
リポジトリ作成ユーティリティの実行によるデータベース・スキーマの作成
作成するスキーマは、インストールおよび構成する製品により異なります。RCUの実行については、『Oracle Fusion Middlewareのインストールのプランニング』および『Oracle Fusion Middlewareリポジトリ作成ユーティリティによるスキーマの作成』を参照してください。
親トピック: Access Managerの高可用性の構成ステップ
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の高可用性の構成ステップ
Access Manager Application Tierのインストールと構成
『Oracle Identity and Access Managementのインストールおよび構成』のIdentity and Access Managementのインストールと構成に関する項 を参照してください。
親トピック: Access Managerの高可用性の構成ステップ
OAMHOST1での管理サーバー用boot.propertiesの作成
boot.properties
ファイルを使用すると、administratorのユーザー名とパスワードの入力を求められることなく管理サーバーを起動できます。
boot.properties
ファイルを作成する手順は次のとおりです。
親トピック: Access Managerの高可用性の構成ステップ
OAMHOST1の起動
次の各項では、OAMHOST1の起動ステップについて説明します。
ノード・マネージャの起動
-
次のコマンドを発行してノード・マネージャを起動します。
OAMHOST1>ORACLE_HOME/user_projects/domains/domainName/bin/startNodeManager.sh
親トピック: OAMHOST1の起動
OAMHOST1の検証
OAMサーバーに接続することによって実装を検証します。
http://OAMHOST1.example.com:14150/access http://OAMHOST1.example.com:14100/oam/server/logout
OAMから正常にログアウトしたことを示すページが表示されると、実装は有効です。
親トピック: Access Managerの高可用性の構成ステップ
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
親トピック: Access Managerの高可用性の構成ステップ
OAMHOST2の起動
次の各項では、OAMHOST2を起動するステップについて説明します。ステップには次の項目が含まれます。
親トピック: Access Managerの高可用性の構成ステップ
OAMHOST2でのノード・マネージャ・プロパティ・ファイルの作成
コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。ORACLE_HOME/oracle_common/common/bin
ディレクトリにあるスクリプトsetNMProps.sh
を実行します。例:
OAMHOST1> $ORACLE_HOME/oracle_common/common/bin/setNMProps.sh
親トピック: OAMHOST2の起動
ノード・マネージャの起動
次のコマンドを発行してノード・マネージャを起動します。
OAMHOST2>ORACLE_HOME/user_projects/domains/domainName/bin/startNodeManager.sh
親トピック: OAMHOST2の起動
OAMHOST2の検証
OAMサーバーに接続することによって実装を検証します。
http://OAMHOST2.example.com:14150/access http://OAMHOST2.example.com:14100/oam/server/logout
OAMから正常にログアウトしたことを示すページが表示されると、実装は有効です。
親トピック: Access Managerの高可用性の構成ステップ
Oracle HTTP Serverと連携するためのAccess Managerの構成
次の手順を実行して、Access ManagerをOracle HTTP Serverと連携するように構成します。
親トピック: Access Managerの高可用性の構成ステップ
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 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>
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
外部LDAPストアを使用するためのAccess Managerの構成
デフォルトでは、Access Managerでは、組込みLDAPサーバーにある独自コンポーネントを使用します。高可用性環境では、ディレクトリ・ストアとして外部LDAPディレクトリをお薦めします。
注意:
この手順に従う前に環境およびLDAPストアをバックアップすることをお薦めします。
- Access Manager用のディレクトリ・スキーマの拡張
- LDAPにおけるユーザーとグループの作成
- ユーザー・アイデンティティ・ストアの作成
- システム・ストアおよびデフォルト・ストアへのLDAPの設定
- 外部LDAPを使用する認証の設定
- WebLogic管理者へのLDAPグループの追加
Access Managerでは、管理サーバー内に格納されているMBeanへのアクセスが必要です。LDAPユーザーがWebLogicコンソールとFusion Middleware Controlにログインできるようにするには、WebLogic管理権限をユーザーに割り当てる必要があります。Access ManagerでこれらのMbeanを呼び出すために、IAMAdministratorsグループのユーザーにはWebLogic管理権限が必要です。
親トピック: Access Managerの高可用性の構成ステップ
Access Manager用のディレクトリ・スキーマの拡張
アイデンティティ・ストアを事前構成することで、ディレクトリ・タイプに関係なくバックエンド・ディレクトリのスキーマを拡張します。
Access Managerのためにディレクトリ・スキーマを拡張するには、OAMHOST1上で次のステップを実行します。
システム・ストアおよびデフォルト・ストアへのLDAPの設定
LDAPアイデンティティ・ストアを定義したら、それをプライマリ認証ストアとして設定する必要があります。Oracle Access Managementコンソールで次のステップを実行します。
- 「構成」タブで、「ユーザー・アイデンティティ・ストア」をクリックします。
- デフォルト・ストアとしてLDAP_DIRを選択します。
- システム・ストアとしてLDAP_DIRを選択します。
- 「アクセス・システム管理者」の追加[+]アイコンをクリックします。
- 検索名フィールドにOAM*を入力して、「検索」をクリックします。
- 検索結果から「OAMAdministrators」を選択して、「選択済の追加」をクリックします。
- 「適用」をクリックします。
- 「システム管理者の検証」ウィンドウで、OAM管理者のユーザー名とパスワード(例: oamadmin)を入力します。
- 「検証」をクリックします。
- 「接続テスト」をクリックして接続をテストします。
外部LDAPを使用する認証の設定
デフォルトでは、Access Managerは、ユーザーの検証に統合LDAPストアを使用します。LDAP認証モジュールを更新して、そのモジュールが新しい外部LDAPストアに対してユーザーを認証できるようにします。
LDAP認証モジュールが外部LDAPを使用するように更新する手順は、次のとおりです。
- 「アプリケーション・セキュリティ」タブで、「認証モジュール」を選択し、「検索」をクリックします。
- 「LDAP」をクリックします。
- 「オープン」を「アクション」メニューで選択します。
- 「ユーザー・アイデンティティ・ストア」を
LDAP_DIR
に設定します。 - 「適用」をクリックします。
- 管理対象サーバーの管理サーバー、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管理アクションを実行できます。
IAMAdministrators
およびWLSAdmins
をWebLogic管理者に追加する手順は、次のとおりです。
- WebLogic管理サーバー・コンソールにログインします。
- コンソールの左ペインで「セキュリティ・レルム」をクリックします。
- 「セキュリティ・レルムのサマリー」ページの表「レルム」で「myrealm」をクリックします。
- 「myrealm」の「設定」ページで、「ロールとポリシー」タブをクリックします。
- 「レルム・ロール」ページの表「ロール」の「グローバル・ロール」エントリを開きます。
- 「ロール」リンクをクリックして、「グローバル・ロール」ページに移動します。
- 「グローバル・ロール」ページで、「管理」ロールをクリックして「グローバル・ロールの編集」ページに移動します。
- 「グローバル・ロールの編集」ページで、「ロール条件」表の「条件の追加」ボタンをクリックします。
- 「述部の選択」ページで、条件のドロップダウン・リストから「グループ」を選択し、「次へ」をクリックします。
- 「引数の編集」ページのグループ引数フィールドにIAMAdministratorsを指定し、「追加」をクリックします。
- グループWLSAdminsについても同様に繰り返します。
- 「終了」をクリックして、「グローバル・ロールの編集」ページに戻ります。
- 「ロール条件」表には、IAMAdministratorsおよびWLSAdminsグループがロール条件として表示されます。
- 「保存」をクリックして、OAMAdministratorsおよびIDM Administratorsグループへの管理ロールの追加を終了します。
Access Managerの構成の検証
Oracle Access Managementコンソール(http://OAMHOST1.example.com:7001/oamconsole
)にoamadmin
としてログインすることにより、構成を検証します。
WebLogic管理者へのLDAPグループの追加を参照してください。
親トピック: Access Managerの高可用性の構成ステップ
Access Managerトポロジのスケール・アップ
すでに1つ以上のサーバー・インスタンスが実行されているノードに、新しいAccess Manager管理対象サーバーを追加するには、スケール・アップします。
新しい管理対象サーバーの登録
新しい管理対象サーバーをOAMサーバーとして構成するには、Oracle Access Managementコンソールを使用します。
親トピック: Access Managerトポロジのスケール・アップ
新しいOAM管理対象サーバーでのWebGateの構成
新しいOAM管理対象サーバーにWebGateを構成するには、次のステップを実行します。
- ノード・マネージャが新しいAccess ServerのWLS_OAM3で実行されていることを確認します。
- 管理コンソールを使用して管理対象サーバーを起動します。「管理対象サーバーの起動」を参照してください
- 新しい管理対象サーバーをWebGateに通知します。「新しい管理対象サーバーをWebGateに通知」を参照してください
管理対象サーバーの起動
管理コンソールを使用して管理対象サーバーを起動するには、次の手順を実行します。
-
ディレクトリをOAMドメイン・ホームに変更します。たとえば、
DOMAIN_HOME/bin
-
管理対象サーバーを起動します。たとえば、次のように入力します。
./startManagedWebLogic.sh WLS_OAM3 http://hostname:7001
-
プロンプトで、WebLogicのユーザー名とパスワードを入力します。[Enter]を押します。
-
管理対象サーバーが実行されていることを確認します。startManagedWebLogicログを確認し、管理コンソールの「環境」の下にある「サーバー」をクリックして、「サマリー」ページを表示します。ページをリフレッシュして更新内容を確認します。
親トピック: 新しいOAM管理対象サーバーでのWebGateの構成
新しい管理対象サーバーをWebGateに通知
新しい管理対象サーバーをWebGateに通知するには、次の手順を実行します。
-
Oracle Access Managementコンソール(
http://OAMHOST1.example.com:7001/oamconsole
)にoamadmin
ユーザーとしてログインします。 -
「アプリケーション・セキュリティ」タブをクリックし、「エージェント」をクリックして「SSOエージェント」ページを表示します
-
「SSOエージェント」ページで、「検索」をクリックします。
-
「検索」をクリックします。
-
変更するWebGateをクリックします。
-
「追加」+アイコンをクリックして、新しいサーバーをプライマリまたはセカンダリ・サーバー・リストに追加します。
-
サーバー名をリストから選択します。
-
「適用」をクリックします
注意:
この手順を繰り返して、すべての構成されたWebGateエージェントに通知します。親トピック: 新しいOAM管理対象サーバーでのWebGateの構成
Access Managerのスケール・アウト
新しいノードに、新しいAccess Manager管理対象サーバーを追加するには、スケール・アウトします。スケール・アウトはスケール・アップとよく似ていますが、新しいノードにソフトウェアをインストールする必要がある点が異なります。
新しいOAM Access ServerでのWebGateの構成
Access Serverを起動します。このサーバーを使用するには、その存在をWebGateに通知する必要があります。
-
Oracle Access Managementコンソール(
http://OAMHOST1.example.com:7001/oamconsole
)にoamadmin
ユーザーとしてログインします。 -
「アプリケーション・セキュリティ」タブをクリックします。
-
「エージェント」をクリックして「SSOエージェント」ページを表示します
-
「SSOエージェント」ページで、「検索」をクリックします。
-
変更するWebGateをクリックします。
-
「サーバー・リスト」セクションで「追加」(+)アイコンをクリックして、新しいOAM Access Server (
WLS_OAM3
)をプライマリまたはセカンダリ・サーバー・リストに追加します。 -
サーバー名をリストから選択します。
-
「適用」をクリックします。
WebGate構成の更新の検証
WebGate構成を検証するには、次の手順を実行します
- WebGateが前回更新されたWebサーバーにログインします。
- ディレクトリ
OHSDomain/config/fmwconfig/components/OHS/<instancename>/webgate/config
に移動します - テキスト・エディタで
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>
親トピック: Access Managerのスケール・アウト