| Oracle® Fusion Middleware Oracle Identity Manager開発者ガイド 11g リリース1(11.1.1) B66705-01 |
|
 前 |
 次 |
職務の分離(SoD)の概念は、ビジネス・プロセスにチェック・アンド・バランスを適用することを目的としています。ビジネス・プロセスの各段階では、複数の個人の関与が必要になる場合があります。組織では、ユーザー・プロビジョニング・ソリューションの一部としてSoDを実装することにより、こうした状況をIT対応のビジネス・プロセスの要件に変換できます。SoDの全体的な利点は、組織のリソースが意図的または偶発的に悪用されることにより生じるリスクを軽減できる点です。この章には次の項が含まれます:
Oracle Identity Managerは、権限リクエストの検証および管理にも使用できるユーザー・プロビジョニング・ソリューションです。Oracle Identity ManagerのSoD実装では、ユーザーによるIT権限(権限)リクエストがSoDエンジンおよび他のユーザーによってチェックされ、承認されます。システムと人による複数レベルのチェックにより、たとえ元のリクエストに変更が加えられても、リクエストがクリアされる前に必ず入念に検査されるようにすることができます。この予防方法は、リクエストされた権限が割り当てられる前に、権限割当てで競合する可能性のあるものを特定し、修正するうえで役立ちます。
Oracle Identity ManagerでのSoD検証プロセスは、ユーザーが特定のターゲット・システムでの権限に対するリクエストを作成すると開始されます。リクエストはリソース承認ワークフローを通り、その初期ワークフローをパスした場合はプロビジョニング・ワークフローを通ります。
リソース承認ワークフローは、SoDエンジンによりリアルタイムでこのリクエストを検証するように構成できます。SoDエンジンでは、事前定義のルールを使用して、権限割当てがSoD違反につながるかどうかを確認します。この確認が行われた後、その結果がOracle Identity Managerに返されます。
リソース・プロビジョニング・ワークフローは、リソース承認ワークフローをパスした権限リクエストをターゲット・システムにプロビジョニングします。
ユーザーのリクエストがSoD検証にパスし、承認者がリクエストを承認した場合、リソース・プロビジョニング・ワークフローが開始されます。リクエストがSoD検証に失敗した場合、改善ステップが行われるようにリソース承認ワークフローを構成できます。
|
注意: SoDコンプライアンスを保証するために、権限割当てがターゲット・システムにプロビジョニングされる直前に、SoD検証を再実行するようにリソース・プロビジョニング・ワークフローを構成できます。 |
Oracle Identity Managerは、SoDエンジンとターゲット・システムの両方と通信します。また、ターゲット・システムとSoDエンジンは、権限データの同期化が有効になるように相互に通信します。図27-1に、SoD検証プロセスにおけるデータ・フローを示します。
SoD起動ライブラリ(SIL)は、Oracle Identity ManagerでのSoD実装の基礎となります。SILはJavaベースのアダプタの集合で、事前に定義されたOracle Identity Managerコネクタとの統合を可能にします。その結果、コネクタは、Oracle Identity Managerをターゲット・システムと結び付けます。次のOracle Identity Managerコネクタが、SoD検証用に事前にアダプタに構成されています。
SILは、SILとSoDエンジンを統合する専用アダプタの基礎の役割も果たします。これらのアダプタは、SILプロバイダと呼ばれます。SILプロバイダは、SILと特定のSoDエンジンとのインタフェースの機能を果たします。次のSoDエンジン用に事前に定義されたSILプロバイダがあります。
SAP GRC用SILプロバイダ
このプロバイダは、SAP GRC SILプロバイダとしても知られています。動作保証されたSAP GRCのバージョンは、バージョン5.2 SP4以上および5.3 SP5以上です。
Oracle Application Access Controls Governor(OAACG)リリース8.2.1以上用SILプロバイダ
このプロバイダは、OAACG SILプロバイダとしても知られています。
|
注意: Oracle Identity ManagerでSoDの実装および使用を開始する前に、OAACGの最新のパッチ・セットをインストールしてください。詳細は、Oracleサポートに連絡してください。 |
Oracle Identity Analytics(OIA)リリース11.1.1.3以上用SILプロバイダ
図27-2に、Oracle Identity ManagerでのSoD実装のアーキテクチャを示します。
Oracle Identity Managerコネクタは、必要に応じて、SAP GRC SILプロバイダ、OAACG SILプロバイダまたはOIA SILプロバイダのいずれとも構成できます。たとえば、PeopleSoft User ManagementコネクタとOAACG SILプロバイダを使用すれば、PeopleSoft Enterpriseアプリケーションで権限に対するリクエストのSoD検証を自動化できます。
カスタムSoDエンジン用SILプロバイダを作成し、事前に構成されたOracle Identity Managerコネクタ、またはSoD検証用に構成したOracle Identity Managerコネクタのいずれかとともに使用することもできます
次に示すSoD対応コネクタのインストール手順は、特定のコネクタのドキュメントを参照してください。Oracle Identity Managerコネクタのドキュメント・ページは、次のURLにあります。
http://download.oracle.com/docs/cd/E11223_01/index.htm
Oracle E-Business User Managementリリース9.1.0以上
SAP CUAリリース9.1.0以上
SAP User Managementリリース9.1.0以上
SIL登録は、デフォルトで、一部のターゲット・システムおよびSoDエンジンに対して提供されています。これらのターゲット・システムおよびSoDエンジンのデフォルトの組合せの場合は、デプロイメント・ステップは不要です。SIL登録が提供されているターゲット・システムには次のものがあります。
EBSおよびOAACG
PSFTおよびOAACG
SAPおよびSAP-GRC
OIA
OIA SoDエンジンは、他のターゲット・システムではなくOracle Identity Managerとの間でデータを同期化するため、OIAに対して登録されるトポロジは、Oracle Identity Managerで構成されている任意のコネクタで使用できます。OIAはOracle Identity Managerからすべてのデータをインポートします。したがって、OIAの視点からは、Oracle Identity Managerはターゲット・システムになります。
ターゲット・システムまたはSoDエンジンの他の組合せを使用する場合は、SIL登録プロセスを実行する必要があります。詳細は、第27.10項「ターゲット・システムおよびSoDエンジンのカスタムの組合せ」を参照してください。
ターゲット・システムからSoDエンジンに権限データをインポートする必要があります。必要に応じて、SoDエンジンでSoD検証ルールも構成します。次の各項では、事前に構成されたSoDエンジンに対するこれらの手順を説明します。
Oracle Application Access Controls Governor(OAACG)の構成には、次の手順が必要です。
Oracle Application Access Controls Governorのインストール
OAACG 8.6.xはOracle Identity Manager 11gリリース1(11.1.1.4)以上でサポートされています。OAACG 8.6.0.203が推奨されているバージョンであり、このバージョンがインストールされている必要があります。さらに、このバージョンをOAACG 8.6.0.219またはOAACG 8.6.0.240にアップグレードする必要があります。
OAACG 8.6.0.203をインストールするには、次の手順を実行します。
My Oracle Supportにログインします。
「パッチと更新版」タブをクリックします。
「拡張検索」をクリックします。
「製品ファミリ」で「Oracle Application Access Controls Governor」を選択し、リリースとしてAACG 8.6.0を選択します。適切なプラットフォームを選択し、「検索」をクリックします。
最新のパッチを選択します。Oracle Identity Manager Bundle Patch Readmeで、これが8.6.0.219または8.6.0.240であるかどうかを確認します。
|
注意: Oracle Identity Manager SoDは、OAACG 8.6.0.219およびOAACG 8.6.0.240で動作保証されています。 |
パッチまたは更新をダウンロードします。
OAACGアップグレード・ガイドを参照して、OAACGのアップグレードを実行します。
OAACG 8.6.0.203は、OAACG 8.6.0.219またはOAACG 8.6.0.240にアップグレードする必要があります。これを行うには、次の手順を実行します。
My Oracle Supportにログインします。
「パッチと更新版」タブをクリックします。
パッチIDを検索します。
パッチIDを選択します。
パッチまたは更新をダウンロードします。
OAACGアップグレード・ガイドを参照して、OAACGのアップグレードを実行します。
SoD処理用のOracle Application Access Controls Governorアカウントの作成
SoD検証処理用に基本タイプのアカウントを作成します。「SoDエンジンの情報を保持するためのITリソースの作成」で説明されている手順の実行中に、このアカウントのユーザー名およびパスワードを指定します。
アカウント作成の詳細は、Oracle Application Access Controls Governorのドキュメントを参照してください。
Oracle E-Business Suiteのロールおよび職責データのOracle Application Access Controls Governorへの同期化
Oracle E-Business Suiteからロールおよび職責データをOracle Application Access Controls Governorにインポート(同期化)する必要があります。最初の同期化の後、データの定期的同期化のスケジュールを設定する必要があります。
詳細は、Oracle Application Access Controls Governorのドキュメントを参照してください。
Oracle Application Access Controls Governorでのアクセス・ポリシーの定義
ロールおよび職責データのインポート後、Oracle Application Access Controls Governorでアクセス・ポリシーを設定します。これらのアクセス・ポリシーは、ロールおよび職責の様々な組合せに基づいています。
詳細は、Oracle Application Access Controls Governorのドキュメントを参照してください。
SAP GRCでは、SAP R/3のユーザー、ロールおよびプロファイル・データを使用して、アカウント、ロールおよび職責に対するリクエストを検証します。SAP GRCの構成には、次の手順が必要です。
SoD処理用のSAP GRCアカウントの作成
SoD処理用のSAP GRCアカウントを作成する必要があります。SoD処理中、SAP GRC Webサービスのコールにこのアカウントが使用されます。
このユーザー・アカウントの作成時に、アカウントを次のグループに割り当てる必要があります。
すべての人
認証済ユーザー
このアカウントにはロールを割り当てないでください。
キーストアの生成
キーストアを生成するには、次のようにします。
Webブラウザで、SAP GRC Access Controlの「Web Services Navigator」ページを開きます。URLは次のようなものです。
https://SAP_GRC_HOST:PORT_NUMBER/VirsaCCRiskAnalysisService/Config1?wsdl
証明書をエクスポートします。
証明書をSAP GRCのJDKインストール・ディレクトリ内のbinディレクトリにコピーします。
次のコマンドを実行し、ダウンロードした証明書ファイルからキーストアを作成します。
keytool -import -v -trustcacerts -alias sapgrc -file CERTIFICATE_FILENAME -keystore sgil.keystore -keypass changeit -storepass changeit
|
注意: このサンプル・コマンドで、キーストア・ファイル名はsgil.keystoreです。 |
キーストアのパスワードを要求されたら、changeitを指定します。これは、デフォルトのキーストア・パスワードです。
証明書を信頼するかどうかの指定を要求されたら、yesを入力します。
sgil.keystoreファイルは、binディレクトリに作成されます。ファイルをOIM_HOME/configディレクトリにコピーします。
Risk Terminatorの構成
Risk Terminatorは、GRC Access Controlの機能です。これは、SAP GRCのSoD検証機能のメイン・コンポーネントです。ロールがプロファイル・ジェネレータで作成されたり、ユーザーに割り当てられたりすると、Risk Terminatorにより、このロールの作成または割当てがSoD違反になるかどうかが検証されます。
詳細は、Risk Terminator構成のドキュメントを参照してください。
SAP ERPのユーザー、ロールおよびプロファイル・データのSAP GRCへの同期化
ユーザー、ロールおよびプロファイル・データは、SAP ERPからSAP GRCにインポート(同期化)する必要があります。最初の同期化の後、データの定期的同期化のスケジュールを設定する必要があります。
SAP GRCでのリスク・ポリシーの定義
ロールおよび職責データのインポート後、SAP GRCのRisk Analysis and Remediation機能を使用して、職務の分離タイプのリスク・ポリシーを定義します。
詳細は、SAP GRCのドキュメントを参照してください。
Oracle Identity Analyticsの構成には、次の手順が必要です。
SoD処理用のOracle Identity Analyticsアカウントの作成
Oracle Identity Analyticsでアカウントを作成し、それをSoD検証処理用にSRM管理ロールに割り当てます。「SoDエンジンの情報を保持するためのITリソースの作成」で説明されている手順の実行中に、このアカウントのユーザー名およびパスワードを指定します。
アカウント作成の詳細は、Oracle Identity Analyticsのドキュメントを参照してください。
|
注意: ユーザー名が |
Oracle Identity ManagerメタデータのOracle Identity Analyticsとの同期化
Oracle Identity ManagerからOracle Identity Analyticsにリソース・メタデータおよびリソースをインポートします。
詳細は、Oracle Identity Analyticsのドキュメントを参照してください。
Oracle Identity AnalyticsでのID監査ポリシーの定義
Oracle Identity Analyticsを使用して、ID監査ルールおよびポリシーを設定します。ルールはリソースの属性に基づいて作成されます。権限SoDチェック時には、Oracle Identity Managerでのとおりに、エンコードされた値をロールおよび職責に指定します。
詳細は、Oracle Identity Analyticsのドキュメントを参照してください。
次の各項では、SoDの有効化および無効化について説明します。
SoD機能を有効にするには、次の手順を実行します。
XL.SoDCheckRequiredシステム・プロパティをtrueに設定します。システム・プロパティの詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のシステム・プロパティの管理に関する説明を参照してください。
コネクタITリソース・インスタンスのtopologyNameパラメータをSILConfig.xml内に存在する値に設定します。デフォルトのSIL登録を使用している場合は、コネクタITリソースのtopologyNameパラメータを次のいずれかに設定します。
sodoaacg: EBSコネクタと、SoDエンジンとしてOAACGを使用している場合
oaacgpsft: PSFTコネクタと、SoDエンジンとしてOAACGを使用している場合
sodgrc: SoDエンジンとしてGRCを使用している場合
sodoia: SoDエンジンとしてOIAを使用している場合
|
注意: すべてのユーザーがITリソース情報にアクセスできるように、コネクタITリソースにはALL USERSロールが付与されている必要があります。ユーザーが要求したSODリクエストにはこれが必要です。 |
SILおよびSILプロバイダのデプロイ
ターゲット・システムおよびSoDエンジンのデフォルトの組合せに対してSILおよびSILプロバイダをデプロイするには、次の手順を実行します。
Sodエンジンの新しいITリソースを次の名前(タイプ)で作成します。
EBS-OAACGの場合: OAACG-ITRes(eBusiness Suite OAACG)
SAP-GRCの場合: GRC-ITRes(SoDプロバイダ)
OIAの場合: OIA-ITRes(OIA)という名前のITリソースが事前に定義されています。
PSFT-OAACGの場合: PSFT-OAACG-ITRes(OAACG)という名前のITリソースが事前に定義されています。
「SoDエンジンの情報を保持するためのITリソースの作成」の説明に従って、作成したITリソースを編集します。
|
注意:
|
ダイレクト・プロビジョニングおよびアクセス・ポリシー・ベースのプロビジョニングでのSoDの有効化:
SoDは、HolderおよびSODCheckerタスクがプロビジョニング・ワークフロー内に存在する場合にのみ有効にできます。
リクエスト・プロビジョニングでのSoDの有効化:
手順1および2により承認中のデフォルトのSoDチェックが有効になります。デフォルトのSoDチェックは、承認される前に実行されます。1つの承認レベルの後でSoDチェックが必要になった場合、デフォルトのSoDチェック承認ワークフローであるDefaultSODApprovalが、承認ポリシーの作成によりアタッチされる必要があります。SoDチェックは、任意の承認ワークフローでオンデマンドで実行することもできます。これは、BPELからSoDチェックWebサービスをコールすることによって行うことができます。詳細は、「SoD用の承認ワークフローの変更」を参照してください。
|
注意: DefaultSODApprovalワークフローが承認の操作レベルにアタッチされている場合、システム管理者が最初に承認した後で、SoDチェックのみが実行されます。SoDチェックが実行された後、SoD管理者ロールによる承認が必要です。このワークフローに従って、システム管理者に割り当てられている最初の承認タスクが生成され、次にSoDチェックが実行されてから、承認タスクが生成されます。SoD管理者ロールのメンバーであればどのユーザーでも、SoDチェック結果を表示した後、2番目の承認タスクを承認できます。 |
SoDチェックのCSF資格証明の追加:
Enterprise Managerコンソールにログインし、左側のタブで「WebLogicドメイン」を開きます。
base_domainを開きます。
右側のペインの上部で、「WebLogicドメイン」リストから「セキュリティ」を選択し、「資格証明」を開きます。
「キーの作成」オプションを選択してから、マップ'oim'を選択します。
キーをsodcheck.credentialsとして指定し、「タイプ」を「パスワード」として指定します。
「ユーザー名」をoiminternalとして指定し、パスワードを「未使用」として指定します。「OK」をクリックして、キーを保存します。
SoDは次のいずれかを実行して無効にできます。
XL.SoDCheckRequiredシステム・プロパティをfalseに設定します。
コネクタITリソースのtopologyNameパラメータの値を削除し、その値が空白に設定されるようにします。ITリソースのtopologyNameパラメータがNoneに設定されていると、SoDチェックは実行されません。
ダイレクト・プロビジョニングおよびアクセス・ポリシー・ベースのプロビジョニングでのSoDの有効化
HolderおよびSODCheckerプロセス・タスクを無効にします。
|
関連項目: これらのプロセス・タスクの無効化の詳細は、コネクタのガイドを参照してください。 |
リクエスト・プロビジョニングでのSoDの無効化
承認中のデフォルトのSoDチェックを無効にするには、いずれかの手順を実行してSoDを無効にします。BPELで、承認中のデフォルトのSoDチェックを実行し、SoDチェックのみを無効にする場合は、SoDの承認ポリシーを削除するか、承認ワークフローからSoDチェックWebサービスのコールを削除します。
次の各項では、SoDの様々な用途のためのSecure Sockets Layer(SSL)通信の有効化について説明します。
Oracle Application Access Controls GovernorとOracle Identity Manager間のSSL通信を有効にするには、次の手順を実行します。
|
注意: 登録プロセス中にsslEnableを |
次のようにしてOracle Application Access Controls Governorホスト・コンピュータで証明書をエクスポートします。
|
注意: 手順1で、JAVA_HOMEはOracle Application Access Controls Governorホスト・コンピュータ上のディレクトリを示しています。 |
JAVA_HOME/binディレクトリから次のコマンドを実行します。
keytool -genkey -alias tomcat -keyalg RSA -keystore JAVA_HOME/lib/security/.keystore keytool -certreq -alias tomcat -file JAVA_HOME/lib/security/xell.cvs -keystore JAVA_HOME/lib/security/.keystore keytool -export -alias tomcat -file JAVA_HOME/lib/security/server.cert -keystore JAVA_HOME/lib/security/.keystore
これらのコマンドを実行した後、サーバー証明書(server.cert)がJAVA_HOME/lib/securityディレクトリ内に作成されます。
TOMCAT_HOME/conf/server.xmlファイルで、キーストアの詳細をConnector要素の属性として入力します。次の例を参照してください。
<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" keystoreFile="JAVA_HOME/lib/security/.keystore">
Oracle Application Access Controls Governorを再起動します。
次のようにしてOracle Identity Managerホスト・コンピュータに証明書をインポートします。
|
注意: 手順2で、JAVA_HOMEはOracle Identity Managerホスト・コンピュータ上のディレクトリを指しています。 |
Oracle Application Access Controls Governorホスト・コンピュータで作成されたサーバー証明書を、Oracle Identity Managerホスト・コンピュータのJAVA_HOME/lib/securityディレクトリにコピーします。
JAVA_HOME/binディレクトリから次のコマンドを実行します。
keytool -import -alias oaacg_trusted_cert -file JAVA_HOME/lib/security/server.cert -trustcacerts -keystore JAVA_HOME/lib/security/cacerts -storepass changeit
SAP GRCとOracle Identity Manager間のSSL通信を有効にするには、SAP GRCホスト・コンピュータで次のようにして証明書をエクスポートします。
|
注意: ここでは、JAVA_HOMEは、アプリケーション・サーバーの実行に使用されるOracle Identity Managerホスト・コンピュータ上のディレクトリを指しています。 |
Webブラウザで、SAP GRC Access Controlの「Web Services Navigator」ページを開きます。URLは次のようなものです。
https://mysapserver01:50001/VirsaCCRiskAnalysisService/Config1?wsdl
次の手順は、使用しているブラウザによって異なります。
Microsoft Internet Explorerの場合: 「セキュリティの警告」ダイアログ・ボックスで、「証明書の表示」をクリックします。ダイアログ・ボックスの「詳細」タブで「このファイルをコピーする」ボタンを使用して、証明書をエクスポートします。
Mozilla Firefoxの場合: 証明書を.pemファイルとしてエクスポートします。この手順を実行するには、Mozilla Webサイトから証明書ビューア拡張機能をダウンロードし、インストールすることが必要となる場合があります。
Oracle Identity Managerをホストするアプリケーション・サーバーによって使用されるJAVA_HOME/lib/securityディレクトリに、証明書をコピーします。
端末ウィンドウで、JAVA_HOME/binディレクトリに移動します。
次のコマンドを実行して、GRC証明書をcacertsにインポートします。
keytool -import -alias sapgrc_trusted_cert -file JAVA_HOME/lib/security/CERTIFICATE_FILENAME -trustcacerts -keystore JAVA_HOME/lib/security/cacerts -storepass changeit
このコマンドでは、次のように指定します。
CERTIFICATE_FILENAMEは、SAP GRCホスト・コンピュータからエクスポートした証明書の名前です。
-storepass changeit句は、cacertsキーストアのパスワードを指定します。
証明書を信頼するかどうかの指定を要求されたら、yesを入力します。
証明書がキーストアに追加されたことを示すメッセージが表示されます。
SOAでは、oim-config.xmlファイル内でoimFrontEndURLとして指定されているURL(Oracle Identity Manager UIへのアクセスに使用されるURL)経由で、Oracle Identity Manager Webサービスをコールします。デフォルトではこれはHTTP URLです。通信がSSL経由で行われるように、これをHTTPSに変更できます。Oracle Identity ManagerのSSLポートは、WebLogic管理コンソールで確認できます。
SSL経由でSoDチェックWebサービスをコールするには、次の手順を実行します。
Oracle Identity ManagerのSSLポートを特定します。これを行うには、次の手順を実行します。
WebLogic管理コンソールにログインします。
「サーバー」→「oim_server1」に移動します。「SSLリスニング・ポート」が有効になっています。
Enterprise ManagerのMBeanブラウザでoimFrontEndURLを変更します。これを行うには、次の手順を実行します。
Enterprise Managerにログインします。
「oim_server1」に移動します。
ペインの上部にあるリストから、システムMBeanブラウザを選択します。
アプリケーション定義のMBean→「oracle.iam」→「サーバー: oim_server1」→「アプリケーション: oim」→「XMLConfig」→「構成」→「XMLConfig.DiscoveryConfig」→「検出」に移動します。属性が右側に表示されます。
「oimFrontEndURL」をクリックし、値を次のように変更します。
https://HOST_NAME:SSL_PORT
|
注意: oimFrontEndURLの値は、Oracle Identity Managerのインストール時に設定することもできます。 |
Oracle Identity Managerを再起動します。
SoD対応リソースに対するリクエストを作成します。新しいワークフロー・インスタンスはEnterprise Managerで確認できます。SSLポートでWebサービスがコールされるようになります。
|
注意: Oracle Identity ManagerおよびSOAが同じJava Runtime Environment(JRE)で実行されているものと仮定します。SOAとOracle Identity Managerが異なるJREで実行されている場合、SSL通信を行うためにはWebLogic証明書の交換が必要になります。詳細は、次のURLを使用してOracle Technology Network(OTN)WebサイトにあるOracle WebLogic Server 10gリリース3(10.3)のドキュメントを参照してください。
|
この項で説明されている手順は、事前に構成されたSoD互換コネクタ(Oracle E-Business User Management、SAP User ManagementおよびSAP CUA)の1つを使用しない場合のみ実行してください。この項の内容は次のとおりです。
SoD用の承認ワークフローを変更するには、次の手順を実行します。
Oracle Identity Managerの以前のリリースのオブジェクト・フォームのかわりに、11gリリース1(11.1.1)でのリクエストの作成時に入力するデータが、リクエスト・データセットに入力されます。プロビジョニング対象のターゲット・システム・リソース用にリクエスト・データセットがまだ存在しない場合は、新しい親データセットおよび子データセットを作成し、MDSインポート・ユーティリティを使用してこれらをMDSにインポートします。
|
注意:
|
次に、eBusiness Suite User TCA Foundationリソースのサンプルのリクエスト・データセットを示します。使用されているリソースに適したリクエスト・データセットを作成してください。
<request-data-set xmlns="http://www.oracle.com/schema/oim/request"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.oracle.com/schema/oim/request"
name="eBusiness Suite User TCA Foundation" entity="eBusiness Suite User TCA Foundation" operation="PROVISION">
<!-- Parent form having fields -->
<AttributeReference name="Effective Date From" attr-ref="Effective Date From" type="Date" length="50" widget="date" required="true" available-in-bulk="true"/>
<AttributeReference name="SSO GUID" attr-ref="SSO GUID" type="String" length="256" widget="text" required="false" available-in-bulk="true"/>
<AttributeReference name="Last Name" attr-ref="Last Name" type="String" length="150" widget="text" required="false" available-in-bulk="true"/>
<AttributeReference name="EBS Server" attr-ref="EBS Server" type="String" length="50" widget="itresource-lookup" available-in-bulk="true" itresource-type="eBusiness Suite UM" required="true"/>
<AttributeReference name="Password Expiration Interval" attr-ref="Password Expiration Interval" type="Long" length="50" widget="text" required="false" available-in-bulk="true"/>
<AttributeReference name="Fax" attr-ref="Fax" type="String" length="80" widget="text" required="false" available-in-bulk="true"/>
<AttributeReference name="Password" attr-ref="Password" type="String" length="30" widget="text" masked="true" required="true" available-in-bulk="true"/>
<AttributeReference name="Effective Date To" attr-ref="Effective Date To" type="Date" widget="date" length="50" required="false" available-in-bulk="true"/>
<AttributeReference name="Description" attr-ref="Description" type="String" length="240" widget="text" required="false" available-in-bulk="true"/>
<AttributeReference name="Password Expiration Type" attr-ref="Password Expiration Type" type="String" length="30" widget="lookup" required="false" available-in-bulk="true" lookup-code="Lookup.EBS.PasswordExpirationType"/>
<AttributeReference name="SSO User ID" attr-ref="SSO User ID" type="String" length="256" widget="text" required="false" available-in-bulk="true"/>
<AttributeReference name="User Name" attr-ref="User Name" type="String" length="100" widget="text" required="true" available-in-bulk="true"/>
<AttributeReference name="First Name" attr-ref="First Name" type="String" length="150" widget="text" required="false" available-in-bulk="true"/>
<AttributeReference name="Party ID" attr-ref="Party ID" type="Long" widget="text" length="50" required="false" available-in-bulk="true"/>
<AttributeReference name="User ID" attr-ref="User ID" type="Long" widget="text" length="50" required="false" available-in-bulk="true"/>
<AttributeReference name="Email" attr-ref="Email" type="String" length="240" widget="text" required="false" available-in-bulk="true"/>
<!-- Child form EBS -->
<AttributeReference name="UD_EBST_RSP" attr-ref="UD_EBST_RSP" type="String" length="20" widget="text" available-in-bulk="true">
<AttributeReference name="Effective Start Date" attr-ref="Effective Start Date" type="Date" length="50" widget="date" required="false" available-in-bulk="true"/>
<AttributeReference name="Effective End Date" attr-ref="Effective End Date" type="Date" length="50" widget="date" required="false" available-in-bulk="true"/>
<AttributeReference name="Application Name" attr-ref="Application Name" type="String" length="256" widget="lookup" required="false" available-in-bulk="true" lookup-code="Lookup.EBS.Application"/>
<AttributeReference name="Responsibility Name" attr-ref="Responsibility Name" type="String" length="256" widget="lookup-query" available-in-bulk="true" required="true">
<lookupQuery lookup-query="select lkv_encoded as lkv_encoded,lkv_decoded as lkv_decoded from lkv lkv,lku lku where lkv.lku_key=lku.lku_key and
lku_type_string_key='Lookup.EBS.Responsibility' and instr(lkv_encoded,concat('$Form data.Application Name','~'))>0" display-field="lkv_decoded" save-field="lkv_encoded"/>
</AttributeReference>
</AttributeReference>
<AttributeReference name="UD_EBST_RLS" attr-ref="UD_EBST_RLS" type="String" length="20" widget="text" available-in-bulk="true">
<AttributeReference name="Start Date" attr-ref="Start Date" type="Date" widget="date" length="50" required="false" available-in-bulk="true"/>
<AttributeReference name="Expiration Date" attr-ref="Expiration Date" type="Date" widget="date" length="50" required="false" available-in-bulk="true"/>
<AttributeReference name="Application Name" attr-ref="Application Name" type="String" length="256" widget="lookup" required="false" available-in-bulk="true" lookup-code="Lookup.EBS.Application"/>
<AttributeReference name="Role Name" attr-ref="Role Name" type="String" length="256" widget="lookup-query" available-in-bulk="true" required="true">
<lookupQuery lookup-query="select lkv_encoded as lkv_encoded,lkv_decoded as lkv_decoded from lkv lkv,lku lku where lkv.lku_key=lku.lku_key and
lku_type_string_key='Lookup.EBS.UMX.Roles' and instr(lkv_encoded,concat('$Form data.Application Name','~'))>0" display-field="lkv_decoded" save-field="lkv_encoded"/>
</AttributeReference>
</AttributeReference>
</request-data-set>
図27-3に、SoDチェックが完了した後のリクエスト・データセット・ページに表示される、SoD属性のシステム属性を示します。
コネクタのITリソースで、まだ存在しない場合はTopologyNameパラメータを作成します。図27-4に、このパラメータが追加されたサンプルのITリソースを示します。
コネクタITリソースでSoDチェック・プロパティがtrueに設定され、topologyNameパラメータが適切な値に設定されている場合、承認ワークフローの前処理ステージでデフォルトのSoDチェックが実行されます。リクエストが作成された後、リクエスト・ステータスが、非同期SoDチェックの場合は「SoDチェック結果が保留中です」、同期SoDチェックの場合は「SoDチェックが完了しました」ステータスになります。非同期SoDチェックの場合、SoDチェックを完了するにはSoDチェック結果の取得(承認)スケジュール済ジョブが実行されている必要があります。
|
注意: SoDチェックの実行中にエラーが発生した場合は、リクエスト・データセット内の「SoDチェックのステータス」属性が |
図27-5に、非同期SODチェックのリクエスト履歴を示します。
あらゆるレベルの承認の前にデフォルトでトリガーされるSoDチェックに加え、事前定義されたDefaultSODApprovalワークフローをアタッチすることによってもSoDチェックをトリガーできます。ワークフローを承認の操作レベルにアタッチするには、承認ポリシーを作成します。
|
注意: Oracle Identity Manager 11gでは、SoDワークフローが機能するためにはSOAおよびWebLogic Serverにパッチが必要でした。Oracle Identity Manager 11g PS1のリリースでは、パッチは必要ありません。 |
デフォルト・ワークフローの使用の詳細は、「承認ポリシーを使用したワークフローの適用」を参照してください。このワークフローには、システム管理者に割り当てられる承認タスクが含まれています。この承認タスクの後で、SoDチェックを開始するために、非同期SoDCheck Webサービスがコールされます。SoDCheck Webサービスを完了してコールバックするには、SoDチェック結果の取得(承認)スケジュール済ジョブを実行する必要があります。図27-6に、SoDCheck Webサービス・コールを含むワークフローを示します。
|
注意: すべてのリクエストには、テンプレート・レベル承認、リクエスト・レベル承認および操作レベル承認の、3つの承認レベルがあります。DefaultSODApprovalワークフローをアタッチできるのは、承認レベルのみです。バルク・リクエストでは、すべてのリソースおよびユーザーについて、リクエスト・レベル承認が一般的です。このレベルの承認後、リソースとユーザーの組合せごとに個別のリクエストが作成されます。ワークフローでは、リソースとユーザーごとに、個別にSoDチェックが実行されます。 ワークフローは、リクエスト・レベル承認の後でSoDチェックが必要な場合に役立ちます。一例として、承認者によりコネクタITリソース情報が入力される場合があります。この場合、リクエスト・データセットのITリソース・フィールドは、次に示すように承認者専用に設定されます。 <AttributeReference name="EBS Server" attr-ref="EBS Server" type="String" length="50" widget="itresource-lookup" available-in-bulk="true" itresource-type="eBusiness Suite UM" required="true" approver-only="true"/> この例では、リクエストの要求時にはITリソース情報は使用できません。これは、承認者による入力後に初めて使用できるようになります。リクエスト・レベル承認時にこれが入力された場合は、DefaultSODApprovalワークフローを操作レベルで使用できます。 |
この後、承認タスクを含むswitch caseがSoD管理者ロールに割り当てられます。このロールを持つすべてのユーザーは、タスクを要求して承認できます。図27-7に示すように、switchは、SoDチェックの結果が成功か失敗かに基づきます。
図27-8に、承認タスクの割当てを示します。
承認ワークフローは、Oracle Identity Manager 11gリリース1(11.1.1)でBPELに移行されたため、デフォルト・ワークフローを表示または変更するには、JDeveloperを使用する必要があります。デフォルトのSoDワークフローは、OIM_HOME/workflows/composites/DefaultSODApproval.zipファイルに含まれています。このファイルを解凍し、JDeveloperでDefaultSODApproval.jprを開くことができます。さらに、デフォルトの承認ワークフローを変更して新しいワークフローを作成し、SoDチェックWebサービスをコールしてオンデマンドでSoDチェックを開始できます。これを行うには、次の手順を実行します。
SOAでのワークフローの作成とデプロイ
OIM_HOME/workflows/new-workflow/new_project.xmlを実行して、新しいワークフロー・プロジェクトを作成します。
説明:
WEBLOGIC_HOMEは、Oracle WebLogic Serverがインストールされているディレクトリです。
NEW_PROJECTは、作成する新規プロジェクトの名前です。
新しいワークフロー・プロジェクトを作成するには、次のコマンドを実行します。
ant -f new_project.xml
これにより、新しいワークフロー名のプロジェクト名、アプリケーション名およびサービス名を入力するよう要求されます。この3つすべてに、SODWorkflowのような任意の名前を指定します。これにより、指定された名前を持つ新規プロジェクトがworkflows/new-workflow/process-template/ディレクトリに作成されます。
JDevepolerでprocess-template/APPLICATION_NAME/PROJECT_NAME/にナビゲートし、PROJECT_NAME.jprを開きます(ここで、APPLICATION_NAMEおよびPROJECT_NAMEは、それぞれアプリケーションおよびプロジェクトの名前です)。
PROJECT_NAME.jprワークフローは、DefaultRequestApprovalワークフローと同じです。SoDCheck Webサービスをコールするように、このワークフローを変更できます。図27-9に、人による承認後にSoDチェックを実行するように変更された、デフォルト・ワークフローを示します。
OIM_HOME/workflows/composites/DefaultSODApproval.zipを解凍し、asyncsod.wsdlを解凍されたディレクトリからOIM_HOME/workflows/ process-template/APPLICATION_NAME/PROJECT_NAME/にコピーします。SODCheckService1などのWebサービスをcomposite.xmlに追加し、asyncsod.wsdlをWSDLファイルとして提供します。SoDCheckパートナ・リンクは、図27-10のようになります。
|
注意: BPELは、パートナ・リンクを介してすべての外部エンティティに接続します。 |
ApprovalProcess.bpel設計に、次のBPELアクティビティを含めます。
ASSIGN: assignアクティビティは、SoDチェックWebサービスをコールする前に追加する必要があります。このアクティビティにより、Webサービスをコールするために必要なパラメータが初期化されます。assignアクティビティを作成するには、次の手順を実行します。
i) JDeveloperで開いたBPELプロセスにアクティビティをドラッグ・アンド・ドロップします。
ii) アクティビティが作成されたら、アクティビティをダブルクリックし、「コピー操作」タブをクリックします。
iii) 「追加」をクリックして「コピー操作」を選択します。表27-1に示すように、変数の値を指定します。
表27-1 割り当てる変数
| コピー元 | コピー先 |
|---|---|
|
XML Fragment
<EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
<Address/>
</EndpointReference>
|
変数 partnerlink |
|
Expression concat(substring-before(bpws:getVariableData('inputVariable','payload','/client:process/ns1:url'), "/workflowservice/CallbackService"), '/sodcheck/SoDCheckInitiateService') |
Partnerlink, EndpointReference, Address |
|
変数 partnerlink |
Partner Link SODCheckService1 |
|
変数 Payload, RequestId |
変数 SODInvoke_initiate_InputVariable。SODInvoke_initiate_InputVariableは、Invoke BPELアクティビティで定義された変数です。 |
次の各図に、追加される値を示します。
図27-11に、最終的なassignアクティビティを示します。
INVOKE: このアクティビティの詳細は次のとおりです。
相互作用タイプ: Partnerlink
パートナ・リンク: SODCheckService
操作: Initiate
入力変数: SODInvoke_initiate_InputVariable
図27-12に、フィールドにサンプル値が入力された「Invoke」ダイアログ・ボックスを示します。
RECEIVE: このアクティビティの詳細は次のとおりです。
相互作用タイプ: Partnerlink
パートナ・リンク: SODCheckService
操作: Result
Variable: SODResultReceive_result_InputVariable
図27-13に、フィールドにサンプル値が入力された「Receive」ダイアログ・ボックスを示します。
SWITCH: このアクティビティは、SODCheckの結果に基づいてワークフローをスイッチするためのものです。switch caseは、図27-14のようになります。
新規ヒューマン・タスク: 新規ヒューマン・タスクを作成して、システム管理者以外の承認者に割り当てることができます。新規承認タスクは、ワークフローにすでに存在する古いものと同じですが、承認者が異なります。このヒューマン・タスクはswitch caseで使用されます。たとえば、SoDチェックが成功した場合に、承認タスクをロールに割り当てることができます。SoDチェックが失敗した場合は、承認タスクをSOD管理者ロールに割り当てることができます。DefaultSODApprovalでは常に、承認タスクをSoD管理者ロールに割り当てます。
|
注意: SoDCheck Webサービスは複数回コールできます。 |
AsyncSoD WebサービスのリクエストとコールバックのためのSAMLポリシーの適用:
Security Assertion Markup Language(SAML)にづいたメッセージ保護ポリシー付きOWSM SAMLトークンは、SOAコンポジットからOracle Identity ManagerへのSoDチェックの非同期コールにおいて、メッセージ保護のセキュリティ・ポリシーとして使用されます。非同期SoDチェックWebサービスでは、この項で説明するように、リクエストのためのメッセージ保護クライアント・ポリシー付きSAMLトークンおよびコールバックのためのメッセージ保護サービス・ポリシー付きSAMLトークンを使用する必要があります。
リクエストのためのメッセージ保護クライアント・ポリシー付きSAMLトークンを適用するには、次の手順を実行します。
i) 図27-15に示すように、AsynchSoD Webサービスを右クリックし、「WSポリシーの構成」を選択して、「リクエスト対象」を選択します。
ii) 「SOA WSポリシーの構成」ダイアログ・ボックスの「セキュリティ」セクションで、正符号(+)のアイコンをクリックしてセキュリティ・ポリシーを追加します。
iii) 図27-16に示すように、クライアント・セキュリティ・ポリシーの選択ダイアログ・ボックスで「wss11_saml _token_with_message_protection_client_policy」を選択し、「OK」をクリックします。
コールバックのためのメッセージ保護サービス・ポリシー付きSAMLまたはユーザー名トークンを適用するには、次の手順を実行します。
i) AsynchSoD Webサービスを右クリックし、「WSポリシーの構成」を選択して、「コールバック対象」を選択します。
ii) 「SOA WSポリシーの構成」ダイアログ・ボックスの「セキュリティ」セクションで、正符号(+)のアイコンをクリックしてセキュリティ・ポリシーを追加します。
iii) 図27-17に示すように、サーバー・セキュリティ・ポリシーの選択ダイアログ・ボックスで「wss11_saml _or_username_token_with_message_protection_service_policy」を選択し、「OK」をクリックします。
プロジェクトをコンパイルして、エラーがないか確認します。エラーがない場合は、プロジェクトを右クリックし、「デプロイ」を選択します。表示されるダイアログ・ボックスで、次のいずれかのオプションを選択します。
アプリケーション・サーバーにデプロイ: このオプションを選択してから、適切なサーバーを選択します。ワークフローは、アプリケーション・サーバーに直接デプロイされます。
JARにデプロイ: JDeveloperのデプロイ・ディレクトリの下に、sca_PROJECT_NAME_rev1.0.jarという名前でJARファイルが作成されます(ここで、PROJECT_NAMEはプロジェクトの名前です)。
SOA_HOME/bin/ディレクトリから、次のコマンドを実行してSOAサーバーにワークフローをデプロイします。
|
注意:
|
ant -f ant-sca-deploy.xml -DserverURL=http://SOA_SERVER_HOSTNAME:SOA_PORT -DsarLocation=JDeveloper/deploy/sca_PROJECT_NAME_rev1.0.jar -Duser=SOA_USER -Dpassword=SOA_PASSWORD
|
注意: 次の項目を有効な値で置き換える必要があります。
|
これにより、SOAサーバーに新規コンポジットがデプロイされます。次のURLにナビゲートすると、コンポジットがデプロイされたかどうかを確認できます。
http://SOA_SERVER_HOSTNAME:SOA_PORT/soa-infra
URLのSOA_SERVER_HOSTNAMEはSOAサーバーのホスト名で、SOA_PORTはSOAサーバーがインストールされているポートで置き換えてください。
SOAサーバーを再起動します。
ワークフローの登録
OIM_HOME/workflows/registration/ディレクトリに、DefaultRequestApproval.propsをコピーしてNEW_PROJECT_NAME.propsファイルを作成します。名前属性を変更して、NEW_PROJECT_NAME.propsを変更します。
ここで、NEW_PROJECT_NAMEは作成した新規プロジェクトの名前です。
NEW_PROJECT_NAME.propsファイルの内容は次のとおりです。
#This is is the input file for registering the default workflow
# <new project name>
name=NEW_PROJECT_NAME
category=Approval
providerType=BPEL
serviceName=RequestApprovalService
domainName=default
version=1.0
payLoadID=payload
operationID=process
listOfTasks=ApprovalTask
各構成要素は次のとおりです。
versionパラメータは、BPELにデプロイされたワークフローのバージョンです。
listOfTasksパラメータは、承認タスクのコロン区切りリストです。たとえば、新規承認タスクをApproval_Task1として追加する場合は、ApprovalTask:ApprovalTask1をこのパラメータの値として指定する必要があります。
次のようにしてOIM_HOME/workflows/registration /registerworkflows-mp.xmlを実行します。
ant -f registerworkflows-mp.xml register
このコマンドにより、次の項目を入力するよう要求されます。
ユーザー名: Oracle Identity Manager管理者のユーザー名を入力します。
パスワード: Oracle Identity Manager管理者のパスワードを入力します。
OIMサーバーのt3 URL: t3://OIM_HOST_NAME/OIM_MANAGED_SERVER_PORTと入力します。ここで、OIM_HOST_NAMEはOracle Identity Managerがインストールされているコンピュータのホスト名で、OIM_MANAGED_SERVER_PORTはOracle Identity Managerがインストールされているポートで置き換えます。
プロパティ・ファイルの入力パス(完全なファイル名): OIM_HOME/workflows/registration/NEW_PROJECT_NAME.props。ここで、NEW_PROJECT_NAMEは作成したプロジェクトの名前で置き換えます。
承認ポリシーを使用したワークフローの適用
SoDワークフローを適用するリクエスト・モデル用の承認ポリシーを作成します。たとえば、リソースのプロビジョニング中にSoDチェックを実行するには、「リソースのプロビジョニング」リクエスト・モデル用のポリシーを作成します。承認ポリシーの作成の詳細は、Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイドの承認ポリシーの作成に関する説明を参照してください。
|
注意:
|
各プロセス定義には、権限をユーザーにプロビジョニングするために、1つのプロセス・タスクがアタッチされています。SoD検証プロセスは、このタスクをトリガーする前、ターゲット・システムで権限を保持する子表にすべてのデータを挿入した直後に実行する必要があります。したがって、子表にデータを挿入した後、SoD検証プロセスが完了するまで、このプロセス・タスクを保持する必要があります。これを実行するには、ユーザーへの権限のプロビジョニングに先行するHolderタスクを作成します。
Holderタスクは、SoD検証プロセスが完了する前に、ユーザーにリソースをプロビジョニングすることを防ぐために追加されます。ユーザー権限は、このタスクが完了した場合にのみプロビジョニングされます。SoDエンジンで、権限の割当てがSoDポリシーまたはルールに違反していないことが検証されると、このタスクは完了します。
SoD検証プロセスが承認ワークフローで実行された場合、プロビジョニング・レベルでSoD検証プロセスが有効になっている場合であっても、SoD検証プロセスを再実行する必要はありません。SoD検証プロセスを実行する必要があるかないかは、プロビジョニング・レベルでのSoD検証プロセスの前に、次のチェックを行うことにより評価できます。
プロビジョニングはリクエストに関連がありますか。
関連がある場合、SoDCheckStatusフィールドはSoDCheckCompletedに設定されていますか。
設定されている場合、権限のプロビジョニング中にSoD検証プロセスを実行しないでください。
|
注意: SoD検証プロセスは、プロセス子フォームが権限の追加、更新または削除のために編集された場合のみ再実行されます。 |
SoD検証用プロビジョニング・ワークフローを変更するには、次の手順を実行します。
Holderタスクをプロビジョニング・ワークフローに追加します。このタスクは条件付きにし、「複数のインスタンスを許可」オプションを選択する必要があります。
次の図は、このHolderタスクを示しています。
コネクタの権限の挿入、更新および失効タスクを、Holderタスクに依存させます。
次の図は、Holderタスクに依存するOracle E-Business User Managementコネクタのすべての権限タスクを示しています。
次の図は、Add Responsibility to Userタスクに先行するタスクとしてのHolderタスクを示しています。
SODCheckerタスク(名前がSODCheckerで始まる任意のタスク)を追加します。このタスクは条件付きにする必要があります。
次の図は、このSODCheckerタスクを示しています。
InitiateSODCheckプロセス・タスク・アダプタをSoDCheckerタスクにアタッチします。
次のレスポンス・コードをSODCheckerタスクにアタッチします。
| レスポンス・コード | タスク・ステータス | 説明 |
|---|---|---|
|
SODCheckResultPending |
P |
SoD検証プロセスが開始され、結果待ちの状態です。 |
|
SODCheckCompleted |
C |
SoD検証プロセスの結果が返され、レスポンスはSoD違反がないことを示します。 |
|
SODCheckViolation |
C |
SoD検証プロセスの結果が返され、レスポンスはSoD違反があることを示します。 |
|
SODCheckNotInitiated |
C |
Oracle Identity ManagerでSoDが有効になっていないため、SoD検証プロセスは開始されていません。 |
次の図に、これらのレスポンス・コードを示します。
この項には次のトピックが含まれます:
権限を保持するリクエスト・データセット属性を、権限プロパティをtrueに設定してマークします。次に例を示します。
<AttributeReference name="Responsibility Name" attr-ref="Responsibility Name" type="String" length="256" widget="lookup-query" available-in-bulk="true" required="true" entitlement="true">
<lookupQuery lookup-query="select lkv_encoded as lkv_encoded,lkv_decoded as lkv_decoded from lkv lkv,lku lku where lkv.lku_key=lku.lku_key and
lku_type_string_key='Lookup.EBS.Responsibility' and instr(lkv_encoded,concat('$Form data.Application Name','~'))>0" display-field="lkv_decoded" save-field="lkv_encoded"/>
</AttributeReference>
子プロセス・フォーム表では、異なるタイプの複数値データ(ロール・データ、プロファイル・データおよびアドレス情報など)を保持できます。SoD処理に使用する権限データを保持している子プロセス・フォーム表をマークする必要があります。詳細は、「子プロセス・フォームでの権限属性のマーク」を参照してください。
この項には次のトピックが含まれます:
|
注意: この項で説明する手順は、Oracle E-Business Suite、SAP CUAおよびSAP R3以外のターゲット・システムを使用する場合にのみ実行します。Oracle Application Access Controls GovernorおよびSAP GRC以外のSoDエンジンを使用する場合は、「カスタムSoDエンジンの追加」の手順も実行する必要があります。 この手順は、Oracle Identity ManagerでのSoDの最初の実装前、または実装後のいつでも実行できます。 |
次に、新規ターゲット・システム用のSILを構成する手順のサマリーを示します。
「前提条件への対応」の項に示されている手順に従います。
コネクタ用にIdMvsSoDDataTransformationOperインタフェースのJavaクラス実装を作成します。手順は、「変換レイヤーの作成」を参照してください。
変換サービス・コンポーネントをデプロイします。「変換レイヤーのデプロイ」を参照してください。
登録XMLファイルに新規ターゲット・システムのエントリを追加します。手順は、「登録XMLファイルの変更」を参照してください。
「SoD非対応コネクタでのワークフローの構成」の手順を実行します。
権限データを保持する子プロセス・フォームをマークします。手順は、「権限としてのフィールドのマーク」を参照してください。
新規ターゲット・システムを登録します。手順は、「新規ターゲット・システムの登録」を参照してください。
次の前提条件を満たしていることを確認します。
ターゲット・システムからSoDエンジンに権限データをロードします。
詳細は、SoDエンジンのベンダーのドキュメントを参照してください。
ターゲット・システム用のOracle Identity Managerコネクタをデプロイします。詳細は、コネクタのドキュメントを参照してください。
変換レイヤーは、ターゲット・システムの属性値を、SoDエンジンで使用可能な値に変換するために使用されます。変換レイヤーは、すべての新規SoDエンジンまたはターゲット・システム・タイプに対して作成する必要があります。
IdMvsSoDDataTransformationOperインタフェースの実装として、変換レイヤーを作成する必要があります。transformInputおよびtransformSoDAnalysisInputメソッドの実装は、IdMvsSoDDataTransformationOperインタフェースの実装クラスで作成します。
|
関連項目: 実装メソッドの詳細は、Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンスを参照してください。 |
Oracle Identity Managerの以前のリリースでは、承認ワークフロー・データはオブジェクト・フォームから読み取られます。Oracle Identity Manager 11gリリース1(11.1.1)では、オブジェクト・フォームは承認プロセス内のリクエスト・データセットに置き換えられています。そのため、権限データがオブジェクト・フォームではなくリクエスト・データセットから読み取られるように、変換レイヤーを変更する必要があります。
変換レイヤーでは、リクエスト・モデルもチェックする必要があります。リクエスト・モデルがリソースのプロビジョニングである場合、データはリクエスト・データセットからのみ読み取る必要があります。一方、リクエスト・モデルがプロビジョニング済リソースの変更である場合は、データはリクエスト・データセットとプロセス・フォームの両方から読み取る必要があります。
変換サービス・コンポーネントは、次のようにデプロイされます。
IdMvsSoDDataTransformationOperサービス・コンポーネント・タイプの実装用に作成したJavaクラスのJARファイルを作成します。
UploadJarユーティリティを使用して、JARファイルをThirdPartyとしてアップロードします。
|
注意: UploadJar.shまたはUploadJar.batユーティリティは、OIM_HOME/bin/ディレクトリにあります。この場所からユーティリティを実行して、作成したJARファイルをMDSにアップロードします。 |
registration.xmlファイルで、次のようにして変換レイヤーの詳細を入力します。
MDSからRegistration.xmlファイルをインポートします。Registration.xmlファイルは、ネームスペース/metadata/iam-features-sil/db/Registration.xmlでMDS内に存在します。
テキスト・エディタでRegistration.xmlファイルを開きます。
SystemType要素およびServiceComponent要素を、このXML行ブロックのように追加します。
|
注意: 設定が必要な値は、太字で強調されています。このXMLブロックの後に、ガイドラインとサンプル値を示します。 |
<SystemType name="SYSTEM_TYPE_NAME" type="Sod Source DataStore"></SystemType>
<ServiceComponent type="IdMvsSoDDataTransformationOper" name="NAME_FOR_IMPLEMENTATION"
<Impl-Class>NAME_OF_IPMLEMENTATION_CLASS</Impl-Class>
<IdMSystemType>OIM</IdMSystemType>
<SoDEngineType>SoD_ENGINE</SoDEngineType>
<srcSystemType>SYSTEM_TYPE_NAME</srcSystemType>
<DataTransformation>
<AttrSoD type="user" name="NAME_OF_ATTRIBUTE_ON_TARGET_SYSTEM" sourceIdMAttrName="NAME_OF_ATTRIBUTE_ON_SOD_ENGINE" isSourceKey="true"/>
<AttrSoD type="user" name="firstname" sourceIdMAttrName="firstname" isSourceKey="false"/>
<AttrSoD type="user" name="lastname" sourceIdMAttrName="lastname" isSourceKey="false"/>
<AttrSoD type="duty" dutyType="ENTITLEMENT_TYPE" name="accessorigid" sourceIdMAttrName="ENTITLEMENT_NAME" isSourceKey="true"/>
</DataTransformation>
<DataTransformation>
. . .
</DataTransformation>
<DataTransformation>
. . .
</DataTransformation>
</ServiceComponent>
registration.xmlファイルでSystemType要素とServiceComponent要素を追加する際、次のガイドラインに従います。
プレースホルダを次の値に置き換えます。
SYSTEM_TYPE_NAME: システム・タイプの名前を指定します。
<SystemType>タグのタイプには、カスタム・ターゲット・システムの場合はSoD Source DataStore値を、カスタムSoDエンジンの値としてはSoD Engineを指定できます。
NAME_FOR_IMPLEMENTATION: サービス・コンポーネントの名前を指定します。たとえば、DBToOAACGのように指定します。
NAME_OF_IPMLEMENTATION_CLASS: 「変換レイヤーの作成」の手順に従って作成したクラスに設定した名前を指定します。たとえば、oracle.iam.grc.sod.scomp.impl.oaacg.transformation.IdMvsSoDDataTransformationOperDBvsOAACGのように指定します。
SoD_ENGINE: SoDエンジンとしてOracle Application Access Controls Governorを使用する場合は、OAACGを入力します。SoDエンジンとしてSAP GRCを使用する場合は、GRCを入力します。カスタムSILプロバイダを使用する場合は、そのSoDエンジンに設定した名前を入力します。
SYSTEM_TYPE_NAME: 先に入力したシステム・タイプ名を指定します。
NAME_OF_ATTRIBUTE_ON_TARGET_SYSTEM: ターゲット・システムの属性の名前を指定します。
NAME_OF_ATTRIBUTE_ON_SOD_ENGINE: SoDエンジンの対応する属性の名前を指定します。
ENTITLEMENT_TYPE: 権限のタイプを入力します。たとえば、ROLEのように指定します。
ENTITLEMENT_NAME: 権限の1つのインスタンスの名前を入力します。たとえば、Resource Managerのように指定します。
作成する属性マッピングごとに1つのDataTransformation要素を追加します。
Registration.xmlファイルを保存して閉じます。
Registration.xmlファイルをエクスポートしてMDSに戻します。
新規ターゲット・システムを登録するには、次の各項に記載されている手順を実行します。
登録スクリプト(registration.shおよびregistration.bat)により、登録プロセスが進められます。このスクリプトを実行すると、必要な情報を入力するよう要求されます。スクリプトにより最初に表示される一連のプロンプトは、registration.xmlファイルから読み取られます。登録スクリプトはOIM_HOME/binディレクトリにあります。registration.xmlファイルはMDSにあります。
|
注意: Oracle Identity Managerインストールのライフサイクル中はいつでも、登録スクリプトを複数回実行できます。たとえば、新規のSoDエンジンを登録するとします。スクリプトの実行時に、プロンプトを使用して、入力を行うセクションに移動します(一連のプロンプト)。残りのセクションはスキップできます。 登録スクリプトの実行例は、例27-1を参照してください。この例では、SoDエンジンの情報を指定するためにITリソースが作成されているものと仮定します。 |
スクリプトを実行し、Oracle Identity Managerインストール、SoDエンジンおよびターゲット・システムの登録情報を指定するには、次の手順を実行します。
MDSからSILConfig.xmlファイルをエクスポートします。SILConfig.xmlファイルは、ネームスペース/metadata/iam-features-sil/db/SILConfig.xmlで、MDS内に存在します。
テキスト・エディタでSILConfig.xmlファイルを開き、DOMBuilderFactoryImpl要素の値を指定します。
DOMBuilderFactoryImpl要素の値は、使用するJREによって異なります。
Sun JREまたはOracle JRockit JREを使用する場合は、次の値を含むDOMBuilderFactoryImpl要素のコメントアウトを解除します。
com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl
IBM JREを使用する場合は、次の値を含むDOMBuilderFactoryImpl要素のコメントアウトを解除します。
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
コマンド・ウィンドウで、OIM_HOME/binディレクトリに移動し、登録スクリプトを実行します。
Oracle Identity Managerのログイン情報を入力します。ユーザー名、パスワードおよびURLの値を入力するよう要求されます。サンプルの実行セグメントを次に示します。
[Enter the admin username:]OIM_ADMINISTRATOR_LOGIN [Enter the admin password:]OIM_ADMINISTRATOR_PASSWORD [Enter the service url:]t3://OIM_HOST_NAME:OIM_PORT_NO
次の項目に対して有効な値を指定します。
OIM_ADMINISTRATOR_LOGIN
OIM_ADMINISTRATOR_PASSWORD
OIM_HOST_NAME
OIM_PORT_NO
T3 URLの例は次のとおりです。
t3://localhost:14000
登録を続行するかどうかの指定を要求されます。
Do you want to proceed with registration? (y/n)
|
注意: ここから先は、スクリプトで表示される各プロンプトの説明の後に、プロンプトの実際のメッセージが続きます。このドキュメントでは、実際のメッセージは固定幅フォントで示されます。 |
登録を続行するには、yを入力します。Oracle Identity Managerインストールを登録するかどうかの指定を要求されます。
Register System Instance for type OIM?(y/n)
nを入力します。
Oracle E-Business Suiteインストールを登録するかどうかの指定を要求されます。
Register System Instance for type EBS? (y/n)
デフォルトで登録されている既存のOracle E-Business Suiteを使用する場合は、nを入力します。Oracle Identity Managerの別のITリソースを含む新規EBSインスタンスを登録するには、yを入力します。
yを入力すると、Oracle E-Business Suiteインストールのインスタンス名の入力を要求されます。
Provide instance name
Oracle E-Business Suiteインストールの名前を入力します。例:
ebs2
Oracle Application Access Controls Governorインストールを登録するかどうかの指定を要求されます。
Register System Instance for type OAACG? (y/n)
デフォルトで登録されている既存のOAACGを使用する場合は、nを入力します。Oracle Identity Managerの別のITリソースを含む新規OAACGインスタンスを登録するには、yを入力します。
yを入力すると、Oracle Application Access Controls Governorインストールのインスタンス名の入力を要求されます。
Provide instance name
Oracle Application Access Controls Governorインストールの名前を入力します。例:
oaacg01
作成したITリソース名の入力を要求されます。
OIM ITResource Instance Name:
作成したITリソース名OAACG ITR2を入力します。
登録するSoDコンポーネント(システム・インスタンス)が他にない場合は、残りのプロンプトでnを入力します。そうでない場合は、SAPおよびGRCインスタンスに対して同様の手順に従います。この後で、Registration.xmlに追加したカスタム・システム・タイプ(たとえば、NEW)の入力を要求されます。
Register System Instance for type NEW? (y/n)
yを入力します。カスタム・タイプのインスタンス名の入力を次のように要求されます。
Provide instance name
インストールの名前を、new1のように入力します。追加したシステム・タイプがSoDエンジンである場合は、作成したITリソースの名前の入力を要求されます。
OIM ITResource Instance Name:
作成したITリソース名ITR_NEWを入力します。
テキスト・エディタでSILConfig.xmlファイルを開き、Topologies要素の値を指定します。トポロジの値の詳細は、「システム・タイプ名の記録」を参照してください。
次のXMLブロックは、Topologies要素とその子要素を示しています。
|
注意: ターゲット・システムとSoDエンジンの組合せが複数ある場合、Topologies要素内に複数のTopology要素を追加できます。 |
<Topologies> <Topology> <name>@topologyName</name> <IdmId>@Idm RegistrationId</IdmId> <SodId>@Sod RegistrationId</SodId> <SDSId>@Sds RegistrationId</SDSId> </Topology> </Topologies>
Topologies要素の次の子要素の値を入力します。
@topologyName: トポロジ名を入力します。
|
注意: TopologyName ITリソース・パラメータの値として、Topology要素と同じ名前を設定します。 |
@Idm RegistrationId: Oracle Identity Managerインストールの登録IDを入力します。
@Sod RegistrationId: SoDエンジンの登録IDを入力します。
@Sds RegistrationId: ターゲット・システムの登録IDを入力します。
SILConfig.xmlをエクスポートしてMDSに戻します。
例27-1に、登録スクリプトの実行例の出力を示します。ここでは、SoDエンジンの情報を指定するためにITリソースが作成されているものと仮定します。
例27-1 登録スクリプトの実行例
sh registration.sh Enter data related to login to OIM Server [Enter the admin username:]OIM_ADMINISTRATOR_LOGIN [Enter the admin password:]OIM_ADMINISTRATOR_PASSWORD [Enter the service url:]t3://localhost:14000 Do you want to proceed with registration? (y/n) y Register System Instance for type OIM ?(y/n) n Register System Instance for type EBS ?(y/n) n Register System Instance for type OAACG ?(y/n) n Register System Instance for type SAP ?(y/n) n Register System Instance for type GRC ?(y/n) n Register System Instance for type NEW ?(y/n) y Provide instance name new1 OIM ITResource Instance Name: ITR_NEW
登録プロセスの最後に、システム・タイプ名がOracle Identity Managerデータベースで設定されます。これらの名前は、登録スクリプトを使用してデータベースから取得できます。取得したら、これらの名前をSILConfig.xmlファイルに入力する必要があります。
サービス・コンポーネント名を取得して記録するには、次の手順を実行します。
コマンド・ウィンドウで、次のディレクトリに移動します。
OIM_HOME/bin/
次のコマンドのいずれかを実行します。
Microsoft Windowsの場合:
registration.bat printRegistrationIDs
UNIXの場合:
registration.sh printRegistrationIDs
このコマンドの出力例は、次のとおりです。
----------------------------------------------- System Type Instance Name Registration ID ----------------------------------------------- OIM oim 1 EBS Ebs 2 OAACG oaacg 3
これらのインスタンス名を参照のためにコピーします。
|
注意: この項で説明する手順は、Oracle Application Access Controls GovernorおよびSAP GRC以外のSoDエンジンを使用する場合にのみ実行します。Oracle E-Business Suite、SAP CUAおよびSAP R3以外のターゲット・システムを使用する場合は、「カスタム・ターゲット・システムの使用」の手順も実行する必要があります。 SILプロバイダの作成を開始する前に、SoDエンジンをインストールする必要があります。 この手順は、Oracle Identity ManagerでのSoDの最初の実装前、または実装後のいつでも実行できます。 |
次に、SILプロバイダを作成する手順のサマリーを示します。
「前提条件への対応」の項に示されている手順に従います。
SoDエンジンの情報を保持するためのITリソースを作成します。「SoDエンジンの情報を保持するためのITリソースの作成」を参照してください。
SILプロバイダ用インタフェースのJavaクラス実装を作成します。手順は、「プロバイダ用サービス・コンポーネントの実装」を参照してください。
サービス・コンポーネントをデプロイします。「サービス・コンポーネントのデプロイ」を参照してください。
登録XMLファイルに、新規SoDエンジンのエントリを追加します。手順は、「新規SoDエンジン用登録XMLファイルの変更」を参照してください。
新規SoDエンジンを登録します。手順は、「新規SILプロバイダの登録」を参照してください。
次の前提条件を満たしていることを確認します。
ターゲット・システムからSoDエンジンに権限データをロードします。この手順を実行するために、任意のETLユーティリティを使用できます。詳細は、SoDエンジンのベンダーのドキュメントを参照してください。
SoDエンジンで、ターゲット・システムからロードしたデータを使用して、ポリシー定義またはリスク定義を作成します。
ターゲット・システム用のOracle Identity Managerコネクタをデプロイします。詳細は、コネクタのドキュメントを参照してください。
SoDエンジンの情報を保持するには、ITリソースを作成する必要があります。
ITリソース・タイプ(まだ存在しない場合)およびITリソースの作成の詳細は、第11章「リソース・オブジェクトの開発」を参照してください。ITリソース・タイプおよびITリソースには任意の名前を指定できます。次の表は、ITリソースに含める必要のあるパラメータの名前を示しています。
| パラメータ | 説明 | サンプル値 |
|---|---|---|
|
Source Datastore Name |
SoDエンジンで定義したソース・データ・ストア(ターゲット・システム)の名前を入力します。 ソース・データ・ストア名は、「Oracle Application Access Controls Governorの構成」の項で説明されている手順の実行中に指定します。 |
|
|
dbuser |
SoDエンジンで使用されるデータベース上のスキーマ所有者のユーザー名を入力します。 このアカウントは、SoD処理中にApplication Access Controls Governorデータベースへのアクセスに使用されます。 注意: このパラメータは、Oracle Application Access Controls Governor固有のものです。 |
|
|
dbpassword |
SoDエンジンで使用されるデータベース上のスキーマ所有者のパスワードを入力します。 注意: このパラメータは、Oracle Application Access Controls Governor固有のものです。 |
|
|
jdbcURL |
SoDエンジンで使用されるデータベースに接続するためのJDBC URLを入力します。 注意: このパラメータは、Oracle Application Access Controls Governor固有のものです。 |
|
|
password |
APIコール用にSoDエンジンで作成されたアカウントのパスワードを入力します。 |
|
|
port |
SoDエンジンがリスニングを行うポートの番号を入力します。 |
|
|
server |
SoDエンジンが稼働しているホスト・コンピュータのIPアドレスを入力します。 |
|
|
sslEnable |
SoDエンジンでHTTPS通信リクエストのみを受け入れる場合、 |
|
|
username |
SoDエンジンで作成されたアカウントのユーザー名を入力します。このアカウントは、SoD検証中に使用されるSoDエンジンAPIのコールのために使用されます。 |
|
|
sodServerURL |
SoDサーバーのURLを次の形式で入力します。 http(s)://HOST_NAME:PORT_NUMBER/URL |
|
|
注意: 複数のSoDエンジンを使用する場合は、同じITリソース・タイプで複数のITリソースを作成してください。 |
次のサービス・コンポーネントのJava実装を作成します。
|
関連項目: Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンス |
SoDAnalysisExecutionOper: SoD分析レイヤーを、デフォルトで提供されていないカスタムSoDエンジン用に実装する必要があります。
IdMvsSoDDataTransformationOper: ターゲット・システムの属性値を、SoDエンジンで使用可能な値に変換するために使用されます。変換レイヤーは、すべての新規SoDエンジンまたはターゲット・システム・タイプに対して作成する必要があります。
CallBackIdMOper(オプション): Oracle Identity Managerにアクセスするために、SoD分析レイヤーからのコールバックが必要な場合に実装されます。
SoDDataValidationOper(オプション): SoD分析レイヤーで指定された属性に対して検証を提供するために実装されます。
「プロバイダ用サービス・コンポーネントの実装」で作成されたサービス・コンポーネントは、次のようにデプロイされます。
サービス・コンポーネントの実装用に作成したJavaクラスのJARファイルを作成します。
UploadJarユーティリティを使用して、JARファイルをThirdPartyとしてアップロードします。
|
注意: UploadJar.shまたはUploadJar.batユーティリティは、OIM_HOME/binにあります。この場所からユーティリティを実行して、作成したJARファイルをMDSにアップロードします。 |
Registration.xmlファイルで、次のようにして変換レイヤーの詳細を入力します。
MDSからRegistration.xmlファイルをインポートします。Registration.xmlファイルは、ネームスペース\metadata\iam-features-sil\db\Registration.xmlでMDS内に存在します。
テキスト・エディタでRegistration.xmlファイルを開きます。
SoDエンジン用のSystemType要素を次のように追加します。
<SystemType name="SYSTEM_TYPE_NAME" type="SYSTEM_TYPE" isSynch="IS_SYNCH"> <!-- The Parameters which are required to connect the Sod Engine. --> <Parameter name="PARAM_NAME1" required="true" /> <Parameter name="PARAM_NAME2" required="true" /> ... </SystemType>
ここで、次のように値を置き換えます。
SYSTEM_TYPE_NAMEをシステム・タイプ名で置き換えます。
SYSTEM_TYPEをSoDエンジンで置き換えます。
IS_SYNCHを、SoDエンジンが同期か非同期かに応じて、trueまたはfalseで置き換えます。
PARAM_NAMEを、SoDエンジンに接続するために使用するパラメータ名で置き換えます。これらのパラメータ値は、SoDエンジンの登録中に指定する必要があります。これらは、SoDエンジンに接続するために、サービス・コンポーネント実装クラスで読み取られます。
実装されたすべてのサービス・コンポーネントを次のように追加します。
<ServiceComponent type="SERVICECOMPONENT_TYPE" name="NAME_FOR_IMPLEMENTATION" <Impl-Class>NAME_OF_IPMLEMENTATION_CLASS</Impl-Class> <IdMSystemType>SYSTEM_TYPE_NAME_FOR_IDM</IdMSystemType> <SoDEngineType>SYSTEM_TYPE_NAME_FOR_SOD_ENGINE</SoDEngineType> <srcSystemType>SYSTEM_TYPE_NAME_FOR_TARGET_SYSTEM</srcSystemType> <!-- AttrSoD tag is only required for Sod Analysis Service Component--> <AttrSoD type="user" isKey="true" name="NAME_OF_ATTRIBUTE_ON_SOD_ENGINE"> <!-- "name" attribute of the "Validation" element should be same as the "name" of one of the registered "ServiceComponent" of type "SoDDataValidationOper" --> <Validation name="NAME_FOR_VALIDATION_ON_ATTRIBUTE"/> </AttrSoD> <AttrSoD type="duty" isKey="true" dutyType="ENTITLEMENT_TYPE" name="NAME_OF_ENTITLEMENT_ON_SOD_ENGINE"><Validation name="isNotNullOAACG"/> </AttrSoD> <AttrSoD...> ... </AttrSoD> <!-- DataTransformation tag is only required for transformation Service component--> <DataTransformation> <AttrSoD type="user" name="NAME_OF_ATTRIBUTE_ON_TARGET_SYSTEM" sourceIdMAttrName="NAME_OF_ATTRIBUTE_ON_SOD_ENGINE" isSourceKey="true"/> <AttrSoD type="user" name="firstname" sourceIdMAttrName="firstname" isSourceKey="false"/> <AttrSoD type="user" name="lastname" sourceIdMAttrName="lastname" isSourceKey="false"/> <AttrSoD type="duty" dutyType="ENTITLEMENT_TYPE" name="accessorigid" sourceIdMAttrName="ENTITLEMENT_NAME" isSourceKey="true"/> </DataTransformation> </ServiceComponent>
ここで、次のように値を置き換えます。
SERVICECOMPONENT_TYPE: サービス・コンポーネントのタイプに応じて、CallBackIdMOper、SoDAnalysisExecutionOper、SoDDataValidationOperまたはIdMvsSoDDataTransformationOperなどの値を指定できます。
NAME_FOR_IMPLEMENTATION: サービス・コンポーネントの名前をDBToOAACGのように指定します。
NAME_OF_IPMLEMENTATION_CLASS: 「変換レイヤーの作成」の手順に従って作成したクラスに設定した名前を指定します。たとえば、oracle.iam.grc.sod.scomp.impl.oaacg.transformation.IdMvsSoDDataTransformationOperDBvsOAACGのように指定します。
SOD_ENGINE: SoDエンジンとしてOracle Application Access Controls Governorを使用する場合は、OAACGを入力します。SoDエンジンとしてSAP GRCを使用する場合は、GRCを入力します。カスタムSILプロバイダを使用する場合は、そのSoDエンジンに設定した名前を入力します。
SYSTEM_TYPE_NAME: 先に入力したシステム・タイプ名を指定します。
NAME_OF_ATTRIBUTE_ON_TARGET_SYSTEM: ターゲット・システムの属性の名前を指定します。
NAME_OF_ATTRIBUTE_ON_SOD_ENGINE: SoDエンジンの対応する属性の名前を指定します。
ENTITLEMENT_TYPE: 権限のタイプを、ROLEのように入力します。
ENTITLEMENT_NAME: 権限の1つのインスタンスの名前を、Resource Managerのように入力します。
Registration.xmlファイルを保存して閉じます。
Registration.xmlファイルをエクスポートしてMDSに戻します。
新規SILプロバイダを登録するには、次の各項で説明されている手順を実行します。
登録スクリプトの再実行の詳細は、「登録スクリプトの実行と登録情報の指定」を参照してください。スクリプトのここでの実行では、登録済のサービス・コンポーネントの値を入力しないでください。
SILConfig.xmlファイルでの新規ターゲット・システムに関するデータの入力の詳細は、「システム・タイプ名の記録」を参照してください。
ロールSoDチェックは、ユーザーにロールを割り当てるリクエストまたはユーザーからロールを削除するリクエストが要求された場合に実行されます。Oracle Identity AnalyticsによるロールSoDチェックは、リクエストが要求された場合にのみ実行され、ロールが直接割り当てられた場合または削除された場合は実行されません。
|
注意: Oracle Identity AnalyticsによるSoDチェックを実行するには、Oracle Identity ManagerとOracle Identity Analyticsが統合されていることが前提条件です。 |
Oracle Identity AnalyticsによるロールSoDチェックを有効化するには、次の手順を実行する必要があります。
XL.SoDCheckSystemPropertyシステム・プロパティの値をTRUEに設定します。システム・プロパティの詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のシステム・プロパティの管理に関する説明を参照してください。
RoleSoDCheckTopologyNameシステム・プロパティの値をsodoiaに設定します。このトポロジは事前定義され、登録されています。
OIA-ITRes ITリソースでOIA接続の詳細を、次の図に示すように設定します。
次の各項では、ロールSoD機能を実装する方法について説明します。
次の手順は、ユーザーがロールに対するリクエストを要求した場合に実行されます。SoDチェックは、有効化されている場合に実行されます。この手順の例では、ユーザーにrole1がすでに割り当てられていることを前提としています。
次のステップを実行します。
管理およびユーザー・コンソールにユーザーとしてログインします。
「セルフ・サービス」で、「リクエストの作成」タブをクリックし、「自分のためのリクエスト」オプションを選択して、「次」をクリックします。
「リクエスト・テンプレート」リストから、「ロールの自己割当て」を選択して、「次」をクリックします。
ユーザーにすでに割り当てられているロールと競合するロールを選択し、「次」をクリックします。
理由を追加し、「終了」をクリックしてリクエストを発行します。
管理およびユーザー・コンソールからログアウトします。
管理およびユーザー・コンソールに管理者としてログインし、次のことを確認します。
次の図に示すように、リクエストの詳細を表示します。
次の図に示すように、リクエストの詳細でSoDチェックの結果を表示します。
この手順では、削除されるロールがユーザーにすでに割り当てられていることを前提としています。
次のステップを実行します。
管理およびユーザー・コンソールにユーザーとしてログインします。
「セルフ・サービス」で、「リクエストの作成」タブをクリックし、「自分のためのリクエスト」オプションを選択して、「次」をクリックします。
「リクエスト・テンプレート」リストから、「ロールの自己削除」を選択して、「次」をクリックします。
削除するロールを選択し、「次」をクリックします。
「終了」をクリックしてリクエストを発行します。
管理およびユーザー・コンソールからログアウトします。
管理およびユーザー・コンソールに管理者としてログインし、次のことを確認します。
次の図に示すように、リクエストの詳細を表示します。
リクエストの詳細でSoDチェックの結果を表示します。競合するロールの1つが削除されたため、SoDチェックは成功します。次の図は、SoDチェックの結果を示しています。
この手順により、システム管理者はユーザーにロールを割り当てることができます。
管理およびユーザー・コンソールにシステム管理者としてログインします。
拡張管理で、「リクエストの作成」タブをクリックし、「リクエスト・テンプレート」リストから「ロールの割当て」を選択して、「次」をクリックします。
リクエストを要求する対象のユーザーを選択して、「次」をクリックします。
ユーザーに割り当てるロールを選択して、「次」をクリックします。
「終了」をクリックしてリクエストを発行します。
次の手順は、リクエストに関連するロールの数によって異なります。
3つ以上のロールに対するリクエストが要求された場合、バルク・リクエストが作成されます。この場合、SoDチェックは個別の子リクエストに対して実行されます。まず、「セルフ・サービス」にログインし、承認するリクエストを選択して、「タスクの承認」をクリックすることにより、リクエスト・レベル承認を実行する必要があります。
2つのロールに対するリクエストが要求された場合、2つの子リクエストが作成され、そのそれぞれに対してSoDチェックが実行されます。次の図は、2つの子リクエストを示しています。
最初の子リクエストをクリックして、SoDチェックの結果を表示します。
結果には、次のように、2つの競合するロールに対するリクエストが要求されたために、SoDチェックが失敗したことが示されています。
2番目のリクエストをクリックすると、次のようにその詳細が表示されます。
この手順により、システム管理者はユーザーからロールを削除できます。
管理およびユーザー・コンソールにシステム管理者としてログインします。
拡張管理で、「リクエストの作成」タブをクリックし、「リクエスト・テンプレート」リストから「ロールからの削除」を選択して、「次」をクリックします。
リクエストを要求する対象のユーザーを選択して、「次」をクリックします。
削除するロールを選択し、「次」をクリックします。
「終了」をクリックしてリクエストを発行します。
次に示すように、リクエストの詳細を表示します。
リクエストの詳細でSoDチェックの結果を表示します。競合するロールの1つが削除されたため、次に示すように、SoDチェックに成功しました。
このタイプのリクエストは自動的に承認されます。前述のユースケースに示すように、リクエストを要求できます。選択されるリクエスト・テンプレートは、「コールバック・ポリシーを持つロールの割当て」またはコールバック・ポリシーを持つロールの削除です。SoDチェックは、前述のユースケースに示すように実行されます。
この項では、SoDに関連する様々なユースケースについて説明します。
|
注意: この項の手順は、OAACGなどの非同期SoDエンジン用であり、非同期SoDエンジンでSoDチェックを完了するには、スケジュール済ジョブを実行する必要があります。 |
次の手順を実行して、ダイレクト・プロビジョニングでSoDチェックを有効化できます。
SoDチェック・システム・プロパティを有効化します。SoDチェック・システム・プロパティの詳細は、「SoDの有効化」を参照してください。
コネクタITリソースでトポロジ名パラメータを設定します。トポロジ名パラメータの設定の詳細は、「SoDの有効化」の手順2を参照してください。
「SoD用のプロビジョニング・ワークフローの変更」の説明に従って、コネクタ・プロビジョニング・ワークフローを変更します。
SoD対応リソースを直接プロビジョニングするには、次の手順を実行します。
ターゲット・システムにアカウントを作成するユーザーを作成します。
Oracle Identity Administrationの「ユーザーの詳細」ページで、「リソース」タブに移動し、「追加」をクリックします。
使用可能なオプションから、SoD対応リソースを選択します。
プロセス・フォームの詳細を入力します。親プロセス・フォームには、SoDCheckStatus、SoDCheckTrackingID、SoDCheckResult、SoDCheckTimestampおよびSoDCheckEntitlementViolationなどのSoDチェック・フィールドが含まれている必要があります。これらのフィールドには、SoDチェックの値が移入されます。
子フォームに権限を入力したことを確認します。入力されていない場合、SoDは競合する権限をチェックするためにのみ必要なため、SoDチェックは実行されません。
プロビジョニングの開始後、ターゲット・システムにアカウントが作成されたことは確認できますが、権限はプロビジョニングされません。これは、SoDチェックが完了するまで、権限タスクは「待機中」ステータスに保持されるためです。
リソース・プロファイルで、HolderタスクおよびSoDCheckerタスクが「保留」ステータスになり、親プロセス・フォームのSoDCheckStatusフィールドに「SoDチェック結果が保留中です」と表示されます。SoDCheckTrackingIDフィールドには、SoDエンジンで開始されたシミュレーションのトラッキングIDが表示されます。
SoDチェック結果の取得(プロビジョニング)スケジュール・ジョブを実行して、SoDエンジンから結果を取得し、SoDチェックを完了します。
親プロセス・フォームのSoDCheckResultが「成功」ステータスになっている場合、競合は存在せず、ターゲット・システムで権限がプロビジョニングされます。フォームのSoDCheckStatusフィールドに「SoDチェックが完了しました」と表示され、HolderタスクおよびSoDCheckerタスクが完了します。
親プロセス・フォームのSoDCheckResultが「失敗」ステータスになっている場合、競合が存在し、ターゲット・システムで権限はプロビジョニングされません。フォームのSoDCheckEntitlementViolationフィールドに、SoDエンジン上で競合しているポリシーが表示され、Holderタスクは取り消されます。
リソース・プロファイルを開き、子フォームで権限を追加、更新または削除しようとしたときには必ずSoDチェックがトリガーされ、新規HolderタスクおよびSoDCheckerタスクが生成されます。SoDチェックを完了するには、SoDチェック結果の取得(プロビジョニング)スケジュール・ジョブを実行する必要があります。新しい権限が古い権限と競合する場合、新しい権限はプロビジョニングされません。そうでない場合は、新しい権限がターゲット・システムでプロビジョニングされます。
権限の追加、更新および削除は、行単位で行われます。そのため、変更ごとに個別のSoDチェックがトリガーされます。2つ変更を行うと、変更ごとに1つ、合わせて2つの新規SoDCheckerタスクが表示されます。
次の操作を行うことにより、リクエスト・プロビジョニングでデフォルトのSoDチェックを有効化できます。
SoDチェック・システム・プロパティを有効化します。
コネクタITリソースでトポロジ名パラメータを設定します。
リクエスト・データセットにはITリソース・タイプの属性が必要で、その値はリクエスト作成中に指定する必要があります。有効な値が、そのトポロジ名パラメータに存在する必要があります。
SoD対応リソースをプロビジョニングするためのリクエストを作成するには、次の手順を実行します。
Oracle Identity Manager拡張管理で、「リクエスト」セクションに移動し、左ペインのツールバーで「リクエストの作成」をクリックします。「リソースのプロビジョニング」リクエスト・モデルを選択します。
リクエスト・データセットで定義された属性の値を指定します。SoDチェック・フィールドは共通データセットの一部であり、リクエストの作成中には表示されません。これらのフィールドは、リクエストが作成された後に、「リクエストの詳細」ページに表示できます。
リクエストの作成ウィザードで権限データを属性値として指定すると、このウィザードにより、リクエスト・データセットに基づいて属性名が表示されます。権限が指定されない場合、SoDチェックは開始されません。
SoDが正常に開始されると、リクエストは「SoDチェック結果が保留中です」ステータスになります。リクエスト・データセットでSoDチェック・フィールドの値を確認します。エラーが原因でSoDが正常に開始されない場合、リクエストは直接「リクエスト承認を取得しています」ステータスに移行します。データセット内のSoDCheckStatusフィールドには、「SoDチェックが開始されていません」と表示されます。
リクエストが「SoDチェック結果が保留中です」ステータスになっている場合は、SoDチェック結果の取得(承認)スケジュール・ジョブを実行してSoDチェックを完了し、リクエストを承認に送ります。競合がある場合は、SoDCheckResultフィールドに「失敗」ステータスが表示され、SoDCheckEntitlementViolationフィールドに違反している職務が表示されます。
Oracle Identity Managerセルフ・サービスから、リクエスト・レベル承認を承認または拒否します。リクエスト・レベル承認のデフォルト・ワークフローはDefaultRequestApprovalです。このワークフローに従って、承認タスクがシステム管理者ロールに割り当てられます。管理者がリクエストを承認すると、リクエストは操作レベル承認に送られます。デフォルトでは、このレベルの承認はシステム管理者ロールにも割り当てられます。
承認者は、リクエストの詳細フィールドに表示されているSoDチェックの結果に基づいて、リクエストを承認または拒否できます。
すべての承認が取得されると、リソースがターゲット・システムでプロビジョニングされます。
ターゲット・システムでのアカウントの変更を要求するには、次の手順を実行します。
Oracle Identity Manager拡張管理で、「リクエスト」セクションに移動し、左ペインのツールバーで「リクエストの作成」をクリックします。「プロビジョニング済リソースの変更」リクエスト・モデルを選択します。
変更するリソースおよび変更を必要とするユーザーを選択します。
リクエスト・データセットに事前定義されている属性の値が表示されます。SoDチェック・フィールドは共通データセットの一部であり、リクエストの作成中には表示されません。これらのフィールドは、リクエストが作成された後に、「リクエストの詳細」ページに表示できます。
リクエストの作成ウィザードで、権限データを属性値として追加、更新または削除すると、このウィザードにより、リクエスト・データセットに基づいて属性名が表示されます。
SoDが正常に開始されると、リクエストは「SoDチェック結果が保留中です」ステータスになります。リクエスト・データセットでSoDチェック・フィールドの値を確認します。エラーが原因でSoDが正常に開始されない場合、リクエストは直接「リクエスト承認を取得しています」ステータスに移行します。SoDCheckStatusフィールドには、「SoDチェックが開始されていません」と表示されます。
リクエストが「SoDチェック結果が保留中です」ステータスになっている場合は、SoDチェック結果の取得(承認)スケジュール・ジョブを実行してSoDチェックを完了し、リクエストを承認に送ります。競合がある場合は、SoDCheckResultフィールドに「失敗」ステータスが表示され、SoDCheckEntitlementViolationフィールドに違反している職務が表示されます。
セルフ・サービスから、リクエスト・レベル承認を承認または拒否します。リクエスト・レベル承認のデフォルト・ワークフローはDefaultRequestApprovalです。このワークフローに従って、承認タスクがシステム管理者ロールに割り当てられます。管理者がリクエストを承認すると、リクエストは操作レベル承認に送られます。デフォルトでは、このレベルの承認はシステム管理者にも割り当てられます。承認者は、リクエストの詳細フィールドに表示されているSoDチェックの結果に基づいて、承認または拒否できます。
すべての承認が取得されると、新しい権限がターゲット・システムでプロビジョニング、更新または削除されます。
承認ポリシーを使用してDefaultSODApprovalワークフローが指定されている場合は、リクエスト・プロビジョニングのための次の手順を実行します。
操作レベルでDefaultSODApprovalワークフローを指定します。つまり、承認の操作レベルより前の手順は同じままです。
DefaultSODApprovalワークフローによって、リクエストが承認の操作レベルに送られると、承認タスクがシステム管理者ロールに割り当てられます。管理者がこのタスクを承認すると、SoDチェックWebサービスがロードされ、SoDチェックが開始されます。
これは、リクエスト・ステータス(「SoDチェック結果が保留中です」である必要があります)をチェックすることにより確認できます。SoDチェック結果の取得(承認)スケジュール済ジョブを実行してSoDチェックを完了します。
SOD管理者ロールに割り当てられる承認タスクが生成されます。このロールを持つすべてのユーザーが、タスクを要求して承認できます。
タスクを承認する前に、リクエストの詳細でSoDチェックの結果を確認してください。タスクが承認されている場合、アカウント、権限またはその両方のプロビジョニングが続けられます。
このユースケースでは、SoDチェックは2回実行されます。1回目はあらゆるレベルの承認の前に行われるデフォルトのSoDチェックであり、2回目のSoDチェックはDefaultSODApprovalワークフローにより開始されます。
リクエスト・データセットの「ITリソース」フィールドが承認者専用に設定されている場合、その値はリクエストの作成時には設定されず、承認者のみが設定できます。SoDチェックでは、コネクタITリソースからSILトポロジ情報を取得します。そのため、リソースが選択されていない場合、SoDチェックはトリガーされません。この場合、どのレベルの承認の前にもSoDチェックは実行されず、承認者によるITリソース情報の提供後に、DefaultSODApprovalワークフローを使用してのみSoDチェックが実行されます。
承認者専用フィールドとDefaultSODApprovalワークフローによりリクエスト・プロビジョニングを行うには、次の手順を実行します。
発行されたリクエストは、リクエスト・レベル承認に直接送られます。この前にSoDチェックは行われません。承認者は、ITリソース情報を提供した後でリクエストを承認します。
DefaultSODApprovalワークフローによって、リクエストが承認の操作レベルに送られると、承認タスクがシステム管理者ロールに割り当てられます。管理者がこのタスクを承認すると、SoDチェックWebサービスが起動され、SoDチェックが開始されます。これは、リクエスト・ステータス(「SoDチェック結果が保留中です」である必要があります)をチェックすることにより確認できます。SoDチェック結果の取得(承認)スケジュール・ジョブを実行して、SoDチェックを完了する必要があります。
SoD管理者ロールに割り当てられる承認タスクが生成されます。このロールを持つすべてのユーザーが、タスクを要求して承認できます。
タスクを承認する前に、リクエストの詳細でSoDの結果を確認してください。タスクが承認されている場合、アカウント、権限またはその両方のプロビジョニングが続けられます。
ユーザーは、セルフ・サービスからリソースを要求するか、またはリソースを変更するためのリクエストを要求できます。SoDチェックの手順は、その他のリソース・プロビジョニングのユースケースと同様です。
アクセス・ポリシーに基づくプロビジョニングを行うには、次の手順を実行します。
新規ロールを作成します。
SoD対応リソースを新規ロールにプロビジョニングするためのアクセス・ポリシーを作成します。子フォームに権限を入力したことを確認します。
新しく作成したユーザーにこのロールを割り当てます。これにより、ターゲット・システムでアカウントがプロビジョニングされますが、権限のプロビジョニングはSoDチェックが実行されるまで行われません。
プロセス・フォームをチェックして、SoDCheckStatusフィールド値を確認します。SoDチェックが正常に開始されている場合、SoDCheckStatusフィールドの値は「SoDチェック結果が保留中です」になり、HolderタスクおよびSoDCheckerタスクが生成され、これらは「保留」ステータスになっています。
SoDチェック結果の取得(プロビジョニング)スケジュール済ジョブを実行して、SoDチェックを完了します。
SoDチェックに成功すると、HolderタスクおよびSoDCheckerタスクが完了し、権限がプロビジョニングされます。そうでない場合は、Holderタスクが取り消され、権限はプロビジョニングされません。
アクセス・ポリシーに基づくプロビジョニングを使用して権限を更新するには、次の手順を実行します。
新規ロールを作成します。
SoD対応リソースを新規ロールにプロビジョニングするためのアクセス・ポリシーを作成します。子フォームに権限を入力したことを確認します。
SoD対応リソースのプロビジョニングをすでに行っているユーザーにこのロールを割り当てます。アクセス・ポリシーでは、このアカウントの権限の更新のみを行います。
子プロセス・フォームの新規権限行をチェックします。親プロセス・フォームをチェックして、SoDCheckStatusフィールド値を確認します。SoDチェックが正常に開始されている場合、SoDCheckStatusフィールドの値は「SoDチェック結果が保留中です」になり、HolderタスクおよびSoDCheckerタスクが生成され、これらは「保留」ステータスになっています。
SoDチェック結果の取得(プロビジョニング)スケジュール済ジョブを実行して、SoDチェックを完了します。
SoDチェックに成功すると、HolderタスクおよびSoDCheckerタスクが完了し、権限がプロビジョニングされます。そうでない場合は、Holderタスクが取り消され、権限はプロビジョニングされません。
すべてのSoD関連イベントのロギングを有効にするには、次の手順を実行します。
テキスト・エディタで、DOMAIN_HOME/config/fmwconfig/servers/oim_server1/logging.xmlファイルを開きます。
<loggers>要素を見つけます。次にサンプルの<loggers>要素を示します。
<loggers> <logger name="" level="WARNING:1"> <handler name="odl-handler"/> <handler name="wls-domain"/> <handler name="console-handler"/> </logger>
ロギング・レベルを、INCIDENT_ERROR:1、ERROR:1、NOTIFICATION:1、NOTIFICATION:16、TRACE:1、TRACE:16またはTRACE:32に変更できます。デフォルト・ロギング・レベルでは、エラーおよび警告メッセージが出力されます。
表27-2に、SoDチェックの実行中にエラーが発生した場合に実行できるトラブルシューティング手順を示します。
表27-2 SoDチェックのトラブルシューティング
| 問題 | 解決策 |
|---|---|
|
プロセス・フォームのSoDCheckStatusフィールドに値が表示されないか、デフォルト値が表示されます。EBSコネクタのフィールドでは、 |
これは、SoD構成が正しくないことを意味します。XL.SoDCheckRequiredシステム・プロパティが デフォルトの登録が使用されている場合、topologyNameパラメータの値は |
|
プロセス・フォームまたはリクエスト・データセットのSoDCheckStatusフィールドに SoDCheckResultフィールドには |
SoD構成は正しいがSoDエンジンの接続情報が正しくない可能性があるか、SoDエンジンでエラーが発生しました。SoDエンジンのエラーは、次のような理由により発生することがあります。
SoDエンジン・ログで、その他のエラーがないかを確認します。SoDエンジンによりトラッキングIDが返されない場合、シミュレーションは正常に開始されていません。 |
|
プロセス・フォームのSoDCheckStatusフィールドが |
承認用のスケジュール済ジョブではなく、SoDチェック結果の取得(プロビジョニング)スケジュール済ジョブを実行していることを確認します。スケジュール済ジョブがトリガーされていることを確認します。デバッグ・レベルのロギングを有効化して、これを確認できます。 スケジュール済ジョブが実行されてもSoDチェックが完了しない場合は、SoDエンジンでエラーが発生しています。SoDエンジン・ログで詳細を確認してください。 |
|
SoD対応リソースを要求する際、リクエストを作成してもデータセットにSoDフィールドが表示されず、リクエストはリクエスト・レベル承認に直接送られます。 |
このエラーは、SoD構成が正しくないことを意味します。XL.SoDCheckRequiredシステム・プロパティが デフォルトの登録が使用されている場合、topologyNameパラメータの値は 登録が手動で行われている場合は、対応するトポロジがSILConfig.xmlファイルで定義されており、このファイルが変更後にMDSにシードされているかどうかを確認してください。 |
|
リクエスト・データセットのSoDCheckStatusフィールドが |
承認用のスケジュール済ジョブではなく、SoDチェック結果の取得(承認)スケジュール済ジョブを実行していることを確認します。スケジュール済ジョブがトリガーされていることを確認します。デバッグ・レベルのロギングを有効化して、これを確認できます。 スケジュール済ジョブが実行されてもSoDチェックが完了しない場合は、SoDエンジンでエラーが発生しています。SoDエンジン・ログで詳細を確認してください。 |
|
リクエスト・プロビジョニング中にSoDチェックが正常に実行されましたが、ユーザー・プロファイルのリソース状態に |
リソース履歴でプロセス・タスクを確認します。System Validationタスクのみが表示されている場合、必要なデータがこのフォームに保存されていない可能性があります。編集モードでフォームを開き、「保存」をクリックすると、手動でフォームを保存できる場合があります。以降のリクエストのために、プロセス定義で自動保存オプションを有効化してください。 ターゲット・システムでアカウントを作成するためのタスクなど、その他のタスクがリソース履歴に表示されている場合は、タスクの詳細をチェックして、ターゲット・システムのエラーがないかどうかを確認してください。たとえば、作成中のアカウントがターゲット・システムにすでに存在しています。 |
|
ダイレクト・プロビジョニング中にSoDチェックが正常に実行されましたが、ユーザー・プロファイルのリソース状態が「プロビジョニング済」ではありません。 |
リソース履歴でプロセス・タスクを確認します。System Validationタスクのみが表示されている場合、必要なデータがこのフォームに保存されていない可能性があります。これは、プロセス定義で自動保存オプションがオンになっている場合に発生することがあり、そのため、ダイレクト・プロビジョニング中にフォームが表示されません。編集モードでフォームを開き、「保存」をクリックすると、手動でフォームを保存できる場合があります。以降のリクエストのために、プロセス定義で自動保存オプションを無効化してください。 ターゲット・システムでアカウントを作成するためのタスクなど、その他のタスクがリソース履歴に表示されている場合は、タスクの詳細をチェックして、ターゲット・システムのエラーがないかどうかを確認してください。たとえば、作成中のアカウントがターゲット・システムにすでに存在しています。 |
|
リクエスト・プロビジョニングは正常に実行され、リクエスト・データセットに該当する値が表示されましたが、SoDステータスと結果がプロセス・フォームに反映されません。 |
プロセス・フォームでSoDフィールド・ラベルを確認してください。これらは、SoDCheckStatus、SoDCheckTrackingID、SoDCheckResult、SoDCheckTimestampおよびSoDCheckEntitlementViolationである必要があります。これらのフィールド・ラベルを変更すると、SoDフィールドがリクエスト・データセットからプロセス・フォームにマップされません。 |
|
特定のSoDリクエストが複数回試行され、エラーが生成されます。 |
SoD構成に問題があるか、特定のリクエストで発行されたデータにエラーがある可能性があります。SoD構成が正しいにもかかわらず、リクエストにエラーのトレースがあり、その特定のリクエストを無視するには、WebLogic管理コンソールからOIMSODQueueの「再配信の制限」を変更して、そのリクエストに関連するJMSメッセージが複数回試行されないようにできます。これを行うには、次の手順を実行します。
|
|
タスク割当てルールの評価にエラーがあります。ユーザーnullのタスク割当てルールの評価にエラーがあります。エラーは次のとおりです。「構成"{1}"の"{0}"の所有者を取得中のエラー。構成"jazn.com"の"SOD ADMINISTRATORS"の所有者を取得中にエラーが発生しました。グループ名が有効であり、所有者が関連付けられていることを確認してください。エラーを修正できない場合は、Oracleサポートに連絡してください。ユーザーnullに指定されたルールが有効であることを確認してください。」 |
このエラーは無視してください。このエラーの原因は、OIMDBProviderではロールの所有者の取得がサポートされていないことです。そのため、SOAではこのエラーがログに記録されます。 |
|
DefaultSODApprovalワークフローを使用してSoDチェックを実行しようとすると、次のエラー・メッセージが表示されます。 Unknown Credential type to find the password for the given map : oim key : sodcheck.credentials |
「SoDの有効化」の手順5の説明に従って、 |
|
次のエラーが表示されます。 [exec] Caused By: Thor.API.Exceptions.tcITResourceNotFoundException [exec] at com.thortech.xl.ejb.beansimpl.tcITResourceInstanceOperationsBean.getITResourceInstanceParametersData |
SoDエンジンITリソースが作成されていません。そのため、使用するSoDエンジンに応じたITリソースを作成する必要があります。たとえば、OAACGの場合はOAACG-ITResを作成します。 |
|
OAACGとOIAなど、複数のSoDエンジンに対してSoDが有効化されている場合に、OIAを使用してSoDチェックを開始しようとすると、OAACGファイルからエラーがログに記録されることがあります。 |
この問題は、SILConfig.xmlファイル内のトポロジ・エントリが正しくない場合に発生します。これらのエントリを確認するには、MDSからSILConfig.xmlファイルをエクスポートします。デフォルト・プロバイダの場合、SILConfig.xmlファイルにはトポロジ名に対応するSIL登録IDが含まれています。SILConfig.xmlのIDと、SIL登録スクリプトから返されるIDは同じである必要があります。たとえば、SILConfig.xmlに含まれるsodoiaトポロジのIDは次のようになります。 <IdmId>1</IdmId> <SodId>7</SodId> <SDSId>6</SDSId> この場合、登録スクリプトにより返されるIDは次のようになります。 1 oimInstance 6 oimSDSInstance 7 oiaInstance これらが異なる場合、SILConfig.xmlファイルでIDを変更し、MDSユーティリティを使用してファイルを再インポートしてください。 |
