| Oracle® Fusion Middleware Oracle Identity and Access Management高可用性ガイド 11gリリース2 (11.1.2.2) B69538-05 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity and Access Management高可用性ガイド 11gリリース2 (11.1.2.2) B69538-05 |
|
前 |
次 |
この章では、Oracle Access Management Access Manager (Access Manager)の概要、およびAccess Managerの高可用性環境の設計およびデプロイ方法について説明します。
Access Managerによって、すべての認証および認可サービスの一元的な提供が可能になります。提供されるコア・サービスは、有効なセッション・トークンのチェック、セッション・トークンが無効であるか見つからない場合の資格証明の要求、セッション・トークンの発行、リソース・リクエストのインターセプト、およびリソースへのアクセスを制御するためのアクセス制御ポリシーの評価です。Access Managerは、Pure Javaサーバーの機能を備えていますが、Oracle Single Sign-On 10gおよびOracle Access Manager 10gエージェント・コンポーネントも引き続き使用します。Access Managerの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Management Access Managerの概要に関する説明を参照してください。
この章の内容は、次のとおりです。
図6-1は、Access Managerコンポーネントのアーキテクチャを示しています。
図6-1は、次のコンポーネントを示しています。
ユーザー・エージェント: これらには、Webブラウザ、Javaアプリケーション、およびWebサービス・アプリケーションが含まれます。ユーザー・エージェントは、HTTPを使用してアクセス・サーバーと管理および構成ツールにアクセスします。
保護されたリソース: 保護されたリソースとは、それへのアクセスが制限されたアプリケーションまたはWebページのことです。保護されたリソースへのアクセスは、WebGateまたはカスタム・エージェントによって制御されます。
管理および構成ツール: Access Managerは、Oracle Access Managementコンソール、Oracle Enterprise Manager Fusion Middleware Control、Oracle Enterprise Manager Grid ControlおよびWebLogic Scripting Tool (WLST)を使用して管理および構成します。
アクセス・サーバー: アクセス・サーバーには、資格証明コレクタ、OSSOプロキシおよびOAMプロキシ・コンポーネントが含まれます。Coherence分散オブジェクト・キャッシュは、アクセス・サーバー間で構成ファイルの変更を伝播するために使用されます。
Access Managerデプロイメントは、次のシステム・エンティティで構成されます。
Access Managerエージェント: Access Managerエージェントは、アクセス・サーバーの拡張機能であり、アクセス・サーバーで管理されているポリシーに従ってアクセスが制御されるようにする役割を担います。
エージェントがその機能を実行するには、アクセス・サーバー・コンポーネントが必要です。アクセス・サーバーが使用できない場合、保護されるサーバーへのアクセスは許可されないため、ユーザーはシステムからロックアウトされます。
保護されたリソース(パートナ・アプリケーション): Access Managerによって保護されたアプリケーションです。これらのリソースへのアクセスは、Access Managerのアクセス制御ポリシーに従って行われ、保護されたリソースのアクセス・パスにデプロイされたAccess Managerエージェント(WebサーバーにデプロイされたAccess Managerエージェントなど)によって制御されます。
アクセス・サーバー: コア・ランタイム・アクセス管理サービスを提供するサーバー・サイド・コンポーネントです。
JMX Mbean: ランタイムMBeanは、アクセス・サーバー・パッケージの一部としてパッケージ化されています。構成Mbeanは、スタンドアロンWARファイルとしてパッケージ化されています。
WebLogic 11g SSPIプロバイダは、Access Java Access JDKとともにSSPIインタフェースを実現するJavaクラスで構成されています。AccessGateは、Pure Java Access JDKを使用して構築されています。
Oracle Access Managementコンソール: 管理コンソールをホストするJ2EEアプリケーションであり、Access Managerデプロイメントを管理するための管理や構成などのサービスを提供します。
WebLogic Scripting Tool (WLST)は、アクセス・サーバー・パッケージに含まれているJavaクラスで構成されています。Access Managerデプロイメントの管理の一部は、コマンド行からサポートされます。
Fusion Middleware ControlおよびEnterprise Manager Grid Control: Access Managerは、Enterprise Manager Grid Controlと統合し、パフォーマンス・メトリックとデプロイメント・トポロジを表示します。
Coherence分散オブジェクト・キャッシュ: Access Managerコンポーネントは、このインフラストラクチャに依存して、変更をリアルタイムに伝播します。
Access Manager Proxyは、Apache MINAサーバーのカスタマイズ・バージョン(JCAアーキテクチャに基づく)であり、Javaサーバー・クラスに加えてMessageDrivenBeanおよびResourceAdapterが含まれています。
Oracle Single Sign-On (OSSO)プロキシは、アクセス・サーバー・パッケージに含まれているJavaクラスで構成されています。
データ・リポジトリ: Access Managerは、アイデンティティ、ポリシー、パートナ、セッション、一時データを含む様々なタイプの情報を処理します。
アイデンティティ・データ用LDAP
構成およびパートナ・データ用ファイル
セッションおよび一時データ用Coherenceインメモリー
ポリシー・データはファイルまたはRDBMSに格納されます
Oracle Access Manager 10g WebGateは、Webサーバーにデプロイすることを意図したCベースのエージェントです。
Oracle Single Sign-On Apacheモジュールは、Oracle HTTP Server Webサーバーにデプロイすることを意図したCベースのエージェントです。
Access Manager 11g WebGateは、Webサーバーにデプロイすることを意図したCベースのエージェントです。
認証ユーザー・セッション情報は、Coherence分散オブジェクト・キャッシュを介して永続化されます。Access Managerに対しては、Coherence分散オブジェクト・キャッシュ・インメモリー・モードを使用します。
Access Managerによって、ログイン処理中に、認証されていないユーザーに対して一時状態が作成されることがあります。この状態は、通常、Access Managerノード間でレプリケートされません。ログイン処理中のノードの障害の影響を防止するために、オプションでその状態を暗号化されたクライアントCookieに格納することができます。
認証されていないユーザーの一時状態をログイン処理中に格納するには、次の手順に従ってOAMサーバー・パラメータRequestCacheTypeをBASICからCOOKIEに変更します。
次のコマンドを実行して、WLSTの環境を設定します。
DOMAIN_HOME/bin/setDomainEnv.sh
次のコマンドを発行して、WLSTを起動します。
Start WLST by issuing this command:
ORACLE_HOME/common/bin/wlst.sh
ドメインに接続します。
wls:/IDM_Domain/serverConfig> connect()
WebLogic管理ユーザー名とパスワードを入力し、管理サーバーのURLを次の形式で入力します。
t3://OAMHOST1.example.com:7001
次のコマンドを発行します。
wls:/IDM_Domain/serverConfig> configRequestCacheType(type="COOKIE")
次のコマンドを発行して、コマンドが動作したことを確認します。
wls:/IDM_Domain/serverConfig> displayRequestCacheType()
Access Manager管理対象サーバーを再起動します。
Access Managerのリクエスト・フローの手順を次に説明します。
ユーザーが、Access Managerによって保護されたWebリソースに、Webブラウザを使用してアクセスを試みます。
Access Managerエージェント脚注1 によって、そのリクエストはインターセプトされ、ユーザーが認証済セッションを持っているかどうかの確認が試みられます。
これは、ユーザーの最初のアクセスであるため、ユーザーは認証のためにAccess Manager 11gアクセス・サーバーにリダイレクトされます。
アクセス・サーバーの資格証明コレクタ脚注2 ・コンポーネントによってログイン・フォームが表示されます。脚注3 ユーザーは、自身の資格証明をアクセス・サーバーに送信します。
アクセス・サーバーによって、ユーザーの資格証明が検証され、セキュリティ・トークン(Cookie)が生成されます。ユーザーは、ステップ1でアクセスを試みたリソースにリダイレクトされます。
Access Managerエージェントによってリクエストがインターセプトされ、セキュリティ・トークン(Cookie)が抽出されます。
Access Managerエージェントによってアクセス・サーバーにバック・チャネル呼出し脚注4 (TCPを介したOAP)が行われ、セッションが検証され、リクエストが認可されます。
アクセス・サーバーによって、そのWebリソースの構成済ポリシーに対してユーザーの権限が検証されます。
アクセス・サーバーは、WebGateリクエストに応答し、そのアクセスが許可されることを示します。
Access Managerエージェントによって、リクエストの通過が許可されます。脚注5
ユーザーは、手順1でアクセスを試みたWebリソースにアクセスできるようになります。
アクセス・サーバーと管理コンソールは、WebLogic Serverの提供するユーザー・インタフェースおよびコマンド行ツールから起動できます。
アクセス・サーバーは、障害の検出のためにロード・バランサで使用できるヘルス・チェック・リクエスト(HTTPを介したpingリクエスト)をサポートしています。
Access Managerエージェントは、保護されたアプリケーション環境に常駐するネイティブ・アプリケーションです。OAMの一部として提供されているツールはありませんが、環境固有のツールが使用可能な場合は、それが前述の目的で使用されます。
Access Managerは、サーバー・サイド・メトリック用(DMSを使用)にインスツルメント処理されており、この情報はWebLogic管理コンソールに公開されます。コンポーネントの監視のかわりとして、DMSメトリック収集を使用してエージェントおよびサーバー・コンポーネント・メトリックを監視できます。さらに、Access Managerは、きめ細かいリアルタイム・アクティビティ・トレースをサポートしており、それもコンポーネントの監視のかわりとして使用できます。
アクセス・サーバーは、起動時にバックエンド・リポジトリへの接続を初期化します。リポジトリに到達不能な場合、アクセス・サーバーはリポジトリへの接続を再試行します。この接続の再試行には指数関数的に増加するタイムアウトが使用されます。タイムアウトの上限は構成可能です。
アクセス・サーバーは、バックエンド接続が停止した場合はローカルにキャッシュしたデータに基づいてサービスの継続性を提供します。これは、キャッシュが失効するか、バックエンド接続が復活するまで継続されます。
Access Managerの構成アーティファクトには、次のファイルが含まれています。
DOMAIN_HOME/config/fmwconfig/oam-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がアイデンティティ・ストア、データベースおよびその他のエンティティへの接続に使用するストア・パスワードに使用されます。これは、エンド・ユーザー用のパスワードではありません。
Access Managerは、次の項目に対して外部ランタイム依存性があります。
LDAPベースのアイデンティティ・ストア
ユーザー・アイデンティティ・リポジトリ
ユーザー/ロールAPIによって抽象化されるLDAPアクセス
|
注意: Access Managerは、常に1つのアイデンティティ・ストアに接続しますが、そのアイデンティティ・ストアは物理サーバーまたはロード・バランサIPです。プライマリが停止した場合、Access Managerはロード・バランサに再接続し、ロード・バランサによってセカンダリに接続します。 |
OCSPレスポンダ・サービス
リアルタイムX.509認証検証
RDBMSポリシー・ストア
ポリシー(認証および認可)リポジトリ
OAMポリシー・エンジンによって抽象化されるRDBMSアクセス
Oracle Identity Manager (OIMベースのパスワード管理が有効化されている場合)
Oracle Identity Managerはパスワード管理サービスを提供します。これはOracle Access Manager 10g Identity Serverにかわるものです。
Oracle Identity Managerポリシー・ストア(Oracle Identity Managerベースのパスワード管理が有効化されている場合)
構成、メタデータなどを格納するために使用されるOblixスキーマ要素を含むLDAPリポジトリ
Oracle Adaptive Access Manager (Oracle Adaptive Access Managerの拡張認証スキームが選択されている場合)
Identity Federation (Identity Federationの認証スキームが選択されている場合)
この項では、Access Managerを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。
図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アプリケーションをホストする管理対象サーバーをデプロイします。これらの管理対象サーバーは、アクセス・サーバーがアクティブ/アクティブ的に動作できるように、クラスタにおいて構成されます。
Oracle WebLogic管理サーバーはOAMHOST1上で実行され、WebLogic管理コンソール、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Access Managementコンソールをデプロイします。管理サーバーは、OAMHOST2上でアクティブ/パッシブ・モードで実行するように構成できます。つまり、OAMHOST1が使用不可になった場合に、管理サーバーをOAMHOST2上で手動で起動できます。
ディレクトリ層で、仮想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データベースは、データ層における高可用性を提供します。
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インスタンスを削除できます。
高可用性アーキテクチャでは、OAMサーバーは、Oracle WebLogicクラスタにデプロイされますが、このクラスタには、その一部として少なくとも2つのサーバーが存在します。
デフォルトでは、WebLogic Serverによって、このアプリケーションに対する様々なライフサイクル・イベントの起動、停止、監視および管理が行われます。Access Managerアプリケーションは、基盤となるOracle WebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。
高可用性環境では、WebLogicノード・マネージャはWebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。
Access Managerが使用する標準Java EEアーティファクトは、Access ManagerがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソースなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、Access Managerコンポーネントで使用されるライブラリを同期します。
さらに、Access Managerのアプリケーション・レベルの構成は、Access Managerリポジトリに格納されます。すべてのクラスタ・メンバーへのAccess Managerの構成変更の伝播は、Coherence分散オブジェクト・キャッシュを活用する配布メカニズムに基づきます。すべてのAccess Managerコンポーネントは、変更イベントをCoherenceレイヤーから通知されて取得します。変更の原子性を確保するために、Access Managerコンポーネントには、変更が行われるたびにそれらの構成全体がリロードされます。
Access Managerの構成は、クラスタ内のすべてのインスタンスに適用されます。Access Managerでサポートされる前述の構成(インスタンス固有の構成)の例外は、Access Managerプロキシ・ホスト、Access Managerプロキシ・ポートおよびインスタンス固有のCoherence構成(Well Knownアドレス(WKA)が使用されている場合)のみです。プロキシ・ホストのIPアドレスおよびプロキシ・ポートは、構成ファイルに格納されます。Access Managerプロキシ・ポートは、エージェントからのOAPリクエストのエンドポイントです。Coherence WKAのIPアドレスも、構成ファイルに格納されます。Coherence WKAは、Access Manager固有のトラフィックを受信する権限を付与されたCoherenceノードを判別するために使用されます。oam-config.xmlファイルは、この構成情報を格納する構成ファイルです。
アクセス・サーバー・インスタンスの追加および削除は、クラスタ内の他のAccess Manager Access Serverインスタンスに対して透過的です。ただし、特定のアクセス・サーバーの削除が、エージェントのロード・バランシングとフェイルオーバーの特性に影響を与えないように注意してください。
Access Manager Access Serverを再起動しても、クラスタ内の他の実行中のコンポーネントやメンバーには影響ありません。
この項では、Oracle Identity Managementの高可用性クラスタ・デプロイメントによって、コンポーネントを障害から保護する仕組みと、コンポーネントの障害が発生したときに予想される動作について説明します。
WebLogic Serverインフラストラクチャにより、Identity Managementサービス・インフラストラクチャ・システムは、あらゆるプロセス障害から保護されます。
また、次の機能もAccess Managerの高可用性構成を障害から保護します。
バック・チャネルOAPバインディングでは、フェイルオーバーのためにプライマリ/セカンダリ・モデルが使用されます。フロント・チャネルHTTPバインディングでは、フェイルオーバーのためにロード・バランシング・ルーターが使用されます。
セッションの状態は、Coherence分散オブジェクト・キャッシュで保持され、それは、すべてのセッションの状態情報についてレプリケーションとフェイルオーバーを提供します。Coherenceキャッシュに格納されたデータは、データベースに非同期的に書き込まれます。このデータは、すべてのアクセス・サーバーが再起動されても保持されます。ただし、書込みの非同期的な性質により少量のデータが失われる可能性があります。
アクセス・サーバーで障害が発生した場合、そのサーバーへの永続接続を持つWebGateは、接続がタイムアウトするまで待機し、その後にセカンダリ(バックアップ)アクセス・サーバーに切り替えます。未処理のリクエストは、セカンダリ・サーバーにフェイルオーバーされます。
Access Manager Access Serverは、ハートビート・チェックをサポートしています。また、管理対象サーバー上のWebLogicノード・マネージャは、アプリケーションを監視して、そのアプリケーションを再起動できます。
WebLogic Serverノードに障害が発生すると、構成、再試行のタイムアウトおよび再試行の回数に基づいて外部接続のフェイルオーバーが行われます。Access Managerエージェントとアクセス・サーバーのフェイルオーバーはタイムアウトに基づいています。
ロード・バランシング・ルーターまたはプロキシ・サーバーがWebLogic Serverノードの障害を検出した場合、後続のクライアント接続は、アクティブ・インスタンスにルーティングされ、そのセッション状態を取得して処理を継続します。
接続の存続時間が期限切れした場合、保留中のリクエストは接続が終了する前に完了します。接続オブジェクトはプールに戻されます。
別のサービスから例外を受信した場合、Access Managerは、外部接続リクエストを再試行します。再試行回数は設定が可能です。
WLS_OAMxサーバーで障害が発生すると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。
HTTP Serverからの処理中のリクエストはタイムアウトして、新しいリクエストは他のWLS_OAMxサーバーに送られます。障害が発生したノードでサーバーが正常に再起動されると、Oracle HTTP Serverは、受信したリクエストのサーバーへのルーティングを再開します。
|
注意: Access Managerサーバーは、アクセス・サーバーがそのリクエストにサービスを提供できるかどうかを判別するため、ハートビート・チェックをサポートします。次のチェックを行います。
ハートビート・チェックに成功した場合、アクセス・サーバーはリクエストの処理が可能であり、リクエストがそれに送信されます。ハートビート・チェックで問題がある場合、リクエストはアクセス・サーバーにルーティングされません。 |
Access Managerサービス・インフラストラクチャは、マルチ・データ・ソースの使用によりデータベースの障害から保護されます。通常、これらのマルチ・データ・ソースは、システムの初期設定時に構成されます(Oracle Fusion Middleware構成ウィザードで、インストール時にこれらのマルチプールを直接定義できます)。これらのソースによって、Oracle RACデータベース・インスタンスで障害が発生した場合に、使用可能なデータベース・インスタンスとの接続が再確立されることが保証されるようになります。マルチ・データ・ソースを使用すると、Oracle RACデータベース内の複数のインスタンスへの接続を構成できます。
Oracle RACおよびMDSリポジトリでのマルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。
この項では、Access Managerで高可用性を得るためのデプロイメントを設定する高度な手順について説明します。このデプロイメントには、2つのOracle HTTP Serverが含まれており、それらは、リクエストを2つのOAMサーバーに配布します。これらのOAMサーバーは、Oracle Real Application Clusters (Oracle RAC)データベースおよび、(オプションで)外部LDAPストアと対話します。1つのコンポーネントで障害が発生しても、残りのコンポーネントは引き続き機能します。
この項には次のトピックが含まれます:
Access Managerを高可用性のために構成する前に、次の操作を実行しておく必要があります。
リポジトリ作成ユーティリティを実行して、データベースにAccess Managerのスキーマを作成します。第6.3.2項「リポジトリ作成ユーティリティの実行によるデータベース・スキーマの作成」を参照してください。
OAMHOST1およびOAMHOST2にOracle WebLogic Serverをインストールします。第6.3.3項「Oracle WebLogic Serverのインストール」を参照してください。
OAMHOST1およびOAMHOST2にOracle Identity Management実行可能ファイルをインストールします。第6.3.4項「Access Manager Application Tierのインストールと構成」を参照してください。
高可用性LDAP実装が使用可能であることを確認します。
作成するスキーマは、インストールおよび構成する製品により異なります。インストールする製品と互換性のあるバージョンのリポジトリ作成ユーティリティ(RCU)を使用します。RCU実行の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・プランニング・ガイド』および『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
Oracle WebLogic Serverをインストールする前に、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』で指定されているように、ご使用のマシンのシステム、パッチ、カーネルの要件、およびその他の要件が満たされていることを確認します。
インストーラを起動し、次の手順を実行します。
「ようこそ」画面で、「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で、「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。
ORACLE_BASE/product/fmw
|
注意: ORACLE_BASEは、Oracle製品のインストール先であるベース・ディレクトリです。このディレクトリは |
「次へ」をクリックします。
セキュリティ・アップデートが通知できるようにするために、連絡先情報を入力します。
「次へ」をクリックします。
「インストール・タイプの選択」画面で、「カスタム」を選択します。
「次へ」をクリックします。
「製品とコンポーネントの選択」画面で、「Oracle JRockit SDK」のみを選択し、「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、ディレクトリORACLE_BASE/product/fmw/wlserver_10.3を受け入れます。
「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「Quickstartの実行」の選択を解除します。
「完了」をクリックします。
この項では、Oracle Fusion MiddlewareコンポーネントをOAMHOST1およびOAMHOST2にインストールして構成する方法について説明します。
この項では、Oracle Identity Managementソフトウェアを、前に作成したMiddlewareホーム・ディレクトリにインストールする手順について説明します。OAMHOST1およびOAMHOST2上で手順を実行します。
/etc/oraInst.locファイルが存在している場合は、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在しない場合は、この手順をスキップできます。
次のようにOracle Fusion Middlewareのインストーラを起動します。
OAMHOST1> runInstaller
インストーラで、JRE/JDKの場所を入力するように求められたら、WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE/product/fmw/jrockit_160_<バージョン>のように入力します。
次の手順を実行します。
「ようこそ」画面で、「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を入力します。
Oracle Middlewareホーム: MW_HOMEのリストから前にインストールしたMiddlewareホームを選択します。次に例を示します。
/u01/app/oracle/product/fmw
Oracleホーム・ディレクトリ: idmを入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
「インストール完了」画面で「終了」をクリックします。
この項では、OAMHOST1にドメインを作成します。
次のコマンドを実行して、構成ウィザードを起動します。
MW_HOME/oracle_common/common/bin/config.sh
次の手順を実行します。
「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」画面で、次を選択します。
「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。
次の製品を選択します。
Oracle Enterprise Manager
Oracle JRF(デフォルトで選択)
Oracle Access Management
Oracle Platform Security Service
「次へ」をクリックします。
「ドメイン名と場所の指定」画面で、次を入力します。
ドメイン名: IDM_Domain
ドメインの場所: デフォルトを受け入れます。
アプリケーション・ディレクトリ: デフォルトを受け入れます。
「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。
WebLogicドメインの起動モード: 「本番モード」を選択します。
JDKの選択: 「JROCKIT SDK1.6.0_<バージョン>」を選択します。
「JDBCコンポーネント・スキーマの構成」画面で、すべてのデータ・ソースを選択し、「次のパネルで選択したデータ・ソースをRACマルチ・データ・ソースとして構成します。」を選択します。
「次へ」をクリックします。
「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、最初のデータ・ソースであるOAMインフラストラクチャを選択し、次の項目を入力します。
データ・ソース: OAM
サービス名: oam.example.com
ユーザー名: OAM_OAM (OAMがRCU接頭辞として使用されていたと想定)
パスワード: 前述のアカウント用のパスワード
右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。
ホスト名: OAMDBHOST1
インスタンス名: oamdb1
ポート: 1521
再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。
ホスト名: OAMDBHOST2
インスタンス名: oamdb2
ポート: 1521
「次へ」をクリックします。
「コンポーネント・スキーマのテスト」画面で、データ・ソースの検証が試行されます。
データ・ソースの検証が成功したら、「次へ」をクリックします。
失敗した場合は、「前へ」をクリックし、問題を修正して、やり直します。
「オプションの構成を選択」画面で、次を選択します。
管理サーバー
管理対象サーバー、クラスタ、およびマシン
「次へ」をクリックします。
「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: OAMHOST1.example.com
リスニング・ポート: 7001
SSLリスニング・ポート: 適用なし
SSL有効: 選択を解除
「次へ」をクリックします。
「管理対象サーバーの構成」画面で、トポロジのOAMHOSTごとにエントリを作成します。つまり、OAMHOST1上で実行されているOAMサーバーに対して1つと、OAMHOST2上で実行されているOAMサーバーに対して1つ作成します。
OAM_SERVERエントリを選択し、そのエントリを次の値に変更します。
名前: WLS_OAM1
リスニング・アドレス: OAMHOST1.example.com
リスニング・ポート: 14100
2つ目のOAM_SERVERに対して、「追加」をクリックし、次の情報を入力します。
名前: WLS_OAM2
リスニング・アドレス: OAMHOST2.example.com
リスニング・ポート: 14100
「次へ」をクリックします。
「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成します。
名前としてOAM_Clusterを入力します。
その他すべてのフィールドはデフォルトの設定のままにします。
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、次のように管理対象サーバーをクラスタに関連付けます。
右のウィンドウでクラスタ名OAM_Clusterをクリックします。
管理対象サーバーWLS_OAM1をクリックし、矢印をクリックしてそれをクラスタに割り当てます。
管理対象サーバーWLS_OAM2に対しても同様に繰り返します。
「次へ」をクリックします。
「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。ホストでUNIXベースのオペレーティング・システムを使用する場合は、「Unix」タブをクリックします。それ以外の場合は、「マシン」タブをクリックします。次の情報を指定します。
名前: ホスト名です。ベスト・プラクティスは、DNS名(OAMHOST1)を使用することです。
ノード・マネージャ・リスニング・アドレス: マシン(OAMHOST1.example.com)のDNS名。
ノード・マネージャ・ポート: ノード・マネージャが使用するポート。
OAMHOST2に対しても次のように手順を繰り返します。
名前: ホスト名です。ベスト・プラクティスは、DNS名(OAMHOST2)を使用することです。
ノード・マネージャ・リスニング・アドレス: マシン(OAMHOST2.example.com)のDNS名。
ノード・マネージャ・ポート: ノード・マネージャが使用するポート。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを指定します。
右のウィンドウでマシンOAMHOST1をクリックします。
左のウィンドウで管理対象サーバーWLS_OAM1をクリックします。
矢印をクリックし、その管理対象サーバーをホストOAMHOST1に割り当てます。
右のウィンドウでマシンOAMHOST2をクリックします。
左のウィンドウで管理対象サーバーWLS_OAM2をクリックします。
矢印をクリックし、その管理対象サーバーをホストOAMHOST2に割り当てます。
「次へ」をクリックします。
「構成のサマリー」画面で、「作成」をクリックし、作成プロセスを開始します。
|
注意: 構成を変更するためにconfig.shスクリプトを2回実行することはできないため、構成に追加の変更を行う場合は、Fusion Middleware ControlのMBeansブラウザの使用などの別のツールを使用する必要があります。 |
ドメインの構成後、管理サーバーを起動する前に、データベース・セキュリティ・ストアを構成する必要があります。詳細は、第5.3.4項「ドメイン用のデータベース・セキュリティ・ストアの構成」を参照してください。
この項では、OAMHOST1上の管理サーバーに対してboot.propertiesファイルを作成する方法について説明します。boot.propertiesファイルを使用すると、administratorのユーザー名とパスワードの入力を求められることなく管理サーバーを起動できます。
boot.propertiesファイルを作成する手順は次のとおりです。
OAMHOST1で、次のディレクトリに移動します。
MW_HOME/user_projects/domains/domainName/servers/AdminServer/security
例:
cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security
テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をこのファイルに入力します。
username=adminUserpassword=adminUserPassword
|
注意: 管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。 セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルを編集した後、できるだけ速やかにサーバーを起動し、エントリを暗号化してください。 |
管理サーバーが実行されている場合は停止します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。
MW_HOME/user_projects/domains/domainName/binディレクトリにあるstartWebLogic.shスクリプトを使用して、OAMHOST1の管理サーバーを起動します。
Webブラウザを開いて次のページにアクセスし、変更が正常に行われたことを確認します。
WebLogic Server管理コンソール:
http://oamhost1.example.com:7001/console
Oracle Enterprise Manager Fusion Middleware Control:
http://oamhost1.example.com:7001/em
weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。
この項では、OAMHOST1の起動手順について説明します。
コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行することによって行います。例:
OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh
次のコマンドを発行してノード・マネージャを起動します。
OAMHOST1> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh
OAMHOST1上のAccess Managerを起動する手順は、次のとおりです。
次のURLを使用して、WebLogic管理コンソールにログインします。
http://oamhost1.example.com:7001/console
WebLogic管理者のユーザー名とパスワードを指定します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
サーバーWLS_OAM1をクリックします。
「起動」をクリックします。
「OK」をクリックし、サーバーを起動することを確認します。
実装を検証するには、次のURLにあるOracle Access Managementコンソールに接続します。
http://OAMHOST1.example.com:7001/oamconsole
OAM管理コンソールのログイン・ページが開き、WebLogic administratorアカウントを使用してログインできる場合、実装は有効です。
OAMHOST1で構成を完了したら、それをOAMHOST2に伝播できます。これを実行するには、OAMHOST1でpackスクリプトを使用してドメインをパックし、OAMHOST2でunpackスクリプトを使用してドメインを解凍します。
スクリプトは両方とも、MW_HOME/oracle_common/common/binディレクトリにあります。
OAMHOST1で、次のように入力します。
pack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
-template=/tmp/idm_domain.jar -template_name="OAM Domain" -managed=true
これにより、/tmpディレクトリにidm_domain.jarというファイルが作成されます。このファイルをOAMHOST2にコピーします。
OAMHOST2で、次のように入力します。
unpack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
-template=/tmp/idm_domain.jar
この項では、OAMHOST2を起動する手順について説明します。
コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行することによって行います。例:
OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh
次のコマンドを発行してノード・マネージャを起動します。
OAMHOST2> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh
OAMHOST2上のAccess Managerを起動する手順は、次のとおりです。
次のURLを使用して、WebLogic管理コンソールにログインします。
http://oamhost2.example.com:7001/console
WebLogic管理者のユーザー名とパスワードを指定します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
サーバーWLS_OAM2をクリックします。
「起動」をクリックします。
「OK」をクリックし、サーバーを起動することを確認します。
次のURLを使用してOAMサーバーに接続することによって実装を検証します。
http://OAMHOST2.example.com:14100/oam/server/logout
OAMから正常にログアウトしたことを示すページが表示されると、実装は有効です。
この項では、Oracle HTTP Serverと連携するためのAccess Managerの構成手順について説明します。
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
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
WebLogicCluster oamhost1.example.com:14100,oamhost2.example.com:14100
</Location>
</VirtualHost>
WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。
WEBHOST1>opmnctl stopall WEBHOST1>opmnctl startall WEBHOST2>opmnctl stopall WEBHOST2>opmnctl startall
デフォルトでは、Access Managerではローカル・サーバーにあるログイン・ページにリクエストに送信します。高可用性デプロイメントでは、この設定を変更してログイン・ページ・リクエストがローカル・バランサに送信されるようにする必要があります。
Access Managerにロード・バランサを認識させる手順は、次のとおりです。
次のURLで、Oracle Access Managementコンソールにweblogicユーザーとしてログインします。
http://OAMHOST1.example.com:7001/oamconsole
「構成」タブをクリックします。
「Access Managerの設定」リンクをクリックします。
次の情報を入力します。
OAMサーバー・ホスト: sso.example.com
OAMサーバー・ポート: 7777
OAMサーバー・プロトコル: http
「適用」をクリックします。
管理対象サーバーWLS_OAM1およびWLS_OAM2を再起動します。
デフォルトでは、Access Managerでは、組込みLDAPサーバーにある独自コンポーネントを使用します。高可用性構成では、ディレクトリ・ストアとして外部LDAPディレクトリを使用することをお薦めします。この項では、外部LDAPストアの設定方法について説明します。
|
注意: この項で説明する手順を実行する前に、環境およびLDAPストアをバックアップしておくことをお薦めします。 |
アイデンティティ・ストアを事前構成することで、ディレクトリ・タイプに関係なくバックエンド・ディレクトリのスキーマを拡張します。
Access Managerのためにディレクトリ・スキーマを拡張するには、OAMHOST1上で次のタスクを実行します。
環境変数MW_HOME、JAVA_HOME、IDM_HOMEおよびORACLE_HOMEを設定します。
IDM_HOMEをIDM_ORACLE_HOMEに設定します。
ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。
次の項目を含む、プロパティ・ファイルextend.propsを作成します。
IDSTORE_HOST : idstore.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リコンシリエーション・ユーザーがあげられます。
idmConfigToolコマンドを使用して、アイデンティティ・ストアを作成します。このコマンドは、IAM_ORACLE_HOME/idmtools/binにあります。
コマンド構文は次のとおりです。
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
ログ・ファイルを確認して、エラーや警告を修正します。
Access Managerが必要とするユーザーをアイデンティティ・ストアに追加する手順は、次のとおりです。
環境変数MW_HOME、JAVA_HOME、IDM_HOMEおよびORACLE_HOMEを設定します。
IDM_HOMEをIDM_ORACLE_HOMEに設定します。
ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。
次の項目を含む、プロパティ・ファイルoam.propsを作成します。
IDSTORE_HOST : idstore.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サーバーに接続するために使用されます。
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
ログ・ファイルを確認して、エラーや警告を修正します。
idmConfigToolコマンドの詳細は、Oracle Fusion Middleware Oracle Identity Management Suite統合概要を参照してください。
ユーザー・アイデンティティ・ストアを作成する手順は、次のとおりです。
次のURLのOracle Access Managementコンソールに移動します。
http://adminvhn.example.com:7001/oamconsole
WebLogic管理ユーザーを使用してログインします。
「システム構成」→「データソース」を選択します。
「ユーザー・アイデンティティ・ストア」を選択して、「追加」をクリックします。次の情報を入力します。
ストア名: 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
「適用」をクリックします。
「接続テスト」をクリックし、LDAPサーバーへの接続を検証します。
LDAPアイデンティティ・ストアを定義したので、プライマリ認証ストアとして設定する必要があります。これを行うには、Oracle Access Managementコンソールで次の手順を実行します。
「システム構成」タブをクリックします。
ナビゲーション・ペインから「データ・ソース - ユーザー・アイデンティティ・ストア」を選択します。
「LDAP_DIR」をクリックします。
「オープン」を「アクション」メニューで選択します。
「デフォルト・ストアとして設定」をクリックします。
「システム・ストアとして設定」をクリックします。
「アクセス・システム管理者」の追加[+]アイコンをクリックします。
検索名フィールドにOAM*を入力して、「検索」をクリックします。
検索結果から「OAMAdministrators」を選択して、「選択済の追加」をクリックします。
「適用」をクリックします。
「システム管理者の検証」ウィンドウで、OAM管理者のユーザー名とパスワード(例: oamadmin)を入力します。
「検証」をクリックします。
「接続テスト」をクリックして接続をテストします。
デフォルトでは、Access Managerは、ユーザーの検証に統合LDAPストアを使用します。LDAP認証モジュールを更新して、そのモジュールが新しい外部LDAPストアに対してユーザーを認証できるようにします。
LDAP認証モジュールが外部LDAPを使用するように更新する手順は、次のとおりです。
「システム構成」タブをクリックします。
「Access Managerの設定」→「認証モジュール」→「LDAP認証モジュール」を選択します。
「LDAP」をクリックします。
「オープン」を「アクション」メニューで選択します。
「ユーザー・アイデンティティ・ストア」をLDAP_DIRに設定します。
「適用」をクリックします。
管理対象サーバーの管理サーバー、WLS_OAM1およびWLS_OAM2を再起動します。
Oracle Access Managementコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminとしてログインすることにより、構成を検証します。
高可用性環境では、OracleはOracle Coherenceを使用して構成ファイルの同期を保ちます。Oracle Coherenceは、デフォルトではポート9095を使用しますが、これはOracle Access Managementコンソールを使用して変更できます。
URL (http://admin.example.com/oamconsole)を使用して、コンソールにログインし、次の手順を実行します。
「システム構成」タブをクリックします。
ナビゲータでサーバーを展開します。
ポートを変更する管理対象サーバーをダブルクリックします。
「コヒーレンス」タブをクリックします。
「ローカル・ポート」の値を目的の値に変更します。
「適用」をクリックします。
管理サーバーと、更新された管理対象サーバーと同じクラスタに配置されている管理対象サーバーすべてを再起動します。
この項では、Access Managerの高可用性トポロジをスケール・アップおよびスケール・アウトする方法について説明します。すでに1つ以上のサーバー・インスタンスが実行されているノードに、新しいAccess Manager管理対象サーバー・インスタンスを追加するには、スケール・アップ操作を実行します。新しいノードに、新しいAccess Manager管理対象サーバー・インスタンスを追加するには、スケール・アウト操作を実行します。
OAMをスケール・アップする手順は、次のとおりです。
Oracle WebLogic Server管理コンソール(http://oamhost1.example.com:7001/console)にログインします。
管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
拡張するホスト上のサーバーを選択します(例: WLS_OAM1)。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3です。
サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意である必要があります。
「OK」をクリックします。
新しく作成したサーバーWLS_OAM3をクリックします。
SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAM3管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。OAMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。
Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。表の「名前」列で「WLS_OAM3」を選択します。
「SSL」タブをクリックします。「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。「保存」をクリックします。
構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
新しい管理対象サーバーをOAMに登録します。この時点で、Oracle Access Managementコンソールで、新しい管理対象サーバーをOAMサーバーとして構成する必要があります。
Oracle Access Managementコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminユーザーとしてログインします。
「システム構成」タブをクリックします。「サーバー・インスタンス」をクリックします。
「アクション」メニューから「作成」を選択します。
次の情報を入力します。
サーバー名: WLS_OAM3
ホスト: サーバーを実行するホスト。
ポート: 管理対象サーバーが作成されたときに割り当てられたリスニング・ポート
OAMプロキシ・ポート: OAMプロキシを実行するポート。これは当該ホストについて一意のポートです。
プロキシ・サーバーID: AccessServerConfigProxy
モード: オープン
「コヒーレンス」タブをクリックします。
「ローカル・ポート」をそのホストで一意の値に設定します。
「適用」をクリックします。
「適用」をクリックします。
これでアクセス・サーバーを起動できます。このアクセス・サーバーを使用するには、その存在をWebgateに通知する必要があります。この手順は次のとおりです。
Oracle Access Managementコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminユーザーとしてログインします。
「システム構成」タブをクリックします。
「アプリケーション管理」の下の「起動パッド」から、「SSOエージェント」をクリックして開きます。「SSOエージェント」ページで、「検索」をクリックします。
変更するWebゲートをダブルクリックします。
「追加」+アイコンをクリックして、新しいサーバーをプライマリまたはセカンダリ・サーバー・リストに追加します。
サーバー名をリストから選択します。
「適用」をクリックします。
スケール・アウトはスケール・アップとよく似ていますが、最初に新しいノードにソフトウェアをインストールする必要がある点が異なります。
第6.3.3項「Oracle WebLogic Serverのインストール」の手順に従い、新しいホストにOracle WebLogic Serverをインストールします。
新しいホストにIdentity Managementコンポーネントをインストールします。第6.3.4項「Access Manager Application Tierのインストールと構成」を参照してください。
Oracle WebLogic Server管理コンソール(http://oamhost1.example.com:7001/oamconsole)にログインします。
管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
拡張するホスト上のサーバーを選択します(例: WLS_OAM1)。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3です。
サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。
「OK」をクリックします。
新規作成したサーバーである「WLS_OAM3」をクリックします。
SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAM3管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。OAMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。
Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ペインで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
次のコマンドを使用してOAMHOST1上のドメインをパックします。
pack.sh -domain=ORACLE_BASE/admin/IDM_Domain/aserver/IDM_Domain -template =/tmp/idm_domain.jar -template_name="OAM Domain" -managed=true
pack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。
次のコマンドを使用して新しいホスト上でドメインを解凍します。
unpack.sh -domain=ORACLE_BASE/admin/IDM_Domain/mserver/IDM_Domain -template=/tmp/idm_domain.jar -template_name="OAM Domain" -app_dir=ORACLE_BASE/admin/IDM_Domain/mserver/applications
unpack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。
コンソールから管理対象サーバーを起動する前に、OAMHOST3上にノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binにあるsetNMProps.shスクリプトを実行することによって行います。次のように入力します。
MW_HOME/oracle_common/common/bin/setNMProps.sh
新しい管理対象サーバーをOAMに登録します。この時点で、Oracle Access Managementコンソールで、新しい管理対象サーバーをOAMサーバーとして構成する必要があります。
Oracle Access Managementコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminユーザーとしてログインします。
「システム構成」タブをクリックします。「サーバー・インスタンス」をクリックします。
「アクション」メニューから「作成」を選択します。
次の情報を入力します。
サーバー名: WLS_OAM3
ホスト: サーバーを実行するホスト、OAMHOST3。
ポート: 管理対象サーバーが作成されたときに割り当てられたリスニング・ポート。
OAMプロキシ・ポート: OAMプロキシを実行するポート。これは当該ホストについて一意のポートです。
プロキシ・サーバーID: AccessServerConfigProxy
モード: オープン
「適用」をクリックします。
Access Serverを起動します。このサーバーを使用するには、その存在をWebgateに通知する必要があります。
Oracle Access Managementコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminユーザーとしてログインします。
「システム構成」タブをクリックします。
「エージェント」→「OAMエージェント」→「10gエージェント」を展開します。
変更するWebゲートをダブルクリックします。
「追加」+アイコンをクリックして、新しいサーバーをプライマリまたはセカンダリ・サーバー・リストに追加します。
サーバー名をリストから選択します。
「適用」をクリックします。
Web層を更新します。これで、新しい管理対象サーバーが作成されて起動され、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,OAMhsot3.example.com:14300
</Location>
脚注
脚注 1: 使用されるエージェントはデプロイメント固有であり、デプロイメントによって(異なる機能を持つ)様々なタイプのエージェントを使用できます。