19 WDTを使用したOracle Identity Governanceの構成

エンタープライズ・デプロイメントの開始点として使用する初期ドメインをインストールおよび構成します。後でこのドメインを構成します。

完全なOracle Identity and Access Managementでは、ドメインを分割してデプロイします。つまり、Oracle Access Management用に1つのドメインがあり、Oracle Identity Governance用に別のドメインがあります。

WebLogic Kubernetes Operatorのバージョン4.1.2では、Oracle WebLogicドメインを作成するための2つの異なる方法を使用できます。従来のWLSTの方法では、WLSTスクリプトを使用してドメインを作成します。これは、エンタープライズ・デプロイメント・ガイドでいくつかのリリースに使用されている方法です。

このリリース以降、エンタープライズ・デプロイメント・ガイドでは、Weblogicデプロイメント・ツール(WDT)を使用してドメインを作成します。WDTはテンプレートを使用してドメインを作成し、インストール手順を簡素化します。WebLogicデプロイメント・ツールの詳細は、WebLogic Deploy Toolingを参照してください

この章の内容は次のとおりです。

• システム・クロックの同期
  Oracle Identity Governanceをデプロイする前に、各ホスト・コンピュータのシステム・クロックが同期していることを確認します。これを行うには、各クラスタ内のすべてのホストでdateコマンドを同時に実行します。
• 初期インフラストラクチャ・ドメインについて
  初期インフラストラクチャ・ドメインを作成する前に、重要な概念を確認してください。
• 前提条件
  KubernetesインフラストラクチャにOracle Identity Governance (OIG)を作成する前に、Oracle Identity Governanceコンテナ・イメージをダウンロードし、Oracle WebLogic Operatorをインストールしておく必要があります。
• Oracle Identity Governanceのネームスペースの作成
  すべてのOracle Identity Governance Kubernetesオブジェクトを含むネームスペースを作成します。
• コンテナ・レジストリ・シークレットの作成
  コンテナ・レジストリを使用して、オンデマンドでOracleコンテナ・イメージをプルする場合は、コンテナ・レジストリのログイン詳細を含むシークレットを作成する必要があります。
• Docker HubイメージのKubernetesシークレットの作成
  このシークレットを使用すると、Kubernetesはhelm、kubectl、logstashコマンドなど、サードパーティのイメージを含むhub.docker.comからイメージをプルできます。
• Oracle Identity Governance用のデータベース・スキーマの作成
  Oracle Fusion Middlewareコンポーネントでは、データベース内にスキーマが必要です。これらのスキーマは、デプロイメント時にWebLogicデプロイメント・ツールによって処理されます。
• Oracle Identity Governanceドメインの作成
  Oracle Identity Governanceドメインを作成するには、ドメイン・ネームスペースのWebLogic Kubernetes Operatorを構成し、Kubernetesシークレットを作成して、Governanceドメインを作成する必要があります。
• Kubernetesサービスの作成
  デフォルトでは、OIGドメインは、ClusterIPサービスとして構成されたすべてのコンポーネント(管理サーバーを除く)を使用して作成されます。つまり、Oracle Identity Governanceコンポーネントは、Kubernetesクラスタ内でのみ認識されます。
• JMSキューのチューニング
  最大スループットを確保するには、JMSキューをチューニングします。
• コネクタ・バンドルのインストール
  ドメインを作成したら、必要なコネクタをKubernetesコンテナにコピーする必要があります。これらのコネクタは、永続ボリュームに格納する必要があります。
• Oracle Identity Managementドメイン用の構成後タスクの実行
  OIGドメインの構成後タスクには、サーバー・オーバーライド・ファイルの作成およびデータ・ソースの更新が含まれます。
• Identity Governanceの検証
  いくつかのテストを実行して、インストールを検証します。
• ブートストラップ・レポートの分析
  Oracle Identity Governanceサーバーを起動すると、$DOMAIN_HOME/servers/oim_server1/logs/BootStrapReportPreStart_XXXX.htmlにブートストラップ・レポートが生成されます。
• ドメイン用のWeb層の構成
  まだ構成していない場合、Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをインスタンスでルーティングできるようにします。
• Oracle Identity GovernanceとOracle SOA Suiteの統合
  ロード・バランサ・エントリ・ポイントを使用してOracle Identity GovernanceとOracle SOA Suiteを統合し、高可用性を維持できます。
• 通知サービスの管理
  イベントとは、Oracle Identity Managerで発生する操作で、ユーザー作成、リクエスト開始またはユーザーが作成した任意のカスタム・イベントなどが含まれます。これらのイベントは、ビジネス操作の一部として、またはエラー生成を介して生成されます。イベント定義は、イベントを記述するメタデータです。
• メッセージング・ドライバの構成
  各メッセージング・ドライバを構成する必要があります。OAMのパスワードを忘れた場合の機能を有効にする場合は、このサービスを構成する必要があります。
• データベース接続プール・サイズの増加
  Oracle Identity GovernanceをLDAPディレクトリとのインタラクションを許可するコネクタと組み合せて使用する場合には、デフォルトのデータベース接続プール・サイズを増加する必要があります。
• Oracle Identity GovernanceとLDAPとの統合
  OIGとLDAPを統合する前に、LDAPのコネクタを構成し、必要なオブジェクト・クラスが欠落している場合はそれらを追加する必要があります。
• Oracle Identity GovernanceとOracle Access Managerとの統合
  Oracle Identity GovernanceとOracle Access Managerを統合するには、いくつかのタスクを完了する必要があります。これらのタスクには、WLS認証プロバイダの作成、OIMSignatureAuthenticatorの削除とOUDAuthenticatorの再作成、新しい管理グループへの管理ロールの追加などが含まれます。
• リコンシリエーション・ジョブの実行
  Oracle Identity Governanceドメインを実行して、LDAPユーザー名をOracle Identity Governanceデータベースにインポートします。
• 電子メールで送信するOIMワークフロー通知の構成
  OIMでは、SOAワークフローと統合されたヒューマン・ワークフローが使用されます。SOAサーバーで電子メールを構成し、通知を受信してユーザーのメールボックスに配信します。ユーザーは、通知を承認または拒否できます。
• Administratorsグループへのwsm-pmロールの追加
  新しいLDAPベースの認可プロバイダを構成して管理サーバーを再起動したら、エンタープライズ・デプロイメント管理LDAPグループ(WLSAdministrators)をメンバーとしてwsm-pmアプリケーション・ストライプのpolicy.Updaterロールに追加します。
• SOA管理者へのWebLogic管理グループの追加
  LDAP管理グループWLSAdministratorsのユーザーを使用してSOAを管理するには、グループの名前をSOA管理者グループに追加する必要があります。
• Oracleキーストア・サービスへのOracle Access Managerロード・バランサ証明書の追加
  セルフ・サービス・アプリケーション内部のOracle Identity GovernanceからBusiness Intelligenceレポートへのリンクでは、ロード・バランサによって使用されるSSL証明書をOracleキーストア・サービスの信頼できる証明書に追加する必要があります。
• 初期サーバー数の設定
  最初にドメインを作成したときに、1つの管理対象サーバーのみを起動するように指定しました。この値によって、OIGブートストラップ・プロセスが正常に完了したことが保証されます。構成を完了したら、初期サーバー数を必要な実際の数まで増やすことができます。
• チャレンジ質問の設定
  OAMとOIMを統合した場合、環境の準備が整ったら、システム・ユーザーのチャレンジ質問を設定する必要があります。
• Oracle Identity ManagerとOracle Business Intelligence Publisherとの統合
  Oracle Identity Managerでは、Oracle Identiy and Access Managementに関する情報を提供するために、いくつかの事前作成されたレポートを使用できます。
• Design Consoleアクセスの有効化
  インストール環境の一部としてインストールされているDesign Consoleには、アクセスできません。これはコンテナ内にあり、外部のX Window環境にアクセスする必要があるためです。
• GrafanaとPrometheusによる集中管理型の監視
  集中管理型のPrometheusおよびGrafanaデプロイメントを使用してインフラストラクチャを監視している場合は、このアプリケーションにOracle Identity Governanceのデータを送信できます。
• ElasticsearchおよびKibanaを使用した集中管理型のログ・ファイル監視
  ElasticsearchとKibanaを使用している場合は、集中管理型のElasticearch/Kibanaコンソールにログ・ファイルを送信するようLogstashポッドを構成できます。Logstashポッドを構成する前に、集中管理型のElasticsearchデプロイメントにアクセスできることを確認してください。
• 構成のバックアップ
  ベスト・プラクティスとして、ドメインを正常に拡張した後や別の論理ポイントで構成をバックアップすることをお薦めします。必ずここまでのインストールが成功していることを確認してからバックアップしてください。これは、後のステップで問題が発生した場合に即座にリストアを実行できるクイック・バックアップです。
• コンテナからのOIMバルクロード・ユーティリティの実行
  コンテナからoimbulkloadユーティリティを実行する場合は、JDKおよびoimbulkloadユーティリティもインストールされているOracle Database Instant Clientに基づいて新しいコンテナ・イメージを作成します。

システム・クロックの同期

Oracle Identity Governanceをデプロイする前に、各ホスト・コンピュータのシステム・クロックが同期していることを確認します。これを行うには、各クラスタ内のすべてのホストでdateコマンドを同時に実行します。

また、そのために使用できるサードパーティおよびオープンソースのユーティリティもあります。

初期インフラストラクチャ・ドメインについて

初期インフラストラクチャ・ドメインを作成する前に、重要な概念を確認してください。

• ソフトウェア・ディストリビューションについて
  
• ドメインの特徴
  
• この章で使用される変数
  
• Kubernetesサービス
  

ソフトウェア・ディストリビューションについて

エンタープライズ・デプロイメントの初期インフラストラクチャ・ドメインの作成には、Oracle WebLogic Operatorを使用します。Oracle Identity Governanceソフトウェアは、事前構築済のコンテナ・イメージとして配布されます。「エンタープライズ・デプロイメント用のソフトウェア・ディストリビューションの特定と取得」を参照してください。このディストリビューションには、Oracle Identity Governanceのインストールと構成に必要なすべてのコンポーネントが含まれています。

『Oracle Fusion Middlewareの理解』のOracle Fusion Middlewareの理解に関する項を参照してください。

ドメインの特徴

次の表に、作成するドメインの主な特徴を示します。これらの特徴を確認することで、ドメインの構成手順の目的やコンテキストに対する理解が深まります。

これらの特徴の多くについては、「標準的なエンタープライズ・デプロイメントの理解」で詳しく説明しています。

ドメインの特徴	詳細情報
各WebLogicドメインをKubernetesクラスタに配置します。	「Kubernetesデプロイメントについて」を参照してください。
各WebLogic Serverは、Kubernetesクラスタ内のポッドに配置されます。	「Kubernetesデプロイメントについて」を参照してください。
各Kubernetesドメイン・オブジェクトを専用のKubernetesネームスペースに配置します。	「Kubernetesデプロイメントについて」を参照してください。
Kubernetes NodePortサービスを使用して、WebLogic管理対象サーバーと通信します。	「Kubernetesサービスの作成」を参照してください。
Kubernetes永続ボリュームを使用して、ドメイン構成を保持します。	unresolvable-reference.html#GUID-CF07EE44-34D9-4F36-97BE-6B3FBB4FCEA8を参照してください。
各Kubernetesポッドは、事前作成済のOracleコンテナ・イメージから作成されます。	「エンタープライズ・デプロイメント用のソフトウェア・ディストリビューションの特定と取得」を参照してください。
ドメインごとのノード・マネージャ構成を使用。	「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。
別途インストールされたLDAPベースの認証プロバイダが必要。	「Oracle Unified Directoryのインストールおよび構成」を参照してください。
証明書は、Oracleキーストア・サービスに格納されます。	「Oracle OPSSキーストア・サービスの構成」を参照してください。
JMSおよびTLOGSは、データベースに格納されます。	「JDBCストアの使用」を参照してください

この章で使用される変数

この章の以降の項では、多数のファイルを作成する手順について説明します。これらのサンプル・ファイルには、デプロイメントに適用可能な値に置換する必要がある変数が含まれています。

変数の形式は<VARIABLE_NAME>です。次の表に、これらの各変数に設定する必要がある値を示します。

表19-1 変更する必要がある変数

変数	サンプル値	説明
<REGISTRY_ADDRESS>	iad.ocir.io/<mytenancy>	レジストリの場所。
<REGISTRY_SECRET_NAME>	regcred	コンテナ・レジストリ資格証明を含むKubernetesシークレットの名前。コンテナ・レジストリから直接イメージをプルする場合にのみ必要です。「コンテナ・レジストリ・シークレットの作成」を参照してください。
<REG_USER>	mytenancy/oracleidentitycloudservice/[e-mail]	レジストリへのログインに使用するユーザーの名前。
<REG_PASSWORD>	<password>	レジストリ・ユーザー・パスワード。
<OIG_REPOSITORY>	oracle/oig local/oracle/oig container-registry.oracle.com/middleware/oig_cpu <REGISTRY_ADDRESS>/oracle/oig	OIGソフトウェア・リポジトリの名前。 コンテナ・イメージをダウンロードしてステージングした場合、この値はoracle/oigになります。OLCNEを使用する場合、値はlocal/oracle/oigになります。 Oracleコンテナ・レジストリを使用する場合、値はcontainer-registry.oracle.com/middleware/oig_cpuになります。 コンテナ・レジストリを使用する場合、値は製品名を含むレジストリの名前になります: <REGISTRY_ADDRESS>/oracle/oig。
<OIG_VER>	12.2.1.4-jdk8-ol7-220420.0828または最新のもの。	使用するイメージのバージョン。これは、ダウンロードしてローカルまたはコンテナ・レジストリにステージングしたバージョンです。
<PVSERVER>	nfsserver.example.com	NFSサーバーの名前またはIPアドレス ノート: この名前は、Kubernetesクラスタ内で解決可能である必要があります。
<OIGNS>	oigns	OIGドメイン・ネームスペースの名前。
<WORKDIR>	workdir/OIG	OAMの作業ディレクトリを作成する場所。
<K8WORKER>	k8worker1.example.com	外部WebLogic管理サーバーのKubernetesサービスが解決可能であるKubernetesホストの1つ。
<OIG_SHARE>	/exports/IAMPVS/oigpv	永続ストアのNFSエクスポート。
<OID_BULK_SHARE>	/exports/IAMPVS/oigbulkpv	バルク・ロード・ユーティリティを介してロードされるデータを格納するために使用される永続ボリューム。
<OIG_DB_SCAN>	dbscan.example.com	RACデータベースのSCANアドレス。
<OIG_DB_LISTENER>	1521	RACデータベースのリスナー・ポート番号。
<OIG_DB_SERVICE>	igdedg.example.com	データベース・サービスの名前。PDBを使用している場合は、PDBサービスの名前を指定します。
<OIG_DB_SYS_PWD>	MySysPWD__001	データベースのSYSパスワード。
<OIG_RCU_PREFIX>	IADEDG	データベース・スキーマの作成時に使用される接頭辞。
<OIG_SCHEMA_PWD>	MySchemaPWD__001	作成される製品スキーマに設定するパスワード。
<OIG_WEBLOGIC_USER>	weblogic	IAMGovernanceドメインの管理ユーザーの名前。
<OIG_WEBLOGIC_PWD>	mypassword	WebLogicユーザーのパスワード。
<OIG_DOMAIN_NAME>	governancedomain	作成されるドメインの名前。
<OIG_DOMAIN_SECRET>	governancedomain-weblogic-credentials	使用されるネームスペースに対して作成するシークレットの名前。シークレットの名前は<OIG_DOMAIN_NAME>-weblogic-credentialsである必要があります。
<OIG_RCU_SECRET>	governancedomain-rcu-credentials	RCUシークレットの名前。シークレットの名前は<OIG_DOMAIN_NAME>-rcu-credentialsである必要があります。「RCUシークレットの作成」を参照してください。
<OIG_LBR_HOST>	prov.example.com	OIMのロード・バランサ・エントリ・ポイント。
<OIG_LBR_PORT>	443	OIMのロード・バランサ・ポート。
<OIM_SERVER_NAME>	oim_server1	OIMサーバーの名前。
<OIG_EMAIL_DOMAIN>	example.com	電子メール・ドメイン。
<OIG_ADMIN_PORT>	7101	OIG管理サーバーに割り当てられた内部ポート。
<WG_CONNECTIONS>	20	WebGateエージェントでサポートされる接続の最大数。
<LDAP_TYPE>	OUD	これは、使用しているディレクトリのタイプ(OUDまたはOID)です。
<LDAP_OAMADMIN_USER>	oamadmin	OAMの管理に使用するユーザーの名前。「構成ファイルの作成」を参照してください。
<LDAP_OAMLDAP_USER>	oamLDAP	OAMがディレクトリに接続してログインを検証するために使用するユーザーの名前。
<LDAP_XELSYSADM_USER>	xelsysadm	OIM管理者アカウント。
<LDAP_HOST>	idstore.example.com edg-oud-ds-rs-lbr-ldap.oudns.svc.cluster.local	LDAPディレクトリのロード・バランサ名。 LDAPディレクトリがKubernetesクラスタ内にある場合は、Kubernetesサービス名を使用できます。その形式は、<K8_SERVICE_NAME>.<NAMESPACE>.svc.cluster.localです。 Kubernetesクラスタの外部のLDAPディレクトリに接続する場合は、外部ロード・バランサの名前を指定する必要があります。
<LDAP_PORT>	1389	これは、ロード・バランサのLDAPポートです。
<LDAP_ADMIN_USER>	cn=oudadmin (OUDの場合)。	ディレクトリに接続して管理アクションを実行するために使用する資格証明。
<LDAP_OIGLDAP_USER>	oimLDAP	OIMがログイン検証のためにLDAPに接続する際に使用するユーザーの名前。
<LDAP_SYSTEMIDS>	cn=systemids	システムIDを格納するコンテナの名前。このコンテナに配置されたユーザー名は、OIMリコンシリエーションまたはパスワード・エージングの対象ではありません。このコンテナは、<LDAP_OAMLDAP_USER>や<LDAP_OIGLDAP_USER>などのユーザー用に予約されています。
<LDAP_SEARCHBASE>	dc=example,dc=com	組織のディレクトリ・ツリー。これは、すべてのデータが格納される場所です。
<LDAP_USER_SEARCHBASE>	cn=Users,dc=example,dc=com	ユーザーの名前が格納されるディレクトリ内の場所。
<LDAP_GROUP_SEARCHBASE>	cn=Groups,dc=example,dc=com	ユーザー・グループが格納されるディレクトリ内の場所。
<LDAP_USER_PWD>	<password>	<LDAP_OAMADMIN_USER>アカウントのパスワードが含まれます。
<OAM_LOGIN_LBR_HOST>	login.example.com	OAMクラスタのフロント・エンド・ロード・バランサのリスニング・アドレス。
<OAM_LOGIN_LBR_PORT>	443	OAMクラスタのフロント・エンド・ロード・バランサのポート。
<OAM_WEBLOGIC_USER>	weblogic	OAM管理サーバーの管理ユーザー。
<OAM_WEBLOGIC_PWD>	<password>	<OAM_WEBLOGIC_USER>のオプションのパスワード。
<OAM_OAP_PORT>	5575	内部OAPポート番号。 Kubernetesサービスを使用している場合、この値を内部ポート番号にできます。
<OAP_SERVICE_PORT>	30540	OAM OAPクラスタ・ノードに面しているKubernetesサービス・ポート。Kubernetesサービスを使用している場合、この値を内部ポート番号にできます。
<GLOBAL_PASSPHRASE>	-	これはグローバル・パスフレーズに設定します。値を取得するには、「グローバル・パスフレーズの取得」を参照してください。
<OIG_SERVER_COUNT>	5	必要な管理対象サーバーの数。この値は、システムの存続期間中に予想されるニーズより大きい数に設定することを強くお薦めします。これにより、WebLogicドメインに複数のサーバー定義が作成され、需要の増加時にシステムをスケール・アップする単純なメカニズムが確保されます。この値は、実際に起動するサーバー・インスタンスの数を反映するものではなく、ニーズの変化に応じて追加のサーバーを起動できます。ドメイン作成後のサーバー定義の追加は複雑なタスクであるため、可能であれば避けてください。
<OIG_INITIAL_SERVERS>	1	起動する管理対象サーバーの数。この値は、構成期間中は1に設定することをお薦めします。
<OIM_MAX_CPU>	1	各OIG_SERVERポッドが消費できるCPUの最大数。CPUはCPUコアで測定され、1の値は1 CPUコアまたは1仮想コアと等しくなります。
<OIM_CPU>	500m	各OIM_SERVERポッドが消費できるCPUの初期数。これはCPUサイクルで測定され、1000mの値は1 CPUコアまたは1仮想コアと等しくなります。CPUはCPUコアで測定され、1の値は1 CPUコアまたは1仮想コアと等しくなります。
<SOA_MAX_CPU>	1	各SOA_SERVERポッドが消費できるCPUの最大数。CPUはCPUコアで測定され、1の値は1 CPUコアまたは1仮想コアと等しくなります。
<SOA_CPU>	500m	各SOA_SERVERポッドが消費できるCPUの初期数。これはCPUサイクルで測定され、1000mの値は1 CPUコアまたは1仮想コアと等しくなります。CPUはCPUコアで測定され、1の値は1 CPUコアまたは1仮想コアと等しくなります。
<OIM_MAX_MEMORY>	8Gi	OIM_SERVERポッドが消費できるメモリーの最大量。メモリーは、1Gが1Giと等しい標準単位で測定されます。
<OIM_MEMORY>	4Gi	OIM_SERVERポッドが消費できるメモリーの初期量。メモリーは、1Gが1Giと等しい標準単位で測定されます。
<OIMSERVER_JAVA_PARAMS>	-Xms4096m -Xmx8192m	各OIM_SERVERに割り当てられる最大(Xmx)および最小ヒープ・サイズ。サイズはMb数で示されます。 ノート: ヒープ・サイズの最大量は、ポッド<OIM_MAX_MEMORY>で使用できる最大量より小さくする必要があります。
<SOASERVER_JAVA_PARAMS>	-Xms4096m -Xmx8192m	各SOA_SERVERに割り当てられる最大(Xmx)および最小ヒープ・サイズ。サイズはMb数で示されます。 ノート: ヒープ・サイズの最大量は、ポッド<SOA_MAX_MEMORY>で使用できる最大量より小さくする必要があります。
<OIG_OIM_T3_PORT_K8>	30142	使用するKubernetesサービス・ポート。
<OIG_ADMIN_K8>	30711	外部WebLogic管理サーバーの外部Kubernetesサービス・ポート。
<ELK_HOST>	https://elasticsearch-es-http.elkns.svc:9200	集中管理型のElasticsearchデプロイメントのホストおよびポート。このホストは、Kubernetesクラスタの中と外のどちらでもかまいません。このホストは、Elasticsearchが使用されている場合にのみ使用されます。
<ELK_VER>	8.11.0	使用するElasticsearchのバージョン。

Kubernetesサービス

NodePortサービスを使用している場合、このデプロイメントの一部として次のKubernetesサービスが作成されます:

表19-2 Kubernetes NodePortサービス

サービス名	タイプ	サービス・ポート	マップ済ポート
governancedomain-oim-http-NodePort	NodePort	30140	14000
governancedomain-soa-http-NodePort	NodePort	30801	8001
governancedomain-adminserver-external	NodePort	30711	7101

イングレスベースのデプロイメントを使用している場合、デプロイメントの一部として次のイングレス・サービスが作成されます:

表19-3 イングレス・サービス

サービス名	ホスト名
oigadmin-ingress	igdadmin.example.com
oigruntime-ingress	prov.example.com
oiginternal-ingress	igdinternal.example.com

前提条件

KubernetesインフラストラクチャにOracle Identity Governance (OIG)を作成する前に、Oracle Identity Governanceコンテナ・イメージをダウンロードし、Oracle WebLogic Operatorをインストールしておく必要があります。

• Oracle Governance ManagerイメージをダウンロードしてDockerイメージ・リポジトリにロードするには(このリポジトリは各Kubernetesノードに認識される必要があります)、「エンタープライズ・デプロイメント用のソフトウェア・ディストリビューションの特定と取得」を参照してください。
• Oracle WebLogic Operatorをインストールするには、「WebLogic Kubernetes Operatorのインストールと構成」を参照してください。

• 製品固有の作業ディレクトリの設定
  

製品固有の作業ディレクトリの設定

インストールを開始する前に、Oracle Identity Governanceコンテナ・イメージおよびコード・リポジトリをダウンロードしてステージングしておく必要があります。「コンテナ・レジストリからのイメージのダウンロード」および「コード・リポジトリのステージング」を参照してください。また、「WebLogic Kubernetes Operatorのインストール」の説明に従って、Oracle WebLogic Operatorをデプロイしている必要があります。

この項では、ダウンロードしたサンプル・デプロイメント・スクリプトをOIGの構成ホストの一時作業ディレクトリにコピーする方法について説明します。

1. インストール・ユーザーとして一時作業ディレクトリを作成します。インストール・ユーザーには、Kubernetesクラスタへのkubectlアクセス権が必要です。

   mkdir -p /<WORKDIR>

   たとえば:

   mkdir -p /workdir/OIG

2. ディレクトリをこの場所に変更します:

   cd /workdir/OIG

3. サンプル・スクリプトを作業ディレクトリにコピーします。

   cp -R <WORKDIR>/fmw-kubernetes/OracleIdentityGovernance/kubernetes <WORKDIR>/samples

   たとえば:

   cp -R /workdir/OIG/fmw-kubernetes/OracleIdentityGovernance/kubernetes /workdir/OIG/samples

Oracle Identity Governanceのネームスペースの作成

すべてのOracle Identity Governance Kubernetesオブジェクトを含むネームスペースを作成します。

1. ネームスペースを作成するには、次のコマンドを使用します:

   kubectl create namespace <OIGNS>

   たとえば:

   kubectl create namespace oigns

   出力が次のように表示されます。

   namespace/oigns created

2. WebLogic Kubernetes Operatorで管理できるようにネームスペースをタグ付けします。

   kubectl label namespaces oamns weblogic-operator=enabled

コンテナ・レジストリ・シークレットの作成

コンテナ・レジストリを使用して、オンデマンドでOracleコンテナ・イメージをプルする場合は、コンテナ・レジストリのログイン詳細を含むシークレットを作成する必要があります。

ノート:

コンテナ・レジストリを使用していない場合は、レジストリ・シークレットを作成する必要があります。ただし、ユーザー名とパスワードに意味のあるデータを含める必要はありません。

コンテナ・レジストリ・シークレットを作成するには、次のコマンドを使用します:

kubectl create secret -n <OIGNS> docker-registry <REGISTRY_SECRET_NAME> --docker-server=<REGISTRY_ADDRESS> --docker-username=<REG_USER> --docker-password=<REG_PWD>

たとえば:

kubectl create secret -n oigns docker-registry regcred --docker-server=iad.ocir.io/mytenancy --docker-username=mytenancy/oracleidentitycloudservice/[e-mail] --docker-password=<password>

Docker HubイメージのKubernetesシークレットの作成

このシークレットを使用すると、Kubernetesはhelm、kubectl、logstashコマンドなど、サードパーティのイメージを含むhub.docker.comからイメージをプルできます。

ノート:

独自のコンテナ・レジストリからイメージをプルする場合、このステップは必要ありません。

hub.docker.comにアカウントが必要です。イメージを独自のリポジトリにステージングする場合は、それを実行し、helmオーバーライド・ファイルを適宜変更できます。

hub.docker.comにKubernetesシークレットを作成するには、次のコマンドを使用します:

$ kubectl create secret docker-registry dockercred --docker-server="https://index.docker.io/v1/" --docker-username="<DH_USER>" --docker-password="<DH_PWD>" --namespace=<OIGNS>

たとえば:

$ kubectl create secret docker-registry dockercred --docker-server="https://index.docker.io/v1/" --docker-username="username" --docker-password="<mypassword>" --namespace=oigns

Oracle Identity Governance用のデータベース・スキーマの作成

Oracle Fusion Middlewareコンポーネントでは、データベース内にスキーマが必要です。これらのスキーマは、デプロイメント時にWebLogicデプロイメント・ツールによって処理されます。

このツールは次のスキーマを作成します:

• メタデータ・サービス(MDS)
• 監査サービス(IAU)
• 監査サービスへの追加(IAU_APPEND)
• 監査サービス・ビューア(IAU_VIEWER)
• OPSS (Oracle Platform Security Services)
• ユーザー・メッセージング・サービス(UMS)
• WebLogicサービス(WLS)
• 共通インフラストラクチャ・サービス(STB)

RCUの詳細とスキーマを作成してデータベースに格納する方法の詳細は、リポジトリ作成ユーティリティによるスキーマの作成でスキーマ作成の準備に関する項を参照してください。

必要なスキーマをインストールするには、次のステップを実行します。

• 動作保証されたデータベースのインストールと構成
  
• トランザクション・リカバリ用のOIMスキーマの構成
  

動作保証されたデータベースのインストールと構成

動作保証されたデータベースを適切にインストールして構成し、そのデータベースを起動して稼働させておく必要があります。

「エンタープライズ・デプロイメント用の既存のデータベースの準備」を参照してください。

トランザクション・リカバリ用のOIMスキーマの構成

Oracle Identity Governanceを正常にインストールしたら、この項の手順に従ってトランザクション・リカバリのスキーマを構成します。

この手順では、WebLogic Serverが予期せずに使用不可になった後、進行中のトランザクションをリカバリする際に、Oracle WebLogic Serverトランザクション・マネージャでトランザクション状態の情報を問い合せて該当するコマンド(commitやrollbackなど)を発行できるように適切なデータベース権限を設定します。

これらの権限は、リポジトリ作成ユーティリティでスキーマを作成したときに定義したOIMスキーマの所有者に付与する必要があります。

トランザクション・リカバリ権限のOIMスキーマを構成するには:

1. sysdba権限を持つユーザーとしてSQL*Plusにログオンします。たとえば:

   sqlplus "/ as sysdba"
   

2. PDBを使用している場合は、IDMをホストしているPDBにセッションを変更します。たとえば:

   alter session set container=igdpdb;

3. 次のコマンドを入力します。

   grant select on sys.dba_pending_transactions to <OIG_RCU_PREFIX>_oim;

   Grant succeeded.

   SQL> grant force any transaction to <OIG_RCU_PREFIX>_oim;

   Grant succeeded.

Oracle Identity Governanceドメインの作成

Oracle Identity Governanceドメインを作成するには、ドメイン・ネームスペースのWebLogic Kubernetes Operatorを構成し、Kubernetesシークレットを作成して、Governanceドメインを作成する必要があります。

• Kubernetesシークレットの作成
  
• Governanceドメインの作成
  

Kubernetesシークレットの作成

ドメイン作成プロセスに資格証明を直接渡さずに、Kubernetesシークレットを使用して、暗号化された形式で資格証明を格納できます。WebLogic Operatorは、資格証明を要求するかわりに、これらのシークレットを読み取ります。

• ドメイン・シークレットの作成
  
• RCUシークレットの作成
  

ドメイン・シークレットの作成

ドメイン・シークレットには、ドメインを作成するWebLogic管理ユーザーに関する情報が含まれます。

1. 次のコマンドを使用して、ドメイン・シークレットを作成します:

   cd <WORKDIR>/samples/create-oim-domain/domain-home-on-pv/wdt-utils

   ./create-secret.sh -l "username=<OIG_WEBLOGIC_USER>" -l "password=<OIG_WEBLOGIC_PWD>" -n <OIGNS> -d <OIG_DOMAIN_NAME> -s <OIG_DOMAIN_SECRET>

   たとえば:

   cd /workdir/OIG/samples/create-oim-domain/domain-home-on-pv/wdt-utils

   ./create-secret.sh -l "username=weblogic" -l "password=mypassword" -n oigns -d governancedomain -s governancedomain-weblogic-credentials

   出力が次のように表示されます。

   secret/governancedomain-weblogic-credentials created
   secret/governancedomain-weblogic-credentials labeled 
   The secret governancedomain-weblogic-credentials has been successfully created in the oigns namespace

2. 次のコマンドを使用して、シークレットが作成されたことを確認します:

   kubectl get secret governancedomain-weblogic-credentials -o yaml -n oigns

RCUシークレットの作成

RCUシークレットは、WebLogic Operatorが作成済のデータベース・スキーマに接続する方法を決定するために使用されます。「Access Manager用のデータベース・スキーマの作成」を参照してください。

RCUシークレットを作成するには、次のステップを実行します:

1. 次のコマンドを使用します。

   cd <WORKDIR>/samples/create-oim-domain/domain-home-on-pv/wdt-utils

   ./create-secret.sh -l "rcu_prefix=<OIG_RCU_PREFIX>" -l "rcu_schema_password=<OIG_SCHEMA_PWD>" -l "db_host=<DB_HOST>" -l "db_port=<DB_PORT>" -l "db_service=<OIG_DB_SERVICE>" -l "dba_user=sys" -l "dba_password=<OIG_SYS_PWD>" -n <OIGNS> -d <OIG_DOMAIN_NAME> -s <OIG_RCU_SECRET>

   たとえば:

   cd /workdir/OIG/samples/create-oim-domain/domain-home-on-pv/wdt-utils

   ./create-secret.sh -l "rcu_prefix=IGDEDG" -l "rcu_schema_password=MySchemaPWD__001" -l "db_host=DB-SCAN.example.com" -l "db_port=1521" -l "db_service=oig_s.example.com" -l "dba_user=sys" -l "dba_password=MySysPassword" -n oigns -d governancedomain -s governancedomain-rcu-credentials

   出力が次のように表示されます。

   secret/governancedomain-rcu-credentials created
   secret/governancedomain-rcu-credentials labeled
   The secret governancedomain-rcu-credentials has been successfully created in the oigns namespace

2. コマンドを使用して、シークレットが作成されたことを確認します:

   kubectl get secret governancedomain-rcu-credentials -o yaml -n oigns

Governanceドメインの作成

Oracle Identity Governanceドメインを作成する手順には、ドメイン構成ファイルの作成、WebLogic Kubernetes Operatorを使用したドメインの作成、メモリー・パラメータの設定、ドメインの初期化、およびドメインの確認が含まれます。

• ドメイン構成ファイルの作成
  
• WDT補助イメージの生成
  
• domain.yamlの更新
  
• WebLogic Operatorを使用したドメインの作成
  
• ドメインの確認
  

ドメイン構成ファイルの作成

構成ファイルは、WebLogic Operatorにドメインの作成方法を指定するために使用されます。この構成ファイルは、create-domain-wdt.yamlという名前で、<WORKDIR>/samples/create-oim-domain/domain-home-on-pvにあります。

1. create-domain-wdt.yamlファイルのコピーを作成します。
   たとえば:

   cp /workdir/OIG/samples/create-oim-domain/domain-home-on-pv/create-domain-wdt.yaml /workdir/OIG/wdt-utils/generate_models_utils/create-domain-wdt.yaml

2. /workdir/OIG/create-domain-wdt.yamlファイルに次の変更を加えます:

   domainUID: <OIG_DOMAIN_NAME> 
   domainPVMountPath: /u01/oracle/user_projects/
   domainHome: /u01/oracle/user_projects/domains/<OIG_DOMAIN_NAME> 
   image: <OIG_REPOSITORY>:<OIG_VER>
   imagePullSecretName: <REGISTRY_SECRET_NAME>
   namespace: <OIGNS> 
   weblogicCredentialsSecretName: <OIG_DOMAIN_SECRET> 
   logHome: /u01/oracle/user_projects/domains/logs/<OIG_DOMAIN_NAME> 
   exposeAdminNodePort: true
   configuredManagedServerCount: <OIG_SERVER_COUNT>
   initialManagedServerReplicas: <OIG_INITIAL_SERVERS>
   productionModeEnabled: true
   exposeAdminT3Channel: false
   adminPort: 7101
   adminNodePort: <OIG_ADMIN_K8>
   # Front End Host that will front end the oim and soa servers
   frontEndHost: <OIG_LBR_HOST>
   frontEndPort: <OIG_LBR_PORT>
   datasourceType: agl
   weblogicDomainStorageNFSServer: <PVSERVER>
   weblogicDomainStorageType: NFS
   weblogicDomainStoragePath: <OIG_SHARE>
   edgInstall: true
   oimServerJavaParams: <OIMSERVER_JAVA_PARAMS>
   
   oimMaxCPU: <OIM_MAX_CPU>
   oimCPU: <OIM_CPU>
   oimMaxMemory: <OIM_MAX_MEMORY>
   oimMemory: <OIM_MEMORY>
   
   soaServerJavaParams: <SOASERVER_JAVA_PARAMS>
   soaMaxCPU: <SOA_MAX_CPU>
   soaCPU: <OAM_CPU>
   soaMaxMemory: <SOA_MAX_MEMORY>
   soaMemory: <SOA_MEMORY>

   たとえば:

   domainUID: governancedomain 
   domainPVMountPath: /u01/oracle/user_projects/
   domainHome: /u01/oracle/user_projects/domains/governancedomain
   image: latest
   imagePullSecretName: regcred
   namespace: oigns 
   weblogicCredentialsSecretName: oig-domain-credentials
   persistentVolumeClaimName: governancedomain-domain-pvc
   logHome: /u01/oracle/user_projects/domains/logs/governancedomain 
   rcuSchemaPrefix: IGDEDG 
   rcuDatabaseURL: dbscan.example.com:1521/igdedg.example.com 
   rcuCredentialsSecret: oig-rcu-credentials
   exposeAdminNodePort: true
   configuredManagedServerCount: 5
   initialManagedServerReplicas: 1
   productionModeEnabled: true
   exposeAdminT3Channel: false
   adminPort: 7101
   adminNodePort: 30711
   # Front End Host that will front end the oim and soa servers
   frontEndHost: prov.example.com
   frontEndPort: 443
   datasourceType: agl

3. 構成ファイルを保存します。

WDT補助イメージの生成

WebLogicデプロイメント・ツールを使用してドメインを作成すると、デプロイメントを記述する専用イメージが作成されます。これは、「ドメイン構成ファイルの作成」で説明されているドメイン作成ファイルに基づいています。このイメージは、ローカル・コンテナ・レジストリに格納されます。

構成で補助イメージを使用する利点は、プロパティがわずかに異なる複数の環境を作成するために繰り返し使用できることです。たとえば、同じイメージ・ファイルを使用して、データベース接続の詳細のみが異なる開発、テストおよび本番環境を作成できます。同様の環境を作成するたびに新しいイメージを作成する必要はありません。このイメージは、イメージがロードされるレジストリに格納する必要があり、ユーザーはこのレジストリへのアクセス権が必要です。

次の項では、WDTモデル・ファイルを生成し、補助イメージを作成して、それをリポジトリにアップロードする方法について説明します。

WDTモデル・ファイルの生成

次のステップを実行して、ドメイン構成ファイルからWDTモデル・ファイルを生成します:

1. ディレクトリを、ダウンロードしたサンプルのWDT utilsディレクトリに変更します。

   cd <WORKDIR>/samples/create-oim-domain/domain-home-on-pv/wdt-utils/generate_models_utils

   例:

   cd /workdir/OIG//samples/create-oim-domain/domain-home-on-pv/wdt-utils/generate_models_utils

2. generate_wdt_models.shユーティリティを使用してモデル・ファイルを生成します。

   ./generate_wdt_models.sh -i <WORKDIR>/create-domain-wdt.yaml -o <WORKDIR>

   -iを使用して、「ドメイン構成ファイルの作成」で作成したドメイン構成ファイルの場所を指定します。

   -oを使用して、WDTモデル・ファイルおよびテンプレートを作成する場所を指定します。

   たとえば:

   ./generate_wdt_models.sh -i /workdir/OIG/create-domain-wdt.yaml -o /workdir/OIG

   ユーティリティの実行後、生成されたファイルを含むweblogic-domainsというディレクトリが作成されます。

入力パラメータとサンプル出力

export version="create-weblogic-sample-domain-inputs-v1"
export adminPort="7101"
export domainUID="governancedomain"
export configuredManagedServerCount="5"
export initialManagedServerReplicas="1"
export productionModeEnabled="true"
export t3ChannelPort="30012"
export datasourceType="agl"
export edgInstall="true"
export domainHome="/u01/oracle/user_projects/domains/governancedomain"
export image="iad.ocir.io/mytenancyoig:12.2.1.4-jdk8-ol8-apr24"
export imagePullSecretName="regcred"
export logHome="/u01/oracle/user_projects/domains/logs/governancedomain"
export exposeAdminT3Channel="false"
export adminNodePort="30711"
export exposeAdminNodePort="false"
export namespace="oigns"
javaOptions=-Dweblogic.StdoutDebugEnabled=false
export domainPVMountPath="/u01/oracle/user_projects"
export weblogicDomainStorageType="NFS"
export weblogicDomainStorageNFSServer="mynfsserver.example.com"
export weblogicDomainStoragePath="/exports/IAMPVS/oigpv"
export weblogicDomainStorageReclaimPolicy="Retain"
export weblogicDomainStorageSize="10Gi"
export frontEndHost="prov.example.com"
export frontEndPort="443"
export oimServerJavaParams="-Xms8192m -Xmx8192m "
export soaServerJavaParams="-Xms4096m -Xmx8192m"
export oimMaxCPU="1"
export oimCPU="500m"
export oimMaxMemory="8Gi"
export oimMemory="4Gi"
export soaMaxCPU="1"
export soaCPU="1000m"
export soaMaxMemory="10Gi"
export soaMemory="4Gi"

validateWlsDomainName called with governancedomain
WDT model file, property file and sample domain.yaml are genereted successfully at /workdir/OIG/weblogic-domains/governancedomain

イメージ・プロパティ・ファイルの作成

モデル・ファイルを作成したら、それらをイメージに追加し、レジストリにアップロードする必要があります(プロパティ・ファイルにターゲット・レジストリを記述することから始めます)。

次のステップを実行して、イメージ・プロパティ・ファイルを作成します:

1. 次のコマンドを実行して、javaがマシンにインストールされていることを確認します:

   which java

2. プロパティ・ファイルを作業ディレクトリにコピーします。

   cp <WORKDIR>/samples/create-oim-domain/domain-home-on-pv/wdt-utils/build-domain-creation-image/properties/build-domain-creation-image.properties <WORKDIR>

   例:

   cp /workdir/OIG/samples/create-oim-domain/domain-home-on-pv/wdt-utils/build-domain-creation-image/properties/build-domain-creation-image.properties /workdir/OIG

3. ファイルbuild-domain-creation-image.propertiesを編集し、次の値を追加します:

   JAVA_HOMEは、これをステップ1にあるJAVAインストールの場所に設定します。

   例:

   /usr

   • REPOSITORYは、これをイメージ・ファイルが存在するレジストリ内の場所に設定します。

     たとえば、

     iad.ocir.io/<mytenancy>/idm/oig_wdt

     .

     ここで、oig_wdtは、作成するイメージの名前です。

   • アップロードされたイメージにタグを割り当てるために使用されるIMAGE_TAGは、ここでは何でも使用できます。この例では、<OIG_DOMAIN_NAME>を使用できます。

   • レジストリへの認証されていないアップロードを許可しない場合は、IMAGE_PUSH_REQUIRES_AUTHをtrueに設定する必要があります。

   • REG_USERは、イメージをアップロードするレジストリ内のユーザーに設定する必要があります。このユーザーにはアップロード権限が必要です。

   • WDT_MODEL_FILEは、前述のステップで生成されたファイルoam.yamlに設定する必要があります。たとえば、<WORKDIR>/weblogic-domains/<OIG_DOMAIN_NAME>/oim.yamlです。

   • WDT_VARIABLE_FILEは、前述のステップで生成されたファイルoam.propertiesに設定する必要があります。たとえば、<WORKDIR>/weblogic-domains/<OIG_DOMAIN_NAME/>oim.propertiesです。

   • REG_PWDは、前述のユーザーのパスワードに設定し、次に示すように<WORKDIR>にあるbuiidpwdの別のファイルに配置する必要があります:

     REG_PASSWORD="<mypwd>"

     サンプルのbuild-domain-creation-image.properties

     
     # Copyright (c) 2024, Oracle and/or its affiliates.
     # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl.
     # Input Property file for build-domain-creation-image.sh script
     
     #
     # set the JAVA_HOME environment variable to match the location of your Java installation. Java 8 or newer is required
     #
     JAVA_HOME=/usr
     
     #
     # Image Details
     #
     #Set the IMAGE_TAG, default oam-aux-v1 if not set.
     IMAGE_TAG=governancedomain
     # Set the BASE_IMAGE, default ghcr.io/oracle/oraclelinux:8-slim if not set.
     BASE_IMAGE=ghcr.io/oracle/oraclelinux:8-slim
     #
     # Container Registry
     #
     #Image will be created with REPOSITORY:IMAGE_TAG
     REPOSITORY=iad.ocir.io/<mytenancy>idm/oig_wdt
     # Container registry username
     REG_USER=<mytenancy>/oracleidentitycloudservice/[e-mail]
     #Set it to false if authentication is not required for pushing the image to registry, for example docker login already done in the host before invoking the script.
     IMAGE_PUSH_REQUIRES_AUTH=true
     #
     # WDT and WIT Variables
     #
     #Full path to wdt model files
     WDT_MODEL_FILE=/workdir/OIG/weblogic-domains/governancedomain/oim.yaml
     #Full path to wdt variable files
     WDT_VARIABLE_FILE=/workdir/OIG/weblogic-domains/governancedomain/oim.properties
     #Full path to wdt archive files
     WDT_ARCHIVE_FILE=""
     #If not set, Latest version will be used.
     WDT_VERSION="3.5.3"
     #If not set, latest will be used during every fresh run
     WIT_VERSION="1.12.1"
     
     #In Most cases, no need to use these parameters. Please refer https://oracle.github.io/weblogic-image-tool/userguide/tools/create-aux-image/ for details about them.
     TARGET=""
     CHOWN=""

WDT補助イメージのアップロード

ユーティリティbuild-domain-creation-image.shを使用して、補助イメージを作成およびアップロードします:

例:

cd <WORKDIR>/samples/create-oim-domain/domain-home-on-pv/wdt-utils/build-domain-creation-image

./build-domain-creation-image.sh -i <WORKDIR>/build-domain-creation-image.properties -p <WORKDIR>/.buildpwd

例:

cd /workdir/OIG/samples/create-oim-domain/domain-home-on-pv/wdt-utils/build-domain-creation-image

./build-domain-creation-image.sh -i /workdir/OIG/build-domain-creation-image.properties -p /workdir/OIG/.buildpwd

サンプル出力から抽出

Getting image source signatures
Copying blob sha256:d56869e2b34f592d78b05cce249e0130a52fb73209bbb394bb329b1fed54a652
Copying blob sha256:ba40a64765a65573fb1b9cfc9e175bd53c420c7ce8ec1424fda55835efbb7055
Copying blob sha256:0b458bb8ab4506598a0a925a3110c079ffbf77f85e3b97713e4592a2cb47a97f
Copying blob sha256:9aa2b64b3e6fefe00a04b52511ffda5b5ab3018538a1c7b11c4af4300e9220e0
Copying blob sha256:8b4d3bacf0d79476c744efb9d80fc05c5e1298b2ce8c5ed88edc9a4a01198ba9
Copying blob sha256:3ae779ed2d0c15ccbf8b31ae75afcbb857bb731618e9bde89108e8079ed4e9fe
Copying blob sha256:306ac5e1f9589c0be83dfa010d3bc53097c7acb7ef0fd51d054d1e6545c35c84
Copying blob sha256:5002f0067a2f325a4e67415b2e6889568719d0020b1df7b07af6be945c332210
Copying blob sha256:97acec59a7dd3180feaa8c2257fa8ed8027e5763d6aedb1c8a4df1a740e1ecb7
Copying blob sha256:5778e746ec78114f3569e4729dc11cc746dc6af9b5ebcf577ae9fe94867b495d
Copying blob sha256:6e841a878721c1c37fc0885152697674be097dc5d81004188a2e1dd647850e3e
Copying config sha256:ff14e6503d9efa8858512e8e7401e9c1b7d532acf11ffc44fb866ed5f4de00f1
Writing manifest to image destination
Storing signatures
Pushed image iad.ocir.io/mytenancy/oig_wdt:governancedomain to image repository

domain.yamlの更新

WDTモデル・ファイルの生成中に、domain.yamlというファイルが<WORKDIR>/weblogic-domains/<OIG_DOMAIN_NAME>ディレクトリに作成されました。このファイルは、WebLogicドメインの作成に使用されます。このファイルを使用する前に、作成した補助イメージをファイルに追加するために次を編集する必要があります

domain.yaml

ファイルで変数%DOMAIN_CREATION_IMAGE%を見つけ、それをbuild-domain-creation-image.propertiesファイルから取得した<REPOSITORY>:<IMAGE_TAG>というイメージの名前に置き換えます。

たとえば、

iad.ocir.io/mytenancy/idm/oig_wdt:accessdomain

ノート:

イメージが存在するレジストリがOIGイメージが格納されているレジストリと異なる場合は、メイン・レジストリとは異なる名前を使用して、補助イメージ・レジストリの資格証明を持つ新しいシークレットを作成します。

たとえば:

kubectl create secret -n oigns docker-registry regcred2 --docker-server=iad.ocir.io/mytenancy2 --docker-username=mytenancy/oracleidentitycloudservice/[e-mail] --docker-password=<password>

ファイルdomain.yamlを更新し、行を新しいシークレットの名前で置き換えます。

ドメイン作成イメージに別のレジストリを使用している場合は、別のシークレット名を追加します。

イメージをプルするための資格証明を含むシークレットを識別します。

  imagePullSecrets:

  - name: regcred2

WebLogic Operatorを使用したドメインの作成

次のコマンドを使用して、ドメインを作成します:

cd <WORKDIR>/weblogic-domains/<OIG_DOMAIN_NAME>

kubectl create -f <WORKDIR>/weblogic-domains/<OIG_DOMAIN_NAME>/domain.yaml

たとえば:

cd /workdir/OIG/weblogic-domains/governancedomain

kubectl create -f /workdir/OIG/weblogic-domains/governancedomain/domain.yaml

次を使用して、ドメインの作成をモニターします:

kubectl logs -n <OIGNS> <OIG_DOMAIN_DOMAIN>-introspector

kubectl describe domain -n <OIGNS> <OIG_DOMAIN_NAME>

例:

kubectl logs -n oigns governancedomain-introspector

kubectl describe domain -n oigns governancedomain

詳細は、WebLogicオペレータ・ログを参照してください。

例:

kubectl logs -n opns weblogic-operator-688f5dcdc4-qxnnz | grep <OIG_DOMAIN_NAME>

ドメインの作成後、OAM Kubernetesポッドが自動的に起動されます。次のコマンドを使用して表示できます:

kubectl get pods -n <OIGNS>

ドメインの確認

ドメインの作成を確認するには、次のステップを実行します:

1. ドメインが作成されたことを確認するには、次のコマンドを使用します:

   kubectl describe domain <domain_uid> -n <namespace>

   たとえば:

   kubectl describe domain governancedomain -n oigns

2. 次のコマンドを使用して、ドメイン・ポッドとサービスが作成されて起動されていることを確認します:

   kubectl get all,domains -n oigns

   出力が次のように表示されます。

   NAME                                                            READY   STATUS      RESTARTS   AGE   IP               NODE       NOMINATED NODE   READINESS GATES
   pod/governancedomain-adminserver                                1/1     Running     0          17h   192.168.14.205   slc09byd   <none>           <none>
   pod/governancedomain-create-fmw-infra-sample-domain-job-45mwk   0/1     Completed   0          23h   192.168.14.203   slc09byd   <none>           <none>
   pod/governancedomain-soa-server1                                1/1     Running     0          16h   192.168.14.206   slc09byd   <none>           <none>
   pod/helper                                                      1/1     Running     0          45h   192.168.14.202   slc09byd   <none>           <none>
   
   NAME                                            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)               AGE    SELECTOR
   service/governancedomain-adminserver            ClusterIP   None             <none>        7101/TCP              17h    weblogic.createdByOperator=true,weblogic.domainUID=governancedomain,weblogic.serverName=AdminServer
   service/governancedomain-adminserver-external   NodePort    10.96.33.206     <none>        7101:30711/TCP        17h    weblogic.createdByOperator=true,weblogic.domainUID=governancedomain,weblogic.serverName=AdminServer
   service/governancedomain-cluster-oim-cluster    ClusterIP   10.103.195.154   <none>        14002/TCP,14000/TCP   16h    weblogic.clusterName=oim_cluster,weblogic.createdByOperator=true,weblogic.domainUID=governancedomain
   service/governancedomain-cluster-soa-cluster    ClusterIP   10.106.89.77     <none>        8001/TCP              16h    weblogic.clusterName=soa_cluster,weblogic.createdByOperator=true,weblogic.domainUID=governancedomain
   service/governancedomain-soa-server1            ClusterIP   None             <none>        8001/TCP              16h    weblogic.createdByOperator=true,weblogic.domainUID=governancedomain,weblogic.serverName=soa_server1
   
   NAME                                                            COMPLETIONS   DURATION   AGE   CONTAINERS                           IMAGES                  SELECTOR
   job.batch/governancedomain-create-fmw-infra-sample-domain-job   1/1           9m9s       23h   create-fmw-infra-sample-domain-job   oracle/oig:12.2.1.4.0   controller-uid=a724d3ea-cbf0-43e1-9743-61a4f753c8b7

ノート:

前述のすべてのサービスが表示されるまでには数分かかります。STATUSが0/1のポッドは、すでにポッドは起動しているが、ポッドに関連付けられたSOAサーバーが起動中であることを示します。ポッドの起動中に、次のコマンドを使用して、ポッド・ログの起動ステータスを確認できます:

kubectl logs governancedomain-adminserver -n oigns

kubectl logs governancedomain-soa-server1 -n oigns

管理サーバーおよびSOAサーバーが正常に起動された後にのみ、コマンドを使用して残りのサーバーを起動します:

kubectl patch cluster -n <OIGNS> <OIG_DOMAIN_NAME>-oim-cluster --type=merge -p '{"spec":{"replicas":1}}"'

たとえば:

kubectl patch cluster -n signs governancedomain-oim-cluster --type=merge -p '{"spec":{"replicas":1}}"'

次のコマンドを使用して、ドメインが初期化されたことを確認します:

kubectl get all,domains -n oigns

出力が次のように表示されます。

NAME                                                            READY   STATUS      RESTARTS   AGE   
pod/governancedomain-adminserver                                1/1     Running     0          13h   
pod/governancedomain-create-fmw-infra-sample-domain-job-ks2rj   0/1     Completed   0          14h   
pod/governancedomain-oim-server1                                1/1     Running     0          12h
pod/governancedomain-oim-server2                                1/1     Running     0          12h   
pod/governancedomain-soa-server1                                1/1     Running     0          12h
pod/governancedomain-soa-server2                                1/1     Running     0          12h   
pod/helper                                                      1/1     Running     0          14h   

NAME                                            TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)               AGE    
service/governancedomain-adminserver            ClusterIP   None              <none>        7101/TCP              13h    
service/governancedomain-cluster-oim-cluster    ClusterIP   10.98.52.6        <none>        14002/TCP,14000/TCP   14h    
service/governancedomain-cluster-soa-cluster    ClusterIP   10.104.237.225    <none>        8001/TCP              14h    
service/governancedomain-oim-server1            ClusterIP   None              <none>        14002/TCP,14000/TCP   12h    
service/governancedomain-oim-server2            ClusterIP   None              <none>        14002/TCP,14000/TCP   12h
service/governancedomain-oim-server3            ClusterIP   10.107.107.116    <none>        14002/TCP,14000/TCP   12h
service/governancedomain-oim-server4            ClusterIP   10.98.134.71      <none>        14002/TCP,14000/TCP   12h
service/governancedomain-oim-server5            ClusterIP   10.103.64.15      <none>        14002/TCP,14000/TCP   12h    
service/governancedomain-soa-server1            ClusterIP   None              <none>        8001/TCP              12h
service/governancedomain-soa-server2            ClusterIP   None              <none>        8001/TCP              12h
service/governancedomain-soa-server3            ClusterIP   10.111.204.234    <none>        8001/TCP              12h
service/governancedomain-soa-server4            ClusterIP   10.107.90.229     <none>        8001/TCP              12h
service/governancedomain-soa-server5            ClusterIP   10.97.72.84       <none>        8001/TCP              12h

NAME                                                              COMPLETIONS   DURATION   AGE   
job.batch/governancedomain-create-fmw-infra-sample-domain-job     1/1           5m41s      14h   

NAME                                            AGE 
domain.weblogic.oracle/governancedomain         14h

NAME                                                        AGE
cluster.weblogic.oracle/governancedomain-oim-cluster        14h
cluster.weblogic.oracle/governancedomain-soa-cluster        14h

ノート:

前述のすべてのサービスが表示されるまでには数分かかります。ポッドのSTATUSが0/1の場合、ポッドは起動しているが、それに関連付けられたOIMサーバーは起動中です。ポッドの起動中に、次のコマンドを実行して、ポッド・ログの起動ステータスを確認できます:

kubectl logs governancedomain-oim-server1 -n oigns

Kubernetesサービスの作成

デフォルトでは、OIGドメインは、ClusterIPサービスとして構成されたすべてのコンポーネント(管理サーバーを除く)を使用して作成されます。つまり、Oracle Identity Governanceコンポーネントは、Kubernetesクラスタ内でのみ認識されます。

エンタープライズ・デプロイメントでは、WebLogicコンポーネントとのすべての対話は、Kubernetesクラスタの外部にあるOracle HTTP Serverを介して行われます。Kubernetesの追加サービスを作成して、WebLogicコンポーネントを外部に公開します。NodePortサービスまたはイングレス・コントローラを使用できます。

• NodePortサービスの作成
  
• SOA NodePortサービスの作成
  
• サービスの検証
  
• イングレス・サービスの作成
  

NodePortサービスの作成

OIM NodePortサービスを作成するには:

1. 次の内容を含む<WORKDIR>/oim_nodeport.yamlというテキスト・ファイルを作成します:

   kind: Service
   apiVersion: v1
   metadata:
     name: <OIG_DOMAIN_NAME>-oim-nodeport
     namespace: <OIGNS>
   spec:
     type: NodePort
     selector:
       weblogic.clusterName: oim_cluster
     ports:
       - targetPort: 14000
         port: 14000
         nodePort: <OIG_OIM_PORT_K8>
         protocol: TCP
     sessionAffinity: ClientIP
   

2. 次のコマンドを使用して、サービスを作成します:

   kubectl create -f /workdir/OIG/oim_nodeport.yaml

   出力が次のように表示されます。

   service/governancedomain-oim-nodeport created

SOA NodePortサービスの作成

SOA NodePortサービスを作成するには:

1. <WORKDIR>/soa_nodeport.yamlというテキスト・ファイルを、次の内容で作成します:

   kind: Service
   apiVersion: v1
   metadata:
     name: <OIG_DOMAIN_NAME>-soa-nodeport
     namespace: <OIG>
   spec:
     type: NodePort
     selector:
       weblogic.clusterName: soa_cluster
     ports:
       - targetPort: 8001
         port: 8001
         nodePort: <OIG_SOA_PORT_K8>
         protocol: TCP

2. 次のコマンドを使用して、サービスを作成します:

   kubectl create -f /workdir/OIG/soa_nodeport.yaml

   出力が次のように表示されます。

   service/governancedomain-soa-nodeport created

サービスの検証

サービスが正しく作成されたことを検証するには、次のコマンドを使用します:

kubectl -n oigns get all -o wide

イングレス・サービスの作成

イングレス・サービスを作成するには、最初にイングレス・コントローラを作成する必要があります。インストール手順の詳細は、「イングレス・コントローラのインストールと構成」を参照してください。

イングレス・サービスは製品ネームスペース内に作成されます。これにより、ネームスペース内でリクエストを転送する方法がイングレス・コントローラに指示されます。

ノート:

次の例では、3つのイングレス・サービス(各OIG仮想ホストに1つずつ)を作成します。

• igdadmin.example.com
• prov.example.com
• igdinternal.example.com

イングレス・サービスを作成するには:

1. <WORKDIR>/samples/charts/ingress-per-domainから、作業ディレクトリにvalues.yamlファイルをコピーし、ファイルの名前をoverride_ingress.yamlに変更します。
2. ファイル<WORKDIR>/override_ingress.yamlを編集し、値を次のように設定します:

   set domainUID to <OIG_DOMAIN_NAME>
   set adminServerPort to <OIG_ADMIN_PORT>
   set hostName.enabled to true
   set admin to <OIG_ADMIN_LBR_HOST>
   set runtime to <OIG_LBR_HOST>
   set internal to <OIG_LBR_INT_HOST>

   たとえば:

   # Load balancer type. Supported values are: NGINX
   type: NGINX
   
   # SSL configuration Type. Supported Values are : NONSSL,SSL
   sslType: NONSSL
   
   # domainType. Supported values are: oim
   domainType: oim
   
   #WLS domain as backend to the load balancer
   wlsDomain:
     domainUID: governancedomain
     adminServerName: AdminServer
     adminServerPort: 7101
     adminServerSSLPort:
     soaClusterName: soa_cluster
     soaManagedServerPort: 8001
     soaManagedServerSSLPort:
     oimClusterName: oim_cluster
     oimManagedServerPort: 14000
     oimManagedServerSSLPort:
   
   # Host specific values
   hostName:
     enabled: true
     admin: igdadmin.example.com
     runtime: prov.example.com
     internal: internal.example.com
   
   # Ngnix specific values
   nginx:
     nginxTimeOut: 180

3. 次のコマンドを実行して、イングレス・サービスを作成します:

   cd <WORKDIR>/samples

   helm install oig-nginx charts/ingress-per-domain --namespace <OIGNS> --values <WORKDIR>/override_ingress.yaml

4. 次のコマンドを使用して、イングレス・サービスが正しく作成されたことを検証します:

   kubectl get ingress -n oigns

JMSキューのチューニング

最大スループットを確保するには、JMSキューをチューニングします。

OIM JMSキューをチューニングするには:

1. WebLogic Serverコンソール(http://k8worker1.example.com:30711/console)にログインします。
2. 「ロックして編集」をクリックします。
3. 「ドメイン構造」で、「サービスおよびメッセージング」を展開し、「JMSサーバー」をクリックします。
4. 「OIMJMSServer」をクリックします。次のように値を変更します:
   • メッセージ・バッファ・サイズ: 1073741824 (1GB)。
   • 「しきい値および割当て制限」で、「最大メッセージ数」を1000000に変更します。
5. 「保存」をクリックします。
6. 「変更のアクティブ化」をクリックします。

コネクタ・バンドルのインストール

ドメインを作成したら、必要なコネクタをKubernetesコンテナにコピーする必要があります。これらのコネクタは、永続ボリュームに格納する必要があります。

コネクタ・バンドルをインストールするため、この例では、Oracle Identity GovernanceとOracle Unified Directoryの統合に使用されるOracle Internet Directoryコネクタ・バンドルを使用します。

1. まだ実行していない場合は、コネクタ・バンドルを<WORKDIR>にダウンロードします。
   https://www.oracle.com/middleware/technologies/identity-management/oim-connectors-downloads.html
2. サブディレクトリを作成し、そこにコネクタを解凍します。たとえば:

   mkdir /workdir/OIG/connectors
   cd /workdir/OIG/connectors
   unzip /workdir/OIG/oid-12.2.1.3.zip

3. コネクタをKubernetesコンテナにコピーして永続ストレージに配置します。

   kubectl exec -ti oimserver-1 -n <OIGNS> -- mkdir -p /u01/oracle/user_projects/domains/ConnectorDefaultDirectory

   kubectl cp <CONNECTOR_DIR>/OID-12.2.1.3.0 <OIGNS>/<domain-uid>-adminserver:/u01/oracle/user_projects/domains/ConnectorDefaultDirectory

   たとえば:

   kubectl exec -ti governancedomain-oim-server1 -n oigns -- mkdir -p /u01/oracle/user_projects/domains/ConnectorDefaultDirectory

   kubectl cp /workdir/OIG/connectors/OID-12.2.1.3.0 oigns/governancedomain-adminserver:/u01/oracle/user_projects/domains/ConnectorDefaultDirectory

Oracle Identity Managementドメイン用の構成後タスクの実行

OIGドメインの構成後タスクには、サーバー・オーバーライド・ファイルの作成およびデータ・ソースの更新が含まれます。

• 特定のワーカー・ノードへのポッドの制限
  
• サーバー・オーバーライド・ファイルの作成
  

特定のワーカー・ノードへのポッドの制限

OIGサーバーを特定のワーカー・サーバーのセットでのみ起動するようにするには、次のステップを実行します:

• Kubernetesワーカー・ノードのラベル付け
  
• ラベルへのプロセスの制限
  

Kubernetesワーカー・ノードのラベル付け

スケジューリングに含めるワーカー・ノードにラベルを付けます。これは必要に応じて詳細に設定できます。たとえば、OIGプロセスをノードのセットで実行するようにスケジュールする場合は、そのセットにoigserversなどのラベルを付けます。管理サーバーが特定のワーカー・ノードのセットで実行され、oim_serverが別のセットで実行されるように指定する場合は、oigadminとoimserversという2つのラベルを作成します。

次のコマンドを使用して、Kubernetesノードにラベルを追加します:

kubectl label node worker1 name=oimservers

ラベルへのプロセスの制限

OIMポッドが適切なラベルのワーカー・ノードでのみ実行されるようにするには、次のパスにあるdomain.yamlファイルを編集します:

<WORKDIR>/samples/create-oim-domain/domain-home-on-pv/output/weblogic-domains/<OIG_DOMAIN_NAME>/

たとえば:

/workdir/OIG/samples/create-oim-domain/domain-home-on-pv/output/weblogic-domains/accessdomain/

クラスタに構成されているすべての管理対象サーバーについて「管理対象サーバー」セクションを変更し、ラベル付けされたワーカー・ノードのみがスケジューリングに使用されるようにします。

oim_server1およびoim_server2の場合、エントリは次のようになります:

   managedServers:
   - serverName: oim_server1
     serverPod:
       nodeSelector:
         name: oimservers
   - serverName: oim_server2
     serverPod:
       nodeSelector:
         names: oimservers

サーバー・オーバーライド・ファイルの作成

serverOverridesファイルは、コンテナの起動時に特定のJava値を設定するために使用されます。パラメータがsetDomainEnv.shファイルの構成に追加されます。ただし、setDomainEnv.shファイルとは異なり、serverOverridesファイルはアップグレード中に上書きされません。

• Derbyデータベースの無効化
  
• 管理対象サーバーでのIPv4ネットワーキングの使用の有効化
  
• IAMGovernanceDomainでのメモリー・パラメータの設定
  
• Kubernetesコンテナへのサーバー・オーバーライドのコピー
  

Derbyデータベースの無効化

組込みDerbyデータベースを無効化します。このデータベースは、ファイルベースのデータベースであり、Oracle WebLogic Serverにパッケージ化されています。Derbyデータベースは、主に開発環境で使用します。そのため、本番対応のエンタープライズ・デプロイメント環境を構成する場合は無効にする必要があります。そうしないと、管理対象サーバーを起動したときにDerbyデータベース・プロセスが自動的に起動されます。

Derbyデータベースを無効にするには:

1. 次の内容を含む/workdir/OIG/setUserOverrides.shというファイルを作成します:

   DERBY_FLAG=false

2. ファイルを保存して閉じます。

管理対象サーバーでのIPv4ネットワーキングの使用の有効化

管理対象サーバーがIPv6ネットワーキングを使用するように構成されている場合、管理対象サーバーの起動時に問題が発生する可能性があります。このため、管理対象サーバーでIPv4ネットワーキングの使用を有効化する必要があります。

1. setUserOverrides.shファイルを編集し、次の行を追加します:

   JAVA_OPTIONS="${JAVA_OPTIONS} -Djava.net.preferIPv4Stack=true"

   ノート:

   ファイルが存在しない場合は、作成します。
2. ファイルを保存して閉じます。

IAMGovernanceDomainでのメモリー・パラメータの設定

メモリー使用量を定義するIAMGovernanceDomainの初期起動パラメータは十分ではありません。このパラメータの値を増やす必要があります。

1. setUserOverrides.shファイルの次のメモリー割当てを変更します。Java最大メモリー割当てプール(Xmx)を8192mに、初期メモリー割当てプール(Xms)を4096mに更新します。たとえば、次の行を追加します:

   MEM_ARGS="-Xms4096m -Xmx8192m"

2. ファイルを保存して閉じます。

Kubernetesコンテナへのサーバー・オーバーライドのコピー

Kubernetes環境では、コンテナ内にエディタはありません。この問題を回避するには、マスター・ノードでファイルを作成し、次のコマンドを使用してKubernetesコンテナにコピーします:

chmod 755 /workdir/OIG/setUserOverrides.sh

kubectl cp /workdir/OIG/setUserOverrides.sh oigns/governancedomain-adminserver:/u01/oracle/user_projects/domains/governancedomain/bin/setUserOverrides.sh

ここで、oignsはOIGネームスペースで、governancedomainはDOMAIN_NAME/UIDです。

Identity Governanceの検証

いくつかのテストを実行して、インストールを検証します。

• アイデンティティ・コンソールへのログインによるOIMの検証
  
• SOAアプリケーションの検証
  
• Fusion Middleware Controlアプリケーションの検証
  

アイデンティティ・コンソールへのログインによるOIMの検証

WebブラウザでOracle Identity Managerコンソールを起動することによって、Oracle Identity Managerサーバー・インスタンスを検証できます。

1. Webブラウザで次の場所を指定してOracle Identity Managerコンソールを起動します:

   http://k8worker1.example.com:30140/identity/ 

   http://k8worker1.example.com:30140/sysadmin/

2. xelsysadmのユーザー名とパスワードを使用してログインします。

SOAアプリケーションの検証

soa-infraにログインしてSOAを検証します:

http://k8worker1.example.com:30801/soa-infra

weblogicユーザー名を使用してログインします。

Fusion Middleware Controlアプリケーションの検証

ブートストラップ・プロセスを実行した後にFusion Middleware Controlアプリケーションにアクセスし、それを検証できます。

ノート:

チャレンジ質問の入力を求められたら入力します。

Fusion Middleware Controlアプリケーションに移動するには、次のURLを入力し、Oracle WebLogic Server管理者の資格証明を使用してログインします:

http://k8worker1.example.com:30711/em

ブートストラップ・レポートの分析

Oracle Identity Governanceサーバーを起動すると、$DOMAIN_HOME/servers/oim_server1/logs/BootStrapReportPreStart_XXXX.htmlにブートストラップ・レポートが生成されます。

ブートストラップ・レポートBootStrapReportPreStart_XXXX.htmlは、デプロイしたトポロジ、システム・レベルの詳細、使用するURLなど接続の詳細、接続チェック、タスク実行詳細に関する情報を含むHTMLファイルです。このレポートを使用して、システムが起動しているかどうかを確認し、問題のトラブルシューティングおよび構成後タスクを実行できます。

Oracle Identity Governanceサーバーを起動するたびに、ブートストラップ・レポートが更新されます。

ブートストラップ・レポートのセクション

• トポロジの詳細

  この項には、デプロイメントに関する情報が含まれます。クラスタ設定が構成されているかどうか、SSLが有効かどうか、Oracle Identity Manager環境が11gから12cにアップグレードされているかどうかを示します。

• システム・レベルの詳細

  この項には、JDKバージョン、データベース・バージョン、JAVA_HOME、DOMAIN_HOME、OIM_HOME、MIDDLEWARE_HOMEに関する情報が含まれます。

• 接続の詳細

  この項には、管理URL、OIMフロント・エンドURL、SOA URL、RMI URLなど接続詳細に関する情報が含まれます。

  管理サーバー、データベース、SOAサーバーが起動されているかどうかも示します。

• 実行の詳細

  この項では、様々なタスクとそのステータスを示します。

ブートストラップ・レポートを取得するには、次のいずれかを実行します:

• コマンドを使用して、Oracle Identity Governance管理サーバーに接続します:

  kubectl exec -n <OIGNS> -ti <OIG_DOMAIN_NAME>-adminserver –- /bin/bash

  cat /u01/oracle/user_projects/domains/<OIG_DOMAIN_NAME>/servers/oim_server1/logs/BootStrapReportPreStart_XXXX.html

  たとえば:

  kubectl exec -n oigns -ti governancedomain-adminserver –- /bin/bash

  cat /u01/oracle/user_projects/domains/governancedomain/servers/oim_server1/logs/BootStrapReportPreStart_XXXX.html

• IAMPVSを構成ホストにマウントした場合は、ブラウザに次の場所を指定するだけです:

  /nfs_volumes/oigpv/domains/governancedomain/servers/oim_server1/logs/BootStrapReportPreStart_XXXX.html

ドメイン用のWeb層の構成

まだ構成していない場合、Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをインスタンスでルーティングできるようにします。

Oracle HTTP Serverの構成の詳細は、「Oracle HTTP Serverのインストールと構成」を参照してください。

考えられるスケールアウト・シナリオの準備での追加のステップは、クロス・コンポーネント・ワイヤリング情報の更新を参照してください。

Oracle Identity GovernanceとOracle SOA Suiteの統合

ロード・バランサ・エントリ・ポイントを使用してOracle Identity GovernanceとOracle SOA Suiteを統合し、高可用性を維持できます。

• OIM統合URLの更新
  

OIM統合URLの更新

この項では、ロード・バランシングされたURLを使用するようにSOA統合URLを更新する方法について説明します。Oracle Identity GovernanceをOracle SOA Suiteと統合する場合は、Enterprise Managerコンソールを使用します。

Oracle Identity Governanceを使用して新しく作成したドメインを構成するには、特定のタスクを実行する必要があります。これらのタスクは、ドメイン作成後のタスクです。

Oracle Identity GovernanceをOracle SOA Suiteと統合するには、次のことを行います。

1. 次のURLを使用してOracle Fusion Middleware Controlにログインします。

   http://igdadmin.example.com/em

   または

   http://k8worker1.example.com:30711/em

   管理サーバーのホストおよびポート番号は「構成の終了」画面のURLにありました(「ドメイン・ホームと管理サーバーURLの記録」)。デフォルトの管理サーバーのポート番号は7101です。

   ログイン資格証明は「管理者アカウントの構成」の「管理者アカウント」画面で指定されました。

2. 「weblogic_domain」,をクリックし、「システムMBeanブラウザ」をクリックします。
3. 検索ボックスに、OIMSOAIntegrationMBeanと入力して、「検索」をクリックします。mbeanが表示されます。

   ノート:

   Oracle Identity Governanceがまだ起動中(立ち上げ中)または起動したばかり(RUNNING MODE)の場合、Enterprise Managerに、OIMで定義されたMbeanは表示されません。サーバーが起動するまで2分間待ってから、Enterprise Managerの「システムMBeanブラウザ」でMbeanの検索を試みてください。

4. MBeanの「操作」タブに移動して、integrateWithSOAServerを選択します。
5. 次の情報を入力します。
   • Weblogic管理者ユーザー名: WebLogic管理者の名前を入力します。たとえば: weblogic。
   • WebLogic管理者パスワード: 前述のアカウントのパスワードを入力します。
   • OIMフロント・エンドURL: 内部コールバックに対して使用するロード・バランサ仮想ホストにこのURLを設定します。たとえば:

     http://igdinternal.example.com:7777/

   • OIM外部フロント・エンドURL: Oracle Identity Governanceに対して使用するメイン・ロード・バランサ仮想ホストにこのURLを設定します。たとえば:

     https://prov.example.com:443/

   • SOA SOAP URL: 内部コールバックに対して使用するSOA KubernetesサービスにこのURLを設定します。たとえば:

     http://governancedomain-cluster-soa-cluster.oigns.svc.cluster.local:8001

   • SOA RMI URL: 内部コールバックに対して使用するSOA KubernetesサービスにこのURLを設定します。たとえば:

     t3://<OIG_DOMAIN_NAME>-cluster-soa-cluster.<OIG NAMESPACE>.svc.cluster.local:8001

     前述のURLの例:

     t3://governancedomain-cluster-soa-cluster.oigns.svc.cluster.local:8001

   • UMS WebサービスURL: 内部コールバックに対して使用するSOA KubernetesサービスにこのURLを設定します。たとえば:

     http://governancedomain-cluster-soa-cluster.oigns.svc.cluster.local:8001/ucs/messaging/webservice

6. 「起動」をクリックします。

通知サービスの管理

イベントとは、Oracle Identity Managerで発生する操作で、ユーザー作成、リクエスト開始またはユーザーが作成した任意のカスタム・イベントなどが含まれます。これらのイベントは、ビジネス操作の一部として、またはエラー生成を介して生成されます。イベント定義は、イベントを記述するメタデータです。

イベントのメタデータを定義するには、機能コンポーネントでサポートされるすべてのイベント・タイプを識別する必要があります。たとえば、スケジューラ・コンポーネントの一部として、スケジュール済ジョブの実行の失敗とスケジューラの停止に対してメタデータが定義されます。ジョブが失敗するかスケジューラが停止するたびに、関連するイベントがトリガーされ、イベントに関連付けられた通知が送信されます。

イベントで使用可能なデータを使用して、通知のコンテンツが作成されます。イベントに定義された様々なパラメータにより、システムは適切な通知テンプレートを選択できます。イベントに定義されている各種のパラメータは、テンプレート設計時に使用可能にするイベント変数をシステムが決定する際に役立ちます。

通知テンプレートは、通知を送信するために使用されます。これらのテンプレートには、より詳細な通知を提供するために、使用可能なデータを参照する変数が含まれています。通知プロバイダを介して通知が送信されます。このようなチャネルの例には、電子メール、インスタント・メッセージ(IM)、ショート・メッセージ・サービス(SMS)、ボイスなどがあります。これらの通知プロバイダを使用するために、Oracle Identity ManagerではOracle User Messaging Service (UMS)が使用されます。

バックエンドでは、通知エンジンが通知の生成と通知プロバイダを利用した通知の送信を担当します。

• Oracle Unified Messagingを使用した通知
  
• CSFキーの更新
  

Oracle Unified Messagingを使用した通知

通知にOracle Unified Messaging (UMS)を使用するには、UMS電子メール通知プロバイダのプロパティを構成し、CSFキーを追加します。

UMSEmailNotificationProviderMBeanを使用してSMTP電子メール通知プロバイダのプロパティを構成するには:

1. 次のURLを使用してOracle Fusion Middleware Controlにログインします。

   http://igdadmin.example.com/em

   または

   http://k8worker1.example.com:30711/em

   管理サーバーのホストおよびポート番号は「構成の終了」画面のURLにありました(「ドメイン・ホームと管理サーバーURLの記録」)。デフォルトの管理サーバーのポート番号は7001です。

   ログイン資格証明は「管理者アカウントの構成」の「管理者アカウント」画面で指定されました。

2. 「weblogic_domain」,をクリックし、「システムMBeanブラウザ」をクリックします。
3. 検索ボックスに、UMSEmailNotificationProviderMBeanと入力して、「検索」をクリックします。mbeanが表示されます。

   ノート:

   Oracle Identity Governanceがまだ起動中(立ち上げ中)または起動したばかり(RUNNING MODE)の場合、Enterprise Managerに、OIMで定義されたMbeanは表示されません。サーバーが起動するまで2分間待ってから、Enterprise Managerの「システムMBeanブラウザ」でMbeanの検索を試みてください。
4. 特に電子メール・サーバーに関しては正しい情報を入力するようにします。

   表19-4 SMTP電子メール通知プロバイダのプロパティ

   属性	値
   Enabled	trueに設定します。
   MailServerName	電子メール・サーバーのホスト名を設定します。
   WSUrl	http://<OIG_DOMAIN_NAME>-cluster-soa-cluster.<OIGNS>.svc.cluster.local:8001/ucs/messaging/webservice

5. 「適用」をクリックして変更を保存します。

CSFキーの更新

CSFキーを更新するには:

1. Oracle Enterprise Managerにログインします。
2. 「WebLogicドメイン」をクリックし、「セキュリティ」、「資格証明」の順にクリックします。
3. oracle.wsm.securityを展開し、「キーの作成」をクリックします。
4. 次の情報を入力します。

   表19-5 CSFキーのプロパティ

   属性	値
   キー名	資格証明キーの値を入力します。これは「Oracle Unified Messagingを使用した通知」で定義されたものと同じ値(たとえば、mailUser)である必要があります。
   ユーザー名	電子メール・サーバーの認証に使用するユーザーの名前を入力します。
   パスワード/パスワードの確認	電子メール・サーバーの認証に使用するユーザーのパスワードを入力します。
   説明	作成するキーの説明を指定します。たとえば、メール・サーバーの資格証明

5. 「OK」をクリックします。

メッセージング・ドライバの構成

各メッセージング・ドライバを構成する必要があります。OAMのパスワードを忘れた場合の機能を有効にする場合は、このサービスを構成する必要があります。

• 電子メール・ドライバの構成
  

電子メール・ドライバの構成

ドライバを構成して電子メールを送信するには、次のステップを実行する必要があります。

1. Oracle Fusion Middleware Controlにログインします。
2. ドメイン名の隣の「ターゲット・ナビゲーション」アイコンをクリックします。
3. 「ユーザー・メッセージング・サービス」の下の「usermessagingserver (soa_server)」をクリックします。すべてのドライバのリストが表示されます。
4. 「ユーザー・メッセージング電子メール・ドライバ」の隣の「ドライバの構成」をクリックします。
5. 構成が存在しない場合は、「作成」をクリックします。構成が存在する場合は、「編集」をクリックします。
6. 必要な詳細情報を指定して属性を更新します。

   表19-6 電子メール・ドライバ属性の構成

   属性	値
   名前	MyemailServer
   送信者アドレス	電子メールの送信時に送信者として使用する電子メール・アドレスを、EMAIL:[e-mail]の形式で入力します
   機能	電子メールを送信するか、それとも受信するかを選択します。 次の電子メール・プロパティに組織固有の値を設定します。詳細は電子メール管理者にご確認ください。次の詳細は送信の場合にのみ必要になります。電子メール受信の詳細は、ドキュメントを参照してください。 送信メール・サーバー。 送信メール・サーバー・ポート 送信電子メール・サーバー・セキュリティ 送信で使用するユーザー名とパスワード(電子メール・サーバーから要求がある場合)。

7. 「テスト」をクリックして、情報を検証します。
8. 「OK」をクリックして、情報を保存します。

データベース接続プール・サイズの増加

Oracle Identity GovernanceをLDAPディレクトリとのインタラクションを許可するコネクタと組み合せて使用する場合には、デフォルトのデータベース接続プール・サイズを増加する必要があります。

これを行うには、次のステップを実行します:

1. IAMGovernanceDomainのWebLogic Server管理コンソールにログインします。
2. 「ロックして編集」をクリックします。
3. 「サービス」をクリックして、次に「データソース」をクリックします。
4. データソースmds-oimをクリックします。
5. 「接続プール」タブに移動します。
6. 次のプロパティを指定した値に変更します。
   • 初期容量: 50
   • 最大容量: 150
   • 最小容量: 50
   • 非アクティブ接続タイムアウトの値が30になっていなければ、30に設定します

   ノート:

   非アクティブ接続タイムアウトは「拡張」セクションにあります。
7. 「保存」をクリックします。
8. 「変更のアクティブ化」をクリックします。
9. 次のメッセージが表示されます: 「すべての変更がアクティブ化されました。」再起動は不要です。

Oracle Identity GovernanceとLDAPとの統合

OIGとLDAPを統合する前に、LDAPのコネクタを構成し、必要なオブジェクト・クラスが欠落している場合はそれらを追加する必要があります。

ノート:

次の各項では、プロパティ・ファイルを編集し、./OIGOAMIntegration.shスクリプトでそれらのプロパティ・ファイルを使用する必要があります。

Kubernetesコンテナには、エディタがありません。そのため、ファイルをローカル・マシンにコピーし、編集してからコピーして戻します。このコマンドの構文は次のとおりです。

kubectl cp <OIGNS>/<OIG_DOMAIN_NAME>-adminserver:<SOURCE FILENAME> <DESTINATION_FILENAME>

ファイルを編集してからコピーして戻します。ファイルをコピーしてKubernetesに戻す構文は、次のとおりです:

kubectl cp /workdir/OIG/configureLDAPConnector.config oigns/governancedomain-adminserver:/u01/oracle/idm/server/ssointg/config/configureLDAPConnector.config

• LDAP用のOracleコネクタの構成
  
• 不足しているオブジェクト・クラスの追加
  

LDAP用のOracleコネクタの構成

LDAP用のOracleコネクタを使用すると、認証されたLDAPディレクトリにユーザーおよびパスワードを格納できます。コネクタは構成してから使用します。コネクタは次のステップで構成します。

1. /u01/oracle/idm/server/ssointg/configディレクトリに移動します。

2. configureLDAPConnector.configファイルを編集します。

   次に、テンプレート・ファイルを示します:

   ## [configureLDAPConnector]
   IDSTORE_DIRECTORYTYPE=<LDAP_TYPE>
   OIM_HOST=<OIG_DOMAIN_NAME>-cluster-oim-cluster.<OIGNS>.svc.cluster.local
   OIM_PORT=14000
   OIM_SERVER_SYSADMIN_USER=<LDAP_XELSYSADM_USER>
   OIM_WLSHOST=<OIG_DOMAIN_NAME>-adminserver-external.<OIGNS>.svc.cluster.local
   OIM_WLSPORT=<OIG_ADMIN_PORT>
   OIM_WLSADMIN=<OIG_WEBLOGIC_USER>
   OIM_WLSADMIN_PWD=<OIG_WEBLOGIC_PWD>
   IDSTORE_HOST=<LDAP_HOST>
   IDSTORE_PORT=<LDAP_PORT>
   IDSTORE_BINDDN=<LDAP_ADMIN_USER>
   IDSTORE_OIMADMINUSERDN=cn=<LDAP_OIGLDAP_USER>,cn=<LDAP_SYSTEMIDS>,<LDAP_SEARCHBASE>
   IDSTORE_SEARCHBASE=<LDAP_SEARCHBASE>
   IDSTORE_USERSEARCHBASE=<LDAP_USER_SEARCHBASE>
   IDSTORE_GROUPSEARCHBASE=<LDAP_GROUP_SEARCHBASE>
   IDSTORE_USERSEARCHBASE_DESCRIPTION=Default user container
   IDSTORE_GROUPSEARCHBASE_DESCRIPTION=Default group container
   IDSTORE_EMAIL_DOMAIN=<OIG_EMAIL_DOMAIN>
   ## For ActiveDirectory use the values of "yes" or "no". i.e. IS_LDAP_SECURE=yes/no
   IS_LDAP_SECURE=false
   SSO_TARGET_APPINSTANCE_NAME=SSOTarget
   ## Path to expanded connector bundle: e.g. for OID and OUD
   CONNECTOR_MEDIA_PATH=/u01/oracle/user_projects/domains/ConnectorDefaultDirectory/OID-12.2.1.3.0
   WLS_OIM_SYSADMIN_USER_PWD=<LDAP_USER_PWD>
   IDSTORE_BINDDN_PWD=<LDAP_ADMIN_PWD>
   IDSTORE_OIMADMINUSER_PWD=<LDAP_USER_PWD>

   次に、例としてファイルのサンプルを示します:

   ##-----------------------------------------------------------##
   ## [configureLDAPConnector]
   IDSTORE_DIRECTORYTYPE=OUD
   OIM_HOST=governancedomain-cluster-oim-cluster.oigns.svc.cluster.local
   OIM_PORT=14000
   OIM_SERVER_SYSADMIN_USER=xelsysadm
   OIM_WLSHOST=governancedomain-adminserver-external.oigns.svc.cluster.local
   OIM_WLSPORT=7101
   OIM_WLSADMIN=weblogic
   OIM_WLSADMIN_PWD=<Password1>
   IDSTORE_HOST=edg-oud-ds-rs-lbr-ldap.oudns.svc.cluster.local
   IDSTORE_PORT=1389
   IDSTORE_BINDDN=cn=oudadmin
   IDSTORE_OIMADMINUSERDN=cn=oimLDAP,cn=systemids,dc=example,dc=com
   IDSTORE_SEARCHBASE=dc=example,dc=com
   IDSTORE_USERSEARCHBASE=cn=Users,dc=example,dc=com
   IDSTORE_GROUPSEARCHBASE=cn=Groups,dc=example,dc=com
   IDSTORE_USERSEARCHBASE_DESCRIPTION=Default user container
   IDSTORE_GROUPSEARCHBASE_DESCRIPTION=Default group container
   IDSTORE_EMAIL_DOMAIN=example.com
   ## For ActiveDirectory use the values of "yes" or "no". i.e. IS_LDAP_SECURE=yes/no
   IS_LDAP_SECURE=false
   SSO_TARGET_APPINSTANCE_NAME=SSOTarget
   ## Path to expanded connector bundle: e.g. for OID and OUD
   CONNECTOR_MEDIA_PATH=/u01/oracle/user_projects/ConnectorDefaultDirectory/OID-12.2.1.3.0
   WLS_OIM_SYSADMIN_USER_PWD=<PASSWORD>
   IDSTORE_BINDDN_PWD=<PASSWORD>
   IDSTORE_OIMADMINUSER_PWD=<PASSWORD>

   ノート:

   必要に応じて、ファイルに直接パスワードを指定することもできます。パスワードを指定しない場合、実行時にパスワードの入力を求められます。

   パラメータは次のとおりです:

   • OIM_WLSADMIN_PWD
   • IDSTORE_BINDDN_PWD
   • WLS_OIM_SYSADMIN_USER_PWD
   • ADMIN_USER_PWD
   • IDSTORE_OIMADMINUSER_PWD

   ファイルを保存します。

   ノート:

   「構成ファイルの作成」でこれらのパラメータに指定したものと同じ値を使用してください。

3. スクリプトOIGOAMIntegrationを実行してコネクタを構成します。

   たとえば:

   kubectl exec -n oigns -ti governancedomain-adminserver -- /bin/bash

   cd /u01/oracle/idm/server/ssointg/bin

   export JAVA_HOME=/u01/jdk

   export APPSERVER_TYPE=wls

   export ORACLE_HOME=/u01/oracle

   export OIM_ORACLE_HOME=/u01/oracle/idm

   export WL_HOME=$ORACLE_HOME/wlserver

   chmod 750 _OIGOAMIntegration.sh OIGOAMIntegration.sh

   ./OIGOAMIntegration.sh -configureLDAPConnector

不足しているオブジェクト・クラスの追加

Oracle Identity Manager有効化前からLDAPにユーザーが存在する場合は、新しいユーザーにOIM/OAM統合の制御に使用するオブジェクト・クラスが不足する可能性があります。このような不足しているオブジェクト・クラスを新しいユーザーに追加するには、次のコマンドを実行します:

ノート:

このプロセスを正常に実行するには、ldapsearchバイナリがユーザーのPATHに存在し、screenパッケージがホストにインストールされている必要があります。

1. /u01/oracle/idm/server/ssointg/configディレクトリに移動します。

2. ファイルaddMissingObjectClasses.configを編集し、次に示すプロパティを更新します。

   次に、テンプレート・ファイルを示します:

   IDSTORE_DIRECTORYTYPE=<LDAP_TYPE>
   IDSTORE_HOST=<LDAP_HOST>
   IDSTORE_PORT=<LDAP_PORT>
   IDSTORE_BINDDN=<LDAP_ADMIN_USER>
   IDSTORE_USERSEARCHBASE=<LDAP_USER_SEARCHBASE>

   次に、例としてファイルのサンプルを示します:

   IDSTORE_DIRECTORYTYPE=OUD
   IDSTORE_HOST=edg-oud-ds-rs-lbr-ldap.oudns.svc.cluster.local
   IDSTORE_PORT=1389
   IDSTORE_BINDDN=oudadmin
   IDSTORE_USERSEARCHBASE=cn=Users,dc=example,dc=com

   ファイルを保存します。

3. スクリプトOIGOAMIntegrationを実行します。

   たとえば:

   kubectl exec -n oigns -ti governancedomain-adminserver --/bin/bash

   cd /u01/oracle/idm/server/ssointg/bin

   export JAVA_HOME=/u01/jdk

   export APPSERVER_TYPE=wls

   export ORACLE_HOME=/u01/oracle

   export OIM_ORACLE_HOME=/u01/oracle/idm

   export WL_HOME=$ORACLE_HOME/wlserver

   ./OIGOAMIntegration.sh -addMissingObjectClasses

   パラメータ・ファイルへの入力としてパスワードを指定していない場合は、LDAPディレクトリ管理者アカウントのパスワードの入力を求められます。

Oracle Identity GovernanceとOracle Access Managerとの統合

Oracle Identity GovernanceとOracle Access Managerを統合するには、いくつかのタスクを完了する必要があります。これらのタスクには、WLS認証プロバイダの作成、OIMSignatureAuthenticatorの削除とOUDAuthenticatorの再作成、新しい管理グループへの管理ロールの追加などが含まれます。

• WLS認証プロバイダの作成
  
• OIMSignatureAuthenticatorの削除
  
• OUDAuthenticatorの再作成
  
• 新しい管理グループへの管理ロールの追加
  
• GovernanceドメインでのSSO統合の構成
  
• OAM通知の有効化
  
• oam-config.xmlのMatchLDAPAttributeの値の更新
  
• TapEndpoint URLの更新
  

WLS認証プロバイダの作成

WLS認証プロバイダを構成して、OIGドメインのSSOログアウトおよびセキュリティ・プロバイダを設定する必要があります。これにより、SSOログインとOIMクライアントベース・ログインの両方が適切に動作します。

1. /u01/oracle/idm/server/ssointg/configディレクトリに移動します。
2. configureWLSAuthnProviders.configファイルを編集して、次のプロパティを設定します:

   これはテンプレート・ファイルです:

   OIM_WLSHOST: <OIG_DOMAIN_NAME>-adminserver.<OIGNS>.svc.cluster.local
   OIM_WLSPORT=<OIG_ADMIN_PORT>
   OIM_WLSADMIN=<OIG_WEBLOGIC_USER>
   OIM_WLSADMIN_PWD=<OIG_WEBLOGIC_PWD>
   OIM_SERVER_NAME=oim_server1
   ## DIRTYPE values can be [OID | OUD | AD]
   IDSTORE_DIRECTORYTYPE=<LDAP_TYPE>
   IDSTORE_HOST=<LDAP_HOST>
   IDSTORE_PORT=<LDAP_PORT>
   IDSTORE_BINDDN=<LDAP_ADMIN_USER>
   IDSTORE_BINDDN_PWD=<LDAP_ADMIN_PWD>
   IDSTORE_USERSEARCHBASE=<LDAP_USER_SEARCHBASE>
   IDSTORE_GROUPSEARCHBASE=<LDAP_GROUP_SEARCHBASE>

   これはサンプル・ファイルです:

   OIM_WLSHOST: governancedomain-adminserver.oigns.svc.cluster.local
   OIM_WLSPORT: 7101
   OIM_WLSADMIN=weblogic
   OIM_WLSADMIN_PWD=<password>
   OIM_SERVER_NAME=oim_server1
   IDSTORE_DIRECTORYTYPE=OUD
   IDSTORE_HOST=edg-oud-ds-rs-lbr-ldap.oudns.svc.cluster.local
   IDSTORE_PORT=1389
   IDSTORE_BINDDN=cn=oudadmin
   IDSTORE_BINDDN_PWD=<password>
   IDSTORE_USERSEARCHBASE=cn=Users,dc=example,dc=com
   IDSTORE_GROUPSEARCHBASE=cn=Groups,dc=example,dc=com

   ファイルを保存します。

3. OIGOAMIntegrationスクリプトを実行して、WebLogicセキュリティ・プロバイダを構成します。

   kubectl exec -n oigns -ti governancedomain-adminserver -- /bin/bash

   cd /u01/oracle/idm/server/ssointg/bin

   export JAVA_HOME=/u01/jdk

   export APPSERVER_TYPE=wls

   export ORACLE_HOME=/u01/oracle

   export OIM_ORACLE_HOME=/u01/oracle/idm

   export WL_HOME=$ORACLE_HOME/wlserver

   ./OIGOAMIntegration.sh -configureWLSAuthnProviders

OIMSignatureAuthenticatorの削除

createWLSAuthenticatorスクリプトによって、OIMSignatureAuthenticatorという新しいセキュリティ・プロバイダが作成されます。このセキュリティ・プロバイダは、Oracle Identity Manager 12cでは必要ありません。

セキュリティ・プロバイダを削除するには:

1. WebLogic Server管理コンソールにログインしていない場合は、ログインします。
2. 「ロックして編集」をクリックします。
3. 左のナビゲーション・ペインにある「セキュリティ・レルム」をクリックします。
4. myrealmというデフォルト・レルム・エントリをクリックします。
5. 「プロバイダ」タブをクリックします。
6. セキュリティ・プロバイダOIMSignatureAuthenticatorを選択します。
7. 「削除」をクリックします。
8. 「はい」をクリックし、削除を確定します。
9. 「変更のアクティブ化」をクリックして変更を伝播します。

OUDAuthenticatorの再作成

ターゲット・ディレクトリがOUDの場合は、OUDAuthenticatorセキュリティ・プロバイダを削除して再作成する必要があります。

セキュリティ・プロバイダを削除するには:

1. WebLogic Server管理コンソールにログインしていない場合は、ログインします。
2. 「ロックして編集」をクリックします。
3. 左のナビゲーション・ペインにある「セキュリティ・レルム」をクリックします。
4. myrealmというデフォルト・レルム・エントリをクリックします。
5. 「プロバイダ」タブをクリックします。
6. セキュリティ・プロバイダOUDAuthenticatorを選択します。
7. 「削除」をクリックします。
8. 「はい」をクリックし、削除を確定します。
9. 「変更のアクティブ化」をクリックして変更を伝播します。

セキュリティ・プロバイダを再作成するには:

1. URLを使用してWebLogic Server管理コンソールにログインします。

   http://k8worker1.example.com:30711/console

2. 左のナビゲーション・バーにある「セキュリティ・レルム」をクリックします。

3. myrealmというデフォルト・レルム・エントリをクリックします。

4. 「プロバイダ」タブをクリックします。

5. 「チェンジ・センター」で「ロックして編集」をクリックします。

6. 「認証プロバイダ」表の下の「新規」ボタンをクリックします。

7. プロバイダの名前を入力します。

   資格証明ストアとして使用する予定のLDAPディレクトリ・サービスに基づいて、次のいずれかの名前を使用します。

   OUDAuthenticator (Oracle Unified Directoryの場合)

8. 「タイプ」ドロップダウン・リストで、Oracle Unified Directoryのオーセンティケータ・タイプOracleUnifiedDirectoryAuthenticatorを選択します。

9. 「OK」をクリックして「プロバイダ」画面に戻ります。

10. 「プロバイダ」画面の表で、新しく作成したオーセンティケータをクリックします。

11. 「制御フラグ」ドロップダウン・メニューで「SUFFICIENT」を選択します。

    制御フラグをSUFFICIENTに設定すると、そのオーセンティケータがユーザーを正常に認証できる場合はその認証を受け入れ、それ以上のオーセンティケータを起動しません。

    正常に認証できない場合は、チェーン内の次のオーセンティケータに引き継がれます。以降のすべてのオーセンティケータの制御フラグも「SUFFICIENT」に設定されていることを確認してください。特にDefaultAuthenticatorをチェックして、その制御フラグが「SUFFICIENT」に設定されていることを確認します。

12. 「保存」をクリックして、制御フラグ設定の変更を確定します。

13. 「プロバイダ固有」タブをクリックし、次の表に示すように、使用するLDAPサーバーに固有の詳細を入力します。

    ノート:

    この手順では、必須フィールドのみを説明しています。このページのすべてのフィールドの詳細は、次のリソースを参照してください。

    • 各フィールドの説明を表示するには、「プロバイダ固有」タブの「ヘルプ」をクリックします。
    • 「ユーザー・ベースDN」、「名前指定によるユーザー・フィルタ」、「ユーザー属性」の各フィールドの設定に関する詳細は、『Oracle WebLogic Serverセキュリティの管理』のOracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダでのユーザーおよびグループの構成に関する項を参照してください。

    パラメータ	サンプル値	値の説明
    ホスト	たとえば: edg-oud-ds-rs-lbr-ldap.oudns.svc.cluster.local	LDAPサーバーのサーバーID。
    ポート	たとえば: 1389	LDAPサーバーのポート番号。
    プリンシパル	たとえば: cn=oimLDAP,cn=systemids,dc=example,dc=com	LDAPサーバーへの接続に使用されるLDAPユーザーのDN。
    資格証明	LDAPパスワードを入力します。	LDAPサーバーへの接続に使用されるパスワード。
    SSLの有効化	選択解除(クリア)	LDAPサーバーに接続するときにSSLプロトコルを使用するかどうかを指定します。
    ユーザー・ベースDN	たとえば: cn=users,dc=example,dc=com	ユーザーが開始時に使用するDNを指定します。
    すべてのユーザーのフィルタ	(&(uid=*)(objectclass=person))	「すべてのユーザーのフィルタ」のデフォルトの検索基準のかわりに、uid値に基づいてすべてのユーザーを検索します。 LDAPディレクトリ構造のユーザー・オブジェクト・クラスの「ユーザー名属性」がuid以外のタイプである場合は、「名前指定によるユーザー・フィルタ」フィールドで、そのタイプを変更します。 たとえば、「ユーザー名属性」のタイプがcnである場合は、このフィールドを次のように設定する必要があります。 (&(cn=*)(objectclass=person)))
    名前指定によるユーザー・フィルタ	たとえば: (&(uid=%u)(objectclass=person))	LDAPディレクトリ構造のユーザー・オブジェクト・クラスの「ユーザー名属性」がuid以外のタイプである場合は、「名前指定によるユーザー・フィルタ」の設定で、そのタイプを変更します。 たとえば、「ユーザー名属性」のタイプがcnである場合は、このフィールドを次のように設定する必要があります。 (&(cn=%u)(objectclass=person)))
    ユーザー名属性	たとえば: uid	グループの名前を指定するLDAPユーザー・オブジェクトの属性。
    取得したユーザー名をプリンシパルとして使用する	選択	オンにする必要があります。
    グループ・ベースDN	たとえば: cn=groups,dc=example,dc=com	グループ・ノードを指すDNを指定します。
    すべてのグループのフィルタ	(&(cn=*)(objectclass=groupOfUniqueNames))	グループ・フィルタを指定します。
    GUID属性	entryuuid	OUDにOracleUnifiedDirectoryAuthenticatorが使用されている場合、この値にはentryuuidが事前に移入されています。認証プロバイダとしてOracle Unified Directoryを使用している場合は、この値を確認します。

14. 「保存」をクリックして、変更を保存します。

15. 右のナビゲーション・ペインで「セキュリティ・レルム」をクリックして、デフォルトのレルム名(myrealm)をクリックし、「プロバイダ」をクリックして「プロバイダ」ページに戻ります。

16. 「並替え」をクリックし、表示されるページを使用して、次の順序と一致するようにプロバイダのリストを並べ替えます:

    認証プロバイダのリスト

    • OAMIDAsserter
    • OUDAuthenticator
    • DefaultAuthenticator
    • OIMAuthenticationProvider
    • 信頼サービスIDアサータ
    • DefaultIdentityAsserter

17. 「OK」をクリックします。

18. 「チェンジ・センター」で、「変更のアクティブ化」をクリックします。

19. 変更を有効にするには、ドメインを再起動する必要があります。次のコマンドを使用して再起動できます:

    kubectl -n <OIGNS> patch domains <OIG_DOMAIN_NAME> --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "Never" }]'

    すべて停止したら、次のコマンドを使用して再起動できます:

    kubectl -n <OIGNS> patch domains <OIG_DOMAIN_NAME> --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "IfNeeded" }]'

    たとえば:

    kubectl -n oigns patch domains governancedomain --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "Never" }]'
    kubectl -n oigns patch domains governancedomain --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "IfNeeded" }]'

20. 再起動後、次の場所にあるAdminServer.logファイルの内容を確認します:

    /u01/oracle/user_projects/domains/logs/governancedomain

    LDAP接続エラーが発生していないことを確認します。たとえば、次のようなエラーを探します。

    The LDAP authentication provider named "OUDAuthenticator" failed to make connection to ldap server at ...
    

    ログ・ファイルでこのようなエラーが見つかった場合は、認可プロバイダ接続の詳細をチェックして、それらが適切であることを確認し、管理サーバーの保存と再起動をもう一度試みます。

21. 再起動後、LDAP接続エラーがログ・ファイルに記述されていないことを確認し、LDAPプロバイダ内に存在するユーザーとグループの参照を試みます。

    管理コンソールで、「セキュリティ・レルム」→「myrealm」→「ユーザーとグループ」ページに移動します。LDAPプロバイダ構造内に存在するすべてのユーザーおよびグループを表示できるようになります。

新しい管理グループへの管理ロールの追加

これにより、このグループに属するすべてのユーザーがそのドメインの管理者になることができます。

管理ロールを新しいエンタープライズ・デプロイメント管理グループに割り当てるには:

1. 構成ウィザードで指定した管理資格証明を使用してWebLogic管理サーバー・コンソールにログインします。

   作成して新しい認証プロバイダに提供した管理ユーザーの資格証明は使用しないでください。

2. 管理コンソールの左ペインで、「セキュリティ・レルム」をクリックします。
3. デフォルト・セキュリティ・レルム(myrealm)をクリックします。
4. 「ロールとポリシー」タブをクリックします。
5. 表の「グローバル・ロール」エントリを開き、「ロール」をクリックします。
6. 「管理」ロールをクリックします。
7. 「条件の追加」をクリックします。
8. 「述部リスト」ドロップダウン・メニューで「グループ」を選択し、「次へ」をクリックします。
9. 「グループ引数名」フィールドにWLSAdministratorsと入力して、「追加」をクリックします。

   WLSAdministratorsが引数のリスト・ボックスに追加されます。

10. 「終了」をクリックして、「グローバル・ロールの編集」ページに戻ります。

    WLSAdministratorsグループが表示されるようになりました。

11. 「保存」をクリックして、WLSAdministratorsグループへの「管理」ロールの追加を終了します。
12. 新しいweblogic_iamユーザーの資格証明を使用してWebLogic管理サーバー・コンソールにログインし、変更が行われたことを確認します。

    新しい認証プロバイダでプロビジョニングした新しい管理ユーザーの資格証明を使用してOracle WebLogic Server管理コンソールとFusion Middleware Controlにログインできる場合は、プロバイダは正常に構成されています。

GovernanceドメインでのSSO統合の構成

コネクタをデプロイしたら、プロセスの次のステップは、ドメインのSSOの構成です。SSOを構成するには、次のステップを実行します:

1. /u01/oracle/idm/server/ssointg/configディレクトリに移動します

2. ファイルconfigureSSOIntegration.configを編集し、セクションconfigureSSOIntegrationのプロパティを次に示すように更新します:

   これはテンプレート・ファイルです:

   NAP_VERSION=4
   COOKIE_EXPIRY_INTERVAL=120
   OAM_HOST=<OAM_LOGIN_LBR_HOST>
   OAM_PORT=<OAM_LOGIN_LBR_PORT>
   ACCESS_SERVER_HOST=<OAM_DOMAIN_NAME>-oap.<OAMNS>.svc.cluster.local
   ACCESS_SERVER_PORT=<OAM_OAP_PORT>
   OAM_SERVER_VERSION=12c
   WEBGATE_TYPE=ohsWebgate12c
   ACCESS_GATE_ID=Webgate_IDM
   ACCESS_GATE_PWD=<PASSWORD>
   COOKIE_DOMAIN=example.com
   OAM_TRANSFER_MODE=open
   OIM_LOGINATTRIBUTE=uid
   SSO_ENABLED_FLAG=true
   SSO_INTEGRATION_MODE=CQR
   OAM11G_WLS_ADMIN_HOST=<OAM_DOMAIN_NAME>-adminserver.<OAMNS>.svc.cluster.local
   OAM11G_WLS_ADMIN_PORT=30012
   OAM11G_WLS_ADMIN_USER=<OAM_WEBLOGIC_USER>
   OAM11G_WLS_ADMIN_PASSWD=<OAM_WEBLOGIC_PWD>
   OAM11G_IDSTORE_NAME=OAMIDSTORE
   ## Required if OAM_TRANSFER_MODE is not OPEN
   SSO_KEYSTORE_JKS_PASSWORD=<GLOBAL_PASSPHRASE>
   SSO_GLOBAL_PASSPHRASE=<GLOBAL_PASSPHRASE>
   OIM_WLSHOST=<OIG_DOMAIN_NAME>-adminserver.<OIGNS>.svc.cluster.local
   OIM_WLSPORT=<OIG_ADMIN_PORT>
   OIM_WLSADMIN=<OIG_WEBLOGIC_USER>
   IDSTORE_OAMADMINUSER_PWD=<LDAP_USER_PWD>
   OIM_SERVER_NAME=<OIM_SERVER_NAME>
   IDSTORE_OAMADMINUSER=<LDAP_OAMADMIN_USER>

   これはサンプル・ファイルです:

   NAP_VERSION=4
   COOKIE_EXPIRY_INTERVAL=120 
   OAM_HOST=login.example.com
   OAM_PORT=443
   ACCESS_SERVER_HOST=accessdomain-oap.oamns.svc.cluster.local
   ACCESS_SERVER_PORT=5575
   OAM_SERVER_VERSION=12c
   WEBGATE_TYPE=ohsWebgate12c
   ACCESS_GATE_ID=Webgate_IDM
   ACCESS_GATE_PWD=<password>
   COOKIE_DOMAIN=example.com
   OAM_TRANSFER_MODE=Simple
   OIM_LOGINATTRIBUTE=uid
   SSO_ENABLED_FLAG=true
   SSO_INTEGRATION_MODE=CQR
   OAM11G_WLS_ADMIN_HOST=accessdomain-adminserver.oamns.svc.cluster.local
   OAM11G_WLS_ADMIN_PORT=30012
   OAM11G_WLS_ADMIN_USER=weblogic
   OAM11G_WLS_ADMIN_PASSWD=<PASSWORD>
   OAM11G_IDSTORE_NAME=OAMIDSTORE
   ## Required if OAM_TRANSFER_MODE is not OPEN
   SSO_KEYSTORE_JKS_PASSWORD=<GLOBAL_PASSPHRASE>
   SSO_GLOBAL_PASSPHRASE=<GLOBAL_PASSPHRASE>
   OIM_WLSHOST=governancedomain-adminserver.oigns.svc.cluster.local
   OIM_WLSPORT=7101
   OIM_WLSADMIN=weblogic
   IDSTORE_OAMADMINUSER_PWD=<password>
   OIM_SERVER_NAME=oim_server1
   IDSTORE_OAMADMINUSER=oamadmin

   終了後、ファイルを保存します。

   ノート:

   変数をデプロイメントに適用可能な値に置き換えます。「この章で使用される変数」を参照してください。その他の指定値はそのまま使用する必要があります。

3. OIGOAMIntegrationスクリプトを実行してSSO統合を構成します。

   たとえば:

   kubectl exec -n oigns -ti governancedomain-adminserver -- /bin/bash

   cd /u01/oracle/idm/server/ssointg/bin

   export JAVA_HOME=/u01/jdk

   export APPSERVER_TYPE=wls

   export ORACLE_HOME=/u01/oracle

   export OIM_ORACLE_HOME=/u01/oracle/idm

   export WL_HOME=$ORACLE_HOME/wlserver

   chmod 750 _OIGOAMIntegration.sh OIGOAMIntegration.sh

   ./OIGOAMIntegration.sh -configureSSOIntegration

4. IAMAccessDomainとIAMGovernanceDomainのドメインを再起動します。

OAM通知の有効化

コネクタをデプロイしたら、プロセスの次のステップは、ユーザー名の期限切れまたは終了後にOAMと対話してユーザー・セッションを終了する方法をOIMに指示することです。このアクティビティを完了するには、次のステップを実行する必要があります:

1. /u01/oracle/idm/server/ssointg/configディレクトリに移動します。

2. enableOAMSessionDeletion.configファイルを編集し、enableOAMNotificationsセクションのプロパティを更新します。

   これはファイルのテンプレートです:

   OIM_WLSHOST: <OIG_DOMAIN_NAME>-adminserver.<OIGNS>.svc.cluster.local
   OIM_WLSPORT=<OIG_ADMIN_PORT>
   OIM_WLSADMIN=<OIG_WEBLOGIC_USER>
   OIM_WLSADMIN_PWD=<OIG_WEBLOGIC_PWD>
   IDSTORE_DIRECTORYTYPE=<LDAP_TYPE>
   IDSTORE_HOST=<LDAP_HOST>
   IDSTORE_PORT=<LDAP_PORT>
   IDSTORE_BINDDN=<LDAP_ADMIN_USER>
   IDSTORE_GROUPSEARCHBASE=<LDAP_GROUP_SEARCHBASE> 
   IDSTORE_SYSTEMIDBASE: cn=<LDAP_SYSTEMIDS>,<LDAP_SEARCHBASE> 
   IDSTORE_OAMADMINUSER: <LDAP_OAMADMIN_USER> 
   IDSTORE_OAMSOFTWAREUSER: <LDAP_OAMLDAP_USER>
   IDSTORE_USERSEARCHBASE: <LDAP_USER_SEARCHBASE>
   OIM_SERVER_NAME: <OIM_SERVER_NAME>

   これはサンプル・ファイルです:

   OIM_WLSHOST: governancedomain-adminserver.oigns.svc.cluster.local
   OIM_WLSPORT: 7101
   OIM_WLSADMIN: weblogic
   OIM_WLSADMIN_PWD: <password>
   IDSTORE_DIRECTORYTYPE: OUD
   IDSTORE_HOST: edg-oud-ds-rs-lbr-ldap.oudns.svc.cluster.local
   IDSTORE_PORT: 1389
   IDSTORE_BINDDN: cn=oudadmin
   IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=example,dc=com 
   IDSTORE_SYSTEMIDBASE: cn=systemids,dc=example,dc=com 
   IDSTORE_OAMADMINUSER: oamAdmin 
   IDSTORE_OAMSOFTWAREUSER: oamLDAP
   IDSTORE_USERSEARCHBASE: cn=Users,dc=example,dc=com
   OIM_SERVER_NAME: oim_server1

3. スクリプトOIGOAMIntegrationを実行して通知を有効にします。

   たとえば:

   kubectl exec -n oigns -ti governancedomain-adminserver -- /bin/bash

   cd /u01/oracle/idm/server/ssointg/bin

   export JAVA_HOME=/u01/jdk

   export APPSERVER_TYPE=wls

   export ORACLE_HOME=/u01/oracle

   export OIM_ORACLE_HOME=/u01/oracle/idm

   export WL_HOME=$ORACLE_HOME/wlserver

   chmod 750 _OIGOAMIntegration.sh OIGOAMIntegration.sh

   ./OIGOAMIntegration.sh -enableOAMSessionDeletion

oam-config.xmlのMatchLDAPAttributeの値の更新

Oracle Access ManagerとのOracle Identity Governanceの統合を完了するには、Oracle Access Managerのoam-config.xmlファイルの設定の1つを変更する必要があります。バージョン12cでは、このファイルはデータベースに格納され、直接編集することはできません。

次の手順では、REST APIを使用してoam-config.xmlファイルの値の1つを変更する方法を示します:

ノート:

コマンド行でwhich curlを実行し、cURLパッケージがホストに追加されていることを確認します。パッケージがインストールされていない場合、管理者はyum install curlを実行してパッケージをインストールする必要があります。

1. 次を実行して、DAPModuleのコンポーネント番号を見つけます:

   curl -i -u oamadmin:<LDAP_USER_PWD> http://k8worker1.example.com:30701/iam/admin/config/api/v1/config?path=/DeployedComponent/Server/NGAMServer/Profile/AuthenticationModules/DAPModules

   出力例:

   HTTP/1.1 200 OK
   Date: Tue, 09 Jul 2019 20:30:33 GMT
   Content-Length: 625
   Content-Type: text/xml
   X-ORACLE-DMS-ECID: 6f9baf65-751b-4fc9-b2e1-ade5b38063ff-00000427
   X-ORACLE-DMS-RID: 0
   Set-Cookie: JSESSIONID=g3LYbkLA2bs5-9zfoMBqKTBbk0mky_8URGgzFnbNkm8n3tK63tq4!1064195705; path=/; HttpOnly

   <Configuration xmlns="http://www.w3.org/2001/XMLSchema" schemaLocation="http://higgins.eclipse.org/sts/Configuration Configuration.xsd" Path="/DeployedComponent/Server/NGAMServer/Profile/AuthenticationModules/DAPModules">

   <Setting Name="DAPModules" Type="htf:map">
       <Setting Name="7DASE52D" Type="htf:map">
         <Setting Name="MAPPERCLASS" Type="xsd:string">oracle.security.am.engine.authn.internal.executor.DAPAttributeMapper</Setting>
         <Setting Name="MatchLDAPAttribute" Type="xsd:string”>cn</Setting>
         <Setting Name="name" Type="xsd:string">DAP</Setting>
       </Setting>
     </Setting>

   ノート:

   "<Setting Name="DAPModules" Type="htf:map">"という行の下のコンポーネント番号を、構成の変更に使用する必要があります。前述の例では、"7DASE52D"がコンポーネント番号です。変更する必要がある値は、MatchLDAPAttributeの値です。前述の例では、"User Name"が現在の値です。
2. /tmpに移動して、次の内容の構成ファイルMatchLDAPAttribute_input.xmlを作成します:

   <Configuration>
     <Setting Name="MatchLDAPAttribute" Type="xsd:string" Path="/DeployedComponent/Server/NGAMServer/Profile/AuthenticationModules/DAPModules/7DASE52D/MatchLDAPAttribute">uid</Setting>
   </Configuration>

   ノート:

   前述のコンポーネント番号は、パスのDAPModulesとMatchLDAPAttributeの部分の間に挿入されます。構成ファイルにより、MatchLDAPAttributeの値がUser Nameからuidに変更されます。
3. 次を実行して、OAM構成に戻って変更を挿入します:

   curl -u oamadmin:<LDAP_USER_PWD> -H 'Content-Type: text/xml' -X PUT http://k8worker1.example.com:30701/iam/admin/config/api/v1/config -d @MatchLDAPAttribute_input.xml

4. MatchLDAPAttributeタグの値に注意し、最初にコンポーネントの問合せに使用したものと同じコマンドで、変更を検証します:

   curl -i -u oamadmin:<LDAP_USER_PWD> http://k8worker1.example.com:30701/iam/admin/config/api/v1/config?path=/DeployedComponent/Server/NGAMServer/Profile/AuthenticationModules/DAPModules

   出力例:

   HTTP/1.1 200 OK
   Date: Tue, 09 Jul 2019 20:30:33 GMT
   Content-Length: 625
   Content-Type: text/xml
   X-ORACLE-DMS-ECID: 6f9baf65-751b-4fc9-b2e1-ade5b38063ff-00000427
   X-ORACLE-DMS-RID: 0
   Set-Cookie: JSESSIONID=g3LYbkLA2bs5-9zfoMBqKTBbk0mky_8URGgzFnbNkm8n3tK63tq4!1064195705; path=/; HttpOnly

   <Configuration xmlns="http://www.w3.org/2001/XMLSchema" schemaLocation="http://higgins.eclipse.org/sts/Configuration Configuration.xsd" Path="/DeployedComponent/Server/NGAMServer/Profile/AuthenticationModules/DAPModules">

   <Setting Name="DAPModules" Type="htf:map">
       <Setting Name="7DASE52D" Type="htf:map">
         <Setting Name="MAPPERCLASS" Type="xsd:string">oracle.security.am.engine.authn.internal.executor.DAPAttributeMapper</Setting>
         <Setting Name="MatchLDAPAttribute" Type="xsd:string”>uid</Setting>
         <Setting Name="name" Type="xsd:string">DAP</Setting>
       </Setting>
     </Setting>

TapEndpoint URLの更新

OAM/OIM統合を有効にするには、次のステップを実行してOAM TapEndpoint URLを更新する必要があります。

1. 次のURLを使用してOracle Fusion Middleware Controlにログインします。

   http://igdadmin.example.com/em

   または

   http://k8worker1.example.com:30711/em

   管理サーバーのホストおよびポート番号は「構成の終了」画面のURLにありました(「ドメイン・ホームと管理サーバーURLの記録」)。デフォルトの管理サーバーのポート番号は7101です。

2. 「WebLogicドメイン」をクリックし、「システムMBeanブラウザ」をクリックします。

   検索ボックスに、SSOIntegrationMXBeanと入力して、「検索」をクリックします。mbeanが表示されます。

3. TapEndpointURLに次の値を設定します

   https://login.example.com/oam/server/dap/cred_submit

4. 「適用」をクリックします。

リコンシリエーション・ジョブの実行

Oracle Identity Governanceドメインを実行して、LDAPユーザー名をOracle Identity Governanceデータベースにインポートします。

リコンシリエーション・ジョブを実行するには:

1. OIMシステム管理コンソールにユーザーxelsysadmとしてログインします。
2. 「システム構成」の下の「スケジューラ」をクリックします。
3. 検索ボックスにSSO*と入力します。
4. 「スケジュール済ジョブの検索」の矢印をクリックして、すべてのスケジューラを一覧表示します。
5. SSOユーザー完全リコンシリエーションを選択します。
6. 「即時実行」をクリックしてジョブを実行します。
7. SSOグループ作成および更新完全リコンシリエーションに対して繰り返します。
8. OIMアイデンティティ・コンソールにログインして、ユーザーweblogic_iamが表示されることを確認します。

電子メールで送信するOIMワークフロー通知の構成

OIMでは、SOAワークフローと統合されたヒューマン・ワークフローが使用されます。SOAサーバーで電子メールを構成し、通知を受信してユーザーのメールボックスに配信します。ユーザーは、通知を承認または拒否できます。

すべての機能を使用するには、ポータル・ワークフロー専用の送受信メール・アドレスおよびメールボックスが必要になります。『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のヒューマン・ワークフロー通知プロパティの構成に関する項を参照してください。

OIMワークフロー通知を構成するには:

1. 管理者のアカウントを使用してFusion Middleware Controlにログインします。たとえば、weblogic_iamです。
2. 「ターゲット・ナビゲーション」パネルを展開して、「SOA」→「soa-infra (soa_server1)」サービスに移動します。
3. 「SOAインフラストラクチャ」ドロップダウンから、「SOA管理」→「ワークフロー・プロパティ」の順に選択します。
4. 通知モードを「電子メール」に設定します。通知サービスに正しい電子メール・アドレスを指定します。
5. 「適用」をクリックし、要求に応じて確認します。
6. 変更を確認します。
7. 「ターゲット・ナビゲーション」を展開して、「ユーザー・メッセージング・サービス」→「usermessagingdriver-email (soa_servern)」の順に選択します。実行中のSOA管理対象サーバーごとに、1つのドライバがあります。これらのエントリの1つのみを選択する必要があります。
8. 「ユーザー・メッセージング電子メール・ドライバ」ドロップダウン・リストから、「電子メール・ドライバ・プロパティ」を選択します。
9. 電子メール・ドライバが存在しない場合は、「作成」をクリックします。
10. 「テスト」をクリックして変更を検証します。
11. 「OK」をクリックして電子メール・ドライバ構成を保存します。
12. SOAクラスタを再起動します。OIMの場合、構成または再起動は不要です。

Administratorsグループへのwsm-pmロールの追加

新しいLDAPベースの認可プロバイダを構成して管理サーバーを再起動したら、エンタープライズ・デプロイメント管理LDAPグループ(WLSAdministrators)をメンバーとしてwsm-pmアプリケーション・ストライプのpolicy.Updaterロールに追加します。

1. 管理者のアカウントを使用してFusion Middleware Controlにサインインします。たとえば、weblogic_iamです。
2. 「WebLogicドメイン」メニューから、「セキュリティ」→「アプリケーション・ロール」を選択します。
3. 「アプリケーション・ストライプ」ドロップダウン・メニューから、wsm-pmアプリケーション・ストライプを選択します。
4. ロール名テキスト・ボックスの隣にある三角形のアイコンをクリックし、wsm-pmアプリケーション・ストライプのロール名をすべて検索します。
5. 編集するpolicy.Updater の行を選択します。
6. アプリケーション・ロールの「編集」アイコンをクリックして、ロールを編集します。
7. 「アプリケーション・ロールの編集」ページで、アプリケーション・ロールの「追加」アイコンをクリックします。
8. 「プリンシパルの追加」ダイアログ・ボックスで、「タイプ」ドロップダウン・メニューから「グループ」を選択します。
9. エンタープライズ・デプロイメントの管理者グループを検索するには、「プリンシパル名」の「次で始まる」フィールドにグループ名WLSAdministratorsを入力し、右矢印をクリックして検索を開始します。
10. 検索結果で適切な管理者グループを選択し、「OK」をクリックします。
11. 「アプリケーション・ロールの編集」ページで、「OK」をクリックします。

SOA管理者へのWebLogic管理グループの追加

LDAP管理グループWLSAdministratorsのユーザーを使用してSOAを管理するには、グループの名前をSOA管理者グループに追加する必要があります。

グループを追加するには:

1. 管理者のアカウントを使用してFusion Middleware Controlにサインインします。例: weblogic。
2. ナビゲーション・ペインで、「WebLogicドメイン」をクリックし、「セキュリティ」メニューから「アプリケーション・ロール」を選択します。
3. ドロップダウン・リストから、「soa-infra」を選択してアプリケーション・ストライプを設定します。「検索」をクリックします。
4. SOAAdminをクリックします。メンバーシップ・ボックスに「Administrators」が表示されることを確認します。
5. 「編集」をクリックします。「編集」ページが表示されます。
6. 「メンバー」ボックスで「追加」をクリックします。「プリンシパルの追加」検索ボックスが表示されます。
   1. 次のように入力します:
      • タイプ: Group
      • プリンシパル名が次で始まる: WLS
   2. 「検索」をクリックします。
   3. 「結果」ボックスからWLSAdministratorsを選択し、「OK」をクリックします。
      「編集」画面にリダイレクトされます。メンバーがAdministratorsおよびWLSAdministratorsであることを確認します。
   4. 「OK」をクリックします。

Oracleキーストア・サービスへのOracle Access Managerロード・バランサ証明書の追加

セルフ・サービス・アプリケーション内部のOracle Identity GovernanceからBusiness Intelligenceレポートへのリンクでは、ロード・バランサによって使用されるSSL証明書をOracleキーストア・サービスの信頼できる証明書に追加する必要があります。

証明書を追加する手順は、次のとおりです。

1. ユーザーが作成したキーストアと証明書を格納するディレクトリを作成します。

   kubectl exec -n <OIGNS> -ti <OIG_DOMAIN_NAME>-adminserver -- mkdir -p SHARED_CONFIG_DIR/keystores

   たとえば:

   kubectl exec -n oigns -ti governancedomain-adminserver -- mkdir -p /u01/oracle/user_projects/keystores

2. ロード・バランサから証明書を取得します。ロード・バランサの証明書は、Firefoxなどのブラウザを使用して取得できます。ただし、証明書を取得する最も簡単な方法は、opensslコマンドを使用します。コマンドの構文は、次のとおりです。

   openssl s_client -connect LOADBALANCER -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM>LOADBALANCER.pem

   たとえば:

   openssl s_client -connect login.example.com:443 -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM >login.example.com.pem

   opensslコマンドにより、証明書が SHARED_CONFIG_DIR/keystoresのlogin.example.com.pemというファイルに保存されます。

3. 次のコマンドを使用して、Kubernetesに証明書をコピーします:

   kubectl cp <FILENAME> <NAMESPACE>/<DOMAIN_NAME>-adminserver:<SHARED_CONFIG_DIR>/keystores

   たとえば:

   kubectl cp login.example.com.pem oigns/$domain_name-adminserver:/u01/oracle/user_projects/keystores/login.example.com.pem

4. WLSTを使用して、証明書をOracleキーストア・サービスにロードします。
   1. コマンドを使用して、コンテナに接続します:

      kubectl exec -n oigns -ti governancedomain-adminserver -- /bin/bash

   2. 次のコマンドを使用して、WLSTに接続します:

      ORACLE_HOME/oracle_common/common/bin/wlst.sh

   3. 次のコマンドを使用して管理サーバーに接続します。

      connect('<OAM_WEBLOGIC_USER>','<OAM_WEBLOGIC_PWD>','t3://<OAM_DOMAIN_NAME>-adminserver.<OIGNS>.svc.cluster.local:30012')

      たとえば:

      connect('weblogic','<password>','t3://governancedomain-adminserver.oigns.svc.cluster.local:7101')

   4. 次のコマンドを使用して、証明書をロードします:

      svc = getOpssService(name='KeyStoreService')
      svc.importKeyStoreCertificate(appStripe='system',name='trust',password='', keypassword='',alias='<CertificateName>',type='TrustedCertificate', filepath='/<SHARED_CONFIG_DIR>/keystores/<LOADBALANCER>.pem')

   5. 次のコマンドを使用して、キーストア・サービスとファイル・システムを同期します:

      syncKeyStores(appStripe='system', keystoreFormat='KSS')

      たとえば:

      connect('weblogic','password','t3://governancedomain-adminserver.oigns.svc.cluster.local:7101')
      svc = getOpssService(name='KeyStoreService')
      svc.importKeyStoreCertificate(appStripe='system',name='trust',password='', keypassword='',alias='login.example.com',type='TrustedCertificate', filepath='/u01/oracle/user_projects/keystores/login.example.com.pem')
      syncKeyStores(appStripe='system',keystoreFormat='KSS')
      exit()

変更を有効にするには、ドメインを再起動する必要があります。ノード・マネージャ・キーストアのデフォルト・パスワードは、COMMON_IAM_PASSWORDです。証明書が有効であることを確認するよう求められます。

初期サーバー数の設定

最初にドメインを作成したときに、1つの管理対象サーバーのみを起動するように指定しました。この値によって、OIGブートストラップ・プロセスが正常に完了したことが保証されます。構成を完了したら、初期サーバー数を必要な実際の数まで増やすことができます。

ドメインが作成されると、domain.yamlおよびdomain_oim_soa.yamlという2つのファイルも作成されます。これらのファイルを使用して、Kubernetesでドメインを初期化しました。初期構成およびブートストラップ・プロセスを完了すると、domain.yamlファイルを使用する必要がなくなります。domain_oim_soa.yamlファイルにより、必要なサーバーが起動されます。

残りのサーバーを起動して、非常に多くのサーバーが今後も継続して起動されるようにするには、domainファイルを更新する必要があります。サーバー数を増やすには、次のコマンドを使用します:

kubectl patch cluster -n <OIGNS> <OIG_DOMAIN_NAME>-${CLUSTER_NAME} --type=merge -p '{"spec":{"replicas":<INITIAL_SERVER_COUNT>}}'

2つのSOAおよび2つのOIM管理対象サーバーが必要な場合は、次のコマンドを使用します:

kubectl patch cluster -n oigns governancedomain-soa-cluster --type=merge -p '{"spec":{"replicas":2}}'

kubectl patch cluster -n oigns governancedomain-oim-cluster --type=merge -p '{"spec":{"replicas":2}}'

チャレンジ質問の設定

OAMとOIMを統合した場合、環境の準備が整ったら、システム・ユーザーのチャレンジ質問を設定する必要があります。

チャレンジ質問を設定するには、URL: https://prov.example.com/identityを使用してアイデンティティ・セルフ・サービスにログインします。

ユーザー名を使用してログインし、プロンプトが表示されたら、チャレンジ質問を追加します。次のユーザーにこれらの質問を設定する必要があります:

• xelsysadm
• weblogic_iam
• oamadmin

Oracle Identity ManagerとOracle Business Intelligence Publisherとの統合

Oracle Identity Managerでは、Oracle Identiy and Access Managementに関する情報を提供するために、いくつかの事前作成されたレポートを使用できます。

Oracle Identity Managerレポートは、アクセス・ポリシー・レポート、リクエストおよび承認レポート、パスワード・レポートなどの機能領域に基づいて分類されます。「操作レポート」や「履歴レポート」という名前は使用しなくなりました。これらのレポートは、Oracle Identity ManagerではなくOracle Business Intelligence Publisher (BIP)で生成されます。Oracle Identity Managerレポートには、Oracle BI Publisherに関する制約があります。

Oracle BI Publisherの高可用性エンタープライズ・デプロイメントのセットアップについては、このドキュメントでは説明していません。詳細は、『Business Intelligenceエンタープライズ・デプロイメント・ガイド』の「Business Intelligenceエンタープライズ・デプロイメント・トポロジの理解」を参照してください。

ノート:

Oracle Identity Manager用にBIを構成する際は、Business Intelligence Publisherのみを構成する必要があります。BI Publisherの構成時にBusiness Intelligence Enterprise EditionやEssbaseなど他のコンポーネントを選択した場合は、Oracle Identity Managerとの統合が機能しないことがあります。『Oracle Identity Governanceのためのアプリケーションの開発とカスタマイズ』のレポートの構成に関する項を参照してください

• BIレポートを実行するユーザーの作成
  
• BI Publisherを使用するOracle Identity Managerの構成
  
• BIServiceAdministratorロールのidm_reportへの割当て
  
• Oracle Identity GovernanceのBI資格証明の格納
  
• BIPでのOIMおよびBPELデータ・ソースの作成
  
• Oracle Identity GovernanceレポートのBIへのデプロイ
  
• 証明レポートの有効化
  
• レポートの検証
  
• Oracleキーストア信頼サービスへのBusiness Intelligenceロード・バランサ証明書の追加
  
• IAMGovernanceDomainの再起動
  変更を有効にするには、ドメインを再起動する必要があります。

BIレポートを実行するユーザーの作成

Business Intelligenceドメインでレポートを実行するためのユーザーがすでに存在する場合、この項は無視できます。

BI Publisherドメインでレポートを実行するユーザーを作成する必要がある場合は、次のLDIFコマンドを使用してLDAPディレクトリにユーザーを作成します。

1. 次の内容を含む/workdir/OIG/report_user.ldifというファイルを作成します:

   dn: cn=idm_report,cn=Users,dc=example,dc=com
   changetype: add
   orclsamaccountname: idm_report
   givenname: idm_report
   sn: idm_report
   userpassword: <password>
   mail: idm_report
   objectclass: top
   objectclass: person
   objectclass: organizationalPerson
   objectclass: inetorgperson
   objectclass: orcluser
   objectclass: orcluserV2
   uid: idm_report
   cn: idm_report

2. ファイルを保存します。
3. 次のコマンドを使用して、ファイルをLDAPディレクトリにロードします:

   ldapmodify -D cn=oudadmin -h idstore.example.com -p 1389 report_user.ldif

BI Publisherを使用するOracle Identity Managerの構成

Oracle BI PublisherをセットアップしてOracle Identity Managerレポートを生成できます。

BI Publisherを使用するようにOracle Identity Managerを構成するには:

1. URLを使用して、Oracle Enterprise Manager Fusion Middleware Controlにログインします。:
   http://igdadmin.example.com/em
2. 「WebLogicドメイン」をクリックして、「システムMBeanブラウザ」を選択します。
3. XMLConfig.DiscoveryConfigを検索基準として入力し、「検索」をクリックします。
   XMLConfig.DiscoveryConfig MBeanが表示されます。
4. 「検出構成BI Publisher URL」の値をBIP URLに更新します。たとえば、http://bi.example.comなどです
5. 「適用」をクリックします。

BIServiceAdministratorロールのidm_reportへの割当て

LDAPをBusiness Intelligence (BI)ドメインのアイデンティティ・ストアとして使用している場合は、BIドメインでLDAPオーセンティケータを作成しておく必要があります。LDAP内に格納されているユーザー名とグループ名を表示できます。

レポートを生成するには、Oracle Identity Manager (OIM)システム管理アカウント(idm_reportなど)をBIServiceAdministratorロールに割り当てる必要があります。

このロールを割り当てるには:

1. 次のURLを使用してBI Publisher WebLogicコンソールにログインし、OIM管理者ユーザーがドメインから参照できることを確認します:

   http://biadmin.example.com/console

2. 「セキュリティ・レルム」をクリックし、myrealmをクリックします。
3. 「ユーザーとグループ」タブに移動します。
4. ユーザー・リストを参照し、OIM管理ユーザー(idm_report)がそのユーザー・リストに含まれていることを確認します。
5. URL http://biadmin.example.com/emおよび管理者のアカウントを使用して、BI Fusion Middleware Controlにサインインします。たとえば、weblogic_biです。
6. 「WebLogicドメイン」メニューから、「セキュリティ」→「アプリケーション・ロール」を選択します。
7. 「アプリケーション・ストライプ」ドロップダウン・リストから、「obi」を選択します。
8. ロール名テキスト・ボックスの隣にある三角形のアイコンをクリックし、obiアプリケーション・ストライプのロール名をすべて検索します。
9. 編集するBIServiceAdministratorロールの行を選択します。
10. アプリケーション・ロールの「編集」アイコンをクリックして、ロールを編集します。
11. 「アプリケーション・ロールの編集」ページで、アプリケーション・ロールの「追加」アイコンをクリックします。
12. 「プリンシパルの追加」ダイアログ・ボックスで、「タイプ」ドロップダウン・メニューから「ユーザー」を選択します。
13. idm_reportユーザーを検索するには、「プリンシパル名」の「次で始まる」フィールドにユーザー名idm_reportを入力し、右矢印をクリックして検索を開始します。
14. 検索結果で適切なユーザーを選択し、「OK」をクリックします。
15. 「アプリケーション・ロールの編集」ページで、「OK」をクリックします。

Oracle Identity GovernanceのBI資格証明の格納

Oracle Identity ManagerでBIPの資格証明を構成するには:

1. URLを使用して、Oracle Enterprise Managerにログインします
   http://igdadmin.example.com/em
2. 左側のペインで、「WebLogicドメイン」を展開します。ドメイン名が表示されます。
3. ドメイン名を右クリックし、「セキュリティ」→「資格証明」に移動します。oimマップなど、資格証明ストアにおけるマップのリストが表示されます。
4. oimマップを開きます。Passwordタイプのエントリのリストが表示されます。
5. BIPWSKeyキーを編集するか(すでに存在する場合)、次の値を使用して新しいキーを作成します:

   表19-7 新規CSFエントリのプロパティ

   属性	値
   マップの選択	oim
   キー	BIPWSKey
   タイプ	パスワード
   ユーザー名	idm_report
   パスワード	idm_reportのパスワード
   説明	BI Publisher webサービスのログイン資格証明

BIPでのOIMおよびBPELデータ・ソースの作成

OIMデータソースの作成

レポートを実行するには、Oracle BIPをOIMおよびSOAデータベース・スキーマに接続する必要があります。

そのためには、次の手順でBIPデータソースを作成する必要があります。

1. URL https://bi.example.com/xmlpserverを使用して、BI Publisherホーム・ページにログインします

2. BI Publisherのホーム・ページの上部にある「管理」リンクをクリックします。 BI Publisherの「管理」ページが表示されます。

3. 「データ・ソース」で、「JDBC接続」リンクをクリックします。「Data Sources」ページが表示されています。

4. 「JDBC」タブで、「データソースの追加」をクリックして、データベースへのJDBC接続を作成します。 「データソースの追加」ページが表示されます。

5. 次のフィールドに値を入力します。

   表19-8 OIM追加データ・ソース属性

   属性	値
   データソース名	Oracle Identity Governance JDBC接続名を指定します。たとえば、OIM JDBCです。
   ドライバ・タイプ	11gデータベースの場合はOracle 11gを選択し、12cデータベースの場合はOracle 12cを選択します
   データベース・ドライバ・クラス	データベースに適したドライバ・クラス(oracle.jdbc.OracleDriverなど)を指定します
   接続文字列	データベース接続の詳細を、 jdbc:oracle:thin:@HOST_NAME:PORT_NUMBER/SIDの形式で指定します。 たとえば、jdbc:oracle:thin:@igddbscan:1521/oim.example.comです
   ユーザー名	Oracle Identity Governanceのデータベース・ユーザー名を指定します。たとえば、IGD_OIMです
   パスワード	Oracle Identity Governanceのデータベース・ユーザーのパスワードを指定します。

6. 「接続テスト」をクリックして接続を確認します。

7. 「適用」をクリックして接続を確立します。

8. データベースへの接続が確立されると、成功を示す確認メッセージが表示されます。

9. 「適用」をクリックします。

「JDBC」ページのJDBCデータソースのリストに、新しく定義されたOracle Identity Governance JDBC接続が表示されます。

BPELデータソースの作成

1. URL https://bi.example.com/xmlpserverを使用して、BI Publisherホーム・ページにログインします。

2. BI Publisherホーム・ページの「管理」リンクをクリックします。BI Publisherの「管理」ページが表示されます。

3. 「データ・ソース」で、「JDBC接続」リンクをクリックします。 「Data Sources」ページが表示されています。

4. 「JDBC」タブで、「データソースの追加」をクリックして、データベースへのJDBC接続を作成します。 「データソースの追加」ページが表示されます。

5. 次のフィールドに値を入力します。

   表19-9 JDBC追加データソース属性

   属性	値
   データソース名	Oracle Identity Governance JDBC接続名を指定します。たとえば、BPEL JDBCです。
   ドライバ・タイプ	Oracle 12c
   データベース・ドライバ・クラス	データベースに適したドライバ・クラス(oracle.jdbc.OracleDriverなど)を指定します
   接続文字列	データベース接続の詳細を、 jdbc:oracle:thin:@HOST_NAME:PORT_NUMBER/SIDの形式で指定します。 たとえば、jdbc:oracle:thin:@igddbscan:1521/oim.example.comです
   ユーザー名	Oracle Identity Governanceのデータベース・ユーザー名を指定します。たとえば、IGD_SOAINFRAです。
   パスワード	Oracle Identity Governanceのデータベース・ユーザーのパスワードを指定します。

6. 「接続テスト」をクリックして接続を確認します。

7. 「適用」をクリックして接続を確立します。

8. データベースへの接続が確立されると、成功を示す確認メッセージが表示されます。

9. 「適用」をクリックします。

「JDBC」ページのJDBCデータソースのリストに、新しく定義されたOracle Identity Governance JDBC接続が表示されます。

Oracle Identity GovernanceレポートのBIへのデプロイ

BI PublisherをOracle Identity Governanceと統合した後、それらの使用に関する事前定義済レポートをデプロイできます。Oracle Identity Managerレポートをデプロイするには:

1. OIMHOST1ファイルにある事前定義済レポート/u01/oracle/idm/server/reports/oim_product_BIPReports_12c.zipを、ディレクトリShared_Storage_location/biconfig/bidataにコピーし、解凍します。

   ノート:

   Shared_Storage_Locationが、ASERVER_HOME/config/fmwconfig/bienv/core/bi-environment.xmlファイルに定義されています。
2. 事前定義済のOracle Identity Governanceレポートを表示して実行できるように、フォルダ・レベルの権限をBIServiceAdministrator BIアプリケーション・ロールに追加します。これを行うには:

   • WebLogic管理資格証明を使用して、Oracle BI Publisher https://bi.example.com/xmlpserverにログインします。

   • 右上の「カタログ」リンクをクリックします。共有フォルダの下にあるOracle Identity Managerという名前のフォルダが左側のペインに表示されます。 Oracle Identity Managerという名前のフォルダを選択します。

   • 「タスク」ウィンドウで左下の「権限」オプションをクリックします。

   • プラス記号をクリックし、使用可能なロールで空白検索を実行します。

   • BIサービス管理者ロールを選択して、右側のパネルに追加します。

   • 「OK」をクリックします。

3. WebLogicユーザーとしてログアウトします。
4. Oracle Identity Managerシステム管理者ユーザーとしてBI Publisherコンソールにログインします。
5. Oracle Identity Managerレポートを実行します。

証明レポートの有効化

「証明レポートの有効化」オプションを選択または選択を解除して、証明レポートを有効または無効にします。証明レポートの生成を有効にするには、BI Publisher資格証明およびURLの構成後に次を実行します。

1. URL: https://prov.example.com/identityを使用してOracle Identity Self Serviceにログインします。
2. 「コンプライアンス」タブをクリックします。
3. 「アイデンティティの証明」ボックスをクリックします。
4. 「証明構成」を選択します。 「証明構成」ページが表示されます。
5. 「証明レポートの有効化」を選択します。
6. 「保存」をクリックします。

ノート:

デフォルトでは、「コンプライアンス」タブは表示されません。コンプライアンス機能を有効にする場合は、最初にSysadminコンソールでOIGIsIdentityAuditorEnabledプロパティをtrueに設定する必要があります(「構成プロパティ」セクションにあります)。

レポートの検証

サンプル・データソースに関するレポートを生成するには、そのサンプル・データ・ソースを作成する必要があります。

サンプル・レポートの作成

本番JDBCデータ・ソースに対してレポートを実行せずにレポート・データの例を表示するには、サンプル・データ・ソースに対してサンプル・レポートを生成します。サンプル・レポートを生成するには、まずサンプル・データ・ソースを作成します。

• サンプル・データ・ソースに対するレポートの生成
  
• Oracle Identity Manager JDBCデータソースに対するレポートの生成
  
• BPELベースのJDBCデータソースに対するレポートの生成
  

サンプル・データ・ソースに対するレポートの生成

サンプル・データ・ソースを作成したら、次のステップを実行してサンプル・レポートを生成できます:

1. URL: https://bi.example.com/xmlpserverを使用して、Oracle BI Publisherにログインします。
2. 「共有フォルダ」をクリックします。
3. Oracle Identity Managerレポートをクリックします。
4. 「サンプル・レポート」を選択します。
5. 生成するサンプル・レポートについて「表示」をクリックします。
6. サンプル・レポートの出力フォーマットを選択して「表示」をクリックします。

サンプル・レポートが生成されます。

Oracle Identity Manager JDBCデータソースに対するレポートの生成

OIM JDBCデータソースに対してレポートを生成するには、Oracle BI PublisherにログインしてOracle Identity Managerレポートに移動し、生成するレポートの出力形式を選択します。

Oracle Identity Manager JDBCデータソースに対してレポートを生成するには:

1. URL: https://bi.example.com/xmlpserverを使用して、Oracle BI Publisherにログインします。
2. Oracle Identity Managerレポートに移動します。これを行うには:

   • BI Publisherホーム・ページの「参照/管理」で、「カタログ・フォルダ」をクリックします。 または、ページの上部で「カタログ」をクリックすることもできます。

     「カタログ」ページでは、ページの左側にはツリー構造が、右側には詳細が表示されます。

   • 左側のペインで「共有フォルダ」を展開し、Oracle Identity Managerに移動します。 Oracle Identity Managerフォルダのすべてのオブジェクトが表示されます。

     BI Publisher 12cに移動して、Oracle Identity Manager BI Publisherレポートを使用できます。

3. 生成するレポートの下で「表示」をクリックします。
4. レポートの出力フォーマットを選択して「表示」をクリックします。

レポートが生成されます。

BPELベースのJDBCデータソースに対するレポートの生成

一部のレポートには、セカンダリ・データ・ソース(BPELベースのJDBCデータソース)があります。この項では、BPELベースのJDBCデータソースに対してレポートを生成する方法について説明します。

セカンダリ・データソースを使用したレポート

次の4つのレポートには、BPELデータベースに接続してBPELデータを取得するセカンダリ・データソースがあります。

• タスク割当て履歴

• リクエストの詳細

• リクエスト・サマリー

• 承認アクティビティ

これらのレポートには、BPEL JDBC (BPELベースのJDBCデータ・ソース)と呼ばれるセカンダリ・データ・ソースがあります。BPELベースのJDBCデータソースに対してレポートを生成するには:

1. URL: https://bi.example.com/xmlpserverを使用して、Oracle BI Publisherにログインします。
2. Oracle Identity Managerレポートに移動します。これを行うには:

   • BI Publisherホーム・ページの「参照/管理」で、「カタログ・フォルダ」をクリックします。 または、ページの上部で「カタログ」をクリックすることもできます。

     「カタログ」ページでは、ページの左側にはツリー構造が、右側には詳細が表示されます。

   • 左側のペインで「共有フォルダ」を展開し、Oracle Identity Managerに移動します。Oracle Identity Managerフォルダのすべてのオブジェクトが表示されます。

     BI Publisher 12cに移動して、Oracle Identity Manager BI Publisherレポートを使用します。

3. 生成するレポートを選択して、「オープン」をクリックします。
4. レポートの出力フォーマットを選択して「適用」をクリックします。

BPELベースのJDBCデータソースに基づいてレポートが生成されます。

Oracleキーストア信頼サービスへのBusiness Intelligenceロード・バランサ証明書の追加

セルフ・サービス・アプリケーション内部のOracle Identity GovernanceからBusiness Intelligenceレポートへのリンクでは、ロード・バランサによって使用されるSSL証明書をOracleキーストア・サービスの信頼できる証明書に追加する必要があります。

証明書を追加するには:

1. ユーザーが作成したキーストアと証明書を格納するディレクトリを作成します。

   kubectl exec -n <OIGNS> -ti <OIG_DOMAIN_NAME>-adminserver -- mkdir -p SHARED_CONFIG_DIR/keystores

   たとえば:

   kubectl exec -n oigns -ti governancedomain-adminserver -- mkdir -p /u01/oracle/user_projects/keystores

2. ロード・バランサから証明書を取得します。ロード・バランサの証明書は、Firefoxなどのブラウザを使用して取得できます。ただし、証明書を取得する最も簡単な方法は、opensslコマンドを使用します。コマンドの構文は、次のとおりです。

   openssl s_client -connect LOADBALANCER -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM>LOADBALANCER.pem

   たとえば:

   openssl s_client -connect bi.example.com:443 -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM>bi.example.com.pem

   opensslコマンドは、証明書をSHARED_CONFIG_DIR/keystoresにあるbi.example.com.pemという名前のファイルに保存します。

3. 次のコマンドを使用して、Kubernetesに証明書をコピーします:

   kubectl cp <FILENAME> <OIGNS>/<OIG_DOMAIN_NAME>-adminserver:<SHARED_CONFIG_DIR>/keystores

   たとえば:

   kubectl cp bi.example.com.pem oigns/$governancedomain-adminserver:/u01/oracle/user_projects/keystores/bi.example.com.pem

4. WLSTを使用して、証明書をOracleキーストア・サービスにロードします。
   1. 次のコマンドを使用して、WLSTに接続します:

      /u01/oracle/oracle_common/common/bin/wlst.sh

   2. 次のコマンドを使用して管理サーバーに接続します。

      connect('<AdminUser>','<AdminPwd>','t3://<Adminserverhost>:<Adminserver port>')

      たとえば:

      connect('weblogic','<password>','t3://governancedomain-adminserver.oigns.svc.cluster.local:7101')

   3. 次のコマンドを使用して、証明書をロードします:

      svc = getOpssService(name='KeyStoreService')
      svc.importKeyStoreCertificate(appStripe='system',name='trust',password='', keypassword='',alias='<CertificateName>',type='TrustedCertificate', filepath='/<SHARED_CONFIG_DIR>/keystores/<LOADBALANCER>.pem')

   4. 次のコマンドを使用して、キーストア・サービスとファイル・システムを同期します:

      syncKeyStores(appStripe='system', keystoreFormat='KSS')

      たとえば:

      connect('weblogic','password','t3://governancedomain-adminserver.oigns.svc.cluster.local:7101')
      svc = getOpssService(name='KeyStoreService')
      svc.importKeyStoreCertificate(appStripe='system',name='trust',password='', keypassword='',alias='bi.example.com',type='TrustedCertificate', filepath='/u01/oracle/user_projects/keystores/bi.example.com.pem')
      syncKeyStores(appStripe='system',keystoreFormat='KSS')
      exit()

変更を有効にするには、ドメインを再起動する必要があります。JDKのデフォルトのパスワードはchangeitです。ノード・マネージャ・キーストアのデフォルト・パスワードは、COMMON_IAM_PASSWORDです。証明書が有効であることを確認するよう求められます。

IAMGovernanceDomainの再起動

変更を有効にするには、ドメインを再起動する必要があります。

次のコマンドを使用して再起動できます:

kubectl -n <OIGNS> patch domains <OIG_DOMAIN_NAME> --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "NEVER" }]'

すべて停止したら、次のコマンドを使用して再起動できます:

kubectl -n <OIGNS> patch domains <OIG_DOMAIN_NAME> --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "IF_NEEDED" }]'

たとえば:

kubectl -n oigns patch domains governancedomain --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "NEVER" }]'
kubectl -n oigns patch domains governancedomain --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "IF_NEEDED" }]'

Design Consoleアクセスの有効化

インストール環境の一部としてインストールされているDesign Consoleには、アクセスできません。これはコンテナ内にあり、外部のX Window環境にアクセスする必要があるためです。

Design Consoleを使用する場合は、スタンドアロン・インストールを作成して、デプロイメントを指定する必要があります。

Design Consoleは、T3プロトコルを使用してOIGと対話します。このプロトコルは、デフォルトでは有効になっていません。

Design Consoleへのアクセスを有効にするには:

1. イングレスまたはNodePortを使用して、OIMサーバーのT3ポートを公開します。
2. WebLogic Server内のT3チャネルを更新して、名前付きKubernetesワーカー・ノードへのリクエストを許可します。
3. Javaスイッチを追加して、T3ポートへの外部アクセスを許可します。

次の各項では、Javaスイッチを追加するステップについて説明します。

• T3ポートを公開するためのイングレス・サービスの作成
  
• T3ポートを公開するためのNodePortサービスの作成
  
• T3チャネルの更新
  
• domain_oim_soa.yamlファイルへのJavaプロパティの追加
  
• Design ConsoleからのOIGデプロイメントへのアクセス
  

T3ポートを公開するためのイングレス・サービスの作成

T3チャネルは、デプロイメントの一環としてすでに作成されています。イングレスを使用してこのT3ポートを公開するには:

1. 次の内容を含むdesign-console-ingress.yamlというファイルを作業ディレクトリに作成します:

   # Load balancer type. Supported values are: NGINX
   type: NGINX
   # Type of Configuration Supported Values are : NONSSL,SSL
   # tls: NONSSL
   tls: NONSSL
   # TLS secret name if the mode is SSL
   secretName: dc-tls-cert
   
   # WLS domain as backend to the load balancer
   wlsDomain:
     domainUID: governancedomain
     oimClusterName: oim_cluster
     oimServerT3Port: 14002

2. 次のコマンドを使用して、イングレスを作成します:

   cd $WORKDIR/sample

   helm install oig-designconsole-ingress kubernetes/design-console-ingress --namespace oigns --values $WORKDIR/design-console-ingress.yaml

3. 次のコマンドを使用して、イングレスが作成されたことを確認します:

   kubectl get ingress -n oigns

T3ポートを公開するためのNodePortサービスの作成

T3チャネルは、デプロイメントの一環としてすでに作成されています。T3チャネルと対話するには、NodePortサービスを作成する必要があります。

ノート:

T3は、特定の時間にクラスタ内の1つの管理対象サーバー/ポッドからのみ公開されます。

1. 次の内容を含む/workdir/OIG/oim_t3_nodeport.yamlファイルを作成します:

   kind: Service
   apiVersion: v1
   metadata:
     name: <OIG_DOMAIN_NAME>-oim-t3-nodeport
     namespace: <OIGNS>
   spec:
     type: NodePort
     selector:
       weblogic.clusterName: oim_cluster
       weblogic.domainUID: <OIG_DOMAIN_NAME>
       weblogic.serverName: oim_server1
     ports:
       - targetPort: 14002
         port: 14002
         nodePort: <OIG_OIM_T3_PORT_K8>
         protocol: TCP
     sessionAffinity: ClientIP

   たとえば:

   kind: Service
   apiVersion: v1
   metadata:
     name: governancedomain-oim-t3-nodeport
     namespace: oigns
   spec:
     type: NodePort
     selector:
       weblogic.clusterName: oim_cluster
       weblogic.domainUID: governancedomain
       weblogic.serverName: oim_server1
     ports:
       - targetPort: 14002
         port: 14002
         nodePort: 30142
         protocol: TCP
     sessionAffinity: ClientIP

2. コマンドを使用して、サービスを作成します:

   kubectl apply -f /workdir/OIG/oim_t3_nodeport.yaml

   次のコマンドを使用して、サービスが正常に作成されたことを確認できます:

   kubectl get service -n <OIGNS>

   たとえば:

   kubectl get service -n oigns

   出力が次のように表示されます。

   service/governancedomain-oim-t3-nodeport created 

T3チャネルの更新

NodePortサービスを作成したら、それにWebLogic Serverをバインドする必要があります。

サービスをバインドするには:

1. http://igdadmin.example.com/console URLを使用してWebLogicコンソールにログインします。
2. 「環境」に移動して「サーバー」をクリックし、「oim_server1」を選択します。
3. 「プロトコル」をクリックし、「チャネル」をクリックします。
4. 「T3Channel」というデフォルトのT3チャネルをクリックします。
5. 「ロックして編集」をクリックします。
6. 「外部リスニング・アドレス」を、Kubernetesワーカー・ノードの1つに設定します。たとえば: K8WORKER1.example.com。
7. 「外部リスニング・ポート」を、前に定義したKubernetesサービス・ポートに設定します。「T3ポートを公開するためのNodePortサービスの作成」を参照してください。たとえば: 30142。
8. 「保存」をクリックします。
9. 「変更の適用」をクリックします。

domain_oim_soa.yamlファイルへのJavaプロパティの追加

Javaプロパティを追加するには:

1. WebLogic Kubernetes Operatorディレクトリ内にあるdomain_oim_soa.yamlドメイン・ファイルを編集します。例: /workdir/OIG/samples/create-oim-domain/domain-home-on-pv/output/weblogic-domains/<OIG_DOMAIN_NAME>。
2. - clusterName: oim_clusterという行で始まるセクションを見つけます。
3. このセクションで、プロパティ-Dweblogic.rjvm.allowUnknownHost=trueをUSER_MEM_ARGS値に追加します。たとえば: 編集後のファイルは次のようになります:

   - clusterName: oim_cluster
       serverService:
         precreateService: true
       serverStartState: "RUNNING"
       serverPod:
         # Instructs Kubernetes scheduler to prefer nodes for new cluster members where there are not
         # already members of the same cluster.
         affinity:
           podAntiAffinity:
             preferredDuringSchedulingIgnoredDuringExecution:
               - weight: 100
                 podAffinityTerm:
                   labelSelector:
                     matchExpressions:
                       - key: "weblogic.clusterName"
                         operator: In
                         values:
                           - $(CLUSTER_NAME)
                   topologyKey: "kubernetes.io/hostname"
         env:
         - name: USER_MEM_ARGS
           value: "-Djava.security.egd=file:/dev/./urandom -Xms4096m -Xmx8192m -Dweblogic.rjvm.allowUnknownHost=true"
       replicas: 2

4. ファイルを保存します。
5. 次のコマンドを使用して、変更を適用します:

   kubectl apply -f domain_oim_soa.yaml

6. 変更を有効にするには、ドメインを再起動します。

Design ConsoleからのOIGデプロイメントへのアクセス

Design Consoleのスタンドアロン・デプロイメントを実行したら、次のURLを使用してコンソールにアクセスできます:

http://K8WORKER1.example.com:30142/

ノート:

WebLogicチャネルを使用しているため、通常のT3プロトコルではなくhttpプロトコルが使用されます。

GrafanaとPrometheusによる集中管理型の監視

集中管理型のPrometheusおよびGrafanaデプロイメントを使用してインフラストラクチャを監視している場合は、このアプリケーションにOracle Identity Governanceのデータを送信できます。PrometheusおよびGrafanaをまだデプロイしていない場合は、「PrometheusおよびGrafanaのインストール」を参照してください。

集中型のPrometheusおよびGrafanaを使用してインフラストラクチャを監視するには、次のステップを実行します:

• 監視アプリケーションのダウンロードとコンパイル
  
• WebLogicドメインへの監視アプリケーションのデプロイ
  
• Prometheusオペレータの構成
  
• Prometheusサービスの検出
  

監視アプリケーションのダウンロードとコンパイル

Oracle Identity Governanceクラスタの監視アプリケーションをダウンロードして構成するには:

1. 監視の設定を行うサンプル・スクリプトにディレクトリを変更します:

   cd <WORKDIR>/samples/monitoring-service/scripts

   たとえば:

   cd /workdir/OAM/samples/monitoring-service/scripts

2. get-wls-exporter.shスクリプトを実行します。

   スクリプトを実行する前に、環境設定を決定する環境変数を設定します:

   export adminServerPort=<OIG_ADMIN_PORT>

   export wlsMonitoringExporterTosoaCluster=true

   export soaManagedServerPort=8001

   export wlsMonitoringExporterTooimCluster=true

   export oimManagedServerPort=14100

   export domainNamespace=<OIGNS>

   export domainUID=<OIG_DOMAIN_NAME>

   export weblogicCredentialsSecretName=<OIG_DOMAIN_NAME>-credentials

   たとえば:

   export adminServerPort=7101

   export wlsMonitoringExporterTosoaCluster=true

   export soaManagedServerPort=8001

   export wlsMonitoringExporterTooimCluster=true

   export oimManagedServerPort=14100

   export domainNamespace=oigns

   export domainUID=governancedomain

   export weblogicCredentialsSecretName=governancedomain-credentials

   次のコマンドを使用して、スクリプトを実行します。

   ./get-wls-exporter.sh

   出力が次のように表示されます。

     
   % Total    % Received % Xferd   Average Speed   Time    Time       Time  Current
                                   Dload   Upload  Total   Spent      Left  Speed
     0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
   100 2196k  100 2196k    0     0  1138k      0  0:00:01  0:00:01 --:--:-- 6365k
   created /home/opc/workdir/OIG/samples/monitoring-service/scripts/wls-exporter-deploy dir
   adminServerName is empty, setting to default "AdminServer"
   soaClusterName is empty, setting to default "soa_cluster"
   oimClusterName is empty, setting to default "oim_cluster"
   created /tmp/ci-rsqE8LWMAw
   /tmp/ci-rsqE8LWMAw ~/workdir/OIG/samples/monitoring-service/scripts
   in temp dir
     adding: WEB-INF/weblogic.xml (deflated 61%)
     adding: config.yml (deflated 60%)
   ~/workdir/OIG/samples/monitoring-service/scripts
   created /tmp/ci-xD6iyUUBut
   /tmp/ci-xD6iyUUBut ~/workdir/OIG/samples/monitoring-service/scripts
   in temp dir
     adding: WEB-INF/weblogic.xml (deflated 61%)
     adding: config.yml (deflated 60%)
   ~/workdir/OIG/samples/monitoring-service/scripts
   created /tmp/ci-l0Caci13DM
   /tmp/ci-l0Caci13DM ~/workdir/OIG/samples/monitoring-service/scripts
   in temp dir
     adding: WEB-INF/weblogic.xml (deflated 61%)
     adding: config.yml (deflated 60%)
   ~/workdir/OIG/samples/monitoring-service/scripts

WebLogicドメインへの監視アプリケーションのデプロイ

前の項では、監視アプリケーションを含むWARファイルを多数作成しました。「監視アプリケーションのダウンロードとコンパイル」を参照してください。これらのファイルは、WebLogicドメインにデプロイする必要があります。オラクル社では、このファイルをデプロイするスクリプトを用意しています。スクリプトを実行する前に、WebLogic管理サーバーが含まれるコンテナにファイルをコピーしてください。

アプリケーションを配置するには:

1. ディレクトリをサンプル・ファイルの場所に変更します:

   cd <WORKDIR>/samples/monitoring-service/scripts

   たとえば:

   cd /workdir/OIG/samples/monitoring-service/scripts

2. 次のコマンドを使用して、ファイルを管理サーバー・コンテナにコピーします:

   kubectl cp <WORKDIR>/samples/monitoring-service/scripts/wls-exporter-deploy  <OIGNS>/<OIG_DOMAIN_NAME>-adminserver:/u01/oracle

   kubectl cp <WORKDIR>/samples/monitoring-service/scripts/deploy-weblogic-monitoring-exporter.py  <OIGNS>/<OIG_DOMAIN_NAME>-adminserver:/u01/oracle/wls-exporter-deploy

   たとえば:

   kubectl cp /workdir/OIG/samples/monitoring-service/scripts/wls-exporter-deploy  oigns/governancedomain -adminserver:/u01/oracle

   kubectl cp /workdir/OIG/samples/monitoring-service/scripts/deploy-weblogic-monitoring-exporter.py  oigns/governancedomain-adminserver:/u01/oracle/wls-exporter-deploy

3. 次のコマンドを使用して、アプリケーションをデプロイします:

   kubectl exec -it -n <OIGNS> <OIG_DOMAIN_NAME>-adminserver -- /u01/oracle/oracle_common/common/bin/wlst.sh \
   -domainName <OIG_DOMAIN_NAME> \
   -adminServerName AdminServer \
   -adminURL <OIG_DOMAIN_NAME>-adminserver:<OIG_ADMIN_PORT> \
   -username <OIG_WEBLOGIC_USER> \
   -password <OIG_WEBLOGIC_PWD> \
   -oimClusterName oim_cluster \
   -wlsMonitoringExporterTooimCluster true \
   -soaClusterName soa_cluster \
   -wlsMonitoringExporterTosoaCluster true

   たとえば:

   kubectl exec -it -n oigns governancedomain-adminserver -- /u01/oracle/oracle_common/common/bin/wlst.sh \
   -domainName governancedomain \
   -adminServerName AdminServer \
   -adminURL accessdomain-adminserver:7101 \
   -username weblogic \
   -password MyPassword \
   -oimClusterName oim_cluster \
   -wlsMonitoringExporterTooimCluster true \
   -soaClusterName soa_cluster \
   -wlsMonitoringExporterTosoaCluster true

   出力が次のように表示されます。

   Initializing WebLogic Scripting Tool (WLST) ...
   
   Welcome to WebLogic Server Administration Scripting Shell
   
   Type help() for help on available commands
   
   Connecting to t3://governancedomain-adminserver:7101 with userid weblogic ...
   Successfully connected to Admin Server "AdminServer" that belongs to domain "governancedomain".
   
   Warning: An insecure protocol was used to connect to the server.
   To ensure on-the-wire security, the SSL port or Admin port should be used instead.
   
   Deploying .........
   Deploying application from /u01/oracle/wls-exporter-deploy/wls-exporter-adminserver.war to targets AdminServer (upload=true) ...
   <Aug 22, 2022 10:52:21 AM GMT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating deploy operation for application, wls-exporter-adminserver [archive: /u01/oracle/wls-exporter-deploy/wls-exporter-adminserver.war], to AdminServer .>
   .Completed the deployment of Application with status completed
   Current Status of your Deployment:
   Deployment command type: deploy
   Deployment State : completed
   Deployment Message : no message
   Starting application wls-exporter-adminserver.
   <Aug 22, 2022 10:52:29 AM GMT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating start operation for application, wls-exporter-adminserver [archive: null], to AdminServer .>
   .Completed the start of Application with status completed
   Current Status of your Deployment:
   Deployment command type: start
   Deployment State : completed
   Deployment Message : no message
   Deploying .........
   Deploying application from /u01/oracle/wls-exporter-deploy/wls-exporter-soa.war to targets soa_cluster (upload=true) ...
   <Aug 22, 2022 10:52:32 AM GMT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating deploy operation for application, wls-exporter-soa [archive: /u01/oracle/wls-exporter-deploy/wls-exporter-soa.war], to soa_cluster .>
   ..Completed the deployment of Application with status completed
   Current Status of your Deployment:
   Deployment command type: deploy
   Deployment State : completed
   Deployment Message : no message
   Starting application wls-exporter-soa.
   <Aug 22, 2022 10:52:42 AM GMT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating start operation for application, wls-exporter-soa [archive: null], to soa_cluster .>
   .Completed the start of Application with status completed
   Current Status of your Deployment:
   Deployment command type: start
   Deployment State : completed
   Deployment Message : no message
   Deploying .........
   Deploying application from /u01/oracle/wls-exporter-deploy/wls-exporter-oim.war to targets oim_cluster (upload=true) ...
   <Aug 22, 2022 10:52:45 AM GMT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating deploy operation for application, wls-exporter-oim [archive: /u01/oracle/wls-exporter-deploy/wls-exporter-oim.war], to oim_cluster .>
   .Completed the deployment of Application with status completed
   Current Status of your Deployment:
   Deployment command type: deploy
   Deployment State : completed
   Deployment Message : no message
   Starting application wls-exporter-oim.
   <Aug 22, 2022 10:52:52 AM GMT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating start operation for application, wls-exporter-oim [archive: null], to oim_cluster .>
   .Completed the start of Application with status completed
   Current Status of your Deployment:
   Deployment command type: start
   Deployment State : completed
   Deployment Message : no message
   Disconnected from weblogic server: AdminServer
   
   
   Exiting WebLogic Scripting Tool.
   
   <Aug 22, 2022 10:52:55 AM GMT> <Warning> <JNDI> <BEA-050001> <WLContext.close() was called in a different thread than the one in which it was created.>

Prometheusオペレータの構成

Prometheusを使用すると、WebLogic Monitoring Exporterからメトリックを収集できます。Prometheusオペレータは、サービス検出を使用してターゲットを識別します。WebLogic Monitoring Exporterのエンド・ポイントをターゲットとして検出するには、サービスを指すサービス・モニターを作成する必要があります。

wls-exporterからメトリックをエクスポートするには、basicAuthが必要です。そのため、base64でエンコードしたユーザー名とパスワードを使用して、Kubernetesシークレットを作成します。このシークレットは、ServiceMonitorデプロイメントで使用されます。wls-exporter-ServiceMonitor.yamlファイルにはbasicAuthが指定されており、資格証明のユーザー名は<OIG_WEBLOGIC_USER>、パスワードは<OIG_WEBLOGIC_PWD>で、base64でエンコードされています。

1. 次のコマンドを実行し、base64でエンコードしたバージョンのweblogicユーザー名を取得します:

   echo -n "weblogic” | base64

   出力が次のように表示されます。

   d2VibG9naWM=

2. 次のコマンドを実行し、base64でエンコードしたバージョンのweblogicパスワードを取得します:

   echo -n "<OIG_WEBLOGIC_PWD>" | base64

   出力が次のように表示されます。

   V2VsY29tZTE=

3. テンプレート・ファイル<WORKDIR>/samples/monitoring-service/manifests/wls-exporter-ServiceMonitor.yaml.templateを<WORKDIR>/samples/monitoring-service/manifests/wls-exporter-ServiceMonitor.yamlにコピーします。
4. <WORKDIR>/samples/monitoring-service/manifests/wls-exporter-ServiceMonitor.yamlの場所を更新し、userおよびpasswordの値をステップ2で返された値に変更します。
   また、次の値を変更して、OAMネームスペース、ドメイン名およびPrometheusリリース名と一致させます。たとえば:

   • namespace: oigns
   • weblogic.domainName: governancedomain
   • release: kube-prometheus
     リリース名は、次のコマンドで取得できます:

     kubectl get prometheuses.monitoring.coreos.com --all-namespaces -o jsonpath="{.items[*].spec.serviceMonitorSelector}"

   たとえば:

   apiVersion: v1
   kind: Secret
   metadata:
     name: basic-auth
     namespace: oigns
   data:
     password: V2VsY29tZTE=
     user: d2VibG9naWM=
   type: Opaque
   ---
   apiVersion: monitoring.coreos.com/v1
   kind: ServiceMonitor
   metadata:
     name: wls-exporter
     namespace: oigns
     labels:
       k8s-app: wls-exporter
       release: monitoring
   spec:
     namespaceSelector:
       matchNames:
       - oigns
     selector:
       matchLabels:
         weblogic.domainName: governancedomain
     endpoints:
     - basicAuth:
         password:
           name: basic-auth
           key: password
         username:
           name: basic-auth
           key: user
       port: default
       relabelings:
         - action: labelmap
           regex: __meta_kubernetes_service_label_(.+)
       interval: 10s
       honorLabels: true
       path: /wls-exporter/metrics

5. <WORKDIR>/samples/monitoring-service/manifests/prometheus-roleSpecific-domain-namespace.yamlと<WORKDIR>/samples/monitoring-service/manifests/prometheus-roleBinding-domain-namespace.yamlファイルを更新し、OIGネームスペースと一致するようにネームスペースを変更します。たとえば:

   prometheus-roleSpecific-domain-namespace.yaml

    apiVersion: rbac.authorization.k8s.io/v1
   items:
   - apiVersion: rbac.authorization.k8s.io/v1
     kind: Role
     metadata:
       name: prometheus-k8s
       namespace: oigns
     rules:
     - apiGroups:
       - ""
       resources:
       - services
       - endpoints
       - pods
       verbs:
       - get
       - list
       - watch
   kind: RoleList

   prometheus-roleBinding-domain-namespace.yaml

   apiVersion: rbac.authorization.k8s.io/v1
   items:
   - apiVersion: rbac.authorization.k8s.io/v1
     kind: RoleBinding
     metadata:
       name: prometheus-k8s
       namespace: oigns
     roleRef:
       apiGroup: rbac.authorization.k8s.io
       kind: Role
       name: prometheus-k8s
     subjects:
     - kind: ServiceAccount
       name: prometheus-k8s
       namespace: monitoring
   kind: RoleBindingList

6. 次のコマンドを実行して、Prometheusを有効にします:

   kubectl apply -f

   出力が次のように表示されます。

   rolebinding.rbac.authorization.k8s.io/prometheus-k8s created
   role.rbac.authorization.k8s.io/prometheus-k8s created
   secret/basic-auth created
   servicemonitor.monitoring.coreos.com/wls-exporter created

Prometheusサービスの検出

ServiceMonitorをデプロイすると、Prometheusによりwls-exporterが検出され、メトリックを収集できるようになります。

1. 次のURLにアクセスし、Prometheusサービス検出を表示します:

   http://<K8_WORKER1>:32101/service-discovery

2. <OIGNS>/wls-exporter/0をクリックし、「さらに表示」をクリックします。すべてのターゲットがリストされていることを確認します。

ElasticsearchおよびKibanaを使用した集中管理型のログ・ファイル監視

ElasticsearchとKibanaを使用している場合は、集中管理型のElasticearch/Kibanaコンソールにログ・ファイルを送信するようLogstashポッドを構成できます。Logstashポッドを構成する前に、集中管理型のElasticsearchデプロイメントにアクセスできることを確認してください。

• OIG永続ボリューム(Logstashポッドによってロードされ、ログ・ファイルの検索が可能になります)。
• 永続ボリューム内のログ・ファイルの場所。
• 集中管理型のElasticsearchの場所。

Logstashポッドを構成するには、次のステップを実行します。Kubernetesクラスタ内のelknsというネームスペースで、Elasticsearchが実行されていることを前提としています。

• Elasticsearchのシークレットの作成
  
• ELK証明書の構成マップの作成
  
• Logstashの構成マップの作成
  
• Logstashデプロイメントの作成
  

Elasticsearchのシークレットの作成

Logstashでは、Elasticsearchデプロイメントに接続するための資格証明が必要です。これらの資格証明は、シークレットとしてKubernetesに格納されます。

Elasticsearchで認証にAPIキーを使用する場合は、次のコマンドを使用します:

kubectl create secret generic elasticsearch-pw-elastic -n <OIGNS> --from-literal password=<ELK_APIKEY>

たとえば:

kubectl create secret generic elasticsearch-pw-elastic -n oigns --from-literal password=afshfashfkahf5f

Elasticsearchで認証にユーザー名とパスワードを使用する場合は、次のコマンドを使用します:

kubectl create secret generic elasticsearch-pw-elastic -n <OIGNS> --from-literal password=<ELK_PWD>

たとえば:

kubectl create secret generic elasticsearch-pw-elastic -n oigns --from-literal password=mypassword

Elasticsearchパスワードを見つけるには、次のコマンドを使用します:

kubectl get secret elasticsearch-es-elastic-user -n <ELKNS> -o go-template='{{.data.elastic | base64decode}}'

ELK証明書の構成マップの作成

本番環境に対応したElasticsearchデプロイメントを構成した場合は、SSLが構成されています。Elasticsearchと通信できるよう、LogstashでElasticsearch証明書を信頼する必要があります。信頼を有効にするには、Elasticsearch証明書の内容で、構成マップを作成する必要があります。

Elasticsearchの自己署名証明書は、すでに保存されています。「Elasticsearch証明書のコピー」を参照してください。本番証明書がある場合は、かわりにそれを使用できます。

1. 証明書を使用して構成マップを作成し、次のコマンドを実行します:

   kubectl create configmap elk-cert --from-file=<WORKDIR>/ELK/elk.crt -n <OIGNS>

   たとえば:

   kubectl create configmap elk-cert --from-file=/workdir/ELK/elk.crt -n oigns

Logstashの構成マップの作成

Logstashは、OAMインストールのログ・ファイルを検索し、集中管理型のElasticsearchに送信します。ログ・ファイルが存在する場所とその送信先は、構成マップを使用してLogstashに指示されます。

1. <WORKDIR>/OIG/logstash_cm.yamlというファイルを、次の内容で作成します:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: oig-logstash-configmap
     namespace: <OIGNS>
   data:
     logstash.yaml: |
     #http.host: "0.0.0.0"
     logstash-config.conf: |
       input {
         file {
           path => "/u01/oracle/user_projects/domains/logs/governancedomain/AdminServer*.log"
           tags => "Adminserver_log"
           start_position => beginning
         }
         file {
           path => "/u01/oracle/user_projects/domains/logs/governancedomain/soa_server*.log"
           tags => "soaserver_log"
           start_position => beginning
         }
         file {
           path => "/u01/oracle/user_projects/domains/logs/governancedomain/oim_server*.log"
           tags => "Oimserver_log"
           start_position => beginning
         }
         file {
           path => "/u01/oracle/user_projects/domains/governancedomain/servers/AdminServer/logs/AdminServer-diagnostic.log"
           tags => "Adminserver_diagnostic"
           start_position => beginning
         }
         file {
           path => "/u01/oracle/user_projects/domains/governancedomain/servers/**/logs/soa_server*-diagnostic.log"
           tags => "Soa_diagnostic"
           start_position => beginning
         }
         file {
           path => "/u01/oracle/user_projects/domains/governancedomain/servers/**/logs/oim_server*-diagnostic.log"
           tags => "Oimserver_diagnostic"
           start_position => beginning
         }
         file {
           path => "/u01/oracle/user_projects/domains/governancedomain/servers/**/logs/access*.log"
           tags => "Access_logs"
           start_position => beginning
         }
       }
       filter {
         grok {
           match => [ "message", "<%{DATA:log_timestamp}> <%{WORD:log_level}> <%{WORD:thread}> <%{HOSTNAME:hostname}> <%{HOSTNAME:servername}> <%{DATA:timer}> <<%{DATA:kernel}>> <> <%{DATA:uuid}> <%{NUMBER:timestamp}> <%{DATA:misc}> <%{DATA:log_number}> <%{DATA:log_message}>" ]
         }
       if "_grokparsefailure" in [tags] {
           mutate {
               remove_tag => [ "_grokparsefailure" ]
           }
       }
       }
       output {
         elasticsearch {
           hosts => ["<ELK_HOST>"]
           cacert => '/usr/share/logstash/config/certs/elk.crt'
           index => "oiglogs-000001"
           ssl => true
           ssl_certificate_verification => false
           user => "<ELK_USER>"
           index => "oiglogs-000001"
           password => "${ELASTICSEARCH_PASSWORD}"
         }
       }

2. ファイルを保存します。
3. 次のコマンドを使用して、構成マップを作成します:

   kubectl create -f <WORKDIR>/OIG/logstash_cm.yaml

   たとえば:

   kubectl create -f /workdir/OIG/logstash_cm.yaml

4. 次のコマンドを使用して、構成マップが作成されたことを確認します:

   kubectl get cm -n <OIGNS>

   構成マップのリストにoig-logstash-configmapが表示されます。

Logstashデプロイメントの作成

構成マップを作成したら、Logstashデプロイメントを作成できます。このデプロイメントは、OAMネームスペースに存在します。

1. 次のコマンドを使用して、OIG永続ボリュームのマウント・ポイントを確認します:

   kubectl describe domains <OIG_DOMAIN_NAME> -n <OIGNS> | grep "Mount Path"

   たとえば:

   kubectl describe domains governancedomain -n oigns | grep "Mount Path"

   この値をノートにとります。次のステップで作成するファイルに必要になります。

2. <WORKDIR>/OIG/logstash.yamlというファイルを、次の内容で作成します:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: oig-logstash
     namespace: <OIGNS>
   spec:
     selector:
       matchLabels:
         k8s-app: logstash
     template: # create pods using pod definition in this template
       metadata:
         labels:
           k8s-app: logstash
       spec:
         imagePullSecrets:
         - name: dockercred
         containers:
         - command:
           - logstash
           image: logstash:<ELK_VER>
           imagePullPolicy: IfNotPresent
           name: oig-logstash
           env:
           - name: ELASTICSEARCH_PASSWORD
             valueFrom:
               secretKeyRef:
                 name: elasticsearch-pw-elastic
                 key: password
           ports:
           - containerPort: 5044
             name: logstash
           volumeMounts:
           - mountPath: <MOUNT_PATH>
             name: weblogic-domain-storage-volume
           - name: shared-logs
             mountPath: /shared-logs
           - mountPath: /usr/share/logstash/pipeline/
             name: oig-logstash-pipeline
           - mountPath: /usr/share/logstash/config/certs
             name: elk-cert
         volumes:
         - configMap:
             defaultMode: 420
             items:
             - key: logstash-config.conf
               path: logstash-config.conf
             name: oig-logstash-configmap
           name: oig-logstash-pipeline
         - configMap:
             defaultMode: 420
             items:
             - key: ca.crt
               path: elk.crt
             name: elk-cert
         - name: weblogic-domain-storage-volume
           persistentVolumeClaim:
             claimName: <OIG_DOMAIN_NAME>-domain-pvc
         - name: shared-logs
           emptyDir: {}

   ノート:

   独自のレジストリを使用している場合は、レジストリ名をイメージ・タグに含めます。レジストリのregcredシークレットを作成した場合は、imagePullSecretsの名前を、作成したシークレット名に置き換えます。例: regcred。
3. ファイルを保存します。
4. 次のコマンドを使用して、Logstashデプロイメントを作成します:

   kubectl create -f <WORKDIR>/OIG/logstash.yaml

   たとえば:

   kubectl create -f /workdir/OIG/logstash.yaml

5. 次のコマンドを使用して、logstashというポッドを作成できます:

   kubectl get pod -n oigns

   これで、Kibanaコンソールでログを使用できるようになります。

構成のバックアップ

ベスト・プラクティスとして、ドメインを正常に拡張した後や別の論理ポイントで構成をバックアップすることをお薦めします。必ずここまでのインストールが成功していることを確認してからバックアップしてください。これは、後のステップで問題が発生した場合に即座にリストアを実行できるクイック・バックアップです。

Kubernetes環境では、永続ボリュームとデータベースをバックアップすれば十分です。

バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

構成をバックアップする方法の詳細は、「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。

コンテナからのOIMバルクロード・ユーティリティの実行

コンテナからoimbulkloadユーティリティを実行する場合は、JDKおよびoimbulkloadユーティリティもインストールされているOracle Database Instant Clientに基づいて新しいコンテナ・イメージを作成します。

開始する前に、Java Development Kit RPMイメージをダウンロードする必要があります。

この項には次のトピックが含まれます:

• 作業ディレクトリの作成
  
• JDKリリース8の取得
  
• コンテナ内のwlfullclient jarファイルのコンパイル
  
• OIGコンテナからのバルクロード・ディレクトリのコピー
  
• Dockerfileの作成
  
• 作業ディレクトリの確認
  
• イメージの構築
  
• イメージの起動
  

作業ディレクトリの作成

イメージの構築に必要なすべてのオブジェクトを格納する作業ディレクトリを作成します。

たとえば:

mkdir -p /workdir/bulkload

JDKリリース8の取得

JDKリリース8のコピーを取得するには:

1. Java SE 8アーカイブ・ダウンロード・ページから、java JDKリリース8用のRPMをダウンロードします。
2. ダウンロードしたJDKを作業ディレクトリ/workdir/bulkloadにコピーします。

コンテナ内のwlfullclient jarファイルのコンパイル

oimbulkloadユーティリティは、wlfullclient.jarファイルに依存します。次のコマンドを使用して、このファイルをOIG管理サーバー・イメージ内に生成する必要があります:

kubectl exec -it -n <OIGNS> <OIG_DOMAIN_NAME>-adminserver -- bash -c 'cd /u01/oracle/wlserver/server/lib ; java -jar wljarbuilder.jar'

たとえば:

kubectl exec -it -n oigns governancedomain-adminserver -- bash -c 'cd /u01/oracle/wlserver/server/lib ; java -jar wljarbuilder.jar'

このコマンドによって、wlfullclient.jarというファイルがイメージ内に作成されます。

ノート:

このファイルは、管理サーバー・ポッドが再起動されるまで存在します。バルク・ロード・イメージの作成後は不要になります。

OIGコンテナからのバルクロード・ディレクトリのコピー

oimbulkloadユーティリティは、Oracleコンテナ・イメージ内の多数のファイルで構成されます。次のコマンドを使用して、作業ディレクトリ内のu01というサブディレクトリにこれらのファイルをコピーする必要があります:

export MW_HOME=/u01/oracle

kubectl exec -it -n oigns governancedomain-adminserver -- bash -c 'cd /u01/oracle/wlserver/server/lib ; java -jar wljarbuilder.jar'
kubectl cp oigns/governancedomain-adminserver:/u01/oracle/idm/server/db/oim/oracle/Utilities/oimbulkload u01/oracle/idm/server/db/oim/oracle/Utilities/oimbulkload
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/oracle_common/modules/javax.management.j2ee.jar u01/oracle/oracle_common/modules/javax.management.j2ee.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/wlserver/modules/com.bea.core.diagnostics.flightrecorder.jar u01/oracle/wlserver/modules/com.bea.core.diagnostics.flightrecorder.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/wlserver/modules/com.oracle.weblogic.rjvm.jar u01/oracle/wlserver/modules/com.oracle.weblogic.rjvm.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/wlserver/modules/com.oracle.weblogic.security.crypto.utils.jar u01/oracle/wlserver/modules/com.oracle.weblogic.security.crypto.utils.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/oracle_common/modules/clients/com.oracle.webservices.wls.jaxws-owsm-client.jar u01/oracle/oracle_common/modules/clients/com.oracle.webservices.wls.jaxws-owsm-client.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/idm/server/idmdf/idmdf-common.jar u01/oracle/idm/server/idmdf/idmdf-common.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/idm/server/idmdf/event-recording-client.jar u01/oracle/idm/server/idmdf/event-recording-client.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/oracle_common/modules/thirdparty/spring-context-5.1.3.RELEASE.jar u01/oracle/oracle_common/modules/thirdparty/spring-context-5.1.3.RELEASE.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/idm/server/client/oimclient.jar u01/oracle/idm/server/client/oimclient.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/oracle_common/modules/oracle.jrf/jrf-api.jar u01/oracle/oracle_common/modules/oracle.jrf/jrf-api.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/oracle_common/modules/org.apache.commons.logging_1.2.jar u01/oracle/oracle_common/modules/org.apache.commons.logging_1.2.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/wlserver/server/lib/wlthint3client.jar u01/oracle/wlserver/server/lib/wlthint3client.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/wlserver/server/lib/wlfullclient.jar u01/oracle/wlserver/server/lib/wlfullclient.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/idm/server/apps/oim.ear/APP-INF/lib/OIMServer.jar u01/oracle/idm/server/apps/oim.ear/APP-INF/lib/OIMServer.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/idm/server/apps/oim.ear/APP-INF/lib/iam-platform-utils.jar u01/oracle/idm/server/apps/oim.ear/APP-INF/lib/iam-platform-utils.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/idm/server/config u01/oracle/idm/server/config
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/oracle_common/modules/thirdparty/spring-core-5.1.3.RELEASE.jar u01/oracle/oracle_common/modules/thirdparty/spring-core-5.1.3.RELEASE.jar
chmod +x u01/oracle/idm/server/db/oim/oracle/Utilities/oimbulkload/scripts/*.sh

ノート:

設計上、u01の前に'/'はありません。

Dockerfileの作成

Dockerfileは、イメージの構築方法を決定するために使用されます。イメージの構築にDockerかPodmanのどちらを使用しているかに関係なく、このファイルは作業ディレクトリにあります。このコンテンツは次のとおりです。

FROM  ghcr.io/oracle/oraclelinux7-instantclient:21

ADD /jdk-8u202-linux-x64.rpm /jdk-8u202-linux-x64.rpm
RUN yum install -y https://yum.oracle.com/repo/OracleLinux/OL7/oracle/instantclient21/x86_64/getPackage/oracle-instantclient-{basic,tools,jdbc}-21.5.0.0.0-1.x86_64.rpm jdk-8u202-linux-x64.rpm tar
RUN mkdir -p /usr/lib/oracle/21/client64/rdbms /usr/lib/oracle/21/client64/jdbc
RUN cp -r /usr/lib/oracle/21/client64/lib /usr/lib/oracle/21/client64/jdbc

COPY u01 ./u01
ENV PATH=$PATH:/usr/lib/oracle/21/client64/bin
ENV JAVA_HOME=/usr
ENV MW_HOME=/u01/oracle
ENV OIM_ORACLE_HOME=/u01/oracle/idm
ENV ORACLE_HOME=/usr/lib/oracle/21/client64

ファイルを保存します。

作業ディレクトリの確認

このプロセスの終了時には、作業ディレクトリに次のファイルが存在します:

• jdk-8u202-linux-x64.rpm
• u01および各種サブディレクトリ
• Dockerfile

イメージの構築

イメージを構築するには:

1. 次のコマンドを使用します。

   podman build -t <REGISTRY>/database/bulkload:latest -f Dockerfile

   または

   docker build -t <REGISTRY>/database/bulkload:latest -f Dockerfile

   たとえば:

   podman build -t iad.ocir.io/mytenancy/database/bulkload:latest -f Dockerfile

   このコマンドは:

   • GitHubから最新のデータベース・インスタント・クライアント・コンテナをプルします。
   • インスタント・クライアント・ツールを使用してイメージを拡張します。
   • データベース・ホーム・ディレクトリのようになるように、コンテナの構造を変更します
   • JDKをインストールします。
   • oimbulkloadユーティリティとその依存関係をイメージにコピーします。
   • イメージ内のJAVA_HOME、MW_HOME、OIM_ORACLE_HOMEおよびORACLE_HOMEのデフォルト環境変数を設定します。
2. イメージを作成した後、次のコマンドを使用して、コンテナ・レジストリとタグ付けされたローカル・リポジトリ内のイメージを表示します:

   podman images

3. 必要に応じて、次のコマンドを使用して、イメージをコンテナ・レジストリにプッシュします:

   podman  push iad.ocir.io/mytenancy/database/bulkload:latest

イメージの起動

これで、Kubernetesでイメージを起動し、それを使用してバルク・ロード・アクティビティを実行できるようになりました。次のステップでは、イメージを起動し、csvファイルに対してNFSでマウントされたファイルシステムを使用する方法を示します。

• ポッド・ファイルの作成
  
• バルクロード・ポッドの起動
  
• バルクロード・ユーティリティの実行
  

ポッド・ファイルの作成

次の内容を含むbulkload.yamlというファイルを作成します:

apiVersion: v1
kind: Pod
metadata:
  name: bulkload
  namespace: <OIGNS>
  labels:
    app: dbclient
spec:
  restartPolicy: OnFailure
  volumes:
    - name: oigbulkpv
      nfs:
        server: <PVSERVER>
        path: <OID_BULK_SHARE>
  containers:
  - name: bulkload
    image: iad.ocir.io/mytenancy/database/bulkload:latest
    volumeMounts:
      - name: oigbulkpv
        mountPath: /u01/oracle/idm/server/db/oim/oracle/Utilities/oimbulkload/csv_files
    command: ["/bin/bash", "-ec", "while :; do echo '.'; sleep 5 ; done"]
  imagePullSecrets:
    - name: <REGISTRY_SECRET_NAME>

たとえば:

apiVersion: v1
kind: Pod
metadata:
  name: bulkload
  namespace: oigns
  labels:
    app: dbclient
spec:
  restartPolicy: OnFailure
  volumes:
    - name: oigbulkpv
      nfs:
        server: nfsserver.example.com
        path: /exports/IAMPVS/oigbulkpv
  containers:
  - name: bulkload
    iad.ocir.io/mytenancy/database/bulkload:latest
    volumeMounts:
      - name: oigbulkpv
        mountPath: /u01/oracle/idm/server/db/oim/oracle/Utilities/oimbulkload/csv_files
    command: ["/bin/bash", "-ec", "while :; do echo '.'; sleep 5 ; done"]
  imagePullSecrets:
    - name: regcred

バルクロード・ポッドの起動

次のコマンドを使用して、バルクロード・ポッドを起動できるようになりました:

kubectl create -f bulkload.yaml

ポッドが起動された場合、次のコマンドを使用すると、それがOIGネームスペースで実行されていることが示されます:

kubectl get pods -n oigns 

1. 最初のステップのテキストをここに入力します。
2. ステップ2のテキストをここに入力します。

バルクロード・ユーティリティの実行

oimbulkloadユーティリティを実行する前に、まず、次のコマンドを使用してコンテナに接続する必要があります:

kubectl exec -it -n <OIGNS> bulkload –- bash

たとえば:

kubectl exec -it -n oigns bulkload -- bash

バルク・ロード・ユーティリティは、/u01/oracle/idm/server/db/oim/oracle/Utilities/oimbulkload/にあります。

oimbulkloadユーティリティを起動するには、次のコマンドを使用します:

cd /u01/oracle/idm/server/db/oim/oracle/Utilities/oimbulkload/
./oim_blkld.sh

実行中に、使用しているロードのタイプに応じて特定の情報を指定するように要求されます。要求される可能性のある情報の一部の概要を次に示します:

• JAVA_HOME=/usr
• MW_HOME=/u01/oracle
• OIM_ORACLE_HOME=/u01/oracle/idm
• ORACLE_HOME=/usr/lib/oracle/21/client64
• ガバナンス・サーバーが実行されているホスト = governancedomain-cluster-oim-cluster.oigns. svc.cluster.local
• ガバナンス・サーバーが実行されているポート = 14000

oimbulkloadユーティリティの実行手順については、『Oracle Identity Governanceのためのアプリケーションの開発とカスタマイズ』のバルク・ロード・ユーティリティの使用に関する項を参照してください。