| Oracle® Fusion Middleware Oracle Identity and Access Managementサードパーティ・アプリケーション・サーバー・ガイド 11gリリース2 (11.1.2.1.0) B72797-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity and Access Managementサードパーティ・アプリケーション・サーバー・ガイド 11gリリース2 (11.1.2.1.0) B72797-01 |
|
前 |
次 |
この章では、IBM WebSphere上でAccess Managerを管理する場合の相違(WebLogic Serverの場合との)について説明します。
この章には次の項が含まれます:
Access Managerの次の機能は、Access ManagerがWebLogic Serverにデプロイされた場合にのみサポートされます。
OSSOエージェント - 非OHS httpサーバーではmod_ossoはサポートされません。WebSphere上のOAMの場合、パートナはIHSである必要があるためです。OSSO10gのOAM-WebSphereへの移行もサポートされません。また、OSSO10gはOC4Jでのみサポートされていました。これからOAM-WLSへの移行のみがサポートされます。
IAMSuiteエージェント - IAMSuiteエージェント(ドメイン・エージェント)は、WebLogic Serverについては非推奨のマークが付けられました。これはOAM-WASの最初のリリースなので、WAS上でのIAMSuiteエージェントのサポートはありません。Identity Managementのコンポーネントをフロントエンドするには、IHS WebGateを使用する必要があります。詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。
OAM NAP簡易モード - IBM JDKでは、NAP簡易モードに必要なアルゴリズムがサポートされていません。
OAMとOIMの統合のためのNAP自動ログイン - OAMとOIMの間での自動ログインはサポートされていますが、これはTAPフロント・チャネル統合に基づく必要があります。NAPに基づく自動ログインはWebLogic Serverではサポートされておらず、WebSphereでもサポートされません。
IDMドメイン・エージェント - Oracle Access ManagementをIBM WebSphereにデプロイするためにIDMドメイン・エージェントを削除したり無効にする必要はありません。
|
注意: OAMとOAAMの統合のために、TAPを使用したOAAMAdvancedSchemeが推奨されています。 |
IBM WebSphereのwsadminコマンドライン・インタフェースから、Oracle Access Managerのコマンドを実行できます。詳細は、「Oracle Fusion Middlewareのwsadminコマンドの使用」を参照してください。
Access Managerのコマンドの詳細は、WebLogic Scripting Toolコマンド・リファレンスを参照してください。Oracle Access Managementのコマンドの機能は、WebLogicでもWebSphereでも同じです。ただし、Access Managerのwsadminコマンドを実行するときには、コマンド名の先頭にAccess Managerのカテゴリ名Oamを付ける必要があります。例:
Oam.displayOAMMetrics()
WebSphereサーバーにオンライン・モードで接続するには、次のコマンドを使用します。
./wsadmin.sh -connType SOAP -host <HOST_NAME> -port <SOAP_PORT> -user <ADMIN_USER> -password <ADMIN_PASSWORD>
説明:
HOST_NAME、SOAP_PORT、ADMIN_USERおよびADMIN_PASSWORDには、使用している環境に合わせて正しい値を指定します。
domainRuntime()を取得するためのWebSphereメソッドはありません。そのため、必要な場合は引数としてdomainHomeを渡す必要があります。これは、オンライン・コマンドでもオフライン・コマンドでも必要です。WebSphereアプリケーション・サーバーのdomainHomeは次のとおりです。
<WAS_HOME>/profiles/<PROFILE_NAME>/config/cells/<CELL_NAME>
Oracle Access Managementサーバーに対する同時リクエストの数が多くなりすぎて、すべてのワーカー・スレッドが現在処理中の状態になると、ThreadPoolQueueIsFullExceptionエラーが発生することがあります。予想される同時リクエスト数に基づいてワーク・マネージャの構成を調整すれば、サーバーがより多くのリクエストを受け入れられるようになります。
これを行うには、次の手順に従います。
WebSphereアプリケーション・サーバーの管理コンソールにログインします。
「Resources」→「Asynchronous Beans」→「Work Managers」→「OAMServerWorkManager」を選択します。
OAMServerWorkManagerの最大スレッド数を50からもっと大きな値(たとえば500)に増やします。
x509を構成してリソースを保護するには、次の手順を実行します。
認証局を使用して、Oracle Access Managementサーバー・マシン用の署名付き証明書をWebSphereセル内に作成します。証明書の詳細にマシン名を含め、証明書を.p12形式で保存してください。
次のサンプル・コマンドに示すように、サーバー・ストアを作成します。
keytool -importkeystore -deststorepass samplepassword -destkeystore server.jks –srckeystore my-server.p12 – srcstoretype PKCS12 -srcstorepass samplepassword -alias "Server"
|
注意: keytoolユーティリティを使用して、鍵と証明書をJKS形式で作成して管理します。コマンドとオプションの詳細は、WebSphereアプリケーション・サーバーに付属のJDKのドキュメントを参照してください。 |
JAVA_HOME/binディレクトリに移動します。
次のコマンドを実行してトラスト・ストアを作成します。
keytool -import -alias trust -file scratch/simpleCA/ca.pem -keystore trust.jks
SSL証明書とクライアント証明書の両方を有効にする必要があるWebSphereサーバー・インスタンスを構成します。
キーストア・サーバー・ストアを追加します。
WebSphere管理コンソールで、「SSL certificate and key management」→「Key stores and certificates」→「New」を選択します。
フォームに必要な情報を入力し、サーバー・ストアのパスを指定します。
「Personal Certificates」をクリックし(「SSL certificate and key management」→「Key stores and certificates」→「server store name」→「Personal certificates」を選択して)、サーバー証明書が表示されることを確認します。表示されない場合は、サーバー・ストアからサーバー証明書をインポートします。
「Signer Certificate」ページを開き(「SSL certificate and key management」→「Key stores and certificates」→「server store name」→「Signer certificates」を選択して)、ルートCA証明書が表示されることを確認します。表示されない場合は、ルートCA証明書を追加します。
トラスト・ストアを追加します。
WebSphereの管理コンソールで、「SSL certificate and key management」→「Keystores and certificates」→「New」を選択します。
フォームに必要な情報を入力し、トラスト・ストアのパスを指定します。
「Signer Certificate」ページを開き(「SSL certificate and key management」→「Key stores and certificates」→「trust store name」→「Signer certificates」を選択して)、ルートCA証明書が表示されることを確認します。表示されない場合は、ルートCA証明書を追加します。
「SSL certificate and key management」→「Key stores and certificates」→「CellDefaultTrustStore」→「Signer certificates」を選択し、ルートCA証明書を追加します。
新しいSSL構成を作成して設定を調整します。
「SSL certificate and key management」→「SSL configurations」を選択します。
「New」をクリックします。
フォームに必要な情報を入力し、OAMサーバーの新しい構成を作成します。前述の手順で追加したトラスト・ストアとキーストアの名前を選択します。
「Quality of protection (QoP) settings」をクリックし(「SSL certificate and key management」→「SSL configuration」→「oam server ssl config name」→「Quality of protection (QoP) settings」を選択して)、「Client authentication」メニューから「Required」を選択します。
「Apply」をクリックします。
「SSL certificate and key management」→「Manage endpoint security configurations」を選択します。
インバウンド・エンドポイントを開き(「Inbound」→「DefaultCell(CellDefaultSSLSettings)」→「nodes」→「DefaultNode(NodeDefaultSSLSettings)」→「servers」)、oamサーバー・インスタンスをクリックして編集します。
「Specific SSL configuration for this endpoint」セクションで「Override inherited values」を選択し、「SSL configuration」メニューからOAMサーバーのSSL構成名を選択します。
「Apply」をクリックし、アウトバウンド・エンドポイントについて同じ手順を繰り返します。
ノードを同期化します。
nodeagentを再起動します。
Oracle Access Managementサーバーを再起動します。
認証局を使用して、署名付きのユーザー証明書を作成します。証明書がリクエストされる対象となるユーザー名を証明書の詳細に含め、証明書を.p12形式で保存してください。
証明書をブラウザにインストールします。
WebSphere上でSSLを有効にするには、次の場所にある.oamkeystoreおよびamtruststoreファイルに証明書ユーティリティのルート証明書を追加します。
<WAS_HOME>/profiles/Dmgr01/config/cells/DefaultCell01/fmwconfig
.oamkeystore / amtruststoreのパスワードを取得するには:
コマンドラインで、次のディレクトリに移動します。
$WAS_HOME/oracle_common/common/bin/
wsadmin.shコマンドを次のように実行します。
wsadmin.sh -conntype SOAP -port <SSL_SOAP_PORT> -user <username>
wsadminシェルから次のコマンドを実行します。
Opss.listCred(map="OAM_STORE", key="jks")
パスワードが表示されます。
CA証明書を.oamkeystore / amtruststoreファイルに追加するには:
次のサンプルkeytooコマンドに示すように、CA証明書を.oamkeystoreファイルおよびamtrustoreファイルに追加します。
|
注意: keytoolコマンドとオプションの詳細は、WebSphereアプリケーション・サーバーに付属のJDKのドキュメントを参照してください。 |
./keytool -importcert -alias ROOT_CA -file /scratch/CA/ca.pem -keystore <WAS_HOME>/Dmgr01/config/cells/DefaultCell01/fmwconfig/.oamkeystore -storepass oru8nd3hhd4t4nrmh6unhv825b -storetype jceks ./keytool -importcert -alias ROOT_CA -file /scratch/CA/ca.pem -keystore <WAS_HOME>/Dmgr01/config/cells/DefaultCell01/fmwconfig/amtruststore -storepass oru8nd3hhd4t4nrmh6unhv825b -storetype jks
|
注意: サンプルkeytoolコマンドの |
Oracle Access Management管理コンソールで、「ポリシー構成」→「共有コンポーネント」→「認証スキーム」→「X509Scheme」を選択します。
「チャレンジURL」ボックスで、値を管理対象サーバーのSSLポートに変更します。
例:
https://<管理対象サーバーのホスト名>:<管理対象サーバーのSSLポート番号>/oam/CredCollectServlet/X509
X509認証スキームを使用してリソースを保護するには、「ポリシー構成」→「アプリケーション・ドメイン」→「ドメイン名」→「認証ポリシー」→「保護リソース・ポリシー」を選択します。
「認証スキーム」メニューからX509スキームを選択します。
ユーザー証明書がインストールされているブラウザを使用して、リソースを開きます。
ブラウザから、接続に使用する証明書を選択するように求められます。
有効なユーザー証明書を選択して「OK」をクリックします。
リソースが表示されます。
RSA SecurID認証プラグイン(authn_securid)をWebSphere上にデプロイする場合は、次の要件に注意してください。
WebSphereで次のディレクトリ構造を作成し、エージェント構成ファイル(sdconf.rec)をoamディレクトリ内に配置します。
Fusion Middlewareのconfigディレクトリと相対的な次のパスを作成します。
fmwconfig/../../../servers/oam_server1/oam
または、プロファイル・ホーム・ディレクトリと相対的な次のパスを作成します。
<PROFILE_HOME>/servers/oam_server1/oam
|
注意: 詳細は、Oracle Access Management管理者ガイドのRSA SecurID認証用のAccess Managerの構成に関する項を参照してください。 |
次のサード・パーティJARファイルをダウンロードします。
authapi.jar
cryptoj.jar
これらのJARファイルを次のディレクトリに追加します。
fmwconfig/oam/plugin-lib
これは、カスタムRSAプラグインを実行するために必要な手順です。
WebSphere上で実行されているAccess ManagerをWindowsネイティブ認証(WNA)用に構成するには、キー・タブ・ファイルのパスを次の書式でoam-config.xmlファイル内に指定します。
file://<キー・タブ・ファイルのパス>
UNIX環境の場合は、次のようなパスを指定します。
<Setting Name="keytabfile" Type="xsd:string">file:///refresh/home/oam.keytab
</Setting>
Windows環境の場合は、次のようなパスを指定します。
<Setting Name="keytabfile" Type="xsd:string">file://C:\\dir\\oam.keytab
</Setting>
詳細は、Oracle Access Manager管理者ガイドのWindowsネイティブ認証のためのAccess Managerの構成に関する項を参照してください。
この項では、Access Managerをテスト環境から本番環境にコピーする方法について説明します。本番環境をテスト環境にコピーする場合にも、同じ手順を使用します。
この項の内容は次のとおりです。
Access Managerをソース環境からターゲット環境に移行できます。
Access Managerを移行すると、移行しなかった場合に移行元の環境でのカスタマイズや構成変更を移行先の環境にすべて再適用するために必要となる作業を最小限に抑えられます。ソース環境では、Access Managerのインストール、構成、カスタマイズおよび検証を行うことができます。システムが安定し、必要に応じて機能するようになったら、ターゲット環境を作成しますが、このとき、ソース環境に取り込んだすべての変更内容を再実行するかわりに、コンポーネントとその構成のコピーをソース環境から移行することでターゲット環境を作成できます。
Access Managerを1つのIBM WebSphere環境から別のWebSphere環境に移行する手順については、次の制約と制限事項があります。
この手順は、自身のポリシー・ストアがデータベース内に存在する場合に使用してください。この手順では、LDAPベースのポリシー・ストアをテストから本番に移行する方法は説明していません。
システム間でのユーザー・アイデンティティ・ストアの移行はサポートされていません。
この手順を使用してMobile and Socialをテストから本番に移行することはできません。
OracleがIBM WebSphere用に提供しているテストから本番への移行(T2P)用のコマンドは、WebLogic環境用と同じツールではありません。IBM WebSphere用のコマンドでは、環境間でファイルを移行するための完全レプリケーション・オプションやゴールデン・テンプレート・オプションはサポートされていません。
Access Managerをテスト環境から本番環境に移行する手順には、次のように多くのステップが含まれます。
テスト(ソース)システムで、exportConfigコマンドを実行します。
このコマンドでは、次が実行されます。
キーストア(たとえばoamkeystoreやコヒーレンス・キーストア)をエクスポートする。
OAM構成をエクスポートする
パスワード・ポリシーも含めたポリシーをエクスポートする
パートナをエクスポートする
エクスポートしたデータ用にwast2p.zipという名前のファイルを作成し、そのファイルを指定されたディレクトリに保存する
このコマンドの完了後、アーカイブは本番(ターゲット)システムに転送されます。
OPSSポリシー・ドメインをテスト・データベースからエクスポートし、OPSS暗号化鍵をエクスポートします。
本番(ターゲット)システムで、importConfigコマンドを実行します。
このコマンドでは、次が実行されます。
本番環境でwast2p.zipアーカイブを開く。
キーストアをインポートする
本番環境にインストールされたAccess Managerを更新することにより、OAM構成をインポートする
本番(ターゲット)システムで、updateConfigコマンドを実行します。
このコマンドでは、次が実行されます。
パスワード・ポリシーも含めたポリシーをインポートする
パートナをインポートする
MultiDataCenterクラスタIDを更新する
OracleAdminサーバー、管理対象サーバーおよびノード・エージェントを停止し、OPSS暗号化鍵をインポートします。
OPSSポリシー・データを本番(ターゲット)データベースにインポートします。
デプロイメント・マネージャを停止して起動します。Sync Node、ノード・エージェント、管理サーバーおよび管理対象サーバーを起動します。
この章で説明している手順を続行する前に、次の要件が満たされていることを確認してください。
Oracle Access Managementのインストール
Oracle Access Managementを本番(ターゲット)環境にインストールします。Oracle Access Managementのバージョンおよびビルド番号が、テスト環境と本番環境で一致していること、そしてすべての構成ファイルで一致していることを確認してください。
管理サーバーと管理対象サーバーが稼働中であることの確認
管理サーバーと管理対象サーバーが起動していて稼働中であることを確認します。
次の手順を順序どおりに実行します。
テスト(ソース)システムで、次のexportConfigコマンドを実行します。
Oam.exportConfig('<TargetDir>')
説明:
TargetDirは、アーカイブを保存するディレクトリのパスです。
例:
Oam.exportConfig('scratch/bkup')
前のステップで作成したアーカイブを本番環境に移行します。
OPSSポリシー・ドメインをテスト・データベースからエクスポートします。
使用しているデータベースに適したエクスポート方法を使用してください。例:
./expdp system/welcome1@orcl DIRECTORY=DATA_PUMP_DIR SCHEMAS=<OPSS_schema name>DUMPFILE=export.dmp PARALLEL=2 LOGFILE=export.log
oracle_common/common/binから次のwsadminコマンドを使用して、OPSS暗号化鍵をエクスポートします。
Opss.exportEncryptionKey('<jpsConfigFilePath>','<keyFilePath>', '<keyFilePassword>')
説明:
<jpsConfigFilePath>は、テスト環境内でのファイルの絶対位置です。
<keyFilePath>は、ewallet.p12ファイルが作成される場所となるテスト環境内のディレクトリです。このファイルの内容は、keyFilePasswordを使用して暗号化されて保護されます。
<keyFilePassword>は、fileewallet.p12ファイルを保護するために使用されるパスワードです。このファイルをインポートするときには、これと同じパスワードを使用する必要があります。
本番(ターゲット)環境で、importConfigコマンドを実行します。管理サーバーと管理対象サーバーが稼働している必要があります。次のコマンドを使用します。
Oam.importConfig('<ZipLocation>')
説明:
ZipLocationは、前のステップでコピーしたアーカイブ・ファイルがある場所のパスです。
例:
Oam.importConfig('scratch/bkup/wast2p.zip')
|
注意: 同期の問題のため、インポートを実行する前に本番環境でデプロイメント・マネージャを再起動する必要が生じる場合があります。 |
本番(ターゲット)環境で、updateConfigコマンドを実行します。管理サーバーと管理対象サーバーが稼働している必要があります。次のコマンドを使用します。
Oam.updateConfig('<ZipLocation>')
説明:
ZipLocationは、前のステップでコピーしたアーカイブがあるディレクトリのパスです。
|
注意: 同期の問題のため、更新を実行する前に本番環境で管理サーバーと管理対象サーバーを再起動する必要が生じる場合があります。 |
Oracle管理サーバーおよび管理対象サーバーを停止し、ノード・エージェントを停止します。
oracle_common/common/binから次のwsadminコマンドを使用して、OPSS暗号化鍵をインポートします。
Opss.importEncryptionKey('<PROD_jpsConfigFilePath>','<PROD_keyFilePath>',
'<keyFilePassword>')
説明:
<PROD_jpsConfigFilePath>は、本番環境内でのファイルの絶対位置です。
<PROD_keyFilePath>は、ewallet.p12ファイルが作成される本番環境内のディレクトリです。このファイルの内容は、keyFilePasswordを使用して暗号化されて保護されます。
<keyFilePassword>は、fileewallet.p12ファイルを保護するために使用されるパスワードです。
OPSSポリシー・データを本番データベースにインポートします。
使用しているデータベースに適したインポート方法を使用してください。例:
/impdp system/welcome1@orcl DIRECTORY=DATA_PUMP_DIR DUMPFILE=export.dmp PARALLEL=2 LOGFILE=import.log remap_schema=<Test schema name>_OPSS:<Prod schema name>_OPSS remap_tablespace=<Test schema name>_IAS_OPSS:<Prod schema name>_IAS_OPSS TABLE_EXISTS_ACTION=REPLACE
次の操作を実行します。
デプロイメント・マネージャを停止して起動します。
ノードを同期化します。
ノード・エージェントを起動します。
管理サーバーと管理対象サーバーを起動します。
