機械翻訳について

接続の作成

統合を構築する前に、データを共有するアプリケーションへの接続を作成する必要があります。

ノート:

統合キャンバスで接続を作成することもできます。 「インバウンド・トリガーとアウトバウンド起動、処理の定義」を参照してください。

Oracle Integrationで接続を作成するには:

  1. 開始する場所を決定します:
    • プロジェクトでの作業(「プロジェクトの使用をお薦めします」の理由を参照)。
      1. ナビゲーション・ペインで、「プロジェクト」をクリックします。
      2. プロジェクト名を選択します。
      3. 「Integrations」をクリックします 統合アイコン
      4. 「接続」セクションで、現在接続が存在しない場合は「追加」をクリックし、接続が存在する場合は+をクリックします。 接続の作成パネルが開きます。
    • プロジェクト外の作業
      1. ナビゲーション・ペインで、「設計」「接続」の順にクリックします。
      2. 「作成」をクリックします。 接続の作成パネルが開きます。
  2. この接続に使用するアダプタを選択します アダプタを検索するには、リストをスクロールするか、「検索」フィールドに名前の一部または全体を入力します。

  3. この接続について説明する情報を入力します。
    要素 説明
    名前

    他のユーザーが自分で統合の作成を始める場合にこの接続を見つけやすいように、わかりやすい名前を入力します。

    識別子

    名前は、「名前」フィールドに入力した大文字で自動的に表示されます。 識別子名を変更する場合は、空白を含めないでください(例: SALES OPPORTUNITY)。

    ロール

    この接続を使用するロール(方向)を選択します。

    ノート: 選択したアダプタでサポートされているロールのみが選択のために表示されます。 一部のアダプタでは、すべてのロールの組合せ(トリガー、呼出しまたはトリガーと呼出し)がサポートされます。 他のアダプタでは、サポートするロールの組合せが少なくなります。

    ロールを選択すると、そのロールに適切な接続プロパティおよびセキュリティ・ポリシーのみが「Connections」ページに表示されます。 起動とトリガーの両方がサポートされるアダプタを選択し、いずれかのロールのみを選択した場合、選択しなかったセクションにアダプタをドラッグしようとするとエラーが発生します。

    たとえば、「Oracle Service Cloud (RightNow)アダプタ」の接続をinvokeのみとして構成するとします。 統合でアダプタをtriggerセクションにドラッグすると、エラーが発生します。

    キーワード

    オプションのキーワード(タグ)を入力します。 接続ページで接続キーワードを検索できます。

    説明

    接続の説明を入力します(オプション)。

    他のプロジェクトと共有

    ノート: このフィールドは、プロジェクトで接続を作成している場合にのみ表示されます。

    この接続を他のプロジェクトで公開する場合に選択します。 接続共有により、異なるプロジェクトで個別の接続を作成および維持する必要がなくなります。

    別のプロジェクトでアダプタ接続を構成すると、「接続」ページの上部に「共有接続の使用」フィールドが表示されます。 構成している接続が、パブリックに使用可能な接続と同じタイプおよびロールと一致する場合は、その接続を選択してそのリソースを参照(継承)できます。

    「プロジェクト間での接続の追加および共有」を参照してください。

  4. 「作成」をクリックします。

    接続が作成されました。 これで、接続プロパティ、セキュリティ・ポリシーおよび(一部の接続に対して)アクセス・タイプを構成する準備ができました。

  5. ステップに従って接続を構成します。

    接続プロパティおよび接続セキュリティの値は、各アダプタに固有です。 接続には、プライベート・エンドポイントやエージェント・グループなどのアクセス・タイプを使用した構成が必要な場合もあります。

  6. 接続をテストします。

起動接続の接続プロパティの構成

接続セキュリティを構成して、「RESTアダプタ」で保護されたターゲット・サービスを起動します。

  1. 「プロパティ」セクションに移動します。
  2. 次の詳細を指定します。
    要素 説明

    接続タイプ

    使用するタイプを選択します:
    • REST APIベースのURL

    • Open API (1.0/2.0/3.0) URL

    接続URL

    「接続タイプ」フィールドでの選択に基づいて、使用するエンドポイントURLを指定します。 接続URLは、HTTPとHTTPSのどちらにすることもできます。

    ノート: REST APIベースURLまたはOpen API URLの最後にスラッシュ(/)を含めないでください。

    • REST APIベースのURL
      https://hostname:port/ic/api/integration/v1/flows/rest/INTEGRATION_NAME/v01
    • Open API (1.0/2.0/3.0) URLの場合:
      https://hostname:port/ic/api/integration/v1/flows/rest/INTEGRATION_NAME/v1/metadata/openapi

    TLSバージョン

    (「オプションのプロパティ」の下)

    値が選択されていない場合、アウトバウンド接続に使用されるデフォルト値は、Transport Layer Security (TLS)バージョン1.3です。 TLSバージョン1.2または1.1をデフォルトとして選択するかどうかは、ユーザーの判断とエンド・アプリケーションの要件によって異なります。

    • TLSv1.1

    • TLSv1.2

    TLSv1はサポートされなくなりました。 以前にOracle Integration 3より前のバージョンでTLSv1.1を使用するように接続を構成していた場合は、このフィールドの値を選択せずに接続を更新するか、TLSv1.2を選択します。

    TLSプロトコルにより、通信する2つのコンピュータ・アプリケーション間でプライバシとデータ統合が実現します。

    トリガーのみの接続では、TLSバージョンを選択できません。 Oracle Integrationは、TLSv1.1またはTLSv1.2であるかぎり、受信するものを受け入れます。

    アウトバウンド接続の双方向SSLの有効化(オプション)

    (「オプションのプロパティ」の下)

    双方向SSL対応サーバーで使用するように「RESTアダプタ」を構成する場合は、Yesを選択します。

    .

    アイデンティティ・キーストア・エイリアス名(オプション)

    (「オプションのプロパティ」の下)

    アイデンティティ証明書のインポート時に指定したキーストア・ファイルのキー別名を入力します。

    指定する別名は、JKSファイルの秘密キー・エントリに指定された名前と一致する必要があります。

    ノート:

    MetadataカタログURL、Swagger定義URLおよびRAML定義URL接続タイプは使用できなくなりました。 RAMLまたはOracleメタデータ・カタログを使用して記述されるREST APIを使用する開発者は、特定のアクションを実行する必要があります。 「Oracle Integration 3の新機能」「Oracle Integrationの以前のバージョンとの相違点」を参照してください。

接続セキュリティの構成

セキュリティ・ポリシーを選択し、必要な詳細を指定して、「RESTアダプタ」接続のセキュリティを構成します。

  1. 「セキュリティ」セクションに移動します。
  2. 使用するセキュリティ・ポリシーを選択します。 「RESTアダプタ」接続の作成時に「起動」ロールまたは「トリガーと起動」ロールを選択した場合、ページがリフレッシュされ、様々なログイン資格証明フィールドが表示されます。 必要なフィールドを設定するために、すでにクライアント・アプリケーションの作成を終えている必要があります。

    接続ページでトリガーおよび起動ロールを使用して「RESTアダプタ」接続を構成する場合は、次のセキュリティ・ポリシー制限が適用されます:

    • Basic Authenticationを選択した場合は、トリガーおよび呼出しとして使用できます。
    • 他のセキュリティ・ポリシーを選択した場合は、起動としてのみ使用できます。 接続をトリガー領域にドラッグすると、例外エラーが表示されます。
    • 既存の統合の場合、アダプタ・エンドポイント構成ウィザードで「RESTアダプタ」を編集する際に前述の制限は適用されません。

    ノート:

    RFC 6749に示すように、次の標準OAuthセキュリティ・ポリシーは、実装されているプロバイダと連携するように実装されています。
    • OAuthリソース所有者のパスワード資格証明
    • OAuthクライアント資格証明

    標準ポリシーが機能しない場合は、OAuth Custom Two LeggedまたはOAuth Custom Three Leggedセキュリティ・ポリシーを使用することをお薦めします。

トリガー接続のセキュリティ・ポリシーの構成

選択されているセキュリティ・ポリシー 説明 フィールド
OAuth2.0
  • HTTPベアラー認証をサポートします。
  • クライアントは、HTTPヘッダーでOAuth 2.0 bearerトークンを送信する必要があります。

「Oracle Integrationフローを起動するための認証リクエスト」を参照してください。

フィールドは表示されません。
Basic認証
  • HTTP basic認証をサポートします。
  • クライアントは、HTTPヘッダーでユーザー名/パスワードを送信する必要があります。
フィールドは表示されません。
OAuth 2.0またはBasic認証 クライアントは、任意のOAuth 2.0 bearerトークンまたはHTTP Basic認証ヘッダーを使用できます。 フィールドは表示されません。

起動接続のセキュリティ・ポリシーの構成

ノート:

OAuth認証コード資格証明、OAuthカスタム3レッグ・フローおよびOAuthカスタム2レッグ・フローのセキュリティ・タイプの場合、接続は、「Provide Consent」ボタンをクリックした後にのみ成功します。 すべての詳細を構成するだけでは不十分です。

ノート:

HTTP Basic認証セキュリティ・ポリシーおよび「トリガーと起動」または「起動」のロール接続を使用して構成されたRESTアダプタ接続をテストしても、資格証明は検証されず、指定したURLへの接続がオープンします。 エンドポイントと資格証明を検証するには、RESTアダプタがべき等なAPIを呼び出す必要があります。
選択されているセキュリティ・ポリシー フィールド

AWSシグネチャ・バージョン4

ノート: オンプレミス環境でホストされているAWS APIを呼び出す必要があるシナリオでは、このセキュリティ・ポリシーを接続エージェントとともに使用できます。

  • 「アクセス・キー」 - Amazonセキュリティ資格証明を作成したときに取得したキーを入力します。

  • 「シークレット・キー」 - Amazonセキュリティ資格証明を作成したときに取得したキーを入力します。

  • 「シークレット・キーの確認」 - 2回目のキーを入力します。

  • 「AWSリージョン」 - AWSサーバーがホストされるリージョンを選択します。

  • 「サービス名」 - 接続するAWSサービスを選択します。

Basic認証

  • Username - 宛先Webサービスにアクセスできるユーザーの名前。

  • Password - パスワードを入力します。

  • Confirm Password - パスワードを再入力します。

OAuthクライアント資格証明

  • Access Token URI - アクセス・トークンの取得元のURL。

  • Client Id - 登録プロセス中にクライアントに発行されたクライアント識別子。

  • Client Secret - クライアント・シークレット。

  • Confirm Client Secret - クライアント・シークレットを再入力します。

  • Scope - アクセス・リクエストのスコープ。 スコープによって、必要なアクセスのタイプを指定できます。 スコープによって、OAuthトークンに対するアクセスが制限されます。 ユーザーがすでに保持している以上の追加権限が付与されることはありません。

  • Auth Request Media Type - 希望するデータの受信形式。 これは、空白のままにしておくことができるオプションのパラメータです。 たとえば、Twitter APIを呼び出す場合、タイプを選択する必要はありません。

  • 「クライアント認証」 - オプションで、クライアント認証を使用してOAuthフローを構成できます。 これは、クライアント認証を構成するPostmanユーザー・インタフェース機能に似ています。

    • クライアント資格証明を基本認証ヘッダーとして送信: basic認証としてヘッダーにクライアントIDとクライアント・シークレットを渡します。
    • 本文にクライアント資格証明を送信: 本文のクライアントIDとクライアント・シークレットをフォーム・フィールドとして渡します。

OAuthリソース所有者のパスワード資格証明

  • Access Token URI - アクセス・トークンの取得元のURL。

  • Client Id - 登録プロセス中にクライアントに発行されたクライアント識別子。

  • Client Secret - クライアント・シークレット。

  • Confirm Client Secret - クライアント・シークレットを再入力します。

  • Scope - アクセス・リクエストのスコープ。 スコープによって、必要なアクセスのタイプを指定できます。 スコープによって、OAuthトークンに対するアクセスが制限されます。 ユーザーがすでに保持している以上の追加権限が付与されることはありません。

  • Auth Request Media Type - 希望するデータの受信形式。

  • Username - リソース所有者のユーザー名。

  • Password - リソース所有者のパスワード。

  • Confirm Password - パスワードを再入力します。

  • 「クライアント認証」 - オプションで、クライアント認証を使用してOAuthフローを構成できます。 これは、クライアント認証を構成するPostmanユーザー・インタフェース機能に似ています。

    • クライアント資格証明を基本認証ヘッダーとして送信: basic認証としてヘッダーにクライアントIDとクライアント・シークレットを渡します。
    • 本文にクライアント資格証明を送信: 本文のクライアントIDとクライアント・シークレットをフォーム・フィールドとして渡します。
OAuth認証コード資格証明
  • Client Id - 登録プロセス中にクライアントに発行されたクライアント識別子。

  • Client Secret - クライアント・シークレット。

  • Confirm Client Secret - クライアント・シークレットを再入力します。

  • Authorization Code URI - 認証コードのリクエスト元のURI。

  • Access Token URI - アクセス・トークン用として使用するURI。

  • Scope - アクセス・リクエストのスコープ。 スコープによって、必要なアクセスのタイプを指定できます。 スコープによって、OAuthトークンに対するアクセスが制限されます。 ユーザーがすでに保持している以上の追加権限が付与されることはありません。

  • 「クライアント認証」 - オプションで、クライアント認証を使用してOAuthフローを構成できます。 これは、クライアント認証を構成するPostmanユーザー・インタフェース機能に似ています。

    • クライアント資格証明を基本認証ヘッダーとして送信: basic認証としてヘッダーにクライアントIDとクライアント・シークレットを渡します。
    • 本文にクライアント資格証明を送信: 本文のクライアントIDとクライアント・シークレットをフォーム・フィールドとして渡します。

OAuthカスタム3レッグ・フロー

このセキュリティ・ポリシーの詳細については、「OAuthカスタム3つのレッグ・フロー・トークン・ベース認証で保護されたREST APIを使用するようにRESTアダプタを構成」を参照してください。

  • Authorization Request - 同意したときにリダイレクト先となるクライアント・アプリケーションURL。 認証サーバーは、Oracle Integrationにコールバックを送信して、ストレージ用のアクセス・トークンを取得します。 クライアント・アプリケーションを作成する際、クライアント・アプリケーションがリスニングするリダイレクトURIを登録する必要があります。
    authorization_URI?query_parameters
    このフィールドのク・リア・テキストに値を入力しない場合は、次の操作を行います:
    • 使用可能なパラメータを使用して構文を指定: ${security_field_1}から${security_field_4} (たとえば、スコープを&scope=${security_field_1}として定義)。 「データ難読化のサポート」を参照してください。
    • 「オプションのセキュリティ」を展開し、使用したパラメータの実際の値を入力します。 検出されないように、入力した値は不明瞭化されます。 「セキュリティ・フィールド1 - 4」を参照してください。
  • Access Token Request - アクセス・トークンをフェッチするために使用するアクセス・トークン・リクエスト。 CURL構文を使用してリクエストを指定します。 たとえば:

    -X POST method -H headers -d string_data access_token_uri?query_parameters
    このフィールドのク・リア・テキストに値を入力しない場合は、次の操作を行います:
    • 使用可能なパラメータを使用して構文を指定: ${security_field_1}から${security_field_4} (たとえば、クライアントIDを&client_id=${security_field_3}として定義)。
    • 「オプションのセキュリティ」を展開し、使用したパラメータの実際の値を入力します。 検出されないように、入力した値は不明瞭化されます。 「セキュリティ・フィールド1 - 4」を参照してください。
  • Refresh Token Request - アクセス・トークンをフェッチするために使用するリフレッシュ・トークン・リクエスト。 このリクエストは、失効したアクセス・トークンをリフレッシュします。 CURL構文を使用してリクエストを指定します。 たとえば

    -X POST method -H headers -d string_data refresh_token_uri?query_parameters
    このフィールドのク・リア・テキストに値を入力しない場合は、次の操作を行います:
    • 使用可能なパラメータを使用して構文を指定: ${security_field_1}から${security_field_4} (たとえば、クライアントIDを&client_id=${security_field_2}として定義)。
    • 「オプションのセキュリティ」を展開し、使用したパラメータの実際の値を入力します。 検出されないように、入力した値は不明瞭化されます。 「セキュリティ・フィールド1 - 4」を参照してください。
  • Sauth_code - regexを使用して、認証コードを識別します。
    code
  • Saccess_token - 正規表現(regex)を使用して、アクセス・トークンを取得します。
    access.[tT]oken
  • Srefresh_token - regexを使用して、リフレッシュ・トークンを取得します。
    refresh.[tT]oken
  • Sexpiry - regexを使用して、アクセス・トークンが失効するタイミングを識別します。
    expires_in
  • Stoken_type - regexを使用して、アクセス・トークン・タイプを識別します。

    token.?[tT]ype
  • access_token_usage - 保護されたリソースにアクセスするために、トークンを複数のヘッダーまたは複数の問合せパラメータとして渡す方法を指定します。 ヘッダーと問合せパラメータを混在させることはできません。

    ヘッダーの場合:

    -H Authorization: ${token_type} ${access_token} -H validity: 30000 -H signature: ok

    オプションで、ヘッダーの引用符を指定できます:

    -H 'Authorization: ${token_type} ${access_token}' -H 'validity: 30000' -H 'signature: ok'

    問合せパラメータの場合:

    ?token=${access_token}&validity=3000&signature=ok
  • セキュリティ・フィールド1 - 4

    使用したパラメータの実際の値を入力します。 検出されないように、入力した値は不明瞭化されます。
    • 「セキュリティ・フィールド1」 - ${security_field_1}パラメータの値を入力します。

    • 「セキュリティ・フィールド2」 - ${security_field_2}パラメータの値を入力します。

    • 「セキュリティ・フィールド3」 - ${security_field_3}パラメータの値を入力します。

    • 「セキュリティ・フィールド4」 - ${security_field_4}パラメータの値を入力します。

OAuthカスタム2レッグ・フロー

このセキュリティ・ポリシーの詳細については、「OAuthカスタム2つのレッグ・トークン・ベース認証で保護されたREST APIを使用するようにRESTアダプタを構成」を参照してください。

  • Access Token Request - アクセス・トークンをフェッチするために使用するアクセス・トークン・リクエスト。 CURL構文を使用してリクエストを指定します。 たとえば:

    -X POST method -H headers -d string_data access_token_uri?query_parameters
    このフィールドのク・リア・テキストに値を入力しない場合は、次の操作を行います:
    • 使用可能なパラメータを使用して構文を指定: ${security_field_1}から${security_field_4} (たとえば、クライアントIDを&client_id=${security_field_1}として定義)。 「データ難読化のサポート」を参照してください。
    • 「オプションのセキュリティ」を展開し、使用したパラメータの実際の値を入力します。 検出されないように、入力した値は不明瞭化されます。 「セキュリティ・フィールド1 - 4」を参照してください。
  • Refresh Token Request - アクセス・トークンをフェッチするために使用するリフレッシュ・トークン・リクエスト。 このリクエストは、失効したアクセス・トークンをリフレッシュします。 CURL構文を使用してリクエストを指定します。 たとえば

    -X POST method -H headers -d string_data refresh_token_uri?query_parameters
    このフィールドのク・リア・テキストに値を入力しない場合は、次の操作を行います:
    • 使用可能なパラメータを使用して構文を指定: ${security_field_1}から${security_field_4} (たとえば、クライアント・シークレットを&client_secret=${security_field_3}として定義)。 「データ難読化のサポート」を参照してください。
    • 「オプションのセキュリティ」を展開し、使用したパラメータの実際の値を入力します。 検出されないように、入力した値は不明瞭化されます。 「セキュリティ・フィールド1 - 4」を参照してください。
  • Saccess_token - regexを使用して、アクセス・トークンを識別します。
    access.[tT]oken
  • Srefresh_token - regexを使用して、リフレッシュ・トークンを識別します。
    refresh.[tT]oken
  • Sexpiry - regexを使用して、アクセス・トークンが失効するタイミングを識別します。
    expires_in
  • Stoken_type - regexを使用して、アクセス・トークン・タイプを識別します。
    token.?[tT]ype
  • access_token_usage - 保護されたリソースにアクセスするために、トークンを複数のヘッダーまたは複数の問合せパラメータとして渡す方法を指定します。 ヘッダーと問合せパラメータを混在させることはできません。

    ヘッダーの場合:

    -H Authorization: ${token_type} ${access_token} -H validity: 30000 -H signature: ok

    オプションで、ヘッダーの引用符を指定できます:

    -H 'Authorization: ${token_type} ${access_token}' -H 'validity: 30000' -H 'signature: ok'

    問合せパラメータの場合:

    ?token=${access_token}&validity=3000&signature=ok
  • セキュリティ・フィールド1 - 4

    使用したパラメータの実際の値を入力します。 検出されないように、入力した値は不明瞭化されます。
    • 「セキュリティ・フィールド1」 - ${security_field_1}パラメータの値を入力します。

    • 「セキュリティ・フィールド2」 - ${security_field_2}パラメータの値を入力します。

    • 「セキュリティ・フィールド3」 - ${security_field_3}パラメータの値を入力します。

    • 「セキュリティ・フィールド4」 - ${security_field_4}パラメータの値を入力します。

APIキー・ベース認証

このセキュリティ・ポリシーの詳細については、「APIキーで保護されたREST APIを消費するようにRESTアダプタを構成」を参照してください。

  • 「APIキー」 - リクエストを行ったクライアントを識別するために生成されたAPIキーを指定します。

  • 「APIキーを確認」 - APIキーを再入力します。

  • 「APIキーの使用」 - 保護されたリソースにアクセスするためにAPIキーを渡す方法のURI構文を指定します。

    実行時にAPIキーを問合せパラメータとして渡して、保護されたリソースにアクセスするには:

    ?key=${api-key}

    保護されたリソースにアクセスするために、実行時にAPIキーをヘッダーとして渡すこと。

    -H Authorization: Bearer ${api_key}
    たとえば:
    -H Authorization: Bearer AASDFADADX

OAuth 1.0 1レッグ認証

  • 「コンシューマ・キー」 - リクエストを行うクライアントを識別するキーを指定します。

  • 「コンシューマ・シークレット」 - リクエストを行うクライアントを認証するコンシューマ・シークレットを指定します。

  • 「消費者シークレットを確認」 - シークレットをもう一度指定してください。

  • 「トークン」 - 保護されたリソースにアクセスするトークンを指定します。

  • 「トークン・シークレット」 - リクエストのシグネチャを生成するトークン・シークレットを指定します。

  • 「トークン・シークレットを確認」 - シークレットをもう一度指定してください。

  • 「レルム」 - アカウントを識別するレルムを指定します。

ノート: HMAC-SHA256シグネチャ暗号化アルゴリズムはデフォルトでサポートされており、変更できません。 HMAC-SHA1 Oracle Integration 3ではサポートされていません。

OCIシグネチャ・バージョン1 このセキュリティ・ポリシーを使用するための前提条件を満たす場合に作成した値を指定します。 「接続を作成するための前提条件」を参照してください。
  • 「テナンシOCID」 - Oracle Cloud Infrastructureコンソールからコピーした値を指定します。
  • 「ユーザーOCID」 - Oracle Cloud Infrastructureコンソールからコピーした値を指定します。
  • 「秘密キー」 - 「アップロード」をクリックして作成したキーを選択します。 キーがRSA (PKCS1)形式であることを確認します。 この形式に変換する必要がある場合は、「OCIシグネチャ・バージョン1セキュリティ・ポリシーのための秘密キーのPKCS8からRSA (PKCS1)形式への変換」を参照してください。
  • 「フィンガ・プリント」 - Oracle Cloud Infrastructureコンソールでキーを作成したときに生成されたフィンガ・プリントを入力します。
  • 「パスフレーズ」 - キーの作成時に作成したパスフレーズを入力します。
  • 「パスフレーズの確認」 - パスフレーズを2回入力します。

OAuth JWTクライアント・アサーションを使用したクライアント資格証明

ノート: このポリシーは、通常、アプリケーション主導のAPIを起動するために使用されます。

  • 「アクセス・トークンURI」 - アクセス・トークンを取得するリクエストを送信するURLを入力します。 たとえば:
    https://accounts.google.com/o/oauth2/token
  • 「JSON形式のJWTヘッダー」 - JWTヘッダー・ファイルをJSON形式でアップロードします。
  • 「JSON形式のJWTペイロード」 - JWTペイロード・ファイルをJSON形式でアップロードします。
  • 「JWT秘密キー別名」 - JWT秘密キーの別名を入力します。 これは、証明書ページで署名キー証明書をアップロードするときに指定した別名です。
  • 「スコープ」 - (オプション)スコープを入力します。
  • 「アクセス・トークン・リクエスト」 - (オプション)アクセス・トークンを取得するリクエストを入力します。 指定する形式は、サービス・プロバイダによって異なります。 「サービス・プロバイダ別のJWT使用のバリエーション」を参照してください。

JWTユーザー・アサーションを使用したOAuth

ノート:
  • 「アクセス・トークンURI」 - アクセス・トークンを取得するリクエストを送信するURLを入力します。 たとえば:
    https://accounts.google.com/o/oauth2/token
  • 「JSON形式のJWTヘッダー」 - JWTヘッダー・ファイルをJSON形式でアップロードします。
  • 「JSON形式のJWTペイロード」 - JWTペイロード・ファイルをJSON形式でアップロードします。
  • 「JWT秘密キー別名」 - JWT秘密キーの別名を入力します。 これは、証明書ページで署名キー証明書をアップロードするときに指定した別名です。
  • 「スコープ」 - (オプション)スコープを入力します。
  • 「アクセス・トークン・リクエスト」 - (オプション)アクセス・トークンを取得するリクエストを入力します。 指定する形式は、サービス・プロバイダによって異なります。 「サービス・プロバイダ別のJWT使用のバリエーション」を参照してください。

OCIサービスの起動

このセキュリティ・ポリシーを選択すると、値の指定は求められません。 構成は自動です。 ただし、構成を成功させるには、すべての前提条件を実行する必要があります。

「RPSTおよびOCIサービス起動セキュリティ・ポリシーの使用」を参照してください。

セキュリティ・ポリシーなし

このセキュリティ・ポリシーを選択する場合、追加フィールドは表示されません。

サービス・プロバイダ別のJWT使用のバリエーション

サービス・プロバイダは、JWTクライアント・アサーションを使用してOAuthクライアント資格証明を構成する場合、または接続ページのJWTユーザー・アサーション・セキュリティ・ポリシーを使用してOAuthクライアント資格証明を構成する場合、「スコープ」および「アクセス・トークン・リクエスト」フィールドでスコープ値およびアクセス・トークン・リクエスト値を指定する方法など、様々な方法でJWTアサーションを実装します。

サービス・プロバイダ 同意が必要ですか? 接続ページのスコープおよびアクセス・トークン・リクエストのフィールド 参照ドキュメント
Okta いいえ
curl --location --request POST 'https://${yourOktaDomain}/oauth2/v1/token' \ 
   --header 'Accept: application/json' \ 
   --header 'Content-Type: application/x-www-form-urlencoded' \ 
   --data-urlencode 'grant_type=client_credentials' \ 
   --data-urlencode 'scope=okta.users.read' \ 
   --data-urlencode 'client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \ 
   --data-urlencode 'client_assertion=eyJhbGciOiJSU....tHQ6ggOnrG-ZFRSkZc8Pw'
サービス・アプリケーションを使用したOkta用のOAuthの実装
Okta はい
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&
  code=<id_token>&
  client_id=<client_id>
  client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&
  client_assertion=<client_assertion>
秘密キーを含むJWT
NHS いいえ
curl -x post -h "content-type:application/x-www-form-urlencoded" --data \
"grant_type=client_credentials\
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer\
&client_assertion=<your-signed-jwt>" \
https://api.service.nhs.uk/oauth2/token
アプリケーション制限付きRESTful API - 署名済JWT認証
NHS はい
curl --location --request POST 'https://api.service.nhs.uk/oauth2/token'\
--header 'Content-Type: application/x-www-form-urlencoded'\
--data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange'\
--data-urlencode 'subject_token_type=urn:ietf:params:oauth:token-type:id_token'\
--data-urlencode 'client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer'\
--data-urlencode 'subject_token={NHS CIS2 ID token}\
--data-urlencode 'client_assertion={jwt token}

ステップ4: 公開キーの登録

ユーザー制限付きRESTful API - NHSログインの個別の認証および認可

FHIR いいえ
POST https://fhir.epic.com/interconnect-fhir-oauth/oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion=<client_assertion>
OAuthの使用 2.0
FHIR はい
POST https://fhir.epic.com/interconnect-fhir-oauth/oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=[assertion]&client_id=[client_id]
スタンドアロン起動
Microsoft いいえ
POST /{tenant}/oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com Content-Type: application/x-www-form-urlencoded
scope=https://graph.microsoft.com/.default
&client_id=97e0a5b7-d745-40b6-94fe-5f77d35c6e05
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=<client_assertion>
&grant_type=client_credentials
Microsoftアイデンティティ・プラットフォームおよびOAuth 2.0クライアント資格証明フロー
Microsoft はい
POST /oauth2/v2.0/token HTTP/1.1 Host: login.microsoftonline.com/<tenant> Content-Type: 
application/x-www-form-urlencoded 
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&
client_id=<client_id>&
client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion=
<client_assertion> &assertion=<assertion>&requested_token_use=on_behalf_of 
&scope=https://graph.microsoft.com/user.read+offline_access
Microsoftアイデンティティ・プラットフォームとOAuth 2.0 On-Behalf-Ofフロー
DocuSign はい
curl --data "grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&
assertion=YOUR_JSON_WEB_TOKEN" --request POST https://account-d.docusign.com/oauth/token
JWT付与によるアクセス・トークンの取得方法
Adobe いいえ
POST https://ims-na1.adobelogin.com/ims/exchange/jwt
client_id={api_key_value}&client_secret={client_secret_value}&jwt_token=
{base64_encoded_JWT}
JWT (サービス・アカウント)認証
Oracle Cloud Infrastructure Identity and Access Management (アイデンティティ・ドメイン) いいえ
POST <hostname>/oauth2/v1/token
grant_type=client_credentials&client_assertion_type=urn:ietf:params:oauth:client-assertion-
type:jwt-bearer&client_assertion=<client_assertion>&scope=<scope>
クライアント/ユーザーJWTアサーション
Oracle Cloud Infrastructure Identity and Access Management (アイデンティティ・ドメイン) いいえ
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=<user_assertion>&scope=
<scope>&client_assertion_type=urn:ietf:params:oauth:Aclient-assertion-type:jwt-bearer&
client_assertion=<client_assertion>
クライアント/ユーザーJWTアサーション

エンドポイント・アクセス・タイプの構成

エンドポイントへのアクセスを構成します。 構成しているアダプタの機能によっては、パブリック・インターネット、プライベート・エンドポイント、またはファイアウォールでホストされているオンプレミス・サービスへのアクセスの構成オプションが表示される場合があります。

エンドポイント・アクセス・タイプの選択

  1. 「アクセス・タイプ」セクションに移動します。
  2. エンドポイントにアクセスするためのオプションを選択します。
    オプション アダプタがサポートしている場合、このオプションが表示されます...
    パブリック・ゲートウェイ パブリック・インターネットを使用したエンドポイントへの接続。
    プライベート・エンドポイント プライベート仮想クラウド・ネットワーク(VCN)を使用したエンドポイントへの接続。

    ノート: プライベート・エンドポイントに接続するには、Oracle Cloud Infrastructureコンソールで前提条件タスクを完了する必要があります。 そうしないと、接続のテスト時にエラーが発生します。 「Oracle Integration 3のプロビジョニングと管理」「プライベート・リソースへの接続」および「Oracle Integration 3での統合の使用」「プライベート・エンドポイントのトラブルシューティング」を参照してください。

    接続性エージェント

    接続エージェントを介したオンプレミス・エンドポイントへの接続。

    1. 「エージェント・グループの関連付け」をクリックします。

      エージェント・グループの関連付けパネルが表示されます。

    2. エージェント・グループを選択し、「使用」をクリックします。

    エージェント・グループを構成するには、オンプレミス接続エージェントをダウンロードしてインストールする必要があります。 「Oracle Integration 3での統合の使用」「接続性エージェント・インストーラのダウンロードおよび実行」Oracle Integrationを使用したハイブリッド統合の作成について」を参照してください。

プライベート・エンドポイント構成が成功したことの確認

  • プライベート・エンドポイントに接続するには、Oracle Cloud Infrastructureコンソールで前提条件タスクを完了する必要があります。 そうしないと、接続のテスト時にエラーが発生します。 「Oracle Integration 3のプロビジョニングと管理」「プライベート・リソースへの接続」を参照してください。
  • プライベート・ネットワークを使用してエンドポイントに接続するように接続ページでアダプタを構成する場合は、IPアドレスではなく、完全修飾ドメイン名(FQDN)を指定します。 IPアドレスを入力すると、「テスト」をクリックすると検証が失敗します。

接続のテスト

接続をテストして、接続が正常に構成されていることを確認します。

  1. ページ・タイトル・バーで、「テスト」をクリックします。 次に起こることは、アダプタ接続でWeb Services Description Language (WSDL)ファイルを使用するかどうかによって異なります。 一部のアダプタ接続のみがWSDLを使用します。
    接続の場合... 結果

    WSDLを使用しない

    テストが自動的に開始され、接続に指定した入力が検証されます。

    WSDLの使用

    実行する接続テストのタイプを選択するダイアログが表示されます:

    • 検証とテスト: インポートされたスキーマおよびWSDLの処理など、WSDLの完全な検証を実行します。 インポートされたスキーマおよびWSDLの数によっては、完全な検証に数分かかる場合があります。 WSDLで公開されている操作に送信されたリクエストはありません。

    • テスト: WSDL URLに接続し、WSDLに対して構文チェックを実行します。 WSDLで公開されている操作に送信されたリクエストはありません。

  2. 接続テストの結果に関するメッセージを待機します。
    • テストに成功した場合、接続は適切に構成されています。
    • テストが失敗した場合は、入力した構成詳細を編集します。 入力ミスを確認し、URLおよび資格証明を確認してください。 接続が成功するまでテストを続けます。
  3. 完了したら「保存」をクリックします。