6.2 OAMサーバーの登録および管理の理解

Oracle Access Managementコンソールは、WebLogic管理サーバーと同じコンピュータにインストールして実行する必要があるJava EEアプリケーションです。WebLogic管理サーバーで実行する他の重要なアプリケーションには、WebLogic Server管理コンソールとFusion Middleware Control用のEnterprise Managerがあります。

Oracle Access Managementコンソールは、OAM管理サーバーと呼ぶこともあります。ただし、これはWebLogic管理対象サーバー上にデプロイされたOAMサーバーと同類ではありません。

Oracle WebLogic管理対象サーバーにデプロイされたOracle Access Management実行時インスタンスは、OAMサーバーと呼びます。OAMサーバーは、Access Managerに登録されている必要があります。これにより、認証時、認可時およびリソースへのアクセス時にエージェントとの通信が可能になります。

管理者はWebLogic Serverドメインを拡張して、別のOAMサーバー・インスタンスを必要に応じて次の方法で追加できます。

WebLogic Server管理コンソール。Oracle Access Managementコンソールを使用して、OAMサーバー・インスタンスを手動で登録した後で使用します。
WebLogic構成ウィザード
カスタマイズされたOracle WebLogicスクリプト・ツール(WLST)コマンド(『WebLogic Server WLSTコマンド・リファレンス』を参照)

最後の2つの方法では、Oracle Access Managementコンソールに表示されるOAMサーバー・インスタンスが自動的に登録され、他に必要なステップはありません。

関連項目:

Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド

この項では、Oracle Access Managementコンソールを使用したOAMサーバー・インスタンスの登録と管理の概要について説明します。

関連項目:

Access Manager 11gとOracle Access Manager 10gの比較については、Access Manager 11.1.2.3.0で使用できない機能を参照してください。

6.2.1 個々のOAMサーバー登録について

管理者は、1つ以上の管理対象サーバーをOracle Access ManagementのWebLogic Serverドメインに追加できます。

WebLogic構成ウィザードを使用するときに、OAMサーバーは自動的に登録されます。ただし、構成ウィザードを使用しない場合は、通信チャネルを開くためにOAMサーバーを手動で登録する必要があります。

または、OAM用のカスタムWLSTコマンドを使用して、サーバー登録を表示、編集または削除できます。すべての変更は自動的にOracle Access Managementコンソールおよびクラスタ内のすべてのOAMサーバーに伝播されます。

関連項目:

WebLogic Server WLSTコマンド・リファレンス

OAMサーバーのみがOracle Access Managementに登録されます。Oracle Access Managementコンソール(WebLogic管理サーバー上)は、自身には登録されません。

OAMサーバーの登録に使用された方法に関係なく、各インスタンスの詳細はOracle Access Managementコンソールの「システム構成」タブの「共通構成」セクションにあります。

サーバー名、ホスト、ポート
プロキシ: レガシー・アクセス・サーバーとして実行され、通信のセキュリティ・モードを定義します。詳細は、次を参照してください。
Oracle Coherence: セッション・データを含む様々なOAMサービスに分散されたキャッシュを提供します。

管理者は特定のインスタンス登録を検索し、新しくインストールされたOAMサーバーを登録して、Oracle Access Managementコンソールを使用してサーバー登録を表示、変更または削除できます。詳細は、「OAMサーバー登録のページ」を参照してください。

6.2.2 埋込みプロキシ・サーバーおよび下位互換性について

Oracle Access Managementのサーバー側コンポーネントには、Oracle Access Manager 10gポリシー強制エージェント(10g Webゲートおよびアクセス・クライアント)およびOracleAS SSO 10g mod_osso (11gではOSSOエージェントと呼びます)に加え、OpenSSOエージェントとの下位互換性を維持するための、プロキシ・サーバーが含まれています。

レガシー10g SSO: OAMプロキシは複数のアクセス・クライアントから同時にリクエストを受け入れることが可能で、すべてのWebゲートおよびアクセス・ゲート(11gではアクセス・クライアントと呼びます)がAccess Managerと情報交換できるようにします。詳細は、「OAMプロキシ設定」を参照してください。

レガシーOracleAS 10g (OSSO): 統合されたOSSOプロキシは、Access Manager使用時のOSSOエージェントを使用した認証中に、トークン生成およびトークン・リクエストに応じた検証を処理します。OSSOプロキシに構成は必要ありません。「エージェントおよび登録の概要」および「OAM 11gエージェントの登録および管理」の説明に従って、OSSOエージェントの登録のみを行います。

6.2.3 OSSO 10gとの組合せにおける11g SSOと古い10g SSOについて

古いデプロイメントにOracle Access Manager 10gが統合され、OracleAS (OSSO) 10gとともに使用されている場合、OracleAS SSOをアップグレードして、Access Manager SSOを使用できます。

Access Manager 11gを使用するためにOSSOをアップグレードすると、10g Webgatesを同じデプロイメント内のAccess Manager 11g SSOとともに動作させることができます。この場合は、OAMプロキシが必要に応じてOAM 10gアクセス・サーバーまたはAccess Manager 11gのどちらかにリクエストを転送します。

Oracle Access Manager 10g ObSSOCookieは、暗号化されたセッション・ベースのシングル・サインオンCookieであり、ユーザーの認証が成功すると生成されます。10g ObSSOCookieはユーザー・アイデンティティ・ストア情報を格納し、必要があればユーザーはそれをキャッシュ化できます。

統合されたOAMプロキシは、10g ObSSOCookieのAES暗号化アルゴリズムをサポートして、リリース10g Webgateとの下位互換性を可能にします。10g Accessサーバーは、OAMプロキシによって作成されたCookieを復号化できます(その逆も可)。これにより、Access Manager 11gで認証を実行し、Oracle Access Manager 10gで認可を実行できます(この逆も可能です)。

ノート:

OAMプロキシによって作成されたAccess Manager 11g ObSSOCookieは、アクセス・サーバーによって作成された10g ObSSOCookieと互換性があります。

詳細は、「OAMプロキシ設定」を参照してください。

6.2.4 OAMサーバーとWebゲート間の通信について

OAMサーバーの通信モードは、エージェント登録が成功した後に変更できます。Webゲートのモードは、サーバーがエージェントと引き続き通信するためにOAMサーバーのモードと同じかそれより上のレベルである必要があります。

OAPチャネルの通信モードには次のものがあります。

オープン: 通信のセキュリティがデプロイメントで問題にならない場合、この暗号化されていないモードを使用してください。
簡易: 認証局(CA)を自分で管理せずに証明書パスワードをプレーン・テキストとして送信するなど、セキュリティ上の考慮事項がある場合に、このオラクル社が署名する証明書モードを使用します。
証明書: OAMサーバーとWebゲートで異なる証明書を使用し、信頼できるサード・パーティの認証局にアクセスできる場合は、これを使用します。

個々のOAMサーバー登録で、セキュリティ・モードは「プロキシ」タブで定義されます("「OAMサーバー登録のページ」を参照してください)。

「簡易」と「証明書」のモードには以下が必要です。

すべてのOAMサーバーとWebゲートに共通のセキュリティ・パスワード(「OAMプロキシの簡易および証明書モード・セキュリティのアクセス・プロトコルの管理」を参照)。
適切に署名されたX.509デジタル証明書(「通信の保護」を参照)。

少なくとも1つのOAMサーバー・インスタンスが、エージェント登録時にエージェントと同じモードで実行中である必要があります。そうでなければ、エージェント登録が失敗します。ただし、エージェント登録の後に、OAMサーバーの通信モードは変更できます。エージェントとサーバー間の通信は、WebgateモードがOAMサーバーのモードと同じか、またはそれ以上であれば続けて機能します。エージェント・モードは高くでも問題ありませんが、低くすることはできません。たとえば、OAMサーバーのモードがオープンの場合、エージェントは3つのモードのどれでも通信することができます。OAMサーバー・モードが簡易の場合、エージェントは簡易または証明書を使用できます。OAMサーバー・モードが証明書の場合、エージェントは証明書モードを使用する必要があります。

関連項目:

通信の保護

6.2.5 サーバーの再起動が必要になる条件

Oracle Access Managementのほとんどの機能サービスでは、OAMサーバーを再起動することなく、Oracle Access Managementコンソールから行った変更を反映します。

表6-1に、サーバーの再起動が必要になる条件を示します。

表6-1 サーバーの再起動が必要になる条件

イベント	説明
セッション永続性の変更	セッションの永続性をデータベースからメモリー内(またはその逆)に変更すると、OAMサーバーの再起動が必要になります。
Oracle Coherenceのポート番号	ポート番号を変更すると、OAMサーバーの再起動が必要になります。
ロード・バランサ・サーバーの定義	変更すると、OAMサーバーの再起動が必要になります。
管理対象サーバーのポート番号	変更すると、OAMサーバーの再起動が必要になります。
新しい管理対象サーバー	新しい管理対象サーバーをクラスタに追加したときには、AdminServerを再起動してポリシーの取得を可能にする必要があります。 Oracle Coherenceのセキュリティ構成を新しく組み込んだサーバーを含めて再初期化するために、OAMサーバーを再起動する必要があります。