機械翻訳について

サービス間でのOAuthユーザー・アイデンティティの伝播

Oracle Integrationは、REST API操作の起動時にOAuthアイデンティティ伝播をサポートします。 OAuthアイデンティティ伝播を使用すると、サービス間で同じユーザー・アイデンティティおよびアクセス資格証明を安全に転送できます。 関係するサービスでは、Oracle Integration内の同じアイデンティティ・ドメイン、Oracle Integration外の別のアイデンティティ・ドメイン、またはサード・パーティのアイデンティティ・プロバイダを使用できます。

Oracle Integrationでのアイデンティティ伝播の動作

ユーザーのアイデンティティを複数のサービス間で伝播する一般的なビジネス要件です。 たとえば:
  • VBCSアプリケーションにログインし、そのテナンシでアイデンティティ・ドメインを使用しているOracle Integrationをコールします。
  • 次に、Oracle Integrationは、別のテナンシで個別のアイデンティティ・ドメインを使用しているOracle Fusion Applicationsエンドポイントを起動します。 Oracle Fusion Applicationsエンドポイントは、ビジネス・ロジックを推進するためにコールを行うエンド・ユーザーを認識している必要があります。
  • Oracle Integrationは、Oracleの外部にあるサード・パーティのアイデンティティ・プロバイダを使用して、Salesforceエンドポイントも起動します。 Salesforceエンドポイントは、ビジネス・ロジックを推進するためにコールを行うエンド・ユーザーも認識している必要があります。
これらのタイプのシナリオでは、アイデンティティ伝播は次のように機能します:
  • ユーザー認証 - ユーザーは、資格証明を使用してアイデンティティ・プロバイダで認証します。
  • トークン発行 - 認証に成功すると、アイデンティティ・プロバイダは、ユーザーのアイデンティティ情報および認可スコープを含むJWTアクセス・トークンを発行します。
  • トークンの伝播 - ユーザーが別のサービスにアクセスすると、JWTアクセス・トークンがリクエストとともに伝播されます。
  • トークン検証 - リクエストを受信する各サービスは、その整合性、有効期限および発行者を検証することで、JWTアクセス・トークンを検証します。
  • アイデンティティの取得 - トークンの検証に成功すると、サービスはJWTアクセス・トークンの要求からユーザーのアイデンティティを抽出します。
  • アクセス・コントロール - アイデンティティに基づいて、適切なアクセス制御が適用され、リソースへのユーザーのアクセスが決定されます。

Oracle Integrationは、「JWTユーザー・アサーションを使用したOAuth」セキュリティ・ポリシーを使用したOAuthアイデンティティ伝播のサポートを提供します。 このセキュリティ・ポリシーは、次のアダプタを呼出し接続として使用してREST API操作を呼び出す必要がある場合に使用できます。

  • RESTアダプタ
  • Oracle ERP Cloudアダプタ
  • Oracle HCM Cloudアダプタ
  • Oracle CX SalesおよびB2B Serviceアダプタ

これらのアダプタの「接続」ページまたはアダプタ・エンドポイント構成ウィザードでは、アイデンティティ伝播の構成タスクは必要ありません。 かわりに、「セキュリティ・プロパティ」の下の「件名」要素を使用してマッパーに伝播するようにユーザー・アイデンティティを構成します。

ノート:

  • リリース25.04より前に作成された呼出し接続でアイデンティティ伝播を使用するには、アダプタ・エンドポイント構成ウィザードでアダプタを開き、各ページをクリックして「保存」をクリックします。 これらのアクションによって、必要な「件名」ソース要素およびターゲット要素がマッパーに作成されます。
  • アイデンティティ伝播はオプションの機能です。 「JWTユーザー・アサーションを使用したOAuth」セキュリティ・ポリシーでアイデンティティ伝播を使用しない場合は、「件名」要素を空のままにします。

ユーザー・アイデンティティの伝播

この項では、ユーザー・アイデンティティの伝播の概要について説明します。

  1. トリガー接続(たとえば、「RESTアダプタ」)を作成します。
  2. 「RESTアダプタ」を使用して新しい呼出し接続を作成します。
  3. 「JWTユーザー・アサーションを使用したOAuth」セキュリティ・ポリシーを使用するように起動接続を構成し、必要なヘッダー・ファイルとペイロード・ファイルをアップロードし、「証明書」ページでアップロードした秘密キー別名を指定し、「オプションのセキュリティ」でスコープを指定します。


    「セキュリティ」セクションには、セキュリティ・ポリシー、アクセス・トークンURI、json形式のJWTヘッダー、json形式のJWTペイロードおよびJWT秘密キー別名のフィールドが含まれます。 この下には、展開可能な「オプション」セキュリティ・セクションがあります。

  4. アプリケーション統合を作成します。
  5. アダプタ・エンドポイント構成ウィザードを使用して、トリガーおよび呼出しの接続を統合キャンバスにドラッグして構成します。
  6. マッパーを開きます。


    統合には、トリガー接続、マッパーおよび呼出しアクションが表示されます。

  7. マッパーの2つのオプションのいずれかを使用して、統合を実行する権限を持つユーザーを設定します:
    • 「ソース」および「ターゲット」領域の「セキュリティ・プロパティ」を展開し、ソース「件名」要素内のユーザーをターゲットの「件名」要素にマップします。


      ソース、マッピング・キャンバスおよびターゲット・セクションが表示されます。 ソース・セキュリティ・プロパティ・ノードおよびターゲット・セキュリティ・プロパティ・ノードが展開されました。 「ソース」セクションの「件名」要素は、「ターゲット」セクションの「件名」要素にマップされます。

    • 「ターゲット」領域で「セキュリティ・プロパティ」を展開し、式ビルダーで「件名」要素のユーザーを手動で設定します。 この例では、このオプションが示されています。 ユーザー名は、式ビルダーで"l1serviceadmin"として指定します。


      ソース、マッピング・キャンバスおよびターゲット・セクションが表示されます。 サブジェクト・ターゲット要素は、ページの下部にある式ビルダーにl1serviceadminの値で表示されます。

  8. 統合の完全な設計。
  9. 統合をアクティブ化し、マッパーで指定されたl1serviceadminユーザーとして実行します。

    アクティビティ・ストリームは、実行が成功したことを示します。

    マッパーの「件名」要素で構成されているユーザーとは異なるユーザーとの統合を実行すると、次のエラーが表示されます:
    Request to access token failed. Cause: status = 400 Error: 
{\"error\":\"invalid_grant\",\"error_description\":\"Invalid user assertion: 
The user name that you entered is invalid. Contact your system administrator.\"

    トリガーから呼出しにサブジェクトをマップすると、フローを起動するユーザーのアイデンティティによって、JSONファイルで構成されているユーザーがオーバーライドされます。 たとえば、実行時に、user1、user2およびuser3は統合フローを実行でき、それらはすべて特定のユーザーごとにトークンを取得します。 JWTペイロードJSONファイルは変更されません。

詳細は、ビデオをご覧ください: