1 SAP User Managementコネクタについて
Oracle Identity Governanceは、オンプレミスまたはクラウドにあるアプリケーションに対して、セルフ・サービス、コンプライアンス、プロビジョニングおよびパスワード管理サービスを提供する集中アイデンティティ管理ソリューションです。Oracle Identity Governanceコネクタは、Oracle Identity Governanceと外部のアイデンティティ認識アプリケーションの統合に使用されます。
SAP UMコネクタは、2種類のSAPターゲット・システム(SAP Netweaver ABAP Application ServerおよびSAP GRC Access Request Management)と統合できます。
SAP UMコネクタは、SAP NetWeaver ABAP Application Serverに対するアカウントのプロビジョニングとリコンサイルに使用されます。このコネクタは、SAP GRC Access Risk Analysis (ARA)モジュールを利用したSoD検証機能もサポートします。SAP AC UMコネクタは、Webサービスを介したユーザー・プロビジョニングのためにSAP GRC Access Request Managent (ARM)モジュールと一緒に構成できます。
ノート:
このマニュアルでは、Identity Self Serviceの「管理」タブの「アプリケーション」オプションを使用してデプロイされるコネクタをAOBアプリケーションと呼びます。Oracle Identity System Administrationの「コネクタの管理」オプションを使用してデプロイされるコネクタをCIベース・コネクタ(コネクタ・インストーラ・ベース・コネクタ)と呼びます。アプリケーション・オンボードとは、Oracle Identity Governanceにアプリケーションを登録または関連付けして、ユーザー情報のプロビジョニングおよびリコンシリエーションにそのアプリケーションを使用できるようにするプロセスです。
次の各トピックでは、SAP UMコネクタの概要を示します。
ノート:
このマニュアルでは、UMターゲット・システムという用語は、SAP ERPとSAP CUAの両方をまとめて指します。情報がSAP ERPまたはSAP CUAのいずれかに特有である場合、ターゲット・システムの名前が使用されています。1.1 動作保証されているコンポーネント
コネクタをインストールおよび使用するために必要なソフトウェア・コンポーネントおよびそのバージョンは次のとおりです。
表1-1 動作保証されているコンポーネント
コンポーネント | AOBアプリケーションの要件 | CIベース・コネクタの要件 |
---|---|---|
Oracle Identity GovernanceまたはOracle Identity Manager |
Oracle Identity ManagerまたはOracle Identity Governanceの次のリリースのいずれかを使用できます。
|
Oracle Identity ManagerまたはOracle Identity Governanceの次のリリースのいずれかを使用できます。
|
ターゲット・システム |
ターゲット・システムは次のいずれか。
|
ターゲット・システムは次のいずれか。
|
コネクタ・サーバー |
11.1.2.1.0または12.2.1.3.0 |
11.1.2.1.0または12.2.1.3.0 |
コネクタ・サーバーJDK |
JDK 1.6 Update 24以降およびJKD1.7以降、またはJRockit 1.6以降 |
JDK 1.6 Update 24以降およびJKD1.7以降、またはJRockit 1.6以降 |
外部コード |
コネクタはSAP JCo 3.0.2以降とともに動作します。次のSAPカスタム・コード・ファイルが必要です。
ノート: 様々なサポートされるプラットフォームおよびプロセッサ用に、異なる配布パッケージ(JCo) 3.0が用意されています。環境に応じたJCo 3.0パッケージの使用の詳細は、JCoのドキュメントを参照してください。 |
コネクタはSAP JCo 3.0.2以降とともに動作します。次のSAPカスタム・コード・ファイルが必要です。
ノート: 様々なサポートされるプラットフォームおよびプロセッサ用に、異なる配布パッケージ(JCo) 3.0が用意されています。環境に応じたJCo 3.0パッケージの使用の詳細は、JCoのドキュメントを参照してください。 |
SAP Governance, Risk and Compliance Access Control (GRC AC) |
このターゲット・システムのAccess Risk Analysis機能またはAccess Request Management機能を構成および使用する場合は、次のいずれかをインストールしてください。
|
このターゲット・システムのAccess Risk Analysis機能またはAccess Request Management機能を構成および使用する場合は、次のいずれかをインストールしてください。
|
ノート:
一般的には、次のとおりです。
-
ABAPスタックにインストールされたSAPアプリケーションがサポートされます。
-
JAVAスタックにインストールされたアプリケーションはサポートされません。
-
一部のSAPアプリケーションはABAP+JAVAスタックにインストールできます。そのようなアプリケーションのインストール時には、ABAPまたはJAVAをデータ・ソースとして指定します。コネクタでは、ABAPデータ・ソースを使用するSAPアプリケーションがサポートされています。
1.2 使用上の推奨事項
ここでは、Oracle Identity GovernanceまたはOracle Identity Managerの使用しているバージョンに応じて、デプロイおよび使用できるSAP UMコネクタ・バージョンに関する推奨事項について説明します。
ノート:
Oracle Identity Managerでは、SAP UMコネクタとSAP UM Engineコネクタの両方をインストールして構成できます。
SAP GRC ACターゲット・システムのコネクタを構成して、Access Risk AnalysisまたはAccess Request Management機能のいずれかを使用できます。
-
Oracle Identity Governance 12cPS4 (12.2.1.4.0)、12cPS3リリースBP02 (12.2.1.3.2)およびこのリリース・トラックのそれ以降のBP、SAP NetWeaver 7.51 SPS 00 (SAP S/4HANA 1610)およびSAP BusinessObjects AC 10.1以降のバージョンを使用している場合、このコネクタの最新の12.2.1.xバージョンを使用します。
Oracle Identity Self Serviceコンソールの「管理」タブの「アプリケーション」オプションを使用してコネクタをデプロイします。
-
表1-1の「CIベースのコネクタの要件」列に記載されているように、Oracle Identity Managerリリース11.1.2.xを使用している場合は、SAP User Managementコネクタの11.1.xバージョンを使用してください。Oracle Identity Managerリリース11.1.2.xとともにこのコネクタの12.2.1.xバージョンを使用する場合は、CIベースのモードでのみこのコネクタをインストールおよび使用できます。AOBアプリケーションを使用する場合は、Oracle Identity Governanceリリース12.2.1.3.0にアップグレードする必要があります。SAP UMコネクタの最新の12.2.1.xバージョンをCIベース・モードで使用している場合、コネクタのデプロイメント、使用方法およびカスタマイズの詳細は、『Oracle Identity Manager SAP User Managementコネクタ・ガイド リリース11.1.1』を参照してください。
- SAP S/4HANA On-Premise: SAP ERP 6.0の従来のアップグレード済リリースは、SAP GUIベースでシステムにアクセスでき、Fiori launchpadにもアクセスできます。多くのお客様がこれに移行しています。これは、管理/サポート/メンテナンスに関してお客様が完全に制御できる環境です。推奨事項 - Oracle Identity Governance - SAP User Managementコネクタを使用します。詳細は、「SAP User Managementコネクタについて」を参照してください。
- SAP S/4HANA Cloud Private Edition: SAP S/4HANA On-Premiseと似ていますが、全体的なシステム制御/管理/メンテナンスはSAPで行います。これは、"Rise with SAP"プログラムに基づいて、エンド/ビジネス・ユーザーにSAP GUIアクセスを許可するサービスとしてのみ提供されています。エンド/ビジネス・ユーザーはFiori Launchpadにもアクセスできます。推奨事項 - Oracle Identity Governance - SAP User Managementコネクタを使用します。詳細は、「SAP User Managementコネクタについて」を参照してください。
- SAP S/4HANA Cloud Public Edition/Essential Edition: S/4HANAのコアSaaS製品で、ここにインスタンスがプロビジョニングされます。エンド/ビジネス・ユーザーにはブラウザベースのアクセスのみが許可されます。このクラウド・インスタンスに対して有効な、または公開されるSAP GUIアクセスはありません。推奨事項 - Oracle Identity Governance - SAP S/4 HANA Cloudコネクタを使用します。詳細は、「コネクタの概要」を参照してください。
1.3 動作保証されている言語
コネクタでサポートされている言語は次のとおりです。
-
アラビア語
-
中国語(簡体字)
-
中国語(繁体字)
-
チェコ語
-
デンマーク語
-
オランダ語
-
英語
-
フィンランド語
-
フランス語
-
フランス語(カナダ)
-
ドイツ語
-
ギリシャ語
-
ヘブライ語
-
ハンガリー語
-
イタリア語
-
日本語
-
韓国語
-
ノルウェー語
-
ポーランド語
-
ポルトガル語
-
ポルトガル語(ブラジル)
-
ルーマニア語
-
ロシア語
-
スロバキア語
-
スペイン語
-
スウェーデン語
-
タイ語
-
トルコ語
1.4 サポートされているコネクタ操作
これらは、ターゲット・システムにおける、コネクタでサポートされる操作のリストです。
表1-2 SAP UMおよびSAP AC UMコネクタでサポートされているコネクタ操作
操作 | SAP UMでサポート | SAP AC UMでサポート |
---|---|---|
ユーザー管理 |
||
ユーザー・アカウントの作成 |
〇 |
〇 |
ユーザー・アカウントの更新 |
〇 |
〇 |
ユーザー・アカウントの削除 |
〇 |
〇 |
ユーザー・アカウントの有効化 |
〇 |
〇 |
ユーザー・アカウントの無効化 |
〇 |
〇 |
ユーザー・アカウントのロック |
〇 |
〇 |
ユーザー・アカウントのロック解除 |
〇 |
〇 |
パスワードのリセット |
〇 |
× |
ユーザー・アカウントへのロールの割当て |
〇 |
〇 |
ユーザー・アカウントへの複数のロールの割当て |
〇 |
〇 |
ユーザー・アカウントからのロールの削除 |
〇 |
〇 |
ユーザー・アカウントからの複数のロールの削除 |
〇 |
〇 |
ユーザー・アカウントへのプロファイルの割当て |
〇 |
〇 |
ユーザー・アカウントへの複数のプロファイルの割当て |
〇 | 〇 |
ユーザー・アカウントからのプロファイルの削除 |
〇 |
〇 |
ユーザー・アカウントからの複数のプロファイルの削除 |
〇 | 〇 |
ユーザー・アカウントへのグループの割当て |
〇 |
× |
ユーザー・アカウントへの複数のグループの割当て |
〇 | × |
ユーザー・アカウントからのグループの削除 |
〇 |
× |
ユーザー・アカウントからの複数のグループの削除 |
〇 | × |
ユーザー・アカウントへのパラメータの割当て |
〇 |
× |
ユーザー・アカウントへの複数のパラメータの割当て |
〇 | × |
ユーザー・アカウントからのパラメータの削除 |
〇 |
× |
ユーザー・アカウントからの複数のパラメータの削除 |
〇 |
× |
権限 |
||
ロールの追加 |
〇 |
〇 |
複数のロールの追加 |
〇 |
〇 |
ロールの削除 |
〇 |
〇 |
複数のロールの削除 |
〇 |
〇 |
プロファイルの追加 |
〇 |
〇 |
複数のプロファイルの追加 |
〇 |
〇 |
プロファイルの削除 |
〇 |
〇 |
複数のプロファイルの削除 |
〇 |
〇 |
1.5 コネクタのアーキテクチャ
SAP UMコネクタは、Identity Connector Framework (ICF)を使用して実装されます。
操作の基本モードでは、コネクタはOracle Identity Governanceを、アカウントの作成または変更のプロビジョニング・リクエストのSAP ERPまたはSAP CUAへの送信のためのフロント・エンドとして設定します。アプリケーションの作成時に、Oracle Identity Governanceでダイレクト・プロビジョニングまたはリクエストベース・プロビジョニングのどちらを有効化するかを選択できます。ダイレクト・プロビジョニングでは、Oracle Identity Governance管理者のみがターゲット・システム・リソースを作成および管理できます。リクエストベースのプロビジョニングでは、ユーザーはそのアカウントの作成および管理のリクエストを出すことができます。管理者または承認者として指定された他のユーザーはそのリクエストに基づいて動作します。
アクセス・ポリシーの変更は、コネクタによりサポートされるプロビジョニングでは、操作の3番目のフォームです。アクセス・ポリシーでの変更に、ユーザーのセットにプロビジョニングされたリソースでの対応する変更が必要な場合、ターゲット・システムでの必要なプロビジョニング操作がOracle Identity Governanceから自動的に継承されます。
ターゲット・システムで直接実行されたプロビジョニング操作によって追加または変更されたアカウント・データは、Oracle Identity Governanceにリコンサイルできます。
図1-1に、SAP ERPとOracle Identity Governanceを統合するコネクタを示します。
図1-1 SAP ERPとOracle Identity Governanceを統合するコネクタ
「図1-1 SAP ERPとOracle Identity Governanceを統合するコネクタ」の説明
図1-2に、SAP CUAとOracle Identity Governanceを統合するコネクタを示します。
図1-2 SAP CUAとOracle Identity Governanceを統合するコネクタ
「図1-2 SAP CUAとOracle Identity Governanceを統合するコネクタ」の説明
これらの図に示されているように、SAP ERPまたはSAP CUAは、Oracle Identity Governanceのターゲット・リソースとして構成されます。Oracle Identity Governanceで実行されるプロビジョニング操作を通じて、OIMユーザーのアカウントがターゲット・システムで作成および更新されます。リコンシリエーションを通じて、ターゲット・システムで直接作成および更新されるアカウント・データがOracle Identity Governanceにフェッチされ、対応するOIMユーザーに対して格納されます。
ノート:
コネクタはSAP CUAの子システムでのアカウントの直接管理はサポートしません。図1-2に示されているように、コネクタ操作はOracle Identity GovernanceとSAP ERP親システムとの間で実行されます。必要な場合、これらのコネクタ操作によるユーザー・データの変更は、親システムから子システムへ伝播されます。
プロビジョニング時には、アダプタがプロセス・フォームを介した送信されたプロビジョニング・データをターゲット・システムに搬送します。ターゲット・システムの標準BAPIはアダプタからのプロビジョニング・データを受け入れ、ターゲット・システムで必要な操作を実行し、ターゲット・システムからのレスポンスをアダプタに返します。アダプタはOracle Identity Governanceにレスポンスを返します。
リコンシリエーション時には、スケジュール済タスクによってターゲット・システムとの接続が確立され、リコンシリエーション基準がBAPIに送信されます。BAPIはリコンシリエーション基準に一致するユーザー・レコードを抽出し、レコードをスケジュール済タスクに戻し、スケジュール済タスクがOracle Identity Governanceにレコードを渡します。
ターゲット・システムからフェッチされた各レコードは、OIMユーザーにすでにプロビジョニングされているSAP UMリソースと比較されます。一致が見つかると、ターゲット・システムからSAPレコードに対して行われた更新が、Oracle Identity GovernanceのSAP UMリソースにコピーされます。一致が見つからなかった場合、レコードのユーザーIDが、各OIMユーザーのユーザーIDと比較されます。一致が見つかった場合、ターゲット・システム・レコードのデータを使用して、SAP UMリソースがOIMユーザーにプロビジョニングされます。
1.6 サポートされているデプロイメント構成
次に示すのは、コネクタのサポートされるデプロイメント構成のリストです。
コネクタは、ターゲット・システムとの直接統合を可能にすることに加え、SAP GRCのAccess Risk AnalysisモジュールおよびAccess Request Managementモジュールとのインタフェースとして機能するように使用することもできます。ターゲット・システム(SAP ERPまたはSAP CUA)およびSAP GRCのこれら2つのモジュールでは、様々なデプロイメント構成が提供されます。次の各項で、コネクタのサポートされるデプロイメント構成について説明します。
1.6.1 基本ユーザー管理
基本ユーザー管理用にコネクタを構成する場合、コネクタはOracle Identity Governanceを介して送信されたプロビジョニング・データを受け入れ、このデータをターゲット・システムに伝播します。たとえば、「ユーザーの作成」プロビジョニング操作がOracle Identity Governanceで実行される場合、ターゲット・システムでアカウントが作成される結果になります。
ターゲット・システムで直接実行されたプロビジョニング操作によって追加または変更されたアカウント・データは、Oracle Identity Governanceにリコンサイルできます。
図1-1および図1-2に、このデプロイメント構成でのコネクタのアーキテクチャを示します。
プロビジョニング操作中に実行されるステップの概要は次のとおりです。
-
プロビジョニング操作が、ダイレクト・プロビジョニング、リクエストベースのプロビジョニングまたはアクセス・ポリシーの変更を介して開始されます。
-
プロビジョニング・データがターゲット・システムに送信されます。
-
ターゲット・システムで必要な変更が行われ、操作の結果がOracle Identity Governanceに送り返されて保存されます。
1.6.2 SoDを使用したユーザー管理
SAP GRCのAccess Risk AnalysisモジュールをSAP動作環境で職務の分離(SoD)を実装するように構成できます。このシナリオでは、コネクタをOracle Identity GovernanceとSoDモジュール間のインタフェースとして使用できます。コネクタは、SAP GRC Access Risk AnalysisのSoD検証プロセスを介してOracle Identity Governanceから送信されたプロビジョニング・リクエストが最初に実行されるように構成できます。この検証プロセスをクリアしたプロビジョニング・リクエストは、Oracle Identity Governanceからターゲット・システムへと伝播されます。
リコンシリエーションにはSAP GRC Access Risk Analysisは関係しません。ターゲット・システムで直接実行されたプロビジョニング操作によって追加または変更されたアカウント・データは、Oracle Identity Governanceにリコンサイルできます。
このガイドにおいて、SoDの構成というフレーズは、Oracle Identity GovernanceとSAP GRC Access Risk Analysisとの統合の構成を意味します。
図1-3に、コネクタのこのモードでのデータ・フローを示します。
プロビジョニング操作中に実行されるステップの概要は次のとおりです。
関連項目:
プロビジョニング・プロセス・フローの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド 11g リリース2 (11.1.2.2.0)』の職務の分離(SoD)の使用に関する項を参照してください
-
プロビジョニング操作が、ダイレクト・プロビジョニング、リクエストベースのプロビジョニングまたはアクセス・ポリシーの変更を介して開始されます。
-
このリクエストは、Oracle Identity Governanceのリソース承認ワークフローからSoDエンジン(SAP GRC Access Risk Analysis)に送信されます。
-
SoDエンジンでは、事前定義のルールを使用して、権限割当てがSoD違反につながるかどうかをチェックします。このチェックの結果はOracle Identity Governanceに送り返されます。
-
リクエストがSoD検証に失敗した場合、改善ステップが行われるように承認ワークフローを構成できます。ユーザーのリクエストがSoD検証にパスし、Oracle Identity Governanceの承認者がリクエストを承認した場合、リソース・プロビジョニング・ワークフローが開始されます。
-
このリソース・プロビジョニング・ワークフローは、SoD検証を再度実行するように構成できます。これは、権限割当てがターゲット・システムにプロビジョニングされる直前に、権限割当てのSoDコンプライアンスを確認するためです。また、この検証がリソース承認ワークフローで通過した場合、リソース・プロビジョニング・ワークフローのSoD検証チェックをバイパスするように構成することもできます。
-
ターゲット・システムで必要な変更がリソース・プロビジョニング・ワークフローで実行され、操作の結果がOracle Identity Governanceに送り返されて保存されます。
アカウント管理プロセスの概要:
-
Oracle Identity Governanceでのプロビジョニング操作からのデータは、まずSoD検証のためにSAP GRC Access Risk Analysisモジュールに送信されます。
-
SoD検証チェックをクリアしたプロビジョニング・リクエストは、SAP GRC Access Request Managementに送信されます。
-
リクエストがSAP GRC Access Request Managementワークフローをクリアすると、プロビジョニング・リクエストがターゲット・システムに実装されます。
-
Oracle Identity Governanceから実行されるスケジュール済タスクによって、ターゲット・システムからの操作結果がOracle Identity Governanceにリコンサイルされます。
1.6.3 コネクタのログの監査証跡詳細
Access Request Managementが構成されている場合、コネクタのログで監査証跡詳細を取得できます。
コネクタのログ内の監査証跡のサンプルをいくつか示します。
-
ユーザーの作成
logAuditTrial : Audit Trial: {Result=[Createdate:20130409,Priority:HIGH,Requestedby:,johndoe (JOHNDOE),Requestnumber:9000001341,Status:Decision pending,Submittedby:,johndoe (JOHNDOE),auditlogData:{,ID:000C290FC2851ED2A899DA29DAA1B1E2,Description:,Display String:Request 9000001341 of type New Account Submitted by johndoe ( JOHNDOE ) for JK1APRIL9 JK1APRIL9 ( JK1APRIL9 ) with Priority HIGH}], Status=0_Data Populated successfully}
-
リクエスト・ステータス・スケジュール・ジョブ
logAuditTrial : Audit Trial: {Result=[Createdate:20130409,Priority:HIGH,Requestedby:,johndoe (JOHNDOE),Requestnumber:9000001341,Status:Approved,Submittedby:,johndoe (JOHNDOE),auditlogData:{,ID:000C290FC2851ED2A899DA29DAA1B1E2,Description:,Display String:Request 9000001341 of type New Account Submitted by johndoe ( JOHNDOE ) for JK1APRIL9 JK1APRIL9 ( JK1APRIL9 ) with Priority HIGH,ID:000C290FC2851ED2A899DAF9961C91E2,Description:,Display String:Request is pending for approval at path GRAC_DEFAULT_PATH stage GRAC_MANAGER,ID:000C290FC2851ED2A89A1400B60631E2,Description:,Display String:Approved by JOHNDOE at Path GRAC_DEFAULT_PATH and Stage GRAC_MANAGER,ID:000C290FC2851ED2A89A150972D091E2,Description:,Display String:Auto provisioning activity at end of request at Path GRAC_DEFAULT_PATH and Stage GRAC_MANAGER,ID:000C290FC2851ED2A89A150972D111E2,Description:,Display String:Approval path processing is finished, end of path reached,ID:000C290FC2851ED2A89A150972D151E2,Description:,Display String:Request is closed}], Status=0_Data Populated successfully}
-
ユーザーの変更
logAuditTrial : Audit Trial: {Result=[Createdate:20130409,Priority:HIGH,Requestedby:,johndoe (JOHNDOE),Requestnumber:9000001342,Status:Decision pending,Submittedby:,johndoe (JOHNDOE),auditlogData:{,ID:000C290FC2851ED2A89A3ED3B1D7B1E2,Description:,Display String:Request 9000001342 of type Change Account Submitted by johndoe ( JOHNDOE ) for JK1FirstName JK1APRIL9 ( JK1APRIL9 ) with Priority HIGH}], Status=0_Data Populated successfully}
1.6.4 Access Request Managementを使用したユーザー管理
Access Request Managementは、SAP GRCスイート内のモジュールです。SAP環境では、アカウントの作成および変更のプロビジョニング・リクエストを受信するフロント・エンドとしてAccess Request Managementを設定できます。Access Request Managementでは、これらのリクエストを処理するワークフローを構成することが可能で、承認者として指定されたユーザーがこれらのリクエストを処理します。
ノート:
このガイドにおいて(SAPUM-AC-Connector-CI.xmlファイルを使用するSAP UM ACコネクタの場合)、Access Request Managementの構成というフレーズは、Oracle Identity GovernanceとSAP GRC Access Request Managementとの統合の構成を意味します。
GRCターゲットとのやりとりがないため、このコネクタは通常のSAP UMコネクタとして機能します。
動作環境によっては、Access Request ManagementモジュールがAccess Risk Analysisモジュールと直接リンク付けされている場合があります。すなわち、プロビジョニング・リクエストは、SoD検証用にまずAccess Request ManagementからAccess Risk Analysisに送信されます。検証プロセスをクリアしたリクエストのみがターゲット・システムに実装されます。このシナリオでは、コネクタのSoD機能は構成しないことをお薦めします。
リコンシリエーションにはSAP GRC Access Request Managementは関係しません。Oracle Identity Governanceのスケジュール済タスクでは、ターゲット・システムからのデータがOracle Identity Governanceにフェッチされます。
図1-4に、コネクタのこのモードでのデータ・フローを示します。
図1-4 SAP GRC Access Request ManagementをOracle Identity Governanceおよびターゲット・システムに統合するコネクタ
「図1-4 SAP GRC Access Request ManagementをOracle Identity Governanceおよびターゲット・システムに統合するコネクタ」の説明
プロビジョニング操作中に実行されるステップの詳細なステップは次のとおりです。
-
プロビジョニング操作が、ダイレクト・プロビジョニング、リクエストベースのプロビジョニングまたはアクセス・ポリシーの変更を介して開始されます。
-
コネクタでは、次のSAP GRCのWebサービスを使用して、リクエストの送信およびレスポンスの受信が行われます。
-
SAPGRC_AC_IDM_SUBMITREQUEST: このWebサービスはリクエストの送信に使用されます。
-
SAPGRC_AC_IDM_REQUESTSTATUS: このWebサービスはリクエスト・ステータスのフェッチに使用されます。
-
SAPGRC_AC_IDM_AUDITTRAIL: このWebサービスは、SAP GRC Access Request Managementのログにエラー・メッセージがあるかどうかをチェックするために使用されます。
プロセス・フォームには、基本的なユーザー管理用とAccess Request Management用の両方のフィールドが保持されています。ただし、「ユーザーの作成」操作では、プロセス・フォームのAccess Request Managementフィールド(属性)も使用されます。これらのフィールドのマッピングは、GRCターゲット・バージョンに基づきLookup.SAPAC10ABAP.UM.ProvAttrMap参照定義の中に保存されます。
これらの参照定義に存在しない属性の値を指定した場合、コネクタはユーザーの作成操作中、これらの属性を無視します。
ノート:
SAP GRC Access Request Managementでは、パスワードは処理されません。したがって、「パスワード」フィールドに入力された値はすべて、「ユーザーの作成」プロビジョニング操作中は無視されます。
Access Request Managementを構成する際のパスワードの設定の詳細は、「プロビジョニング実行のガイドライン」を参照してください。
「ユーザーの変更」操作では、SAP GRC Access Request Managementでマップされる属性の値を指定できます。
-
-
SAP GRC Access Request Managementでリクエストが作成されると、Access Request Managementによって送り返されたデータがOracle Identity Governanceの次の読取り専用フィールドに保存されます。
-
ACリクエストID: このフィールドには、SAP GRC Access Request Managementで生成されたリクエストIDが保持されます。「ACリクエストID」は、リクエストの存続期間中変更されません。
-
ACリクエスト・ステータス: このフィールドには、SAP GRC Access Request Managementでのリクエストのステータスが保持されます。SAP ACリクエスト・ステータス・スケジュール済ジョブを構成および実行し、ターゲット・システムからリクエストの最新ステータスをフェッチします。
-
ACリクエスト・タイプ: このフィールドには、リクエストのタイプ(アカウントの新規作成、アカウントの変更、アカウントの削除、新規作成、変更など)が保持されます。
-
-
リクエストは、SAP GRC Access Request Managementで定義されたワークフローを介して渡されます。次のいずれかの結果になります。
-
Access Request Managementがリクエストをクリアした場合、ターゲット・システム(SAP R/3またはSAP CUA)でユーザーのアカウントが作成または変更される結果になります。リクエストのステータスは、SAP GRC 10では「OK」に設定されます。次に、Oracle Identity Governanceのログにメッセージが記録されます。
-
Access Request Managementがプロビジョニング・リクエストを拒否した場合、リクエストのステータスは、SAP GRC 10では「Failed」になります。次に、Oracle Identity Governanceのログにメッセージが記録されます。
-
Access Request Managementとターゲット・システム間の通信中にエラーが発生した場合、リクエストは「Open」ステータスのままになります。操作が失敗したことを示すメッセージが、リクエストに関連付けられた監査ログに記録されます。エラー・メッセージがコンソールに表示されます。
-
アカウント管理プロセスの概要:
-
Oracle Identity Governanceでのプロビジョニング操作からのデータは、SAP GRC Access Request Managementに送信されます。
-
SAP GRC Access Request Managementで定義されたワークフローによって、リクエストがSoD検証のためにSAP GRC Access Risk Analysisモジュールに送信されます。
-
SoD検証チェックをクリアした後、プロビジョニング・リクエストがターゲット・システムに実装されます。
-
Oracle Identity Governanceから実行されるスケジュール済タスクによって、ターゲット・システムからの操作結果がOracle Identity Governanceにリコンサイルされます。
1.6.5 SoDとAccess Request Managementを両方使用したユーザー管理
SAP GRC Access Risk AnalysisとAccess Request Managementの両方をSAP動作環境で構成できます。User ManagementとAccess Request Managementモジュールが動作環境内で個別に構成されている(つまり、リンクされていない)など、Access Risk AnalysisとAccess Request Managementモジュールが個別に構成されている場合にかぎり、SoDとAccess Request Managementの両方のコネクタ機能を同時に構成する必要があります。
ノート:
プロビジョニング・リクエストをSoD検証用にGRC Access Risk Analysisに送信するようにSAP GRC Access Request Managementが構成されている場合、コネクタのSoD機能を構成することはできません。
1.6.6 デプロイメント構成の使用に関するガイドライン
ここでは、サポートされるデプロイメント構成のいずれかを使用する際に適用する必要があるガイドラインについて説明します。
Oracle Identity GovernanceをSAP動作環境に統合する場合、次の要件のいずれかを想定していると考えられます。
-
Oracle Identity GovernanceをSAPリソースでのアカウント管理のプロビジョニング・ソースとして使用。
-
SAP GRC Access Request Managementで構成されたワークフローおよびアクセス・ポリシーを利用し、Oracle Identity GovernanceをSAPリソースでのアカウント管理のプロビジョニング・ソースとして使用。
-
SoD実施のためにSAP GRC Access Risk Analysisを使用し、Oracle Identity Governanceを介して送信されたプロビジョニング・リクエストのユーザー承認のためにSAP GRC Access Request Managementを使用。SAPリソースでの全体的なアカウント管理はOracle Identity Governanceを介して実行します。
次の各項で、サポートされるデプロイメント構成のガイドラインを説明します。
ノート:
User ManagementとSoD、Access Request Managementは個別に構成する必要があります。
1.6.6.1 SoDを使用するユーザー管理とAccess Request Management
次のデプロイメント・ガイドラインは、SAP GRC Access Risk AnalysisとGRC AC Access Request Managementが有効化され、個別に構成されたモジュールであるシナリオで適用してください。
-
コネクタのSoD機能とAccess Request Management機能を両方構成します。
-
SAP GRC Access Request Managementで、アカウント作成に対するステージなしの承認を構成します。すなわち、アカウント作成リクエストはAccess Request Managementで自動的に承認される必要があります。
ロールまたはプロファイルがOracle Identity Governanceでプロビジョニングされ、SAP GRC Access Request Managementで拒否された場合、そのロールまたはプロファイルは次回のユーザー・リコンシリエーション実行の最後にOracle Identity Governanceから削除されます。このため、ロールおよびプロファイルのプロビジョニング・リクエストの承認ワークフローをSAP GRC Access Request Managementで定義できます。
1.6.6.2 Access Request Managementを使用したユーザー管理
次のデプロイメント・ガイドラインは、SAP動作環境でSAP GRC Access Request Managementが構成され、有効化されているシナリオで適用してください。
ノート:
SAP GRC Access Risk Analysisは、SAP GRC Access Request Managementにリンク付けされたモジュールとして構成されているか、またはまったく使用されていません。
User ManagementとSoD、Access Request Managementは個別に構成する必要があります。
-
SAP GRC Access Request Managementで、アカウント作成に対するステージなしの承認を構成します。すなわち、アカウント作成リクエストはAccess Request Managementで自動的に承認される必要があります。
このガイドラインについては、この項で前述したシナリオを参照してください。
-
コネクタのAccess Request Management機能を構成します。
-
コネクタのSoD機能は構成しないでください。
1.6.7 Access Request Managementを有効化する際の考慮事項
コネクタのAccess Request Management機能を有効化する際は、次の事項を考慮してください。
-
プロビジョニング操作によっては、Oracle Identity Governanceから複数のリクエストが生成される場合があります。たとえば、特定のプロビジョニング操作で、あるユーザーに複数のロールを割り当てると、ロールごとに1つのリクエストが作成され、Access Request Managementに送信されます。
-
アカウントによって、Oracle Identity Governanceが最新のリクエスト以外を記録しない場合があります。たとえば、あるアカウントの複数の属性が別個のプロビジョニング操作で変更された場合、Oracle Identity Governanceでは最後の操作に関連したデータのみが記録されます。
-
ユーザーの変更操作によって、複数のプロセス・フォーム・フィールドまたは子フォーム・フィールドに変更が及ぶ場合があります。変更されるフィールドごとにリクエストが1つ作成され、SAP GRC Access Request Managementに送信されます。Access Request Managementに送信された最後のリクエストに関する情報のみがOracle Identity Governanceに保存されます。
-
1回の操作で送信できるのは、親フォーム・リクエストまたは子フォーム・リクエストのいずれかです。親フォーム・リクエストと子フォーム・リクエストの両方を同時に送信することはできません。
-
ステージなしのワークフローが「ユーザーの作成」プロビジョニング操作に対して定義されている場合にかぎり、SAP HRMSとSAP R/3またはSAP CUAアカウントのリンクを有効にします。
「SAP HRMSとSAP ERPまたはSAP CUAアカウントのリンク」では、個別のユーザーに対し作成されたSAP HRMSアカウントとそれに対応する同じユーザーに対して作成されたSAP R/3またはSAP CUAアカウントの間のリンクを保存するコネクタの機能について説明します。Access Request Management機能を構成する場合、SAP GRC Access Request Managementでステージなしの承認が「ユーザーの作成」リクエスト・タイプに対して定義されている場合にかぎり、リンクを有効にする必要があります。ステージなし承認は承認者が関与していない承認です。ステージなし承認を介して送信されたすべてのリクエストは自動的に承認されます。
1.6.8 セキュリティの構成のガイドライン
ここでは、セキュリティを構成する際に適用する必要があるガイドラインを示します。
-
通信の保護
Oracle Identity GovernanceとSAPシステムとの間の通信を保護することで、機密データを保護することは重要です。
SAP User Managementをターゲット・システムとして使用している場合、SNC (Secure Network Communication)を構成する必要があります。詳細は、「Oracle Identity Governanceとターゲット・システム間の通信を保護するSNCの構成」を参照してください。
SAP GRCをターゲット・システムとして使用している場合、Oracle Identity GovernanceとSAP GRCとの間のSSLを有効にする必要があります。手順は、『Oracle Fusion Middleware Oracle Identity Governanceのためのアプリケーションの開発とカスタマイズ』のアイデンティティ・コネクタ・サーバーの使用に関する項を参照してください。
-
パスワード管理
Oracle Identity Governanceを介して作成したアカウントに対し、新たに作成したアカウントを持つユーザーが最初のログイン時にパスワードを変更することを求められるように、またはOracle Identity Governanceでのアカウントの作成中にパスワード・セットがターゲット・システムで新しいパスワードとして設定されるように、コネクタを構成できます。
詳細は、「新たに作成したアカウントのパスワード変更の構成」を参照してください。
1.7 サポートされているコネクタ機能のマトリックス
AOBアプリケーションとCIベース・コネクタでサポートされている機能のリストを示します。
表1-3 サポートされるコネクタの機能マトリックス
機能 | AOBアプリケーション | CIベース・アプリケーション |
---|---|---|
SAP GRCバージョン10のサポート | 〇 | 〇 |
コネクタ・サーバーのサポート | 〇 | 〇 |
リコンシリエーションとプロビジョニングでの標準およびカスタムの単一値属性のサポート | 〇 | 〇 |
権限リクエストのSoD検証 | 〇 | 〇 |
SAP GRC Access Request Managementによるプロビジョニング・リクエストのルーティング | 〇 | 〇 |
完全リコンシリエーションおよび増分リコンシリエーション | 〇 | 〇 |
制限付き(フィルタ)リコンシリエーション | 〇 | 〇 |
バッチ・リコンシリエーション | 〇 | 〇 |
SAP HRMSとSAP R/3またはSAP CUAアカウントのリンク | 〇 | 〇 |
ターゲット・システムとOracle Identity Governance間のSNC通信 | 〇 | 〇 |
新たに作成したアカウントのパスワード変更の構成 | 〇 | 〇 |
SAP JCoトレース・レベルの指定 | 〇 | 〇 |
接続プーリング | 〇 | 〇 |
コネクタ操作用のターゲット・システムでのログオン・グループの使用の指定 | 〇 | 〇 |
アカウント・データの変換および検証 | 〇 | 〇 |
リソース除外リストのサポート | 〇 | 〇 |
Unicodeおよび非Unicodeモードの両方のサポート | 〇 | 〇 |
1.8 コネクタの機能
コネクタの機能には、コネクタ・サーバーのサポート、完全リコンシリエーション、増分リコンシリエーション、制限付きリコンシリエーション、およびアカウント・データへの更新のリコンシリエーションなどが含まれます。
コネクタには、次のような機能があります。
1.8.1 SAP Governance, Risk, and Complianceバージョン10以降のサポート
このコネクタは、リスク分析と改善およびユーザーのプロビジョニングと管理のために使用できます。
このコネクタでは次の新しいコンポーネントがサポートされます。
-
Risk Analysis and Remediation (別名Access Risk Analysis (ARA))
-
Compliant User Provisioning (別名Access Request Management (ARM))
このガイドでは、SAP GRC Access Risk AnalysisはRisk Analysis and Remediation、SAP GRC Access Request ManagementはCompliant User Provisioningを示します。
1.8.2 コネクタ・サーバーのサポート
コネクタ・サーバーはICFによって提供される機能の1つです。コネクタ・アーキテクチャでは、1つ以上のコネクタ・サーバーを使用することで、アプリケーションと外部にデプロイされたバンドルとの通信が可能になります。
アプリケーションと同じVMでJavaコネクタ・バンドルを実行しない場合は、Javaコネクタ・サーバーを使用すると便利です。パフォーマンス向上のためにJavaコネクタを別のホストで実行すると、効果を発揮できます。
コネクタ・サーバーのインストール、構成および実行、ならびにコネクタ・サーバーへのコネクタのインストールの詳細は、『Oracle Fusion Middleware Oracle Identity Governanceのためのアプリケーションの開発とカスタマイズ』のアイデンティティ・コネクタ・サーバーの使用に関する項を参照してください。
1.8.3 権限リクエストのSoD検証
Oracle Identity Governanceでの権限リクエストをSoDエンジンを使用して検証できます。
このコネクタではOracle Identity GovernanceでのSoD機能がサポートされます。また、この機能は次のように更新されています。
-
SoD起動ライブラリ(SIL)は、Oracle Identity Governanceにバンドルされています。SILは、任意のSoDエンジンとのプラガブル統合インタフェースとして機能します。
-
SAP User Managementコネクタは、SoDエンジンとしてのSAP GRCとともに動作するように構成できます。そのために、コネクタの認証とプロビジョニングのワークフローが変更されました。
-
SoDエンジンは、コネクタを介して送信されるロールおよびプロファイル権限のリクエストを処理します。この予防シミュレーション方法は、リクエストされた権限がユーザーに割り当てられる前に、ユーザーへの権限割当てで競合する可能性のあるものを特定し、修正するうえで役立ちます。
関連項目:
このガイドの「SoD (職務の分離)の構成」。
ノート:
SODを使用したSAPユーザー管理を使用している場合は、「権限」タブから権限をリクエストしてください。
1.8.4 リコンシリエーションとプロビジョニングでの標準およびカスタムの単一値属性のサポート
コネクタでは、Oracle Identity Governanceとターゲット・システム間のプロビジョニングとリコンシリエーション用に属性マッピングのデフォルト・セットが提供されています。必要な場合には、プロビジョニングおよびリコンシリエーション用に新規ユーザーまたはグループ属性を追加できます。
デフォルト属性マッピングのリストに含まれない属性に対してマッピングを作成できます。これらの属性は、ターゲット・システムで提供されている標準属性セットの一部であっても、ユーザーがターゲット・システムに追加したカスタム属性であってもかまいません。
詳細は、「SAP User Managementコネクタの機能拡張」を参照してください。
1.8.5 SAP GRC Access Request Managementによるプロビジョニング・リクエストのルーティング
SAP GRC Access Request Managementとともに機能するようにコネクタを構成できます。
この機能の詳細は、「Access Request Managementを使用したユーザー管理」を参照してください。
1.8.6 完全リコンシリエーションおよび増分リコンシリエーション
完全リコンシリエーションでは、すべてのレコードがターゲット・システムからOracle Identity Governanceにフェッチされます。増分リコンシリエーションでは、前回のリコンシリエーションの実行後に追加または変更されたレコードのみがOracle Identity Governanceにフェッチされます。
このリコンシリエーション実行の完了後に、スケジュール済タスクの属性はリコンシリエーションの実行が開始したタイムスタンプを含みます。
コネクタのデプロイ後はいつでも、増分リコンシリエーションから完全リコンシリエーションへ切り替えることができます。詳細は、「完全リコンシリエーションおよび増分リコンシリエーションの実行」を参照してください。
1.8.7 制限付き(フィルタ)リコンシリエーション
リコンシリエーション実行時に、Oracle Identity Governanceにフェッチされるレコードを制限またはフィルタ処理するために、リコンサイルが必要な追加または変更されたターゲット・システム・レコードのサブセットを指定できます。
詳細は、「制限付きリコンシリエーションの実行」を参照してください。
1.8.8 バッチ・リコンシリエーション
リコンシリエーションの実行をバッチに分割することができます。これには、各バッチに含める必要があるレコード数を指定します。
詳細は、「バッチ・リコンシリエーションの実行」の「バッチ・サイズ」属性の説明を参照してください。
1.8.9 有効なアカウントと無効なアカウント
有効期限開始と有効期限終了は、ターゲット・システムの2つのユーザー属性です。SAPの特定ユーザーの有効期限終了日が現在の日付より前の場合、アカウントは無効状態です。それ以外の場合、アカウントは有効状態です。同じ動作が、リコンシリエーションを介してOracle Identity Governanceで複製されます。また、プロビジョニング操作を介して、有効期限終了日の値を現在の日付または過去の日付に設定することもできます。
ノート:
アカウントの有効状態または無効状態は、アカウントのロック状態またはロック解除状態とは関係ありません。
1.8.10 SAP HRMSとSAP ERPまたはSAP CUAアカウントのリンク
個別のユーザーに対して作成されたSAP HRMSアカウントは、同じユーザーに対して作成されたSAP ERPまたはSAP CUAアカウントにリンクできます。特定のユーザーに対し、SAP HRMSの属性は対応するSAP ERPまたはSAP CUAアカウントのユーザーIDを含みます。
Lookup.SAPABAP.Configuration参照定義内の次のエントリを使用して、Oracle Identity Governanceでこのリンクを複製できます。
-
validatePERNR
-
overwriteLink
詳細は、「SAP HRMSとSAP ERPまたはSAP CUAアカウントのリンク」を参照してください。
1.8.11 ターゲット・システムとOracle Identity Governance間のSNC通信
Oracle Identity Governanceとターゲット・システムの間の通信を保護するためにSecure Network Communication (SNC)を構成できます。
詳細は、「Oracle Identity Governanceとターゲット・システム間の通信を保護するSNCの構成」を参照してください。
1.8.12 新たに作成したアカウントのパスワード変更の構成
新たに作成したアカウントを使用してSAPにログインする場合、初回ログオン時にパスワードを変更するよう求められます。Oracle Identity Governanceで作成したアカウントの場合、構成ルックアップのchangePasswordAtNextLogonパラメータを使用してパスワード管理を構成できます。AOB実装を使用する場合は、「拡張構成」の項を参照してください。次のいずれかのアプローチをとることができます。
-
新たに作成したアカウントを持つユーザーの初回ログオン時にパスワードの変更を求めるように、コネクタを構成します。これには、changePasswordAtNextLogonパラメータをyesに設定します。このように設定すると、新規ユーザー・アカウントのプロセス・フォームに入力されたパスワードを使用して、ターゲット・システムで新規アカウントのパスワードが設定されます。ユーザーがターゲット・システムにログインすると、パスワードを変更するよう求められます。
-
Oracle Identity Governanceでアカウント作成時に設定されたパスワードが、ターゲット・システムで新規パスワードとして設定されるように、コネクタを構成します。ユーザーは初回ログオン時に、パスワードの変更を求められません。これには、changePasswordAtNextLogonパラメータの値をnoに設定し、「ITリソース」のdummyPasswordパラメータに文字列を入力します。AOB実装を使用する場合は、「基本構成」の項を参照してください。
このように設定すると、Oracle Identity Governanceでユーザー・アカウントを作成する際、ユーザーはまずダミー・パスワードを使用して作成されます。その後すぐに、ユーザーのパスワードは、プロセス・フォームに入力されたパスワードに変更されます。ユーザーがターゲット・システムにログインする際、パスワードを変更するよう求められません。
1.8.13 SAP JCoトレース・レベルの指定
コネクタはリコンシリエーションおよびプロビジョニング操作のためにSAP JCoを使用します。JCoトレース・レベルはSAP JCoが使用されるときに記録される必要のあるトレース・データのレベルを数値で指定するものです。トレース・レベルはITリソースのパラメータとして指定できます。
1.8.14 接続プーリング
接続プールは、ターゲット・システムへの物理的な接続を表すオブジェクトのキャッシュです。Oracle Identity Governanceコネクタは、これらの接続を使用してターゲット・システムと通信できます。
実行時に、アプリケーションはプールに接続をリクエストします。接続が使用可能であれば、コネクタがその接続を使用してからプールに戻します。プールに戻された接続は、コネクタが別の操作のために再びリクエストして使用することができます。接続プールは、接続の再利用を可能にし、ネットワーク待機時間、メモリー割当ておよび認証といった接続作成のオーバーヘッドを減らすことに役立っています。
アプリケーション作成時に指定する基本構成パラメータのセットごとに1つの接続プールが作成されます。たとえば、ターゲット・システムの3つのインストールに3つのアプリケーションがある場合は、ターゲット・システム・インストールごとに1つずつ、3つの接続プールが作成されます。接続プリーリング用に構成できるパラメータの詳細は、表3-3を参照してください。
1.8.15 コネクタ操作用のターゲット・システムでのログオン・グループの使用の指定
SAPでは、ログオン・グループを負荷分散メカニズムとして使用します。ユーザーがログオン・グループにログオンすると、システムはその接続リクエストを最小ロードのログオン・グループ・メンバーに内部的にルーティングします。リコンシリエーションおよびプロビジョニング操作用にターゲット・システムにログインするためにログオン・グループを使用するように、コネクタを構成できます。
1.8.16 アカウント・データの変換および検証
アプリケーションの作成時にGroovyスクリプトを作成して、リコンシリエーション操作およびプロビジョニング操作の際にOracle Identity Governanceとの間で送受信されるアカウント・データの変換と検証を構成できます。
詳細は、『Oracle Fusion Middleware Oracle Identity Governanceでのセルフ・サービス・タスクの実行』のプロビジョニングおよびリコンシリエーション属性の検証および変換に関する項を参照してください。
1.8.17 リソース除外リストのサポート
リコンシリエーションおよびプロビジョニング操作から除外する必要のあるアカウントのリストを指定できます。除外リストで指定したユーザーIDを持つアカウントは、リコンシリエーションおよびプロビジョニング操作による影響を受けません。
リソース除外リストの構成の詳細は、『Oracle Fusion Middleware Oracle Identity Governanceでのセルフ・サービス・タスクの実行』のリソース除外のための検証Groovyスクリプトに関する項を参照してください。