| Oracle® Fusion Middleware Oracle Identity Manager開発者ガイド 11g リリース2 (11.1.2.2.0) B69536-07 |
|
 前 |
 次 |
職務の分離(SoD)の概念は、ビジネス・プロセスにチェック・アンド・バランスを適用することを目的としています。ビジネス・プロセスの各段階では、複数の個人の関与が必要になる場合があります。組織では、ユーザー・プロビジョニング・ソリューションの一部としてSoDを実装することにより、こうした状況をIT対応のビジネス・プロセスの要件に変換できます。SoDの全体的な利点は、組織のリソースが意図的または偶発的に悪用されることにより生じるリスクを軽減できる点です。
この章では、次の各項で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エンジンは、権限データの同期化が有効になるように相互に通信します。図22-1に、SoD検証プロセスにおけるデータ・フローを示します。
SoD起動ライブラリ(SIL)は、Oracle Identity ManagerでのSoD実装の基礎となります。SILはJavaベースのアダプタの集合で、事前に定義されたOracle Identity Managerコネクタとの統合を可能にします。その結果、コネクタは、Oracle Identity Managerをターゲット・システムと結び付けます。次のOracle Identity Managerコネクタが、SoD検証用に事前にアダプタに構成されています。
SAP User Managementリリース9.1.2.5以上
|
注意: SAP UM 9.1.2.5の場合、Oracle Identity Manager 11gリリース2 (11.1.2.2.0)で権限のリクエストが機能しません。 |
SILは、SILとSoDエンジンを統合する専用アダプタの基礎の役割も果たします。これらのアダプタは、SILプロバイダと呼ばれます。SILプロバイダは、SILと特定のSoDエンジンとのインタフェースの機能を果たします。次のSoDエンジン用に事前に定義されたSILプロバイダがあります。
SAP Governance, Risk and Compliance Access Control (GRC AC)
このターゲット・システムのAccess Risk Analysis機能またはAccess Request Management機能を構成および使用する場合は、次のいずれかをインストールしてください。
SAP NetWeaver AS JAVA 7.00サポートパック14で実行されているSAP BusinessObjects Access Control 5.3
VIRACLP 530_700_19、VIRAE 530_700_19、VIRCC 530_700_19、VIRFF 530_700_19およびVIRRE 530_700_19コンポーネントをインストールします。
ECC 6.0をRTAコンポーネントVIRSAHR SP 10およびVIRSANH SP 10とともに使用します。
|
注意: 他のSAPアプリケーションを使用する場合、SAPアプリケーションと互換性のあるRTAコンポーネントをインストールする必要があります。 |
SAP NetWeaver AS ABAP 7.02サポートパック7で実行されているSAP BusinessObjects Access Control 10
GRCFND_A SP 10コンポーネントをインストールします。
ECC 6.0をRTAコンポーネントGRCPIERP SP 9とともに使用します。
|
注意: 他のSAPアプリケーションを使用する場合、SAPアプリケーションと互換性のあるRTAコンポーネントをインストールする必要があります。 |
Oracle Application Access Controls Governor (OAACG)リリース8.6.4用SILプロバイダ
このプロバイダは、OAACG SILプロバイダとしても知られています。
|
注意: Oracle Identity ManagerでSoDの実装および使用を開始する前に、OAACGの最新のパッチ・セットをインストールしてください。詳細は、Oracleサポートに連絡してください。 |
Oracle Identity Analytics (OIA) 11gリリース1パッチ・セット1バンドル・パッチ2 (11.1.1.5.2)用SILプロバイダ
このプロバイダは、OIA SILプロバイダとしても知られています。
|
注意: OIAの現行バージョンは、次のURLに移動してパッチ13641335を検索することによってMy Oracle Support Webサイトからダウンロードできます。 |
図22-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 User Managementリリース9.1.2.5以上
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登録プロセスを実行する必要があります。詳細は、第22.10項「ターゲット・システムおよびSoDエンジンのカスタムの組合せ」を参照してください。
ターゲット・システムからSoDエンジンに権限データをインポートする必要があります。必要に応じて、SoDエンジンでSoD検証ルールも構成します。次の各項では、事前に構成されたSoDエンジンに対するこれらの手順を説明します。
Oracle Application Access Controls Governor (OAACG)の構成には、次の手順が必要です。
Oracle Application Access Controls Governorのインストール
OAACG 8.6.4.5259はOracle Identity Manager 11gリリース2 (11.1.2.2.0)でサポートされています。OAACG 8.6.4.5259は、直接インストールできます。既存のOAACG 8.6.3 GAインストールがある場合は、8.6.4.5259にアップグレードできます。
8.6.3 GAから8.6.4.5259にアップグレードするには、次の手順を実行します。
My Oracle Supportにログインします。
「パッチと更新版」タブをクリックします。
「拡張検索」をクリックします。
「製品ファミリ」で「Oracle Application Access Controls Governor」を選択し、リリースとしてAACG 8.6.4を選択します。適切なプラットフォームを選択し、「検索」をクリックします。次のパッチおよびその他の最新のパッチが表示されます。
14528065 - ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.4.3347
14786771 - ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.4.4240
16178807 - ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.4.5259
手順4に示されているパッチをダウンロードします。次の順序でアップグレードを実行します。
8.6.3から8.6.4.3347から8.6.4.4240から8.6.4.5259
OAACGインストレーション・ガイドを参照して、OAACGのアップグレードまたはインストールを実行します。
デプロイメントごとに、アクティブなデータ・ソースに対してAccess ETLを再実行します。
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の構成には、次の手順が必要です。
|
注意: Oracle Identity Analytics 11.1.1.5.0パッチ・セット2は、Oracle Identity Manager 11gリリース2 (11.1.2.2.0)で動作することが保証されています。 |
SoD処理用のOracle Identity Analyticsアカウントの作成
Oracle Identity Analyticsでアカウントを作成し、それをSoD検証処理用にSRM管理ロールに割り当てます。「SoDエンジンの情報を保持するためのITリソースの作成」で説明されている手順の実行中に、このアカウントのユーザー名およびパスワードを指定します。
アカウント作成の詳細は、Oracle Identity Analyticsのドキュメントを参照してください。
Oracle Identity Analytics 11.1.1.5.2は、競合の原因となった権限に関する情報を提供します。この情報は、SoDの詳細の下に表示されます。SoDの詳細の下では、権限がエンコードされた形式(たとえば、4~695~24123)で表示されます。これは、その方法でポリシーがOIA上に作成されているためです。
|
注意: ユーザー名がrbacxadminの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機能を有効にするには、次の手順を実行します。
「職務の分離(SOD)チェックは必須です」システム・プロパティを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リソースを編集します。
|
注意: OAACG 8.5以上と構成するには、このITリソースにsodServerURLという名前とhttp(s)://HOST_NAME:PORT/URIという値を持つ新しいフィールドを追加します(この場合、URLはgrcc/services/GrccServiceになります)。OAACG8.2.1の場合、URLの値はags/services/AGServiceになります。 |
ダイレクト・プロビジョニングおよびアクセス・ポリシー・ベースのプロビジョニングでのSoDの有効化:
SoDは、HolderおよびSODCheckerタスクがプロビジョニング・ワークフロー内に存在する場合にのみ有効にできます。
リクエスト・プロビジョニングでのSoDの有効化:
手順1および2により承認中のデフォルトのSoDチェックが有効になります。デフォルトのSoDチェックは、承認される前に実行されます。1つの承認レベルの後でSoDチェックが必要になった場合、デフォルトのSoDチェック承認ワークフローであるDefaultSODApprovalが、承認ポリシーの作成によりアタッチされる必要があります。SoDチェックは、任意の承認ワークフローでオンデマンドで実行することもできます。これは、BPELからSoDチェックWebサービスをコールすることによって行うことができます。詳細は、「SoD用の承認ワークフローの変更」を参照してください。
|
注意: DefaultSODApprovalワークフローは、2つの承認タスクで構成されています。ワークフローがトリガーされたときに、承認タスクが生成されてシステム管理者に割り当てられ、次にSoDチェックが実行されます。再度、承認タスクが生成されて、再度、システム管理者ロールに割り当てられます。システム管理者ロールのメンバーであればどのユーザーでも、SoDチェック結果を表示した後、2番目の承認タスクを承認できます。 |
SoDチェックのCSF資格証明の追加:
Enterprise Managerにログインし、左側のタブで「WebLogicドメイン」を開きます。
OIM_DOMAINを開きます。
右側のペインの上部で、「WebLogicドメイン」リストから「セキュリティ」を選択し、「資格証明」を開きます。
「キーの作成」オプションを選択してから、マップ'oim'を選択します。
キーをsodcheck.credentialsとして指定し、「タイプ」を「パスワード」として指定します。
「ユーザー名」をoiminternalとして指定し、パスワードを「未使用」として指定します。「OK」をクリックして、キーを保存します。
SoDは次のいずれかを実行して無効にできます。
「職務の分離(SOD)チェックは必須です」システム・プロパティをfalseに設定します。
コネクタITリソースのtopologyNameパラメータの値をNoneに設定し、SoDチェックが実行されないようにします。または、このパラメータを削除して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がtrueに設定されていることを前提とします。 |
次のようにして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_SERVER」に移動します。「SSLリスニング・ポート」が有効になっています。
Enterprise ManagerのMBeanブラウザでoimFrontEndURLを変更します。これを行うには、次の手順を実行します。
Enterprise Managerにログインします。
「OIM_SERVER」に移動します。
ペインの上部にあるリストから、システム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)の1つを使用しない場合のみ実行してください。この項の内容は次のとおりです。
SoD用の承認ワークフローを変更するには、次の手順を実行します。
|
注意: フォームは、コネクタ・プロセス・フォームに基づいてUIで作成されます。リクエスト・データセットは、Oracle Identity Managerでは必要なくなりました。 |
コネクタのITリソースで、まだ存在しない場合はTopologyNameパラメータを作成します。図22-3に、このパラメータが追加されたサンプルのITリソースを示します。
コネクタITリソースでSoDチェック・プロパティがtrueに設定され、topologyNameパラメータが適切な値に設定されている場合、承認ワークフローの前処理ステージでデフォルトのSoDチェックが実行されます。リクエストが作成された後、リクエスト・ステータスが、非同期SoDチェックの場合は「SoDチェック結果が保留中です」、同期SoDチェックの場合は「SoDチェックが完了しました」ステータスになります。非同期SoDチェックの場合、SoDチェックを完了するにはSoDチェック結果の取得(承認)スケジュール済ジョブが実行されている必要があります。
|
注意: SoDチェックの実行中にエラーが発生した場合は、リクエスト・フォーム内の「SoDチェックのステータス」属性が「SoDチェックがエラーで完了しました」に設定され、リクエストが承認に送られます。SoDチェックが正常に実行されていなくてもリクエストを承認するかどうかについての最終的な決定は、承認者が下します。 |
あらゆるレベルの承認の前にデフォルトでトリガーされるSoDチェックに加え、事前定義されたDefaultSODApprovalワークフローをアタッチすることによってもSoDチェックをトリガーできます。ワークフローを承認の操作レベルにアタッチするには、承認ポリシーを作成します。
|
注意: Oracle Identity Manager 11gでは、SoDワークフローが機能するためにはSOAおよびWebLogic Serverにパッチが必要でした。現在、Oracle Identity Managerにパッチは必要ありません。 |
デフォルト・ワークフローの使用の詳細は、「承認ポリシーを使用したワークフローの適用」を参照してください。このワークフローには、システム管理者に割り当てられる承認タスクが含まれています。この承認タスクの後で、SoDチェック結果を戻すために、SoDCheck Webサービスがコールされます。図22-4に、SoDCheck Webサービス・コールを含むワークフローを示します。
|
注意: すべてのリクエストには、リクエスト・レベル承認および操作レベル承認の、2つの承認レベルがあります。DefaultSODApprovalワークフローをアタッチできるのは、承認レベルのみです。バルク・リクエストでは、すべてのアプリケーション・インスタンスおよびユーザーに対して、リクエスト・レベル承認が共通です。このレベルの承認後、アプリケーション・インスタンスとユーザーの組合せごとに個別のリクエストが作成されます。ワークフローでは、アプリケーション・インスタンスとユーザーごとに、個別にSoDチェックが実行されます。ワークフローは、リクエスト・レベル承認の後でSoDチェックが必要な場合に役立ちます。一例として、承認者によりコネクタITリソース情報が入力される場合があります。 承認のみのフィールドは、Oracle Identity Manager 11gリリース2 (11.1.2.2.0)でサポートされていません。 |
この後、承認タスクを含むswitch caseがシステム管理者ロールに割り当てられます。このロールを持つすべてのユーザーは、タスクを要求して承認できます。図22-5に示すように、switchは、SoDチェックの結果が成功か失敗かに基づきます。
図22-6に、承認タスクの割当てを示します。
承認ワークフローは、Oracle Identity Manager 11gリリース2 (11.1.2.2.0)で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サービスをコールするように、このワークフローを変更できます。図22-7に、人による承認後にSoDチェックを実行するように変更された、デフォルト・ワークフローを示します。
OIM_HOME/workflows/composites/DefaultSODApproval.zipを解凍し、SodCheckServicePortImplService.wsdlを解凍されたディレクトリからOIM_HOME/workflows/ process-template/APPLICATION_NAME/PROJECT_NAME/にコピーします。SODCheckService1などのWebサービスをcomposite.xmlに追加し、asyncsod.wsdlをWSDLファイルとして提供します。SoDCheckパートナ・リンクは、図22-8のようになります。
|
注意: BPELは、パートナ・リンクを介してすべての外部エンティティに接続します。 |
ApprovalProcess.bpel設計に、次のBPELアクティビティを含めます。
ASSIGN: assignアクティビティは、SoDチェックWebサービスをコールする前に追加する必要があります。このアクティビティにより、Webサービスをコールするために必要なパラメータが初期化されます。assignアクティビティを作成するには、次の手順を実行します。
i) JDeveloperで開いたBPELプロセスにアクティビティをドラッグ・アンド・ドロップします。
ii) アクティビティが作成されたら、アクティビティをダブルクリックし、「コピー・ルール」タブをクリックします。
iii) 「追加」をクリックして「コピー操作」を選択します。表22-1に示すように、変数の値を指定します。
表22-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アクティビティで定義された変数です。 |
次の各図に、追加される値を示します。
図22-9に、最終的なassignアクティビティを示します。
INVOKE: このアクティビティの詳細は次のとおりです。
相互作用タイプ: Partnerlink
パートナ・リンク: SODCheckService
操作: Initiate
入力変数: SODInvoke_initiate_InputVariable
図22-10に、フィールドにサンプル値が入力された「Invoke」ダイアログ・ボックスを示します。
RECEIVE: このアクティビティの詳細は次のとおりです。
相互作用タイプ: Partnerlink
パートナ・リンク: SODCheckService1
操作: Result
変数: SODResultReceive_result_InputVariable
図22-11に、フィールドにサンプル値が入力された「Receive」ダイアログ・ボックスを示します。
SWITCH: このアクティビティは、SODCheckの結果に基づいてワークフローをスイッチするためのものです。switch caseは、図22-12のようになります。
新規ヒューマン・タスク: 新規ヒューマン・タスクを作成して、システム管理者以外の承認者に割り当てることができます。新規承認タスクは、ワークフローにすでに存在する古いものと同じですが、承認者が異なります。このヒューマン・タスクはswitch caseで使用されます。たとえば、SoDチェックが成功した場合に、承認タスクをロールに割り当てることができます。SoDチェックが失敗した場合は、承認タスクをシステム管理者ロールに割り当てることができます。DefaultSODApprovalでは常に、承認タスクをシステム管理者ロールに割り当てます。
|
注意: SoDCheck Webサービスは複数回コールできます。 |
AsyncSoD WebサービスのリクエストとコールバックのためのSAMLポリシーの適用:
Security Assertion Markup Language (SAML)に基づいたメッセージ保護ポリシー付きOWSM SAMLトークンは、SOAコンポジットからOracle Identity ManagerへのSoDチェックの非同期コールにおいて、メッセージ保護のセキュリティ・ポリシーとして使用されます。非同期SoDチェックWebサービスでは、この項で説明するように、リクエストのためのメッセージ保護クライアント・ポリシー付きSAMLトークンおよびコールバックのためのメッセージ保護サービス・ポリシー付きSAMLトークンを使用する必要があります。
リクエストのためのメッセージ保護クライアント・ポリシー付きSAMLトークンを適用するには、次の手順を実行します。
i) 図22-13に示すように、AsynchSoD Webサービスを右クリックし、「WSポリシーの構成」を選択して、「リクエスト対象」を選択します。
ii) 「SOA WSポリシーの構成」ダイアログ・ボックスの「セキュリティ」セクションで、正符号(+)のアイコンをクリックしてセキュリティ・ポリシーを追加します。
iii) 図22-14に示すように、クライアント・セキュリティ・ポリシーの選択ダイアログ・ボックスで「wss11_saml _token_with_message_protection_client_policy」を選択し、「OK」をクリックします。
コールバックのためのメッセージ保護サービス・ポリシー付きSAMLまたはユーザー名トークンを適用するには、次の手順を実行します。
i) AsynchSoD Webサービスを右クリックし、「WSポリシーの構成」を選択して、「コールバック対象」を選択します。
ii) 「SOA WSポリシーの構成」ダイアログ・ボックスの「セキュリティ」セクションで、正符号(+)のアイコンをクリックしてセキュリティ・ポリシーを追加します。
iii) 図22-15に示すように、サーバー・セキュリティ・ポリシーの選択ダイアログ・ボックスで「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サーバーを再起動します。
承認ポリシーを使用したワークフローの適用
SoDワークフローを適用するリクエスト・モデル用の承認ポリシーを作成します。たとえば、アプリケーション・インスタンスのプロビジョニング中にSoDチェックを実行する場合は、Provision Application Instanceリクエスト・モデル用のポリシーを作成します。承認ポリシーの作成の詳細は、『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違反があることを示します。
注意: 競合する権限を持つEBS 9.1.0.7.0リソースのリクエスト・プロビジョニングについては、プロセス・フォームのSodCheckViolationフィールドは更新されません。権限の違反は、SoDCheckEntitlementViolationラベルが付いたフィールドにマップされますが、EBSリソースにあるのは、SoDCheckViolationラベルが付いたフィールドです。したがって、マッピングは行われません。ダイレクト・プロビジョニングおよびアクセス・ポリシーを介したプロビジョニングが、SoDCheckViolationフィールド・ラベルで正常に行われます。リクエスト・プロビジョニングについてこの問題を回避するには、Design Consoleを使用して、EBSフォームのSoDCheckViolationフィールド・ラベルをSoDCheckEntitlementViolationに変更します。 注意: 値がSoDCheckEntitlementViolationの場合は、リクエスト、直接、アクセス・ポリシーなどあらゆるタイプのプロビジョニングが正常に行われます。したがって、値を変更せずに、SoDCheckEntitlementViolationとして値を保持できます。 |
| SODCheckNotInitiated | C | Oracle Identity ManagerでSoDが有効になっていないため、SoD検証プロセスは開始されていません。 |
次の図に、これらのレスポンス・コードを示します。
子プロセス・フォーム表では、異なるタイプの複数値データ(ロール・データ、プロファイル・データおよびアドレス情報など)を保持できます。SoD処理に使用する権限データを保持している子プロセス・フォーム表をマークする必要があります。詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』の子プロセス・フォームでの権限属性のマークに関する説明を参照してください。
この項には次のトピックが含まれます:
|
注意: この項で説明する手順は、Oracle E-Business Suiteおよび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リリース2 (11.1.2.2.0)では、オブジェクト・フォームは承認プロセス内のリクエスト・データセットに置き換えられています。そのため、権限データがオブジェクト・フォームではなくリクエスト・データセットから読み取られるように、変換レイヤーを変更する必要があります。
変換レイヤーでは、リクエスト・モデルもチェックする必要があります。リクエスト・モデルがリソースのプロビジョニングである場合、データはリクエスト・データセットからのみ読み取る必要があります。一方、リクエスト・モデルがプロビジョニング済リソースの変更である場合は、データはリクエスト・データセットとプロセス・フォームの両方から読み取る必要があります。
変換サービス・コンポーネントは、次のようにデプロイされます。
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エンジンおよびターゲット・システムの登録情報を指定するには、次の手順を実行します。
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 [Enter the Context Factory:]CONTEXT_FACTORY
次の項目に対して有効な値を指定します。
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、OIM SDSおよびOIAインスタンスに対して同様の手順に従います。この後で、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に再びインポートします。
例22-1に、登録スクリプトの実行例の出力を示します。ここでは、SoDエンジンの情報を指定するためにITリソースが作成されているものと仮定します。
例22-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 oiminstance 1 EBS ebsinstacne 2 SAP sapinstance 3 OAACG oaacginstance 4
これらのインスタンス名を参照のためにコピーします。
|
注意: この項で説明する手順は、Oracle Application Access Controls GovernorおよびSAP GRC以外のSoDエンジンを使用する場合にのみ実行します。Oracle E-Business Suiteおよび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リソースの作成の詳細は、第4章「アプリケーション・インスタンスの開発」を参照してください。ITリソース・タイプおよびITリソースには任意の名前を指定できます。次の表は、ITリソースに含める必要のあるパラメータの名前を示しています。
| パラメータ | 説明 | サンプル値 |
|---|---|---|
| Source Datastore Name | SoDエンジンで定義したソース・データ・ストア(ターゲット・システム)の名前を入力します。
ソース・データ・ストア名は、「Oracle Application Access Controls Governorの構成」の項で説明されている手順の実行中に指定します。 |
EBS STMD122 |
| dbuser | SoDエンジンで使用されるデータベース上のスキーマ所有者のユーザー名を入力します。
このアカウントは、SoD処理中にApplication Access Controls Governorデータベースへのアクセスに使用されます。 注意: このパラメータは、Oracle Application Access Controls Governor固有のものです。 |
databaseusr1 |
| dbpassword | SoDエンジンで使用されるデータベース上のスキーマ所有者のパスワードを入力します。
注意: このパラメータは、Oracle Application Access Controls Governor固有のものです。 |
Cryp100ne |
| jdbcURL | SoDエンジンで使用されるデータベースに接続するためのJDBC URLを入力します。
注意: このパラメータは、Oracle Application Access Controls Governor固有のものです。 |
jdbc:oracle:thin:@10.123.123.123 |
| password | APIコール用にSoDエンジンで作成されたアカウントのパスワードを入力します。 | K1rb1r0s |
| port | SoDエンジンがリスニングを行うポートの番号を入力します。 | 8090 |
| server | SoDエンジンが稼働しているホスト・コンピュータのIPアドレスを入力します。 | 10.231.231.231 |
| sslEnable | SoDエンジンでHTTPS通信リクエストのみを受け入れる場合、trueを入力します。それ以外の場合はfalseを入力します。 |
false |
| username | SoDエンジンで作成されたアカウントのユーザー名を入力します。このアカウントは、SoD検証中に使用されるSoDエンジンAPIのコールのために使用されます。 | jdoe |
| sodServerURL | SoDサーバーのURLを次の形式で入力します。
http(s)://HOST_NAME:PORT_NUMBER/URL |
http://10.231.231.231:8090/grcc/services/GrccService |
|
注意: 複数の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チェックは、有効化されている場合に実行されます。この手順の例では、ユーザーにAudit Reviewerロールがすでに割り当てられていることを前提としています。
次のステップを実行します。
ユーザーとしてOracle Identity Self Serviceにログインします。
「プロファイル」の下で、「マイ・アクセス」をクリックします。「ロール」タブをクリックしてから、「ロールのリクエスト」をクリックします。リクエストするロールを検索できる「カタログ」ページが表示されます。
Asset Management Teamなど、ユーザーに割り当てる特定のロールを検索します。
「カートに追加」をクリックします。これによって、カートに1つの項目が表示されます。次に、「チェックアウト」をクリックします。
「送信」をクリックして、ロールのリクエストを送信します。リクエストが作成されます。
「リクエスト」→「リクエストのトラッキング」に移動します。
作成したリクエストを検索します。リクエストを開いて、SoDチェック結果を表示します。「SODステータス」列に「SoDチェックが完了しました」と表示されている必要があります。
次の図に示すように、「SODステータス」をクリックしてSoDチェック結果を確認します。
SoD Check結果が「失敗」になっているのは、リクエストを要求したAsset Management Teamロールとユーザーがすでに持っているAudit Reviewerロールが競合しているためです。
SoDチェック結果は、リクエスト・レベル承認の前に使用できます。この場合、SoDチェックに失敗しましたが、管理者は競合するロールをユーザーに割り当てるリクエストを承認できます。
この手順では、削除されるロールがユーザーにすでに割り当てられていることを前提としています。
次のステップを実行します。
ユーザーとしてOracle Identity Self Serviceにログインします。
「プロファイル」→「マイ・アクセス」に移動し、「ロール」タブをクリックします。ユーザーに割り当てたロールが表示されます。
削除するロールを選択して、「ロールの削除」をクリックします。「ロールの削除」ページが表示され、選択したロールがカート項目として表示されます。
「送信」をクリックします。リクエストが作成されます。
次の図に示すように、リクエストの詳細を開いてSoDチェック結果を確認できます。
競合するロールが削除されたため、SoDチェック結果が「成功」になりました。
この手順により、システム管理者はユーザーにロールを割り当てることができます。
システム管理者としてOracle Identity Self Serviceにログインします。
「管理」→「ユーザー」に移動し、選択したユーザーの詳細を開きます。
「ロール」タブをクリックしてから、「ロールのリクエスト」をクリックします。「カタログ」ページが表示されます。
Asset Management TeamロールとAudit Reviewerロールを検索し、それらをカートに追加します。「チェックアウト」をクリックします。追加したロールが含まれた「カート詳細」が表示されます。
「送信」をクリックします。リクエストが作成されます。これはバルク・リクエストのため、これに対するSoDチェックは開始されません。
Oracle Identity Self Serviceにシステム管理者としてログインし、「受信ボックス」→「保留中の承認」に移動し、リクエストを承認します。2つの子リクエストが作成され、それぞれの子リクエストに対してSoDチェックが実行されます。
「リクエストのトラッキング」に移動し、それぞれの子リクエストを開いてSoDの詳細を確認します。次の図は、Audit Reviewerロールに対して作成されたリクエストのSoDの詳細を示しています。
次の図は、Asset Management Teamロールに対して作成されたリクエストのSoDの詳細を示しています。
この手順により、システム管理者はユーザーからロールを削除できます。
システム管理者としてOracle Identity Self Serviceにログインします。
「管理」→「ユーザー」に移動し、選択したユーザーの詳細を開きます。
「ロール」タブをクリックして、削除するロールを選択し、「ロールの削除」をクリックします。
|
注意: 複数のロールを削除するためにリクエストが作成されます。単一のロールの場合はリクエストが作成されないため、SoDチェックは実行されません。 |
「ロールの削除」ページで、「送信」をクリックします。リクエストが作成されます。
リクエストを承認します。2つのリクエストが作成され、それぞれのリクエストに対してSoDチェックが実行されます。次の図は、Audit Reviewerロールに対して作成されたリクエストのSoDチェック結果を示しています。
次の図は、Asset Management Teamロールに対して作成されたリクエストのSoDチェック結果を示しています。
システム管理者によってリクエストが要求され、SoDの競合もないため、両方の子リクエストがデフォルトで承認されます。
|
注意: デフォルトでは、競合が検出されたためにSoDチェック結果が「失敗」となった場合にのみ、システム管理者が要求したリクエストに対して操作レベル承認がトリガーされます。 |
この項では、SoDに関連する様々なユースケースについて説明します。
|
注意: この項の手順は、OAACGなどの同期SoDエンジン用であり、同期SoDエンジンでSoDチェックを完了するには、スケジュール済ジョブを実行する必要はありません。 |
システム管理者としてアプリケーション・インスタンスをプロビジョニングするには、次の手順を実行します。
ターゲット・システムにアカウントを作成するユーザーを作成します。
「ユーザーの詳細」ページで「アカウント」タブをクリックし、「アカウントのリクエスト」をクリックします。「カタログ」ページが表示されます。
EBSなど、アプリケーション・インスタンスを検索します。
アプリケーション・インスタンスをカートに追加し、チェックアウトします。
アプリケーション・インスタンスに追加されたフォームが、「カート詳細」ページに表示されます。このフォームには、デフォルトのSoDチェック・フィールド(SoDCheckStatus、SoDCheckTrackingID、SoDCheckResult、SoDCheckTimestamp、SoDCheckEntitlementViolationなど)が含まれます。これらのフィールドには、SoDチェックの値が移入されます。
フォームで必要な詳細を指定します。子フォームに権限を入力したことを確認します。入力されていない場合、SoDは競合する権限をチェックするためにのみ必要なため、SoDチェックは実行されません。
「送信準備ができています」をクリックして、リクエストを送信します。これは単一のアプリケーション・インスタンスの単一のユーザーに対するリクエストのため、リクエストは作成されず、アプリケーション・インスタンスはユーザーに直接割り当てられます。
同期SoDチェックが行われたため、「アカウントの詳細」ページでSoDチェック結果を確認できます。競合する権限を選択した場合、SoDチェックは失敗し、ターゲット・システムで権限はプロビジョニングされません。図22-16は、SoDチェック結果を示しています。
リソース履歴を開くと、Holderタスクが「取消」の状態で表示されますが、これはSoDチェックの結果、競合があったためです。また、SoDCheckerタスクは「完了」の状態ですが、これはSoDチェックが完了したことを示します。図22-17は、リソース・プロビジョニングの詳細を示しています。
アプリケーション・インスタンスをプロビジョニングする手順がビューア管理ロールを持つユーザーによって実行された場合は、リクエストが作成されます。SoDチェック結果がこのリクエストに表示されます。承認者には、SoDチェック結果を確認した後にリクエストを承認または却下する権限があります。図22-18は、リクエストの詳細内のSoDチェック結果を示しています。
ユーザーの詳細を開いてプロビジョニング済のアカウントを選択し、子フォームで権限の追加、更新または削除を行うことによってこのアカウントを変更しようとすると、常にSoDチェックがトリガーされます。この操作がシステム管理者によって実行された場合は、新しいHolderタスクとSoDCheckerタスクが生成されます。新しい権限が古い権限と競合する場合、新しい権限はプロビジョニングされません。そうでない場合は、新しい権限がターゲット・システムでプロビジョニングされます。
ビュー管理ロールを持つユーザーによって操作が実行された場合、アプリケーション・インスタンスを変更するための新しいリクエストが作成されます。SoDチェック結果がこのリクエストに表示されます。
権限は、Oracle Identity Managerの第1レベルのエンティティです。そのため、権限は次のように直接リクエストできます。
システム管理者がユーザーの単一の権限をリクエストする場合: SoDチェックが実行され、権限が既存の権限と競合しない場合は、ユーザーにその権限が付与されます。SoDチェック結果は、「アカウントの詳細」ページに表示されます。SoDチェックを実行するためにHolderタスクとSoDCheckerタスクが作成されます。
システム管理者が複数の権限をリクエストする場合: バルク操作に対して、リクエストが作成されます。そのため、システム管理者が2つの権限をリクエストした場合は、リクエストr1が作成されます。SoDチェックは常に子リクエスト・レベルで実行されるため、r1に対してSoDチェックは実行されません。r1に対してリクエスト・レベル承認が取得された後、2つの子リクエストr2およびr3が作成されます。両方の子リクエストに対してSoDチェックが実行されます。結果は、「リクエストの詳細」に表示されます。
ユーザーが単一の権限をリクエストする場合: この場合、ユーザーは権限を直接取得できないため、リクエストが作成されます。承認者がこれを承認する必要があります。リクエストに対してSoDチェックが実行されます。HolderタスクおよびSODCheckerタスクは作成されません。
権限の失効のユースケースは、「ユーザーへの権限のプロビジョニング」で説明されている権限のプロビジョニングと同様です。ユーザーから最後の権限が失効されると、ユーザーに権限がないため、SoDチェックは実行されません。
Oracle Identity Managerでは、権限とともにロールをリクエストできる異種リクエストがサポートされています。これを行うには、「カタログ」ページを開いて必要なエンティティを検索し、エンティティを選択して送信します。これによってリクエストが作成されます。このリクエストが承認されると、リクエストされたエンティティに対して子リクエストが作成されます。それぞれの子リクエストに対してSoDチェックが実行されます。ロールおよび権限が、個別のSoDチェック用に送信されます。
|
注意: SoDチェックの競合は、ロールとターゲット・システムの権限間では検出されません。この2つに対してリクエストが要求された場合は、個別のSoDチェックが実行されます。 |
これは、「ロールおよび権限のリクエスト」で説明されているロールおよび権限のリクエストに類似しています。アプリケーション・インスタンスとロールに対して個別のSoDチェックが実行されます。
承認ポリシーを使用してDefaultSODApprovalワークフローが指定されている場合は、リクエスト・プロビジョニングのための次の手順を実行します。
操作レベルでDefaultSODApprovalワークフローを指定します。つまり、承認の操作レベルより前の手順は同じままです。
DefaultSODApprovalワークフローによって、リクエストが承認の操作レベルに送られると、承認タスクがシステム管理者ロールに割り当てられます。管理者がこのタスクを承認すると、SoDチェックWebサービスがロードされ、SoDチェックが開始されます。
これは、リクエスト・ステータス(「SoDチェックが完了しました」である必要があります)をチェックすることにより確認できます。
システム管理者に再度割り当てられる承認タスクが生成されます。
タスクを承認する前に、リクエストの詳細でSoDチェックの結果を確認してください。タスクが承認されている場合、アカウント、権限またはその両方のプロビジョニングが続けられます。
このユースケースでは、SoDチェックは2回実行されます。1回目はあらゆるレベルの承認の前に行われるデフォルトのSoDチェックであり、2回目のSoDチェックはDefaultSODApprovalワークフローにより開始されます。
エンドユーザーがロールをリクエストし、これが複数のロールに対するリクエストである場合は、ロールに対してSoDチェックが最初に実行されます。リクエストが承認されてユーザーにロールが割り当てられた後、ユーザー・ポリシーの評価スケジュール・ジョブを実行してアクセス・ポリシーを評価します。その後、アカウントのプロビジョニングがトリガーされます。これによって、再度、プロビジョニングされているアカウントに対するSoDチェックが実行されます(子データがリクエストされた場合)。SoDチェック結果は、「アカウントの詳細」ページに表示されます。アカウントが子データなしでプロビジョニングされる場合、SoDチェックは実行されません。
|
注意: ユーザー・ポリシーの評価スケジュール・ジョブの詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』の事前定義済のスケジュール済タスクに関する説明を参照してください。 |
アクセス・ポリシーに基づくプロビジョニングを行うには、次の手順を実行します。
新規ロールを作成します。
アクセス・ポリシー(承認なし)を作成し、新規ロールに対してSoD対応リソースをプロビジョニングします。子フォームに権限を入力したことを確認します。
新しく作成したユーザーにこのロールを割り当てます。ユーザー・ポリシーの評価スケジュール済ジョブを実行してアクセス・ポリシーをトリガーし、ターゲット・システムでアカウントをプロビジョニングします。ただし、権限のプロビジョニングはSoDチェック後に行われます。
「アカウントの詳細」をチェックしてSoDCheckStatusフィールド値を確認します。SoDチェックが正常に完了した場合、SoDCheckStatusフィールドの値は「SoDチェックが完了しました」となり、SoDCheckerタスクは「完了」の状態になります。
Holderタスクのステータスは、SoDチェック結果によって異なります。SoDチェックに成功すると、Holderタスクが完了し、権限がプロビジョニングされます。そうでない場合は、Holderタスクが取り消され、権限はプロビジョニングされません。
アクセス・ポリシーが承認とともに作成されると、アカウントのプロビジョニングのリクエストが作成されます。ユーザーにロールが割り当てられ、ユーザー・ポリシーの評価スケジュール・ジョブが実行された後、ユーザーに対してアカウントをプロビジョニングするためのリクエストが作成されます。このリクエストに対してSoDチェックが実行されます。
異なるアプリケーション・インスタンスからの2つの権限(Sodチェックが有効化されている権限およびSodチェックが有効化されていない権限)に対してリクエストを要求できます。この場合、SoDチェックが有効化されている権限に対してSoDチェックが実行されます。
|
注意: 異なるアプリケーション・インスタンスからの権限間でのSoDチェックはサポートされていません。たとえば、EBS権限とPSFT権限間でのSoDチェックはサポートされません。 |
すべてのSoD関連イベントのロギングを有効にするには、次の手順を実行します。
テキスト・エディタで、DOMAIN_HOME/config/fmwconfig/servers/OIM_SERVER/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に変更できます。デフォルト・ロギング・レベルでは、エラーおよび警告メッセージが出力されます。
表22-2に、SoDチェックの実行中にエラーが発生した場合に実行できるトラブルシューティング手順を示します。
表22-2 SoDチェックのトラブルシューティング
| 問題 | 解決策 |
|---|---|
|
プロセス・フォームのSoDCheckStatusフィールドに値が表示されないか、デフォルト値が表示されます。EBSコネクタのフィールドでは、 |
これは、SoD構成が正しくないことを意味します。「職務の分離(SOD)チェックは必須です」システム・プロパティが デフォルトの登録が使用されている場合、topologyNameパラメータの値は |
|
「リクエスト」フォームのSoDCheckStatusフィールドに SoDCheckResultフィールドには |
SoD構成は正しいがSoDエンジンの接続情報が正しくない可能性があるか、SoDエンジンでエラーが発生しました。SoDエンジンのエラーは、次のような理由により発生することがあります。
SoDエンジン・ログで、その他のエラーがないかを確認します。SoDエンジンによりトラッキングIDが返されない場合、シミュレーションは正常に開始されていません。 |
|
プロセス・フォームのSoDCheckStatusフィールドが |
承認用のスケジュール済ジョブではなく、SoDチェック結果の取得(プロビジョニング)スケジュール済ジョブを実行していることを確認します。スケジュール済ジョブがトリガーされていることを確認します。デバッグ・レベルのロギングを有効化して、これを確認できます。 スケジュール済ジョブが実行されてもSoDチェックが完了しない場合は、SoDエンジンでエラーが発生しています。SoDエンジン・ログで詳細を確認してください。 |
|
SoD対応リソースをリクエストする際、リクエストを作成しても「リクエスト」フォームにSoDフィールドが表示されず、リクエストはリクエスト・レベル承認に直接送られます。 |
このエラーは、SoD構成が正しくないことを意味します。「職務の分離(SOD)チェックは必須です」システム・プロパティが デフォルトの登録が使用されている場合、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"の"SYSTEM 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ユーティリティを使用してファイルを再インポートしてください。 |
