Oracle Cloud Infrastructureドキュメント

汎用RESTとの統合

Generic REST Orchestrated Systemは、Oracle Access GovernanceをRESTベースのアイデンティティ対応システムと統合するソリューションを提供します。RESTベースのアイデンティティ対応システムは、アイデンティティ管理のためにREST APIまたはインタフェースを公開する任意のシステムです。

汎用RESTオーケストレート済システム概要

Generic REST Orchestrated Systemには、次のような機能があります。
  • 認可ソースまたは管理対象システムの完全/増分データ・ロード
  • リアルタイムのプロビジョニング
  • クラウド・ネイティブなサーバーレス機能統合により、RESTベースのアイデンティティ対応システム・スキーマ、リクエスト、レスポンス、テスト・テンプレートを定義

汎用RESTオーケストレート済システムは、スキーマ、リクエストおよびレスポンスの定義が固定されていないという点で他のシステムとは異なります。他のオーケストレート済システムには、スキーマ、リクエスト、レスポンスおよびテスト・テンプレートが、適用先の認可ソースまたは管理対象システム用に事前にロードされています。汎用RESTオーケストレート済システムを任意のRESTベースのアイデンティティ対応システムに適用できます。スキーマ、リクエスト、レスポンスおよびテスト・テンプレートは、オーケストレート済システムの作成時ではなく実行時にロードされます。

認可ソースまたは管理対象システムごとに、次のテンプレートを作成する必要があります。
  • grc-schema-template: このテンプレートは、統合する認可ソースまたは管理対象システムのスキーマを定義します。
  • grc-request-template: このテンプレートは、アイデンティティ・データをリクエストするために認可ソースまたは管理対象システムAPIを呼び出すために必要なリクエスト形式(ヘッダー、URL、リクエスト・パラメータ、リクエスト本文)を定義します。
  • grc-response-template: このテンプレートは、アイデンティティ・データとアカウント・データのレスポンス形式を定義します。
  • grc-test-template: このテンプレートは、Oracle Access Governanceと認可ソースまたは管理対象システムの間の接続をテストするAPIを定義します。
操作が呼び出されると、次のパラメータがOCI関数に渡されます。
  • オーケストレート済システム名
  • エンティティ名(アイデンティティまたはアカウント)
  • 操作名

OCI関数がコールされ、オーケストレート済システムに関連するテンプレートを含むJSONファイルが返されます。

前提条件

Generic REST Orchestrated Systemをインストールおよび構成する前に、次の前提条件およびタスクを考慮する必要があります。

動作保証されたコンポーネント

管理対象システムは次のいずれかです。

  • RESTサービスをサポートするアイデンティティ対応システム

サポートされているモード

Generic REST Orchestrated Systemでは、次の構成モードがサポートされています。

  • 認可ソース
  • 管理されたシステム

Generic REST Orchestrated Systemでサポートされるユースケース

Generic REST Orchestrated Systemを使用すると、RESTサービスからアイデンティティ・データをOracle Access Governanceにオンボーディングし、企業内のアイデンティティ対応システムの復元と統合サイクルでアイデンティティを効率的に管理できます。

ビジネスのユースケースの例として、20を超えるクラウド・アプリケーションを持つ大手ロジスティクス企業について考えます。これらのクラウド・アプリケーションは、データが手動で入力されており、スプレッドシートやカスタムでコーディングされたプロセス・フローを使用して管理されているため、効率が悪くなっています。このため、この会社では、クラウド・アプリケーションとOracle Access Governanceを統合して、操作を合理化し、組織的な効率を高め、同時に運用コストを抑えたいと考えています。これらのクラウド・アプリケーションとOracle Access Governanceを統合するには、2つのアプローチがあります。1つ目のアプローチは、これらのアプリケーションのそれぞれにポイントツーポイントのコネクタをデプロイすることです。この方法のデメリットとして、次の点が挙げられます。

  • 各アプリケーションに対するポイントツーポイントのコネクタを識別してデプロイするための時間と労力がかかる。

  • 各アプリケーション用のコネクタの管理および保守のためのオーバーヘッドが増える。

  • ポイントツーポイントのコネクタを、すべてのアプリケーションには設定できない。このようなシナリオでは、カスタム・コネクタの開発が必要になり、このカスタム・コネクタの開発、デプロイおよびテストの時間と手間が増える。

このアプローチの代替として、汎用RESTオーケストレート済システムを使用して、すべてのクラウド・アプリケーションをOracle Access Governanceと統合する方法があります。Generic REST Orchestrated Systemが提供する機能を使用すると、クラウド・アプリケーションごとにカスタム・コネクタを構築するための追加のリソースや時間を費やすことなく、すべてのクラウド・アプリケーションのアカウントを管理できます。

Generic REST Orchestrated Systemは、企業がOracle Access Governanceを活用してマネージド・システムと統合し、アイデンティティ・ガバナンスを実現するのに役立ちます。これらのマネージド・システムには、SaaS、PaaS、自社製アプリケーションなど、REST APIを公開するすべてのアプリケーションが含まれています。

Generic REST Orchestrated Systemを使用するいくつかのシナリオ例を次に示します:

  • ユーザー管理

    Generic REST Orchestrated Systemでは、Oracle Access Governanceでアイデンティティとして定義し、アイデンティティ・コレクションおよびロールに割り当てることで、リソースにアクセスできる個人を管理できます。アイデンティティは、データ・ロード時に汎用RESTなどの任意の認可オーケストレート済システムから作成されます。

  • アクセス・コントロール

    Generic REST Orchestrated Systemは、アイデンティティ・コレクション、ロール、アクセス・バンドルおよびポリシーを介してアクセス制御を管理します。使用されているオーケストレート済システムに応じて、Oracle Access Governanceセルフ・サービス機能(特にアクセスのリクエスト)を使用してアクセスを管理できます。たとえば、Generic REST Orchestrated Systemを使用すると、Oracle Access Governanceの事前定義済アクセス・ポリシーに基づいて、システムへのアクセスを自動的に割り当てたり、取り消すことができます。新しいユーザーが特定のロールに追加されると、それらのユーザーはアクセス・ポリシーの対象となるシステム内で対応するアクセス権を自動的に得ることになります。

RESTベースのIdentity Awareシステムに接続するためのOCIサーバーレス機能の設定

汎用RESTオーケストレート済システムでは、RESTベースのアイデンティティ対応システムへの接続に、OCIサーバーレス関数からのサポートが必要です。

Generic Rest Orchestrated Systemで使用するOCI関数を設定するには、RESTベースのIdentity Aware Systemに接続するためのOCIサーバーレス関数の設定を参照してください。

構成

OCI Functionsおよびテンプレートの詳細を入力してRESTベースのシステムを統合することで、RESTベースのアイデンティティ対応システムとOracle Access Governanceの統合を確立できます。これを実現するには、Oracle Access Governanceコンソールで使用可能なOrchestrated System機能を使用します。

OCI Functionsおよびテンプレートの詳細を入力してRESTベースのシステムを統合し、RESTベースのアイデンティティ対応システムとOracle Access Governanceの統合を確立します。Oracle Access GovernanceコンソールのOrchestrated System機能を使用します。

Oracle Access Governanceでは、リソース・プリンシパルを使用してOCI関数にアクセスし、起動します。既存のオーケストレート済システムがあり、移行する必要がある場合は、リソース・プリンシパル・アクセスへのAPIキー・アクセスの移行を参照してください。

「Orchestrated Systems」ページに移動します。

次のステップに従って、Oracle Access Governanceコンソールの「Orchestrated Systems」ページにナビゲートします。
  1. Oracle Access Governanceのナビゲーション・メニュー・アイコンナビゲーション・メニューから、「Service Administration」→「Orchestrated Systems」を選択します。
  2. ワークフローを開始するには、「オーケストレート済システムの追加」ボタンを選択します。

システムの選択

ワークフローの「システムの選択」ステップで、オンボーディングするシステムのタイプを指定できます。「検索」フィールドを使用して、名前で必要なシステムを検索できます。「汎用RESTコネクタ」タイルを選択します。このタイルを選択すると、オーケストレート済システムの構成ステップを示すダイアログ・ページが表示されます。これには、RESTベースのアイデンティティ対応システムへの接続に必要なOCI関数のサンプル実装へのリンクが含まれます。まだ実行していない場合は、idm-agcs-generic-rest-reference-implementation.zipファイルをダウンロードし、この例に基づいて独自のOCI関数を開発する必要があります。サンプル実装の詳細は、「サンプル実装の設定」を参照してください。必要なOCI関数の開発方法の詳細は、RESTベースのIdentity Awareシステムに接続するためのOCIサーバーレス関数の設定および一般的なRestスキーマ検出を参照してください。

選択した後、右側の「選択した内容」の下に「汎用RESTコネクタ」の値が表示されます。「次へ」を選択します。

詳細の入力

ワークフローの「詳細の追加」ステップで、オーケストレート済システムの詳細を入力します:
  1. 「名前」フィールドに、接続先のシステムの名前を入力します。
  2. 「説明」フィールドに、システムの説明を入力します。
  3. このオーケストレート済システムが信頼できるソースかどうか、および次のチェック・ボックスを設定してOracle Access Governanceが権限を管理できるかどうかを決定します。
    • これは私のアイデンティティの認証ソースです

      次の項目から選択します。

      • アイデンティティとその属性のソース: システムは、ソース・アイデンティティおよび関連する属性として機能します。新しいアイデンティティは、このオプションを使用して作成されます。
      • アイデンティティ属性のソースのみ: 追加のアイデンティティ属性の詳細が取り込まれ、既存のアイデンティティに適用されます。このオプションは、新規アイデンティティ・レコードを取込みまたは作成しません。
    • このシステムの権限を管理します
    各ケースのデフォルト値は「未選択」です。
  4. 「次へ」を選択します。

所有者の追加

リソース所有権を関連付けるには、プライマリ所有者と追加所有者を追加します。これにより、これらの所有者は所有するリソースを管理(読取り、更新または削除)できるため、セルフサービスが促進されます。デフォルトでは、リソース作成者はリソース所有者として指定されます。1人のプライマリ所有者と最大20人の追加所有者をリソースに割り当てることができます。
ノート

サービス・インスタンスに対して最初のオーケストレート済システムを設定する場合、「アイデンティティの管理」セクションからアイデンティティを有効にした後にのみ所有者を割り当てることができます。
所有者を追加するには:
  1. 「プライマリ所有者は誰ですか。」フィールドで、Oracle Access Governanceのアクティブ・ユーザーをプライマリ所有者として選択します。
  2. 「他の所有者は誰ですか。」リストで1つ以上の追加所有者を選択します。リソースに最大20人の追加所有者を追加できます。
リストの「プライマリ所有者」を表示できます。すべての所有者は、所有するリソースを表示および管理できます。

アカウント設定

ワークフローの「アカウント設定」ステップで、システムが管理対象システムとして構成されている場合、Oracle Access Governanceでアカウントを管理する方法を入力します:
  1. 権限が要求され、アカウントがまだ存在しない場合は、このオプションを選択して新しいアカウントを作成します。このオプションはデフォルトで選択されています。選択すると、権限が要求されたときにアカウントが存在しない場合、Oracle Access Governanceによってアカウントが作成されます。このオプションをクリアすると、権限はオーケストレート済システム内の既存のアカウントに対してのみプロビジョニングされます。アカウントが存在しない場合、プロビジョニング操作は失敗します。
  2. アカウント作成時の通知電子メールの受信者を選択します。デフォルトの受信者は「ユーザー」です。受信者が選択されていない場合、アカウントの作成時に通知は送信されません。
    • ユーザー
    • ユーザー・マネージャ
  3. 既存のアカウントの構成
    ノート

    これらの構成を設定できるのは、システム管理者によって許可されている場合のみです。グローバル・アカウント終了設定が有効になっている場合、アプリケーション管理者は、調整されたシステム・レベルでアカウント終了設定を管理できません。
    1. 早期終了開始時のアカウントの処理の選択: 早期終了の開始時に実行する処理を選択します。これは、正式な退職日より前にアイデンティティ・アクセスを取り消す必要がある場合に発生します。
      • 削除: Oracle Access Governanceで管理されているすべてのアカウントおよび権限を削除します。
        ノート

        特定のオーケストレート済システムでアクションがサポートされていない場合、アクションは実行されません。
      • 無効化: すべてのアカウントを無効化し、Oracle Access Governanceで管理される権限を無効化します。
        • 無効化されたアカウントの権限の削除: 残存アクセス権がゼロであることを確認するには、これを選択して、アカウントの無効化時に直接割り当てられた権限およびポリシーで付与された権限を削除します。
      • アクションなし: アイデンティティにOracle Access Governanceによる早期終了のフラグが付けられている場合、アクションは実行されません。
    2. 退職日のアカウントの処理の選択: 正式な退職時に実行する処理を選択します。これは、正式な退職日にIDアクセスを取り消す必要がある場合に発生します。
      • 削除: Oracle Access Governanceで管理されているすべてのアカウントおよび権限を削除します。
        ノート

        特定のオーケストレート済システムで「削除」アクションがサポートされていない場合、アクションは実行されません。
      • 無効化: すべてのアカウントを無効化し、Oracle Access Governanceで管理される権限を無効化します。
        • 無効化されたアカウントの権限の削除: 残存アクセス権がゼロであることを確認するには、これを選択して、アカウントの無効化時に直接割り当てられた権限およびポリシーで付与された権限を削除します。
        ノート

        特定のオーケストレート済システムで「無効化」アクションがサポートされていない場合は、アカウントが削除されます。
      • アクションなし: Oracle Access Governanceでは、アカウントおよび権限に対するアクションは実行されません。
  4. アイデンティティが企業を離れたときは、そのアカウントへのアクセス権を削除する必要があります。
    ノート

    これらの構成を設定できるのは、システム管理者によって許可されている場合のみです。グローバル・アカウント終了設定が有効になっている場合、アプリケーション管理者は、調整されたシステム・レベルでアカウント終了設定を管理できません。

    アカウントに対する次のアクションのいずれかを選択します。

    • 削除: Oracle Access Governanceで管理されているすべてのアカウントおよび権限を削除します。
    • 無効化: すべてのアカウントを無効化し、権限を非アクティブとしてマークします。
      • 無効化されたアカウントの権限の削除: アカウントの無効化時に直接割り当てられ、ポリシーで付与された権限を削除して、残存アクセスをゼロにします。
    • アクションなし: アイデンティティが組織を離れるときにアクションを実行しません。
    ノート

    これらのアクションは、オーケストレートされたシステム・タイプでサポートされている場合にのみ使用できます。たとえば、「削除」がサポートされていない場合、「無効化」および「アクションなし」オプションのみが表示されます。
  5. アカウントのすべての権限が削除された場合(アイデンティティが部門間を移動する場合など)、アカウントの処理を決定する必要がある場合があります。オーケストレート済システム・タイプでサポートされている場合、次のいずれかのアクションを選択します。
    • 削除
    • 使用不可
    • 処理なし
  6. アクセス・ガバナンスで作成されていないアカウントの管理: オーケストレート済システムで直接作成されるアカウントを管理する場合に選択します。これにより、既存のアカウントを調整し、Oracle Access Governanceから管理できます。
ノート

システムを管理対象システムとして構成しない場合、ワークフローのこのステップは表示されますが、有効になりません。この場合、ワークフローの「統合設定」ステップに直接進みます。
ノート

オーケストレート済システムで、汎用RESTおよびデータベース・アプリケーション表の統合と同様に動的スキーマ検出が必要な場合は、オーケストレート済システムの作成時に通知電子メールの宛先(ユーザー、Usermanager)のみを設定できます。モーバーおよびリーバの無効化/削除ルールは設定できません。これを行うには、オーケストレート済システムを作成してから、「オーケストレート済システム・アカウント設定の構成」の説明に従ってアカウント設定を更新する必要があります。

構成

ワークフローの「構成」ステップで、汎用RESTコネクタを使用してOracle Access Governanceがシステムに接続できるようにするために必要な構成の詳細を入力します。

  1. OCIファンクションのOCIテナンシOCIDとは何ですか。: OCIファンクションのOCID (Oracle Cloud Identifier) を入力します。テナンシのOCIDおよびユーザーのOCIDを取得する場所を参照してください。たとえば、ocid1.oc1..aabdgsegsccawmw2o6qraopae7egmlochlopclhnwxq6pctu6oocgnです。
  2. OCI関数のリージョン・コードとは何ですか。: リージョン識別子を使用して、ターゲットOCIテナンシのホーム・リージョンを入力します。たとえば、米国東部(アッシュバーン)の場合、リージョン識別子はus-ashburn-1です。ホーム・リージョンおよびテナンシのホーム・リージョンを見つけるにはどのようにするのですか。を参照してください。
  3. OCIファンクションのコンパートメントIDとは何ですか。: 統合するファンクションのコンパートメントIDを入力します。
  4. OCI関数のアプリケーション名は何ですか。: 統合する関数のアプリケーション名を入力します。
  5. ファンクション・バージョン: 統合するファンクションのファンクション・バージョンを入力します。
  6. リクエスト・テンプレート・キャッシュTTLの期間(分単位): リクエスト・テンプレートがキャッシュする期間。timeが0に設定されている場合、キャッシュは行われません。キャッシュが期限切れになると、OCI関数が呼び出されて新しいテンプレートが取得されます。トークンの期限切れによる接続の削除を回避するには、キャッシュ時間をトークンの有効期限より短くする必要があります。
  7. レスポンス・テンプレート・キャッシュの期間(分単位): レスポンス・テンプレートがキャッシュする期間。timeが0に設定されている場合、キャッシュは行われません。キャッシュが期限切れになると、OCI関数が呼び出されて新しいテンプレートが取得されます。トークンの期限切れによる接続の削除を回避するには、キャッシュ時間をトークンの有効期限より短くする必要があります。
  8. テスト・テンプレート・キャッシュの期間(分単位): テスト・テンプレートがキャッシュする期間。timeが0に設定されている場合、キャッシュは行われません。キャッシュが期限切れになると、OCI関数が呼び出されて新しいテンプレートが取得されます。トークンの期限切れによる接続の削除を回避するには、キャッシュ時間をトークンの有効期限より短くする必要があります。
  9. スキーマ・テンプレートの期間(分単位): スキーマ・テンプレートがキャッシュする期間。timeが0に設定されている場合、キャッシュは行われません。キャッシュが期限切れになると、OCI関数が呼び出されて新しいテンプレートが取得されます。トークンの期限切れによる接続の削除を回避するには、キャッシュ時間をトークンの有効期限より短くする必要があります。
  10. 読取りレスポンス・タイムアウト(秒): レスポンスを次から受信する必要がある秒数を指定する整数値を入力します
  11. 接続タイムアウト(秒): タイムアウトとタイムアウトの間の接続の確立の試行がタイムアウトする秒数を指定する整数値。
  12. 「追加」を選択します。

完了

「Finish up」の最後のステップでは、データ・ロードを実行する前にオーケストレート済システムをさらに構成するか、デフォルト構成を受け入れてデータ・ロードを開始するかを選択できます。次の中から1つ選択します。
  • システムでデータ・ロードを有効化する前にカスタマイズします
  • 指定されたデフォルトで、データ・ロードのアクティブ化と準備を行います

リソース・プリンシパル・アクセスへのAPIキー・アクセスの移行

APIキー・アクセス・メソッドを使用して接続する既存のオーケストレート済システムがある場合は、できるだけ早くリソース・プリンシパル・アクセス・メソッドに移行する必要があります。

APIキー・アクセスをリソース・プリンシパル・アクセスに移行するには:

  1. 「オーケストレート済システム統合設定の構成」の手順に従って、「統合設定」ページにナビゲートします。
  2. 「統合設定」ページに、非推奨の警告が表示されます。「移行の詳細」ボタンを選択します。
  3. コンソールに表示されているように、ルート・コンパートメントの正確なポリシーをコピーします。ポリシーの適用方法の詳細は、ポリシーの作成を参照してください。
    ノート

    必要なポリシーは、OCI FunctionsとOracle Access Governanceインスタンスがホストされている場所(たとえば、同じテナンシと異なるテナンシ)によって異なります。

  4. ポリシーを適用したら、「統合のテスト」を選択して接続をチェックします。エラーまたはメッセージがある場合は、構成を確認してください。テストが成功するまで、移行を完了できません。
  5. 接続が確認されたら、「移行」ボタンをクリックして移行を開始します。
  6. 移行が完了すると、確認メッセージが表示されます。
ノート

リソース・プリンシパル・メソッドへの移行が完了した後は、オーケストレート済システムでプロシージャを元に戻してAPIキー・メソッドを回復することはできません。

構成後処理

Generic REST Orchestrated Systemを構成したら、「Orchestrated System」ページに移動し、アクティビティ・ログの操作を確認できます。表示される操作には、次のものがあります。
  • スキーマ検出: 汎用RESTオーケストレート済システムは、設計時およびデプロイメント時にスキーマレスです。オーケストレーション・ライフサイクルの一環として、必要な認可ソースまたは管理対象システムのスキーマおよびオブジェクト・クラスの詳細でオーケストレート済システムを更新するために、スキーマ検出が実行される必要があります。スキーマ検出の詳細は、Generic Rest Schema Discoveryを参照してください。
  • 検証: この操作では、次のタスクが実行されます。
    • テスト・テンプレートを呼び出します。これにより、テンプレートで指定されたエンドポイントが呼び出され、管理対象システムとの接続がチェックされます。
    • スキーマ・テンプレートを起動し、エンティティおよび属性を含む管理対象システムのスキーマ情報をすべて取得します。
  • 参照データ・ロード: 参照が定義されている場合は、参照に対応するデータがロードされます。
  • 完全データ・ロード: この操作では、指定されたエンティティのデータをロードし、取り込みます。