Mule OAuth プロバイダーを使用する OAuth 2.0 アクセストークン適用ポリシー

ポリシー名

Mule OAuth プロバイダーを使用する OAuth 2.0 アクセストークン適用ポリシー

概要

承認されたクライアントアプリケーションへのアクセスのみを許可する

カテゴリ

セキュリティ

使用可能な最小 Mule バージョン

v4.1.1

返される状況コード

400 - 無効なトークン

401 - 未承認または認証サーバーへの接続時にエラー

403 - アクセス拒否、無効なクライアントアプリケーションログイン情報

500 - 認証サーバーからの不正応答、または WSDL SOAP 失敗エラー。

概要

Mule OAuth プロバイダーとのみ連携する OAuth 2.0 アクセストークン適用ポリシーは、API アクセス権のあるクライアントアプリケーションに属する有効な OAuth 2 トークンを提供する HTTP 要求のみに、保護されたリソースへのアクセスを制限します。このポリシーはトークンを生成せず、トークンを検証するだけです。

このポリシーは、​Mule OAuth プロバイダー​でのみ使用するように設計されています。このポリシーを他の OAuth 2.0 プロバイダー (Facebook、Google、Microsoft Azure など) で使用することはできません。

ポリシーのパラメーターの設定

Flex Gateway のローカルモード

OAuth 2.0 アクセストークン適用ポリシーは、Flex Gateway のローカルモードではサポートされません。

Flex Gateway の接続モード

OAuth 2.0 アクセストークン適用ポリシーは、Flex Gateway の接続モードではサポートされません。

Mule ゲートウェイ

UI からポリシーを API に適用するときに、パラメーターのリストが表示されます。

要素 説明

スコープ

サポートされるスコープのカンマ区切りリストを表示します。

READ​、​WRITE​、​READ and WRITE

Scope Validation Criteria (スコープ検証条件)

トークンに定義済みのすべてのスコープが含まれる必要があるか、1 つのみ含まれる必要があるかを決定します。 この値は、​Contains all scopes​ と ​Contains any scope​ です。

[Contains all scopes (すべてのスコープを含む)] 値が選択されている場合、スコープ ​READ​ と ​WRITE​ を持つトークンが受け入れられます。[Contains any scopes (いずれかのスコープを含む)] 値が選択されている場合、スコープ ​READ​、​WRITE​、​READ AND WRITE​ を持つトークンが受け入れられます。

Access Token validation endpoint url (アクセストークン検証エンドポイント URL)

外部 OAuth 2 プロバイダーのアクセストークン検証エンドポイントの URL。

クライアントによってホストされる Mule プロバイダーへのリンク: http://client-hostetd-mule-provider-url.cloudhub.io/validate。

Validate TLS Certificate (TLS 証明書の検証)

サードパーティ認証サーバーの TLS 検証を有効にします。

選択した場合、トークン検証エンドポイントとの通信には TLS プロトコルが使用されます。

Expose Headers (ヘッダーを公開)

プロキシのシナリオで、バックエンドへの要求でヘッダーを公開する必要があるかどうかを指定します。統合サーバーによって返されるユーザープロパティは、「X-AGW-」というプレフィックスが付けられ、ヘッダーとしてバックエンドに送信されます。

この要素についての詳細は、​「Mule アプリケーションのトークン検証エンドポイント情報の活用」​を参照してください。

Skip Client Id Validation (クライアント ID 検証をスキップ)

クライアントアプリケーションの API コントラクト検証をスキップします。

選択した場合、​「ポリシーのしくみ」​セクションの図のステップ 4 がスキップされます。

Authentication request timeout (認証要求タイムアウト)

アクセストークン検証エンドポイントを認証するときに、応答を待機する最大時間 (ミリ秒単位) を設定します。

10000

ポリシーのしくみ

次の図は、Mule OAuth プロバイダーポリシーを使用する OAuth 2.0 トークン適用ワークフローを示しています。

OAuth 2.0 トークン適用ワークフロー

この図には次の動作が示されています。

  1. ユーザーが最初にポリシーで保護された API に HTTP 要求を送信します。

  2. ポリシーは要求からトークンを抽出し、それを検証エンドポイントに送信して、トークンの整合性を検証します。

  3. トークン検証エンドポイントは、クライアントアプリケーションのクライアント ID を含むトークンメタデータを返します。

  4. ポリシーは Anypoint Platform から以前に取得したコントラクトで更新されたローカルデータベースを使用して、クライアント ID が API にアクセスできるかどうかを検証します。

  5. すべての検証が正常に完了すると、要求はバックエンドに到達できます。

Mule アプリケーションのトークン検証エンドポイント情報の活用

トークン検証エンドポイントがトークンを正常に検証すると、Mule OAuth プロバイダーからの設定可能な項目などの特定の情報がポリシーに返されます。

次の例は、認証サーバーからのトークン検証応答を示しています:

---
{
    "uid":"john.doe",
    "mail":"john.doe@example.com"
    "token_type":"Bearer",
    "expires_in":3600,
    "alias" : ["Jhon", "Jhonny", "Mr Doe"],
    "address" : {
        "city": "london",
        "road": “abbey road"
    }

} --- OAuth プロバイダーによって返された項目はポリシーによって処理され、Mule フロー全体に伝播され、アクセスを要求しているアプリケーションが HTTP リクエスターを使用している場合は最終的にバックエンドに公開されます。

トークンキャッシュ

システムがトークンを検証すると、そのトークンは (デフォルトで) 期限切れになるまでキャッシュされるため、ポリシーのパフォーマンスが向上します。失効したトークンなどの特定のケースでは、キャッシュを最小限に抑えたり無効にしたりできます。

検証エンドポイントは、トークンの有効期限などの複数のプロパティをポリシーに送信します。有効期限情報がない場合、トークンはキャッシュされません。

トークンのキャッシュにかかる時間を制御するには、トークン検証エンドポイントに対して再検証を試みる前に、Mule Runtime Engine を起動するときに次のプロパティを指定します。

anypoint.platform.max_federation_expiration_time=<expiration time in seconds>

または、​wrapper.conf​ ファイルでこのパラメーターを指定できます。このプロパティを設定すると、指定された時間、またはトークンが期限切れになるまでのいずれか早い方でトークンがキャッシュされます。このプロパティが有効で、検証エンドポイントが有効期限情報を送信しない場合、トークンはキャッシュされません。

同時にキャッシュできるトークンの数を制御するには、Mule Runtime Engine を起動するときに次のプロパティを指定します。

anypoint.platform.oauth2_cache_max_size=<amount of tokens to be cached; default value is 10.000; specify 0 to disable caching>

または、​wrapper.conf​ ファイルでこのパラメーターを指定できます。

Expose Headers (ヘッダーを公開) オプションの設定

ポリシーで ​Expose Headers​ オプションを設定し、アプリケーション (標準のプロキシなど) が HTTP リクエスターを使用している場合、プロパティはヘッダーとしてバックエンドにリダイレクトされます。

各項目で、保護されたリソースへの元の要求は X-AGW- + <key>=<value> 形式を使用して HTTP ヘッダーで強化されます。前のセクションの応答例では、次のヘッダーが追加されています。

---
X-AGW-uid=john.doe
X-AGW-mail=john.doe@example.com
X-AGW-token_type=Bearer
---

伝播されたプロパティには、​scope​ および ​expires_in​ オブジェクトと配列は含まれません。

フロー内の以降の処理では、検証エンドポイントからの元の解析していない応答を使用できます。情報は認証オブジェクトに保存されます。

たとえば、​mail​ 項目がポリシーに返される場合、次の DataWeave 2.0 式を使用してこの項目の値にアクセスできます。

#[authentication.properties.userProperties.mail]

次の DataWeave 2.0 式を使用して、OAuth2 トークンのクライアント ID を取得できます。

#[authentication.principal]

プロキシを使用したトークン検証エンドポイントとの通信

Mule Runtime Engine の起動時に次のプロパティを指定することで、Mule OAuth プロバイダーポリシーを使用した OAuth 2.0 アクセストークン適用を有効にして、ゲートウェイプロキシ設定を使用できます。

anypoint.platform.external_authentication_provider_enable_proxy_settings=<true|false(default)>

このプロパティを有効にすると、次のパラメーターを設定している場合、ポリシーは Mule プロキシ設定を使用します。

  • anypoint.platform.proxy_host=localhost

  • anypoint.platform.proxy_port=8080

FAQs

ポリシーで OAuth 2.0 トークンを生成できますか?

番号ポリシーはトークンの検証のみを行います。

ポリシーで他の OAuth プロバイダーを使用できますか?

いいえ。 このポリシーは、​Mule OAuth プロバイダー​とのみ連携するように設計されています。このポリシーを他の OAuth プロバイダー (Facebook、Google、Azure など) で使用することはできません。

Mule OAuth プロバイダー検証エンドポイントがポリシーによって送信された要求を拒否している場合はどうすればよいですか?

検証エンドポイントが要求を拒否している場合は、ポリシーで設定された URL がポリシーを実行中のマシンから到達可能かどうか、および要求を正常に完了するために認証は不要かどうかを確認します。ユースケースで検証エンドポイントが保護されている必要がある場合は、​Open ID Connect ポリシー​に切り替えることができます。

OAuth トークンがキャッシュされる場所は?

OAuth 2.0 トークンはメモリにのみキャッシュされ、ディスクに書き込まれることはありません。

ポリシーは要求ごとに Anypoint Platform と通信しますか?

いいえ。ポリシーは以前に Mule Runtime Engine によって取得されたクライアントアプリケーションを使用します。 これにより、管理プレーンとの接続が失われた場合でも、ポリシーが機能し続けます。ディスクに書き込まれるクライアントアプリケーション情報を暗号化する場合は、​ランタイムでゲートウェイ暗号化を設定します​。

Mule OAuth プロバイダーポリシーを使用した OAuth 2.0 アクセストークン適用を設定した後に、レート制限 SLA ポリシーを設定できますか?

はい、できます。Mule OAuth プロバイダーポリシーを使用した OAuth 2.0 アクセストークン適用の後に、レート制限 SLA ポリシーを適用し、次の DataWeave 2.0 式を使用して ​Client ID Expression​ 値を指定します。

#[authentication.principal]

リクエスターの ID は、Mule OAuth プロバイダーポリシーを使用した OAuth 2.0 アクセストークン適用によってすでに検証されているため、​Client Secret Expression​ 項目は空のままにしておくことができます。

トークンが検証された後に、トークンに関連付けられた情報をどこで確認できますか?​ この情報は認証オブジェクトにあります。詳細は、​「Mule アプリケーションのトークン検証エンドポイント情報」​を参照してください。