認証サポート

機械翻訳について

認証サポート

次の項では、「RESTアダプタ」認証機能を詳細に説明します。

トピック:

Oracle Integrationフローを起動するリクエストの認証

統合では、様々なアプリケーションおよびユースケースに適した複数の認証メソッドがサポートされます。特定の統合のエンドポイント/リスナーを表すトリガー接続として使用されるアダプタは、1つ以上の認証メソッドをサポートできます。

次の各項では、サポートされている各認証メソッドに対するリクエストの送信に必要なユースケース、長所と短所、前提条件および手順について説明します。

トピック:

「OAuth付与タイプ」を参照してください。

統合を起動するリクエストについて

このアダプタをトリガー接続として使用するすべての統合は、HTTP Basic認証およびOAuthトークン・ベース認証を使用してデフォルトで保護されます。

現在、次のいずれかの方法で、統合を起動するリクエストを認証できます:

HTTP認証ヘッダーを介してユーザーの資格証明(つまり、Oracle Identity Cloud Serviceで作成)を送信することによってHTTP Basic認証を使用
OAuth認可プロバイダとして機能するOracle Identity Cloud Serviceからアクセス・トークンを取得した後にOracle Integrationエンドポイントの起動中に、ヘッダーにOAuthアクセス・トークンを送信しています

統合を起動するには、Oracle Identity Cloud ServiceにServiceUserロールが必要です。

HTTP Basic認証を使用した統合エンドポイントの起動

この認証メソッドでは、Oracle Integrationユーザーに属する資格証明が、統合を起動するリクエストを送信できます。このユーザーをOracle Integrationアイデンティティ・プロバイダOracle Identity Cloud Serviceで作成し、ユーザーが統合を起動するためのロールを付与されていることを確認する必要があります。

ユーザーは次のいずれかです:

人間 - 営業担当、技術者、統合を起動するその他の個人などのビジネス・ユーザーを表します。
非人間 - 外部クライアント・アプリケーションが統合を起動するために使用するサービス統合アカウントを表します。

認証スキームを簡単に実装できますが、これは統合を起動するためにOracle Integrationにリクエストを送信する最も安全な方法です。また、Oracle Integrationは、この認証スキームを推奨しません。

さらに、顧客は、リセット時に、統合を起動するクライアント・アプリケーションに資格証明が提供され、その後新しい資格証明セットが使用されていることを確認する必要があります。

適切なユーザーを様々なOracle Integrationロールに割り当てます。標準/本番構成の場合は、ServiceUserロールを使用します。 (「Oracle Integration Generation 2のプロビジョニングと管理」の「Oracle Integrationロール」を参照してください。)

Oracle Cloud Infrastructureホーム・ページのメニューから、「アイデンティティ&セキュリティ」、「フェデレーション」の順に選択します。
「フェデレーション」表で、OracleIdentityCloudServiceをクリックします。
「Oracle Identity Cloud Serviceコンソール」フィールドで、URLをクリックします。
アプリケーション・ページ・アイコンをクリックします。
アプリケーションをクリックします。
ユーザーを割り当てるには、Oracle Identity Cloud Serviceの「アプリケーション・ロール」セクションに移動します。

「図oauth_grant1.pngの説明」

エンドポイントをトリガーするリクエストを作成します。

curl --location --request GET 'https://OIC host/OIC endpoint' \
--header 'Authorization: Basic <base64-encoded username:password>'

OAuthトークン・ベースの認証を使用した統合エンドポイントの起動

この認証スキームにより、外部クライアントは、統合を起動するために送信されるリクエストの一部としても送信されるトークンを取得できます。

OAuthフロー内でアプリケーションの最も重要なステップは、アプリケーションがアクセス・トークン(オプションでリフレッシュ・トークンとともに)を受け取ることです。権限付与タイプは、トークンを取得するのに使用されるメカニズムです。 OAuthでは、様々な認可メカニズムを表す複数のアクセス権限付与タイプが定義されています。

アプリケーションは、Oracle Identity Cloud Serviceアプリケーションで指定された権限タイプのタイプに応じて、保護されたエンドポイントにアクセスするためのアクセス・トークンを様々な方法でリクエストできます。権限付与とは、保護されているリソースにアクセスするためのリソース所有者の認可を表す資格証明です。

次の各項では、様々な権限付与タイプとその長所/短所、および特定の権限付与タイプの構成方法について説明します。

OAuth 2.0の付与について

Oracle Integrationで使用できるOAuth 2.0付与タイプがいくつかあります。次の情報を確認して、ユースケースに使用する権限付与タイプを特定します。

権限付与タイプ権限付与タイプについてユースケースとリスク

権限付与タイプ	権限付与タイプについて	ユースケースとリスク
JWTユーザー・アサーション (推奨値)	ユーザー・アサーションとは、ユーザーに関するアイデンティティ情報を含むユーザー・トークンです。ユーザーは、特定のコール元アプリケーションを識別するために作成された人間またはサービス統合アカウントを表すことができます。ユーザー・アサーションは、アクセス・トークンを取得するための許可付与として直接使用されます。クライアント詳細は、リクエスト内の認証ヘッダーまたはクライアント・アサーションとして指定されます。ユーザーの資格証明は公開されないため、ユーザー・アサーションの付与はリソース所有者のパスワード資格証明の付与よりも安全です。ユーザー・アサーション・ワークフロー: 機密クライアントとともに使用されます。 OAuthクライアントは、ユーザー/サービス統合アカウントのかわりにユーザー/サービス統合アカウント・アイデンティティをアサートすることが信頼されます。リソース所有者資格証明(Oracle Integrationユーザー)は、クライアント・アプリケーションからアクセスできません。リソース所有者のアサーションのみを使用します。リダイレクション・ベースではありません。クライアント・アプリケーションから認可サーバーへのリクエストのみを受け取ります。ユーザーは、リクエストを認可するためにインタフェース間でリダイレクトされません。このユーザー・アサーション権限付与は、次のように機能します: クライアントでは、ユーザー・アサーションを指定することによって、アクセス・トークンをリクエストします。クライアント詳細は、リクエスト内の認証ヘッダーまたはクライアント・アサーションとして指定されます。 OAuthサービスはクライアントを認証し、有効な場合はアクセス・トークンを提供します。 JWTユーザー・アサーションの特性は次のとおりです: クライアントにユーザー資格証明の知識は必要ありません。ブラウザベースのエンドユーザー操作はありません。リフレッシュ・トークンが許可されます。アクセス・トークンは、エンド・ユーザーのコンテキスト内にあります。このOAuthフローは次のとおりです。ユーザーは、生成されたユーザー・アサーションを送信してクライアント・アプリケーションにアクセスしようとします。クライアント・アプリケーションは、ユーザー・アサーションまたはサード・パーティのユーザー・アサーションを提供することで、アクセス・トークン(多くの場合はリフレッシュ・トークン)をリクエストします。 Oracle Identity Cloud Service認可サーバーは、クライアント・アプリケーションにアクセス・トークンを返します。クライアント・アプリケーションは、APIコールでアクセス・トークンを使用して統合を起動します。	この権限付与は、ユーザーの介入なしで統合をプログラムで起動するアプリケーションで使用されます。クライアント・アプリケーションは、トークン・アクセスのリクエスト中にユーザー・アサーションをOracle Identity Cloud Serviceに送信することで、ユーザーを偽装します。ユーザー・コンテキストでアクセス・トークンが返されます。ユーザーは、特定のコール元アプリケーションを識別するために作成された人間またはサービス統合アカウントを表すことができます。 Oracle Integrationでは、ユーザーの介入なしで統合をプログラム的に開始する必要があるアプリケーションによるOAuthアクセス・トークンを取得するために、この付与の使用をお薦めします。リスク (ファースト・パーティ/信頼できるクライアントでのみ)この権限付与を慎重に使用してください。これは、サービスに対するより高度な権限のあるアカウントに対する簡易的な偽装を可能にするためです。使用方法「JWTユーザー・アサーションの前提条件」を参照してください。
認可コード	許可コード権限付与タイプは、webおよびモバイル・アプリケーションで使用されます。他のほとんどの権限付与タイプとは異なり、最初にアプリケーションでブラウザを起動して統合を開始する必要があります。高レベルでは、統合は次のステップで構成されます: ブラウザが開き、ユーザーがOAuthサーバーに送信されます。ユーザーに認可プロンプトが表示され、アプリケーション・リクエストが承認されます。ユーザーは、問合せ文字列に認可コードが含まれるアプリケーションにリダイレクトされます。アプリケーションは、認可コードをアクセス・トークンと交換します。認可コードには、次の特性があります: クライアントにユーザー資格証明の知識は必要ありません。ブラウザベースのエンド・ユーザー操作です。リフレッシュ・トークンが許可されます。アクセス・トークンは、エンド・ユーザーのコンテキスト内にあります。このOAuthフローは次のとおりです。ユーザーがwebサーバー・クライアント・アプリケーションのリンクをクリックして、保護されたリソースへのアクセスをリクエストします。クライアント・アプリケーションは、認可コードのリクエストを使用して、ブラウザをOracle Identity Cloud Service認可エンドポイントにリダイレクトします: `oauth2/v1/authorize` 　 Oracle Identity Cloud Service認可サーバーは、リソース所有者が同意を付与した後にブラウザ・リダイレクトを介してクライアント・アプリケーションに認可コードを返します。次に、クライアント・アプリケーションは、認可コードをアクセス・トークン(多くの場合、リフレッシュ・トークンとともに)と交換します。　 Oracle Identity Cloud Service認可サーバーは、クライアント・アプリケーションにアクセス・トークンを返します。クライアント・アプリケーションは、APIコールでアクセス・トークンを使用して統合を起動します。	この権限は、統合を起動する可能性があるユーザー操作を含むwebポータルやモバイル・アプリケーションなどのアプリケーションで使用されます。このタイプのユースケースでは、ユーザーがwebポータル/モバイル・アプリケーションにサインインすると、Oracle Integrationに対して認証してアプリケーションが統合を開始できるようにすることで、同意が明示的に提供されます。使用方法「認証コードの前提条件」を参照してください。
リソース所有者のパスワード資格証明(ROPC)	アクセス・トークンを取得するための認可付与として、OAuthクライアントがリソース所有者のパスワード資格証明(つまり、ユーザー名とパスワード)を直接使用できます。リソース所有者のパスワード資格証明権限付与タイプは、リソース所有者がOAuthクライアントと信頼関係を持つ場合に適しています。リソース所有者のパスワード資格証明の付与を使用する場合、ユーザーが資格証明(ユーザー名とパスワード)を直接アプリケーションに指定します。次に、アプリケーションが資格証明を使用して、OAuthトークン・サービスからアクセス・トークンを取得します。リソース所有者のパスワード資格証明の付与は、クライアント・アプリケーションがそのクライアント識別子およびシークレットとともにユーザー名とパスワードを送信して、アクセス・トークンと交換する付与ワークフローです。ユーザーは、webインタフェースでログインして認可リクエストを承認するかわりに、クライアント・アプリケーション・ユーザー・インタフェースでユーザー名とパスワードを直接入力できます。このワークフローには、他のOAuthワークフローとは異なるセキュリティ・プロパティがあります。主な違いは、アプリケーションからユーザーのパスワードにアクセスできることです。このことは、アプリケーションに対するユーザーの強い信頼を必要とします。リソース所有者のパスワード資格証明の付与には、次の特性があります: クライアントには、ユーザー資格証明に関する知識が必要です。ブラウザベースのエンド・ユーザー操作ではありません。リフレッシュ・トークンが許可されます。アクセス・トークンは、エンド・ユーザーのコンテキスト内にあります。このOAuthフローは次のとおりです。ユーザーは、保護されたリソースへのアクセスをリクエストするクライアント・アプリケーション内のリンクをクリックします。クライアント・アプリケーションは、リソース所有者のユーザー名とパスワードをリクエストします。ユーザーは自分のユーザー名とパスワードでログインします。クライアント・アプリケーションは、これらの資格証明をOracle Identity Cloud Service認可サーバーからアクセス・トークン(通常はリフレッシュ・トークン)と交換します。 Oracle Identity Cloud Service認可サーバーは、クライアント・アプリケーションにアクセス・トークンを返します。クライアント・アプリケーションは、APIコールでアクセス・トークンを使用して統合を起動します。	この権限付与は、ユーザーの介入なしでプログラムによって統合を起動するアプリケーションで使用できます。この権限は、ユーザー資格証明を安全に処理する信頼できるファースト・パーティのクライアントでのみ使用します。この権限付与タイプは、クライアント・アプリケーションでOAuthアクセス・トークンを取得して、プログラム的な方法で統合を起動するリクエストを送信するために使用できますが、Oracle Integrationは、次のリスクのためにリソース所有者のパスワード資格証明の付与を推奨しません: リスクこの権限付与タイプは、このプロトコルが回避するために検索するパスワード・アンチ・パターンを保持するため、他の権限付与タイプよりもリスクが高くなります。クライアントがパスワードを不正に使用したり、パスワードが攻撃者に誤って公開される可能性があります(たとえば、ログ・ファイルやクライアントによって保持されているその他のレコードを介して)。アプリケーションは、パスワード資格証明を取得すると、ユーザー・リソースへの完全なアクセス権を持つスコープをリクエストできます。パスワードの有効期限が切れます。この権限は現在非推奨の状態です。使用方法「リソース所有者のパスワード資格証明の前提条件」を参照してください。

JWTユーザー・アサーション

(推奨値)

ユーザー・アサーションとは、ユーザーに関するアイデンティティ情報を含むユーザー・トークンです。ユーザーは、特定のコール元アプリケーションを識別するために作成された人間またはサービス統合アカウントを表すことができます。

ユーザー・アサーションは、アクセス・トークンを取得するための許可付与として直接使用されます。クライアント詳細は、リクエスト内の認証ヘッダーまたはクライアント・アサーションとして指定されます。

ユーザーの資格証明は公開されないため、ユーザー・アサーションの付与はリソース所有者のパスワード資格証明の付与よりも安全です。

ユーザー・アサーション・ワークフロー:

機密クライアントとともに使用されます。 OAuthクライアントは、ユーザー/サービス統合アカウントのかわりにユーザー/サービス統合アカウント・アイデンティティをアサートすることが信頼されます。
リソース所有者資格証明(Oracle Integrationユーザー)は、クライアント・アプリケーションからアクセスできません。リソース所有者のアサーションのみを使用します。
リダイレクション・ベースではありません。クライアント・アプリケーションから認可サーバーへのリクエストのみを受け取ります。ユーザーは、リクエストを認可するためにインタフェース間でリダイレクトされません。

このユーザー・アサーション権限付与は、次のように機能します:

クライアントでは、ユーザー・アサーションを指定することによって、アクセス・トークンをリクエストします。クライアント詳細は、リクエスト内の認証ヘッダーまたはクライアント・アサーションとして指定されます。
OAuthサービスはクライアントを認証し、有効な場合はアクセス・トークンを提供します。

JWTユーザー・アサーションの特性は次のとおりです:

クライアントにユーザー資格証明の知識は必要ありません。
ブラウザベースのエンドユーザー操作はありません。
リフレッシュ・トークンが許可されます。
アクセス・トークンは、エンド・ユーザーのコンテキスト内にあります。

このOAuthフローは次のとおりです。

ユーザーは、生成されたユーザー・アサーションを送信してクライアント・アプリケーションにアクセスしようとします。
クライアント・アプリケーションは、ユーザー・アサーションまたはサード・パーティのユーザー・アサーションを提供することで、アクセス・トークン(多くの場合はリフレッシュ・トークン)をリクエストします。
Oracle Identity Cloud Service認可サーバーは、クライアント・アプリケーションにアクセス・トークンを返します。
クライアント・アプリケーションは、APIコールでアクセス・トークンを使用して統合を起動します。

この権限付与は、ユーザーの介入なしで統合をプログラムで起動するアプリケーションで使用されます。

クライアント・アプリケーションは、トークン・アクセスのリクエスト中にユーザー・アサーションをOracle Identity Cloud Serviceに送信することで、ユーザーを偽装します。ユーザー・コンテキストでアクセス・トークンが返されます。

ユーザーは、特定のコール元アプリケーションを識別するために作成された人間またはサービス統合アカウントを表すことができます。

Oracle Integrationでは、ユーザーの介入なしで統合をプログラム的に開始する必要があるアプリケーションによるOAuthアクセス・トークンを取得するために、この付与の使用をお薦めします。

リスク

(ファースト・パーティ/信頼できるクライアントでのみ)この権限付与を慎重に使用してください。これは、サービスに対するより高度な権限のあるアカウントに対する簡易的な偽装を可能にするためです。

使用方法

「JWTユーザー・アサーションの前提条件」を参照してください。

認可コード

許可コード権限付与タイプは、webおよびモバイル・アプリケーションで使用されます。他のほとんどの権限付与タイプとは異なり、最初にアプリケーションでブラウザを起動して統合を開始する必要があります。高レベルでは、統合は次のステップで構成されます:

ブラウザが開き、ユーザーがOAuthサーバーに送信されます。
ユーザーに認可プロンプトが表示され、アプリケーション・リクエストが承認されます。
ユーザーは、問合せ文字列に認可コードが含まれるアプリケーションにリダイレクトされます。
アプリケーションは、認可コードをアクセス・トークンと交換します。

認可コードには、次の特性があります:

クライアントにユーザー資格証明の知識は必要ありません。
ブラウザベースのエンド・ユーザー操作です。
リフレッシュ・トークンが許可されます。
アクセス・トークンは、エンド・ユーザーのコンテキスト内にあります。

このOAuthフローは次のとおりです。

ユーザーがwebサーバー・クライアント・アプリケーションのリンクをクリックして、保護されたリソースへのアクセスをリクエストします。
クライアント・アプリケーションは、認可コードのリクエストを使用して、ブラウザをOracle Identity Cloud Service認可エンドポイントにリダイレクトします:
```
oauth2/v1/authorize
```
　
Oracle Identity Cloud Service認可サーバーは、リソース所有者が同意を付与した後にブラウザ・リダイレクトを介してクライアント・アプリケーションに認可コードを返します。
次に、クライアント・アプリケーションは、認可コードをアクセス・トークン(多くの場合、リフレッシュ・トークンとともに)と交換します。
　
Oracle Identity Cloud Service認可サーバーは、クライアント・アプリケーションにアクセス・トークンを返します。
クライアント・アプリケーションは、APIコールでアクセス・トークンを使用して統合を起動します。

この権限は、統合を起動する可能性があるユーザー操作を含むwebポータルやモバイル・アプリケーションなどのアプリケーションで使用されます。このタイプのユースケースでは、ユーザーがwebポータル/モバイル・アプリケーションにサインインすると、Oracle Integrationに対して認証してアプリケーションが統合を開始できるようにすることで、同意が明示的に提供されます。

使用方法

「認証コードの前提条件」を参照してください。

リソース所有者のパスワード資格証明(ROPC)

アクセス・トークンを取得するための認可付与として、OAuthクライアントがリソース所有者のパスワード資格証明(つまり、ユーザー名とパスワード)を直接使用できます。

リソース所有者のパスワード資格証明権限付与タイプは、リソース所有者がOAuthクライアントと信頼関係を持つ場合に適しています。

リソース所有者のパスワード資格証明の付与を使用する場合、ユーザーが資格証明(ユーザー名とパスワード)を直接アプリケーションに指定します。次に、アプリケーションが資格証明を使用して、OAuthトークン・サービスからアクセス・トークンを取得します。

リソース所有者のパスワード資格証明の付与は、クライアント・アプリケーションがそのクライアント識別子およびシークレットとともにユーザー名とパスワードを送信して、アクセス・トークンと交換する付与ワークフローです。ユーザーは、webインタフェースでログインして認可リクエストを承認するかわりに、クライアント・アプリケーション・ユーザー・インタフェースでユーザー名とパスワードを直接入力できます。このワークフローには、他のOAuthワークフローとは異なるセキュリティ・プロパティがあります。主な違いは、アプリケーションからユーザーのパスワードにアクセスできることです。このことは、アプリケーションに対するユーザーの強い信頼を必要とします。

リソース所有者のパスワード資格証明の付与には、次の特性があります:

クライアントには、ユーザー資格証明に関する知識が必要です。
ブラウザベースのエンド・ユーザー操作ではありません。
リフレッシュ・トークンが許可されます。
アクセス・トークンは、エンド・ユーザーのコンテキスト内にあります。

このOAuthフローは次のとおりです。

ユーザーは、保護されたリソースへのアクセスをリクエストするクライアント・アプリケーション内のリンクをクリックします。
クライアント・アプリケーションは、リソース所有者のユーザー名とパスワードをリクエストします。
ユーザーは自分のユーザー名とパスワードでログインします。
クライアント・アプリケーションは、これらの資格証明をOracle Identity Cloud Service認可サーバーからアクセス・トークン(通常はリフレッシュ・トークン)と交換します。
Oracle Identity Cloud Service認可サーバーは、クライアント・アプリケーションにアクセス・トークンを返します。
クライアント・アプリケーションは、APIコールでアクセス・トークンを使用して統合を起動します。

この権限付与は、ユーザーの介入なしでプログラムによって統合を起動するアプリケーションで使用できます。

この権限は、ユーザー資格証明を安全に処理する信頼できるファースト・パーティのクライアントでのみ使用します。

この権限付与タイプは、クライアント・アプリケーションでOAuthアクセス・トークンを取得して、プログラム的な方法で統合を起動するリクエストを送信するために使用できますが、Oracle Integrationは、次のリスクのためにリソース所有者のパスワード資格証明の付与を推奨しません:

リスク

この権限付与タイプは、このプロトコルが回避するために検索するパスワード・アンチ・パターンを保持するため、他の権限付与タイプよりもリスクが高くなります。クライアントがパスワードを不正に使用したり、パスワードが攻撃者に誤って公開される可能性があります(たとえば、ログ・ファイルやクライアントによって保持されているその他のレコードを介して)。
アプリケーションは、パスワード資格証明を取得すると、ユーザー・リソースへの完全なアクセス権を持つスコープをリクエストできます。
パスワードの有効期限が切れます。
この権限は現在非推奨の状態です。

使用方法

「リソース所有者のパスワード資格証明の前提条件」を参照してください。

アイデンティティ・ドメイン環境でのOAuth 2.0付与の使用

Oracle Integrationのアイデンティティ・ドメイン環境で、このアダプタでOAuth 2.0権限付与タイプを使用するには、次の前提条件を実行する必要があります。

アイデンティティ・ドメインへのアクセス

アイデンティティ・ドメイン管理者資格証明を使用して、Oracle Cloud Infrastructureコンソールにログインします。
1. ナビゲーション・ペインで、「アイデンティティ&セキュリティ」をクリックします。
2. 「ドメイン」をクリックします。
3. コンパートメントを選択します。
4. アイデンティティ・ドメインをクリックします。
5. ナビゲーション・ペインで、「統合アプリケーション」をクリックします。
  これは、権限付与タイプのクライアント・アプリケーションを作成するロケーションです。

リソース所有者のパスワード資格証明の前提条件

OAuthとの統合をトリガーするには、クライアント・アプリケーションが必要です。

クライアント・アプリケーションの構成

「Add application」をクリックします。
「機密アプリケーション」を選択し、「ワークフローの起動」をクリックします。
名前を入力します。このページの残りのフィールドはオプションであり、無視してかまいません。
「次へ」をクリックします。
「クライアント構成」ボックスで、「このアプリケーションをクライアントとして構成」を選択します。
リソース所有者のパスワード資格証明の場合は、「許可された付与タイプ」セクションで「リソース所有者」および「トークンをリフレッシュ」を選択します。
次のステップを実行します。
1. 「リダイレクトURL」、「ログアウト後リダイレクトURL」および「ログアウトURL」フィールドは空白のままにします。
2. 「クライアント・タイプ」で、「機密」が選択されていることを確認します。
3. 複数のフィールドをバイパスし、「トークン発行ポリシー」セクションまで下にスクロールします。
4. 「認可されたリソース」セクションで「特定」を選択します。
5. 「リソースの追加」チェック・ボックスをクリックします。
6. 「スコープの追加」をクリックします。
7. インスタンスのOracle Integrationアプリケーションを検索し、をクリックします。
8. 次の詳細が追加された2つのスコープを選択します:
  - urn:opc:resource:consumer::all
  - ic/api/
9. 「追加」をクリックします。
  スコープが「リソース」セクションに表示されます。
10. 「アプリケーション・ロールの追加」チェック・ボックスを無視します。この選択は必要ありません。
11. 「次」、「終了」の順にクリックします。
クライアント・アプリケーションの詳細ページが表示されます。
「アクティブ化」、「アプリケーションのアクティブ化」の順にクリックして、使用するクライアント・アプリケーションをアクティブ化します。
「一般情報」セクションで、クライアントIDおよびクライアント・シークレットの値を書き留めます。これらの値は、アイデンティティ・ドメインと通信しているサード・パーティ・アプリケーションに必要です。

クライアント・アプリケーションへのロールの追加

ナビゲーション・ペインで、Oracle Cloud Servicesをクリックします。
Oracle Integrationインスタンスに対応する特定のアプリケーションを選択します。
ナビゲーション・ペインで、「アプリケーション・ロール」をクリックします。
リソース所有者のパスワード資格証明権限付与タイプの場合は、次を選択します:
1. ServiceInvokerを展開し、「割当済ユーザー」または「割当済グループ」の横にある「管理」をクリックします。たとえば、割当済ユーザーをクリックすると、次のようになります:
2. 「使用可能なユーザーの表示」をクリックします。
3. ユーザーを選択し、「割り当て」をクリックしてから、「閉じる」をクリックします。

リソース所有者のパスワード資格証明権限付与タイプのクライアント・アプリケーションを検証します。

アクセス・クライアントをフェッチするには、ペイロードでユーザー名とパスワードを使用してリクエストします。

##Syntax
curl -i -H 'Authorization: Basic <base64Encoded_clientid:secret>' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<Identity_Domain_Service_Instance>.identity.oraclecloud.com/oauth2/v1/token -d 'grant_type=password&username=<user-name>&password=<password>&scope=<App_Scope>%20offline_access'
 
###where
#### <base64-clientid-secret> - Base 64 encode clientId:ClientSecret
#### <username> - user for token needs to be issued (must be in serviceinvoker role).
#### <password> - password for above user
#### <app_scope> - Scope added while creating application in client configuration section (Ends with urn:opc:resource:consumer::all)
##Example
curl -i -H 'Authorization: Basic OGQyM...ZDA0Mjcz' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<identity_domain_host>/oauth2/v1/token -d 'grant_type=password&username=sampleUser&password=SamplePassword&scope=https://<Resource_APP_Audience>urn:opc:resource:consumer::all%20offline_access'

レスポンスからaccess_tokenおよびrefresh_tokenを取得します。

{
    "access_token": "eyJ4NXQjG...dfsdfsFgets2ed",
    "token_type": "Bearer",
    "expires_in": 3600,
    "refresh_token": "AQAgY2MzNjVlOTVhOTRh...vM5S0MkrFSpzc="
}

認可ヘッダーのaccess_tokenを使用して、Oracle Integrationトリガー・エンドポイントを起動します。
```
curl --location --request GET 'https://OIC host/OIC endpoint' \
--header 'Authorization: Bearer eyJ4NXQjG...dfsdfsFgets2ed'
```
アクセス・トークンを更新するには、リフレッシュ・トークンを使用してリクエストします。

レスポンスからaccess_tokenおよびrefresh_tokenを取得して、さらに使用します。

curl -i -H 'Authorization: Basic <base64-clientid-secret>' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<Identity_Domain_Service_Instance>.identity.oraclecloud.com/oauth2/v1/token  -d 'grant_type=refresh_token&refresh_token=<refresh_token>'
 
##Example
curl -i -H 'Authorization: Basic OGQyM...ZDA0Mjcz' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<Identity_Domain_Service_Instance>.identity.oraclecloud.com/oauth2/v1/token  -d 'grant_type=refresh_token&refresh_token=AQAgY2MzNjVlOTVhOTRh...vM5S0MkrFSpzc='

JWTユーザー・アサーションの前提条件

キーの生成

JWTユーザー・アサーションのクライアント・アプリケーションを構成するときに、インポートするキーを最初に生成する必要があります。

自己署名キー・ペアを生成します。

keytool -genkey -keyalg RSA -alias <your_alias> -keystore <keystore_file> -storepass <password> -validity 365 -keysize 2048
 
##example
keytool -genkey -keyalg RSA -alias assert -keystore sampleKeystore.jks -storepass samplePasswd -validity 365 -keysize 2048

JWTアサーションに署名するための公開キーをエクスポートします。

keytool -exportcert -alias <your_alias> -file <filename> -keystore <keystore_file> -storepass <password>
 
##example
keytool -exportcert -alias assert -file assert.cer -keystore sampleKeystore.jks -storepass samplePasswd
 
## This should show a success message e.g. Certificate stored in file <assert.cer>

キーストアをP12形式に変換します。

keytool -importkeystore -srckeystore <filename> -srcstorepass <password> -srckeypass <password> -srcalias <your_alias> -destalias <your_alias> -destkeystore <destFileName> -deststoretype PKCS12 -deststorepass <password> -destkeypass <password>
 
##example
keytool -importkeystore -srckeystore sampleKeystore.jks -srcstorepass samplePasswd -srckeypass samplePasswd -srcalias assert -destalias assert -destkeystore assert.p12 -deststoretype PKCS12 -deststorepass samplePasswd -destkeypass samplePasswd
 
## This should show a success message e.g. Importing keystore sampleKeystore.jks to assert.p12...

P12キーストアから秘密キーをエクスポートします。

openssl pkcs12 -in <destFileName> -nodes -nocerts -out <pem_file>
 
##example
openssl pkcs12 -in assert.p12 -nodes -nocerts -out private_key.pem
 
## This should show a success message: MAC verified OK

クライアント・アプリケーションの構成

OAuthとの統合をトリガーするには、クライアント・アプリケーションが必要です。

「Add application」をクリックします。
「機密アプリケーション」を選択し、「ワークフローの起動」をクリックします。
名前を入力します。このページの残りのフィールドはオプションであり、無視してかまいません。
「次へ」をクリックします。
「クライアント構成」ボックスで、「このアプリケーションをクライアントとして構成」を選択します。
JWTユーザー・アサーションで、「許可された付与タイプ」セクションで「JWTアサーション」および「トークンをリフレッシュ」を選択します。
付与タイプに対して次のステップを実行します:
1. 「リダイレクトURL」、「ログアウト後リダイレクトURL」および「ログアウトURL」フィールドは空白のままにします。
2. 「クライアント・タイプ」セクションで、「信頼」を選択します。
3. 「キーの生成」セクションで作成した証明書をアップロードします。このアクションは、証明書を信頼できるパートナとして追加します。
4. 複数のフィールドをバイパスし、「トークン発行ポリシー」セクションまで下にスクロールします。
5. 「認可されたリソース」セクションで「特定」を選択します。
6. 「リソースの追加」チェック・ボックスをクリックします。
7. 「スコープの追加」をクリックします。
8. インスタンスのOracle Integrationアプリケーションを検索し、をクリックします。
9. 次の詳細が追加された2つのスコープを選択します:
  - urn:opc:resource:consumer::all
  - ic/api/
10. 「追加」をクリックします。
  スコープが「リソース」セクションに表示されます。
11. 「アプリケーション・ロールの追加」チェック・ボックスを無視します。この選択は必要ありません。
12. 「次」、「終了」の順にクリックします。
  クライアント・アプリケーションの詳細ページが表示されます。
13. 「アクティブ化」、「アプリケーションのアクティブ化」の順にクリックして、使用するクライアント・アプリケーションをアクティブ化します。
14. 「一般情報」セクションで、クライアントIDおよびクライアント・シークレットの値を書き留めます。これらの値は、アイデンティティ・ドメインと通信しているサード・パーティ・アプリケーションに必要です。
ナビゲーション・ペインで、Oracle Cloud Servicesをクリックします。
Oracle Integrationインスタンスに対応する特定のアプリケーションを選択します。
ナビゲーション・ペインで、「アプリケーション・ロール」をクリックします。
ServiceInvokerを展開し、「割当済ユーザー」または「割当済グループ」の横にある「管理」をクリックします。たとえば、割当済ユーザーをクリックすると、次のようになります:
「使用可能なユーザーの表示」をクリックします。
ユーザーを選択し、「割り当て」をクリックしてから、「閉じる」をクリックします。

信頼できるパートナとしての証明書の追加

署名証明書をクライアント・アプリケーションにインポートするだけでなく、証明書を信頼できるパートナ証明書として含める必要もあります。

ナビゲーション・ペインで、「設定」をクリックします。
「信頼できるパートナ証明書」をクリックします。
「証明書のインポート」をクリックして、セクション「キーの生成」で作成した証明書をアップロードします。

JWTユーザー・アサーションの生成

生成された秘密キーと単純なJavaコードを使用してJWTユーザー・アサーションを生成します。

ノート:
https://github.com/jwtk/jjwtライブラリを使用して、ユーザー・アサーションを生成できます。 https://jwt.io/には、複数のテクノロジ用に多数のライブラリがリストされています。
```
Sample:
header:
{
"alg": "RS256",
"typ": "JWT",
"kid": "assert"
}
 
payload:
{
"sub": "ssaInstanceAdmin",
"jti": "8c7df446-bfae-40be-be09-0ab55c655436",
"iat": 1589889699,
"exp": 1589909699,
"iss": "d702f5b31ee645ecbc49d05983aaee54",
"aud": "https://identity.oraclecloud.com/"
}
```
説明:
- subでは、ユーザー・アサーションが生成されるユーザー名を指定します。
- jtiは一意の識別子です
- iatが発行されます(エポック秒)。
- expはトークンの有効期限(エポック秒)です。
- issはクライアントIDです。
- audには、アイデンティティ・ドメイン・オーディエンスhttps://identity.oracle.com/が含まれている必要があります。署名アルゴリズムはRS256である必要があります。
- kidは、シグネチャの検証に使用するキーを指定します。したがって、アップロードした証明書の別名と一致する必要があります。

クライアント・アプリケーションの検証

JWTユーザー・アサーションを生成したら、次のようにアクセス・トークンを生成します。

##Syntax
curl -i -H 'Authorization: Basic <base64Encoded clientid:secret>' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<Identity_Domain_Service_Instance>.identity.oraclecloud.com/oauth2/v1/token -d 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=<user assertion>&scope=<app_scope>'
  
###where
#### grant type - urn:ietf:params:oauth:grant-type:jwt-bearer
#### <base64-clientid-secret> - Base 64 encode clientId:ClientSecret
#### <user assertion> - User assertion generated
#### <app scope> - Scope added while creating application in client configuration section (Ends with urn:opc:resource:consumer::all)

レスポンスからaccess_tokenを取得します。

{
    "access_token": "eyJ4NXQjG...dfsdfsFgets2ed",
    "token_type": "Bearer",
    "expires_in": 3600
}

認可ヘッダーのaccess_tokenを使用して、Oracle Integrationトリガー・エンドポイントを起動します。
```
curl --location --request GET 'https://OIC host/OIC endpoint' \
--header 'Authorization: Bearer eyJ4NXQjG...dfsdfsFgets2ed'
```

認証コードの前提条件

クライアント・アプリケーションの構成

OAuthとの統合をトリガーするには、クライアント・アプリケーションが必要です。

「Add application」をクリックします。
「機密アプリケーション」を選択し、「ワークフローの起動」をクリックします。
名前を入力します。このページの残りのフィールドはオプションであり、無視してかまいません。
「次へ」をクリックします。
「クライアント構成」ボックスで、「このアプリケーションをクライアントとして構成」を選択します。

使用する付与タイプを選択します:

認可コードの場合は、「許可された付与タイプ」セクションで「トークンをリフレッシュ」および「承認コード」を選択します。

「リダイレクトURL」フィールドに、クライアント・アプリケーションのリダイレクトURLを入力します。ユーザー・ログイン後、このURLは認可コードでリダイレクトされます。複数のリダイレクトURLを指定できます。これは、複数のインスタンスがあるが、ライセンスの問題が原因でクライアント・アプリケーションが1つのみである開発環境に役立ちます。

ノート:

次の情報がわからない場合は、管理者に確認してください:

インスタンスが新規であるか、Oracle Integration Generation 2 Generation 2からOracle Integration Generation 2にアップグレードされた場合。
リージョンを含む完全なインスタンスURL (新しいインスタンスで必要)。

接続用… リダイレクトURLの一部としてリージョンを含めますか。指定するリダイレクトURLの例…

接続用…	リダイレクトURLの一部としてリージョンを含めますか。	指定するリダイレクトURLの例…
新しいOracle Integration Generation 2インスタンスで作成されます	はい	`https://OIC_instance_URL.region.ocp.oraclecloud.com/icsapis/agent/oauth/callback`
Oracle Integration Generation 2 Generation 2からOracle Integration Generation 2にアップグレードされたインスタンスで作成されます	番号このことは両方とも該当します: アップグレード後に作成された新しい接続アップグレードの一部であった既存の接続	`https://OIC_instance_URL.ocp.oraclecloud.com/icsapis/agent/oauth/callback`

新しいOracle Integration Generation 2インスタンスで作成されます

はい

https://OIC_instance_URL.region.ocp.oraclecloud.com/icsapis/agent/oauth/callback

Oracle Integration Generation 2 Generation 2からOracle Integration Generation 2にアップグレードされたインスタンスで作成されます

番号

このことは両方とも該当します:

アップグレード後に作成された新しい接続
アップグレードの一部であった既存の接続

https://OIC_instance_URL.ocp.oraclecloud.com/icsapis/agent/oauth/callback

「クライアント・タイプ」セクションで、「機密」をクリックします。
「認可されたリソース」セクションで「特定」を選択します。
「リソースの追加」チェック・ボックスをクリックします。
「スコープの追加」をクリックします。
インスタンスのOracle Integrationアプリケーションを検索し、をクリックします。
次の詳細が追加された2つのスコープを選択します:
- urn:opc:resource:consumer::all
- ic/api/
「追加」をクリックします。
スコープが「リソース」セクションに表示されます。
「アプリケーション・ロールの追加」チェック・ボックスを無視します。この選択は必要ありません。
「次」、「終了」の順にクリックします。
クライアント・アプリケーションの詳細ページが表示されます。
「アクティブ化」、「アプリケーションのアクティブ化」の順にクリックして、使用するクライアント・アプリケーションをアクティブ化します。
「一般情報」セクションで、クライアントIDおよびクライアント・シークレットの値を書き留めます。これらの値は、アイデンティティ・ドメインと通信しているサード・パーティ・アプリケーションに必要です。

Oracle Integrationアプリケーション・ロールおよびユーザー・ロールの検証

ナビゲーション・ペインで、Oracle Cloud Servicesをクリックします。
Oracle Integrationインスタンスに対応する特定のアプリケーションを選択します。
ナビゲーション・ペインで、「アプリケーション・ロール」をクリックします。
ServiceInvokerを展開し、「割当済ユーザー」または「割当済グループ」の横にある「管理」をクリックします。たとえば、割当済ユーザーをクリックすると、次のようになります:
「使用可能なユーザーの表示」をクリックします。
ユーザーを選択し、「割り当て」をクリックしてから、「閉じる」をクリックします。

クライアント・アプリケーションの検証

認可コードをフェッチするには、ブラウザから次のリクエストを実行します。

##Syntax
GET https://<Identity_Domain_Service_Instance>.identity.oraclecloud.com/oauth2/v1/authorize?client_id=<client-id>&response_type=code&redirect_uri=<client-redirect-uri>&scope=<app_scope>%20offline_access&nonce=<nonce-value>&state=<unique_value>
 
###where
#### <client-id> - ID of Client application generated.
#### <client-redirect-uri> - Redirect URI, in client application.
#### <app_scope> - scope added while creating application in client configuration. (Ends with urn:opc:resource:consumer::all)
#### nonce - Optional, unique value to mitigate replay attacks
#### state - Recommended, Opaque to IDCS. Value used to maintain state between the request and the callback
##Example
GET https://<identity_domain_host>/oauth2/v1/authorize?client_id=<clientID>&response_type=code&redirect_uri=https://app.getpostman.com/oauth2/callback&scope=https://<Resource_APP_Audience>urn:opc:resource:consumer::all%20offline_access&nonce=121&state=12345544

ユーザーがまだログインしていない場合は、ユーザー資格証明の認証が要求されます。 (認証の場合は、ServiceInvokerロールを割り当てられたユーザーを使用する必要があります。)
認証が成功すると、クライアントURLは認可コードおよび状態がURLに追加されてリダイレクトされます。
```
##Response URL
https://<redirect_URL>?code=<code_value>=&state=<state_value>
 
###Client should validate state received is same as one sent in request.
```

前述のレスポンスからコード値を取得し、次のリクエストを実行してアクセス・トークンを取得します。

##Syntax
curl -i -H 'Authorization: Basic <base64-clientid-secret>' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<Identity_Domain_Service_Instance>.identity.oraclecloud.com/oauth2/v1/token -d 'grant_type=authorization_code&code=<authz-code>&redirect_uri=<client-redirect-uri>
 
###where
#### <base64-clientid-secret> - BAse 64 encode clientId:ClientSecret
#### <authz-code> - code value received as response on redirect.
#### <client-redirect-uri> - Redirect URI, in client application.
 
##Example
curl -i -H 'Authorization: Basic MDMx..NGY1' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<identity_domain_host>/oauth2/v1/token -d 'grant_type=authorization_code&code=AQAg...3jKM4Gc=&redirect_uri=https://app.getpostman.com/oauth2/callback

レスポンスからaccess_tokenおよびrefresh_tokenを取得します。

{
    "access_token": "eyJ4NXQjG...dfsdfsFgets2ed",
    "token_type": "Bearer",
    "expires_in": 3600,
    "refresh_token": "AQAgY2MzNjVlOTVhOTRh...vM5S0MkrFSpzc="
}

認可ヘッダーのaccess_tokenを使用して、Oracle Integrationトリガー・エンドポイントを起動します。
```
curl --location --request GET 'https://OIC host/OIC endpoint' \
--header 'Authorization: Bearer eyJ4NXQjG...dfsdfsFgets2ed'
```
アクセス・トークンを更新するには、リフレッシュ・トークンを使用してリクエストを行います。

さらに使用するために、レスポンスからaccess_tokenおよびrefresh_tokenを取得します。

curl -i -H 'Authorization: Basic <base64-clientid-secret>' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<Identity_Domain_Service_Instance>.identity.oraclecloud.com/oauth2/v1/token  -d 'grant_type=refresh_token&refresh_token=<refresh_token>'
 
 
##Example
curl -i -H 'Authorization: Basic OGQyM...ZDA0Mjcz' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<Identity_Domain_Service_Instance>.identity.oraclecloud.com/oauth2/v1/token  -d 'grant_type=refresh_token&refresh_token=AQAgY2MzNjVlOTVhOTRh...vM5S0MkrFSpzc='

Oracle Identity Cloud Service環境でのOAuth 2.0付与の使用

Oracle IntegrationでこのアダプタでOAuth 2.0権限付与タイプを使用するには、次の前提条件を実行する必要があります。

ノート:

次の手順は、Oracle Identity Cloud Serviceを引き続き使用しているクラウド・テナンシに「のみ」適用します。ほとんどのクラウド・テナンシはアイデンティティ・ドメインに移行されており、異なる構成手順が必要です。「アイデンティティ・ドメイン環境でのOAuth 2.0権限の使用」を参照してください。環境が不明な場合は、管理者に確認してください。

ノート:

OAuth 2.0権限を実行する前に、次の制限を理解してください。

外部クライアント・アプリケーションで、システムが作成したOracle Identity Cloud Serviceアプリケーションを使用してOracle Integrationエンドポイントに対する認証を行わないでください。
クライアント・アプリケーションのスコープは、そのサービス・インスタンスにデプロイされたすべての統合にアクセスすることです。統合のサブセットへのアクセスを制限するためのサポートはありません。

すべての権限付与の前提条件

使用する権限タイプごとに次のタスクを実行します。

Oracle Identity Cloud Service URLを取得します。
1. Oracle IntegrationインスタンスのURLに移動します。
  たとえば、Oracle Integrationインスタンスがhttps://myhost.example.com/ic/homeの場合、そのURLに移動すると、次のようなURLにリダイレクトされます:
```
 https://idcs-c2881.identity.myhost.example.com/ui/v1/signin
```
2. /signinを/adminconsoleに置き換えて、Oracle Identity Cloud Serviceにアクセスします。
  たとえば:
```
https://idcs-c2881.identity.myhost.example.com/ui/v1/adminconsole
```
  Oracle Identity Cloud Serviceコンソールに再度サインインするように求められます。
3. アイデンティティ・ドメイン管理者資格証明を使用してOracle Identity Cloud Serviceコンソールにログインします。
Oracle Identity Cloud ServiceのOracle Integrationアプリケーションを確認します。
Oracle Integrationインスタンスがプロビジョニングされると、そのOracle Integrationインスタンスに対してOracle Identity Cloud Serviceアプリケーションが作成されます。アプリケーション名はOICINST_ service_instance_nameです。
1. Oracleインスタンスにログインして、サービス・インスタンス名を取得します。
```
https://myhost.example.com/ic/home
```
2. Oracle Identity Cloud Serviceにログインしてアプリケーションを取得します。
3. 「アプリケーション」に移動し、前述の名前のアプリケーションを検索してアプリケーションにアクセスします。
または、Oracle Cloudダッシュボードからアプリケーションを見つけることもできます。 Oracle Integrationインスタンスの詳細ページ(この例ではOIC)で「IDCSアプリケーション」リンクをクリックすると、すでに作成されているOracle IntegrationのOracle Identity Cloud Serviceアプリケーションがオープンします。

JWTユーザー・アサーションの前提条件

次のタスクを実行します。

Oracle Integrationアプリケーションおよびユーザー・ロールを検証します。
1. Oracle Identity Cloud Serviceアプリケーションで「リフレッシュ・トークンを許可するかどうか」オプションが有効になっていることを確認します。
2. アプリケーションの「構成」>「リソース」セクションで確認します。 OAuthを使用して統合をトリガーできる特別なスコープが事前定義されていることにも注意してください(urn:opc:resource : consumer::all)。
  
  「図ropc1.pngの説明」
3. 適切なユーザーを様々なOracle Integrationロールに追加します。標準/本番構成の場合は、ServiceUserロールを使用します。 (「Oracle Integration Generation 2のプロビジョニングと管理」の「Oracle Integrationロール」を参照してください。)
4. ユーザーを割り当てるには、アプリケーションの「アプリケーション・ロール」セクションに移動します。
  
  「図oauth_grant1.pngの説明」

キーを生成します:

自己署名キー・ペアを生成します。

keytool -genkey -keyalg RSA -alias <your_alias> -keystore <keystore_file> -storepass <password> -validity 365 -keysize 2048
 
##example
keytool -genkey -keyalg RSA -alias assert -keystore sampleKeystore.jks -storepass samplePasswd -validity 365 -keysize 2048

JWTアサーションに署名するための公開キーをエクスポートします。

keytool -exportcert -alias <your_alias> -file <filename> -keystore <keystore_file> -storepass <password>
 
##example
keytool -exportcert -alias assert -file assert.cer -keystore sampleKeystore.jks -storepass samplePasswd
 
## This should show a success message e.g. Certificate stored in file <assert.cer>

キーストアをP12形式に変換します。

keytool -importkeystore -srckeystore <filename> -srcstorepass <password> -srckeypass <password> -srcalias <your_alias> -destalias <your_alias> -destkeystore <destFileName> -deststoretype PKCS12 -deststorepass <password> -destkeypass <password>
 
##example
keytool -importkeystore -srckeystore sampleKeystore.jks -srcstorepass samplePasswd -srckeypass samplePasswd -srcalias assert -destalias assert -destkeystore assert.p12 -deststoretype PKCS12 -deststorepass samplePasswd -destkeypass samplePasswd
 
## This should show a success message e.g. Importing keystore sampleKeystore.jks to assert.p12...

P12キーストアから秘密キーをエクスポートします。

openssl pkcs12 -in <destFileName> -nodes -nocerts -out <pem_file>
 
##example
openssl pkcs12 -in assert.p12 -nodes -nocerts -out private_key.pem
 
## This should show a success message: MAC verified OK

クライアント・アプリケーションを構成します:
OAuthとの統合をトリガーするには、クライアント・アプリケーションが必要です。
1. Oracle Identity Cloud Serviceコンソールで、「アプリケーション」セクションに移動して、OAuthとの統合をトリガーできる新しいアプリケーションを作成します。
  
  アプリケーションは機密アプリケーションとして追加されます。
  
  「
  図oauth_grant61.pngの説明」
2. 「詳細」セクションに入力し、「クライアント」セクションに移動します。
  
  「図oauth_grant7.pngの説明」
3. 「クライアント」セクションで、「このアプリケーションをクライアントとして構成」を選択し、次を追加します。
  1. 「許可された許可タイプ」の「クライアント資格証明」および「JWTアサーション」を選択します。
  2. 「セキュリティ」セクションで、「信頼できるクライアント」を選択し、前の項(「キーの生成 - ステップ2」)で作成した証明書をアップロードします。
  3. 「承認済リソース」セクションで「特定」を選択します。
    
    「図add_conf_app.pngの説明」
  4. 「リソース」セクションの下の「スコープの追加」をクリックします。
  5. Oracle Integrationアプリケーションを検索し、>をクリックします。
  6. urn:opc:resource: consumer::allを含むスコープを追加し、>をクリックします。
    urn:opc:resource : consumer::allを含むスコープが追加されます。
  7. 変更を保存します。
4. ウィザードの残りのステップをスキップして、アプリケーションを保存します。
5. 使用するアプリケーションをアクティブ化します。
信頼できるパートナとして証明書を追加します:
署名証明書をアプリケーションにインポートした場合でも、Oracle Identity Cloud Serviceでは、信頼できるパートナ証明書としての証明書も必要です。前の項で作成した証明書をアップロードします。 (「キーの生成 - ステップ2」を参照してください。)
JWTユーザー・アサーションを生成します:
1. 生成された秘密キーと単純なJavaコードを使用してJWTユーザー・アサーションを生成します。
  
  ノート:
  https://github.com/jwtk/jjwtライブラリを使用して、ユーザー・アサーションを生成できます。 https://jwt.io/には、複数のテクノロジ用に多数のライブラリがリストされています。
```
Sample:
header:
{
"alg": "RS256",
"typ": "JWT",
"kid": "assert"
}
 
payload:
{
"sub": "ssaInstanceAdmin",
"jti": "8c7df446-bfae-40be-be09-0ab55c655436",
"iat": 1589889699,
"exp": 1589909699,
"iss": "d702f5b31ee645ecbc49d05983aaee54",
"aud": "https://identity.oraclecloud.com/"
}
```
説明:
- subでは、ユーザー・アサーションが生成されるユーザー名を指定します。
- jtiは一意の識別子です
- iatが発行されます(エポック秒)。
- expはトークンの有効期限(エポック秒)です。
- issはクライアントIDです。
- audには、Oracle Identity Cloud Serviceオーディエンスhttps://identity.oracle.com/を含める必要があります。署名アルゴリズムはRS256である必要があります。
- kidは、シグネチャの検証に使用するキーを指定します。そのため、Oracle Identity Cloud Serviceでアップロードした証明書の別名と一致する必要があります。

クライアント・アプリケーションを検証します:

JWTユーザー・アサーションを生成したら、次のようにOracle Identity Cloud Serviceアクセス・トークンを生成します。

##Syntax
curl -i -H 'Authorization: Basic <base64Encoded clientid:secret>' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<IDCS-Service-Instance>.identity.oraclecloud.com/oauth2/v1/token -d 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=<user assertion>&scope=<app_scope>'
  
###where
#### grant type - urn:ietf:params:oauth:grant-type:jwt-bearer
#### <base64-clientid-secret> - Base 64 encode clientId:ClientSecret
#### <user assertion> - User assertion generated
#### <app scope> - Scope added while creating application in client configuration section (Ends with urn:opc:resource:consumer::all)

レスポンスからaccess_tokenを取得します。

{
    "access_token": "eyJ4NXQjG...dfsdfsFgets2ed",
    "token_type": "Bearer",
    "expires_in": 3600
}

認可ヘッダーのaccess_tokenを使用して、Oracle Integrationトリガー・エンドポイントを起動します。
```
curl --location --request GET 'https://OIC host/OIC endpoint' \
--header 'Authorization: Bearer eyJ4NXQjG...dfsdfsFgets2ed'
```

認証コードの前提条件

次のタスクを実行します。

Oracle Integrationアプリケーションおよびユーザー・ロールを検証します:
1. Oracle Identity Cloud Serviceアプリケーションで「リフレッシュ・トークンを許可するかどうか」オプションが有効になっていることを確認します。
2. アプリケーションの「構成」>「リソース」セクションを確認します。 OAuthを使用したOracle Integration統合のトリガーを許可する特殊な事前定義スコープ(urn:opc:resource: consumer::all)もあります。
  
  「図ropc1.pngの説明」
3. 適切なユーザーを様々なOracle Integrationロールに追加します。標準/本番構成の場合は、ServiceUserロールを使用します。 (「Oracle Integration Generation 2のプロビジョニングと管理」の「Oracle Integrationロール」を参照してください。)
4. ユーザーを割り当てるには、アプリケーションの「アプリケーション・ロール」セクションに移動します。
  
  「図oauth_grant1.pngの説明」
クライアント・アプリケーションを構成します:
OAuthとのOracle Integration統合をトリガーできるようにするには、クライアント・アプリケーションが必要です。
1. Oracle Identity Cloud Serviceコンソールで、「アプリケーション」セクションに移動して、OAuthとのOracle Integration統合をトリガーできる新しいアプリケーションを作成します。
  
  アプリケーションは機密アプリケーションとして追加されます。
  「
  図oauth_grant6.pngの説明」
2. 「詳細」セクションに入力し、「クライアント」セクションに移動します。
  
  図oauth_grant71.pngの説明
3. 「クライアント」の選択で、「このアプリケーションをクライアントとして構成」を選択し、次を追加します。
  1. 「リフレッシュ・トークン」および「認可コード」 for 「許可された許可タイプ」を選択します。
  2. リダイレクトURLをクライアント・アプリケーションのURL (https://sample_client_app/oauth2/callbackなど)に設定します。ユーザー・ログイン後、Oracle Identity Cloud Serviceは認可コードを使用してこのURLにリダイレクトします。
  3. 「承認済リソース」セクションで「特定」を選択します。
    
    「図authorization.pngの説明」
  4. 「リソース」セクションの下の「スコープの追加」をクリックします。
  5. Oracle Integrationアプリケーションを検索し、>をクリックします。
  6. urn:opc:resource : consumer::allを含むスコープを追加し、>をクリックします。
    
    urn:opc:resource : consumer::allを含むスコープが追加されます。
  7. 変更を保存します。
4. ウィザードの残りのステップをスキップして、アプリケーションを保存します。
5. 使用するアプリケーションをアクティブ化します。

クライアント・アプリケーションを検証します:

認可コードをフェッチするには、ブラウザから次のリクエストを実行します。

##Syntax
GET https://<IDCS-Service-Instance>.identity.oraclecloud.com/oauth2/v1/authorize?client_id=<client-id>&response_type=code&redirect_uri=<client-redirect-uri>&scope=<app_scope>%20offline_access&nonce=<nonce-value>&state=<unique_value>
 
###where
#### <client-id> - ID of Client application generated.
#### <client-redirect-uri> - Redirect URI, in client application.
#### <app_scope> - scope added while creating application in client configuration. (Ends with urn:opc:resource:consumer::all)
#### nonce - Optional, unique value to mitigate replay attacks
#### state - Recommended, Opaque to IDCS. Value used to maintain state between the request and the callback
##Example
GET https://<idcs-host>/oauth2/v1/authorize?client_id=<clientID>&response_type=code&redirect_uri=https://app.getpostman.com/oauth2/callback&scope=https://<Resource_APP_Audience>urn:opc:resource:consumer::all%20offline_access&nonce=121&state=12345544

ユーザーがまだログインしていない場合、Oracle Identity Cloud Serviceはユーザーを認証しようとします。 Oracle Identity Cloud Serviceは、ユーザー資格証明をチェックします。 (認証の場合、ServiceUserロールが割り当てられたユーザーを使用する必要があります。)
認証が成功すると、Oracle Identity Cloud Serviceは、認可コードとURLに追加された状態を使用してクライアント・リダイレクトURLにリダイレクトします。
```
##Response URL
https://<redirect_URL>?code=<code_value>=&state=<state_value>
 
###Client should validate state received is same as one sent in request.
```

前述のレスポンスからコード値を取得し、Oracle Identity Cloud Serviceに次のリクエストを実行してアクセス・トークンを取得します。

##Syntax
curl -i -H 'Authorization: Basic <base64-clientid-secret>' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<IDCS-Service-Instance>.identity.oraclecloud.com/oauth2/v1/token -d 'grant_type=authorization_code&code=<authz-code>&redirect_uri=<client-redirect-uri>
 
###where
#### <base64-clientid-secret> - BAse 64 encode clientId:ClientSecret
#### <authz-code> - code value received as response on redirect.
#### <client-redirect-uri> - Redirect URI, in client application.
 
##Example
curl -i -H 'Authorization: Basic MDMx..NGY1' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<idcs_host>/oauth2/v1/token -d 'grant_type=authorization_code&code=AQAg...3jKM4Gc=&redirect_uri=https://app.getpostman.com/oauth2/callback

レスポンスからaccess_tokenおよびrefresh_tokenを取得します。

{
    "access_token": "eyJ4NXQjG...dfsdfsFgets2ed",
    "token_type": "Bearer",
    "expires_in": 3600,
    "refresh_token": "AQAgY2MzNjVlOTVhOTRh...vM5S0MkrFSpzc="
}

認可ヘッダーのaccess_tokenを使用して、Oracle Integrationトリガー・エンドポイントを起動します。
```
curl --location --request GET 'https://OIC host/OIC endpoint' \
--header 'Authorization: Bearer eyJ4NXQjG...dfsdfsFgets2ed'
```
アクセス・トークンを更新するには、リフレッシュ・トークンを使用してOracle Identity Cloud Serviceにリクエストします。

さらに使用するために、レスポンスからaccess_tokenおよびrefresh_tokenを取得します。

curl -i -H 'Authorization: Basic <base64-clientid-secret>' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<IDCS-Service-Instance>.identity.oraclecloud.com/oauth2/v1/token  -d 'grant_type=refresh_token&refresh_token=<refresh_token>'
 
 
##Example
curl -i -H 'Authorization: Basic OGQyM...ZDA0Mjcz' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://IDCS-Service-Instance.identity.oraclecloud.com/oauth2/v1/token  -d 'grant_type=refresh_token&refresh_token=AQAgY2MzNjVlOTVhOTRh...vM5S0MkrFSpzc='

リソース所有者のパスワード資格証明の前提条件

次のタスクを実行します。

Oracle Integrationアプリケーションおよびユーザー・ロールを検証します:
1. Oracle Integration Oracle Identity Cloud Serviceアプリケーションで「リフレッシュ・トークンを許可するかどうか」オプションが有効になっていることを確認します。
2. 「アプリケーション」の「構成」>「リソース」セクションを確認します。また、OAuthとの統合のトリガーを可能にする特別な事前定義済スコープ(urn:opc:resource : consumer::all)もあります。
  
  「図ropc1.pngの説明」
3. 適切なユーザーを様々なOracle Integrationロールに追加します。標準/本番構成の場合は、ServiceUserロールを使用します。 (「Oracle Integration Generation 2のプロビジョニングと管理」の「Oracle Integrationロール」を参照してください。)
4. ユーザーを割り当てるには、アプリケーションの「アプリケーション・ロール」セクションに移動します。
  
  「図oauth_grant1.pngの説明」
クライアント・アプリケーションを構成します:
1. Oracle Identity Cloud Serviceコンソールで、「アプリケーション」セクションに移動して、OAuthとの統合をトリガーできる新しいアプリケーションを作成します。アプリケーションは機密アプリケーションとして追加されます。
  
  「図oauth_grant6.pngの説明」
2. 「詳細」セクションに入力し、「クライアント」セクションに移動します。
  
  図oauth_grant71.pngの説明
3. 「クライアント」の選択で、「このアプリケーションをクライアントとして構成」を選択し、次を追加します。
  1. 「リソース所有者」および「リフレッシュ・トークン」 for 「許可された許可タイプ」を選択します。
  2. 「承認済リソース」セクションで「特定」を選択します。
    
    「図ropc2.pngの説明」
  3. 「リソース」セクションの下の「スコープの追加」をクリックします。
  4. Oracle Integrationアプリケーションを検索します。
  5. urn:opc:resource : consumer::allを含むスコープを追加し、>をクリックします。
    
    urn:opc:resource : consumer::allを含むスコープが追加されます。
  6. 変更を保存します。
4. ウィザードの残りのステップをスキップして、アプリケーションを保存します。
5. 使用するアプリケーションをアクティブ化します。

クライアント・アプリケーションを検証します:

アクセス・クライアントをフェッチするには、ペイロードでユーザー名とパスワードを使用してOracle Identity Cloud Serviceにリクエストします。

##Syntax
curl -i -H 'Authorization: Basic <base64Encoded_clientid:secret>' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<IDCS-Service-Instance>.identity.oraclecloud.com/oauth2/v1/token -d 'grant_type=password&username=<user-name>&password=<password>&scope=<App_Scope>%20offline_access'
 
###where
#### <base64-clientid-secret> - Base 64 encode clientId:ClientSecret
#### <username> - user for token needs to be issued (must be in serviceuser role).
#### <password> - password for above user
#### <app_scope> - Scope added while creating application in client configuration section (Ends with urn:opc:resource:consumer::all)
##Example
curl -i -H 'Authorization: Basic OGQyM...ZDA0Mjcz' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<idcs_host>/oauth2/v1/token -d 'grant_type=password&username=sampleUser&password=SamplePassword&scope=https://<Resource_APP_Audience>urn:opc:resource:consumer::all%20offline_access'

レスポンスからaccess_tokenおよびrefresh_tokenを取得します。

{
    "access_token": "eyJ4NXQjG...dfsdfsFgets2ed",
    "token_type": "Bearer",
    "expires_in": 3600,
    "refresh_token": "AQAgY2MzNjVlOTVhOTRh...vM5S0MkrFSpzc="
}

認可ヘッダーのaccess_tokenを使用して、Oracle Integrationトリガー・エンドポイントを起動します。
```
curl --location --request GET 'https://OIC host/OIC endpoint' \
--header 'Authorization: Bearer eyJ4NXQjG...dfsdfsFgets2ed'
```
アクセス・トークンを更新するには、リフレッシュ・トークンを使用してOracle Identity Cloud Serviceにリクエストします。

レスポンスからaccess_tokenおよびrefresh_tokenを取得して、さらに使用します。

curl -i -H 'Authorization: Basic <base64-clientid-secret>' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<IDCS-Service-Instance>.identity.oraclecloud.com/oauth2/v1/token  -d 'grant_type=refresh_token&refresh_token=<refresh_token>'
 
##Example
curl -i -H 'Authorization: Basic OGQyM...ZDA0Mjcz' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<IDCS-Service-Instance>.identity.oraclecloud.com/oauth2/v1/token  -d 'grant_type=refresh_token&refresh_token=AQAgY2MzNjVlOTVhOTRh...vM5S0MkrFSpzc='

認証タイプ

「RESTアダプタ」では、次のタイプの認証がサポートされます:

「RESTアダプタ」が外部RESTエンドポイントを起動するシナリオの場合:
- Basic認証
- OAuthクライアント資格証明(2レッグ・フロー)
- OAuthリソース所有者のパスワード資格証明(2レッグ・フロー)
- OAuth認証コード資格証明(3レッグ・フロー)
- OAuthカスタム3レッグ・フロー
- OAuthカスタム2レッグ・フロー
- APIキー・ベース認証
- OAuth 1.0 1レッグ認証
- Amazon Web Services (AWS)シグネチャ・バージョン4
- Oracle Cloud Infrastructure (OCI)シグネチャ・バージョン1
「RESTアダプタ」を使用して統合をトリガーするRESTエンドポイントを作成するシナリオの場合:
- Basic認証
- OAuth 2.0
- OAuth 2.0またはBasic認証

これらのセキュリティ・ポリシーの詳細については、「接続セキュリティの構成」を参照してください。

ロールベースの接続

「RESTアダプタ」は双方向です。「RESTアダプタ」は、接続を使用するコンテキストに応じて構成できます。

トリガー: 「RESTアダプタ」は、統合をトリガーするRESTエンドポイントを作成するために使用されます。「新しい接続を作成」ダイアログの「ロール」リストから「トリガー」を選択します。トリガーとして構成した場合、ベースURIは不要です。インバウンド方向で定義したセキュリティ・ポリシーは、アイデンティティ・ドメインで構成されている資格証明を受け入れます。したがって、該当する資格証明を指定する必要はありません。「Connections」ページでセキュリティを構成する際には、インバウンド・エンドポイントにアタッチする必要があるセキュリティ・ポリシーのみを指定します。次のセキュリティ・ポリシーを使用できます:
- Basic認証
- OAuth 2.0
- 基本認証とOAuth 2.0
エージェント構成は、トリガー・ロールが設定された接続に対して適用できません。
起動: 「RESTアダプタ」は、外部RESTエンドポイントの呼出しに使用されます。外部保護リソースにアクセスするためのベースURIおよびセキュリティ構成が必要です。「Connections」ページで、このような詳細の追加入力を求められます。トリガー側で呼出し接続を使用することはできません。
トリガーと起動: 「RESTアダプタ」は、統合のトリガーおよび呼出し方向の両方で使用されます。この接続には、呼出し値とトリガー値が必要です。 Basic認証は、トリガー接続と起動接続の両方で使用できます。

「接続を作成」を参照してください。

複数のOAuthプロバイダのための拡張サポート

「RESTアダプタ」の拡張フレームワークを使用して、エンドポイントのOAuthで保護されたリソースにアクセスできます。このフレームワークにより、固有の種類のOAuthを実装したエンドポイントにアクセスできます。

OAuth標準は、エンドポイントで独自のOAuthフローの特定の側面を定義するための柔軟性を提供します。たとえば:

独自のプロパティを作成します。
OAuthフローでこれらのプロパティを使用するタイミングを決定します。たとえば、認証リクエストで必須となるカスタム・プロパティもありますが、アクセス・トークン・リクエストまたは失効後のアクセス・トークンのリフレッシュで必須となるものもあります。
OAuthフローでこれらのプロパティを渡す方法を決定します。たとえば、ヘッダー、問合せパラメータ、ペイロードのいずれとしてプロパティを渡すかを決定します。

これらの課題に対処するため、Oracle Integrationは、「RESTアダプタ」接続を作成するときにOAuthフローの各ステップを指定できる2つのカスタム・セキュリティ・ポリシーを提供します:

OAuth custom two-legged flow: クライアント・アプリケーションはリソース所有者にかわって認証サーバーと直接対話します。
OAuth custom three-legged flow: クライアント・アプリケーションは所有者を別のリソースURLにリダイレクトし、そこでリソース所有者が認証を行い、フローを続行することに同意します。

これにより、ほとんどのOAuthフレームワークのシナリオに適応し、追加のコーディングなしで多くのサードパーティ・アプリケーションと統合することができます。

設計時に、アクセス・トークンが取得および検証され、CSFに格納されます。セキュリティ・トークンもCSFに格納されます。
ランタイム時に、アクセス・トークンが取得、適用および管理されます。有効なアクセス・トークンは、RESTエンドポイントを呼び出す前にリクエストに適用されます。

OAuthカスタムの2足歩行と3足歩行のセキュリティ・ポリシーを指定します。「接続セキュリティの構成」と「RESTアダプタの使用例」を参照してください。

ノート:

この拡張機能は高度な機能であり、ビジネス・ユーザー向けではありません。この機能のユーザーは、Postmanなどのツールを使用して、必要なプロパティを構成してください。