原文はこちら。
https://blogs.oracle.com/integration/securely-connect-to-rest-apis-from-oracle-integration-cloud
Oracle REST Adapterは、外部RESTful APIを利用するにあたって包括的な方法を提供しています。このエントリでは、REST Adapterを使って保護されたAPIを利用する方法の概要をご紹介します。
Oracle Integration Cloud（OIC、以下OIC）は、保護されたAPIへのアクセスのためのセキュリティポリシーを指定するために利用できる再利用可能な接続を提供します。一度構成すれば、ユーザーは接続をテスト、保存、完成し、統合フロー内で他の接続と同様に利用できます。
REST Adapter接続を新たなセキュリティ資格証明で更新すると、その変更は自動的に全てのデプロイ済みの統合に伝播するため、統合フローのアップデートや再デプロイは必要ありません。統合フローの開発者は、新たなセキュリティ資格証明が統合フロー内で参照されるAPIやリソースに対して（以前のセキュリティ資格証明と）同じアクセス権限を有していることを確認しておく必要があります。
その他の変更、特にベースURI、SwaggerやRAMLドキュメントへのURLのような外部REST APIと関連するものである場合、影響を受けるフローを一度非アクティブ化した上で再アクティブ化する必要があったり、場合によっては、影響を受けるアダプターのエンドポイントを再編集が必要だったりする場合もあります。
以下のセキュリティポリシーをOICではサポートしています。
Basic Authentication
HTTP Basic認証はHTTPプロトコルに組み込まれているシンプルな認証スキームで、クライアントはHTTPリクエストをAuthorizationヘッダーで送信します。このAuthorizationヘッダーには、Basicに続いて空白、そしてユーザー名:パスワードをBase64でエンコードした文字列が設定されています。REST Adapterでは、Basic Authenticationセキュリティポリシーを選択し、ユーザー名とパスワードを指定する必要があります。
REST Adapterは資格証明がCredential Storeに安全に格納されることを保証します。API呼び出し時にAdapterはHTTPヘッダーにリクエストと共に以下のように注入します。
Authorization: Basic <base64-encoded-value-of-credentials>
テスト接続が成功しても、ユーザー名とパスワードは検証されません。統合の開発者が資格証明を事前に検証しておく必要があります。
API Key Based Authentication
API keyで保護されているAPIを利用する場合、統合開発者は
API Key Based Authenticationセキュリティポリシーを利用する必要があります。
REST Adapterは開発者に対し、API Keyをどのようにリクエストと共に送信する必要があるのかを宣言的に定義できる拡張性のあるインターフェースを提供しています。API呼び出し時にAdapterはリクエストと共に指定されたAPI Keyの利用方法に従ってAPI keyを注入します。
テスト接続が成功しても、API Keyは検証されてはいません。統合の開発者が事前にAPI Keyを検証しておく必要があります。
このセキュリティポリシーの詳細を知りたい方は、以下のエントリをご覧ください。
API-Key Based Authentication: Quickly and Easily
https://blogs.oracle.com/integration/api-key-based-authentication%3a-quickly-and-easily
https://orablogs-jp.blogspot.com/2018/10/api-key-based-authentication-quickly.html
OAuth Client Credentials
リソースオーナーの介入なくClient IdとClient Secretを使ってクライアントアプリケーションが直接アクセスを取得します。
REST Adapterでは、
OAuth Client Credentialsセキュリティポリシーを選択して必要な情報を設定する必要があります。
テスト接続では設定した資格証明を使ってアクセストークンを認可サーバから取得します。アクセストークンは安全に内部にキャッシュされ、必要に応じてリフレッシュされます。
REST Adapterは以下のようなセキュリティポリシーに設定された値を使ってアクセストークンを取得します。
curl -X POST -H 'Content-Type: [Auth Request Media Type]' -H "Accept: application/json" -H 'Authorization: Basic {base64#[YOUR_CLIENT_ID]:[YOUR_CLIENT_SECRET]}' -d ‘{'grant_type=client_credentials&scope=[YOUR_SCOPE]' '[YOUR_ACCESS_TOKEN_URI]'
During API呼び出し時にAdapterはリクエストと共に以下のようにアクセストークンをAuthorizationヘッダーとして注入します。
Authorization: Bearer <access_token_obtained_using_oauth_client_credentials>
アクセストークンは特定のスコープ用です。統合の開発者は接続を使って同一のスコープ内のリソースにアクセスできることを確認する必要があります。
［注意］
OAuth2仕様は、クライアント認証のための厳密なメカニズムを意図的に省略しています。保護されたリソースへのアクセスに使用されるアクセストークン属性とメソッドもこの仕様の範囲を超えています。その結果、標準ポリシーを使用して対処できないOAuth2の実装が数多くあります。
RFC 6749 The OAuth 2.0 Authorization Framework
Client Authentication
https://tools.ietf.org/html/rfc6749#section-2.3
Oracle REST Adapterでは任意のOAuthクライアント資格情報設定で使用できる柔軟な
Custom Two Legged OAuthセキュリティポリシーを利用できます。詳細は以下のエントリをご覧ください。後の章でも紹介します。
OAuth Custom Two Legged Security Policy In Oracle Integration Cloud
https://blogs.oracle.com/adapters/integrate-ics-with-a-third-party-oauth-protected-rest-service-using-the-generic-rest-adapter-part-1
OAuth Resource Owner Password Credentials
アクセストークン取得のために、認可グラントとして直接リソースオーナーパスワード資格証明を利用できます。リソースオーナーは資格証明をクライアントに共有するため、ポリシーを利用します。このポリシーは、リソースオーナーとクライアント間の
信頼度が高い場合に使用されます。
REST Adapterでは、ユーザーが
Resource Owner Password Credentialsセキュリティポリシーを選択して、必要な情報を設定する必要があります。
テスト接続時には入力した資格証明を使ってアクセストークンを認可サーバから取得します。このアクセストークンを安全に内部にキャッシュし、必要に応じてリフレッシュします。
REST Adapterは、以下のようにセキュリティポリシーに指定した値を使って、アクセストークンを入手します。
curl -X POST -H "Authorization: Basic {base64#[YOUR_CLIENT_ID]:[YOUR_CLIENT_SECRET]}" -H "Content-Type: [Auth Request Media Type]" -d '{"grant_type": "password", "scope": "[YOUR_SCOPE]", "username": "[USER_NAME]", "password": "[PASSWORD]" }' "[YOUR_ACCESS_TOKEN_URI]"
API呼び出し時にAdapterはAuthorizationヘッダーとしてアクセストークンをリクエストと共に以下のように注入します。
Authorization: Bearer <access_token_obtained_using_oauth_ropc>
アクセストークンは特定のスコープ用です。統合の開発者は接続を使って同一スコープ内のリソースにアクセスできることを確認する必要があります。
［注意］
OAuth2仕様は、クライアント認証のための厳密なメカニズムを意図的に省略しています。保護されたリソースへのアクセスに使用されるアクセストークン属性とメソッドもこの仕様の範囲を超えています。その結果、標準ポリシーを使用して対処できないOAuth2の実装が数多くあります。
RFC 6749 The OAuth 2.0 Authorization Framework
Client Authentication
https://tools.ietf.org/html/rfc6749#section-2.3
Oracle REST Adapterでは任意のOAuthクライアント資格情報設定で使用できる柔軟な
Custom Two Legged OAuthセキュリティポリシーを利用できます。詳細は以下のエントリをご覧ください。後の章でも紹介します。
OAuth Custom Two Legged Security Policy In Oracle Integration Cloud
https://blogs.oracle.com/adapters/integrate-ics-with-a-third-party-oauth-protected-rest-service-using-the-generic-rest-adapter-part-1
OAuth Custom Two Legged Flow
Custom Two leggedセキュリティポリシーにより、OICは
OAuth Client Credentialsおよび
OAuth Resource Owner Password Credentialsフローを使って保護されたサービスを含む、OAuthで保護された多くのサービスに接続するために必要な柔軟性を提供します。
REST Adapterでは、
OAuth Custom Two Legged Flowセキュリティポリシーを選択して、必要な情報を設定する必要があります。
テスト接続では設定された資格証明を使って認可サーバからアクセストークンを取得します。このアクセストークンは安全に内部にキャッシュされ、必要に応じてリフレッシュされます。
Access Token Usageは開発者に対し、アクセストークンをどのようにリクエストと共に送信する必要があるのかを宣言的に定義できる拡張性のあるインターフェースを提供しています。API呼び出し時にAdapterはリクエストと共にAccess Token Usageの指定に従ってアクセストークンを注入します。
アクセストークンは特定のスコープ用です。統合の開発者は接続を使って同一スコープ内のリソースへのアクセスを確認する必要があります。
詳細は以下のエントリをご覧ください。
OAuth Custom Two Legged Security Policy In Oracle Integration Cloud
https://blogs.oracle.com/adapters/integrate-ics-with-a-third-party-oauth-protected-rest-service-using-the-generic-rest-adapter-part-1
OAuth Authorization Code Credential
認可コードグラントは、クライアントアプリケーションにアクセストークンを付与する前にリソースオーナーの同意が必要なOAuthフローです。
REST Adapterでは、
OAuth Authorization Code Credentialセキュリティポリシーを選択して必要な情報を設定する必要があります。
構成が済めば、統合の開発者は
provide consentをクリックできます。この操作でユーザーは認可URLにリダイレクトされ、ここでリソースオーナーが認可サーバで認証、クライアントアプリケーションに同意を提供します。この操作でOAuthフローが無事に完了します。統合の開発者は接続をテスト、保存、完了でき、統合フロー内でその他の接続のように利用できます。
テスト接続では設定された同意フローが成功し、認可サーバからアクセストークンの取得を検証します。このアクセストークンは安全に内部にキャッシュされ、必要に応じてリフレッシュされます。
API呼び出し時に、Adpaterは以下のようにリクエストと共にAuthorizationヘッダーとしてアクセストークンを注入します。
Authorization: Bearer <access_token_obtained_using_code_authorization>
アクセストークンは特定のスコープ用です。統合の開発者は接続を使って同一スコープ内のリソースへのアクセスを確認する必要があります。
［注意］
OAuth2仕様は、クライアント認証のための厳密なメカニズムを意図的に省略しています。保護されたリソースへのアクセスに使用されるアクセストークン属性とメソッドもこの仕様の範囲を超えています。その結果、標準ポリシーを使用して対処できないOAuth2の実装が数多くあります。
RFC 6749 The OAuth 2.0 Authorization Framework
Client Authentication
https://tools.ietf.org/html/rfc6749#section-2.3
Oracle REST Adapterでは任意のOAuthクライアント資格情報設定で使用できる柔軟なCustom Three Legged OAuthセキュリティポリシーを利用できます。次章で紹介します。
OAuth Custom Three Legged Flow
OAuth Custom Three leggedセキュリティポリシーにより、OICは認可コードフローを使って保護されたサービスを含む、OAuth2で保護された多くのサービスに接続するために必要な柔軟性を提供します。
REST Adapterでは、
OAuth Custom Three Legged Flowセキュリティポリシーを選択し、必要な情報を設定する必要があります。
構成が済めば、統合の開発者は
provide consentをクリックできます。この操作でユーザーは認可URLにリダイレクトされ、ここでリソースオーナーが認可サーバで認証、クライアントアプリケーションに同意を提供します。この操作でOAuthフローが無事に完了します。統合の開発者は接続をテスト、保存、完了でき、統合フロー内でその他の接続のように利用できます。
テスト接続では設定された同意フローが成功し、認可サーバからのアクセストークン取得を検証します。このアクセストークンは安全に内部にキャッシュされ、必要に応じてリフレッシュされます。
同意の提供フローではリソースオーナーの操作が必要なので、アクセストークンを実行時にリソースオーナーが操作しなくてもアクセストークンをリフレッシュできるよう、アクセストークンのリフレッシュの仕組みを指定しておくことを推奨します。
Access Token Usageは開発者に対し、アクセストークンをどのようにリクエストと共に送信する必要があるのかを宣言的に定義できる拡張性のあるインターフェースを提供しています。API呼び出し時にAdapterはリクエストと共にAccess Token Usageの指定に従ってアクセストークンを注入します。
アクセストークンは特定のスコープ用です。統合の開発者は接続を使って同一スコープ内のリソースへのアクセスを確認する必要があります。
OAuth Custom Three Leggedポリシーを詳細に説明するエントリを今後用意する予定です。
OAuth 1.0 One legged Authentication
OAuth 1.0a (One-legged) を使うと、クライアントは認証されたHTTPリクエストに対し、リソースの資格証明で保護されたリソースへアクセスさせることができます。この方法は、各リクエストに2個の資格証明セットを含むように設計されています。1つはクライアントの識別、もう1つはリソース所有者の識別用途です。クライアントは、リソースオーナーに代わって認証されたリクエストを作成する前に、リソースオーナーが認可したトークンを取得する必要があります。
テスト接続では、必要な値が設定されているかどうかだけチェックします。実行時にこれらの資格情報を署名付きアクセストークンの生成に使用します。認証済みトークンは一度だけ使用されるため、生成されたトークンはキャッシュしません。
API呼び出し時にAdapterはリクエストと共にAuthorizationヘッダーとしてアクセストークンを注入します。
Authorization: OAuth <generated_oauth1.0a_access_token>
アクセストークンは特定のスコープ用です。統合の開発者は接続を使って同一スコープ内のリソースへのアクセスを確認する必要があります。
APIを使って外部のステークホルダーや内部のチームで情報を共有する、今日のConnected worldでは、セキュリティは最重要課題です。ほとんどのサービスプロバイダーは上記の機構を使ってAPIへのセキュアなアクセスを提供しています。このエントリでは、Oracle REST Adapterを使って安全にこれらの保護されたサービスを利用する方法をご紹介してきました。このあと、上記のほとんどのセキュリティポリシーの詳細説明をする予定です。特に、Custom OAuthポリシーは多数のOAuthで保護されたサービスと連携するための柔軟なインターフェイスを提供します。
