1. SAP User Management Engineアプリケーションの構成
  2. SAP User Management Engineコネクタについて

1 SAP User Management Engineコネクタについて

Oracle Identity Governanceは、オンプレミスまたはクラウドにあるアプリケーションに対して、セルフ・サービス、コンプライアンス、プロビジョニングおよびパスワード管理サービスを提供する集中アイデンティティ管理ソリューションです。Oracle Identity Governanceコネクタは、Oracle Identity Governanceと外部のアイデンティティ認識アプリケーションの統合に使用されます。

SAP User Management Engineコネクタ(SAP UMEおよびSAP AC UMEコネクタ)を使用すると、Oracle Identity GovernanceにSAPアプリケーションをオンボードできます。

SAP UMEコネクタは、SAP NetWeaver Java Application Serverのアカウントをプロビジョニングおよびリコンサイルするために使用されます。また、このコネクタでは、SAP Goverance, Risk, and Compliance (GRC)のAccess Risk Analysis (ARA)モジュールを利用したSoD検証機能もサポートされます。SAP AC UMEコネクタは、Webサービスを介したユーザー・プロビジョニングのためにSAP GRC Access Request Managent (ARM)モジュールと一緒に構成できます。

ノート:

このマニュアルでは、Identity Self Serviceの「管理」タブの「アプリケーション」オプションを使用してデプロイされるコネクタをAOBアプリケーションと呼びます。Oracle Identity System Administrationの「コネクタの管理」オプションを使用してデプロイされるコネクタをCIベース・コネクタ(コネクタ・インストーラ・ベース・コネクタ)と呼びます。
Oracle Identity Governanceリリース12.2.1.3.0以降では、Oracle Identity Self Serviceのアプリケーション・オンボード機能を使用してコネクタのデプロイメントが処理されます。この機能により、ビジネス・ユーザーは最小限の詳細と作業でアプリケーションをオンボードできます。コネクタのインストール・パッケージには、指定したアプリケーションまたはターゲット・システムからデータをプロビジョニングおよびリコンサイルするために必要なすべての情報を含む事前定義済テンプレート(XMLファイル)のコレクションが含まれています。これらのテンプレートには、ターゲット・システムに固有の基本接続性と構成の詳細も含まれています。コネクタによってこれらの事前定義済テンプレートからの情報が使用されるため、ユーザーは単一の簡素化されたUIを使用して迅速かつ簡単にアプリケーションをオンボードできます。

アプリケーション・オンボードとは、Oracle Identity Governanceにアプリケーションを登録または関連付けして、ユーザー情報のプロビジョニングおよびリコンシリエーションにそのアプリケーションを使用できるようにするプロセスです。

次のトピックでは、コネクタの概要を示します。

1.1 動作保証されているコンポーネント

コネクタをインストールおよび使用するために必要なソフトウェア・コンポーネントおよびそのバージョンは次のとおりです。

表1-1 動作保証されているコンポーネント

コンポーネント AOBアプリケーションの要件 CIベース・コネクタの要件

Oracle Identity GovernanceまたはOracle Identity Manager

Oracle Identity ManagerまたはOracle Identity Governanceの次のリリースのいずれかを使用できます。

  • Oracle Identity Governance 12c (12.2.1.4.0)
  • Oracle Identity Governance 12cリリースBP02 (12.2.1.3.2)

Oracle Identity ManagerまたはOracle Identity Governanceの次のリリースのいずれかを使用できます。

  • Oracle Identity Governance 12c (12.2.1.4.0)

  • Oracle Identity Governance 12cリリースBP02 (12.2.1.3.2)

  • Oracle Identity Manager 11gリリース2 PS3 (11.1.2.3.0)およびこのリリース・トラックでのそれ以降のBP

ターゲット・システム

ターゲット・システムは、次のいずれかを指定できます。

  • SAP NetWeaver 7.4 SPS 08以降で実行されているSAP User Management Engine

  • SAP NetWeaver 7.5 SPS 00以降で実行されているSAP User Management Engine

ノート: SAP Enterprise PortalなどのSAPアプリケーションをJavaスタックにインストールする場合、コネクタをアプリケーションのSAP User Management Engine (UME)に接続できます。

SAP Business Warehouse (BW)やSAP Supplier Relationship Management (SRM)などのSAPアプリケーションをAdvanced Business Application Programming (ABAP)スタックにインストールする場合は、アプリケーションのSAP User Management Engine (UME)に対してSAP Enterprise Portalを構成する必要があります。この構成の詳細は、それぞれのターゲット・システムのドキュメントを参照してください。

SAP Process Integration (PI)などのSAPアプリケーションをデュアル・スタック(ABAPおよびJava)にインストールする場合、コネクタをアプリケーションのSAP UMEに接続できます。ただし、ABAPデータ・ソースの制限事項が適用されます。

ターゲット・システムは、次のいずれかを指定できます。

  • SAP NetWeaver '04 SPS 14以降で実行されているSAP User Management Engine

  • SAP NetWeaver 7.0 SPS 05以降で実行されているSAP User Management Engine

  • SAP NetWeaver 7.4 SPS 08以降で実行されているSAP User Management Engine

  • SAP NetWeaver 7.5 SPS 00以降で実行されているSAP User Management Engine

ノート: SAP Enterprise PortalなどのSAPアプリケーションをJavaスタックにインストールする場合、コネクタをアプリケーションのSAP User Management Engine (UME)に接続できます。

SAP Business Warehouse (BW)やSAP Supplier Relationship Management (SRM)などのSAPアプリケーションをAdvanced Business Application Programming (ABAP)スタックにインストールする場合は、アプリケーションのSAP User Management Engine (UME)に対してSAP Enterprise Portalを構成する必要があります。この構成の詳細は、それぞれのターゲット・システムのドキュメントを参照してください。

SAP Process Integration (PI)などのSAPアプリケーションをデュアル・スタック(ABAPおよびJava)にインストールする場合、コネクタをアプリケーションのSAP UMEに接続できます。ただし、ABAPデータ・ソースの制限事項が適用されます。

コネクタ・サーバー

11.1.2.1.0

11.1.2.1.0

コネクタ・サーバーJDK

JDK 1.6 update 24以降およびJDK 1.7以降、またはJRockit 1.6以降

JDK 1.6 update 24以降およびJDK 1.7以降、またはJRockit 1.6以降

SAP Governance, Risk and Compliance Access Control (GRC AC)

このターゲット・システムのAccess Risk Analysis機能またはAccess Request Management機能を構成および使用する場合は、次をインストールしてください。

  • SAP NetWeaver AS ABAP 7.02サポート・パック7で実行されているSAP GRC AC 10

    GRCFND_A SP 10コンポーネントをインストールします。

  • SAP NetWeaver AS ABAP 7.40サポート・パック8で実行されているSAP GRC AC 10.1

    GRCFND_A SP 10コンポーネントをインストールします。

  • コネクタをJava、ABAPまたはLDAPデータ・ソースで使用する場合は、SAP NetWeaver AS ABAP 7.01サポート・パック10をEP RTAコンポーネントGRCPIEP SP 10パッチ2とともに使用します(GRCAC1010_4-20007574.SCAをデプロイするとき)。

  • コネクタをJava、ABAPまたはLDAPデータ・ソースで使用する場合は、SAP NetWeaver AS ABAP 7.01サポート・パック10をEP RTAコンポーネントGRCPIEP SP 03パッチ2とともに使用します(GRCAC1073003P_2-20009496.SCAをデプロイするとき)。

このターゲット・システムのAccess Risk Analysis機能またはAccess Request Management機能を構成および使用する場合は、次をインストールしてください。

  • SAP NetWeaver AS ABAP 7.02サポート・パック7で実行されているSAP GRC AC 10

    GRCFND_A SP 10コンポーネントをインストールします。

  • SAP NetWeaver AS ABAP 7.40サポート・パック8で実行されているSAP GRC AC 10.1

    GRCFND_A SP 10コンポーネントをインストールします。

  • コネクタをJava、ABAPまたはLDAPデータ・ソースで使用する場合は、SAP NetWeaver AS ABAP 7.01サポート・パック10をEP RTAコンポーネントGRCPIEP SP 10パッチ2とともに使用します(GRCAC1010_4-20007574.SCAをデプロイするとき)。

  • コネクタをJava、ABAPまたはLDAPデータ・ソースで使用する場合は、SAP NetWeaver AS ABAP 7.01サポート・パック10をEP RTAコンポーネントGRCPIEP SP 03パッチ2とともに使用します(GRCAC1073003P_2-20009496.SCAをデプロイするとき)。

1.2 使用上の推奨事項

ここでは、Oracle Identity GovernanceまたはOracle Identity Managerの使用しているバージョンに応じて、デプロイおよび使用できるSAP UMEコネクタ・バージョンに関する推奨事項について説明します。

ノート:

Oracle Identity Governanceでは、SAP User ManagementコネクタとSAP User Management Engineコネクタの両方をインストールして構成できます。

SAP GRCターゲット・システムのコネクタを構成して、Access Risk AnalysisまたはAccess Request Management機能のいずれかを使用できます。

  • Oracle Identity Governanceリリース12c BP02 (12.2.1.3.2)または12.2.1.4.0を使用している場合は、このコネクタの最新バージョン12.2.1.xを使用します。Identity Self Serviceの「管理」 タブの「アプリケーション」 オプションを使用してコネクタをデプロイします。

  • 表1-1の「CIベースのコネクタの要件」列に記載されているように、Oracle Identity Managerリリース11.1.2.xを使用している場合は、SAP User Management Engineコネクタの11.1.xバージョンを使用してください。このコネクタの12.2.1.xバージョンをOracle Identity Managerリリース11.1.2.xとともに使用する場合は、CIベース・モードでのみインストールおよび使用できます。AOBアプリケーションを使用する場合は、Oracle Identity Governanceリリース12.2.1.3.0にアップグレードする必要があります。

1.3 動作保証されている言語

コネクタでサポートされている言語は次のとおりです。

  • アラビア語

  • 中国語(簡体字)

  • 中国語(繁体字)

  • チェコ語

  • デンマーク語

  • オランダ語

  • 英語

  • フィンランド語

  • フランス語

  • フランス語(カナダ)

  • ドイツ語

  • ギリシャ語

  • ヘブライ語

  • ハンガリー語

  • イタリア語

  • 日本語

  • 韓国語

  • ノルウェー語

  • ポーランド語

  • ポルトガル語

  • ポルトガル語(ブラジル)

  • ルーマニア語

  • ロシア語

  • スロバキア語

  • スペイン語

  • スウェーデン語

  • タイ語

  • トルコ語

1.4 サポートされているコネクタ操作

これらは、ターゲット・システムにおける、コネクタでサポートされる操作のリストです。

表1-2 SAP UMEおよびSAP AC UMEコネクタでサポートされているコネクタ操作

操作 SAP UMEでのサポート SAP AC UMEでのサポート
ユーザー管理    
ユーザー・アカウントの作成 〇 〇
ユーザー・アカウントの変更 〇 〇
ユーザー・アカウントの削除 〇 〇
ユーザー・アカウントの有効化 〇 〇
ユーザー・アカウントの無効化 〇 〇
ユーザー・アカウントのロック 〇 〇
ユーザー・アカウントのロック解除 〇 〇
ユーザー・アカウントへのロールの割当て 〇 〇
ユーザー・アカウントへの複数のロールの割当て 〇 〇
ユーザー・アカウントからのロールの削除 〇 〇
ユーザー・アカウントからの複数のロールの削除 〇 〇
ユーザー・アカウントへのグループの割当て 〇 ×
ユーザー・アカウントへの複数のグループの割当て 〇 ×
ユーザー・アカウントからのグループの削除 〇 ×
ユーザー・アカウントからの複数のグループの削除 〇 ×
権限    
ロールの追加 〇 〇
複数のロールの追加 〇 〇
ロールの削除 〇 〇
複数のロールの削除 〇 〇

1.5 コネクタのアーキテクチャ

SAP UMEコネクタは、Identity Connector Framework (ICF)を使用して実装されます。

コネクタは、SAP User Management Engineにリンクされているデータ・ソースを使用するアプリケーションにアカウント作成または変更リクエストを送信するためのフロントエンドとして、Oracle Identity Governanceを設定します。

コネクタは、データ・ソースで直接実行されたプロビジョニング操作によって追加または変更されたすべてのアカウント・データを、SAP User Management Engineを介してOracle Identity Governanceにリコンサイルします。

図1-1に、SAP User Management EngineとOracle Identity Governanceを統合するコネクタを示します。

図1-1 コネクタのアーキテクチャ

図1-1の説明が続きます
「図1-1 コネクタのアーキテクチャ」の説明

図に示すように、SAP User Management Engineはデータ・ソース(ABAPモジュール、AS (Application Server) Javaデータ・ソース、またはLDAPベースのソリューションのいずれか)に格納されているユーザー・データの管理ツールとして構成されます。SAP User Management Engine UIを介して行われたユーザー・データの変更は、データ・ソースを使用するアプリケーションまたはLDAPベース・ソリューションのUIに反映されます。

アプリケーションを作成することで、SAP User Management EngineをOracle Identity Governanceのターゲット・リソースとして構成します。

Oracle Identity Governanceが送信するプロビジョニング・リクエストは、SPMLサービスを経由して、SAP User Management Engineにリンクされているデータ・ソースを使用するアプリケーションまたはシステムにルーティングされます。プロビジョニング・リクエストによって行われたユーザー・データの変更は、SAP User Management Engine UIを使用して表示できます。

アカウント管理モードで実行するようにコネクタを構成できます。アカウント管理は、ターゲット・リソース管理とも呼ばれます。アカウント管理モードでは、ターゲット・システムはターゲット・リソースとして使用されます。コネクタのこのモードでは、次の操作が可能です。

  • プロビジョニング

    プロビジョニングでは、Oracle Identity Governanceを使用して、ターゲット・システムでユーザーを作成または更新します。SAP User Management EngineリソースをOIGユーザーに割り当てる(プロビジョニングする)と、その操作の結果として、そのユーザーのアカウントがSAP UMEで作成されます。Oracle Identity Governance関連では、プロビジョニングという用語は、Oracle Identity Governanceを使用したターゲット・システム・アカウントに対する更新を意味する場合にも使用されます。

    プロビジョニング時には、アダプタがプロセス・フォームを介した送信されたプロビジョニング・データをターゲット・システムに搬送します。SAP User Management EngineのSPMLサービスはアダプタからプロビジョニング・データを受け取り、必要なプロビジョニング操作を実行して、レスポンスをOracle Identity Governanceのアダプタに返します。

  • リコンシリエーション

    コネクタによって提供されたスケジュール済タスクがSPMLクライアントとして機能して、SPMLリクエストをアプリケーション・サーバーのSPMLサービスに送信します。

    リコンシリエーション時には、スケジュール済タスクによってSPMLサービスとの接続が確立されます。リコンシリエーション基準が、SPMLリクエストを介してこのSPMLサービスに送信されます。SPMLサービスはリクエストを処理して、リコンシリエーション基準に一致するユーザー・レコードを含むSPMLレスポンスを返します。スケジュール済タスクはこれらのレコードをOracle Identity Governanceに送信します。

    ターゲット・システムからフェッチされた各レコードは、OIGユーザーにすでにプロビジョニングされているSAP User Management Engineリソースと比較されます。一致が見つかった場合、レコードに加えられた更新が、Oracle Identity GovernanceのSAP User Management Engineリソースにコピーされます。一致が見つからなかった場合、レコードのユーザーIDが、各OIGユーザーのユーザーIDと比較されます。一致が見つかった場合、ターゲット・システム・レコードのデータを使用して、SAP User Management EngineリソースがOIGユーザーにプロビジョニングされます。

1.6 サポートされているデプロイ構成

ここでは、コネクタのサポートされているデプロイ構成のリストを示します。

コネクタは、ターゲット・システムとの直接統合を可能にすることに加え、SAP GRCのAccess Risk AnalysisモジュールおよびAccess Request Managementモジュールとのインタフェースとして機能するように使用することもできます。ターゲット・システム(SAP NetWeaver Java Application Server)およびSAP GRCのこれら2つのモジュールでは、様々なデプロイメント構成が提供されます。次の各項で、コネクタのサポートされるデプロイメント構成について説明します。

1.6.1 Access Request Managementを使用したユーザー管理

Access Request Managementは、SAP GRCスイート内のモジュールです。SAP環境では、アカウントの作成および変更のプロビジョニング・リクエストを受信するフロント・エンドとしてAccess Request Managementを設定できます。Access Request Managementでは、これらのリクエストを処理するワークフローを構成することが可能で、承認者として指定されたユーザーがこれらのリクエストを処理します。

ノート:

このガイドにおいて、Access Request Managementの構成というフレーズは、Oracle Identity GovernanceとSAP GRC Access Request Managementとの統合の構成を意味します。

動作環境によっては、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-2に、コネクタのこのモードでのデータ・フローを示します。

図1-2 SAP GRC Access Request ManagementをOracle Identity Governanceおよびターゲット・システムに統合するコネクタ

図1-2の説明が続きます
「図1-2 SAP GRC Access Request ManagementをOracle Identity Governanceおよびターゲット・システムに統合するコネクタ」の説明

プロビジョニング操作中に実行されるステップの詳細なステップは次のとおりです。

  1. プロビジョニング操作が、ダイレクト・プロビジョニング、リクエストベースのプロビジョニングまたはアクセス・ポリシーの変更を介して開始されます。

  2. SPMLユーザーの作成リクエストがターゲット・システムで実行され、次のいずれかが決定されます。

    • ユーザーの作成操作では、SPMLユーザー作成リクエストがターゲット・システムにユーザーが存在すると判断した場合、エラー・メッセージが表示されます。ユーザーが存在しない場合は、プロビジョニング・データからリクエストが作成され、SAP GRC Access Request Managementに送信されます。

    • ユーザーの作成操作では、SPMLユーザー作成リクエストがターゲット・システムにユーザーが存在しないと判断した場合、エラー・メッセージが表示されます。ユーザーが存在する場合は、プロビジョニング・データからリクエストが作成され、SAP GRC Access Request Managementに送信されます。

    コネクタでは、次のSAP GRCのWebサービスを使用して、リクエストの送信およびレスポンスの受信が行われます。

    • GRAC_USER_ACCESS_WS: このWebサービスはリクエストの送信に使用されます。

    • GRAC_REQUEST_STATUS_WS: このWebサービスはリクエスト・ステータスのフェッチに使用されます。

    • GRAC_AUDIT_LOGS_WS: このWebサービスは、SAP GRC Access Request Managementのログにエラー・メッセージがあるかどうかをチェックするために使用されます。

    プロセス・フォームには、基本的なユーザー管理用とAccess Request Management用の両方のフィールドが保持されています。ただし、ユーザーの作成操作では、プロセス・フォームのAccess Request Managementフィールド(属性)のみが使用されます。

    ノート:

    SAP GRC Access Request Managementでは、パスワードは処理されません。したがって、「ユーザーの作成」プロビジョニング操作中は、パスワード・フィールドに入力する値はすべて無視されます。

    Access Request Managementを構成する際のパスワードの設定の詳細は、「プロビジョニング実行のガイドライン」を参照してください。

    ユーザーの変更操作では、マッピングがこれらの参照定義に存在する属性に対してのみ、リクエストが作成されます。これらの参照定義に存在しない属性の値を指定した場合、値はコネクタからターゲット・システムに直接送信されます。

    ノート:

    ユーザーの変更操作では、SAP GRC Access Request Managementでマップされる属性およびターゲット・システムで直接更新される属性の値を指定できます。

  3. 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リクエスト・タイプ: このフィールドには、リクエストのタイプ(アカウントの新規作成、アカウントの変更、アカウントの削除、新規作成、変更など)が保持されます。

  4. リクエストは、SAP GRC Access Request Managementで定義されたワークフローを介して渡されます。次のいずれかの結果になります。

    • Access Request Managementがリクエストをクリアした場合、ターゲット・システム(SAP UME)でユーザーのアカウントが作成または変更される結果になります。リクエストのステータスは「OK」に設定されます。次に、Oracle Identity Governanceのログにメッセージが記録されます。

    • Access Request Managementでプロビジョニング・リクエストが却下されると、リクエストのステータスは「Failed」に設定されます。次に、Oracle Identity Governanceのログにメッセージが記録されます。

    • Access Request Managementとターゲット・システム間の通信中にエラーが発生した場合、リクエストは「Open」ステータスのままになります。操作が失敗したことを示すメッセージが、リクエストに関連付けられた監査ログに記録されます。エラー・メッセージがコンソールに表示されます。

アカウント・リクエスト管理のサマリー: SAP動作環境でSAP GRC Access Request Managementが構成および有効化された場合

  1. Oracle Identity Governanceでのプロビジョニング操作からのデータは、SAP GRC Access Request Managementに送信されます。

  2. SAP GRC Access Request Managementで定義されたワークフローによって、リクエストがSoD検証のためにSAP GRC Access Risk Analysisモジュールに送信されます。

  3. SoD検証チェックをクリアした後、プロビジョニング・リクエストがターゲット・システムに実装されます。

  4. Oracle Identity Governanceから実行されるスケジュール済タスクによって、ターゲット・システムからの操作結果がOracle Identity Governanceにリコンサイルされます。

1.6.2 コネクタのログの監査証跡詳細

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.3 SoDを使用したユーザー管理

SAP動作環境で、SAP GRCのAccess Risk Analysisモジュールが職務の分離(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に、コネクタのこのモードでのデータ・フローを示します。

図1-3 SoD検証プロセス中のデータ・フロー

図1-3の説明が続きます
「図1-3 SoD検証プロセス中のデータ・フロー」の説明

プロビジョニング操作中に実行されるステップの概要は次のとおりです。

  1. プロビジョニング操作が、ダイレクト・プロビジョニング、リクエストベースのプロビジョニングまたはアクセス・ポリシーの変更を介して開始されます。

  2. このリクエストは、Oracle Identity Governanceのリソース承認ワークフローからSoDエンジン(SAP GRC Access Risk Analysis)に送信されます。

  3. SoDエンジンでは、事前定義のルールを使用して、権限割当てがSoD違反につながるかどうかをチェックします。このチェックの結果はOracle Identity Governanceに送り返されます。

  4. リクエストがSoD検証に失敗した場合、改善ステップが行われるように承認ワークフローを構成できます。ユーザーのリクエストがSoD検証にパスし、Oracle Identity Governanceの承認者がリクエストを承認した場合、リソース・プロビジョニング・ワークフローが開始されます。

  5. このリソース・プロビジョニング・ワークフローは、SoD検証を再度実行するように構成できます。これは、権限割当てがターゲット・システムにプロビジョニングされる直前に、権限割当てのSoDコンプライアンスを確認するためです。また、この検証がリソース承認ワークフローで通過した場合、リソース・プロビジョニング・ワークフローのSoD検証チェックをバイパスするように構成することもできます。

  6. ターゲット・システムで必要な変更がリソース・プロビジョニング・ワークフローで実行され、操作の結果がOracle Identity Governanceに送り返されて保存されます。

1.6.4 SoDとAccess Request Managementを両方使用したユーザー管理

SAP動作環境でSAP GRC Access Risk AnalysisとAccess Request Managementの両方が構成されている場合、Access Risk AnalysisとAccess Request Managementモジュールが動作環境内で個別に構成されている(つまり、リンクされていない)モジュールである場合にかぎり、SoDとAccess Request Managementの両方のコネクタ機能を同時に構成します。

ノート:

プロビジョニング・リクエストをSoD検証用にSAP GRC Access Risk Analysisに送信するようにSAP GRC Access Request Managementが構成されている場合、コネクタのSoD機能を構成することはできません。

アカウント管理プロセスのサマリー: SAP GRC Access Risk AnalysisとSAP GRC Access Request Managementが有効化された場合

  1. Oracle Identity Governanceでのプロビジョニング操作からのデータは、まずSoD検証のためにSAP GRC Access Risk Analysisモジュールに送信されます。

  2. SoD検証チェックをクリアしたプロビジョニング・リクエストは、SAP GRC Access Request Managementに送信されます。

  3. リクエストがSAP GRC Access Request Managementワークフローをクリアすると、プロビジョニング・リクエストがターゲット・システムに実装されます。

  4. Oracle Identity Governanceから実行されるスケジュール済タスクによって、ターゲット・システムからの操作結果がOracle Identity Governanceにリコンサイルされます。

1.6.5 アプリケーション構成の使用に関するガイドライン

ここでは、アプリケーション構成を使用する際に適用する必要があるガイドラインを示します。

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を介して実行します。

次の各項で、サポートされるアプリケーション構成のガイドラインを説明します。

ノート:

基本的なユーザー管理構成およびSoDを使用するUser Management Engine構成に関する特別なガイドラインはありません。

1.6.5.1 SoDを使用するUser Management EngineとAccess Request Management

次のデプロイメント・ガイドラインは、SAP GRC Access Risk AnalysisとSAP GRC 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.5.2 Access Request Managementを使用したユーザー管理

次のデプロイメント・ガイドラインは、SAP動作環境でSAP GRC Access Request Managementが構成され、有効化されているシナリオで適用してください。

ノート:

SAP GRC Access Risk Analysisは、SAP GRC Access Request Managementにリンク付けされたモジュールとして構成されているか、またはまったく使用されていません。

  • SAP GRC Access Request Managementで、アカウント作成に対するステージなしの承認を構成します。すなわち、アカウント作成リクエストはAccess Request Managementで自動的に承認される必要があります。

    このガイドラインについては、この項で前述したシナリオを参照してください。

  • コネクタのAccess Request Management機能を構成します。

  • コネクタのSoD機能は構成しないでください。

1.6.6 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回の操作で送信できるのは、親フォーム・リクエストまたは子フォーム・リクエストのいずれかです。親フォーム・リクエストと子フォーム・リクエストの両方を同時に送信することはできません。

1.7 サポートされているコネクタ機能のマトリックス

AOBアプリケーションとCIベース・コネクタでサポートされている機能のリストを示します。

表1-3 サポートされるコネクタの機能マトリックス

機能 AOBコネクタ CIベース・コネクタ
完全リコンシリエーション 〇 〇
制限付き(フィルタ)リコンシリエーション 〇 〇
SAP GRC Access Request Managementを介したプロビジョニング・リクエスト 〇 〇
権限リクエストのSoD検証 〇 〇
アカウントの有効化と無効化 〇 〇
複数のデータ・ソースに対するユーザー関連データのプロビジョニングとリコンシリエーション 〇 〇
フェデレーテッド・ポータル・ネットワーク(FPN)構成でのロール割当ての削除 〇 〇
アカウント・データの変換と検証の構成 〇 〇
すべてのリコンシリエーションおよびプロビジョニング操作から除外するアカウントの指定 〇 〇
接続のテスト 〇 ×

1.8 コネクタの機能

コネクタの機能には、権限リクエストのSoD検証、完全リコンシリエーション、制限付きリコンシリエーション、その他の機能(複数データ・ソースのサポート、フェデレーテッド・ポータル・ネットワーク(FDN)でのリモート・ロール割当てのサポートなど)が含まれます。

コネクタには、次のような機能があります。

1.8.1 完全リコンシリエーション

完全リコンシリエーションでは、すべてのレコードがターゲット・システムからOracle Identity Governanceにフェッチされます。

ノート:

SPML UME APIは、最終変更日の値が指定日より後のレコードは戻しません。このため、コネクタは増分リコンシリエーションをサポートできません。このことは、「ターゲット・システムの機能および特定のコネクタに関連する制限事項」にも記載されています。

完全リコンシリエーションでは、すべてのレコードがターゲット・システムからOracle Identity Governanceにフェッチされます。リコンシリエーション時には、SPMLリクエストがターゲット・システムに送信され、SAPで許可された有効な文字で始まるユーザーIDを持つユーザー・アカウントがフェッチされます。すべての有効な文字のリストは、表3-2のlogonNameInitialSubstringエントリを参照してください。

完全リコンシリエーション時には、ターゲット・システム・アカウントごとに1つのリコンシリエーション・イベントが生成されます。詳細は、「完全リコンシリエーションの実行」を参照してください。

1.8.2 制限付き(フィルタ)リコンシリエーション

指定されたフィルタ基準に基づいて、ターゲット・システムからレコードをリコンサイルできます。リコンシリエーション実行時に、Oracle Identity Governanceにフェッチされるレコードを制限またはフィルタ処理するために、リコンサイルが必要な追加または変更されたターゲット・システム・レコードのサブセットを指定できます。

ユーザー・リコンシリエーション・スケジュール済ジョブのFilter Suffix属性の値としてリコンシリエーション・フィルタを設定できます。Filter Suffix属性は、ターゲット・システムからのフィルタ済レスポンスを取得するベースとなるAPIにフィルタを割り当てるのに役立ちます。

詳細は、「制限付きリコンシリエーションの実行」を参照してください。

1.8.3 SAP GRC Access Request Managementによるプロビジョニング・リクエストのルーティング

SAP GRC Access Request Managementとともに機能するようにコネクタを構成できます。

この機能の詳細は、「Access Request Managementを使用したユーザー管理」を参照してください。

1.8.4 権限リクエストのSoD検証

Oracle Identity Governanceでの権限リクエストをSoDエンジンを使用して検証できます。

コネクタではOracle Identity GovernanceでのSoD機能がサポートされており、この機能は次のように更新されています。

  • SoD起動ライブラリ(SIL)は、Oracle Identity Governanceにバンドルされています。SILは、任意のSoDエンジンとのプラガブル統合インタフェースとして機能します。

  • SoDエンジンとしてのSAP GRCとともに機能するようにコネクタを構成します。

    ノート:

    デフォルトで、承認ワークフローおよび関連オブジェクト・フォームはSAP GRCのSoD検証機能用に構成されています。これらを使用して、独自の承認ワークフローおよびオブジェクト・フォームを作成できます。

  • SoDエンジンは、コネクタを介して送信されるロール権限のリクエストを処理します。この予防シミュレーション方法は、リクエストされた権限がユーザーに割り当てられる前に、ユーザーへの権限割当てで競合する可能性のあるものを特定し、修正するうえで役立ちます。

SoDの構成の詳細は、「SoD (職務の分離)の構成」を参照してください。

ノート:

SODを使用したSAPユーザー管理を使用している場合は、「権限」タブから権限をリクエストしてください。

1.8.5 有効なアカウントと無効なアカウント

有効期限開始と有効期限終了は、ターゲット・システムの2つのユーザー属性です。SAPの特定ユーザーの有効期限終了日が現在の日付より前の場合、アカウントは無効状態です。それ以外の場合、アカウントは有効状態です。同じ動作が、リコンシリエーションを介してOracle Identity Governanceで複製されます。また、プロビジョニング操作を介して、有効期限終了日の値を現在の日付または過去の日付に設定することもできます。

ノート:

アカウントの有効状態または無効状態は、アカウントのロック状態またはロック解除状態とは関係ありません。

1.8.6 複数データ・ソースのサポート

SAP User Management Engineコネクタは、ユーザー関連データと複数データ・ソース(Lightweight Directory Access Protocol (LDAP)ディレクトリ、SAP NetWeaver Application Server Javaのシステム・データベース、Application Server ABAPのユーザー管理など)とのプロビジョニングおよびリコンサイル用に構成できます。すなわち、データ・ソース構成に関係なく、ユーザー管理エンジンからユーザー管理操作を実行するように、このコネクタを構成できます。

1.8.7 フェデレーテッド・ポータル・ネットワークでのリモート・ロール割当てのサポート

フェデレーテッド・ポータル・ネットワーク(FPN)によって、SAPおよびSAP以外の複数のポータルを持つ組織は、独立したポータル間でコンテンツを共有できます。FPNでは、プロデューサがアプリケーションを保持および実行します。コンシューマは、プロデューサ・ポータルへのリダイレクトを管理します。FPN構成では、リモート・ロール割当てコンテンツ使用状況モードを使用して、コンテンツをネットワーク全体で共有できます。コンシューマは、プロデューサから提供されたロールを割り当てることができます。FPN構成でリモート・ロール割当てをサポートするようにSAP User Management Engineコネクタを使用できます。

1.8.8 コネクタ・サーバーのサポート

コネクタ・サーバーはICFによって提供される機能の1つです。コネクタ・アーキテクチャでは、1つ以上のコネクタ・サーバーを使用することで、アプリケーションと外部にデプロイされたバンドルとの通信が可能になります。

アプリケーションと同じVMでJavaコネクタ・バンドルを実行しない場合は、Javaコネクタ・サーバーを使用すると便利です。パフォーマンス向上のためにJavaコネクタを別のホストで実行すると、効果を発揮できます。

コネクタ・サーバーのインストール、構成および実行、ならびにコネクタ・サーバーへのコネクタのインストールの詳細は、『Oracle Fusion Middleware Oracle Identity Governanceのためのアプリケーションの開発とカスタマイズ』のアイデンティティ・コネクタ・サーバーの使用に関する項を参照してください。

1.8.9 アカウント・データの変換および検証

アプリケーションの作成時にGroovyスクリプトを作成して、リコンシリエーション操作およびプロビジョニング操作の際にOracle Identity Governanceとの間で送受信されるアカウント・データの変換と検証を構成できます。

詳細は、『Oracle Fusion Middleware Oracle Identity Governanceでのセルフ・サービス・タスクの実行』のプロビジョニングおよびリコンシリエーション属性の検証および変換に関する項を参照してください。

1.8.10 リソース除外リストのサポート

リコンシリエーションおよびプロビジョニング操作から除外する必要のあるアカウントのリストを指定できます。

除外リストで指定したユーザーIDのアカウントは、リコンシリエーションおよびプロビジョニング操作の影響を受けません。

リソース除外リストの構成の詳細は、『Oracle Fusion Middleware Oracle Identity Governanceでのセルフ・サービス・タスクの実行』のリソース除外のための検証Groovyスクリプトに関する項を参照してください。