| Oracle® Fusion Middleware Oracle Identity Governanceの管理 12c (12.2.1.3.3) E88285-04 |
|
 前 |
 次 |
次の項では、これらの構成変更について説明します。
注意:
この項では、コマンド内にpasswordが含まれるコマンド例がいくつかあります。これらはコマンドを実行する前に実際のパスワードに置き換える必要があります。
Oracle Identity Governanceでは様々なホスト名とポートが構成に使用されています。ホスト名とポートに対応する変更が、Oracle Identity GovernanceとOracle WebLogicの構成で必要になります。
この項では、Oracle Identity GovernanceおよびOracle WebLogicで対応する構成の変更を行う方法について説明します。次の項目が含まれます。
Oracle Identity Governanceのホストとポートの変更には、Oracle Identity Governance構成でのOimFrontEndURLとbackOfficeURLの変更、ヒューマン・タスク構成でのタスク詳細URLの変更、WebLogic管理コンソールでのOIGサーバー・ポートの変更が含まれます。
この項では、Oracle Identity Governanceのホストとポートの変更について説明します。内容は次のとおりです。
注意:
Oracle Identity Governanceの追加ノードを追加または削除する場合は、この項で説明する手順を実行して、Oracle Identity Governanceのホストとポートの変更を構成してください。
OimFrontEndURLは、Oracle Identity Governance UIにアクセスするために使用するURLです。これは、アプリケーション・サーバーでロード・バランサまたはWebサーバーが使用されている場合は、それに応じてロード・バランサURLまたはWebサーバーURL、そうでない場合は単一アプリケーション・サーバーURLです。これはOracle Identity Governanceによって、通知メールやSOA呼出しのコールバックURLに使用されます。
クラスタ化環境でのOracle Identity GovernanceデプロイメントのWebサーバー用ホスト名またはポートの変更、または非クラスタ化環境でのOracle Identity GovernanceデプロイメントのWebLogic管理対象サーバー用ホスト名またはポートの変更により、変更が必要になる場合があります。
注意:
OimFrontEndURLを変更するには、この項で説明する手順と「WebLogic管理コンソールでのOIMサーバー・ポートの変更」の手順を実行します。Oracle Identity Governance構成のOimFronEndURLを変更するには:
backOfficeURLの変更は、Oracle Identity Governanceがフロントオフィス構成およびバックオフィス構成にデプロイされる場合のみ必要になります。この変更は、単純なクラスタ化デプロイメントまたは非クラスタ化デプロイメントには適用されません。このURLは、フロントオフィス・コンポーネントからバックオフィス・コンポーネントにアクセスするために、Oracle Identity Governanceで内部的に使用されます。バックオフィスにサーバーを追加する場合や、バックオフィスからサーバーを削除する場合は、バックオフィス構成およびフロントオフィス構成の実装中にこの属性の値を変更します。
backOfficeURL属性の値を変更するには:
タスクの詳細URLは、受信箱内の特定のヒューマン・タスクについてのタスクの詳細ページのURLです。これは、アプリケーション・サーバーでロード・バランサが使用されているか、Webサーバーが使用されているかよって、ロード・バランサURLまたはWebサーバーURLになり、そうでない場合は、単一のアプリケーション・サーバーURLになります。
クラスタ化環境でのOracle Identity GovernanceデプロイメントのWebサーバー用ホスト名またはポートの変更、または非クラスタ化環境でのOracle Identity GovernanceデプロイメントのWebLogic管理対象サーバー用ホスト名またはポートの変更により、変更が必要になる場合があります。
ヒューマン・タスク構成でタスクの詳細URLを変更するには:
データベースのホスト名とポート番号の変更は、データソースのoimJMSStoreDS、oimAuthenticatorProvider、DirectDBや、正しくないデータベース構成など、構成の様々な箇所で発生することがあります。
この項では、データベースのホスト名とポート番号が使用される構成エリアについて説明します。
Oracle Identity Governanceのインストール後に、データベースのホスト名またはポート番号を変更した場合は、次の変更が必要になります。
注意:
データベースのホストおよびポートを変更する前に、Oracle Identity Governanceをホストする管理対象サーバーを停止してください。ただし、Oracle WebLogic管理サーバーは稼動したままでかまいません。
データソースoimJMSStoreDSの構成を変更するには:
データソースsoaOIMLookupDBの構成を変更するには:
データソースoimOperationsDBの構成を変更するには:
データソースApplicationDBの構成を変更する手順は次のとおりです。
Oracle Identity Governanceのメタデータ・ストア(MDS)構成に関連するデータソースを変更するには:
注意:
この手順が必要なのは、MDSスキーマのデータベース・ホストおよびポートが変更される場合のみです。
OIMAuthenticationProviderの構成を変更するには:
注意:
サービス指向アーキテクチャ(SOA)やOracle Web Services Manager (OWSM)で構成変更を行うと、SOAまたはOWSMに関連するデータソースにも同様の変更を行う必要があります。
データソースの変更後、Oracle WebLogic管理サーバーを再起動し、Oracle Identity Governanceの管理対象WebLogicサーバーを起動します。
注意:
OIM App構成MBeansを使用してEnterprise Management (EM)コンソールからOracle Identity Governanceアプリケーション構成情報を変更するには、1つ以上のOracle Identity Governance管理対象サーバーが実行されている必要があります。稼動していない場合、EMコンソールからOIM App Config MBeansを確認できません。
DirectDBの構成を変更するには:
注意:
Oracle Identity Governanceの単一インスタンスのデプロイメントをOracle Real Application Clusters (Oracle RAC)に変更する場合、またはOracle RACを単一インスタンスのデプロイメントに変更する場合は、oimJMSStoreDS、 oimOperationsDBおよびmds-oimデータソースを変更してください。これらのデータソースをマルチデータソース構成に変更するための一般的な変更に加えて、OIMAuthenticationProviderとドメイン資格証明ストア構成をOracle RACのURLに合わせて変更してください。これらの一般的な変更の詳細は、『Oracle Identity and Access Management高可用性ガイド』を参照してください。
データベースのポートの変更の詳細は、「Oracle Identity Governanceデータベースのホストとポートの変更」を参照してください。
BI PublisherのOracle Identity Governanceデータベース・ホストおよびポートを変更するには:
Oracle Identity Governanceが変更対象の現在データベースではなく別のOracle Identity Governanceインスタンスの別のデータベースを指すよう設定されている場合、次の追加手順を実行します。
宛先DBにインストールされているOracle Identity GovernanceからソースOracle Identity Governanceデプロイメントへ.xldatabasekeyをコピーします。宛先からソースのOracle Identity GovernanceへDOMAIN_HOME/config/fmwconfig/.xldatabasekeyをコピーします。
宛先DB上のOracle Identity Governanceデプロイメントからソース・デプロイメントへ次のキーをコピーします。
OIMSchemaPassword
.xldatabasekey
DataBaseKey
宛先DBにインストールされているOracle Identity GovernanceからOracle Identity Governance資格証明ストアを取得するには:
次のURLを使用して、Oracle Enterprise Managerにログインします。
http://HOST:ADMIN_SERVER_PORT>/em
WebLogicドメインに移動し、「DOMAIN_NAME」を右クリックし、「システムMBeanブラウザ」を選択します。
「アプリケーション定義のMBean」で、「com.oracle.jps」→「サーバー: OIM_SERVER_NAME」→「JpsCredentialStore」に移動します。
「操作」→「getPortableCredentialMap」に移動します。パラメータ値として「oim」および「Invoke」を入力します。
これにより、oim資格証明マップが表示されます。OIMSchemaPassword、.xldatabasekey、およびDataBaseKeyのパスワードをメモします。
ソース・デプロイメント上のOIM資格証明ストア内のキーを変更するには:
OIMSchemaPassword: WebLogicドメインに移動し、「DOMAIN_NAME」を右クリックし、「セキュリティ」→「資格証明」に移動します。「oim」を開いて、「OIMSchemaPassword」をクリックします。「編集」をクリックし、「パスワード」および「パスワードの確認」フィールドに新規パスワードを入力します。
.xldatabasekey: .xldatabasekeyに対して同じ手順を繰り返します。
DataBaseKey: DataBaseKeyに対して同じ手順を繰り返します。
LDAP同期が有効な場合、Oracle Identity Governanceは、Oracle Virtual Directory (OVD)を介してディレクトリ・サーバーに接続します。この接続は、LDAP/LDAPSプロトコルを使用して行われます。
OVDのホストとポートを変更するには:
Oracle Identity System Administrationにログインします。
「プロビジョニング構成」で、「ITリソース」をクリックします。
「ITリソース・タイプ」リストから「ディレクトリ・サーバー」を選択し、「検索」をクリックします。
ディレクトリ・サーバーのITリソースを編集します。これを行うには、次のようにします。
「SSLの使用」フィールドの値がFalseに設定されている場合は、サーバーURLフィールドを編集します。「SSLの使用」フィールドの値がTrueに設定されている場合は、「サーバーSSLのURL」フィールドを編集します。
「更新」をクリックします。
BI Publisherのホストとポートはjms_cluster_config.propertiesファイルで変更できます。その後、BI Publisherサーバーを再起動する必要があります。
BI Publisherのホストとポートを変更するには:
WebLogic管理サーバーとOracle Identity Governance管理対象サーバー(クラスタ化デプロイメントの場合は少なくとも1つのサーバー)が稼働しているときに、次のURLを使用してEnterprise Managerにログインします。
http://ADMIN_SERVER/em
「Identity and Access」→「OIM」に移動します。
「OIM」を右クリックし、「システムMBeanブラウザ」に移動します。
「アプリケーション定義のMBeans」で、「oracle.iam」→「アプリケーション:OIM」→「XMLConfig」→「構成」→「XMLConfig.DiscoveryConfig」→「検出」に移動します。
BIPublisherURL属性に新しい値を入力し、「適用」をクリックして変更を保存します。
jms_cluster_config.propertiesファイル内のBI Publisherのホストとポートを変更するには:
DOMAIN_NAME/config/bipublisher/repository/Admin/Scheduler/ディレクトリに移動します。
テキスト・エディタで、jms_cluster_config.propertiesファイルを開き、BI Publisherのホストとポートを置き換えます。
jms_cluster_config.propertiesファイルを保存します。
BI Publisherサーバーを再起動します。
SOA JNDIProviderのホストとポートは、他のSOAノードの追加または削除時に変更します。
SOAのホストとポートを変更するには:
注意:
追加のSOAノードを追加または削除したときには、この手順を実行してSOAのホストとポートを変更してください。
WebLogic管理サーバーとOracle Identity Governance管理対象サーバー(クラスタ化デプロイメントの場合は少なくとも1つのサーバー)が稼働しているときに、次のURLを使用してEnterprise Managerにログインします。
http://ADMIN_SERVER/em
「Identity and Access」→「OIM」に移動します。
「OIM」を右クリックし、「システムMBeanブラウザ」に移動します。
「アプリケーション定義のMBeans」で、「oracle.iam」→「アプリケーション:OIM」→「XMLConfig」→「構成」→「XMLConfig.SOAConfig」→「SOAConfig」に移動します。
Rmiurl属性の値を変更し、「適用」をクリックして変更を保存します。
Rmiurl属性は、SOA管理対象サーバーにデプロイされたSOA EJBにアクセスするために使用されます。これは、アプリケーション・サーバーのURLです。Oracle Identity Governanceのクラスタ化デプロイメントの場合は、すべてのSOA管理対象サーバーURLのカンマ区切りのリストです。この属性の値は、たとえば次のようになります。
t3://mysoa1.mydomain.com:8001
t3s://mysoaserver1.mydomain.com:8002,mysoa2.mydomain.com:8002
t3://mysoa1.mydomain.com:8001,mysoa2.mydomain.com:8002,mysoa3.mydomain.com:8003
SOA JNDIProviderのホストとポートを変更します。これを行うには、次のようにします。
WebLogic管理コンソールにログインします。
「ドメイン構造」セクションで、「OIM_DOMAIN」→「サービス」、「外部JNDIプロバイダ」に移動します。
「ForeignJNDIProvider-SOA」をクリックします。
「構成」タブで、「一般」サブタブがアクティブであることを確認します。
「プロバイダURL」の値をステップ5で指定したRmiurlに変更します。
Oracle Identity Governance構成では、構造上の要件やミドルウェア要件を満たすために、様々なパスワードが使用されます。
この項では、デフォルトのパスワードと、依存製品または統合された製品でパスワードが変更された場合の、Oracle Identity GovernanceおよびOracle WebLogic構成のパスワードの変更方法について説明します。
この項は次のトピックで構成されています:
Oracle WebLogicの資格証明は、外部JNDIプロバイダとCSFのSOAAdminPasswordで変更する必要があります。
Weblogicの資格証明は、次のような場所で更新する必要があります。
外部JNDIプロバイダ。これを行うには、次のようにします。
WebLogic管理コンソールにログインします。
「ドメイン構造」セクションで、「OIM_DOMAIN」→「サービス」→「外部JNDIプロバイダ」に移動します。
「ForeignJNDIProvider-SOA」をクリックします。
「構成」タブで、「一般」サブタブがアクティブであることを確認します。
「パスワード」フィールドおよび「パスワードの確認」フィールドで、weblogicユーザーの新規パスワードを指定します。
CSF内のSOAAdminPassword。詳細は、「資格証明ストア・フレームワークのOracle Identity Governanceパスワードの変更」を参照してください。
WebLogic管理コンソールを使用してWebLogic管理者のパスワードを変更します。
Oracle WebLogic管理者パスワードを変更するには:
WebLogic管理コンソールにログインします。
「セキュリティ・レルム」→「myrealm」→「ユーザーとグループ」→「weblogic」→「パスワード」に移動します。
「新規パスワード」フィールドに、新しいパスワードを入力します。
「新規パスワードの確認」フィールドに、新しいパスワードを再入力します。
「適用」をクリックします。
Oracle Identity Governanceのインストール中に、インストーラによりOracle Identity Governanceの管理者パスワードの入力を求められます。この管理者パスワードは、必要に応じてインストール完了後に変更できます。
変更するには、Oracle Identity Governanceセルフ・サービスにOracle Identity Governance管理者としてログインする必要があります。管理者パスワードの変更の詳細は、Oracle Identity Governanceでのセルフ・サービス・タスクの実行のエンタープライズ・パスワードの変更に関する項を参照してください。
Oracle Identity Governanceのシステム管理者のパスワードを変更するときには、CSFのoracle.wsm.securityマップでOIMAdminキーのパスワードも更新する必要があります。
注意:
OAMまたはOAAMがOracle Identity Governanceに統合されている場合は、これらのアプリケーションで対応する変更を行う必要があります。詳細は、次のURLのOracle Technology Network (OTN) WebサイトにあるOAMおよびOAAMのドキュメントを参照してください。
http://www.oracle.com/technetwork/indexes/documentation/index.html
システム管理者のデータベース・パスワードをリセットできるのは、Oracle Identity Governanceのスタンドアロン・デプロイメントおよびOAMと統合されたデプロイメントです。
この項では、次の各トピックで、Oracle Identity Governanceのパスワードのリセットについて説明します。
この項では、次の各タイプのデプロイメントでの、Oracle Identity Governanceのパスワードのリセットについて説明します。
LDAP同期のないOracle Identity Governanceデプロイメント
LDAP同期が有効になっているOracle Identity Governanceデプロイメント
Access Manager (OAM)と統合されているOracle Identity Governanceデプロイメント
システム管理者のパスワードをリセットするには、OIM_HOME/server/bin/ディレクトリに格納されているoimadminpasswd_wls.shユーティリティを使用します。oimadminpasswd_wls.shユーティリティを実行するための手順は、LDAP同期が有効になっているOracle Identity Governanceと、LDAP同期が有効になっていないOracle Identity Governance、どちらのタイプのデプロイメントでも同じです。
システム管理者のデータベース・パスワードをリセットする手順は次のとおりです。
Oracle Identity GovernanceがOAMと統合されている場合は、Oracle Internet DirectoryなどのLDAPディレクトリが、すべての認証目的に使用されます。したがって、Oracle Identity Governanceの管理者xelsysadmのパスワードがLDAPでリセットされます。Oracle Identity Governanceデータベースに存在しているxelsysadmのパスワードはこのトポロジで使用されていませんが、LDAPディレクトリでもリセットされ、両方のリポジトリでパスワードが同期するようになります。
Oracle Identity GovernanceデプロイメントがAccess Managerと統合されているときにシステム管理者のデータベース・パスワードをリセットする手順は次のとおりです。
Oracle Identity Governanceでは2つのデータベース・スキーマを使用して、Oracle Identity Governanceの操作データおよび構成データを格納します。Oracle Identity Governance MDSスキーマを使用して構成関係の情報を格納し、Oracle Identity Governanceスキーマを使用してその他の情報を格納します。スキーマ・パスワードを変更すると、Oracle Identity Governance構成も変更する必要があります。
Oracle Identity Governanceデータベース・パスワードを変更すると、次の変更を行う必要があります。
Oracle Identity Governanceデータベース・パスワードを変更したら、WebLogic管理サーバーを再起動します。またOracle Identity Governanceが管理するWebLogicサーバーも同様に起動します。
注意:
データベース・パスワードを変更する前に、Oracle Identity Governanceをホストする管理対象サーバーを停止してください。ただし、Oracle WebLogic管理サーバーは稼動したままでかまいません。
データソースoimJMSStoreDSの構成を変更するには:
データソースApplicationDBの構成を変更する手順は次のとおりです。
データソースsoaOIMLookupDBの構成を変更するには:
データソースoimOperationsDBの構成を変更するには:
Oracle Identity Governance MDSに関連するデータソースの構成を変更するには:
注意:
Oracle Real Application Clusters (Oracle RAC)構成を使用したOracle Identity Governanceのデプロイメントでは、各マルチデータソース構成の下にあるすべてのデータソースを変更する必要があります。
SOAまたはOWSMに関連するデータソースでも、必要に応じて同様の変更を行ってください。
OIMAuthenticationProviderの構成を変更するには:
インストール・プロセスでは、Oracle Identity Governanceインストーラによって複数のパスワードが格納されます。資格証明ストア・フレームワーク(CSF)には様々な値がキーおよび値として格納されています。
表24-1にキーとその対応する値を示します。
表24-1 CSFキー
| キー | 説明 |
|---|---|
DataBaseKey |
データベースの暗号化に使用されるキーのパスワード。パスワードは、インストーラでOracle Identity Governanceキーストアに入力されたユーザー入力値です。 |
.xldatabasekey |
データベース暗号化キーを格納するキーストアのパスワード。パスワードは、インストーラでOracle Identity Governanceキーストアに入力されたユーザー入力値です。 |
xell |
xellキーのパスワードで、Oracle Identity Governanceコンポーネント間の通信を保護するために使用されます。Oracle Identity Governanceインストーラによって生成されるデフォルトのパスワードは、xellerateです。 |
default_keystore.jks |
JKSキーストアdefault_keystore.jksのパスワードで、DOMAIN_HOME/config/fmwconfig/ディレクトリにあります。パスワードは、インストーラでOracle Identity Governanceキーストアに入力されたユーザー入力値です。 |
SOAAdminPassword |
パスワードはインストーラで「SOA管理者パスワード」フィールドに入力されたユーザー入力値です。 |
OIMSchemaPassword |
Oracle Identity Governanceデータベース・スキーマに接続するためのパスワードです。パスワードはインストーラで「OIMデータベース・スキーマのパスワード」フィールドに入力されたユーザー入力値です。 |
JMSKey |
パスワードは、インストーラでOracle Identity Governanceキーストアに入力されたユーザー入力値です。 |
CSFでOracle Identity Governanceパスワードを変更するには、ディレクトリ・サーバーITリソースを編集します。
CSFキーの値を変更するには:
ディレクトリ・サーバーITリソースを編集し、新しいOVDパスワードを「管理パスワード」フィールドに指定します。
OVDパスワードを変更するには:
SSOが有効であり、OAMと統合されたOracle Identity GovernanceデプロイメントでLDAPのOracle Identity Governanceシステム管理者パスワードを変更するには、LDAPでユーザーのdnを検索し、新しいパスワードを含む一時ファイルを作成し、そのファイルを使用してパスワードを変更します。
SSOが有効であり、Access Manager (OAM)と統合されたOracle Identity GovernanceデプロイメントでLDAPのOracle Identity Governanceシステム管理者パスワードを変更するには:
SSOが有効であり、OAMと統合されたOracle Identity GovernanceデプロイメントでLDAPのOracle Identity Governanceシステム管理者パスワードをロック解除するには、LDAPでユーザーのdnを検索し、パスワードをロック解除するための一時ファイルを作成し、そのファイルを使用してシステム管理者のパスワードをロック解除します。
SSOが有効であり、OAMと統合されたOracle Identity GovernanceデプロイメントでLDAPのOracle Identity Governanceシステム管理者パスワードをロック解除するには:
スキーマのパスワードの変更には、OIG、MDS、SOAINFRA、OPSS、ORASDPMおよびBI Publisherスキーマのパスワードの変更が含まれます。
OIG、MDS、SOAINFRA、OPSS、ORASDPMおよびBI Publisherスキーマ・パスワードを変更するには:
すべての管理対象サーバーとアプリケーション・サーバーを停止します。
ドメイン全体とデータベースのバックアップを作成します。
アプリケーション・サーバーを起動します。
xxxx_OPSSユーザー・パスワードを変更します。これを行うには、次のようにします。
次のコマンドを実行します。
SQL> alter user xxxx_OPSS identified by NEW_PASSWORD;
ORACLE_COMMON/common/bin/ディレクトリに移動し、wlstコマンドを実行します。
次のように、modifyBootStrapCredentialスクリプトを実行します。
modifyBootStrapCredential(jpsConfigFile='DOMAIN_NAME/config/fmwconfig/jps-config.xml', username='xxxx_OPSS', password='NEW_PASSWORD')
Weblogic管理コンソールにログインします。「サービス」→ 「データ・ソース」の順に移動します。
「opss-DBDS」→「接続プール」を選択し、手順4aでxxxx_opssに設定された新しいパスワードを入力します。変更を保存します。
アプリケーション・サーバーを再起動します。ただし、管理対象サーバーは起動しません。
sqlplusを使用してシステム・ユーザーとしてデータベースに接続した後、次のコマンドを実行します。
xxx_OIMのパスワードを変更するには、次のコマンドを実行します。
SQL> alter user xxx_OIM identified by NEW_PASSWORD;
xxx_MDSのパスワードを変更するには、次のコマンドを実行します。
SQL> alter user xxx_MDS identified by NEW_PASSWORD;
xxx_SOAINFRAのパスワードを変更するには、次のコマンドを実行します。
SQL> alter user xxx_SOAINFRA identified by NEW_PASSWORD;
xxx_ORASDPMのパスワードを変更するには、次のコマンドを実行します。
SQL> alter user xxx_ORASDPM identified by NEW_PASSWORD;
xxx_BIPLATFORMのパスワードを変更するには、次を実行します。
SQL> alter user xxx_BIPLATFORM identified by NEW_PASSWORD;
パスワードが変更されたことを確認します。これを行うには、sqlplusを使用して、4つのユーザーと新しいパスワードでデータベースにログインします。
WebLogic管理コンソールにログインします。
「サービス」→「データ・ソース」の順に移動し、次の操作を実行します。
「soaOIMLookupDB」→「接続プール」を選択し、手順12aでxxx_OIMに設定された新しいパスワードを入力します。
「oimJMSStoreDS」→「接続プール」を選択し、手順12aでxxx_OIMに設定された新しいパスワードを入力します。
「oimOperationsDB」→「接続プール」を選択し、手順12aでxxx_OIMに設定された新しいパスワードを入力します。
「ApplicationDB」→「接続プール」を選択し、手順12aでxxx_OIMに設定された新しいパスワードを入力します。
「mds-oim」→「接続プール」を選択し、手順12bでxxx_MDSに設定された新しいパスワードを入力します。
「mds-owsm」→「接続プール」を選択し、手順12bでxxx_MDSに設定された新しいパスワードを入力します。
「mds-soa」→「接続プール」を選択し、手順12bでxxx_MDSに設定された新しいパスワードを入力します。
「EDNDataSource」→「接続プール」を選択し、手順12cでxxx_SOAINFRAに設定された新しいパスワードを入力します。
「EDNLocalTxDataSource」→「接続プール」を選択し、手順12cでxxx_SOAINFRAに設定された新しいパスワードを入力します。
「SOADataSource」→「接続プール」を選択し、手順12cでxxx_SOAINFRAに設定された新しいパスワードを入力します。
「SOALocalTxDataSource」→「接続プール」を選択し、手順12cでxxx_SOAINFRAに設定された新しいパスワードを入力します。
「OraSDPMDataSource」→「接続プール」を選択し、手順12dでxxx_ORASDPMに設定された新しいパスワードを入力します。
OIMAuthenticationProvider構成を変更します。これを行うには、次のようにします。
WebLogic管理コンソールで、「セキュリティ・レルム」→「myrealm」→「プロバイダ」に移動します。
「OIMAuthenticationProvider」をクリックします。
「プロバイダ固有」をクリックします。
「DBPassword」フィールドに、Oracle Identity Governanceデータベース・スキーマの新しいパスワードを入力します。
「保存」をクリックして変更を保存します。
ドメインの資格証明ストアの構成を変更します。これを行うには、次のようにします。
Oracle Enterprise Managerにログインします。
「WebLogicドメイン」→「DOMAIN_NAME」に移動します。
ドメイン名を右クリックし、「セキュリティ」→「資格証明」→「oim」を選択します。
「OIMSchemaPassword」を選択し、「編集」をクリックします。
「パスワード」フィールドで、新しいパスワードを入力し、「OK」をクリックします。
BI Publisherでoimおよびsoaスキーマのパスワードを変更します。これを行うには、次のようにします。
BI Publisherにログインします。
「管理」タブをクリックします。
「データ・ソース」の下にある「JDBC接続」をクリックします。
「OIM JDBC」をクリックし、「パスワード」フィールドでパスワードを変更します。
「接続のテスト」をクリックします。接続は確認後に正常に確立されます。
「適用」をクリックします。
JDBCデータ・ソースBPEL JDBCに対して手順14dから14fまでを繰り返します。
BI Publisherスキーマ・パスワードが変更されている場合は、次の手順を実行します。
Oracle Enterprise Managerにログインします。
「WebLogicドメイン」、「DOMAIN_NAME」を展開します。
右ペインの「DOMAIN_NAME」の下のWebLogicドメインの一覧から、「JDBCデータソース」を選択します。
表からbip_datasourceを選択し、ツールバーの「編集」をクリックします。
「接続プール」タブをクリックします。「データベース接続情報」セクションで、パスワードを変更し、右上隅の「適用」をクリックします。
BI Publisherサービスを起動します。
WebLogic管理サーバーを再起動します。
SOAおよびOracle Identity Governanceの管理対象サーバーを起動します。
Oracle Identity GovernanceのSSLの構成には、Oracle Identity Governanceそのものと、Oracle Identity Governanceが相互作用して安全な通信を確立するコンポーネントについての、鍵の生成、証明書への署名およびエクスポート、SSL構成の設定が含まれます。
SHA-2準拠の証明書は、SSL通信のTLS 1.2プロトコルを使用する前提条件です。
注意:
IBM Java7、SHA-2暗号スイートのSR4バージョン・サポートおよびトランスポート・レイヤー・セキュリティ(TLS)バージョン1.2に関連する情報は、IBMのドキュメントを参照してください。
次の各項では、いくつかの例を紹介します。これらの例には、デバッグ情報を増やすことのできるパラメータが含まれており、オプションです。例:
-Dweblogic.StdoutDebugEnabled=true -Dssl.debug=true -Djavax.net.debug=ssl:handshake:verbose.
Oracle JDK 8の場合、最新のJava Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Filesをダウンロードして適用します。local_policy.jarおよびUS_export_policy.jarのjarファイルを<JAVA_HOME>/jre/lib/securityディレクトリに再配置します。
注意:
Opatchのバージョンが12.1.0.1.10より前の場合、p21142429_121010_Linux-x86-64.zipパッチを適用してOPatchユーティリティをアップグレードしてください。
23176395_121020_Generic.zipパッチをDB_HOMEに適用して、Oracle12c DB (12.1.0.2)でTLS 1.2がサポートされるようにしてください。
WebLogicレベルでデモ・アイデンティティおよびデモ・トラストが使用されている場合、BSUを介してp13964737_1036_Generic.zip Weblogicパッチを適用します。
この項では、次の項目について説明します。
注意:
「カスタム・キーストアの生成(オプション)」の項では、後にドキュメントで使用されるサンプル・コマンドを説明します。これらは参照用であって、構成の必須手順の一部ではありません。
SSLベースのOracle User Messaging Service (UMS)通知の構成については、「通知へのUMSの使用」を参照してください。
SSLを使用してメール・サーバーに接続するUMSの構成の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のOracle User Messaging Serviceの構成に関する項を参照してください。
この項には次のトピックが含まれます:
注意:
この項で説明する手順はオプションです。これらの手順は、WebLogicサーバーのためのカスタム・アイデンティティおよびトラスト・ストアがある場合に必要となります。SSLは、デフォルトのアイデンティティおよびトラスト・ストアでも有効にできます。
keytoolコマンドを使用して、秘密と公開の証明書のペアを生成できます。
次のコマンドでは、アイデンティティ・キーストア(oimsupportidentity.jks)が作成されます。
$JAVA_HOME/jre/bin/keytool -genkey -alias ALIAS -keyalg ALGORITHM -keysize KEY_SIZE -sigalg SIGN_ALORITHM -dname DISTINGUISHED_NAME -keypass KEY_PASSWORD -keystore KEYSTORE_NAME -storepass KEYSTORE_PASSWORD
例:
$JAVA_HOME/jre/bin/keytool -genkey -alias supportpvtkey -keyalg RSA -keysize 2048 -sigalg SHA256withRSA -dname "CN=oimhost.mydomain.com, OU=Identity, O=Oracle Corporation,C=US" -keypass privatepassword -keystore oimsupportidentity.jks -storepass password
注意:
keytoolコマンドに渡すパラメータ値は、個別の要件に応じて変更してください。keytoolの引数には改行が含まれないようにしてください。
カスタム・アイデンティティ・キーストアoimsupportidentity.jksは、WL_HOME/server/lib/に作成またはコピーする必要があります。
このリリースでは、JDK 8u131が使用されます。このため、keysizeオプションの値を1024以上にする必要があります。この制限の詳細は、JDK8u131の更新のリリース・ノートを参照してください。
必要なパラメータ値を渡してkeytoolコマンドを使用し、作成した証明書に自己署名します。
作成した証明書に署名するには、次のkeytoolコマンドを実行します。
$JAVA_HOME/jre/bin/keytool -selfcert ALIAS -keyalg ALGORITHM -keysize KEY_SIZE -sigalg SIGN_ALORITHM -dname DISTINGUISHED_NAME -keypass KEY_PASSWORD -keystore KEYSTORE_NAME -storepass KEYSTORE_PASSWORD
例:
$JAVA_HOME/jre/bin/keytool -selfcert -alias supportpvtkey -sigalg SHA256withRSA -validity 2000 -keypass privatepassword -keystore oimsupportidentity.jks -storepass password
注意:
keytoolコマンドに渡すパラメータ値は、個別の要件に応じて変更してください。keytoolの引数には改行が含まれないようにしてください。
証明書をアイデンティティ・キーストアからファイル(supportcert.pemなど)にエクスポートするには、keytoolコマンドを使用します。
次のkeytoolコマンドを実行します。
$JAVA_HOME/jre/bin/keytool -export -alias ALIAS -file FILE_TO_EXPORT -keypass KEY_PASSWORD -keystore KEYSTORE_NAME -storepass KEYSTORE_PASSWORD
たとえば、次のコマンドによって証明書が「supportpvtkeycert.pem」というファイルにエクスポートされます。
$JAVA_HOME/jre/bin/keytool -export -alias supportpvtkey -file supportpvtkeycert.pem -keypass password -keystore oimsupportidentity.jks -storepass password
カスタム信頼ストアを使用する場合、そのカスタム信頼ストアの証明書をインポートします。Java標準信頼を信頼ストアとして使用する場合、そのJava標準信頼の証明書(JAVA_HOME/jre/lib/security/cacertsなど)をインポートします。
ファイルから証明書をインポートするには、keytoolコマンドを使用します。構文は次のとおりです。
keytool -import -alias ALIAS -trustcacerts -file FILE_TO_IMPORT -keystore KEYSTORE_NAME -storepass KEYSTORE_PASSWORD
次の例では、証明書ファイルsupportpvtkeycert.pemがアイデンティティ・キーストアoimsupporttrust.jksにインポートされます。
$JAVA_HOME/jre/bin/keytool -import -alias supportpvtkey -trustcacerts -file supportpvtkeycert.pem -keystore oimsupporttrust.jks -storepass <password>
注意:
このコマンドにより、信頼性のあるCA証明書がカスタム・キーストアoimsupporttrust.jksにロードされます。キーストアが存在しない場合、作成します。
このカスタム信頼キーストアoimsupporttrust.jksはDOMAIN_HOME/config/fmwconfig/に作成またはコピーする必要があります。
keytoolコマンドに渡すパラメータ値は、個別の要件に応じて変更してください。keytoolの引数には改行が含まれないようにしてください。
注意:
カスタム・キーの生成の詳細は、「カスタム・キー・ストアの生成(オプション)」を参照してください。
注意:
証明書のCNがWLSがインストールされているマシンのホスト名と同じでない場合、ホスト名の検証で「なし」を選択する必要があります。選択するには、「SSL」タブ、「拡張」セクションに移動し、「ホスト名の検証」リストから「なし」を選択します。
Oracle Identity Governanceサーバーおよび他の管理対象サーバーでSSLを有効化するには、Oracle Identity GovernanceのSSLを有効にし、SSLポートを使用するようにOimFrontEndURLとbackOfficeURLを変更し、SSLポートを使用するようにSOAサーバーのURLを変更します。
SSLを有効化するには、Oracle Identity GovernanceおよびSOAサーバーで次の構成を実行する必要があります。
Oracle Identity GovernanceのSSLを有効化する詳細は、次の項を参照してください。
デフォルト設定を使用してOracle Identity GovernanceおよびSOAサーバーのSSLを有効化するには、次の手順を実行します。
Oracle Identity GovernanceのSSLポートを使用するためにOimFrontEndURLを変更するには:
SOAサーバーURLをSOA SSLポートを使用するように変更するには:
管理サーバーおよびOracle Identity Governance管理対象サーバーが稼働しているときに、Enterprise Manager (EM)にログインします。
例:
http://ADMINISTRATIVE_SERVER/em
「WebLogicドメイン」をクリックして、「システムMBeanブラウザ」を選択します。
「アプリケーション定義のMBeans」で、「oracle.iam」→「アプリケーション:OIM」→「XMLConfig」→構成→「XMLConfig.SOAConfig」→「SOAConfig」に移動します。
Rmiurl属性の値を変更します。
注意:
Rmiurlは、SOA管理対象サーバーにデプロイされたSOA EJBにアクセスするために使用されます。
これは、アプリケーション・サーバーのURLです。クラスタ化されたインストールの場合は、すべてのSOA管理対象サーバーURLのカンマ区切りのリストです。
例:
t3s://mysoa1.example.com:8002 t3s://mysoa1.example.com:8002,mysoa2.example.com:8003,mysoa3.example.com:8004
Soapurl属性の値を変更します。例:
https://mysoa.example.com:8002
注意:
Soapurlは、SOA管理対象サーバーにデプロイされたSOA Webサービスにアクセスするために使用されます。これは、Webサーバーまたはロード・バランサをフロントエンドとするSOAクラスタでは、WebサーバーURLまたはロード・バランサURLです。単一SOAサーバーでは、アプリケーション・サーバーURLです。
「適用」をクリックして変更を保存します。
SOAサーバーのURLは、ForeignJNDIProvider-SOAでも有効にする必要があります。
Oracle Identity GovernanceデータベースのSSLを有効化するには、サーバー認証SSLモードでデータベースを設定し、KeyStoreと証明書を作成し、Oracle Identity Governanceを更新し、WebLogic Serverを更新します。
Oracle Identity GovernanceデータベースのSSLを有効にするには、次の構成を行う必要があります。
orapkiユーティリティを使用して、サーバー側とクライアント側のキーストアを作成できます。このユーティリティは、Oracle DBインストールの一部として出荷されます。
キーストアは、JKSやPKCS12などの任意の形式にすることができます。キーストアの形式は、プロバイダの実装によって異なります。たとえば、JKSはSun Oracleが提供する実装で、PKCS12はOraclePKIProviderが提供する実装です。
Oracle Identity Governanceでは、DBサーバーにJKSクライアント・キーストアのみを使用します。これは、PKCS12などのJKS以外のキーストア形式を使用するには、リリースが差し迫っているときにインストーラ側に大きな変更を加える必要があったためです。ただし、Oracle Identity Governanceにはdefault-KeyStore.jksという名前のJKS形式のキーストアがあらかじめ含まれています。
orapkiユーティリティを使用して、次のキーストアを作成できます。
サーバー認証SSLモードでデータベースを設定するには:
データベース・サーバーとリスナーを停止します。
listener.oraファイルを次のように構成します。
次のパスに移動します。
$DB_ORACLE_HOME/network/adminディレクトリ
例:
/u01/app/user1/product/12.1.0/dbhome_1/network/admin
listener.oraファイルを編集してSSLリスニング・ポートとサーバー・ウォレット・ロケーションを含めます。
次にlistener.oraファイルのサンプルを示します。
# listener.ora Network Configuration File: DB_ORACLE_HOME/listener.ora # Generated by Oracle configuration tools. SSL_VERSION = 1.2 SSL_CLIENT_AUTHENTICATION = FALSE WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = DB_ORACLE_HOME/bin/server_keystore_ssl.p12) ) ) LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCPS)(HOST = server1.mycompany.com)(PORT = 2484)) ) (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = server1.mycompany.com)(PORT = 1521)) ) ) TRACE_LEVEL_LISTENER = SUPPORT
sqlnet.oraファイルを次のように構成します。
次のパスに移動します。
$DB_ORACLE_HOME/network/adminディレクトリ
例:
/u01/app/user1/product/12.1.0/dbhome_1/network/admin
sqlnet.oraファイルを編集して次の内容を含めます。
TCPS認証サービス
SSL_VERSION
サーバー・ウォレット・ロケーション
SSL_CLIENT_AUTHENTICATIONタイプ(trueまたはfalse)
通信で許可されるSSL_CIPHER_SUITES(オプション)
次にsqlnet.oraファイルのサンプルを示します。
# sqlnet.ora Network Configuration File: DB_ORACLE_HOME/sqlnet.ora # Generated by Oracle configuration tools. SQLNET.AUTHENTICATION_SERVICES= (BEQ,NTS, TCPS) SSL_VERSION = 1.2 SSL_CLIENT_AUTHENTICATION = FALSE WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = DB_ORACLE_HOME/bin/server_keystore_ssl.p12) ) )
tnsnames.oraファイルを次のように構成します。
次のパスに移動します。
$DB_ORACLE_HOME/network/adminディレクトリ
例:
/u01/app/user1/product/12.1.0/dbhome_1/network/admin
tnsnames.oraファイルを編集してサービスの説明リストにSSLリスニング・ポートを含めます。
次にtnsnames.oraファイルのサンプルを示します。
# tnsnames.ora Network Configuration File: DB_ORACLE_HOME/tnsnames.ora
# Generated by Oracle configuration tools.
PRODDB =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCPS)(HOST = server1.mycompany.com)(PORT = 2484))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = proddb)
)
)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = server1.mycompany.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = proddb)
)
)
)
データベース・サーバーのユーティリティを起動および停止します。
データベース・サーバーを起動します。
Oracle Identity GovernanceおよびOracle Identity Governance DBでSSLモードを有効にして安全な通信を確保するには、Oracle Identity Governanceで次の手順を実行する必要があります。
Oracle Identity GovernanceデータベースのSSLを有効にしたら、データベースSSLポートを使用するために、次のOracle Identity Governanceデータソースおよびオーセンティケータを変更する必要があります。
注意:
データベースのホストまたはポートの変更を行う前に、Oracle Identity Governanceアプリケーションをホストする管理対象サーバーを停止する必要があります。ただし、WebLogic管理サーバーは稼動させたままでかまいません。
WebLogicサーバーの既存のOracle Identity Governanceオーセンティケータは、非SSL DB詳細に対して構成されており、Oracle Identity Governance DBとの通信にデータソースを使用しません。オーセンティケータでSSL DB詳細を使用するには、次の手順を実行する必要があります。
データソースがSSLに構成されていることを確認します。
WebLogic管理コンソールで、「セキュリティ・レルム」→「myrealm」→ 「プロバイダ」に移動します。
OIMAuthenticationProviderを削除します。
OIMAuthenticatorタイプの認証プロバイダを作成し、制御フラグをSUFFICIENTに設定します。
OIMSignatureAuthenticatorタイプの認証プロバイダを作成し、制御フラグをSUFFICIENTに設定します。
オーセンティケータを次の順に並べ替えます。
DefaultAuthenticator
OIMAuthenticator
OIMSignatureAuthenticator
その他のプロバイダ(あれば)
すべてのサーバーを再起動します。
SOA承認コンポジットのSSLを有効化するには、ヒューマン・ワークフロー・コンポーネント・タイプの各コンポジットのHTTPSポートを更新します(有効なワークリストURLエントリがあり、HTTPSポートを使用する必要がある場合)。
SOA承認コンポジットのSSLを有効化するには:
注意:
トラスト・ストアの場所を取得するには、WebLogic Server管理コンソールで、「環境」、「サーバー」をクリックします。OIM_SERVER_NAMEをクリックして、Oracle Identity Governanceサーバーの詳細を表示します。
「キーストア」タブをクリックし、「信頼」セクションに表示される信頼キーストアの場所を書き留めておきます。
Design ConsoleおよびOracle Identity Governanceが違うホストにデプロイされている場合は、信頼キーストアをDesign Consoleがデプロイされているホストにコピーし、信頼キーストアをコピーしたローカル・ホストの場所にTRUSTSTORE_LOCATION環境変数を設定します。
例:
setenv TRUSTSTORE_LOCATION OIM_HOME/designconsole/copied_oimsupporttrust.jks
Ready Appについて理解し、登録して使用します。これにより、WebLogic Serverがアプリケーションのデプロイメントを完了した時点で完全に初期化されていないアプリケーションも、サーバーの準備完了状態に加わる要求を登録することができ、完全に初期化されたときにサーバーに通知することができます。
この項では、次の項目について説明します。
Ready AppはWebLogicのメカニズムです。これを使用すると、サーバーまたはサーバーで実行されているパーティション(あるいは両方)の準備完了状態にアプリケーションが影響を与えることができます。このためには、ReadyLifecycle javaインタフェースのready()メソッドとnotReady()メソッドを登録して使用します。
多くのアプリケーションでは、WebLogic Server (WLS)がRUNNING状態の場合、サーバーのすべてがリクエストを受け取る準備ができています。ただし、一部のアプリケーションでは、WebLogic Serverの起動サイクルよりも長くかかる非同期処理が行われている場合があります。WebLogicがRUNNING状態になったときにアプリケーションでリクエストを処理できる準備が整っていない可能性がある場合、そのアプリケーションはReady Appに登録する必要があります。デプロイされたアプリケーションの1つがRUNNING状態に到達せず準備できていない場合に備えて、ロード・バランサとライフサイクル・ツールは常にReadyApp URLを利用して、WebLogic Serverインスタンスがリクエストを受け取る準備ができているかどうかを判別する必要があります。
Fusion Middlewareアプリケーションの起動プロセスにおいて、WebLogic Serverからは上位スタック・アプリケーション(SOA SuiteまたはBPMなど)の起動プロセスが認識できません。このため、ロード・バランサまたは他のWLSインスタンスが、完全に機能していないサーバーへトラフィックのルーティングを早く開始する場合があります。また、サーバーの再起動を伴う自動化された手順において、パッチ・ツールや他のライフサイクル操作を使用して、サーバーが準備できているかどうかを判別するのは困難です。このドキュメントでは、上位スタック・アプリケーションをWLSに登録して、アプリケーションの起動が完了したらWLS起動プロセスに通知するメカニズムを定義します。
このフレームワークの目的は、WebLogic Serverがアプリケーションのデプロイメントを完了した時点で完全に初期化されていないアプリケーションが、サーバーの準備完了状態に加わるという要求を登録し、完全に初期化されたときにサーバーに通知することです。これは次の目的で重要です。
自動メカニズムの場合、ツールは、サーバーがすべてのアプリケーションとともにリクエストを処理する準備ができたかどうかを判別する信頼性の高い方法を必要です。このチェックにより、自動ツールが、プロセスの次のステップに進んでも問題ないかどうかを認識できます。たとえば、ツールで一連のサーバーのローリング再起動を実行する必要がある場合は、停止したサーバーが完全に使用可能になってから、ドメインまたはクラスタの次のサーバーのシャットダウンを開始することが重要です。こうすることにより、ドメインまたはクラスタで、複数のサーバーが使用不可(すなわち起動中/初期化中)にならないようにします。
ロード・バランシング目的では、このフレームワークによって、信頼性の高いサーバー(およびマルチテナントの場合はパーティション)のヘルスチェックURLが提供されます。これでロード・バランサはサーバーがリクエストを受け入れる準備がいつできたかを確実に判別できます。
WebLogic Serverが起動時にアプリケーションのデプロイメントを完了する(つまりサーバーのリスニング・ポートが開く)とすぐに、アプリケーションが完全に初期化されてリクエストを受け入れる準備ができる場合には、アプリケーションをこのフレームワークに含める(アプリケーションでこのフレームワークを使用する)必要はありません。
Ready App機能を使用するには、アプリケーションをReady Appに登録する必要があります。
META-INF\weblogic-application.xmlファイルに次の行を指定することです。<wls:ready-registration>true</wls:ready-registration>
注意:
weblogic-application.xmlファイルの内容によって、「wls:」が必要になる場合と必要ない場合があります。他のタグにこの接頭辞がない場合には、Ready App登録タグにも付けないでください。Not Readyに設定されます。また、アプリケーションがWebLogicからアンデプロイされると、アプリケーションの登録は自動的に解除されます。Ready AppをEARで使用するには、アプリケーションをReady Appに登録し、ready()メソッドとnotready()メソッドを呼び出します。
ready()やnotReady()の呼出しによって、2つのランタイム例外が発生する可能性があります。これらを次に示します。| 例外 | 説明 |
|---|---|
| IllegalArgumentException | この例外が発生するのは、コンポーネント起動コンテキストによって報告されるapplicationIdがnullの場合です。 |
| IllegalStateException | この例外が発生するのは、アプリケーションが正常に登録されなかった場合です。デプロイメント・ディスクリプタが適切に設定されていることを確認してください。 |
Ready AppをEARで使用するには、アプリケーションをReady Appに登録し、ready()メソッドとnotready()メソッドを呼び出します。
注意:
次の手順は、個別にデプロイされたWARファイルのみに適用されます。アプリケーションをEAR内のWARとしてデプロイする場合は、EARでのReady Appの使用方法について「EARでのReady Appの使用」の手順を参照してください。| 例外 | 説明 |
|---|---|
| IllegalArgumentException | この例外が発生するのは、コンポーネント起動コンテキストによって報告されるapplicationIdがnullの場合です。 |
| IllegalStateException | この例外が発生するのは、アプリケーションが正常に登録されなかった場合です。デプロイメント・ディスクリプタが適切に設定されていることを確認してください。 |
Ready Appが作動しているかどうかをテストするには、WebLogic管理コンソールにログインし、DebugReadyAppのデバッグ設定を有効にします。
この例では、サーバーに3つのアプリケーション(グローバル・パーティションに1つ、最新パーティションに1つずつ)がデプロイされています。これは値1 (準備できていないという意味)によってわかります。ready()メソッドをこれらのアプリケーションについて呼び出すと、値は0になります(アプリケーションが準備できていることを示す)。
すべてのアプリケーションの準備ができると、サーバーの準備ができたとみなされます。1つのパーティションのすべてのアプリケーションの準備ができていても、他のアプリケーションの準備ができていないという場合もあります。
