# mulesoft Mule ゲートウェイ (mule-gateway) - Full Documentation # Anypoint Mule ゲートウェイ Mule Runtime Engine には、埋め込み Mule ゲートウェイが含まれています。Mule ゲートウェイを使用すると、バックエンド API とサービスの上に専用のオーケストレーションレイヤーを追加できるため、実装からオーケストレーションを切り離すことができます。API Manager のガバナンス機能を使用して、調整、セキュリティ、キャッシュ、ログなどの機能を API に適用できます。 Mule ゲートウェイを使用すると、たとえば次のことを実行できます。 - 基本認証ポリシーを Mule アプリケーション上に適用する。 - 受信/送信メッセージを強化する。 - コードを記述することなく、他の複雑な機能を API に追加する。 ポリシーを適用し、分析情報を生成する必要がある場合、次のいずれかを使用する必要があります。 - Mule アプリケーションで定義されている API。 - 既存のバックエンド実装をプロキシする Mule アプリケーション。 詳細は、[Mule ゲートウェイの概要](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-capabilities-mule4)を参照してください。 # Anypoint Platform ゲートウェイ API ゲートウェイを使用すると、バックエンド API とサービスの上に専用のオーケストレーションレイヤーを追加できるため、実装に関する懸念事項からオーケストレーションを切り離すことができます。そして、API Manager のガバナンス機能を使用することで、調整、セキュリティ、キャッシュ、ログなどの機能を API に適用できます。 Anypoint Platform には、API を管理して保護するための 3 つの異なるランタイムオプションがあります。 ## [](#anypoint-flex-gateway)Anypoint Flex Gateway Anypoint Flex Gateway は、実行されている場所を問わずに API を管理して保護するように設計された超高速 API ゲートウェイです。 DevOps や CI/CD のワークフローとシームレスに統合できる Anypoint Flex Gateway は、要求量の多いアプリケーションやマイクロサービスで求められるパフォーマンスを保証しつつ、あらゆる環境でエンタープライズセキュリティと容易な管理を実現します。 詳細は、​[「Flex Gateway の使用開始」](https://docs.mulesoft.com/gateway/latest/gateway-getting-started)​を参照してください。 ## [](#anypoint_mule_gateway)Anypoint Mule ゲートウェイ Mule Runtime Engine には、埋め込み Mule ゲートウェイが含まれています。API Manager のガバナンス機能を使用して、調整、セキュリティ、キャッシュ、ログなどの機能を API に適用できます。 Mule ゲートウェイを使用すると、たとえば次のことを実行できます。 - 基本認証ポリシーを Mule アプリケーション上に適用する。 - 受信/送信メッセージを強化する。 - コードを記述することなく、他の複雑な機能を API に追加する。 ポリシーを適用し、分析情報を生成する必要がある場合、次のいずれかを使用する必要があります。 - Mule アプリケーションで定義されている API。 - 既存のバックエンド実装をプロキシする Mule アプリケーション。 詳細は、[Mule ゲートウェイの概要](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-capabilities-mule4)を参照してください。 ## [](#anypoint-service-mesh)Anypoint Service Mesh Anypoint Service Mesh は、MuleSoft 以外のアプリケーションを Anypoint Platform のエコシステムに組み込むことで、マイクロサービスネットワークを拡張します。そして、MuleSoft 以外のアプリケーションを含めたアプリケーションネットワークを、1 つのペインからシームレスに管理および保護できます。 ご利用の MuleSoft 以外のマイクロサービスは、異なる言語やプラットフォームを使用して作成されていたり、異なる環境にデプロイされていたりする場合があります。これらのマイクロサービスの違いによる問題を緩和するため、Anypoint Service Mesh は、次のような特長を備えたアプリケーション管理を実現します。 - ゼロトラストポリシーを使用したサービス間通信によってトラフィック制御、フォールトトレランス、そして負荷分散を処理します。 - MuleSoft の API 管理機能を Mule 以外のサービスにも拡張して、ポリシー、セキュリティ、そして分析を直接 Anypoint Platform から適用します。 - 今後のプロジェクトで使用できる Mule 以外のサービスを Exchange 内で検出し、サービスの再利用を最大限に高めます。 # API URL の設定 API バージョンの詳細ページで、デプロイする API のインバウンドエンドポイントを設定できます。Anypoint Platform で直接またはプロキシを介して API を管理するには、このアクションが必要です。RAML で baseURI の値を定義すると、API エンドポイント設定 \[Configure Endpoint (エンドポイントを設定)\] の \[Implementation URL (実装 URL)\] が設定されます。 1. API Manager の \[API Administration (API 管理)\] で、API バージョンのリンクをクリックします。 2. API バージョンの詳細ページで、\[Configure Endpoint (エンドポイントを設定)\] をクリックします。 3. プレースホルダー URL ではなく、API の実際のインバウンド URL を指定します。API がオンプレミスにデプロイされていてロードバランサーを使用している場合は、ここにロードバランサーエンドポイントを入力します。 4. 他の設定を定義するか受け入れて、API プロキシをセットアップしてデプロイします。 5. \[Configure (設定)\] をクリックします。 # API 自動検出 自動検出を設定すると、デプロイされた Mule Runtime Engine (Mule) アプリケーションで API Manager に接続し、ポリシーのダウンロードと管理や分析データの生成ができます。また、自動検出を使用すると、独自の API プロキシとして機能するように Mule アプリケーションを設定できます。 Mule アプリケーション内で自動検出が正しく設定されている場合、アプリケーションの API が API Manager ​_により追跡されている_​ (緑のドット) または API Manager ​_にペアリングされている_​とみなすことができます。Mule 設定の API は、一度に 1 つの自動検出インスタンスにのみ関連付けることができます。 ## [](#前提条件)前提条件 [Mule アプリケーションの自動検出を設定する](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-config-autodiscovery-mule4)​には、以下を確認します。 - API が API Manager に存在し、基本エンドポイントまたはプロキシエンドポイントのいずれかとして設定されている。 - Anypoint Platform ログイン情報を使用するように Mule アプリケーションが設定されている。 Platform ログイン情報により、API Manager 内の API 設定へのアクセス権がアプリケーションに付与されます。Mule を開始する前に Platform ログイン情報を設定する必要があります。 - 自動検出要素が Mule アプリケーション内で設定されている。 この XML 要素は、ペアリング先の API Manager 内の特定の API を参照している必要があります。 ## [](#プロキシエンドポイントと基本エンドポイント)プロキシエンドポイントと基本エンドポイント プロキシエンドポイントを設定した場合、自動生成プロキシは自動検出要素を使用してすでに適切に設定されています。また、1 クリックデプロイメントなどのプラットフォームデプロイメント機能を使用する場合、API Manager のログイン情報は自動的に設定されます。 ## [](#関連情報)関連情報 - [API プロキシ](https://docs.mulesoft.com/jp/api-manager/latest/api-proxy-landing-page) - [Mule 4 アプリケーションでの API 自動検出の設定](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-config-autodiscovery-mule4) - [Mule 3 アプリケーションでの API 自動検出の設定](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-config-autodiscovery-mule3) - [Mule Runtime 4 の組織のログイン情報の設定](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-org-credentials-mule4) - [Mule Runtime 3 の組織のログイン情報の設定](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-org-credentials-mule3) # CORS CORS (クロスオリジンリソース共有) 標準は、サーバーの HTTP ヘッダーを指定することで、Web ブラウザーを使用してデータを参照することが許可される発信元のセットを指定します。 GET (および場合によっては POST) 以外の HTTP メソッドに対して、この仕様では、ブラウザーが要求の​_プリフライト_​を行うことが規定されています。これは、HTTP OPTIONS 要求を使用してサーバーからサポート対象メソッドを取得することです。サーバーが承認すると、ブラウザーは実際の要求を HTTP OPTIONS 要求を使用して送信します。サーバーは、要求と共に Cookie や HTTP 認証トークンなどのログイン情報を送信するようにクライアントに通知することもできます。 要求のプリフライトを行うには、次の CORS 仕様に従って Mule アプリケーションのレスポンスヘッダーを設定します。 「ユーザーエージェントは、CORS API 仕様で定義された API にレスポンスヘッダーを公開する前に、単純なレスポンスヘッダーであるか、項目名が Access-Control-Expose-Headers ヘッダー (存在する場合) のいずれかの値に一致する ASCII (大文字と小文字を区別する) である場合以外のすべてのレスポンスヘッダーを除外する必要があります。」 リソースは、単純なメソッドと単純なヘッダー以外で処理の対象となるメソッドとヘッダーを指定し、ログイン情報をサポートするかどうかを指定します。単純な要求を実行すると、アプリケーションが設定したヘッダー (単純なリクエストヘッダー以外) が返されます。Mule アプリケーションにヘッダーが設定されていない場合は、何も返されません。CORS ポリシーにヘッダーを追加することは、返すことができるヘッダーを許可リストに登録することと同等です。 ## [](#cors-ポリシーの適用)CORS ポリシーの適用 CORS ポリシーを適用する手順は、次のとおりです。 1. API のバージョン番号をクリックします。 2. API ダッシュボードで、\[Policies (ポリシー)\] をクリックします。 適用されているポリシーのリストが表示されます。 3. \[Apply New Policy (新規ポリシーを適用)\]。 4. \[Select Policy (ポリシーの選択)\] で、\[Cross-Origin Resource Sharing (クロスオリジンリソース共有)\] を選択し、\[Configure Policy (ポリシーの設定)\] をクリックします。 5. これが公開リソースの場合は、\[Apply (適用)\] をクリックします。そうでない場合は、\[Public Resource (公開リソース)\] をオフにします。 \[Default (デフォルト)\] グループを指定するまで新しいグループを指定できません。デフォルトグループは、デフォルトの通常の意味の代替ではありません。この場合のデフォルトグループは、単に CORS 用に設定された最初のグループのことです。 6. ログイン情報を使用した要求を実行するには、​**\[Support credentials (ログイン情報をサポート)\]**​ をクリックします。詳細は、Mozilla の​_「Request with credentials (ログイン情報を使用した要求)」_​を参照し、グループを指定してください。 - \[Default (デフォルト)\] グループの \[Origins (送信元)\] で、1 つ以上のドメイン名 (​**mulesoft.com**​ など) を指定します。複数の名前はカンマで区切ります。 - 必要に応じて、\[Access Control Max Age (アクセスコントロール最大保持時間)\] を変更して、プリフライト要求をキャッシュできる時間を指定します。 - \[Methods (メソッド)\] で、ポリシーによって制御するメソッドを選択します。 - \[Headers (ヘッダー)\] で、必要に応じて、API が許可するクライアントリクエストヘッダーをリストします。 - \[Exposed Headers (公開ヘッダー)\] で、必要に応じて、クライアントがアクセスできるレスポンスヘッダーをリストします。 7. \[Apply (適用)\] をクリックします。 ## [](#cors-ポリシーの編集)CORS ポリシーの編集 CORS ポリシーの作成後、API ダッシュボードで \[Actions (アクション)\] > \[Edit (編集)\] をクリックして、ポリシーを編集します。 1. 必要に応じて値を変更します。 2. \[Apply (適用)\] をクリックします。 ## [](#cors-ポリシーのトラブルシューティング)CORS ポリシーのトラブルシューティング API の CORS を実装できない場合、到達不可能な API の別の解決策として、ブラウザーで同一オリジン制限を無効に方法が考えられます。 ## [](#ブラウザーでの同一オリジン制限を無効化)ブラウザーでの同一オリジン制限を無効化 これらの制限はブラウザーごとに固有の方法で処理されます。ヒント、コツ、プラグインはインターネットで入手できます。 ブラウザーのセキュリティ設定を変更した場合のセキュリティ上の潜在的な影響を理解していることを確認してください。ブラウザーが悪意のあるスクリプトやその他の潜在的な脅威に対して脆弱になる可能性があるため、これらのオプションは、各自の Web ページでテストする場合にのみを使用してください。 ### [](#google-chrome-mac-os-x)Google Chrome (Mac OS X) - 新しいターミナルウィンドウを開き、​`open -a Google\ Chrome --args --disable-web-security`​ の行を貼り付けて ​**Enter**​ キーを押します。 ### [](#google-chrome-windows)Google Chrome (Windows) - 新しいコマンドプロンプトウィンドウを開き、Chrome 実行可能ファイル (Chrome.exe) の場所に移動し、​`chrome.exe --disable-web-security`​ の行を貼り付けて ​**Enter**​ キーを押します。 ### [](#internet-explorer)Internet Explorer ドメイン間でデータソースにアクセスするオプションを有効にします。Internet Explorer の一部のバージョンでは、このオプションは \[インターネットのプロパティ\] > \[セキュリティ\] タブ > \[このゾーンのセキュリティのレベル\] の \[レベルのカスタマイズ\] > \[その他\] > \[ドメイン間でのデータ ソースのアクセス\] にあります。 ## [](#プロキシのバイパス)プロキシのバイパス ファイアウォールを使用してインバウンド要求をブロックする環境で Anypoint Platform ツールを使用する場合、このセクションで説明する方法でプロキシをバイパスします。 ### [](#api-console-と-api-designer-のためのプロキシのバイパス)API Console と API Designer のためのプロキシのバイパス 使用する API の API Designer に移動します。右側のペインで、API がファイアウォールの内側にあることを確認します。これによりプロキシをバイパスできます。 ![RAML コードとモッキングサービスインターフェースが表示されているコードエディター](/mulesoft/current/ja-jp/mule-gateway/_images/accessing-your-api-behind-a-firewall-e7a50.png) ### [](#api-notebook-のためのプロキシのバイパス)API Notebook のためのプロキシのバイパス 使用する API の API Notebook に移動します。クライアントを作成する初期コードセルで、次のコードの新しいコードセルを作成して、クライアントの新しいプロキシ設定を指定します。 **`API.set(client, 'proxy', false);`** 上の行で、​`client`​ は ​`API.createClient().`​ をコールしたときに使用したクライアントの名前を表します。たとえば次のようになります。 **`API.createClient(, …​);`** これらの 2 行を合わせた次の例では、新しいクライアントを作成し、デフォルトプロキシをバイパスします。 **`API.createClient('myClient', 'http://api-portal.anypoint.mulesoft.com/my-client/api/test-api/test.raml');`** **`API.set(myClient, 'proxy', false);`** ## [](#関連情報)関連情報 - [Mule 3 のポリシー](#api-manager::policies-mule3.adoc) - [提供ポリシー](#api-manager::policy-mule3-provided-policies.adoc) # Exchange へのカスタムポリシーのアップロード Exchange では、Maven クライアントを使用してアセットをパブリッシュまたはコンシュームする API が提供されます。アセットをパブリッシュするには、一意のアーティファクト名と組織 ID が必要です。API Manager は、組織のアセットとしてパブリッシュされたカスタムポリシーをリストします。 Exchange Maven Facade アセットについての詳細は、 [「Exchange Maven Facade」](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/exchange-maven-facade-api-http/)​を参照してください。 ## [](#前提条件)前提条件 Exchange にカスタムポリシーをアップロードするには、Exchange Contributor (Exchange コントリビューター) ロールが必要です。 ## [](#maven-アーキタイプを使用して作成されたポリシーをデプロイする)Maven アーキタイプを使用して作成されたポリシーをデプロイする 提供された Maven アーキタイプを使用してカスタムポリシープロジェクトを作成する場合、ポリシーを Exchange にアップロードするために必要なプラグインが事前定義されています。​[「アーキタイプを使用したプロジェクトのセットアップ」](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-getting-started#setting-up-a-project-with-the-archetype)​を参照してください。 Maven アーキタイプを使用して作成されたポリシーをデプロイする手順は、次のとおりです。 1. Maven ​`.m2`​ ディレクトリで、Exchange ログイン情報を使用して ​`settings.xml`​ ファイルを更新します。 ```xml exchange-server myusername mypassword ```
ログイン情報でなく、トークンを使用した認証方法についての詳細は、​「統合アセットをパブリッシュおよびコンシュームする」​を参照してください。
2. `mvn clean deploy`​ を実行してポリシーを Exchange にパブリッシュします。 これで、指定された組織に属する API にカスタムポリシーを適用できます。 ## [](#maven-アーキタイプを使用せずに作成されたポリシーをデプロイする)Maven アーキタイプを使用せずに作成されたポリシーをデプロイする 提供された Maven アーキタイプを使用してカスタムポリシープロジェクトを作成していない場合は、Exchange デプロイメント設定を手動で定義する必要があります。 Maven アーキタイプを使用せずに作成されたポリシーをデプロイする手順は、次のとおりです。 1. Anypoint Platform で、使用する組織 ID を次の方法で検索します。 1. **\[Access Management (アクセス管理)\] > \[Organization (組織)\]**​ に移動します。 2. 組織の名前をクリックします。 3. ブラウザーアドレスから UUID をコピーします。たとえば、URL から ​_2a4b93c3-7899-4ea7-9374-f787744d8784_​ をコピーします。 2. `pom.xml`​ ファイルを次のとおり更新します。 1. `groupId`​ 値を前のステップの組織 ID に置き換えます。 ```XML {orgId} ``` 2. 次のプロパティを追加して、​`{orgId}`​ を前のステップの組織 ID に置き換えます。 ```XML https://maven.anypoint.mulesoft.com/api/v1/organizations/{OrgId}/maven 3.2.0 ``` 3. Exchange をリポジトリとして定義します。 ```XML exchange-server MuleSoft Exchange Environment ${exchange.url} true ``` 4. Exchange サーバーを配布管理リポジトリとしてセットアップします。 ```XML exchange-server Corporate Repository ${exchange.url} default ``` 5. 次の構築プラグインを追加します。 - Mule Maven プラグイン: 必要なすべてのファイルが存在し、ポリシーを適切にパッケージ化するためのすべての要件を満たしていることを確認する。 - Maven デプロイプラグイン: Exchange リポジトリと通信し、ポリシーの JAR および YAML ファイルをアップロードする。 ```XML org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} true org.apache.maven.plugins maven-deploy-plugin upload-template deploy deploy-file exchange-server ${exchange.url} ${project.basedir}/${project.artifactId}.yaml false ${project.groupId} ${project.artifactId} ${project.version} yaml policy-definition ``` 6. 次のプラグインリポジトリを追加します。 ```XML mule-plugin Mule Repository https://repository.mulesoft.org/nexus/content/repositories/public/ ``` 3. Maven ​`.m2`​ ディレクトリで、Exchange ログイン情報を使用して settings.xml ファイルを更新します。 ```XML exchange-server myusername mypassword ```
ログイン情報でなく、トークンを使用した認証方法についての詳細は、​「統合アセットをパブリッシュおよびコンシュームする」​を参照してください。
4. `mvn clean deploy`​ コマンドを使用してポリシーをデプロイします。

Exchange リポジトリに定義される ID は一致する必要があります。
これで、指定された組織に属する API にカスタムポリシーを適用できます。 ## [](#関連情報)関連情報 - [カスタムポリシーのパッケージ化](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-package) - [カスタムポリシーの概念の確認](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-mule-4-reference) # HTTP キャッシュポリシー

ポリシー名

HTTP キャッシュ

概要

API 実装から HTTP 応答をキャッシュする

カテゴリ

サービス品質

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

v4.1.0

返される状況コード

このポリシーの戻りコードは存在しません
## [](#概要)概要 HTTP キャッシュポリシーでは、HTTP 応答をキャッシュして再利用できます。これらの応答をキャッシュすると、ユーザー要求の応答時間が短縮され、バックエンドの負荷が軽減されます。たとえば、要求に対する応答が変更される可能性の低いエンドポイントをバックエンドで公開する場合、HTTP キャッシュポリシーを使用して、HTTP 応答を再利用し、バックエンド要求処理をバイパスできます。

ポリシー順序で HTTP キャッシュポリシーの後に適用されるポリシーはキャッシュによって提供される応答には適用されません。たとえば、HTTP キャッシュポリシーの後に適用されるレート制限ポリシーでは、アップストリームサービスによって提供される応答のみを制限し、キャッシュによって提供される応答は制限しません。HTTP キャッシュポリシーより前にキャッシュされた応答に必要なすべてのポリシーを適用してください。
## [](#cpp)ポリシーのパラメーターの設定 ### [](#mule-ゲートウェイ)Mule ゲートウェイ UI から HTTP キャッシュポリシーを API に適用する場合は、次のパラメーターを設定できます。
パラメーター 説明 必須?

HTTP Caching Key (HTTP キャッシュキー)

DataWeave 式。 デフォルト値: #[attributes.requestPath]

はい

Maximum Cache Entries (最大キャッシュエントリ)

キャッシュ内に特定の期間保存できるエントリの最大数を指定します。 デフォルト値: 10000

はい

Entry Time To Live (エントリ存続期間)

キャッシュの 1 つのエントリの有効期限が切れるまでの時間 (秒) を指定します。 デフォルト値: 600

はい

Distributed (分散)

クラスター内の各ノードでキャッシュが分散されるように設定します。 CloudHub を使用している場合、アプリケーションをデプロイするときに Object Store v2 を有効にします。 デフォルト値: false

はい

Persistent Cache (永続キャッシュ)

Mule/Flex インスタンスの各再起動間でキャッシュが維持されるように設定します。 CloudHub を使用している場合、アプリケーションをデプロイするときに Object Store v2 を有効にします。 デフォルト値: false

はい

Follow HTTP Caching directives (HTTP キャッシュディレクティブに従う)

Cache-Control ヘッダーディレクティブの使用を有効にします。 デフォルト値: true

はい

Invalidation Header (無効化ヘッダー)

1 つのエントリまたはキャッシュ全体を無効化するために使用されるヘッダーの名前。

いいえ

Conditional Request Caching Expression (条件付き要求キャッシュ式)

キャッシュされる要求を決定するために使用される DataWeave 式 (応答は条件が true の場合にのみキャッシュされる)。 デフォルト値: #[attributes.method == 'GET' or attributes.method == 'HEAD']

いいえ

Conditional Response Caching Expression (条件付き応答キャッシュ式)

キャッシュされる応答を決定するために使用される DataWeave 式 (応答は条件が true の場合のみキャッシュされる)。 デフォルト値: #[[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501] contains attributes.statusCode]

いいえ
## [](#ポリシーのしくみ)ポリシーのしくみ HTTP 要求がエンドポイントに到達した後の次の処理は、要求がまだキャッシュにないのか (キャッシュミス)、すでにあるのか (キャッシュヒット) によって決まります。 ### [](#キャッシュミス)キャッシュミス キャッシュミスの場合、HTTP キャッシュポリシーは、送信された要求に対する応答がすでにキャッシュされているかどうかをチェックします。要求がバックエンドに到達したら、キャッシュミスの場合にのみプロセスが開始されます。次の図は、このシナリオで発生するイベントのフローを示しています。 ![Web ブラウザーとバックエンドシステム間のデータフローを示すフローチャート](/mulesoft/current/ja-jp/mule-gateway/_images/http-policy-cache-miss.png) 1. クライアント (ユーザー) が API に要求を送信します。 2. 要求は、HTTP キャッシュポリシーに到達するまでポリシーチェーンの他のポリシーを進みます。 3. HTTP キャッシュポリシーは、要求がすでにオブジェクトストアにあるかどうかをチェックします。ない場合は、キャッシュミスプロセスが開始されます。 4. 要求は、他の残りのポリシーのチェーンを引き続き進みます。 5. 要求がバックエンドに到達し、必要なすべての処理を実行します。 6. バックエンドが応答し、応答はポリシーチェーンを戻ります。 7. 応答が HTTP キャッシュポリシーに到達します。 8. キャッシュで再度オブジェクトストアがヒットし、後で再利用できるように要求の​[キー](#key)​を保存しようとします。 9. 応答は、ポリシーチェーンの残りのポリシーを引き続き進みます。 10. 応答がクライアントに返されます。 ### [](#キャッシュヒット)キャッシュヒット キャッシュヒットの場合、HTTP キャッシュポリシーは、オブジェクトストアのキーを検索し、要求に対する応答が​[保存済みエントリ](#stored_entry)​としてすでにキャッシュされていることを検出します。要求がバックエンドに向けてポリシーチェーンを進むことはなく、キャッシュされた応答が再利用されます。 キャッシュヒットの場合、キャッシュ後にポリシーチェーンで実行される必要のあるすべてのポリシーはそれ以降実行されません。 ![API ゲートウェイを介した Web ブラウザーからバックエンドおよびオブジェクトストアへのデータフローを示すフローチャート](/mulesoft/current/ja-jp/mule-gateway/_images/http-policy-cache-hit.png) 1. クライアント (ユーザー) が API に要求を送信します。 2. 要求は、HTTP キャッシュポリシーに到達するまで他のポリシーを通過します。 3. HTTP キャッシュポリシーは、要求がすでにキャッシュにあるかどうかを確認します。 4. オブジェクトストアで​[キー](#key)​が見つかり、保存された応答が返されます。 5. 応答は、最後のポリシーに到達するまでポリシーチェーンの残りのポリシーを引き続き進みます。 6. キャッシュされた応答がクライアントに返されます。 ### [](#stored_entry)保存済みエントリ _保存済みエントリ_​は、キャッシュされた HTTP 応答です。キャッシュには、最大 1 MB のシリアル化可能データと入力ストリームを保存できます。値がこの制限を超えると、読み取りは停止し、値は保存されません。 ### [](#key)HTTP Caching Key (HTTP キャッシュキー) キャッシュは辞書として機能し、そこではキャッシュに保存された各応答が​_キー_​と呼ばれる文字列に関連付けられます。たとえば、式 #\[attributes.headers\['key'\]\] では、​`key`​ というヘッダーがエントリキーとして使用されます。 ### [](#キャッシュサイズとエントリ有効期限)キャッシュサイズとエントリ有効期限 キャッシュには、指定された数のエントリを特定の期間保持できます。この数は、​`Maximum Cache Entries`​ プロパティを使用して設定できます。各保存済みエントリは、一定時間キャッシュメモリに保持されます。その後、エントリは期限切れになり、再度処理する必要があります。この有効期限は、​_存続期間_​ (TTL) と呼ばれます。 キャッシュが最大項目保存数に達したときもエントリの有効期限がトリガーされます。このシナリオが発生すると、FIFO (先入れ先出し) 条件を使用してエントリが削除されます。つまり、最も早くキャッシュに到達したエントリは、TTL 値にまだ達していなくても削除されます。 ### [](#分散キャッシュ)分散キャッシュ キャッシュの各エントリは、​`Distributed`​ オプション (表を参照) を使用して、クラスター内の各ノードや Runtime Manager の複数のワーカーで共有できます。このオプションが有効になっていない場合、各ノードには独自のキャッシュメモリが割り当てられます。 ### [](#永続キャッシュ)永続キャッシュ 永続キャッシュでは、Mule Runtime Engine (Mule) または Flex レプリカが再起動しても、キャッシュの保存済みエントリを保持できます。 永続的なストアを使用するように設定された HTTP キャッシュポリシーを持つインスタンスのバージョンをアップグレードすると、ポリシーは以前のバージョンで保存されたエントリを維持しようとします。ただし、最悪のシナリオでは、キャッシュ内のエントリが無効になり、新しい要求の到着時にキャッシュが再入力されます。キャッシュ内のエントリのこの操作は自動的に実行され、ユーザーが意識することはありません。 ## [](#http-キャッシュディレクティブ)HTTP キャッシュディレクティブ HTTP キャッシュポリシーは、キャッシュをより詳細に制御するために次のヘッダーを考慮に入れて [RFC-7234](https://tools.ietf.org/html/rfc7234)​ プロトコルのいくつかの HTTP ディレクティブを解釈します。 - `Cache-Control` - `Expires` - `Date` - `Age` ### [](#cache-control)Cache-Control `Cache-Control`​ ヘッダーは要求または応答に存在します。ヘッダーの使用可能な値は次のとおりです。これらの値は、カンマで区切って組み合わせることができます。 - 要求: - `no-cache` 応答は検索されませんが、キャッシュに直接保存されます。 - `no-store` 応答はキャッシュに保存されません。ただし、応答がキャッシュ内にすでに存在する場合は、ポリシーがその応答を返します。 - 応答: - `no-store`​、​`no-cache`​、​`private` どの値でも応答はキャッシュに保存されません。 - `max-age=`, ​`s-maxage=` ``​ プレースホルダーは、応答がキャッシュに残ることができる時間 (秒) を示す有効な整数に置き換える必要があります。両方のパラメーターが定義されている場合、​`max-age`​ よりも ​`s-maxage`​ が優先されます。 ポリシーでグローバル存続期間 (TTL) 値も定義されている場合、ヘッダーで指定されている時間がグローバル TTL よりも少ないと、これらのヘッダー値がポリシーで設定されているグローバル TTL よりも優先されます。 ### [](#expires-有効期限)Expires (有効期限) 存在する場合、このヘッダーでキャッシュ内のエントリの有効期限を指定します。​`max-age`​ ディレクティブまたは ​`s-maxage`​ ディレクティブが指定されている場合、このヘッダーは無視されます。ヘッダー値は [RFC-1123](https://tools.ietf.org/html/rfc1123)​ のとおりに定義する必要があります。 ### [](#date-日付)Date (日付) `date`​ ヘッダーが [RFC-1123](https://tools.ietf.org/html/rfc1123)​ に従って定義されている場合、応答の作成日時が指定されます。定義されていない場合、​`date`​ ヘッダーが要求の受信時刻で追加されます。このヘッダーは、Cache-Control ヘッダーの ​`max-age`​ および ​`s-maxage`​ ディレクティブに定義された値と一緒に使用されます。 ### [](#age-存続期間)Age (存続期間) `age`​ ヘッダーは、date ヘッダーに指定されたキャッシュされている応答の作成以降の経過時間 (秒) を示します。このヘッダーはポリシーによって計算され、キャッシュから取得された各応答に追加されます。 有効期限は、​`cache-control`​、​`date`​、​`expires`​ ヘッダーを使用して計算されます。ただし、計算された有効期限がエントリの TTL 値で指定された存続時間を超える場合、キャッシュエントリの有効期限が切れます。 ### [](#無効化)無効化 HTTP キャッシュポリシーで ​`invalidate`​ ヘッダーが設定されている場合、キャッシュ内のエントリが無効化され、要求が再度処理されます。\[Invalidation Header (無効化ヘッダー)\] 設定のヘッダーの名前を指定して、オプションを有効にします。ヘッダーの値には、​`invalidate`​ オプションのみを設定できます。 このオプションは、キーが現在の要求に一致するエントリを無効化します。 `invalidate-all`​ このオプションは、キャッシュからすべてのエントリを無効化します。 たとえば、ポリシーで要求の次の値が設定されているとします。 - `HTTP Caching Key`​ (HTTP キャッシュキー): "#\[attributes.requestPath\]" - `Invalidation header`​ (無効化ヘッダー): "myInvalidationHeader" 次のコマンドは、キャッシュからキーが "/my/policy" のエントリを無効化します。 `curl http:///my/policy -H “myInvalidationHeader:invalidate”` 次の要求は、キャッシュからすべてのエントリを無効化します。 `curl http:///my/policy -H “myInvalidationHeader:invalidate-all”` ## [](#条件付きキャッシュ)条件付きキャッシュ 条件付きキャッシュでは、エントリをキャッシュに保存するために満たす必要がある一連の条件を設定できます。条件付きキャッシュパラメーターが設定されていない場合、すべての受信要求の応答がキャッシュに保存されます。設定されている場合、各要求のパラメーターが評価されて、現在の要求の応答を保存する必要があるかどうかが判断されます。 条件付き要求式の場合、デフォルトでは、HTTP メソッドの ​`GET`​ または ​`HEAD`​ による受信要求に対する応答のみがキャッシュされます。条件付き応答式の場合、デフォルトでは、 [RFC-7231](https://tools.ietf.org/html/rfc7231#section-6.1)​ で指定された状況コードのみがキャッシュされます。 デフォルト値についての詳細は、​[「ポリシーのパラメーターの設定」](#cpp)​を参照してください。 ## [](#faq)FAQ **キーの評価がエラーになった場合はどうなりますか?** 特定の要求の式の評価がエラーになった場合、ポリシーは有効にならず、要求はポリシーチェーンの次の受け入れ先に引き続き進みます。 **このポリシーで応答の一部のみを保存できますか?** いいえ。ただし、このポリシーの前に別のポリシーを適用して、応答を変更することはできます。 **あるパラメーターではキャッシュ内で応答を検索するように設定し、別のパラメーターではその逆のアクションを実行するように設定した場合、どうなりますか?** これは、Cache-Control ヘッダーに no-store ディレクティブがある状態で応答をキャッシュに保存するように設定したときと同じになります。 この場合、応答は保存されません。キャッシュに応答を保存したり、キャッシュの応答を検索したりできるようにするには、Cache-Contro ヘッダーとキャッシュの両方を設定する必要があります。 **HTTP キャッシュポリシーを CloudHub で実行する場合と Mule Runtime Engine で実行する場合でどのような違いがありますか?** - \[Distributed (分散)\] オプションが選択されている場合、キャッシュは常に保持されます。 - Runtime Manager では最大キャッシュ設定は無視されます。 - Object Store v2 の使用時にはポリシーの TTL の編集内容が正しく反映されません。この値を変更するには、HTTP キャッシュポリシーを削除して新しいポリシーを適用します。 **省略可能なパラメーターを定義しないとどうなりますか?** `invalidation`​ ヘッダーを設定していない場合、要求のキャッシュを無効化できません。 また、要求式や応答式を設定していない場合、キャッシュはすべての要求に対して使用され、すべての応答がキャッシュに保存されます (式 #\[true\])。 **\[Invalidation header (無効化ヘッダー)\] の値を変更できますか?** いいえ。変更できるのはヘッダー名のみです。 **アプリケーションをオンプレミスサーバーにデプロイした場合は、Object Store v2 が使用されますか?** いいえ。Object Store v2 はオンプレミスサーバーでは使用できません。Mule オブジェクトストアを使用する必要があります。詳細は、​[「Object Store v2 に関する FAQ」](https://docs.mulesoft.com/jp/object-store/osv2-faq#can-i-use-object-store-v2-for-apps-deployed-to-on-premises-servers)​を参照してください。 # HTTP ポリシートランスフォーム拡張機能 Mule バージョン 4.1.0 以降では、HTTP ポリシートランスフォーム拡張機能をポリシーで使用できます。この拡張機能により、さまざまなポリシーを通過する HTTP 要求および応答の変更が簡略化されます。このドキュメントは、HTTP ポリシートランスフォーム拡張機能 3.0.0 以降に適用されます。 ## [](#maven-連動関係としての拡張機能のポリシーへの追加)Maven 連動関係としての拡張機能のポリシーへの追加 ポリシーで HTTP ポリシートランスフォーム拡張機能を使用するには、最初に Maven 連動関係をポリシーの POM ファイルに追加する必要があります。ポリシーの POM ファイルの dependency セクションに次のコードを追加します。 ```xml com.mulesoft.anypoint mule-http-policy-transform-extension ${httpPolicyTransformVersion} mule-plugin org.mule.connectors mule-http-connector ``` **NOTE:**​ HTTP ポリシートランスフォーム拡張機能を使用するポリシーがパッケージ化されている場合、​[Mule HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/)​ が不必要にポリシー JAR ファイルに追加されます。コネクタは、ポリシーが適用されるアプリケーションにすでに存在します。そのため、上記のスニペットには exclusion が追加されています。 また、ポリシーの POM ファイルで ​`mule-maven-plugin`​ パラメーターバージョンを ​`3.3.2`​ 以降に設定してください。 ## [](#namespace-名前空間)Namespace (名前空間) ```xml ``` ## [](#操作)操作 - Add Headers 操作 - Add Request Headers - Add Request Headers List (mule-http-policy-transform-extension 3.1.0 以降) - Add Response Headers - Add Response Headers List (mule-http-policy-transform-extension 3.1.0 以降) - Remove Headers - Set Response - Set Request ### [](#add-headers-操作)Add Headers 操作 #### [](#add-request-headers)Add Request Headers この操作は、要求にヘッダーを挿入するために使用されます。この操作を使用するには、次の場所からコールを開始する必要があります。 - ソースポリシー (​`execute-next`​ が呼び出される前)。 - 操作ポリシー (​`execute-next`​ が呼び出される前)。 ##### [](#パラメーター)パラメーター - `headers` 現在のメッセージ属性に追加されるヘッダーのマップに解決される DataWeave 式。 **例** ```xml #[ { 'FirstHeader': 'FirstHeaderValue', 'SecondHeader': 'SecondHeaderValue', 'ThirdHeader': 'ThirdHeaderValue' } ] ``` #### [](#add-request-headers-list)Add Request Headers List
この操作は mule-http-policy-transform-extension 3.1.0 で追加されました。
この操作は、要求にヘッダーを挿入するために使用されます。この操作を使用するには、次の場所からコールを開始する必要があります。 - ソースポリシー (​`execute-next`​ が呼び出される前)。 - 操作ポリシー (​`execute-next`​ が呼び出される前)。 ##### [](#パラメーター-2)パラメーター - `http-transform:new-headers` 各ヘッダーに ​`http-transform:header`​ を追加する必要があります。 各 http-transform:header には、リテラル式または DataWeave 式で定義された ​`headerName`​ および ​`headerValue`​ 属性が必要です。 **例** ```xml ``` ポリシー設定に複数の値を持つ ​`keyvalues`​ 型のプロパティがある場合、この操作では DataWeave 式が許可されます。 **例** ```xml ... configuration: - propertyName: requestHeaders name: Reques Headers description: Header Names and values type: keyvalues optional: true allowMultiple: true ... ``` 上記の設定では、ハンドルバーを使用して、ポリシーに追加されるヘッダーを展開できます。 ```xml ... {{#each requestHeaders}} {{/each}} ... ``` #### [](#add-response-headers)Add Response Headers この操作は、応答にヘッダーを挿入するために使用されます。この操作を使用するには、次の場所からコールを開始する必要があります。 - ソースポリシー (​`execute-next`​ が呼び出された後)。 - 操作ポリシー (​`execute-next`​ が呼び出された後)。 ##### [](#パラメーター-3)パラメーター - `headers` 現在のメッセージ属性に追加されるヘッダーのマップに解決される DataWeave 式。 **例** ```xml #[ { 'FirstHeader': 'FirstHeaderValue', 'SecondHeader': 'SecondHeaderValue', 'ThirdHeader': 'ThirdHeaderValue' } ] ``` #### [](#add-response-headers-list)Add Response Headers List
この操作は mule-http-policy-transform-extension 3.1.0 で追加されました。
この操作は、応答にヘッダーを挿入するために使用されます。この操作を使用するには、次の場所からコールを開始する必要があります。 - ソースポリシー (​`execute-next`​ が呼び出された後)。 - 操作ポリシー (​`execute-next`​ が呼び出された後)。 ##### [](#パラメーター-4)パラメーター - `http-transform:new-headers` 各ヘッダーに ​`http-transform:header`​ を追加する必要があります。 各 http-transform:header には、リテラル式または DataWeave 式で定義された ​`headerName`​ および ​`headerValue`​ 属性が必要です。 **例** ```xml ``` ポリシー設定に複数の値を持つ ​`keyvalues`​ 型のプロパティがある場合、この操作では DataWeave 式が許可されます。 **例** ```xml ... configuration: - propertyName: responseHeaders name: Reques Headers description: Header Names and values type: keyvalues optional: true allowMultiple: true ... ``` 上記の設定では、ハンドルバーを使用して、ポリシーに追加されるヘッダーを展開できます。 ```xml ... {{#each responseHeaders}} {{/each}} ... ``` ### [](#remove-headers)Remove Headers この操作は、HTTP リスナーおよびリクエスターの要求と応答の両方からヘッダーを削除します。返される属性は、入力属性と同じ種別です。この操作では大文字と小文字が区別されます。 #### [](#パラメーター-5)パラメーター - `header-names` 削除するヘッダー名の配列に解決される DataWeave 式。 **例** ```xml #[['FirstHeader', 'SecondHeader']] ``` ### [](#set-response)Set Response この操作は、完全な HTTP 応答を設定します。この操作は、 ポリシーによってフローが実行されないようにする場合、つまり、HTTP 応答が設定されていない場合に使用されます。 #### [](#パラメーター-6)パラメーター - `statusCode`​ (状況コード) — 応答の HTTP 状況コードを表す整数。 - `reasonPhrase`​ (理由を示す語句) — 応答の HTTP の理由を示す語句を表す文字列。 - `body`​ (本文) — HTTP 応答のコンテンツ。 - headers (ヘッダー) — HTTP レスポンスヘッダーのマップに解決される DataWeave 式。 **例** ```xml #['policyPayload'] #[ { 'FirstHeader': 'FirstHeaderValue', 'SecondHeader': 'SecondHeaderValue', 'ThirdHeader': 'ThirdHeaderValue' } ] ``` ### [](#set-request)Set Request この操作は、HTTP リクエスターが実行する完全な HTTP 要求を設定します。 #### [](#パラメーター-7)パラメーター - `requestPath`​ (要求パス): HTTP 要求が送信されるパス。 - `body`​ (本文): HTTP 要求のコンテンツ。 - `headers`​ (ヘッダー): HTTP リクエストヘッダーのマップに解決される DataWeave 式。 - `uriParams`​ (URI パラメーター): HTTP 要求の URI パラメーターのマップに解決される DataWeave 式。 - `queryParams`​ (クエリパラメーター): HTTP 要求のクエリパラメーターのマップに解決される DataWeave 式。 **例** ```xml #['policyPayload'] #[ { 'FirstHeader': 'FirstHeaderValue', 'SecondHeader': 'SecondHeaderValue', 'ThirdHeader': 'ThirdHeaderValue' } ] #[ { 'FirstUriParam': 'FirstUriParamValue', 'SecondUriParam': 'SecondUriParamValue' } ] #[ { 'FirstQueryParam': 'FirstQueryParamValue', 'SecondQueryParam': 'SecondQueryParamValue' } ] ``` # HTTP 基本認証ポリシー このページでは、HTTP 基本認証ポリシーの設定とランタイムアプリケーションの手順について説明します。このポリシーは、要求のログイン情報を検証し、設定に従ってアクセス権を適用します。 このポリシーが機能するには、セキュリティマネージャーポリシーが必要です。単純セキュリティマネージャーポリシーをテスト用に使用するか、LDAP セキュリティマネージャーを設定することができます。HTTP 基本認証ポリシーが認証できるセキュリティマネージャーの設定方法については、LDAP セキュリティマネージャーポリシーのドキュメントを参照してください。 設定は必要ありません。 ## [](#ユーザーログイン情報の取得)ユーザーログイン情報の取得 API を使用しているユーザーに関する情報にアクセスするには、プロキシのインバウンドエンドポイントとアウトバウンドエンドポイントの間の任意の場所に次のスクリプトを配置します。スクリプトは、HTTP 基本認証ポリシーの後に実行されます。 ```xml message.outboundProperties.put('X-Authenticated-userid', _muleEvent.session.securityContext.authentication.principal.username) ``` このスクリプトでは、ユーザー名が Mule メッセージ内の ​`X-Authenticated-userid`​ というアウトバウンドプロパティに保存されます。プロキシの出力を生成する HTTP Connector は、コネクタに到達したすべてのアウトバウンドプロパティを HTTP メッセージヘッダーに変換します。プロキシを通過した後に API に到達したメッセージには、​`X-Authenticated-userid`​ という HTTP ヘッダーが含まれ、そこにユーザー名が含まれています。 このコードを修正して、作成されるヘッダーの名前を変更することもできます。 ## [](#関連情報)関連情報 - [LDAP セキュリティマネージャー](#api-manager::policy-mule3-ldap-security-manager.adoc) # IP ブロックリストポリシー

ポリシー名

IP ブロックリスト

概要

単一の IP アドレスまたは IP アドレスの範囲からの API エンドポイントへのアクセスをブロックする

カテゴリ

セキュリティ

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

v4.1.0

返される状況コード

403 - IP は拒否されました
## [](#概要)概要 IP ブロックリストポリシーは、単一の IP アドレスまたは IP アドレスの範囲からの設定済み API エンドポイントへのアクセスを制御します。 IP ブロックリストポリシーは、ソース IP (ポリシーの設定時に指定します) が個別 IP のリストまたは IP 範囲と一致した場合に、保護対象のリソースへのアクセスを禁止します。 ビジネスのニーズに応じて、Mule 4 では DataWeave 2.0 式、Mule 3 では MEL 式を指定できます。IP がポリシーで定義されている制約 IP リストに含まれているかどうかを確認するときに使用するソース IP を式で定義します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#mule-ゲートウェイ)Mule ゲートウェイ UI から IP ブロックリスト登録済みリストポリシーを API に適用する場合は、以下のパラメーターを設定します。
パラメーター 説明

IP 式

この API 要求から IP アドレスを抽出するために使用する DataWeave 2.0 または MEL 式。

ブロックリスト

API からブロックする IP アドレスのリスト。IP または IP 範囲は一度に 1 つずつ、必要なだけ何度も定義できます。詳細は、​「ポリシーでブロックリスト登録する IP アドレスの指定」​を参照してください。

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション。
## [](#specifying_ip_address)ポリシーでブロックリスト登録する IP アドレスの指定 次の情報に基づいてポリシーでブロックする IP アドレスを指定します。 - 要求の IP アドレス。 - 特定の DataWeave 式または MEL 式を解決することで決定される発生元 IP アドレス ( [x-Forwarded-For](https://en.wikipedia.org/wiki/X-Forwarded-For)​ ヘッダーなど)。 - その他のすべての発生元。 ### [](#要求の-ip-アドレスに基づいてアクセスをブロックリスト登録する)要求の IP アドレスに基づいてアクセスをブロックリスト登録する 次のいずれかの方法で、要求の IP アドレスに基づいてブロックリストにアクセスします。 - 特定の IP アドレスを定義するには、そのアドレスのみを指定します (例: `192.168.1.1`​)。 - アドレスのサブセットを定義するには、サブセットマスクを指定します。たとえば、​`192.168.3.1/30`​ など (これには、統合範囲 ​`192.168.3.0`​ ～ ​`192.168.3.3`​ が含まれます)。 - IP アドレスの範囲全体を定義するには、許可する IP アドレスの関連オクテットを指定します。たとえば、「​`192.168`​>」と設定すると、​`192.168.0.0`​ ～ ​`192.168.255.255`​ の IP アドレスが含まれます。 ### [](#x-forwarded-for-ヘッダーの発生元-ip-アドレスに基づいてアクセスをブロックリスト登録する)x-Forwarded-For ヘッダーの発生元 IP アドレスに基づいてアクセスをブロックリスト登録する クライアントが HTTP プロキシまたはロードバランサーを介して API に接続している場合、要求に含まれるアドレスではなく、クライアントの特定の IP アドレス (要求の発生元 IP アドレス) をブロックリスト登録できます。 たとえば、​`192.168.2.3`​ をブロックリスト登録して、HTTP プロキシを介して接続しているクライアントのアドレスが ​`92.40.1.255`​ である場合、クライアントの要求は、プロキシを使用した公開アドレスで表示されます。 通常、アプリケーションは ​`X-Forwarded-For`​ ヘッダーを使用して、エンドポイントにリダイレクトされた要求の発生元 IP アドレスを識別します。 ポリシーで DataWeave 2.0 または MEL 式を使用して (Mule 3 のみ)、サービスに ​`x-Forwarded-For`​ ヘッダー内の IP アドレスを探すように指示できます。 ポリシーパラメーターの \[IP expression (IP 式)\] 項目で IP アドレスを指定すると、Anypoint Platform は要求の ​`x-Forwarded-For`​ ヘッダーの連結値に含まれる最初の IP アドレスを参照するように指示されます。 # IP 許可リストポリシー

ポリシー名

IP 許可リスト

概要

IP アドレスのリストまたは範囲からのアクセス要求を許可する

カテゴリ

セキュリティ

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

v4.1.0

返される状況コード

403 - IP は拒否されました
## [](#概要)概要 IP 許可リストポリシーは、ソース IP (ポリシーの設定時に指定します) が個別 IP のリストまたは IP 範囲と一致した場合に、指定された IP アドレスのリストまたは範囲に保護対象のリソースへのアクセスを許可します。 ビジネスのニーズに応じて、Mule 4 では DataWeave 2.0 式、Mule 3 では MEL 式を指定します。これらの式により、IP がポリシーの制約 IP リストに含まれているかどうかを確認するためにポリシーで使用されるソース IP を定義します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#mule-ゲートウェイ)Mule ゲートウェイ UI から IP 許可リストポリシーを API に適用する場合は、以下のパラメーターを設定します。
パラメーター 説明

IP 式

この API 要求から IP アドレスを抽出するために使用する DataWeave 2.0 または MEL 式。

許可リスト

API へのアクセスを許可する IP アドレスのリスト。IP または IP 範囲は一度に 1 つずつ、必要なだけ何度も定義できます。 詳細は、​「ポリシーで許可リスト登録する IP アドレスの指定」​を参照してください。

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション。
## [](#specifying_ip_address)ポリシーで許可リスト登録する IP アドレスの指定 次の情報に基づいてポリシーへのアクセスを許可する IP アドレスを指定します。 - 要求の IP アドレス。 - 特定の DataWeave 式または MEL 式を解決することで決定される発生元 IP アドレス ( [x-Forwarded-For](https://en.wikipedia.org/wiki/X-Forwarded-For)​ ヘッダーなど)。 - その他のすべての発生元。 ### [](#要求の-ip-アドレスに基づいてアクセスを許可リストに登録する)要求の IP アドレスに基づいてアクセスを許可リストに登録する 次のいずれかの方法で、要求の IP アドレスに基づいて許可リストにアクセスします。 - 特定の IP アドレスを定義するには、そのアドレスのみを \[Allowlist (許可リスト)\] 項目に指定します (例: `192.168.1.1`​)。 - アドレスのサブセットを定義するには、サブセットマスクを指定します。たとえば、​`192.168.3.1/30`​ など (これには、統合範囲 ​`192.168.3.01`​ ～ ​`192.168.3.3`​ が含まれます)。 - IP アドレスの範囲全体を定義するには、許可する IP アドレスの関連オクテットを指定します。たとえば、「​`192.168`​>」と設定すると、​`192.168.0.0`​ ～ ​`192.168.255.255`​ の IP アドレスが含まれます。 ### [](#x-forwarded-for-ヘッダーの発生元-ip-アドレスに基づいてアクセスを許可リスト登録する)x-Forwarded-For ヘッダーの発生元 IP アドレスに基づいてアクセスを許可リスト登録する クライアントが HTTP プロキシまたはロードバランサーを介して API に接続している場合、要求に含まれるアドレスではなく、クライアントの特定の IP アドレス (要求の発生元 IP アドレス) を許可リスト登録できます。 たとえば、​`192.168.2.3`​ (非公開 IP) を許可リスト登録して、HTTP プロキシを介して接続しているクライアントのアドレスが ​`92.40.1.255`​ (公開 IP) である場合、クライアントの要求は、プロキシを使用した公開アドレスで表示されます。 通常、アプリケーションは ​`X-Forwarded-For`​ ヘッダーを使用して、エンドポイントにリダイレクトされた要求の発生元 IP アドレスを識別します。 ポリシーで DataWeave 2.0 または MEL 式を使用して (Mule 3 のみ)、サービスに ​`x-Forwarded-For`​ ヘッダー内の IP アドレスを探すように指示できます。 ポリシーパラメーターの \[IP expression (IP 式)\] 項目で IP アドレスを指定すると、Anypoint Platform は要求の ​`x-Forwarded-For`​ ヘッダーの連結値に含まれる最初の IP アドレスを参照するように指示されます。 # JSON 脅威保護 本質的に、JSON は JavaScript インジェクションに対して脆弱です。JSON オブジェクトを解析すると、悪意あるコードによる損害を受けます。JSON ペイロードのサイズや深さが過度に増えた場合は、インジェクションの可能性があります。JSON 脅威保護ポリシーを適用すると、JSON ペイロードのサイズが制限され、JSON 階層の再帰的追加が阻止されます。 ## [](#json-アプリケーションの保護)JSON アプリケーションの保護 本質的に、JSON は JavaScript インジェクションに対して脆弱です。JSON オブジェクトを解析すると、悪意あるコードによる損害を受けます。JSON ペイロードのサイズや深さが過度に増えた場合は、インジェクションの可能性があります。JSON 脅威保護ポリシーを適用すると、JSON ペイロードのサイズが制限され、JSON 階層の再帰的追加が阻止されます。 JSON アプリケーションを保護する手順を使用して、JSON 脅威保護を設定します。 1. API のバージョン番号をクリックします。 2. API ダッシュボードで、\[Policies (ポリシー)\] をクリックします。 適用されているポリシーのリストが表示されます。 3. \[Apply New Policy (新規ポリシーを適用)\]。 4. \[Select Policy (ポリシーの選択)\] で、\[JSON Threat Protection (JSON 脅威保護)\] を選択し、\[Configure Policy (ポリシーの設定)\] をクリックします。 5. 制限を指定し、\[Apply (適用)\] をクリックして JSON コードの保護を開始します。次の例は、JSON 脅威保護ポリシーの設定を示しています。 ![JSON 脅威保護ポリシーを設定できるフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/json-threat-policy.png) ノードの深さなどに -1 の値を設定すると、無制限の深さを指定することになります。 ## [](#json-脅威保護ポリシーへの応答)JSON 脅威保護ポリシーへの応答 - 200 メッセージが正常に送信されました。 - 400 Bad Request (400 不正な要求) 要求が、設定された制限に違反している場合は、「Bad Request (不正な要求)」エラーが発生します。 # JSON 脅威保護ポリシー

ポリシー名

JSON 脅威保護

概要

API 要求内の悪意のある JSON から保護する

カテゴリ

セキュリティ

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

v3.8.0

返される状況コード

400 - Bad Request
## [](#概要)概要
JSON 脅威ポリシーでは、SOAP API はサポートされません。
JSON 要求を処理するアプリケーションは、要素とネストレベルの異常な膨張により特徴付けられる攻撃を受けやすくなっています。攻撃者は再帰的な技法を使用してメモリリソースをコンシュームします。多くの場合、アプリケーションデータのサイズが劇的に変動することは、セキュリティの問題が発生していることを示します。JSON 脅威保護ポリシーは、このような侵入からアプリケーションを保護するのに役立ちます。 Anypoint Platform 環境への攻撃の検出が困難である場合は、JSON 脅威保護に保護レイヤーを追加したサービスアーキテクチャを設計する必要があります。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#mule-ゲートウェイ)Mule ゲートウェイ UI から JSON 脅威保護ポリシーを API に適用するときに、以下のパラメーターが表示されます。

項目

説明

デフォルト

必須

Maximum Container Depth (最大コンテナ深度)

最大ネスト深度を指定します。JSON では、コンテナ (オブジェクトおよび配列) を任意の順序で任意の深度までネストできます。

-1

false

Maximum String Value Length (最大文字列値長)

文字列値の最大長を指定します。

-1

false

Maximum Object Entry Name Length (オブジェクトエントリ名の最大長)

オブジェクトのエントリ名の最大文字列長を指定します

-1

false

Maximum Object Entry Count (最大オブジェクトエントリ数)

オブジェクトの最大エントリ数を指定します。

-1

false

Maximum Array Element Count (最大配列要素数)

配列の最大要素数を指定します。

-1

false

-1 の値は、項目値に制限がないことを意味します。
## [](#ペイロードの例)ペイロードの例 ペイロードに次の JSON 例が含まれているとします。 { "Players":\[ { "Name":"Sachin", "Email":"sachin.tendulkar@example.com" }, { "Name":"Suryakumar", "email":"Surya@example.com" }, { "Name":"Bhuvi", "email":"bhuvi@example.com" }, { "Name":"Jonty", "Email":"jonty@example.com" } \] } ポリシーでは、次のようにパラメーター値の例が定義されます。
パラメーター Value (値) 説明

Maximum Container Depth (最大コンテナ深度)

3

Name​ エントリと ​Email​ エントリの深度

Maximum String Value Length (最大文字列値長)

28

sachin.tendulkar@example.com​ の長さ

Maximum Object Entry Name Length (オブジェクトエントリ名の最大長)

7

Players​ オブジェクトエントリ名の長さ

Maximum Object Entry Count (最大オブジェクトエントリ数)

2

各 ​Players​ オブジェクトのエントリ数

Maximum Array Element Count (最大配列要素数)

4

Players​ 配列の要素数
# JWT 検証ポリシー

ポリシー名

JWT 検証

概要

JWT トークンを検証する

カテゴリ

セキュリティ

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

v4.1.0

返される状況コード

400 - トークンが要求で提供されなかった。

401

署名が検証されなかった、または無効である。

必要ないくつかのクレームがない、またはクレームの検証に失敗した。

トークンの解析に失敗した。
## [](#概要)概要 JSON Web Token (JWT) は、2 者間で転送されるクレームを表す URL セキュアな方法です。JWT のクレームは、JSON Web Signature (JWS) のペイロードまたはプレーンテキストの JSON Web Encryption (JWE) 構造として使用される JSON オブジェクトとしてエンコードされます。これにより、クレームはデジタル署名したり、メッセージ認証コード (MAC) で整合性を保護したりできます。トークンは署名されるので、その情報と情報源を信頼できます。 JWT 検証ポリシーは、トークンの署名を検証し、JWS 形式の JWT を使用してすべての受信要求のクレームの値をアサートします。このポリシーでは、JWE を使用する JWT は検証されません。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#mule-ゲートウェイ)Mule ゲートウェイ UI からポリシーを API に適用するときに、環境に Mule アプリケーションがあるか非 Mule アプリケーションがあるかに基づいて、パラメーターのリストが表示されます。 #### [](#mule-アプリケーションのパラメーターの設定)Mule アプリケーションのパラメーターの設定 Mule アプリケーションの場合、環境に Mule アプリケーションがあるかどうかに基づいて、次のパラメーターが表示されます。
要素 説明 例

JWT Origin (元の JWT)

要求のどこから JWT が抽出されるのかを指定します。 * HTTP ベアラー認証ヘッダー * カスタム式

この項目を ​HTTP Bearer Authentication Header​ に設定すると、JWT はベアラーと想定されます。
この項目を ​Custom Expression​ に設定する場合、トークンを返す DataWeave 式を指定します。

Token Expression (トークン式)

[JWT Origin (元の JWT)] を ​Custom Expression​ に設定した場合は、JWT を返す DataWeave 式をここに入力します。

#[attributes.headers['jwt']]
この式は、​jwt​ というヘッダー内の JWT を検索します。

JWT Signing Method (JWT 署名方法)

受信 JWT に期待される署名方法を指定します。JWT の署名方法が異なっている場合、ポリシーはトークンを拒否します。

RSA、HMAC、ES、None

JWT Signing Key Length (JWT 署名キーの長さ)

署名方法で使用されるキーの長さ (HMAC アルゴリズムの場合) またはアルゴリズム (RSA の場合) を指定します。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

256、384、512。ES メソッドの場合、Flex Gateway は 256 キーの長さのみをサポートします。

JWT Key Origin (元の JWT キー)

署名検証用のキーの取得元を指定します。
[Text (テキスト)]​ オプションを選択するか、​JWKS​ から取得することで、ポリシーのキーを提供できます。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

JWT Key (JWT キー)

この項目は、[JWT Key Origin (元の JWT キー)] で ​[Text (テキスト)]​ を選択した場合に表示されます。
この項目を使用して、トークンの署名を確認するために使用するキーを提供します。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

HMAC の場合は 32、48、または 64 文字の文字列の共有シークレット、ES の場合は 32 文字の文字列の共有シークレット、RSA の場合はヘッダーとフッターのない PEM 公開キーを入力します。

JWKS URL

この項目は、[JWT Key Origin (元の JWT キー)] で ​[JWKS]​ を選択した場合に表示されます。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

JWKS サーバーの URL。

JWKS Caching Time To Live (JWKS キャッシュの存続時間)

JKWS が有効な時間 (分)。JKWS の有効期限が切れると、ポリシーによってもう一度取得されます。デフォルト値は 60 分です。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

この項目の入力値は、ポリシーで JWKS が有効とみなされる時間 (分) です。

JWKS サービス接続タイムアウト (ミリ秒)。

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

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

この項目をオンにすると、JWT から抽出したクライアント ID が API の有効なクライアントアプリケーションと一致することの確認はされません。

Client ID Expression (クライアント ID 式)

[Skip Client ID Validation (クライアント ID 検証をスキップ)] を設定しない場合は、クライアント ID をトークンから抽出する必要があります。

デフォルトでは、この値は Oauth 2.0 トークンエクスチェンジドラフト​で指定されているように、式 ​#[vars.claimSet.client_id]​ を使用して抽出されます。

Validate Audience Claim (Audience クレームの検証)

Audience クレームの有効性を確認する必要があることを示します。​[Audience Claim Mandatory (Audience クレーム必須)]​ を選択して、このクレームを「必須」に設定できます。

Validate Expiration Claim (Expiration クレームの検証)

Expiration クレームの有効性を確認する必要があることを示します。​[Expiration Claim Mandatory (Expiration クレーム必須)]​ を選択して、このクレームを「必須」に設定できます。

Validate Not Before Claim (Not Before クレームの検証)

Not Before クレームの有効性を確認する必要があることを示します。​[Not Before Claim Mandatory (Not Before クレーム必須)]​ を選択すると、このクレームを「必須」に設定できます。

Validate Custom Claim (カスタムクレームの検証)

ポリシーでカスタム検証を使用できるようにします。すべての DataWeave 式が満たされた場合にのみ JWT が有効とみなされます。

ポリシーは、受信 JWT にあるすべてのクレームを含む ​claimSet​ 変数を提供します。次に例を示します。

foo : #[vars.claimSet.foo == 'fooValue']​

すべての DataWeave 式がブール値を返す必要があります。返さない場合は必ず式が失敗します。
#### [](#anypoint-service-mesh-非-mule-アプリケーション-のパラメーターの設定)Anypoint Service Mesh (非 Mule アプリケーション) のパラメーターの設定 Anypoint Service Mesh (非 Mule アプリケーション) の場合、JWT 検証ポリシーを同じ方法で設定しますが、次の違いがあります。 - ポリシーはクレーム検証の DataWeave 式を受け入れません。 - 次の表で説明しているように、トークン取得およびクライアント ID 検証パラメーターは異なります。
要素 説明 例

JWT Origin (元の JWT)

要求のどこから JWT を抽出するかを指定します。

  • jwt Header​: そのヘッダーから JWT を抽出する

  • HTTP Bearer Authentication Header​: ベアラーであると想定される JWT

  • Custom Header​: JWT は入力であると想定されるヘッダーの名前を取得する

Token Header (トークンヘッダー)

[JWT Origin (元の JWT)]​ を ​Custom Header​ に設定した場合は、JWT を含むヘッダーの名前を指定します。

myJwtHeader​

Client ID Claim (クライアント ID クレーム)

[Skip Client ID Validation (クライアント ID 検証をスキップ)]​ を設定しない場合、クライアント ID はトークンから抽出されます。

デフォルトでは、この値は ​client_id​ クレームから抽出されます。
## [](#ポリシーのしくみ)ポリシーのしくみ このポリシーは、このセクションで説明しているように、異なる方法でクレームと署名を検証します。 ### [](#署名の検証)署名の検証 このポリシーは、ポリシー設定で指定した値に基づいて JWT の署名を検証します。ポリシー設定で指定したアルゴリズムがトークンと一致しない場合や、トークンの署名が無効である場合、すべての JWT がポリシーで拒否されます。アルゴリズムが指定されていない場は、ポリシーは署名済みと未署名のすべてのトークンに一致します。 署名検証がサポートされているアルゴリズムは、次のとおりです。 - **対称アルゴリズム**​ - SHA-256、SHA-384、SHA-512 を使用する HMAC。 - **非対称アルゴリズム**​ - SHA-256、SHA-384、SHA-512 を使用する ES および RSA。 - **なし**​ - 署名検証なし。 JWS 構造内のアルゴリズムについての詳細は、 [JWA RFC 標準](https://tools.ietf.org/html/rfc7518#section-3.1)​を参照してください。 ### [](#クレームの検証)クレームの検証 クレーム検証では、ポリシーで受信したトークンを拒否する条件を選択できます。次の登録済みクレーム検証がデフォルトで提供されています。 - **aud:**​: Audience (オーディエンス) 検証。定義された値が少なくとも 1 つトークンに含まれていない場合、トークンを拒否しなければならないことを示す。 - **exp:**​: Expiration (有効期限) 検証。トークンの日付が検証日より後の場合、トークンを拒否しなければならないことを示す。 - **nbf**​: Not before (以降) 検証。検証日時がトークンの日時よりも前の場合、トークンを拒否しなければならないことを示す。 これらの​_提供されたクレーム_​に加え、検証で使用する他のクレームを指定することもできます。すべてのクレーム、​_登録済み_​または​_カスタム_​で、次の詳細を指定する必要があります。 - 検証するクレームの名前。 たとえば、トークンの発行者の場合は ​**iss**​。 - テストに使用する値。 リテラル値の検証のみが必要な場合は単純なリテラル値を指定し、より複雑な比較の場合は DataWeave 式を指定できます。 各クレーム検証は必須か必須でないかを定義できます。クレームを必須と定義し、そのクレームが受信 JWT に含まれていない場合、ポリシーはこのトークンを拒否します。クレームを必須でないと定義し、そのクレームが受信 JWT に含まれていない場合、ポリシーはその特定の検証ではトークンを拒否しません。 どちらも、クレームが含まれている場合、ポリシーはトークン値を検証します。検証が失敗すると、JWT は拒否されます。 ### [](#クレームの伝播)クレームの伝播 ポリシーが JWT を解析および検証したら、クレームはダウンストリームポリシーに伝播され、認証オブジェクトの ​**claims**​ プロパティを介して移動します。 クレームの値にアクセスするには、次の Dataweave 2.0 式の ​``​ をアクセス対象のクレームの名前に置き換えて使用します。 `#[authentication.properties.claims.]` JWT は下流にも伝播され、次の Dataweave 2.0 式でアクセスできます。 `#[authentication.properties.jwt]` ### [](#再試行メカニズム)再試行メカニズム \[JWT Key Origin (元の JWT キー)\] として \[JSON Web Key Set (JWKS)\] を選択した場合、ポリシーは再試行メカニズムを使用して、失敗した JWKS フェッチを処理します。キャッシュされた JWKS が期限切れになるか存在せず、新しい要求が開始されるたびに、要求は JWKS サービスに送信されます。要求が失敗した場合、新しい JWKS が取得されて再度キャッシュされるまで、エクスポネンシャルバックオフ遅延のある一連の非同期要求が JWKS サービスに送信されます。 再キャッシュが完了するまで、期限切れの JWKS を使用して要求が処理され、要求が見つからない場合は ​`503`​ エラーが返されます。期限切れの JWKS を使用すると、前の要求が失敗した場合でも、今後の要求にキャッシュされた値を適用できます。 ## [](#ポリシーと互換性がある-pem-公開キーを取得する)ポリシーと互換性がある PEM 公開キーを取得する サポートされていない形式の既存の RSA キーを使用する場合、まずキーを PEM 公開キーに変換します。JWT ポリシーは、PEM 形式の公開 RSA キーを使用します。 **タスクの前提条件** 既存のキーを変換する前に次の作業を行います。 1. `public.pem`​ キーを取得します。 2. キーをポリシー設定に貼り付ける前に、​**\-----BEGIN PUBLIC KEY-----**​ ヘッダーと ​**\-----END PUBLIC KEY-----**​ フッターを削除します。 次の表に、現在の形式に基づいて既存のキーを変換する手順を示します。
開始点 手順

以前の証明書なし

  1. 非公開 RSA キーを生成します。 ​openssl genrsa -out key.pem 2048​

  2. 生成された非公開キー ​key.pem​ から、公開キーを抽出します。 ​openssl rsa -in key.pem -outform PEM -pubout -out public.pem​

  3. 公開キーはファイル public.pem 内に含まれます。

PEM 証明書

  1. PEM 証明書から公開キーを抽出します。​openssl x509 -inform pem -in cert.pem -pubkey -noout > public.pem​

  2. 公開キーはファイル public.pem 内に含まれます。

DER 証明書

  1. DER 証明書から公開キーを抽出します。​openssl x509 -inform der -in cert.crt -pubkey -noout > public.pem​

  2. 公開キーはファイル public.pem 内に含まれます。

JWKS の x5c 項目

  1. チェーンから最初の証明書をコピーしてデコードします。echo <certificateString> | base64 -D > cert.crt​ (​<certificateString> をコピーした値に置き換える)

  2. DER 証明書から公開キーを抽出します。​openssl x509 -inform der -in cert.crt -pubkey -noout > public.pem​

  3. 公開キーはファイル public.pem 内に含まれます。
## [](#関連情報)関連情報 - [JWT 検証ポリシーリリースノート](https://docs.mulesoft.com/jp/release-notes/policies/jwt-validation-release-notes) # LDAP セキュリティマネージャー LDAP セキュリティマネージャーポリシーでは、会社にセットアップした Open LDAP または Active Directory LDAP の設定の詳細を定義します。LDAP セキュリティマネージャーポリシーを適用するには、HTTP 基本認証ポリシーの作成と適用も必要です。これによりエージェントに、LDAP ポリシーで定義された設定を使用して、ログイン情報によるアクセスを行うように要求できます。 ## [](#前提条件)前提条件 このドキュメントは、読者が、管理される API バージョンの API バージョン所有であること、または組織システム管理者ロールのメンバーであることを前提としています。 ## [](#ldap-セキュリティマネージャーの設定)LDAP セキュリティマネージャーの設定 LDAP セキュリティマネージャーを LDAP または Active Directory に接続するように設定します。すべての項目が必須です。これらのリテラル文字列値では、プロパティプレースホルダーがサポートされます。パスワードをセキュアな値 (一度入力したら表示も取得もできない値) として入力します。 - LDAP Server URL (LDAP サーバー URL) ポート番号を含む、LDAP サーバーの URL。 - LDAP User DN (LDAP ユーザー DN) LDAP へのアクセス権を持つユーザーまたはユーザーグループの名前。 - LDAP User Password (LDAP ユーザーパスワード) ユーザーまたはユーザーグループのパスワード - LDAP Search Base (LDAP 検索ベース) ディレクトリツリー内の検索の開始点。 - LDAP Search Filter (LDAP 検索条件) Active Directory または OpenLDAP モデルの検索条件。以下の例を参照してください。 ### [](#active-directory-セキュリティマネージャーの設定例)Active Directory セキュリティマネージャーの設定例
項目 リテラル文字列値の例 セキュアプロパティプレースホルダーの例

LDAP Server URL (LDAP サーバー URL)

ldap://174.19.33.17:389/

${ldap.server.url}

LDAP Server User DN (LDAP サーバーユーザー DN)

CN=Administrator,CN=Users,DC=my-company,DC=com

${ldap.user.dn}

LDAP User Password (LDAP ユーザーパスワード)

somePassword

${ldap.password}

LDAP Search Base (LDAP 検索ベース)

CN=Users,DC=my-company,DC=com

${ldap.search.base}

LDAP Search Filter (LDAP 検索条件)

(sAMAccountName={0})

${ldap.search.filter}
上記の検索条件文字列は、Active Directory アプリケーション固有です。 ### [](#openldap-セキュリティマネージャーの設定例)OpenLDAP セキュリティマネージャーの設定例
項目 リテラル文字列値の例 セキュアプロパティプレースホルダーの例

LDAP Server URL (LDAP サーバー URL)

ldaps://my-company-ldap.cloudhub.io:1010/

${ldap.server.url}

LDAP Server User DN (LDAP サーバーユーザー DN)

cn=Manager,dc=my-company,dc=com

${ldap.user.dn}

LDAP User Password (LDAP ユーザーパスワード)

somePassword

${ldap.password}

LDAP Search Base (LDAP 検索ベース)

ou=people,dc=my-company,dc=com

${ldap.search.base}

LDAP Search Filter (LDAP 検索条件)

(uid={0})

${ldap.search.filter}
**注意**​: 上記の検索条件文字列は、OpenLDAP アプリケーション固有です。 LDAP ポリシーを設定するときにセキュアなプロパティプレースホルダーを使用する場合は、コマンドラインを使用するか、Mule Runtime または Mule ゲートウェイランタイムの ​`wrapper.conf`​ ファイルで、プレースホルダーの値をシステム変数として指定します。 次に例を示します。 ```text # OpenLDAP properties definitions wrapper.java.additional.7=-Dldap.password= wrapper.java.additional.8=-Dldap.user.dn=cn=Manager,dc=my-company,dc=com wrapper.java.additional.9=-Dldap.search.base=ou=people,dc=my-company,dc=com wrapper.java.additional.10=-Dldap.search.filter=(uid={0}) wrapper.java.additional.11=-Dldap.server.url=ldaps://my-company-ldap.cloudhub.io:1010/ ``` ## [](#ldap-セキュリティマネージャーポリシーと基本認証ポリシーの適用)LDAP セキュリティマネージャーポリシーと基本認証ポリシーの適用 実行時にこれらのポリシーをエンドポイントに適用するには、次の手順に従います。 1. API Manager に移動し、ポリシーを適用する API バージョンをクリックします。 2. \[Policies (ポリシー)\] タブをクリックして開きます。 3. LDAP セキュリティマネージャーポリシーを適用し、LDAP に接続するように設定します。 4. HTTP 基本認証ポリシーを適用してセキュリティマネージャーポリシーを適用します。 5. セキュリティポリシーが有効になったこと、つまり、API のエンドポイントで認証が要求されることを確認します。 対象のサービスバージョンまたはエンドポイントにセキュリティマネージャーがすでに設定されていても、LDAP セキュリティマネージャーポリシーを適用して HTTP 基本認証ポリシーで適用できます。API Manager で適用されたセキュリティ管理は、すでに適用されている他のセキュリティマネージャーポリシーを上書きします。 ## [](#ldap-セキュリティマネージャーポリシーと基本認証ポリシーの適用解除)LDAP セキュリティマネージャーポリシーと基本認証ポリシーの適用解除 サービスバージョンまたはエンドポイントから LDAP セキュリティマネージャーに基づく HTTP 基本認証を適用解除するには、ポリシーを 1 つずつ適用解除します。 1. HTTP 基本認証ポリシーを適用解除します。 2. LDAP セキュリティマネージャーポリシーを適用解除します。 3. エンドポイントにアクセスして、API が認証を要求しなくなったことを確認します。 # Mule 3 アプリケーションでの Mule ゲートウェイの API 自動検出の設定 Mule 3.x アプリケーションで API Autodiscovery を設定するには、次の要件を満たす必要があります。 ## [](#api-manager-で-api-を使用できるようにする)API Manager で API を使用できるようにする Mule アプリケーションとペアにする API は、API Manager で使用できる必要があります。 次のどちらかで対応してください。 - Exchange に API をパブリッシュして、そこから API Manager にインポートする。 [「Exchange から API を管理する方法」](#api-manager::manage-exchange-api-task.adoc)​を参照してください。 - マシンから直接インポートする。 詳細は、​[「API インスタンスをインポートする方法」](https://docs.mulesoft.com/jp/api-manager/latest/import-api-task)​を参照してください。 ![Calculator の Web Service Definition Language (WSDL) の自動検出 API 参照名およびバージョン](/mulesoft/current/ja-jp/mule-gateway/_images/api-name-version-autodiscovery.png) API Manager は、上記のタスクで生成した API 参照名とバージョンを公開します。 これらの API 参照名とバージョンは、アプリケーションとペアにする API を識別するために Autodiscovery 要素で必要になります。 ## [](#mule-runtime-で-anypoint-platform-組織のログイン情報を設定する)Mule Runtime で Anypoint Platform 組織のログイン情報を設定する Mule アプリケーションで Autodiscovery を使用するには、Anypoint Platform のログイン情報がすでに設定されている状態で Runtime を開始する必要があります。 デプロイメント対象に基づいて組織のログイン情報を設定する方法については、​[「Mule Runtime 3 の組織のログイン情報の設定」](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-org-credentials-mule3)​を参照してください。 ## [](#mule-アプリケーションでの-autodiscovery-要素の設定)Mule アプリケーションでの Autodiscovery 要素の設定 Mule アプリケーションのコード内で、​`api-gateway:auto-discovery`​ 要素を設定する必要があります。 Autodiscovery 要素は、API Manager のペアにする特定の API を参照します。
API のプロキシエンドポイントを設定している場合、自動生成されたプロキシは Autodiscovery 要素で適切に設定されます。
XML 要素 ```xml (4) ```
1UUID (API Manager によって API に割り当てられたグループ ID と Exchange アセット ID) を使用して ​${apiName}​ を設定します。
2API バージョン (API Manager によって API に割り当てられたバージョン名とインスタンス ID または表示ラベル) を使用して ​${apiVersion}​ を設定します。
3API Manager の API とペアにするフローを参照するように ​flowRef​ 要素を設定します。
4APIkit を使用する場合、リソースレベルでポリシーを適用するには、この値を設定する必要があります。そのようにしないと、ポリシーがリソースレベルで機能しません。
`${apiName}`​ および ​`${apiVersion}`​ を特定の値に置き換えるか、キー - 値形式 (​`apiName=[your-specific-value]`​) で値を定義する ​`config.properties`​ ファイルを作成して、この設定の ​`${apiName}`​ および ​`${apiVersion}`​ として参照できます。 これは、Anypoint Studio の UI を使用して設定することもできます。 1. 既存のフローで、Mule 設定ファイルエディターの \[Global Elements (グローバル要素)\] タブを選択します。 2. \[Create (作成)\] ボタンをクリックし、API Autodiscovery グローバル要素を探します。 ![\[API Autodiscovery\] が選択済みになっている \[Choose Global Type (グローバル種別を選択)\] ウィンドウ](_images/autodis-cerate-global2.png) 3. APIname、バージョン、フロー参照を設定します。 ![自動検出設定を定義できるフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/autodis-choose-global2.png) `${apiName}`​ および ​`${apiVersion}`​ 値を使用して、​`config.properties`​ ファイルから参照することもできます。 アプリケーションで要素が定義され、Anypoint Platform のログイン情報でランタイムが設定されたら、Mule Runtime は、API Manager で定義された API 設定を自動的に追跡して最新の状態に保ちます。 ## [](#関連情報)関連情報 - [Mule ゲートウェイの API 自動検出の概念の確認](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-autodiscovery-overview) # Mule 3 と Mule 4 のポリシーの比較 Mule バージョン 3 とバージョン 4 のポリシーは、実装方法と提供されるサポートのレベルによって異なります。
Feature Mule 3 Mule 4

デフォルトの式言語

MEL 式を使用

DataWeave 2.0 を使用

リソース

ライブラリやリソースなどの外部連動関係はポリシーに含めることができず、ランタイムで使用可能にする必要がある

ポリシーはリソースをパッケージ化できるため、ランタイムでの連動関係は不要。

Performance (パフォーマンス)

部分的な非ブロック処理

完全な非ブロック処理

バージョン管理

サポート対象外

完全にサポートされ適用される

実行順序

調整、レート制限、および CORS が最初に実行される。その他のポリシーは並び替え可能

CORS を除くすべてのポリシーを並び替え可能

リソースレベルのサポート

RAML ベースの API に制限

HTTP ベースの API および RAML ベースの API にまで拡張されたサポート

クラスローダーの分離

サポート対象外

アプリケーションライブラリ、拡張機能、ランタイムライブラリ間でサポート

ポリシーの追加

調整

スパイク制御

認証のサポート

単純なセキュリティマネージャーまたは LDAP セキュリティマネージャーポリシーに基づく HTTP 基本認証

セキュリティマネージャー設定を含む、単純な基本認証および LDAP 基本認証ポリシー

レート制限のサポート

ノードと設定済みクラスター間で共有される設定不可能なクォータ。

  • 以下を含む設定可能なクォータ

    • ヘッダーを公開する機能

    • クォータをクラスタリングする機能

設定

ヘッダー伝搬はデフォルトで行われない

ヘッダー伝播はデフォルトでは行われないが、トークン適用、レート制限、その他のデフォルトポリシーで設定可能

カスタマイズ

XML スキーマ言語に基づいたカスタムポリシーテンプレートの作成をサポート

  • XML スキーマ言語を使用してカスタムポリシーを作成する強力なエンジン

  • 改善されたエラー処理

  • すべての MuleSoft コンポーネントのサポート

  • ポリシーとアプリケーション間の分離

  • バックエンドサービスから戻ってくるアウトバウンド要求に適用可能

  • 追加ライブラリをパッケージ化可能

  • Exchange へのアップロード時にポリシーのバージョン管理サポートを提供。
カスタムポリシーの実装とユーザーエクスペリエンスは、Mule 3 バージョンと Mule 4 バージョンで大きく異なります。Mule バージョンのカスタムポリシーについての詳細は、それぞれのカスタムポリシーセクションを参照してください。 ## [](#関連情報)関連情報 - [カスタムポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-overview) # Mule 3 のゲートウェイ起動暗号化 ゲートウェイ起動暗号化を使用すると、ポリシー、コントラクトや、Mule アプリケーションと Anypoint Platform 間の接続の設定に必要なログイン情報など、ランタイムにより保存される機密情報を暗号化できます。 ## [](#暗号化を使用するためのランタイムの設定)暗号化を使用するためのランタイムの設定 16 文字の暗号化キーを使用して Anypoint Platform ログイン情報 (クライアント ID、クライアントシークレット、およびプロキシパスワード) を暗号化し、ランタイムが暗号化されたログイン報を復号化して使用できるように、​`anypoint.platform.encryption_key`​ プロパティを介して起動時にこの暗号化キーをランタイムに渡すことができます。 ```none $MULE_HOME/bin/mule start -Danypoint.platform.encryption_key=MyEncryptionKey1 ``` ランタイムは起動中に暗号化キーがあるかどうかを確認します。次にクライアント ID とクライアントシークレットの値をその ​`wrapper.conf`​ ファイルから取得します。 ## [](#エージェントを使用したログイン情報の暗号化)エージェントを使用したログイン情報の暗号化 ランタイムが暗号化を使用できるようにするには、暗号化キーを使用するエージェントに引数 ​`encryption-key`​ を値として渡す必要があります。これにより、エージェントはクライアント ID とシークレットを暗号化します。 ランタイムの起動時に、前述したように ​`anypoint.platform.encryption_key`​ プロパティを使用して暗号化キーを渡す必要があります。 ## [](#ゲートウェイ暗号化ツール)ゲートウェイ暗号化ツール ゲートウェイ暗号化ツールには、Mule Runtime Engine 3.9.3 以降で暗号化されるポリシーファイルを調べる方法が用意されています。また、オフラインポリシーを暗号化し、暗号化されたクライアントログイン情報をランタイムに渡す方法もあります。 このツールには、​`policy`​ と ​`property`​ の 2 つのモードがあります。 ### [](#ポリシー)ポリシー このモードは、ポリシー XML ファイルを暗号化および復号化します。 ポリシーファイルを暗号化する方法 ```none java -jar gateway-encryption-tool.jar policy ``` このツールは、​``​ で渡されるポリシーを取得し、​``​ で渡される暗号化キーを使用して暗号化し、​``​ でその結果をファイルに保存します。
このツールはポリシーの有効性を検証しません。
最初に [encryption tool jar](https://docs.mulesoft.com/jp/mule-gateway/_attachments/gateway-encryption-tool-1.0.0.jar) ファイルをダウンロードする必要があります。 ### [](#プロパティ)プロパティ このモードは、​`wrapper.conf`​ ファイルで設定されたプロパティの値を暗号化および復号化します。 設定ファイルのプロパティを暗号化する方法 ```none java -jar gateway-encryption-tool.jar property ``` このツールは、​``​ で渡されるキーを取得し、それを使用して ​``​ で渡される値を暗号化します。 `decrypt`​ オプションを使用すると、ターミナルは暗号化された値の一部の文字のみを解釈する可能性があります。このシナリオを回避するには、暗号化された値を単一引用符で囲みます。 ```none java -jar gateway-encryption-tool.jar property decrypt 1234567812345678 '![FefVUnvDJpbXnUvrGAEezg==]' ``` ## [](#ポリシーの暗号化)ポリシーの暗号化 一部のポリシーには機密データが含まれる可能性があります。ランタイムが暗号化キーを使用するように設定されている場合、ランタイムはすべてのオンラインポリシーを暗号化してからディスクに保存します。同じ理由で生成されるポリシーキャッシュの動作も同じです。暗号化されたポリシーを開いた場合、通常の XML ファイルが表示される代わりに、ファイルは次のようになります。 !\[khaR+9HOuJhCfC+pAQ7NZKjK1u3ZiW1kFnxBkGmMvh1ZUXZi3GMJbl9m7oFSU+ug0kJqaeDoR2iw KhSrUihrR33t3LJzvb8+8wjOEZz+Wl7oBxx+JhYRaz1nZmXm+BtTZUbtreQ4dsqmNTLTI7TWszBq lYe6KWUevUH23kQcbzMB2FGpULJQUoH/HDYm0dkdIQSsCrF8Yx8tGE4rz/NWLH4VnADu9/Y2QuhT JcEjU8GlQu6Ha4YQq4NLljt6E9nE2RCibpfKVdwMh1gKNn1XKP8AuR7PXxVVkmS1NPO+fZNURB+z RhAuYEE9D+u6ncO4qUJ0bjYUUU6Vn0t5BowIJcABZVk4T8lUJgSM70kd/pYTs9F+qh2NUaM4X8f7 XxhY49qyw/0/5PPY9DfieHoUMv8YBzInSz1FSKH0/E+Ouf4TraFaTFbfwRdOlOogYNgWEA+XCenu YEzJH0eG27R5xjeo1WRxN3zHx2OigqJkqwSMn5K9VHIWA686pgGFahZHXpiUsXNXF3irIrhejJwy h5GMv7Jj57zxtSiF5nGlb5HpjoGC0jdxaalD4mfTJv4Riv2MJHwWfSXZ8EO00OAL/sssvBJhBatz 8/kQuvII0E++nPdefzBjDcFD0bawJJpvXWInpqNmHntLg/KoMC9XmSDMn9Bp5NorkZuVxN+jc75k me+nUwpbsIL03LSPCrIGZwIb4ZJJUws+t/CyDlG5NUAALpZL4dV6FJPDOtsGsLfy0/r3qzpgRp/1 a4vjxY5PWchQc4k2x/gKOVqsrH/i0dI2wTl7ggSYEgPG+Ra82jA5tTVfimQafyUfwN9i7J76o716 lZ64JFqm7KD4f4FT1G+mhS/wrJjSeUVOv6JZCdT5T+AK57cxTAb325PJeFm1m8RoDgKeONmYerTr kR4s+s1ha02QVmalvJZIHbEU6fjCHDJMGXhLGdxCP/6QAtGqjpPanbppzssEaKSlPTpAdukbGw2W ZuyhlwpuxbUy097f1d22NBZ1ey2+8X7kXobNabctv57U5Vmca294vkqCVW7yYtKRq/kZHnJD173v HjV5BRBA++tjl7MksXS7cNrk1Fo0YQp7YGW0YnZUksXB1FFzG5VQR4hqaRAcvF8z6CevLjPWoD3s TrSSF1qOw7ejsiF8x0b7QE9l0kpVwwhQoPWeg2rc2VwydMadM8jiBU+3BDXQTZNqNZhxRxtLh9HI wfOHAym2VWceXAInH04w4R8VWlOE24bkdSOwuhRLqMvdnX1nfjztZaiIjEiGqUKMpGZ1rmWeB/M/ sOvyN8MutCi6HdxZBhFiDdYtGBPOu/ru86nx4QdK6OIpeSMNq7EWym9Azr6ixNYKSgvUU+eUhV6I OlzQhLm4Xeu3L9i9R9QM39D3lgm4eoHqowa+7+nGCNznydhWj0exGle5MSIkCRMyTUjzybKT5a4k 4QnK/yOGdKJ9bYJT5WlEENfD9IPYyizsBZXQtw3LFl1apRHsGNF56uUKEfo7cBReV62Iz53HfVCd C12nMoKRlwVQiCCwORdukDu1R/HrpeEdLvpZ0H5zoM91q3f7JuyMWyw2ZD/DSo/8J3gZsjP1bgni Uh3KwbxmBVCtBwJRb67drTelcipBYZ8akHsjUEUB1X2H6yz9FQXld2I3lr79y7eapvSndLfaSc6o fk86CdK2SqrqPGhd5/iFxEmv5J228YEkdCVVmhXLMj5oEdeqeB1Ik487pIcYVKXMMCNu8dyCOxti akSjQN/pH5e45UPtepq2MfQTYAD+9YMPZwF7J+e7yDm5M+NHOMcau5l5eaf8GRmSba0slvUSdpX3 pJRiHFYYROqFkw3D+0tifUQ5jBHQB/ZM7pfwBQk4EO1Rm9FzYUqZsiwrwGscX4TeWCikqv/CEdCQ YEtGurM5wHpW8ZrYDxZPZNXRc2pQluuQ09UneZnCv1LPE0FYbg332nJ98I8zwzASybpLKEw4HUi2 SU5+3/UJHVHaTFThb1mR3NKnMwwBZV2p/tquQVZoSPZ8X85F2Fn9NESqum8yq3mk6aa0WaOV09z3 O1q1lBrvkfOVK0druUcFWzLmcmXHWr3tFKuFqucze8mZ7QljItYaxF+iZlgIRzhCkd2q95u9zOif wVmIJxk1kv4Dha5jQM15uKP/22fMrMkKljGEhApKlhBwevlb542TeXWETlaRU8sZpXLscrLPCHiU XskWI+xK19uVgofmK88iyhWr3gdYY5Aefvdj6Lxr/MMVgve4kYpd7jJpYycS9GzObPIyaOEvL5DG Hvw=\] ポリシー設定のデバッグまたはトラブルシューティングを行う必要がある場合、ゲートウェイ暗号化ツールのポリシーモードを使用して、暗号化されていない XML を復旧できます。 ランタイムはオフラインポリシーを自動的に暗号化しません。ただし、すでに暗号化されているオフラインポリシーファイルを提供する場合、ランタイムはそれらを復号化して通常どおり使用できます。 クラスターでの実行時に、ポリシーの元のデプロイ先ノードが暗号化を使用するように設定されている場合、そのノードでオフラインポリシーは暗号化されたままになります。他のノードに伝播する場合、ポリシーはノードの設定に従います。暗号化を使用するようにノードが設定されている場合、ポリシーは暗号化されてそのノードに伝播されます。暗号化を使用するようにノードが設定されていない場合、ポリシーは暗号化されずにそのノードに伝播されます。 ## [](#関連情報)関連情報 - [Mule 4 のゲートウェイ起動暗号化](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-encryption-mule4) - [Mule Runtime 3 の組織のログイン情報の設定](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-org-credentials-mule3) # Mule 3 のポリシー ポリシーは API の機能を拡張し、セキュリティなど特定の機能を適用します。ポリシーはアクセスとトラフィックを制御できます。たとえば、ポリシーは通常、認証、アクセス、割り当てられたコンシューム量、サービスレベルアクセス (SLA) を制御できます。ポリシーを次の種別の API に適用できます。 - APIkit プロジェクト たとえば、APIkit プロジェクトを API Autodiscovery を使用して Anypoint Platform にデプロイし、ポリシーを適用します。 - CloudHub で実行される API Anypoint Platform 上の API を設計し、CloudHub のプロキシを設定し、ポリシーを適用します。 - 非公開またはクラウドベースの Mule Runtime 3.8.x 以降にデプロイされた API - Mule ゲートウェイランタイム 2.x にデプロイされた API API Manager では多くのポリシーが提供されます。カスタムポリシーを作成することもできます。プロキシ API アプリケーションをデプロイし、1 つ以上のポリシーを適用して、いつどのように受信した要求をその実装エンドポイントに転送するかを制御できます。API 要求が SLA のポリシーに違反したら通知を受け取るように API アラートを設定できます。 デフォルトでは、ポリシーは API 全体に適用され、リソースおよびメソッドごとに要求トラフィックを絞り込みます。 Mule Runtime 3.8.0 以降では、Gatekeeper を使用してポリシーでセキュリティを強化できます。Gatekeeper は、すべてのオンラインポリシーが適用されるまで API を無効化します。 ## [](#管理アーキテクチャ)管理アーキテクチャ ポリシーは、次のコンポーネント間の協調的な通信によって実装されます。 - API Manager - 1 つ以上の Mule ゲートウェイランタイムまたは Mule Runtime 3.8.0 以降 - 1 つ以上の API プロキシアプリケーション API Manager では、Anypoint Platform アカウントおよび組織を使用し、ポリシーを設定して API バージョンに適用できます。 特定の API バージョンを特定の API 実装エンドポイントに結び付け、それによって API プロキシアプリケーションを自動生成することもできます。 次に、API プロキシを Mule Runtime か、API 実装が Mule Runtime 3.7.0 以前で実行されている場合はスタンドアロン Mule ゲートウェイランタイムにデプロイできます。 Mule Runtime 3.8.0 以降には、ランタイム内に埋め込まれた Mule ゲートウェイ機能がすべて含まれています。 各 API プロキシアプリケーションは、API で指定された HTTP または HTTPS URL で要求を受信します。 通常、要求は対応する API 実装エンドポイント URL に転送され、続いて応答が API プロキシアプリケーションを介して要求側のクライアントアプリケーションに返送されます。 ## [](#ポリシーの挿入と適用)ポリシーの挿入と適用 特定の API バージョンの API プロキシアプリケーションを従来の Mule ゲートウェイランタイムまたは Mule Runtime 3.8.0 以降にデプロイすると、ランタイム/ポリシーフォルダーに適用されたポリシーが API プロキシに挿入されます。これにより、アプリケーションの動作が変わります。 プロキシアプリケーションが新規要求を受信すると、挿入されたすべてのポリシーが適用されて、要求を API 実装エンドポイントに転送するかどうかと、その方法が決定されます。 このように、実際のポリシー適用は、プロキシアプリケーション自体の内部で発生し、受信した要求を処理している API プロキシ、Anypoint Platform エージェント、およびオンラインの API Manager 間の相互通信を最小に抑えます。API プロキシアプリケーションには、ランタイムで実行されている Anypoint Platform エージェントとの通信も、API Manager との通信も必要ありません。 ただし、Anypoint Platform エージェントと API Manager の接続は保持されます。ポリシーが再設定されるか、API Manager から削除されると、それらのポリシーは接続された Mule ゲートウェイまたは Mule Runtime にダウンロードされ、それによって各ランタイム/ポリシーフォルダーが更新されます。ポリシーの変更は再度各 API プロキシアプリケーションに挿入されます。これにより、ポリシーは、API プロキシアプリケーションの再デプロイや Mule ゲートウェイまたは Mule runtime の再起動なしで動的に変更されます。 # Mule 4 アプリケーションでの Mule ゲートウェイの API 自動検出の設定 Mule 4.x アプリケーションで API 自動検出を設定するには、次の要件を満たす必要があります。 ## [](#api-manager-で-api-を使用できるようにする)API Manager で API を使用できるようにする Mule アプリケーションとペアにする API は、API Manager で使用できる必要があります。 次のどちらかで対応してください。 - Exchange に API をパブリッシュして、そこから API Manager にインポートする。 [「Exchange から API を管理する方法」](#api-manager::manage-exchange-api-task.adoc)​を参照してください。 - マシンから直接インポートする。 詳細は、​[「API インスタンスをインポートする方法」](https://docs.mulesoft.com/jp/api-manager/latest/import-api-task)​を参照してください。 API Manager は、インポートされた各 API の「API ID」識別子を生成します。 ![API インスタンス ID が強調表示されている HTTP API インスタンス](/mulesoft/current/ja-jp/mule-gateway/_images/api-id.png) この API ID は、アプリケーションとペアにする API を識別するために自動検出要素で必要になります。 ## [](#api-manager-の設定)API Manager の設定 この手順は、デプロイ済み Mule アプリケーションを API プロキシ自体として使用するように API Manager に指示する場合に必要になります。 1. \[Managing Type (管理種別)\] で、\[Basic Endpoint (基本エンドポイント)\] を選択します。 2. デプロイ済み Mule アプリケーションを参照する実装 URI を追加します。 3. チェックマーク ​`Check this box if you are managing this API in Mule 4 or above`​ を選択します。 ## [](#mule-runtime-で-anypoint-platform-組織のログイン情報を設定する)Mule Runtime で Anypoint Platform 組織のログイン情報を設定する Mule アプリケーションで自動検出を使用するには、Anypoint Platform のログイン情報がすでに設定されている状態で Mule Runtime Engine を開始する必要があります。 デプロイメント対象に基づいて組織のログイン情報を設定する方法については、​[「Mule Runtime 4 の組織のログイン情報の設定」](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-org-credentials-mule4)​を参照してください。 ## [](#mule-アプリケーションでの自動検出要素の設定)Mule アプリケーションでの自動検出要素の設定 Mule アプリケーションのコード内で、​`api-gateway:Autodiscovery`​ 要素を設定する必要があります。 Autodiscovery 要素は、API Manager のペアにする特定の API を参照します。
API のプロキシエンドポイントを設定している場合、自動生成されたプロキシは自動検出要素で適切に設定されます。
XML 要素 ```xml (2) ```
1API Manager が API に割り当てた API ID を使用して ​apiId​ を設定します。
2API Manager の API とペアにするフローを参照するように ​flowRef​ 要素を設定します。
`${apiId}`​ を特定の値に置き換えるか、キー - 値形式 (​`apiId=[your-specific-value]`​) で値を定義する ​`config.properties`​ ファイルを作成して、この設定の ​`${apiId}`​ として参照できます。 これは、Anypoint Studio の UI を使用して設定することもできます。 1. 既存のフローで、Mule 設定ファイルエディターの \[Global Elements (グローバル要素)\] タブを選択します。 2. \[Create (作成)\] ボタンをクリックし、API 自動検出グローバル要素を探します。 ![\[Component configurations (コンポーネント設定)\] というラベルが付いたドロップダウンで \[API Autodiscovery (API の自動検出)\] が選択されているグローバル要素を設定するためのフォーム](_images/auto-discovery-studio-7.png) 3. API ID とフロー参照を設定します。 ![API の自動検出設定を表示するフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/auto-discovery-api-config.png) `${apiId}`​ 値を使用して、​`config.properties`​ ファイルから参照することもできます。 アプリケーションで要素が定義され、Anypoint Platform のログイン情報でランタイムが設定されたら、Mule Runtime は、API Manager で定義された API 設定を自動的に追跡して最新の状態に保ちます。 ## [](#mule-3-x-設定からの変更)Mule 3.x 設定からの変更 API 自動検出要素の構文は、Mule 3.x から変更されていますが、その目的は変わりません。Mule アプリケーションの要素の形式は次のとおりです。
Mule 3.x XML 要素 Mule 4.x XML 要素

<api-platform-gw:api (…​)/>。

<api-gateway:autodiscovery (…​)/>。
Mule 4 では、API は API ID と、HTTP リスナーが定義されているフローへの参照によって識別されます。Mule 4 の apiId は、Mule 3.x 以前の自動検出要素を指定するために使用される apiName と apiVersion を置き換えます。 ## [](#関連情報)関連情報 - [Mule ゲートウェイの API 自動検出の概念の確認](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-autodiscovery-overview) # Mule 4 カスタムポリシーのパブリッシュ 以下の手順は、Mule 4 のカスタムポリシーをパブリッシュするためのワークフローの概要です。 1. ポリシー定義ファイルを作成する。 2. ポリシー定義アセットを Exchange にパブリッシュする。 3. 実装ファイルを作成する。 4. パブリッシュしたポリシー定義にポリシー実装を追加する。 ## [](#始める前に)始める前に Mule 4 のカスタムポリシーをパブリッシュする前に、Anypoint Platform の管理者権限またはコントリビューター権限を持っていることを確認してください。 ## [](#create-policy-definition-files)ポリシー定義ファイルの作成 ポリシー実装をアップロードする前に、JSON と YAML ポリシー定義ファイルを作成する必要があります。必要なファイルは JSON と YAML です。 JSON ファイルは、JSON スキーマ言語を使用して、ポリシーのインターフェースを指定します。API Manager は、JSON ファイルを使用して UI を表示します。 YAML ファイルは、ポリシーカテゴリ、インターフェーススコープ、必要な特性、RAML/OAS スニペットなどのポリシーに関連したメタデータを提供します。 カスタムポリシーの定義例をコピーするか、またはローカルシステムでファイルを作成してください。 ### [](#json-スキーマファイルの作成)JSON スキーマファイルの作成 JSON スキーマファイルは、ポリシーの設定で必要なプロパティやサポートされるプロパティを特定することで、ポリシーのインターフェースを指定します。また、このファイルに追加のアノテーションを含めることで、Anypoint Platform で特別な動作を実行できるようにする各プロパティの種別を絞り込みます。たとえば、Dataweave の検証やシークレットの安全な処理などです。 JSON ファイルには次の項目が含まれている必要があります。 - 最上位の @コンテキスト 追加の種別アノテーションで使用するボキャブラリーを参照します。ボキャブラリーの名前空間を指定するための別名は省略可能です。よく使用される名前としては ​`security`​ や ​`config`​ があります。 security 別名と config 別名の値は次のとおりです。 - security: `anypoint://vocabulary/policy.yaml#` - config: `` anypoint://vocabulary/policyConfigurationsForUI.yaml#` `` - 最上位のタイトル - JSON スキーマ仕様へのリンクを指定した $schema (例参照) - `object`​ のルート種別 - 最上位の説明 - 各プロパティには以下を含める必要もあります。 - タイトル タイトルは、API Manager UI が項目名を表示するのに使用します。 - 説明 説明は、API Manager UI が項目を説明するのに使用します。 - 型 プリミティブ型 (例: `integer`​、​`string`​、​`object`​、​`boolean`​、​`array`​) のみがサポートされます。 各プロパティには以下を含めることもできます。 - 形式 オプションは ​`dataweaveExpression`​ と ​`` ipRange` ``​ です。 - デフォルト UI で表示されるデフォルト値を入力することができます。 - @characteristics 配列を使用した @context 追加のアノテーションによる種別を次のオプションでさらに絞り込みます。 - `config:commaSeparatedValues` この項目の値によって配列が生成されます。 - `security:sensitive`​ API Manager UI でプロパティを入力するときにプロパティをマスクするかどうかを決定します。 基本認証 JSON スキーマのコード例を示します。 { "title": "Basic authentication - Simple", "type": "object", "description": "Enforces HTTP Basic authentication according to the details configured in the policy.", "properties": { "username": { "title": "User Name", "type": "string" }, "password": { "title": "User Password", "type": "string", "@context": { "@characteristics": \[ "security:sensitive" \] } } }, "required": \[ "username", "password" \], "unevaluatedProperties": false, "@context": { "@vocab": "anypoint://vocabulary/policy.yaml#", "security": "anypoint://vocabulary/policy.yaml#" }, "$id": "basic-authentication-simple", "$schema": "https://json-schema.org/draft/2019-09/schema" } ### [](#定義メタデータ-yaml-ファイルの作成)定義メタデータ YAML ファイルの作成 YAML ファイルは、ポリシーとその要件に関する情報を提供します。YAML ファイルは、特定のランタイムやバイナリには関連付けられません。 このファイルでは以下の項目を設定する必要があります。 - ヘッダー ヘッダーは #%Policy Definition 0.1 である必要があります。 - 名前 API Manager の UI でポリシー名を表示するために使用されるわかりやすい名前。文字列値である必要があります。 - 説明 文字列値である必要があります。 - カテゴリ ポリシーが属するカテゴリ。API Manager の UI でポリシーのグループ化や絞り込みを行うために使用されます。任意の文字列値を使用できます。例: `security`​、​`quality of service`​、​`compliance`​、​`troubleshooting`​、​`transformation`​。 - 提供される特性 ポリシーで提供する特性を定義するために使用するリスト。文字列の配列である必要があります。空白のままにするには、​`providedCharacteristics: []`​ を使用します。 基本認証定義 YAML ファイルのコード例を示します。 #%Policy Definition 0.1 name: Basic authentication - Simple description: Enforces HTTP Basic authentication according to the details configured in the policy. category: Security providedCharacteristics: - Requires authentication requiredCharacteristics: \[\] interfaceScope: \["api", "resource"\] interfaceTransformation: \[\] encryptionSupported: true violationCategory: authentication ## [](#exchange-へのポリシー定義アセットのパブリッシュ)Exchange へのポリシー定義アセットのパブリッシュ 必要なポリシー定義ファイル (JSON および YAML) を作成したら、ポリシー定義アセットを Exchange にパブリッシュします。 詳細は、​[「カスタムポリシー定義アセットの作成」](https://docs.mulesoft.com/jp/exchange/to-create-an-asset#create-custom-policy-definition-asset)​を参照してください。 ## [](#create-implementation-files)実装ファイルの作成 ポリシーをランタイムで使用できるようにするのに必要なポリシー実装ファイルは、メタデータファイルとバイナリファイルです。メタデータファイルは、バイナリファイルがどのランタイムバージョンからどのテクノロジーに適用されるかを記述します。メタデータファイルは、YAML ファイルである必要があります。バイナリファイルにはポリシーロジックが含まれ、ランタイムの実行を管理します。このファイルは、Mule 4 ランタイムの場合は JAR ファイルです。 ### [](#実装メタデータ-yaml-ファイルの作成)実装メタデータ YAML ファイルの作成 メタデータ YAML ファイルは、ポリシー定義の特定の実装に関する詳細を提供します。1 つのポリシー定義から複数の実装を派生させることができます。それぞれの実装は Exchange では独立したアセットになるか、または同じ Exchange アセットの異なるバージョンになります。 メタデータ YAML ファイルには次の項目が含まれている必要があります。 - Header (ヘッダー) `#%Policy Implementation 1.0` - テクノロジー `mule4` - Name (名前) 実装の名前。 - `minRuntimeVersion` 実装バイナリが互換性を持つ最初のランタイムバージョンを表すセマンティックバージョン。たとえば、Mule バイナリは 4.3.0 以降とのみ互換性を持ちます。 - `supportedJavaVersions` カスタムポリシーでサポートされる Java バージョンで、​`「8」`​、​`「11」`​、​`「17」`​のいずれかになります。1 つまたは複数のバージョンをリストできます。​`supportedJavaVersions`​ 項目を追加しない場合、ポリシーでは Java 8 のみがサポートされます。 YAML ファイルには ​`Release notes`​ を含めることもできます。 実装メタデータ YAML ファイルのコード例を示します。 #%Policy Implementation 1.0 minRuntimeVersion: 4.1.1 supportedJavaVersions: \["8", "11", "17"\] technology: mule4 name: Simple Auth Mule Implementation releaseNotes: "" ### [](#実装バイナリファイルの作成)実装バイナリファイルの作成 実装バイナリファイルは、Mule 4 ポリシーの場合は JAR ファイルです。このファイルは、すべての設定項目をサポートし、定義メタデータで記述されているように機能する必要があります。 ## [](#パブリッシュしたポリシー定義へのポリシー実装ファイルの追加)パブリッシュしたポリシー定義へのポリシー実装ファイルの追加 カスタムポリシー定義アセットを Exchange にパブリッシュしたら、次はパブリッシュしたポリシーにポリシー実装ファイルを追加します。このステップにより、ポリシーがランタイムで使用できるようになります。必要な実装ファイルは、Mule 4 ランタイム用の JAR と YAML メタデータファイルです。 実装ファイルを追加する前に、ポリシーアセットが \[Stable (安定)\] 状態であることを確認してください。 ## [](#anypoint-api-manager-から-api-へのポリシーの適用)Anypoint API Manager から API へのポリシーの適用 実装ファイルをパブリッシュしたら、API Manager でポリシーを API に適用できるようになります。ポリシーの適用については、Anypoint API Manager のドキュメントを参照してください。 # Mule 4 カスタムポリシーワークフロー カスタムポリシーは、既存の機能を拡張または新機能を定義するために誰もが開発して API に適用できるポリシーです。 Anypoint Platform で適用できる Mule 4 の作業ポリシーを取得する現在のワークフローの構成は次のとおりです。 1. ポリシーを開発する。 2. ポリシーをパッケージ化する。 3. 結果のポリシーアセットを Exchange にアップロードする。 4. API Manager を介して任意の API にポリシーを適用する。 ## [](#アーキタイプを使用したプロジェクトのセットアップ)アーキタイプを使用したプロジェクトのセットアップ カスタムポリシーを開発する最初のステップは、必要なファイルを使用してプロジェクトをセットアップすることです。 必要なすべてのファイルを収集する最も簡単な方法は、Maven アーキタイプを使用することです。アーキタイプにより、必要なすべてのファイルが作成されます。 次に、Maven を使用してカスタムポリシーをデプロイ可能な JAR にパッケージ化します。 現在、Maven アーキタイプは Maven 中央リポジトリで使用できないため、Maven 設定を定義して、MuleSoft のいずれかのリポジトリでアーキタイプを検索する必要があります。 この作業を行う方法の 1 つは、次のセクションを使用して Maven の ​`settings.xml`​ を設定することです。 ```xml archetype-repository archetype Mule Repository https://repository.mulesoft.org/nexus/content/repositories/public true fail true warn ``` Maven が設定されたら、次の手順を実行します。 1. カスタムポリシープロジェクトを格納する新しいディレクトリを作成します。 2. コマンドラインでそのディレクトリに移動します。 3. 次のコマンドを実行します。 ```console mvn -Parchetype-repository archetype:generate \ -DarchetypeGroupId=org.mule.tools \ -DarchetypeArtifactId=api-gateway-custom-policy-archetype \ -DarchetypeVersion=1.2.0 \ -DgroupId=${orgId} \ -DartifactId=${policyName} \ -Dversion=1.0.0 \ -Dpackage=mule-policy ``` 置き換え: - `${orgId}`​ を、ポリシーがアップロードされる Anypoint Platform 組織 ID に置き換えます。 - **\[Access Management (アクセス管理)\] > \[Organization (組織)\]**​ から組織 ID を取得します。 - 組織の名前をクリックします。 - ブラウザーアドレスから UUID をコピーします。たとえば、URL から ​_2a4b93c3-7899-4ea7-9374-f787744d8784_​ をコピーします。 - `${policyName}`​ を、カスタムポリシーの目的の名前に置き換えます。 4. 完了する前に、Maven から以下をセットアップするように求められます。 - **policyDescription**​: ポリシーの簡単な説明。 - **policyName**​: ポリシーの識別子名。

-DencryptionSupported=true​ プロパティを渡して、暗号化をサポートするポリシーを作成できます。
詳細は、​「カスタムポリシーの暗号化」​を参照してください。
コマンドを実行すると、プロジェクトのディレクトリは次のような構造になります。 my-custom-policy/ ├── my-custom-policy.yaml ├── mule-artifact.json ├── pom.xml └── src └── main └── mule └── template.xml これらの 4 つのファイルは、作業ポリシーを設定するために必要な基本的なファイルです。 - **pom.xml** - `groupId`​: アーキタイプで使用される組織 ID として定義されます。この値は、そのままにしておく必要があります。 - `mule-policy`​ パッケージ化: これにより、パッケージャープラグインは正常に JAR を構築できます。 - `distributionManagement`​ セクション: ユーザーの Exchange を参照するように定義されます。 - `mule-maven-plugin`​: ポリシーをデプロイ可能な jar にパッケージ化します。 - `maven-deploy-plugin`​: ポリシーを Exchange にアップロードするときに結果の jar と YAML の両方をデプロイするように設定されます。 - **mule-artifact.json**​: mule-maven-plugin のために存在します。これは、Mule アプリケーションで必要なファイルと同じです。 - **my-custom-policy.yaml**​: ポリシー設定 UI を表示します。このファイルが提供されないと、API プラットフォームの UI でポリシーを適用できません。 - **template.xml**​: ポリシーの実際のロジックとポリシーの動作を定義する Mule 設定。 デフォルトでは、アーキタイプにより、返される HTTP 応答ペイロードを「Hello World!」メッセージに設定する基本的なポリシーが生成されます。それは、次の設定で実装されます。 XML 要素 ```xml (1) (2) (3) ```
1ポリシーを定義するための基本構造。 {{{policyId}}}​ は、HandleBars 変数を参照します。HandleBars は、ユーザーがより複雑なポリシーを作成できるようにするテンプレートフレームワークです。
2インバウンド HTTP 要求を参照するソース。その他のオプションは、アウトバウンド HTTP 要求のロジックを定義するためのものです。
3次のポリシーまたはフローを実行する必要があることを示す明示的な要素。この前に配置された要素は次のポリシーまたはフローに移動する前に実行され、この後に配置された要素は次のポリシーまたはフローから戻った後に実行されます。
これでプロジェクトが設定されたので、要件に応じてロジックを更新できます。 ポリシーエンジンは強力で、HTTP 要求や応答の変更、ログ記録、キャッシュ、調整、および Mule Runtime Engine で実行できるその他のほぼすべてのインテグレーションなどを実行できます。 ## [](#関連情報)関連情報 - [カスタムポリシーのパッケージ化](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-package) - [Exchange へのカスタムポリシーのアップロード](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-upload-to-exchange) - [カスタムポリシーの概念の確認](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-overview) - [カスタムポリシーの例](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-response-example) # Mule 4 のカスタムポリシーのキャッシュ 外部システムからトークンなどの値を取得してアプリケーションまたはポリシーで使用する必要がある場合、値を ​[Mule 4 Object Store](https://docs.mulesoft.com/object-store-connector/latest/)​ に一時的に保存できます。​ [Object Store Connector に関する情報は Anypoint Exchange を参照](https://www.anypoint.mulesoft.com/exchange/org.mule.connectors/mule-objectstore-connector/)​してください。​[Object Store バックエンドドキュメント](https://docs.mulesoft.com/jp/object-store/)​も参照してください。 Object Store へのアクセスは、\[Anypoint Platform\] > \[Runtime Manager\] から有効にすることができます。ただし、Runtime Manager Object Store は ​[CloudHub](https://docs.mulesoft.com/cloudhub/)​ およびハイブリッドアプリケーションのみを対象とします。 オブジェクトストアにデータを保存するアプリケーション、またはそのいずれかのワーカーがデータを取得できます。オブジェクトストアではカスタムポリシーのキャッシュが提供されるため、外部コールを何度も実行することが回避されます。また、CloudHub 内のさまざまなインスタンスで実行されているさまざまな API に適用されている複数のポリシーでオブジェクトストアを使用できます。 ## [](#オブジェクトストアを使用したキャッシュ)オブジェクトストアを使用したキャッシュ Mule は、値を取得して最大 30 日間保存する Mule 4 Object Store Connector を提供します。 次の例では、データをオブジェクトストアから取得します。特定のキーのデータが見つからない場合は、外部システムから新しい値を取得してオブジェクトストアに保存します。 ```xml #[vars.myVar] ``` この例の ​``​ ステートメントでは、値トークンを検索のキーとして使用して、Object Store Connector の取得操作を実行し、取得した値を ​`myVar`​ 変数に割り当てます。 キーに関連付けられた値がない場合、取得操作によりエラーがスローされます。このため、操作は ​``​ ブロックで囲まれています。これにより、エラーが発生した場合、最新の値を取得してオブジェクトストアに保存することでエラーを処理できます。 HTTP 要求は ​``​ ブロック内で実装されています。値は API コールを介して取得され、​`myVar`​ 変数に割り当てられます。次に、Object Store Connector の ​`store`​ 操作を使用して、値はオブジェクトストアに保存されます。 このブロックが実行されると、キャッシュまたは外部システムから取得された値が myVar に含まれます。この値は、キャッシュに保存され、後で使用されます。この値を任意の目的で使用できます。たとえば、この値を新しいヘッダーとして要求や応答などに追加できます。 ## [](#オブジェクトストアの定義)オブジェクトストアの定義 Object Store Connector の操作を使用するには、まずその操作で使用するオブジェクトストアを定義する必要があります。 次の設定では、myObjectStore を定義し、値を 1 時間保存します。この例のオブジェクトストアは永続的として設定されているため、ランタイムが再起動しても Object Store はクリアされません。 ```xml ``` 存続期間 (TTL) の値は 1 時間に設定されています。 ## [](#runtime-manager-でのキャッシュ)Runtime Manager でのキャッシュ Runtime Manager で実行されている API にポリシーをデプロイし、そのインスタンスでも Object Store v2 (OSv2) が有効になっている場合、上記の永続的オブジェクトストアの設定を使用すると、ポリシーは値を Cloud Object Store にキャッシュします。 ただし、制限があります。Object Store Connector では新しいストアを作成できないため、設定されたエントリ存続期間は使用時に順守されません。代わりに、30 日の TTL を持つデフォルトのオブジェクトストアパーティションが使用されます。 ## [](#multiple-api-のオブジェクトストアの有効化)Multiple API のオブジェクトストアの有効化 Object Store v2 を使用している場合、複数の API デプロイ間でキャッシュを共有できます。 これを実現するには、オブジェクトストアの設定に含まれる属性の名前が、デプロイされるすべてのポリシーで同じである必要があるほか、ランタイムには、true の値が設定されている ​`objectstore.enable.global.sharing`​ という名前のシステムプロパティが含まれる必要があります。 これを有効にすると、該当のインスタンスで実行されているポリシーで保持されているデータを、同じ環境下の他のインスタンスで実行されているポリシーでも使用できます。 **警告:**​ グローバル共有の OSv2 モードを有効にすると、アプリケーションまたは他のポリシーで使用されているオブジェクトストアが組織のすべての API でも共有されるようになります。 ## [](#オブジェクトストアを使用したポリシーのキャッシュの完全な例の確認)オブジェクトストアを使用したポリシーのキャッシュの完全な例の確認 この例は、外部システムから取得し、Mule Object Store にキャッシュした値を使用して、ヘッダーを受信 HTTP 要求に追加するポリシーを示しています。 ```xml #[vars.myVar] #[{'new-custom-header': vars.myVar}] ``` この例で必要な連動関係は次のようになります。 ```xml org.mule.connectors mule-http-connector 1.2.1 mule-plugin provided org.mule.connectors mule-objectstore-connector 1.1.1 mule-plugin com.mulesoft.anypoint mule-http-policy-transform-extension 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Object Store バックエンドドキュメント](https://docs.mulesoft.com/jp/object-store/) # Mule 4 のゲートウェイ起動暗号化 Mule ゲートウェイ起動暗号化を使用すると、ポリシー、コントラクトや、Mule アプリケーションと Anypoint Platform 間の接続の設定に必要なログイン情報など、Mule Runtime Engine (Mule) により保存される機密情報を暗号化できます。 この機能は、Mule 4.2.0 以降でサポートされています。​[暗号化をサポートするポリシー](#policies-that-support-encryption)​ (基本認証 1.2.0 など) が 4.2.0 より前のバージョンの Mule で実行中の API に適用される場合、ポリシー設定は暗号化されません。 ## [](#エージェントを使用した-anypoint-platform-ログイン情報の暗号化)エージェントを使用した Anypoint Platform ログイン情報の暗号化 最も短い時間でクライアントのログイン情報を保護する方法は、Anypoint Runtime Manager エージェントを介して暗号化を設定する方法です。エージェントサーバーを作成するときに暗号化鍵を追加します。これで、エージェントはプロパティを自動的に暗号化します。 エージェントを介して暗号化を設定する方法についての詳細は、​[「Runtime Manager エージェントのインストールと設定」](https://docs.mulesoft.com/jp/runtime-manager/installing-and-configuring-runtime-manager-agent)​を参照してください。 ## [](#クライアント-id-とクライアントシークレットの暗号化)クライアント ID とクライアントシークレットの暗号化 エージェントを使用している場合でも、プロパティを手動で暗号化できます。最も一般的な方法は​[セキュアプロパティツール](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties#secure-properties-tool)​を使用することです。 暗号化されたプロパティを使用すると、Mule ゲートウェイは、CBC モードで AES アルゴリズムが使用されていると仮定します。 ### [](#例)例 クライアント ID が ​`bb458e566cba4e2ea5a826d27b46031a`​ であり、暗号化鍵を 128 ビット文字列 ​`MyEncryptionKey1`​ とするように選択したとします。これらのプロパティを暗号化するには、次のコマンドを実行する必要があります。 ```console > java -jar secure-properties-tool.jar \ string \ (1) encrypt \ (2) AES \ (3) CBC \ MyEncryptionKey1 \ (4) bb458e566cba4e2ea5a826d27b46031a ```
1string パラメーターを使用して単一値を暗号化します。
2値を暗号化するようにツールを設定します。
3CBC モードで AES を使用します。
Mule は後で値を復号化する際にこの設定を使用するため、これは重要です。
4最後に、暗号化する暗号化鍵-値ペアを指定します。
暗号化されたクライアント ID は、このコマンドにより次のように出力されます。 ```none > smzbg+aV2HbiC9Fv8KBsZpD5PlXiplsfhZ42RWNEbHhUeZ9ZIDftljUx6sYpuQ+b ``` ## [](#暗号化されたクライアント-id-とクライアントシークレットを渡す)暗号化されたクライアント ID とクライアントシークレットを渡す ログイン情報を暗号化したら、暗号化された値を、Mule 環境のルートフォルダーの ​`conf`​ ディレクトリ内にある ​`wrapper.conf`​ ファイルで設定する必要があります。 ```none wrapper.java.additional.=-Danypoint.platform.client_id=![_encrypted client ID_] wrapper.java.additional.=-Danypoint.platform.anypoint.platform.client_secret=![_encryptedclient secret_] wrapper.java.additional.=-Danypoint.platform.proxy_password=![_encrypted password_] ``` には、​`wrapper.java.additional`​ ファイル内で一意の番号を指定してください。

設定ファイルに ​wrapper.java.additional.n​ エントリを追加する場合は、​<n>​ の各インスタンスを連続する番号に変更する必要があります。 そうしないと、Java はプロパティを正しく解析しません。
この例の設定では ​`client_id`​ は次のように表示されます。 ```none wrapper.java.additional.100=-Danypoint.platform.client_id=![smzbg+aV2HbiC9Fv8KBsZpD5PlXiplsfhZ42RWNEbHhUeZ9ZIDftljUx6sYpuQ+b] ```
必須の ​![​ プレフィックスと ​]​ サフィックスは、囲まれた値が暗号化されていることを Mule Runtime Engine に示します。
Mule Runtime の起動時に、​`anypoint.platform.encryption_key`​ プロパティを使用して秘密鍵を渡す必要があります。 ```none $MULE_HOME/bin/mule start -M-Danypoint.platform.encryption_key=MyEncryptionKey1 ``` Mule Runtime は、​`anypoint.platform.encryption_key`​ プロパティに渡された暗号化鍵を使用して、プロパティを復号化します。 ### [](#しくみ)しくみ Anypoint Platform ログイン情報 (クライアント ID、クライアントの秘密、およびプロキシパスワード) を暗号化し、その暗号化された値を暗号化鍵と共に Mule 環境の ​`wrapper.conf`​ ファイルに追加できます。 Mule ゲートウェイ機能は起動時に暗号化鍵があるかどうかを確認します。その後クライアント ID とクライアントシークレットがその ​`wrapper.conf`​ ファイルから取得されます。このファイルのいずれかの値が暗号化インジケーター (​`![`​ と ​`]`​) で囲まれている場合、Mule Runtime は以前に読み込んだ暗号化鍵を使用して値を復号化し、その元のコンテンツを使用します。 ## [](#起動暗号化のデバッグ)起動暗号化のデバッグ 起動中に暗号化メカニズムに関する情報を表示するようにランタイム Log4J ロガーを設定できます。 `$MULE_HOME/conf/log4j2.xml`​ で、ゲートウェイデプロイの非同期ロガーをセットアップします。 ```XML ... ... ``` 鍵を指定すると、Mule 環境は次のメッセージを表示します。 An encryption key is present. Policies and API contracts will be encrypted. 指定しない場合、Mule Runtime は次のメッセージと共に起動します。 No encryption key provided. Policies and API contracts will not be encrypted. 暗号化プロセスが失敗した場合、Mule 環境はエラーを表示します。 Client ID cannot be decrypted ログイン情報を復号化できない場合は、Anypoint Platform には接続できず、以降はポリシーやコントラクトをダウンロードしたり、追跡されている API の分析情報を生成したりできなくなります。 ## [](#ログイン情報に関するトラブルシューティング)ログイン情報に関するトラブルシューティング 暗号化されたログイン情報を Anypoint Platform に渡すときに問題が発生した場合、指定したログイン情報が有効であることを確認することをお勧めします。セキュアプロパティツールを使用して、値を元の値に復号化し、Anypoint Platform に表示された値と比較することができます。 1. セキュアプロパティツールを実行してログイン情報を復号化します。 ```none > java -jar secure-properties-tool.jar string decrypt AES CBC ``` 2. 復号化された値を Anypoint Platform 内の値と比較します。 Anypoint Platform のログイン情報を検証する方法についての詳細は、​[「ログイン情報の取得」](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-org-credentials-mule4#obtaining-credentials)​を参照してください。 ## [](#サポートされるプロパティ)サポートされるプロパティ 暗号化をサポートする ​`wrapper.conf`​ プロパティを次に示します。
プロパティ Property Key (プロパティキー) 説明

Client ID (クライアント ID)

anypoint.platform.client_id

Anypoint Platform のクライアント ID

Client secret (クライアントシークレット)

anypoint.platform.client_secret

Anypoint Platform のクライアントシークレット

Proxy password (プロキシパスワード)

anypoint.platform.proxy_password

Anypoint Platform に接続するためのプロキシ設定のパスワード
## [](#ポリシーの暗号化)ポリシーの暗号化 API ポリシーの設定は ​`policies`​ ディレクトリに保存されています。認証されていないパーティには非表示にする必要がある機密情報 (​`Basic Authentication`​ ヘッダーのパスワード項目など) が一部のポリシーに含まれている場合があります。 提供された API ポリシー内の機密値は、ポリシー設定用の API Manager UI では機密としてマークされます。カスタムポリシーを作成するときに、どの値が機密かを定義することができます。 ## [](#ポリシーの暗号化の設定)ポリシーの暗号化の設定 ポリシーの暗号化を有効にするには、​`wrapper.conf`​ ファイルで 2 つのシステムプロパティを提供する必要があります。 - `anypoint.platform.encryption_key` ポリシーの暗号化鍵。

暗号化鍵なしで Mule Runtime を再起動すると、すべてのポリシーが再度ダウンロードされ、機密情報は暗号化されません。
- `anypoint.platform.policy_encryption_mode` このプロパティキーは、2 つの値を取ります。

FULL

すべての値が暗号化されます。

SENSITIVE_ONLY

sensitive​ としてマークした値のみが暗号化されます。
これはデフォルトの暗号化モードです。
このプロパティを設定しないと、デフォルトの ​`SENSITIVE_ONLY`​ 暗号化モードが使用されます。 暗号化モードは適用後に変更できます。​`policies`​ ディレクトリ内のファイルは、新しい暗号化モードに従って再生成されます。

FULL​ から ​SENSITIVE_ONLY​ に変更している場合、​sensitive​ としてマークされていないすべてのパラメーターはファイルシステム内でプレーンテキストとして表示されます。
## [](#policies-that-support-encryption)暗号化をサポートするポリシー 値の暗号化がサポートされるすべてのポリシーと、その機能をサポートするために必要な最小バージョンが以下のリストで説明されています。 これらのポリシーの以前のバージョンと以下のリストに示されていないポリシーでは、設定内の暗号化鍵がゲートウェイ機能により検出されても、ポリシーの値は暗号化されません。
ポリシー バージョン

基本認証

1.2.0 以降。

クライアント ID 適用

1.2.0 以降。

ヘッダーの挿入

1.1.0 以降。

IP 許可リスト

1.0.0 以降。

IP ブロックリスト

1.0.0 以降。

JWT 検証

1.1.0 以降。

Open AM

1.2.0 以降。

Open ID

1.2.0 以降。

OAuth 2.0

1.2.0 以降。

Ping Federate

1.2.0 以降。
## [](#カスタムポリシーの暗号化)カスタムポリシーの暗号化 新しいカスタムポリシープロジェクトの推奨の作成方法は、Maven アーキタイプを使用することです。 アーキタイプを使用して新しいカスタムポリシープロジェクトを作成する場合、​`-DencryptionSupported=true`​ プロパティを渡して、カスタムポリシー内の暗号化を有効にできます。 この手順についての詳細は、​[「アーキタイプを使用したプロジェクトのセットアップ」](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-getting-started#setting-up-a-project-with-the-archetype)​を参照してください。 カスタムポリシーを手動で開発する場合、または既存のポリシーに暗号化を追加する場合、次の手順を実行します。 1. 必要な連動関係をポリシーの ​`pom.xml`​ ファイルに追加します。 **Secure Configuration Property Module**​ 連動関係を ​`pom.xml`​ ファイルに追加する必要があります。 ```XML com.mulesoft.modules mule-secure-configuration-property-module ${securePropertyModuleVersion} mule-plugin ``` 2. **Secure Properties 要素**​をポリシーのテンプレートファイルに追加します。 次のスニペットをポリシーの XML テンプレートファイルの ​``​ 要素の後に貼り付けます。 ```XML {{#if encrypted}} {{/if}} ``` この機能は CBC モードの AES アルゴリズムのみをサポートします。 ゲートウェイ機能は、ゲートウェイの起動時に設定されたシステムプロパティから ​`anypoint.platform.encryption_key`​ と ​`encryptedPropertiesFile`​ の値を取得します。 3. ポリシーの YAML ファイルで機密値を定義します。 デフォルトでは、カスタムポリシー内の値は機密ではありません。値が機密であることを指定するには、​`sensitive`​ 要素を使用します。 ```YAML configuration: - propertyName: username type: string sensitive: false - propertyName: password type: string sensitive: true (1) ```
1これで、ポリシー内の ​password​ 値は機密とみなされます。
## [](#オフラインポリシーの暗号化)オフラインポリシーの暗号化 オフラインポリシーの設定を暗号化するには、​[セキュアプロパティツール](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties#secure-properties-tool)​を使用して値を暗号化できます。 \> java -jar secure-properties-tool.jar \\ string \\ **(1)** encrypt \\ **(2)** AES \\ **(3)** CBC \\ MyEncryptionKey1 \\ **(4)** bb458e566cba4e2ea5a826d27b46031a 1. string パラメーターを使用して単一値を暗号化します。 2. 値を暗号化するようにツールを設定します。 3. CBC モードで AES を使用します。Mule Runtime は後で値を復号化するときにこの設定を使用するため、これは重要です。 4. 最後に、暗号化する暗号化鍵-値ペアを指定します。 詳細は、​[オフラインポリシーの割り当て](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-offline-apply)​を参照してください。 ## [](#コントラクトの暗号化)コントラクトの暗号化 Mule ゲートウェイが暗号化を使用して設定されている場合、コントラクト適用ポリシーに関連付けられているコントラクトも暗号化されます。 ## [](#スコープと考慮事項)スコープと考慮事項 クラスターのシナリオでは、ノードごとに暗号化プロパティを設定する必要があります。それ以外の場合、一部のノードを無保護のままとすることができます。 # Mule Gateway ポリシーの概要 ポリシーを使用すると、セキュリティの管理、トラフィックの制御、API の適応性の向上に役立つ規制を適用できます。たとえば、ポリシーは認証、アクセス、割り当てられたコンシューム量、サービスレベルアクセス (SLA) を制御できます。 コードの実装を変更することなく、これらの規制を実装できます。 ポリシーは、カテゴリ、目的、バージョン、設定オプションなど、いくつかの異なる要素に基づいて異なります。環境に実装する前に、これらの要素を慎重に検討してください。 Mule Runtime Engine (Mule) に基づいたポリシー Exchange アセットは以下から構成されます。 - Mule 4: - ポリシービジネスロジックが含まれるデプロイ可能な JAR ファイル。 - ポリシーパラメーターとメタデータが定義される YAML 設定ファイル。 - Mule 3.x: ポリシービジネスロジックと設定パラメーターを含む XML ファイル。 ## [](#ポリシーのアーキテクチャ)ポリシーのアーキテクチャ ポリシーは、次のコンポーネント間の協調的な通信によって実装されます。 - API Manager - 1 つ以上の API ゲートウェイランタイム、または Mule Runtime Engine (Mule) 3.8.0 以降 - 1 つ以上の API プロキシまたは API アプリケーション API Manager を使用して、ポリシーを設定し、API インスタンスに適用できます。API バージョンには、1 つ以上の API インスタンスを含めることができます。 特定の API インスタンスを特定の API 実装エンドポイントに結び付け、それによって API プロキシアプリケーションを自動生成することもできます。 Mule Runtime Engine に API プロキシをデプロイできます。 各 API プロキシアプリケーションは、API で指定された HTTP または HTTPS URL で要求を受信します。通常、要求は対応する API 実装に転送され、続いて応答が API プロキシアプリケーションを介して要求側のクライアントアプリケーションに返送されます。 ## [](#ポリシーの挿入と適用)ポリシーの挿入と適用 特定の API バージョンの API プロキシアプリケーションを Mule にデプロイすると、適用されたプラットフォームのポリシーまたはランタイムのオフラインポリシーが API プロキシに挿入されます。これにより、アプリケーションの動作が変わります。プロキシアプリケーションが新規要求を受信すると、挿入されたすべてのポリシーが適用されて、要求を API 実装に転送するかどうかと、その方法が決定されます。 このように、実際のポリシー適用は、プロキシアプリケーション自体の内部で発生します。これにより、受信した要求を処理している API プロキシ、Anypoint Platform エージェント、およびオンラインの API Manager 間の相互通信を最小に抑えます。API プロキシアプリケーションには、ランタイムで実行されている Anypoint Platform エージェントとの通信も、API Manager との通信も必要ありません。 ただし、Anypoint Platform エージェントと API Manager の接続は保持されます。ポリシーが再設定されるか、API Manager から削除されると、それらのポリシーは接続された API ゲートウェイまたは Mule Runtime Engine にダウンロードされ、それによって各ランタイムまたはポリシーフォルダーが更新されます。ポリシーの変更は再度各 API プロキシアプリケーションに挿入されます。これにより、ポリシーは、API プロキシアプリケーションの再デプロイや API ゲートウェイまたは Mule Runtime Engine の再起動なしで動的に変更されます。 ## [](#ポリシーのスコープ)ポリシーのスコープ ポリシーは、アプリケーションや他のポリシーから分離されています。ただし、ポリシーから情報を公開する方法があります。ポリシーについての認証情報は、セキュリティコンテキストプリンシパルオブジェクトで伝播できます。 トークン適用ポリシーなどの一部のポリシーでは、トークンに関連する情報を含むヘッダーの伝播が許可されます。このトークンは、実装サービスまたは API 自体によって使用されます。 ## [](#ポリシーのサイズ)ポリシーのサイズ ポリシーのサイズは連動関係に基づいて異なります。初回は、Mule がポリシーをポーリングし、取得するのに時間がかかります。ただし、取得されたポリシーはファイルシステムにキャッシュされます。オフラインでも使用可能になり、レイテンシーも短縮されます。 ### [](#cached-policy-assets-deletion)キャッシュされたポリシーアセットの削除 デフォルトでは、API Manager でポリシーが適用解除された場合であっても、Mule ゲートウェイで JAR および YAML ポリシーアセットファイルが削除されることはありません。
キャッシュされたポリシーアセットの自動的な削除は 2024 年 2 月 1 日以降にリリースされた Mule Runtime バージョン 4.4.x および 4.5.x と Mule Rruntime バージョン 4.6.0 以降でのみサポートされます。
次のエントリを ​`wrapper.conf`​ ファイルに追加することで、ランタイムが起動したときに使用されていないキャッシュされたファイルを自動的に削除できます。 ```conf anypoint.platform.delete_unused_templates_on_start=true ``` ## [](#ポリシーと-sla)ポリシーと SLA 事前定義された SLA に準拠するようにレート制限ポリシーを設定できます。サービスレベルアクセス (SLA) 層は、API で定義するユーザーアクセスのカテゴリです。層定義と SLA ベースのポリシーの組み合わせにより、API へのアクセスが許可されるかどうかが決まります。 たとえば、アプリケーションに適用される次の SLA 層のいずれかに応じて、アクセスの層を作成します。 - 要求を 3 回/分に制限する層。 承認を必要としない。 - 要求を 5 回/分に制限する層。 API にアクセスする必要があるアプリケーションの API バージョンオーナーの承認が必要です。 SLA では、アクセスを 1 つの API リソースのみに制限します。その他のリソースへのアクセスは無制限です。アプリケーションが保護されたリソースをコンシュームしようとすると、ポリシーが適用されます。要求には、期待されるユーザー名とパスワードが含まれている必要があります。アプリケーションから API への SLA 制限内で繰り返されるコールは成功します。 ## [](#関連情報)関連情報 - [ポリシーのカテゴリ](https://docs.mulesoft.com/jp/mule-gateway/policies-policy-categories) - [ポリシーの種類](https://docs.mulesoft.com/jp/mule-gateway/policies-policy-types) - [Mule 3 のポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3) # Mule OAuth 2.0 アクセストークン OAuth を使用して Anypoint Platform で API を保護するには、次のいずれかのポリシーを使用して OAuth プロバイダーを照合することをお勧めします。 - OpenAM OAuth トークン適用ポリシー - PingFederate OAuth トークン適用ポリシー - OpenID Connect アクセストークン適用ポリシー 推奨されるポリシーを使用するには、OpenAM、PingFederate、または動的クライアント登録に準拠する ID プロバイダーをセットアップする必要があります。何らかの理由で推奨プロバイダーを使用できない場合は、外部プロバイダーを使用した OAuth 2.0 アクセストークン適用ポリシーを使用します。そして、Mule プロバイダーを使用する必要があります。 Mule クライアントアプリケーションで Anypoint Platform 外の OAuth 2.0 で保護されたリソースにアクセスする場合、どのトークン適用ポリシーも機能しません。代わりに、この目的には HTTP 用 Anypoint Connector (HTTP Connector) を使用してください。 Anypoint Platform で API に適用する認証適用ポリシーは、OpenAM 認証サーバー、PingFederate 認証サーバー、OpenID Connect トークンイントロスペクションエンドポイント、またはカスタム OAuth 2.0 プロバイダーに接続します。 **IMPORTANT:**​ 外部プロバイダーを使用する OAuth 2.0 アクセストークン適用ポリシーを使用するには、Mule OAuth 2.0 プロバイダーでアクセストークンを提供する必要があります。Facebook、Google、Azure など、他の OAuth 2.0 プロバイダーは​_使用できません_​。 API Manager で適用される他のポリシーと同様に、OAuth 2.0 アクセストークンポリシーを適用して使用するには、API Manager で API を登録する必要があります。 ## [](#前提条件)前提条件 - Anypoint Platform 組織のシステム管理者であるか、環境で API を作成または管理する権限を持っている。 - OpenAM、OpenID Connect、PingFederate のいずれかを使用して Anypoint Platform 組織を統合組織としてセットアップします。下記のリンクを参照してください。または、Mule OAuth 2.0 プロバイダーが設定されて稼働している必要があります。 ## [](#関連情報)関連情報 - [HTTP 要求の認証の設定](https://docs.mulesoft.com/jp/http-connector/1.10/http-authentication) - [OAuth 2.0 プロバイダー](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-aes-oauth-faq) - [OpenAM OAuth トークン適用](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-openam-oauth-token-enforcement-policy) - [統合ユーザーと OpenID Connect イントロスペクションエンドポイントのクライアント管理について](https://docs.mulesoft.com/jp/access-management/managing-api-clients) # 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 プロバイダー](https://docs.mulesoft.com/jp/api-manager/latest/mule-oauth-provider-landing-page)​でのみ使用するように設計されています。このポリシーを他の OAuth 2.0 プロバイダー (Facebook、Google、Microsoft Azure など) で使用することはできません。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード OAuth 2.0 アクセストークン適用ポリシーは、Flex Gateway のローカルモードではサポートされません。 ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード OAuth 2.0 アクセストークン適用ポリシーは、Flex Gateway の接続モードではサポートされません。 ### [](#mule-ゲートウェイ)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
## [](#how-this-policy-works)ポリシーのしくみ 次の図は、Mule OAuth プロバイダーポリシーを使用する OAuth 2.0 トークン適用ワークフローを示しています。 ![OAuth ポリシーを介して API とやり取りするユーザーのプロセスを示すフローチャート](/mulesoft/current/ja-jp/mule-gateway/_images/open-id-policy-workflow.png) この図には次の動作が示されています。 1. ユーザーが最初にポリシーで保護された API に HTTP 要求を送信します。 2. ポリシーは要求からトークンを抽出し、それを検証エンドポイントに送信して、トークンの整合性を検証します。 3. トークン検証エンドポイントは、クライアントアプリケーションのクライアント ID を含むトークンメタデータを返します。 4. ポリシーは Anypoint Platform から以前に取得したコントラクトで更新されたローカルデータベースを使用して、クライアント ID が API にアクセスできるかどうかを検証します。 5. すべての検証が正常に完了すると、要求はバックエンドに到達できます。 ### [](#leveraging-TVE-information)Mule アプリケーションのトークン検証エンドポイント情報の活用 トークン検証エンドポイントがトークンを正常に検証すると、Mule OAuth プロバイダーからの設定可能な項目などの特定の情報がポリシーに返されます。 次の例は、認証サーバーからのトークン検証応答を示しています: ```text --- { "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=` または、​`wrapper.conf`​ ファイルでこのパラメーターを指定できます。このプロパティを設定すると、指定された時間、またはトークンが期限切れになるまでのいずれか早い方でトークンがキャッシュされます。このプロパティが有効で、検証エンドポイントが有効期限情報を送信しない場合、トークンはキャッシュされません。 同時にキャッシュできるトークンの数を制御するには、Mule Runtime Engine を起動するときに次のプロパティを指定します。 `anypoint.platform.oauth2_cache_max_size=` または、​`wrapper.conf`​ ファイルでこのパラメーターを指定できます。 ## [](#expose-headers-ヘッダーを公開-オプションの設定)Expose Headers (ヘッダーを公開) オプションの設定 ポリシーで ​`Expose Headers`​ オプションを設定し、アプリケーション (標準のプロキシなど) が HTTP リクエスターを使用している場合、プロパティはヘッダーとしてバックエンドにリダイレクトされます。 各項目で、保護されたリソースへの元の要求は X-AGW- + = 形式を使用して HTTP ヘッダーで強化されます。前のセクションの応答例では、次のヘッダーが追加されています。 ```text --- 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=` このプロパティを有効にすると、次のパラメーターを設定している場合、ポリシーは Mule プロキシ設定を使用します。 - `anypoint.platform.proxy_host=localhost` - `anypoint.platform.proxy_port=8080` ## [](#faqs)FAQs **ポリシーで OAuth 2.0 トークンを生成できますか?** 番号ポリシーはトークンの検証のみを行います。 **ポリシーで他の OAuth プロバイダーを使用できますか?** いいえ。 このポリシーは、​[Mule OAuth プロバイダー](https://docs.mulesoft.com/jp/api-manager/latest/mule-oauth-provider-landing-page)​とのみ連携するように設計されています。このポリシーを他の OAuth プロバイダー (Facebook、Google、Azure など) で使用することはできません。 **Mule OAuth プロバイダー検証エンドポイントがポリシーによって送信された要求を拒否している場合はどうすればよいですか?** 検証エンドポイントが要求を拒否している場合は、ポリシーで設定された URL がポリシーを実行中のマシンから到達可能かどうか、および要求を正常に完了するために認証は不要かどうかを確認します。ユースケースで検証エンドポイントが保護されている必要がある場合は、​[Open ID Connect ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-openid-token-enforcement)​に切り替えることができます。 **OAuth トークンがキャッシュされる場所は?** OAuth 2.0 トークンはメモリにのみキャッシュされ、ディスクに書き込まれることはありません。 **ポリシーは要求ごとに Anypoint Platform と通信しますか?** いいえ。ポリシーは以前に Mule Runtime Engine によって取得されたクライアントアプリケーションを使用します。 これにより、管理プレーンとの接続が失われた場合でも、ポリシーが機能し続けます。ディスクに書き込まれるクライアントアプリケーション情報を暗号化する場合は、​[ランタイムでゲートウェイ暗号化を設定します](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-encryption-mule4)​。 **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 アプリケーションのトークン検証エンドポイント情報」](#leveraging-TVE-information)​を参照してください。 ## [](#関連情報)関連情報 - [Mule OAuth 2.0 プロバイダー](https://docs.mulesoft.com/jp/api-manager/latest/mule-oauth-provider-landing-page) - [Mule 4.x HTTP Requester Connector](https://docs.mulesoft.com/jp/http-connector/1.10/http-documentation) - [統合ユーザーと OpenID Connect イントロスペクションエンドポイントのクライアント管理](https://docs.mulesoft.com/jp/access-management/managing-api-clients) # Mule Runtime 3 の組織のログイン情報の設定 組織のログイン情報を使用すると、Mule Runtime を Anypoint 組織にリンクするときに、組織、ビジネスグループ、または特定の環境を一意に識別できます。 ログイン情報は、2 つのキー (クライアント ID とクライアントシークレット) で構成されます。 Mule Runtime はこれらのログイン情報を使用して、Anypoint 組織に接続してアクセスします。 Mule Runtime を API Manager にリンクする方法として推奨されるのは、環境のクライアント ID とクライアントシークレットを使用することです。組織のクライアント ID とクライアントシークレットを使用することもできます。または、Mule Runtime が親ビジネスグループにリンクされていて、ビジネスグループに定義した API を追跡する場合はビジネスグループのログイン情報を使用することさえできます。 クライアントアプリケーションを識別するときには、2 つのキー (クライアント ID とクライアントシークレット) を持つ一意のリソースの ID も使用されます。 クライアントアプリケーションのログイン情報は組織のログイン情報としては使用されません。使用しても実害はありませんが、Mule Runtime が組織にリンクされません。 Mule Runtime と Anypoint 組織をペアリングするには、Mule Runtime の開始時に Anypoint Platform のログイン情報がすでに設定されている必要があります。 ## [](#ログイン情報の取得)ログイン情報の取得 ### [](#環境のログイン情報の取得-推奨)環境のログイン情報の取得 (推奨) 1. Anypoint Platform にシステム管理者としてログインし、​**\[Access Management (アクセス管理)\]**​ をクリックします。 2. **\[Environments (環境)\]**​ タブをクリックし、目的の組織内の環境の名前をクリックします。 ![Mule 3 の環境のログイン情報](/mulesoft/current/ja-jp/mule-gateway/_images/environment-api-manager.png) 環境のログイン情報は、プラットフォームのクラウド (2017 年 11 月) リリースバージョン以降でのみ使用できます。 ### [](#組織のログイン情報の取得)組織のログイン情報の取得 1. Anypoint Platform にシステム管理者としてログインし、​**\[Access Management (アクセス管理)\]**​ をクリックします。 2. **\[Organization (組織)\]**​ タブをクリックし、組織または対応するビジネスグループの名前をクリックします。 ![Mule 3 での名前、ID、クライアントシークレットなどの組織情報が表示されているフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/orgid-api-manager.png) ## [](#スタンドアロンデプロイメントのログイン情報の設定)スタンドアロンデプロイメントのログイン情報の設定 ### [](#runtime-manager-エージェントの自動セットアップメカニズム)Runtime Manager エージェントの自動セットアップメカニズム スタンドアロンインスタンスをセットアップし、Runtime Manager エージェントを登録する場合は、次の手順を実行します。 1. Anypoint Platform にシステム管理者としてログインし、​**\[Runtime Manager\]**​ をクリックします。 2. **\[Servers (サーバー)\]**​ タブをクリックし、​**\[Add Server (サーバーを追加)\]**​ をクリックします。 3. 実行するように要求されたコマンドを実行します。次のようなコマンドです。 ```text /bin/./amc_setup -H bb123456-789c-1234-9fd3-58f4b5e2d82e---123 server-name ``` `MULE_HOME`​ は Mule Runtime インストールのルートディレクトリが保持されている変数です。例: `/opt/Mule/mule-enterprise-standalone/`​。 このコマンドを実行すると、Runtime エージェントが設定され、自動的に正しい組織のログイン情報が URL と共に Mule Runtime に追加されるため、Mule Runtime は特定の組織にリンクされます。 エージェントを登録すると、wrapper.conf ファイルは必要なデータで変更されるため、設定の変更は永続的になります。 ### [](#手動設定)手動設定 オンプレミスのインスタンスが特定の組織を参照するようにセットアップする場合、ログイン情報を ​`wrapper.conf`​ ファイルに追加するか (永続的アプローチ)、コマンドラインを使用してログイン情報データを指定する必要があります。 #### [](#wrapper-conf-ファイルの使用)wrapper.conf ファイルの使用 設定ファイルは ​`/conf`​ ディレクトリに置かれます。MULE\_HOME は Mule Runtime インストールのルートディレクトリが保持される変数です。 1. $MULE\_HOME ディレクトリに移動します。 2. `/conf/wrapper.conf`​ にあるファイルを開きます。 3. Anypoint Platform 組織のログイン情報を次のように追加します。 ```text wrapper.java.additional.=-Danypoint.platform.client_id=XXXXXXXX (1) wrapper.java.additional.=-Danypoint.platform.client_secret=XXXXXXXX wrapper.java.additional.=-Danypoint.platform.platform_base_uri=https://www.anypoint.mulesoft.com/apiplatform wrapper.java.additional.=-Danypoint.platform.coreservice_base_uri=https://www.anypoint.mulesoft.com/accounts wrapper.java.additional.=-Danypoint.platform.contracts_base_uri=https://www.anypoint.mulesoft.com/apigateway/ccs wrapper.java.additional.=-anypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com ```
1<n>​ は、そのファイル内の他のエントリで使用されていない一意の数値にする必要があります。リストの前のエントリに増分した値を使用することをお勧めします。
複数の行が同じ ​``​ 識別子を使用している場合、その数値を持つ最初の値のみが考慮されます。 \+ 組織が EU コントロールプレーンに定義されている場合、EU 固有の URL を定義する必要があります。 + ```text wrapper.java.additional.=-Danypoint.platform.base_uri=https://eu1.anypoint.mulesoft.com/apiplatform wrapper.java.additional.=-Danypoint.platform.coreservice_base_uri=https://eu1.anypoint.mulesoft.com/accounts wrapper.java.additional.=-Danypoint.platform.contracts_base_uri=https://eu1.anypoint.eu1.mulesoft.com/apigateway/ccs wrapper.java.additional.=-anypoint.platform.analytics_base_uri=https://analytics-ingest.eu1.anypoint.mulesoft.com ``` \+ Private Cloud Edition に定義されている組織を参照する場合も同様です。Private Cloud Edition インストールの URL を指定する必要があります。 #### [](#コマンドラインの使用)コマンドラインの使用 次の引数を使用して起動時にログイン情報を渡すことができます。 Mac OS X/Linux ```console MULE_HOME/bin/mule \ -M-Danypoint.platform.client_id=XXXXXXXX \ -M-Danypoint.platform.client_secret=XXXXXXXX \ -M-Danypoint.platform.platform_base_uri=https://www.anypoint.mulesoft.com/apiplatform \ -M-Danypoint.platform.coreservice_base_uri=https://www.anypoint.mulesoft.com/accounts \ -M-Danypoint.platform.contracts_base_uri=https://www.anypoint.mulesoft.com/apigateway/ccs \ -M-Dnypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com ``` Windows ```console MULE_HOME\bin\mule.bat -M-Danypoint.platform.client_id=XXXXXXXX -M-Danypoint.platform.client_secret=XXXXXXXX -M-Danypoint.platform.platform_base_uri=https://www.anypoint.mulesoft.com/apiplatform -M-Danypoint.platform.coreservice_base_uri=https://www.anypoint.mulesoft.com/accounts -M-Danypoint.platform.contracts_base_uri=https://www.anypoint.mulesoft.com/apigateway/ccs -M-Dnypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com ``` 組織が EU コントロールプレーンに定義されている場合、EU 固有の URL を定義する必要があります。 Mac OS X/Linux ```console MULE_HOME/bin/mule \ -M-Danypoint.platform.client_id=XXXXXXXX \ -M-Danypoint.platform.client_secret=XXXXXXXX \ -M-Danypoint.platform.platform_base_uri=https://eu1.anypoint.mulesoft.com/apiplatform \ -M-Danypoint.platform.coreservice_base_uri=https://eu1.anypoint.mulesoft.com/accounts \ -M-Danypoint.platform.contracts_base_uri=https://eu1.anypoint.mulesoft.com/apigateway/ccs \ -M-Dnypoint.platform.analytics_base_uri=https://analytics-ingest.eu1.anypoint.mulesoft.com ``` Windows ```console MULE_HOME\bin\mule.bat -M-Danypoint.platform.client_id=XXXXXXXX -M-Danypoint.platform.client_secret=XXXXXXXX -M-Danypoint.platform.platform_base_uri=https://eu1.anypoint.mulesoft.com/apiplatform -M-Danypoint.platform.coreservice_base_uri=https://eu1.anypoint.mulesoft. com/accounts -M-Danypoint.platform.contracts_base_uri=https://eu1.anypoint.mulesoft.com/apigateway/ccs -M-Dnypoint.platform.analytics_base_uri=https://analytics-ingest.eu1.anypoint.mulesoft.com ``` Private Cloud Edition に定義されている組織を参照する場合も同様です。Private Cloud Edition インストールの URL を指定する必要があります。 ## [](#anypoint-studio-6-でのログイン情報の設定)Anypoint Studio 6 でのログイン情報の設定 エンドポイントに適用される接続性とガバナンスをテストするために、Anypoint Platform 組織で機能するように Studio 7 を設定できます。 1. Anypoint Studio で、上部のメニューバーから ​**\[Anypoint Studio\]**​ をクリックし、​**\[Preferences (プリファレンス)\]**​ をクリックします。 2. Anypoint Studio で、​**\[API Manager\]**​ をクリックします。 3. **\[Environment Credentials (環境のログイン情報)\]**​ でクライアント ID とクライアントシークレットを入力します。 ![API Manager の設定が含まれるウィンドウ](/mulesoft/current/ja-jp/mule-gateway/_images/org-credentials-config-mule3-af73e.png) デフォルトでは、デフォルトの URI が設定されています。 組織が EU コントロールプレーンに定義されている場合、​**\[Override url configuration (URL 設定を上書き)\]**​ チェックボックスをオンにして、必要な EU コントロールプレーン URI を追加します。 +
項目 URI

API Platform URI (API プラットフォーム URI)

https://eu1.anypoint.mulesoft.com/apiplatform

コアサービス URI

https://eu1.anypoint.mulesoft.com/accounts

Analytics URI

https://eu1.anypoint.mulesoft.com/apigateway/ccs

Contracts URI (コントラクト URI)

https://analytics-ingest.eu1.anypoint.mulesoft.com
\+ image::org-credentials-config-mule3-9d90b.png\["Anypoint Platform の URL やログイン情報などのペアリングプロパティを設定するためのフォーム",align=center\] \+ Private Cloud Edition に定義されている組織を参照する場合も同様です。Private Cloud Edition インストールの URL を指定する必要があります。 ## [](#runtime-manager-でのデプロイしたアプリケーションのログイン情報の設定)Runtime Manager でのデプロイしたアプリケーションのログイン情報の設定。 ### [](#自動生成プロキシデプロイメカニズムによる自動設定)自動生成プロキシデプロイメカニズムによる自動設定 自動生成されたプロキシを API から直接 CloudHub にデプロイできます。 1. Anypoint Platform にシステム管理者としてログインし、​**\[API Manager\]**​ をクリックします。 2. 使用可能な API のリストから、プロキシの自動生成元にする API の API バージョンをクリックします。 3. **\[Settings (設定)\]**​ タブをクリックし、​**\[Deployment Configuration (デプロイメント設定)\]**​ に移動します。 4. ランタイムバージョンとプロキシアプリケーション名を設定し、​**\[Deploy (デプロイ)\]**​ をクリックします。 このメカニズムを使用してプロキシをデプロイすると、組織のログイン情報 (該当する場合は URL も) が自動的に設定されます。\[Runtime Manager\] → <アプリケーション名> → \[Settings (設定)\] → \[Properties (プロパティ)\] で確認できます。 ### [](#手動設定-2)手動設定 1. Anypoint Platform で ​**\[Runtime Manager\]**​ に移動します。 2. デプロイされたアプリケーションの ​**\[Properties (プロパティ)\]**​ セクションにアクセスします。アプリケーションが初めてデプロイされる場合、\[Properties (プロパティ)\] セクションはデプロイメント設定時に表示されます。 3. \[Properties (プロパティ)\] セクションで、次のプロパティを追加します。 ```text anypoint.platform.client_id=XXXXXXXX anypoint.platform.client_secret=XXXXXXXX anypoint.platform.platform_base_uri=https://www.anypoint.mulesoft.com/apiplatform anypoint.platform.coreservice_base_uri=https://www.anypoint.mulesoft.com/accounts anypoint.platform.contracts_base_uri=https://www.anypoint.mulesoft.com/apigateway/ccs anypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com ``` 組織が EU コントロールプレーンに定義されている場合、または Mule Private Cloud Edition を使用している場合、2 つのキーを追加することでベース URL を定義する必要があります。 ```text anypoint.platform.client_id=XXXXXXXX anypoint.platform.client_secret=XXXXXXXX anypoint.platform.platform_base_uri=https://eu1.anypoint.mulesoft.com/apiplatform anypoint.platform.coreservice_base_uri=https://eu1.anypoint.mulesoft.com/accounts anypoint.platform.contracts_base_uri=https://eu1.anypoint.mulesoft.com/apigateway/ccs anypoint.platform.analytics_base_uri=https://analytics-ingest.eu1.anypoint.mulesoft.com ``` Private Cloud Edition に定義されている組織を参照する場合も同様です。Private Cloud Edition インストールの URL を指定する必要があります。 ## [](#関連情報)関連情報 - [Mule 3 アプリケーションでの Mule ゲートウェイの API 自動検出の設定](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-config-autodiscovery-mule3) # Mule Runtime 4 の組織のログイン情報の設定 組織のログイン情報は、Anypoint Platform を使用して Mule Runtime Engine (Mule) を組織にリンクするときに、特定の環境、組織、またはビジネスグループを一意に識別する方法を提供します。環境、組織、およびビジネスグループのログイン情報は、クライアント ID とクライアントシークレットの 2 つのキーで構成されます。Mule はこれらのログイン情報を使用して、組織に接続してアクセスします。 Mule を Anypoint API Manager (API Manager) にリンクする方法として推奨されるのは、環境のクライアント ID とクライアントシークレットを使用することです。組織のクライアント ID とクライアントシークレットを使用することもできます。または、Mule にリンクされているか、Mule にリンクされた親ビジネスグループに属するビジネスグループに定義した API を追跡する場合は、ビジネスグループのログイン情報を使用することさえできます。 環境のログイン情報を使用すると、その環境のみに固有の API を管理できます。API が Anypoint Platform の異なる環境にある場合、代わりに両方の環境を含む組織のログイン情報を指定する必要があります。 親組織のログイン情報を使用して、子組織の API を管理することもできます。たとえば、ACME が親組織で Logistics が ACME 内のビジネスグループ (子組織) である場合、API 管理者は Logistics または ACME のログイン情報を使用して、Logistics で作成された API を追跡できます。 クライアント ID とシークレットでクライアントアプリケーションを識別できます。ただし、クライアントアプリケーションのログイン情報は使用せずに組織のログイン情報を使用することをお勧めします。そうしないと、Mule は組織に正しくリンクされません。 すでに設定されている Anypoint Platform のログイン情を使用して Mule が起動された場合にのみ、Mule を組織に正常にペアリングできます。 組織のログイン情報を使用してアダプターをプロビジョニングしている場合、組織の特定のアダプターでのみ API を管理できます。 ## [](#ログイン情報の取得)ログイン情報の取得 API Manager の使用時はログイン情報の提供が必要なことがあるため、さまざまなクライアントアプリケーション用のログイン情報の取得が必要な場合があります。このセクションで説明する手順を使用して、環境と組織のログイン情報を取得できます。 ### [](#環境のログイン情報の取得-推奨)環境のログイン情報の取得 (推奨) 環境のログイン情報を取得する手順は、次のとおりです。 1. Anypoint Platform にシステム管理者としてログインし、​**\[Access Management (アクセス管理)\]**​ をクリックします。 2. **\[Environments (環境)\]**​ タブをクリックし、目的の組織内の環境の名前をクリックします。 ![Mule 4 の環境のログイン情報](/mulesoft/current/ja-jp/mule-gateway/_images/environment-api-manager.png) 環境のログイン情報は、プラットフォームのクラウド (2017 年 11 月) リリースバージョン以降でのみ使用できます。 ### [](#組織のログイン情報の取得)組織のログイン情報の取得 組織のログイン情報を取得する手順は、次のとおりです。 1. Anypoint Platform にシステム管理者としてログインし、​**\[Access Management (アクセス管理)\]**​ をクリックします。 2. **\[Organization (組織)\]**​ タブをクリックし、組織または対応するビジネスグループの名前をクリックします。 ![Mule 4 での名前、ID、クライアントシークレットなどの組織情報が表示されているフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/orgid-api-manager.png) ## [](#スタンドアロンデプロイメントのログイン情報の設定)スタンドアロンデプロイメントのログイン情報の設定 ### [](#runtime-manager-エージェントの自動セットアップメカニズム)Runtime Manager エージェントの自動セットアップメカニズム スタンドアロンインスタンスをセットアップし、Runtime Manager エージェントを登録する場合は、次の手順を実行します。 1. Anypoint Platform にシステム管理者としてログインし、​**\[Runtime Manager\]**​ をクリックします。 2. **\[Servers (サーバー)\]**​ タブをクリックし、​**\[Add Server (サーバーを追加)\]**​ をクリックします。 3. 実行するように要求されたコマンドを実行します。次のようなコマンドです。 ```text /bin/./amc_setup -H bb123456-789c-1234-9fd3-58f4b5e2d82e---123 server-name ``` `MULE_HOME`​ は Mule インストールのルートディレクトリが保持されている変数です。例: `/opt/Mule/mule-enterprise-standalone/`​。 このコマンドを実行すると、Runtime エージェントが設定され、自動的に正しい組織のログイン情報が URL と共に Mule に追加されるため、Mule は特定の組織にリンクされます。 エージェントを登録すると、wrapper.conf ファイルは必要なデータで変更されるため、設定の変更は永続的になります。 ### [](#手動設定)手動設定 オンプレミスのインスタンスが特定の組織を参照するようにセットアップする場合、ログイン情報を ​`wrapper.conf`​ ファイルに追加するか (永続的アプローチ)、コマンドラインを使用してログイン情報データを指定する必要があります。 #### [](#wrapper-conf-ファイルの使用)wrapper.conf ファイルの使用 設定ファイルは ​`/conf`​ ディレクトリに置かれます。MULE\_HOME は Mule インストールのルートディレクトリが保持される変数です。 1. $MULE\_HOME ディレクトリに移動します。 2. `/conf/wrapper.conf`​ にあるファイルを開きます。 3. Anypoint Platform 組織のログイン情報を次のように追加します。 ```text wrapper.java.additional.=-Danypoint.platform.client_id=XXXXXXXX wrapper.java.additional.=-Danypoint.platform.client_secret=XXXXXXXX ``` ``​ は、そのファイル内の他のエントリで使用されていない一意の数値にする必要があります。リストの前のエントリに増分した値を使用することをお勧めします。 複数の行が同じ ​``​ 識別子を使用している場合、その数値を持つ最初の値のみが考慮されます。 組織が EU コントロールプレーンに定義されている場合、次のように 2 つの追加のキーを定義する必要があります。 ```text wrapper.java.additional.=-Danypoint.platform.base_uri=https://eu1.anypoint.mulesoft.com wrapper.java.additional.=-Danypoint.platform.analytics_base_uri=https://analytics-ingest.eu1.anypoint.mulesoft.com ``` #### [](#コマンドラインの使用)コマンドラインの使用 次の引数を使用して起動時にログイン情報を渡すことができます。 Mac OS X/Linux ```console MULE_HOME/bin/mule \ -M-Danypoint.platform.client_id=XXXXXXXX \ -M-Danypoint.platform.client_secret=XXXXXXXX ``` Windows ```console MULE_HOME\bin\mule.bat -M-Danypoint.platform.client_id=XXXXXXXX -M-Danypoint.platform.client_secret=XXXXXXXX ``` 組織が EU コントロールプレーンに定義されている場合、次のように 2 つのキーを追加することでベース URL を定義する必要があります。 Mac OS X/Linux ```console MULE_HOME/bin/mule \ -M-Danypoint.platform.client_id=XXXXXXXX \ -M-Danypoint.platform.client_secret=XXXXXXXX \ -M-Danypoint.platform.base_uri=https://eu1.anypoint.mulesoft.com \ -M-Danypoint.platform.analytics_base_uri=https://analytics-ingest.eu1.anypoint.mulesoft.com ``` Windows ```console MULE_HOME\bin\mule.bat -M-Danypoint.platform.client_id=XXXXXXXX -M-Danypoint.platform.client_secret=XXXXXXXX -M-Danypoint.platform.base_uri=https://eu1.anypoint.mulesoft.com -M-Danypoint.platform.analytics_base_uri=https://analytics-ingest.eu1.anypoint.mulesoft.com ``` Private Cloud Edition に定義されている組織を参照する場合も同様です。Private Cloud Edition インストールの URL を指定する必要があります。 ## [](#anypoint-studio-7-でのログイン情報の設定)Anypoint Studio 7 でのログイン情報の設定 エンドポイントに適用される接続性とガバナンスをテストするために、Anypoint Platform 組織で機能するように Studio 7 を設定できます。 1. Anypoint Studio で、上部のメニューバーから ​**\[Anypoint Studio\]**​ をクリックし、​**\[Preferences (プリファレンス)\]**​ をクリックします。 2. Anypoint Studio で、​**\[API Manager\]**​ をクリックします。 3. **\[Environment Credentials (環境のログイン情報)\]**​ でクライアント ID とクライアントシークレットを入力します。 ![API プラットフォームおよびアナリティクス URI の入力が可能なフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/configure-autodiscovert-4-studio.png) 組織が EU コントロールプレーンに定義されている場合、次のようにそのプレーンのベース URL も指定する必要があります。 ![API プラットフォーム、アナリティクス URI、クライアントログイン情報の項目が含まれる Anypoint Platform API ペアリングプロパティを入力するためのフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/api-gateway-enabling-0cbca.png) Private Cloud Edition に定義されている組織を参照する場合も同様です。Private Cloud Edition インストールの URL を指定する必要があります。 ## [](#runtime-manager-でのデプロイしたアプリケーションのログイン情報の設定)Runtime Manager でのデプロイしたアプリケーションのログイン情報の設定 ### [](#自動生成プロキシデプロイメカニズムによる自動設定)自動生成プロキシデプロイメカニズムによる自動設定 自動生成されたプロキシを API から直接 CloudHub にデプロイできます。 1. Anypoint Platform にシステム管理者としてログインし、​**\[API Manager\]**​ をクリックします。 2. 使用可能な API のリストから、プロキシの自動生成元にする API の API バージョンをクリックします。 3. **\[Settings (設定)\]**​ タブをクリックし、​**\[Deployment Configuration (デプロイメント設定)\]**​ に移動します。 4. ランタイムバージョンとプロキシアプリケーション名を設定し、​**\[Deploy (デプロイ)\]**​ をクリックします。 このメカニズムを使用してプロキシをデプロイすると、組織のログイン情報 (該当する場合は URL も) が自動的に設定されます。\[Runtime Manager\] → <アプリケーション名> → \[Settings (設定)\] → \[Properties (プロパティ)\] で確認できます。 ### [](#手動設定-2)手動設定 1. Anypoint Platform で ​**\[Runtime Manager\]**​ に移動します。 2. デプロイされたアプリケーションの ​**\[Properties (プロパティ)\]**​ セクションにアクセスします。アプリケーションが初めてデプロイされる場合、\[Properties (プロパティ)\] セクションはデプロイメント設定時に表示されます。 3. \[Properties (プロパティ)\] セクションで、次のプロパティを追加します。 ```text anypoint.platform.client_id=XXXXXXXX anypoint.platform.client_secret=XXXXXXXX ``` 組織が EU コントロールプレーンに定義されている場合、または Mule Private Cloud Edition を使用している場合、2 つのキーを追加することでベース URL を定義する必要があります。 ```text anypoint.platform.client_id=XXXXXXXX anypoint.platform.client_secret=XXXXXXXX anypoint.platform.base_uri=https://eu1.anypoint.mulesoft.com anypoint.platform.analytics_base_uri=https://analytics-ingest.eu1.anypoint.mulesoft.com ``` Private Cloud Edition に定義されている組織を参照する場合も同様です。Private Cloud Edition インストールの URL を指定する必要があります。 ## [](#関連情報)関連情報 - [Mule 4 アプリケーションでの Mule ゲートウェイの API 自動検出の設定](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-config-autodiscovery-mule4) # Mule ゲートウェイの概要 Mule Runtime Engine には、埋め込み Mule ゲートウェイが含まれています。Mule ゲートウェイを使用すると、バックエンド API とサービスの上に専用のオーケストレーションレイヤーを追加できるため、実装からオーケストレーションを切り離すことができます。API Manager のガバナンス機能を使用して、調整、セキュリティ、キャッシュ、ログなどの機能を API に適用できます。 Mule ゲートウェイを使用すると、たとえば次のことを実行できます。 - 基本認証ポリシーを Mule アプリケーション上に適用する。 - 受信/送信メッセージを強化する。 - コードを記述することなく、他の複雑な機能を API に追加する。 ![API クライアントとバックエンド API の間に配置された API ゲートウェイのアーキテクチャを示す図](/mulesoft/current/ja-jp/mule-gateway/_images/apigateway.png) ポリシーを適用し、分析情報を生成する必要がある場合、次のいずれかを使用する必要があります。 - Mule アプリケーションで定義されている API。 - 既存のバックエンド実装をプロキシする Mule アプリケーション。 ## [](#主要概念)主要概念 ### [](#api)API API は一連のコンポーネントの抽象化です。これは Mule アプリケーション開発の複雑さをカプセル化するものであり、アセットにアクセスするための簡単で再利用可能な方法を提供します。 自動検出要素を使用して API を API Manager にペアリングすることで、その API にポリシーを適用することができます。 詳細は、​[API 自動検出について](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-autodiscovery-overview)​を参照してください。 #### [](#httphttps-api)HTTP/HTTPS API HTTP Exchange アセットを使用して作成する API。Mule ゲートウェイは、API Manager により追跡される関連付けられた Mule アプリケーションに、実装エンドポイントとして定義された HTTP または HTTPS リスナーがあることを前提とします。 **通常の使用方法**​: REST ベースの API。 [「API アセットの作成」](https://docs.mulesoft.com/jp/exchange/to-create-an-asset#creating-an-api-asset)​を参照してください。 #### [](#raml-api)RAML API RAML/OAS Exchange アセットを使用して作成する API。Mule ゲートウェイは、API Manager により追跡される関連付けられた Mule アプリケーションに、実装エンドポイントとして定義された RAML/OAS ルーターを備えた HTTP または HTTPS リスナーがあることを前提とします。 このアセットを Exchange で使用できるようにするには、API Designer を使用して API を設定した後、API を Exchange にエクスポートすることができます。 **通常の使用方法**​: RAML/OAS ベースの API。 詳細は、​[Design Center でコードエディターを使用して API 仕様を作成およびパブリッシュする方法](https://docs.mulesoft.com/design-center/design-create-publish-api-raml-editor)​を参照してください。 #### [](#wsdl-api)WSDL API WSDL Exchange アセットを使用して作成する API。Mule ゲートウェイは、API Manager により追跡される関連付けられた Mule アプリケーションに、実装エンドポイントとして定義された WSDL ルーターを備えた HTTP または HTTPS リスナーがあることを前提とします。 **通常の使用方法**​: WSDL ベースの API。 ### [](#api-自動検出)API 自動検出 API 自動検出を使用すると、Mule アプリケーションの HTTP エンドポイントを表す API を API Manager で管理できます。 基本的に、これは HTTP リソースを API Manager 内のその API 定義にリンクするメカニズムです。 Mule ゲートウェイは API 自動検出を介して、API Manager 内の対応するペアリング済みの API で定義された設定を同期します。Mule Runtime で自動検出を使用するには、Anypoint Platform 組織のログイン情報が必要です。 詳細は、​[API 自動検出](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-autodiscovery-overview)​に関する記事を参照してください。 ### [](#api-プロキシ)API プロキシ 「自動生成プロキシ」とも呼ばれる API プロキシにより、Mule アプリケーションでの API Manager の使いやすさが向上します。 **通常の使用方法**​: Mule ゲートウェイ機能を使用する必要があるがバックエンド API が Mule Runtime に基づいていない場合や、API は Mule Runtime に基づいているが閉じられたコードのために対応する自動検出要素を定義できない場合に使用します。 ![バックエンド API へのクライアントとの接続における API Manager のロールを示すテクニカル図](/mulesoft/current/ja-jp/mule-gateway/_images/api-gateway-capabilities-mule4-62bf9.png) プロキシエンドポイントとして API を設定した場合、Anypoint Platform を使用して、事前設定済みの Mule アプリケーションをダウンロードできます。アプリケーションが Mule Runtime にデプロイされており、正しい Anypoint Platform ログイン情報を使用している場合、API Manager で API が自動的に追跡されます。 Mule アプリケーションの作成方法の詳細を知らなくても、正しく設定された Mule Runtime にアプリケーションをデプロイできます。
Anypoint Platform は Runtime Manager を介して、Cloudhub にプロキシを直接デプロイしたり、Mule エージェントを使用してプロキシをデプロイしたりできます。
HTTP ではなく HTTPS を使用する場合は、次の手順を実行できます。 1. 自動生成プロキシを Anypoint Studio にインポートします。 2. 使用する証明書を指定します。 3. アプリケーションを Cloudhub またはランタイムインスタンスにデプロイします。 API プラットフォームからダウンロードできるプロキシは、アプリケーションネットワークのデプロイを高速化するための便利なツールです。ただし、これらの自動生成プロキシを使用することに制限されません。正しく設定された自動検出を備えた Mule アプリケーションを使用すれば、Mule ゲートウェイの機能を利用できます。 ### [](#ポリシー)ポリシー ポリシーは、直交する動作を API 全体またはそのリソースに適用するためのツールです。 ポリシーを作成して、受信/送信メッセージの強化、絞り込み、および制御ができるほか、たとえば、API へのトークンアクセスを適用したり、特定の IP アドレスをホワイトリストまたはブラックリストに登録したりすることでセキュリティレイヤーを API 上に適用できます。 Mule ゲートウェイは、標準 (OOTB) ポリシーだけでなく、独自のカスタムポリシーを作成するためのエンジンを提供します。 ### [](#analytics)Analytics Mule Manager に API ゲートウェイを接続すると、​**API Analytics**​ を使用して、登録済み API の使用状況を監視できます。 Mule ゲートウェイでは、検出されたポリシー違反を含め、API 使用状況が報告されます。 #### [](#ポイントカット)ポイントカット Mule ゲートウェイでは、ポリシーがその適用先のリソースを参照するようにポイントカットが使用されます。 API Manager でポリシーを適用した場合、そのポリシーはポイントカットを使用して、適用先の Mule アプリケーションのエンドポイントを決定します。 Mule アプリケーションコードで API 自動検出要素を宣言する必要がありますが、これと同様に、ポリシー内でポイントカットを宣言します。 Mule 4 では、ポイントカットはユーザーに表示されず、Mule ゲートウェイと API Manager によって内部的に管理されるのみです。 ほとんどの場合、ポリシーを設定するときに、ポイントカットの粒度を選択できます。この設定は、ポリシーの ​**\[Method & Resource conditions (メソッドおよびリソースの条件)\]**​ の下にあります。 2 つの使用可能なオプションがあります。 - **Apply configurations to all API methods & resources (設定をすべての API メソッドおよびリソースに適用)**​。 ![設定を API メソッドおよびリソースに適用するオプションが表示されたフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/api-gateway-capabilities-mule4-40081.png) 選択した場合、API ポイントカットは、API のすべてのリソースとメソッドに一致します。つまり、適用されるポリシーは、(自動検出を介して API にリンクされている) HTTP リスナーで受信された要求ごとに実行されます。 - **Apply configurations to specific methods & resources (設定を特定のメソッドおよびリソースに適用)**​。 ![ユーザーが設定を API メソッドおよびリソースに適用できるフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/api-gateway-capabilities-mule4-2ed4e.png) これは、API のリソースレベルのポイントカットを定義します。この例では、ポリシーは、要求メソッドが GET の場合にのみ API に適用されます。必要に応じて、リソースに一致する正規表現を定義し、粒度をさらに細かくすることができます。 ## [](#mule-ゲートウェイ機能の有効化)Mule ゲートウェイ機能の有効化 Mule ゲートウェイの機能を利用するには、Mule Runtime と、コントロールプレーン (US または EU)、または Mule Private Cloud Edition で作成された組織との間で通信チャネルを確立します。 このように Mule Runtime を設定するには、Anypoint 組織のログイン情報を指定します。 実装に応じて、組織のログイン情報をランタイムに渡す方法がいくつかあります。 詳細は、​[「Mule Runtime 4 の組織のログイン情報の設定」](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-org-credentials-mule4)​または​[「Mule Runtime 3 の組織のログイン情報の設定」](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-org-credentials-mule3)​を参照してください。 ## [](#mule-gateway-hyperforce)Hyperforce の Mule ゲートウェイ Hyperforce では、Mule ゲートウェイのすべての機能がサポートされています。ただし、一部の API Manager の Hyperforce の制限は Mule ゲートウェイに影響します。詳細は、​[「API Manager on Hyperforce (Hyperforce での API Manager)」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#APIM-hyperforce)​を参照してください。 ### [](#hyperforce-の-mule-ゲートウェイプロキシ)Hyperforce の Mule ゲートウェイプロキシ Hyperforce では、すべての Mule ゲートウェイプロキシがサポートされています。次の表で、Hyperforce でサポートされているプロキシの最初のバージョンを確認してください。
プロキシ バージョン

HTTP および HTTPS プロキシ

2.1.0

REST プロキシ

2.2.1 および 3.2.1

WSDL プロキシ

2.2.1 および 3.1.1
### [](#hyperforce-の-mule-ゲートウェイポリシー)Hyperforce の Mule ゲートウェイポリシー Hyperforce では、すべての Mule ゲートウェイポリシーがサポートされています。次の表で、Hyperforce でサポートされているポリシー定義および実装の最初のバージョンを確認してください。
ポリシー 定義 実装

基本認証: LDAP

1.4.0

1.4.1

基本認証: シンプル

1.3.1

1.4.1

クライアント ID 適用

1.3.2

1.4.0

クロスオリジンリソース共有 (CORS)

1.3.1

1.4.1

ヘッダーの挿入

1.3.1

1.4.0

ヘッダーの削除

1.1.1

1.2.0

HTTP キャッシュ

1.1.0

1.1.0

IP 許可リスト

1.1.1

1.2.0

IP ブロックリスト

1.1.1

1.2.0

JSON 脅威保護

1.2.0

1.2.3

JWT 検証

1.4.0

1.4.1

メッセージログ

2.0.1

2.1.1

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

1.6.0

1.6.1

OpenAM OAuth 2.0 トークン適用

1.6.0

1.6.1

OpenID Connect OAuth 2.0 アクセストークン適用

1.6.0

1.6.1

PingFederate OAuth 2.0 トークン適用

1.6.0

1.6.1

レート制限

1.4.0

1.4.0

レート制限: SLA ベース

1.3.0

1.3.0

スパイク制御

1.2.1

1.3.1

XML 脅威保護

1.2.0

1.2.0
## [](#関連情報)関連情報 - [Mule ゲートウェイの API 自動検出の概念の確認](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-autodiscovery-overview) # Mule ゲートウェイメトリクスの収集 Mule ゲートウェイはデフォルトで有効になっており、ユーザーエクスペリエンスを改善するために関連する使用状況データを収集します。MuleSoft はこのデータを使用して、すべての顧客の Mule ゲートウェイ機能を均一に分析し、理解を深めます。Mule ゲートウェイによって収集されるメトリクスを次に示します。 - デプロイされたアプリケーション、API、およびポリシーの数と種別 - Mule ゲートウェイ関連の設定パラメーター - 処理された要求数に関する統計 ログイン情報やポリシー設定パラメーターなどの機密情報は収集されません。この機能は、Mule Runtime エンジンの 3.9.5、4.2.2、および 4.3.0 バージョンに含まれています。 ## [](#mule-ゲートウェイメトリクス収集の無効化)Mule ゲートウェイメトリクス収集の無効化 この設定を使用して機密情報が収集されることはありませんが、何らかの理由で無効にすることができます。この設定を無効にするには、​`wrapper.conf`​ ファイルに次のエントリを追加します。 `anypoint.platform.metrics_enabled=false` ## [](#log-analytics-event-data)Analytics イベントデータのログ記録 Mule ゲートウェイでは、受信 API 要求に関するデータを取得するために ​`INFO`​ API Analytics イベントログが提供されます。
API Analytics イベントログは 2024 年 2 月 1 日以降にリリースされた Mule Runtime バージョン 4.4.x および 4.5.x と Mule Rruntime バージョン 4.6.0 以降でのみサポートされます。
デフォルトでは、​`anypoint.platform.log_analytics_events=false`​ になっています。次のエントリを ​`wrapper.conf`​ ファイルに追加してイベントログを有効にします。 ```conf anypoint.platform.log_analytics_events=true ```
追加のログ生成を行うため、イベントログは要求処理のパフォーマンスに影響する場合もあります。
ログは次の形式で表示されます。 com.mulesoft.mule.runtime.gw.analytics.logger.AnalyticsHttpEventsLogger: {"api\_id":XX,"api\_version\_id":XX,"org\_id":"XXX","host\_id":"XXXX","client\_id":XXX,"transaction\_id":XXX,"received\_ts":"XXX","replied\_ts":"XXX","client\_ip":"XX","verb":"GET","path":"/backend","status\_code":200,"user\_agent":"XXX","request\_bytes":0,"response\_bytes":150,"request\_disposition":"XXX","policy\_violation":null,"event\_id":"XXX","deployment\_type":null} ## [](#ログの管理とトラブルシューティング)ログの管理とトラブルシューティング メトリクス収集プロセス中にエラーが発生した場合でも、Mule アプリケーションは他のタスクを完了できます。さらに、メトリクス収集に関連するすべてのエントリは、ログファイルが乱雑にならないように次のパッケージに ​`DEBUG`​ として記録されます。 - Mule 3 Runtime の場合: - `com.mulesoft.module.client.metrics` - `com.mulesoft.module.metrics` - Mule 4 Runtime の場合: `com.mulesoft.mule.runtime.gw.metrics` この機能で問題が発生した場合、次の手順を実行します。 1. MuleSoft サポートに連絡し、前のセクションにリストされているメトリクスログを提供します。 2. サポートが問題を解決できるまで、設定を無効にします。 # OAuth 2 ポリシー Anypoint Platform では、OAuth ソリューションをサーバー側 (HTTP Connector や Salesforce Connector を設定して、OAuth で保護されたサーバーにアクセスするなど) とクライアント側 (OAuth 2.0 ポリシーを適用し、独自の OAuth プロバイダーを通じてクライアントアプリケーションからの認証を適用するなど) の両方で操作できます。 次の OAuth プロバイダーとポリシーのペアを使用できます。
プロバイダー ポリシー名

PingFederate

PingFederate OAuth トークン適用。

OpenAM

OpenAM OAuth トークン適用。

動的クライアント登録に準拠する ID プロバイダー

OpenID Connect アクセストークン適用。

Mule OAuth 2.0

OAuth 2.0 アクセストークン適用。
動的クライアント登録に準拠する ID プロバイダーは、『OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1 (OpenID Connect 動的クライアント登録 1.0 の組み込みの正誤表セット 1)』に準拠している必要があります。 OAuth 2.0 ポリシーを適用する API は、Mule OAuth 2.0 プロバイダーを使用する HTTPS 通信をサポートしています。プロバイダーは、OAuth 2.0 ログイン情報の有効性を検証します。 ## [](#関連情報)関連情報 - [OpenID Connect Client Registration 1.0 incorporating errata set 1 (エラータセット 1 を含む OpenID Connect Client Registration 1.0)](https://openid.net/specs/openid-connect-registration-1_0.html) - [外部プロバイダーを使用した OAuth 2.0 アクセストークンの適用](#api-manager::external-oauth-2.0-token-validation-policy.adoc) - [SAML 2.0 および OpenID Connect プロバイダー](https://docs.mulesoft.com/jp/access-management/external-identity) # OAuth 2.0 トークン検証 API Manager で提供されている OAuth 2.0 ポリシーのいずれかを使用する場合、アクセススコープを設定できます。クライアントアプリケーションがそのログイン情報を使用してアクセスできるスコープを指定します。プロバイダー (OpenAM、OpenID Connect、PingFederate、または Mule プロバイダー) は、アプリケーションに対して定義されたスコープをサポートする必要があります。OpenAM、PingFederate、Mule プロバイダーまたは OpenID Connect トークンイントロスペクションエンドポイントで定義されているスコープの名前を把握し、Anypoint Platform でポリシーの設定と適用を行うときにその名前を文字列形式で入力する必要があります。スコープ名は大文字と小文字を区別します。 ポリシーを API に適用するには、ポリシーの一般的な適用手順を使用します。以下の手順に従って、省略可能なスコープと、必須のトークン検証エンドポイント URL を設定します。 ## [](#スコープ)スコープ 1. 省略可能な \[Scopes (スコープ)\] 項目には、サポートされる OAuth スコープのスペース区切りのリスト (​`read write`​ など) を入力します。スコープ名は大文字と小文字を区別します。 ![すべてのスコープを含むか任意のスコープを含むオプションと一緒にスコープ検証条件が表示されているフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/scopes-mule4.png) 2. 参照先の OAuth 2.0 プロバイダーアプリケーションで定義されている 1 つ以上のスコープに一致するスコープを指定します。 Mule OAuth 2.0 プロバイダーの場合、Mule プロバイダーでスコープが定義されていないときは、この項目を空白のままにします。API Console を使用して API をシミュレートする場合、スコープを空白のままにして、CORS ポリシーを適用します。 ## [](#アクセストークン検証エンドポイント-url)アクセストークン検証エンドポイント URL OAuth 2.0 アクセストークン適用ポリシーには、アクセストークン検証エンドポイント URL が必要です。この URL は、アクセストークンを検証するためにコールされるサービスを定義します。 ![アクセストークン検証エンドポイント URL のテキスト項目](/mulesoft/current/ja-jp/mule-gateway/_images/access-token.png) 必須の ​**\[Access Token validation endpoint url\]**​ 項目には、アクセストークンを付与するために使用する外部 OAuth 2.0 プロバイダーの URL (​`https://oauth2provider.cloudhub.io/validate`​ など) を入力します。 ![OAuth 2.0 アクセストークン適用ポリシーの設定が可能なフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/external-oauth-2_0-token-validation-policy-ba3c0.png) ## [](#関連情報)関連情報 - [ポリシーの適用](https://docs.mulesoft.com/jp/mule-gateway/policies-included-apply) - [サポートされる OAuth スコープ](https://tools.ietf.org/html/rfc6749#page-23) # OpenAM OAuth 2.0 トークン適用ポリシー

ポリシー名

OpenAM OAuth 2.0 トークン適用

概要

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

カテゴリ

セキュリティ

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

v3.8.0

返される状況コード

400 - 無効なトークン

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

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

500 - 認証サーバーからの不正応答、または WSDL SOAP 失敗エラー。
このポリシーは、OpenAM をクライアント管理ソリューションとして使用するように設定された統合組織でのみ使用できます。
## [](#概要)概要 OpenAM OAuth 2.0 トークン適用ポリシーでは、HTTP 要求で指定されたトークンが有効で、必要に応じて、要求された OAuth スコープが完了している場合にのみ、その HTTP 要求を許可することで、保護されたリソースへのアクセスが制限されます。 ポリシーは、OAuth 認証サーバーに接続してトークンを検証します。トークンは、​[OAuth ダンス](https://docs.mulesoft.com/jp/api-manager/latest/oauth-dance-about)​の実行時に、​[認証されたクライアントアプリケーション](https://docs.mulesoft.com/jp/api-manager/latest/api-contracts-landing-page)​のログイン情報を指定することで取得されます。 このポリシーを適用する前に、​[前提条件](https://docs.mulesoft.com/jp/api-manager/latest/about-configure-api-for-oauth)​をよく理解しておいてください。 ポリシーの適用時、必要に応じて、適用対象となる [OAuth 2.0 スコープ](https://tools.ietf.org/html/rfc6749#page-23)​のスペース区切りリストを定義できます。 OAuth 2.0 スコープは、OAuth によって保護されているリソースへのアクセスをさらに制限する手段です。READ、WRITE のような語や、組織のコンテキストで意味のあるその他の語 (例: CONTRACTOR、PUBLIC、​EMPLOYEES\_ONLY​ など) を定義できます。 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード OpenAM OAuth 2.0 トークン適用ポリシーは、Flex Gateway のローカルモードではサポートされません。 ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード OpenAM OAuth 2.0 トークン適用ポリシーは、Flex Gateway の接続モードではサポートされません。 ## [](#supported-grant-types-サポートされる付与種別)Supported Grant Types (サポートされる付与種別) OpenAM は 2 種類の OAuth クライアントをサポートしています。 - 機密クライアントは、ログイン情報を機密に保ちます。次の許可種別が含まれます。 - クライアントログイン情報 - 暗黙的 - リソースオーナー - 公開クライアントは、ログイン情報を他の関係者と共有します。次の許可種別が含まれます。 - 認証コード - 暗黙的 - リソースオーナー どちらの種類のクライアントも、RFC で定義されている 4 つの OAuth 許可種別のうち 3 つをサポートしています。このため、OpenAM クライアントの設定時には、4 つの許可種別のうち 3 つのみ選択できます。残りの許可種別は、もう一方のクライアントに属しているため使用できません。選択した許可種別に応じて、OpenAM クライアントのプロパティを公開または機密のどちらにするかを決定します。 ## [](#performance-パフォーマンス)Performance (パフォーマンス) パフォーマンス向上のために、トークンが検証されると、デフォルトでは、システムによってトークンが有効期限までキャッシュされます。たとえば、トークンが失効するシナリオを考慮するときなど、このキャッシュメカニズムの制限や無効化が必要になる場合があります。 トークンキャッシュ時間 (OAuth プロバイダーに対して検証を再試行するまでのトークンキャッシュ時間) を制御する場合、次のプロパティを指定できます。 anypoint.platform.max\_federation\_expiration\_time= ## [](#プロキシを介した-oauth-プロバイダーへの接続)プロキシを介した OAuth プロバイダーへの接続 OpenAM OAuth 2.0 トークン適用ポリシーが Gateway プロキシ設定を使用できるようにするには、次のプロパティを指定します。 anypoint.platform.external\_authentication\_provider\_enable\_proxy\_settings= 上記のプロパティを true に設定すると、ポリシーがランタイムプロキシ設定を使用します (指定されている場合)。次に例を示します。 anypoint.platform.proxy\_host=localhost anypoint.platform.proxy\_port=8080 ## [](#oauth-プロバイダー情報の利用)OAuth プロバイダー情報の利用 トークンが OAuth プロバイダーによって正常に検証されると、プロバイダーはトークン検証を要求したポリシーに、OpenAM 側で設定可能な項目を含む追加の情報を返送します。 認証サーバーからのトークン検証応答: ```text { "uid":"john.doe", "mail":"john.doe@example.com", "scope":["uid","mail","cn","givenName"], "grant_type":"password", "cn":"John Doe", "realm":"/", "token_type":"Bearer", "expires_in":3600, "givenName":"John", "access_token":"fa017a0e-1bd5-214c-b19d-03efe9f9847e" } ``` OAuth プロバイダーから返された項目はポリシーで処理され、さらに次のように処理されます。 - 項目ごとに、元の保護されたリソースへの要求が「​`X-AGW-`​ + キー = 値」形式の HTTP ヘッダーで強化されます。 - \[Mule 4\] ポリシー設定の一部として、\[Expose Headers (ヘッダーを公開)\] をオフにすることもできます。その場合、要求は ​`X-AGW`​ ヘッダーで強化​**されません**​。 - フロー内の以降の処理では、プロバイダーからの元の解析していない応答を使用できます。 - \[Mule 3\] フロー変数 ​`['_agwUser']`​ がセットアップされます。マップ内の特定の値にアクセスするには、MEL 式を使用して直接指定します。次に例を示します。 #\[flowVars\['\_agwUser'\]\['mail'\]\] - \[Mule 4\] 情報は ​`authentication`​ オブジェクトに保存されます。mail (メール) 項目が返されるとすると、その値には次の DataWeave 2.0 式を使用してアクセスできます。 #\[authentication.properties.userProperties.mail\]
追加情報を使用してビジネスロジックをさらに調整できます。
## [](#関連情報)関連情報 - [クライアントアプリケーションとコントラクト](https://docs.mulesoft.com/jp/api-manager/latest/api-contracts-landing-page) - [OAuth 2.0 ポリシーの前提条件](https://docs.mulesoft.com/jp/api-manager/latest/about-configure-api-for-oauth) - [OAuth 2.0 ダンスと OAuth 2.0 アクセストークン適用](https://docs.mulesoft.com/jp/api-manager/latest/oauth-dance-about) - [OAuth 2.0 トークン検証ポリシーの適用](https://docs.mulesoft.com/jp/mule-gateway/policies-included-oauth-access-token-enforcement) - [ポリシーの適用](https://docs.mulesoft.com/jp/mule-gateway/policies-included-apply) - [OpenAM](https://www.openidentityplatform.org/openam)​ ID プロバイダー - [SAML 2.0](https://docs.mulesoft.com/jp/access-management/external-identity#instructions-for-saml-configuration) - [Mule 4 アプリケーションでの Mule ゲートウェイの API 自動検出の設定](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-config-autodiscovery-mule4) - [Mule 3 アプリケーションでの Mule ゲートウェイの API 自動検出の設定](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-config-autodiscovery-mule3) # OpenAM OAuth 2.0 トークン適用ポリシー Anypoint Platform で API に適用する適用ポリシーは、OpenAM 認証サーバー、OpenID Connect トークンイントロスペクションエンドポイント、または PingFederate 認証サーバーに接続します。ポリシーは、次の設定に従ってアクセス権を適用します。 - アクセス権のスコープ (省略可能) - OAuth クライアント - 認証サーバーへのプロキシ接続 ポリシーを API に適用するには、ポリシーの一般的な適用手順を使用します。アクセス権のスコープは、ポリシーを適用するときに設定します。設定タスクに加えて、アクセストークンを要求するユーザーのログイン情報の検証を実装できます。 ## [](#前提条件)前提条件 - Anypoint Platform 組織が、OpenAM、OpenID Connect、PingFederate のいずれかを使用して統合組織としてセットアップされていること。 - ユーザーが Anypoint Platform 組織のシステム管理者であるか、API を作成または管理する権限を持っていること。 ## [](#pingfederate-と-openam-の-oauth-クライアントと許可種別)PingFederate と OpenAM の OAuth クライアントと許可種別 OpenAM は 2 種類の OAuth クライアントをサポートしています。 - 機密クライアントは、ログイン情報を機密に保ちます。次の許可種別が含まれます。 - クライアントログイン情報 - 暗黙的 - Password (パスワード) - 公開クライアントは、ログイン情報を他の関係者と共有します。次の許可種別が含まれます。 - 認証コード - 暗黙的 - Password (パスワード) 各クライアント種別は、4 つの OAuth 許可種別のうちの 3 つをサポートしています。このため、OpenAM クライアントの設定時には、4 つの許可種別のうち 3 つのみ選択できます。残りの許可種別は、もう一方のクライアントに属しているため使用できません。選択した許可種別に応じて、OpenAM クライアントのプロパティを公開または機密のどちらにするかを決定します。 PingFederate クライアントでは、OAuth 許可種別の任意の組み合わせを使用できます。許可種別には、暗黙的、クライアントログイン情報、リソースオーナーのパスワードログイン情報、認証コードがあります。PingFederate ユーザーは、自由な順序で許可種別を有効または無効にできます。 ## [](#ユーザー検証)ユーザー検証 API には、アクセストークンを要求するユーザーのログイン情報のチェックを含めることができます。MEL 式を使用して、有効なトークンに関連付けられているユーザー情報のマップにアクセスします。フロー変数 ​`['_agwUser']`​ を使用します。マップ内の特定の値にアクセスするには、値を直接指定します。 次の例は、アプリケーションを使用して API をコールしているエンドユーザーのユーザー ID にアクセスします。 `#[flowVars['_agwUser']['uid']]`
_agwUser マップキー 説明

uid

アプリケーションを使用して API をコールしているエンドユーザーのユーザー ID。

グループ

ユーザーが関連付けられているグループの配列。

email (メール)

ユーザーのメール。
## [](#ユーザーログイン情報の取得)ユーザーログイン情報の取得 ポリシーは、アウトバウンドプロパティが含まれる Mule メッセージを返します。アウトバウンドプロパティには、外部で認証されたどのユーザーまたはアプリケーションが API を使用しているかに関する情報が含まれます。受信要求トークンの許可種別に応じて、これは異なるヘッダー内で表されます。 - 要求のトークンの許可種別が、リソースオーナーのログイン情報、暗黙的、認証コードの場合は、要求を実行したユーザーの ID がヘッダー X-AGW-userid に含まれます。 - 要求のトークンの許可種別が、クライアントのログイン情報の場合は、要求を実行したユーザーの ID がヘッダー ​`X-AGW-client_id`​ に含まれます。 2 つのプロパティのいずれかが参照可能で、フロー内の後続の任意のコンポーネントによってプロキシ内部で使用されます。 プロキシの出力を生成する HTTP Connector は、受信したすべてのアウトバウンドプロパティを HTTP メッセージヘッダーに変換します。プロキシを通過した後に API に到達したメッセージには、次のいずれかの HTTP ヘッダーが含まれています。 - ユーザー名を含む X-AGW-userid - クライアント ID を含む X-AGW-client\_id ### [](#トークン検証応答の例)トークン検証応答の例 次の例は、HTTP メッセージヘッダーを形成する、返された情報を示しています。 ```text HTTP/1.1 200 OK Cache-Control: no-cache, no-store Date: Mon, 09 Mar 2015 19:08:07 GMT Accept-Ranges: bytes Server: Restlet-Framework/2.1.1 Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept Content-Type: application/json;charset=UTF-8 Transfer-Encoding: chunked {"uid":"john.doe","mail":"john.doe@example.com","scope":["uid","mail","cn","givenName"],"grant_type":"password","cn":"John Doe Full","realm":"/","token_type":"Bearer","expires_in":580,"givenName":"John","access_token":"fa017a0e-1bd5-214c-b19d-03efe9f9847e"} ``` ## [](#ポリシーの実装)ポリシーの実装 次の図は、ポリシーが既存の OpenAM または PingFederate 認証サーバー、OpenID Connect トークンイントロスペクションエンドポイントと連携して API バージョンへのアクセスを保護するしくみを示しています。 ![API 認証プロセスのフローチャート図](/mulesoft/current/ja-jp/mule-gateway/_images/openam-oauth-token-enforcement-policy-0fbb9.png) - まず、クライアントアプリケーションは API コールを実行する前に認証サーバーから直接トークンを要求します。クライアントアプリケーションは、ユーザーログイン情報を使用して認証することによって、この要求を行います。 - サーバーはクライアントアプリケーションに有効なトークンを提供します。 - 次に、クライアントアプリケーションは、有効なトークンを API コール内で送信します。 - Mule は、OpenAM、OpenID Connect、または PingFederate OAuth トークン適用ポリシーによって制御され、ヘッダーまたはクエリパラメーター内のトークンが有効で、正しいスコープに一致していることを確認します。 - ポリシーは OpenAM 認証サーバー、OpenID Connect トークンイントロスペクションエンドポイント、または PingFederate 認証サーバーを呼び出して、トークンを検証し、スコープを確認します。 - 最後に、API はクライアントアプリケーションからコールを受信します。 パフォーマンス向上のために、Mule では認証サーバーへのコールがキャッシュされ、トークンの存続期間中に 1 回だけ実行されます。OAuth トークンが有効でない場合、認証サーバーはエラーを返します。次に例を示します。 - OpenAM 11.0.0 は ​`404 NOT FOUND`​ を返します。 - OpenAM 12.0.0 は ​`400 BAD REQUEST`​ を返します。 - PingFederate は ​`403 FORBIDDEN`​ を返します。 ## [](#関連情報)関連情報 - [api-manager::apply-oauth-token-policy-task.adoc](#api-manager::apply-oauth-token-policy-task.adoc) - [ポリシーの適用](https://docs.mulesoft.com/jp/mule-gateway/policies-included-apply) - [SAML 2.0](https://docs.mulesoft.com/jp/access-management/external-identity#instructions-for-saml-configuration) # OpenID Connect OAuth 2.0 トークン適用ポリシー

ポリシー名

OpenID Connect OAuth 2.0 トークン適用

概要

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

カテゴリ

セキュリティ

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

v4.1.1

返される状況コード

400 - 無効なトークン

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

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

500 - 認証サーバーからの不正応答、または WSDL SOAP 失敗エラー (Mule のみ)。
## [](#概要)概要 OpenID Connect アクセストークン適用ポリシーは、保護されたリソースへのアクセスを、API アクセス権を持つクライアントアプリケーションに属する有効な Oauth2 トークンを提供する HTTP 要求に制限します。このポリシーはトークンを生成せず、トークンを検証するだけです。 このポリシーは、​[クライアント管理ソリューション](https://docs.mulesoft.com/jp/access-management/configure-client-management-openid-task)​として OpenID Connect 動的クライアント登録を使用するように設定されている組織でのみ使用できます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#mule-ゲートウェイ)Mule ゲートウェイ UI からポリシーを API に適用するときに、環境に Mule アプリケーションがあるかどうかに基づいて、パラメーターのリストが表示されます。 #### [](#mule-アプリケーションと-flex-gateway-のパラメーターの設定)Mule アプリケーションと Flex Gateway のパラメーターの設定 次のパラメーターが表示されます。
要素 説明 例

Scopes (スコープ)

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

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, and READ AND WRITE​ を持つトークンが受け入れられます。

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

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

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

Expose Headers (ヘッダーを公開)

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

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

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

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

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

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

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

10000
#### [](#非-mule-アプリケーションのパラメーターの設定-anypoint-service-mesh)非 Mule アプリケーションのパラメーターの設定 (Anypoint Service Mesh) Anypoint Service Mesh によって管理される非 Mule アプリケーションの場合、次のパラメーターが表示されます。
要素 説明 例

Scopes (スコープ)

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

READ​、​WRITE​、​READ AND WRITE

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

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

選択した場合、​「ポリシーのしくみ」​セクションの図のステップ 4 はスキップされます。
## [](#how-this-policy-works)ポリシーのしくみ 次の図は、OpenID Connect アクセストークン適用ポリシーワークフローを示しています。 ![OpenID Connect ポリシーを介して API とやり取りするユーザーのプロセスを示すフローチャート](/mulesoft/current/ja-jp/mule-gateway/_images/open-id-policy-workflow.png) この図には次の動作が示されています。 1. ユーザーが最初にポリシーで保護された API に HTTP 要求を送信します。 2. ポリシーは要求からトークンを抽出し、それを検証エンドポイントに送信して、トークンの整合性を検証します。 3. トークン検証エンドポイントは、クライアントアプリケーションのクライアント ID を含むトークンメタデータを返します。 4. ポリシーは Anypoint Platform から以前に取得したコントラクトで更新されたローカルデータベースを使用して、クライアント ID が API にアクセスできるかどうかを検証します。 5. すべての検証が正常に完了すると、要求はバックエンドに到達できます。 ### [](#leveraging-TVE-information)Mule アプリケーションのトークン検証エンドポイント情報の活用 トークン検証エンドポイントで正常にトークンが検証されると、特定の情報 (OpenID Connect の設定可能な項目など) がポリシーに返されます。 次の例は、認証サーバーからのトークン検証応答を示しています: ```text --- { "uid":"john.doe", "mail":"john.doe@example.com" "token_type":"Bearer", "exp": 1516239022 "alias" : ["Jhon", "Jhonny", "Mr Doe"], "address" : { "city": "london", "road": “abbey road" } } --- ``` OAuth プロバイダーによって返された項目はポリシーによって処理され、Mule フロー全体に伝播され、アクセスを要求しているアプリケーションが HTTP リクエスターを使用している場合は最終的にバックエンドに公開されます。 ### [](#token-caching)トークンキャッシュ システムがトークンを検証すると、そのトークンは (デフォルトで) 期限切れになるまでキャッシュされるため、ポリシーのパフォーマンスが向上します。失効したトークンなどの特定のケースでは、キャッシュを最小限に抑えたり無効にしたりできます。 検証エンドポイントは、トークンの有効期限などの複数のプロパティをポリシーに送信します。有効期限情報がない場合、トークンはキャッシュされません。 トークンのキャッシュにかかる時間を制御するには、トークン検証エンドポイントに対して再検証を試みる前に、Engine でこの設定を行います。 - **Mule**​: Mule Runtime Engine を起動するときに次のプロパティを指定します。 ​\`anypoint.platform.max\_federation\_expiration\_time=\` または、​`wrapper.conf`​ ファイルでこのパラメーターを指定できます。 - **Flex Gateway**​: YAML ポリシー設定ファイルでこのプロパティを指定します。 \---- - policyRef: name: openidconnect-access-token-enforcement-flex config: ... maxFederationExpirationTime: ---- このプロパティを設定すると、指定された時間、またはトークンが期限切れになるまでのいずれか早い方でトークンがキャッシュされます。このプロパティが有効で、検証エンドポイントが有効期限情報を送信しない場合、トークンはキャッシュされません。 同時にキャッシュできるトークン数を制御するには、Engine で次の設定を行います。 - **Mule**​: Mule Runtime Engine を起動するときに次のプロパティを指定します。 ​\`anypoint.platform.openid\_connect\_cache\_max\_size=\` または、​`wrapper.conf`​ ファイルでこのパラメーターを指定できます。 - **Flex Gateway**​: YAML ポリシー設定ファイルでこのプロパティを指定します。 \---- - policyRef: name: openidconnect-access-token-enforcement-flex config: ... maxCacheSize: ---- ### [](#token-validation-endpoint-authentication)トークン検証エンドポイント認証 指定されたトークンの検証が完了すると、ポリシーは要求を検証エンドポイントに送信します。次に、ポリシーは OAuth 2.0 認証フレームワーク仕様の「Token Introspection Client (トークンイントロスペクションクライアント)」セクションに従って、アクセス管理のクライアントプロバイダー設定からログイン情報を取得します。これらのログイン情報は、 [OAuth 2.0 認証フレームワーク仕様の「Client Authentication (クライアント認証)」セクション](https://tools.ietf.org/html/rfc6749#section-2.3)​で指定されているようにリクエストボディで送信されます。 トークン検証エンドポイントの認証方法は、現在サポートされていません。 ## [](#expose-headers-ヘッダーを公開-オプションの設定)Expose Headers (ヘッダーを公開) オプションの設定 ポリシーで ​`Expose Headers`​ オプションを設定し、アプリケーション (標準のプロキシなど) が HTTP リクエスターを使用している場合、プロパティはヘッダーとしてバックエンドにリダイレクトされます。 項目ごとに、元の保護されたリソースへの要求が「X-AGW- + =」形式を使用する HTTP ヘッダーで強化されます。前のセクションの応答例では、次のヘッダーが追加されています。 ```text --- X-AGW-uid=john.doe X-AGW-mail=john.doe@example.com X-AGW-token_type=Bearer --- ``` 伝播されたプロパティには、​`scope`​、​`exp`​ オブジェクトおよび配列は含まれません。 フロー内の以降の処理では、検証エンドポイントからの元の解析していない応答を使用できます。情報は認証オブジェクトに保存されます。 たとえば、​`mail`​ 項目がポリシーに返される場合、次の DataWeave 2.0 式を使用して項目の値にアクセスできます。 `#[authentication.properties.userProperties.mail]` 次の DataWeave 2.0 式を使用して、OAuth2 トークンのクライアント ID を取得できます。 `#[authentication.principal]` ## [](#プロキシを使用したトークン検証エンドポイントとの通信)プロキシを使用したトークン検証エンドポイントとの通信 OpenID Connect OAuth 2.0 トークン適用ポリシーでゲートウェイプロキシ設定を使用できるようにするには、Mule Runtime Engine の開始時に次のプロパティを指定します。 `anypoint.platform.external_authentication_provider_enable_proxy_settings=` 次のパラメーターを指定している場合、このプロパティを有効にすると、ポリシーは Mule プロキシ設定を使用します。 - `anypoint.platform.proxy_host=localhost` - `anypoint.platform.proxy_port=8080` ## [](#faq)FAQ **API に適用するポリシーのリストに OpenID Connect アクセストークン適用ポリシーが表示されない。** ポリシーリストにポリシーが表示されない場合、アクセス管理で OpenID クライアントプロバイダーを設定していることを確認します。詳細は、​[「OpenID Connect クライアント管理を設定する」](https://docs.mulesoft.com/jp/access-management/configure-client-management-openid-task)​を参照してください。​[複数のクライアントプロバイダー](https://docs.mulesoft.com/jp/api-manager/latest/configure-multiple-credential-providers)​を使用している場合、API で OpenID Connect クライアントが正しく設定されていることを確認します。 **ポリシーで OAuth 2.0 トークンを生成できますか?** いいえ。 ポリシーはトークンの検証のみを行います。 **Mule OAuth プロバイダー検証エンドポイントがポリシーによって送信された要求を拒否している場合はどうすればよいですか?** OpenID Connect サーバーから提供される検証エンドポイントドキュメントを参照し、​[「トークン検証エンドポイント認証」](#token-validation-endpoint-authentication)​セクションに記載されている認証方法がサポートされているかどうかを確認します。 **ポリシーは検証エンドポイントと通信するためのログイン情報をどのように管理しますか?** この情報は、ポリシー設定に含まれており、ディスクに保存されます。この情報を暗号化して保存する場合、​[ランタイムでゲートウェイ暗号化を設定します](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-encryption-mule4)​。 **OAuth トークンはどのようにキャッシュされますか?** OAuth 2.0 トークンはメモリにのみキャッシュされ、ディスクに書き込まれることはありません。 **ポリシーは要求ごとに Anypoint Platform と通信しますか?** いいえ。ポリシーは以前に Engine によって取得されたクライアントアプリケーションを使用します。 これにより、管理プレーンとの接続が失われた場合でも、ポリシーが機能し続けます。ディスクに書き込まれるクライアントアプリケーション情報を暗号化する場合は、​[ランタイムでゲートウェイ暗号化を設定します](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-encryption-mule4)​。 **OpenID Connect アクセストークン適用ポリシーを設定した後にレート制限 SLA ポリシーを設定できますか?** はい、できます。OpenID Connect アクセストークン適用ポリシーの後にレート制限 SLA ポリシーを適用し、次の DataWeave 2.0 式を使用して \[​`Client ID Expression`​ (クライアント ID 式)\] の値を指定します。 `#[authentication.principal]` リクエスターの ID はすでに OpenID Connect アクセストークン適用ポリシーで検証されているため、\[​`Client Secret Expression`​ (クライアントシークレット式)\] 項目は空のままにできます。 **トークンが検証された後に、トークンに関連付けられた情報をどこで確認できますか?**​ この情報は認証オブジェクトにあります。詳細は、​[「Mule アプリケーションのトークン検証エンドポイント情報」](#leveraging-TVE-information)​を参照してください。 # PingFederate OAuth 2.0 トークン適用ポリシー

ポリシー名

PingFederate OAuth 2.0 トークン適用

概要

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

カテゴリ

セキュリティ

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

v4.1.1

返される状況コード

400 - 無効なトークン

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

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

500 - 認証サーバーからの不正応答、または WSDL SOAP 失敗エラー。
## [](#概要)概要 PingFederate OAuth 2.0 トークン適用ポリシーは、保護されたリソースへのアクセスを、API アクセス権を持つクライアントアプリケーションに属する有効な OAuth2 トークンを提供する HTTP 要求に制限します。このポリシーはトークンを生成せず、トークンを検証するだけです。 このポリシーは、​[クライアント管理ソリューションとして PingFederate を使用](https://docs.mulesoft.com/jp/access-management/conf-client-mgmt-pf-task)​するように設定されている組織でのみ使用できます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#mule-ゲートウェイ)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​ を持つトークンが受け入れられます。

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

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

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

Expose Headers (ヘッダーを公開)

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

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

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

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

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

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

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

10000
## [](#how-this-policy-works)ポリシーのしくみ 次の図は、PingFederate OAuth 2.0 トークン適用ポリシーワークフローを示しています。 ![PingFederate ポリシーを介して API とやり取りするユーザーのプロセスを示すフローチャート](/mulesoft/current/ja-jp/mule-gateway/_images/open-id-policy-workflow.png) この図には次の動作が示されています。 1. ユーザーが最初にポリシーで保護された API に HTTP 要求を送信します。 2. ポリシーは要求からトークンを抽出し、それを検証エンドポイントに送信して、トークンの整合性を検証します。 3. トークン検証エンドポイントは、クライアントアプリケーションのクライアント ID を含むトークンメタデータを返します。 4. ポリシーは Anypoint Platform から以前に取得したコントラクトで更新されたローカルデータベースを使用して、クライアント ID が API にアクセスできるかどうかを検証します。 5. すべての検証が正常に完了すると、要求はバックエンドに到達できます。 ### [](#leveraging-TVE-information)Mule アプリケーションのトークン検証エンドポイント情報の活用 トークン検証エンドポイントで正常にトークンが検証されると、特定の情報 (PingFederate の設定可能な項目など) がポリシーに返されます。 次の例は、認証サーバーからのトークン検証応答を示しています: ```text --- { "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=` または、​`wrapper.conf`​ ファイルでこのパラメーターを指定できます。このプロパティを設定すると、指定された時間、またはトークンが期限切れになるまでのいずれか早い方でトークンがキャッシュされます。このプロパティが有効で、検証エンドポイントが有効期限情報を送信しない場合、トークンはキャッシュされません。 同時にキャッシュできるトークンの数を制御するには、Mule Runtime Engine を起動するときに次のプロパティを指定します。 `anypoint.platform.ping_federate_cache_max_size=` または、​`wrapper.conf`​ ファイルでこのパラメーターを指定できます。 ## [](#expose-headers-ヘッダーを公開-オプションの設定)Expose Headers (ヘッダーを公開) オプションの設定 ポリシーで ​`Expose Headers`​ オプションを設定し、アプリケーション (標準のプロキシなど) が HTTP リクエスターを使用している場合、プロパティはヘッダーとしてバックエンドにリダイレクトされます。 項目ごとに、元の保護されたリソースへの要求が「​`X-AGW- + =`​」形式を使用する HTTP ヘッダーで強化されます。前のセクションの応答例では、次のヘッダーが追加されています。 ```text --- 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]` ## [](#プロキシを使用したトークン検証エンドポイントとの通信)プロキシを使用したトークン検証エンドポイントとの通信 PingFederate OAuth 2.0 トークン適用ポリシーでゲートウェイプロキシ設定を使用できるようにするには、Mule Runtime Engine の開始時に次のプロパティを指定します。 `anypoint.platform.external_authentication_provider_enable_proxy_settings=` 次のパラメーターを指定している場合、このプロパティを有効にすると、ポリシーは Mule プロキシ設定を使用します。 - `anypoint.platform.proxy_host=localhost` - `anypoint.platform.proxy_port=8080` ## [](#faqs)FAQs **API に適用するポリシーのリストに PingFederate OAuth 2.0 トークン適用ポリシーが表示されないのはなぜですか?** ポリシーリストにポリシーが表示されない場合、アクセス管理で PingFederate クライアントプロバイダーを設定していることを確認します。詳細は、​[「PingFederate クライアント管理を設定する」](https://docs.mulesoft.com/jp/access-management/conf-client-mgmt-pf-task)​を参照してください。​[複数の IDP](https://docs.mulesoft.com/jp/api-manager/latest/configure-multiple-credential-providers)​ を使用している場合、API で PingFederate クライアントが正しく設定されていることを確認します。 **ポリシーで OAuth2 トークンを生成できますか?** 番号ポリシーはトークンの検証のみを行います。 **ポリシーは検証エンドポイントと通信するためのログイン情報をどのように管理しますか?** この情報は、ポリシー設定に含まれており、ディスクに保存されます。この情報を暗号化して保存する場合、​[ランタイムでゲートウェイ暗号化を設定します](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-encryption-mule4)​。 **OAuth トークンがキャッシュされる場所は?** OAuth2 トークンはメモリにのみキャッシュされ、ディスクに書き込まれることはありません。 **ポリシーは要求ごとに Anypoint Platform と通信しますか?** いいえ。ポリシーは以前に Mule Runtime Engine によって取得されたクライアントアプリケーションを使用します。 これにより、コントロールプレーンとの接続が失われても、ポリシーは引き続き機能することができます。ディスクに書き込まれるクライアントアプリケーション情報を暗号化する場合は、​[ランタイムでゲートウェイ暗号化を設定します](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-encryption-mule4)​。 **PingFederate アクセストークン適用ポリシーを設定した後にレート制限 SLA ポリシーを設定できますか?** はい、できます。PingFederate アクセストークン適用ポリシーの後にレート制限 SLA ポリシーを適用し、次の DataWeave 2.0 式を使用して \[​`Client ID Expression`​ (クライアント ID 式)\] の値を指定します。 `#[authentication.principal]` リクエスターの ID はすでに PingFederate アクセストークン適用ポリシーで検証されているため、\[​`Client Secret Expression`​ (クライアントシークレット式)\] 項目は空のままにできます。 **トークンが検証された後に、トークンに関連付けられた情報をどこで確認できますか?**​ この情報は認証オブジェクトにあります。詳細は、​[「Mule アプリケーションのトークン検証エンドポイント情報」](#leveraging-TVE-information)​を参照してください。 ## [](#関連情報)関連情報 - [PingFederate](https://www.pingidentity.com/en/products/pingfederate.html)​ ID プロバイダー - [SAML 2.0](https://docs.mulesoft.com/jp/access-management/external-identity#instructions-for-saml-configuration) # RAML ベースの API の特性およびポリシーの概念 ユーザーが参照する必要がある RAML 定義を API が公開する場合、RAML 定義には、API に対するコールで想定されるすべての要素の詳細を確実に含める必要があります。たとえば、クライアント ID ベースのポリシーを適用すると、API に対するすべての要求にクライアント ID とクライアントシークレット (デフォルトでクエリパラメーターとして想定される) が含まれていることを意味します。ユーザー要求が却下されることを防止するため、RAML ルートに特性を作成し、API のすべての操作でこの特性を参照します。特性は次のようになります。 ```yaml traits: - client-id-required: queryParameters: client_id: type: string client_secret: type: string ``` 次に、個々の操作で次のようにこの特性を適用できます。 ```yaml /products: get: is: [client-id-required] description: Gets a list of all the inventory products. ``` 1. API ダッシュボードで \[Policies (ポリシー)\] をクリックします。 ポリシーリストの RAML スニペットリンクには、RAML に追加する必要がある RAML コードが含まれています。 ![API ポリシーの詳細が示されているテーブル](/mulesoft/current/ja-jp/mule-gateway/_images/raml-snippet.png) 2. \[RAML Snippet (RAML スニペット)\] をクリックします。 3. API RAML バージョンに合わせて、RAML 0.8 または RAML 1.0 を選択します。 4. API を編集してコードを追加します。 5. API を再デプロイします。 ## [](#関連情報)関連情報 - [提供ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-available-policies) # Rate Limiting and Throttling - SLA-Based Policies (レート制限および調整 - SLA ベースのポリシー) レート制限 - SLA ベースのポリシーと調整 - SLA ベースのポリシーは、クライアント ID ベースのポリシーで、ID を参照として使用して、各アプリケーションが一定期間内に実行できる要求の数を制限します。これらのポリシーを使用するには、1 つ以上の SLA 層を作成して、チュートリアルで説明されているように要求制限を定義します。API ユーザーを引き付けるために、API Portal を使用してユーザーがアプリケーションを登録することを義務付けます。登録プロセスによって、ユーザーにクライアント ID とクライアントシークレットが付与されます。 API をコールするアプリケーションを登録するユーザーからの要求に手動の承認が必要になるように SLA 層を設定できます。 ## [](#レート制限-sla-ベースのポリシー)レート制限 - SLA ベースのポリシー レート制限 (SLA ベース以外) では、特定の期間に API がすべてのアプリケーションから受け入れる要求の数を制限します。制限に達した後は、要求が拒否されます。ユーザーは、アプリケーションを登録したり、クライアント ID を送信したりする必要はありません。SLA ベースのレート制限では、アプリケーションによる API への要求の数を SLA 層の設定に基づいて制限します。デフォルトでは、クライアント ID とトークンのログイン情報は、client\_id と client\_secret というクエリパラメーターの形式で渡されることが想定されています。これを参照する Mule 式を変更し、これらの値を HTTP メッセージ内の別の場所から取得することもできます。 ## [](#調整-sla-ベースのポリシー)調整 - SLA ベースのポリシー SLA ベースの調整は、SLA ベースのレート制限と同じように機能しますが、SLA 制限を超えた要求が拒否されず、後で再処理するためにキューに登録されるという点が異なります。これらの要求は、設定に従って定期的に再試行され、最終的には要求が受け入れられるか再試行の最大回数に達したために拒否されます。 要求が受け入れられていない間の試行間隔を設定でき、試行回数を制限できます。 ## [](#sla-ベースのアプリケーション登録)SLA ベースのアプリケーション登録 API 用に SLA 層を少なくとも 1 つ作成すると、新しいアプリケーションからアクセスを要求するユーザーは、SLA 層を選択する必要があります。異なるレート制限や調整に基づいて複数の SLA 層の選択肢を提供できます。 ## [](#api-アクセス要求の管理)API アクセス要求の管理 選択された SLA 層が自動に設定されている場合、API Manager は API アクセスのすべての要求をただちに承認し、ユーザーはすぐに API に認証済み要求を送信できます。選択された SLA 層が手動承認に設定されている場合、ユーザーが API に有効な要求の送信を開始できるようにするには、組織のシステム管理者が承認する必要があります。 API アクセス要求を承認するには、API バージョンページに移動し、\[Applications (アプリケーション)\] を選択します。 ![アプリケーションの SLA 層と状況](/mulesoft/current/ja-jp/mule-gateway/_images/approve-applications.png) ここで、保留中の要求と処理済みの要求の詳細を確認し、管理できます。 ## [](#sla-層または階層-sla-の作成)SLA 層または階層 SLA の作成 まず、SLA 層を作成します。手動承認を選択すると、組織のシステム管理者がアプリケーションのアクセス要求を手動で承認する必要があります。 複数の SLA 制限は、次の条件の下でサポートされています。 - API Manager で API を管理している。 - Mule ゲートウェイランタイム 2.1 以降で API を管理している。 SLA 階層で、API ゲートウェイランタイム 2.1 より前のバージョンで実行される Mule に複数の制限が使用されている場合、最初に定義された制限のみが適用されます。 1 つの SLA 階層に複数のスループット制限を指定できます。 1. \[Add SLA Tier (SLA 層を追加)\] ダイアログの \[Limits (制限)\] で、最初の制限セットを設定します。 2. プラスアイコンをクリックし、次の制限セットを設定します。 次に例を示します。
# of Reqs (要求数) Time Period (期間) Time Unit (時間単位)

100

1

Second (秒)

10000

1

Day (日)
3. \[Add (追加)\] をクリックします。 gold という名前の 1 つの SLA 階層で、1 秒あたり 100 件の要求の制限と 1 日あたり 10,000 件の要求の制限を提供できます。この場合、Gold 層に登録されたアプリケーションが 100 要求/秒のバースティング制限を超えることはありません。登録されたアプリケーションでアドバタイズされた 10,000 要求/日の SLA が取得されると同時に、トラフィックのボトルネックが回避されます。表示フラグをオフにすることによって、100 件の要求という最初の制限は、登録時にアプリケーション開発者に公開されません。1 つの制限のみを設定した場合は、その制限を表示する必要があります。 ### [](#レスポンスヘッダー)レスポンスヘッダー 要求応答には、ユーザーに SLA 制限について通知し、しきい値に近づいたときに通知するための 3 つのヘッダーが含まれています。SLA が、要求スループットを制限する複数のポリシーを適用する場合、最も制限の厳しいポリシーに関する 1 つのヘッダーセットによってこの情報が提供されます。 たとえば、API のユーザーが次のヘッダーが含まれる応答を受信するとします。 X-RateLimit-Limit: 20 X-RateLimit-Remaining: 14 X-RateLimit-Reset: 19100 次の 19100 ミリ秒間に SLA によって許可される要求は 14 件のみです。この SLA はこの期間に 20 件の要求を許可するように設定されています。 ## [](#mule-クラスター内のレート制限と調整)Mule クラスター内のレート制限と調整 クラスター内のレート制限と調整のガイドラインが、SLA ベースのポリシーのレート制限と調整に適用されます。 ## [](#関連情報)関連情報 - [クラスターのレート制限の選択](https://docs.mulesoft.com/jp/mule-gateway/%3Chttps://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting#Choosing Between a Cluster or a Standalone Configuration>) - [クライアント ID ベースのポリシー](https://docs.mulesoft.com/gateway/latest/policies-included-client-id-enforcement) # URI テンプレート正規表現の設定 API によって公開されているリソースの一部にポリシーを適用する場合には、正規表現 (regex) を指定することで、複数のパスを含めることができます。正規表現の式は、ポリシーの ​**URI template regex**​ 項目で指定できます。 **URI template regex**​ を設定する場合は、アプリケーションを実装 (またはプロキシを使用) する Mule Runtime Engine (Mule) アプリケーションのベースパスを考慮する必要があります。その理由は、Mule 4 のリソースレベルポリシーは、API がデプロイされている場所に依存するためです。 この図は、ポリシーを適用するリソースサブセットを指定するメソッドのリストを示しています。 ![API エンドポイントと対応する GET および POST メソッドを示すリスト](/mulesoft/current/ja-jp/mule-gateway/_images/configure-regex-resources-list.png) この API 仕様は、次の Mule アプリケーションで実装されています。 ```xml ``` この例では、​`http:listener-config`​ は ​`basePath`​ 属性と、パス ​`v1/`**​ の最後にある ​**​ の前に追加パス v1 の両方を定義しています。これら 2 つのパスを連結した ​`/api/v1`​ が​_ベースパス_​として参照されます。 API ​`resource-1`​ の最初のリソースを呼び出すには、ベースパスをリソースパス ​`resource-1: [http://localhost:80/api/v1/resource-1](http://localhost:80/api/v1/resource-1)`​ と組み合わせて使用する必要があります。 以後、​`resource-1`​ をポリシーで保護するには、リソースレベルのポリシーを使用する必要があります。そのため、ポリシーを適用するときに指定する ​**URI テンプレート正規表現**​にはベースパスを含める必要があります。 **URI テンプレート正規表現**​の設定方法を下図に示します。 ![設定を特定の API メソッドおよびリソースに適用できるフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/configure-uri-regex-example.png) API のアセットタイプが RAML または OAS である場合、​`Preview Resource Matching`​ オプションは実際のランタイム動作とは異なり、どのリソースとも一致したとは示しません。 また、正規表現を使用することで、ベースパス (例: `.*/resource-1`​) を明示的に指定する必要がなくなります。ただし、同じ名前のリソースが API 定義の別のレベルにも存在する場合は、正規表現によってそれらすべてと一致してしまうため問題が発生します。つまり、正規表現が ​`/api/v1/resource-1`​ と ​`/api/v1/resources/resource-1`​ の両方と一致するため、結果が曖昧になってしまいます。 ## [](#ignorebasepath-を使用する状況)ignoreBasePath を使用する状況 リソースレベルのポリシーを適用するときにリソースのフルパスにベースパスを含めることで、設計時の API とランタイムの API が強制的に結合されます。これは、リソースレベルポリシーを適用するときには、API のデプロイ先となるベースパスを知る必要があるためです。 この結合の問題を回避するため、Mule 4.3.0 には新しい設定が追加され、Mule ポリシーエンジンが受信した HTTP 要求をポリシーの ​**URI テンプレート正規表現**​と一致させるときに、API リソースのベースパスを無視できるようになりました。 この設定は、API を実装する Mule アプリケーションで公開されます。 ```xml ``` `ignoreBasePath`​ 属性を ​`true`​ に設定すると、API のデプロイ先となるベースパスは考慮されなくなります。 ## [](#機能の前提条件)機能の前提条件 この機能を実装するには、Mule アプリケーションが次の条件を満足していることが必要です。 - Mule 4.3.0 で動作している - HTTP 用 Anypoint Connector (HTTP Connector) 1.5.15 以降を使用している 下位互換性を実現するため、この機能は属性が ​`true`​ に明示的に設定されない限り無効化されています。Mule アプリケーションがバージョン 4.3.0 より古い Mule で動作していて、リソースレベルのポリシーが正しく設定されている場合は、何も変更を行わなくても Mule 4.3.0 以降に移行できます。 API Manager で使用できる API プロキシの最新バージョンは、ベースパスを無視するように事前に設定されています。旧バージョンの API プロキシを使用して実装されている既存のリソースレベルポリシーとの互換性を保証するため、この機能を搭載した以下のメジャーバージョンの API プロキシがリリースされています。 - HTTP プロキシ 2.0.0 - HTTP プロキシ 3.0.0

Mule バージョン 4.2.x および 4.1.x ではリソースレベルのポリシーが互換モードで機能するため、これらのプロキシバージョンをデプロイすることはお勧めしません。これらのプロキシバージョンをデプロイする場合、Mule 4.3.x に移行する前に URI テンプレート設定を更新する必要があります。
## [](#機能の制限)機能の制限 ### [](#ベースパスの要件)ベースパスの要件 API のルートパスは、API のベースパスを計算できるように正しく定義されている必要があります。Mule アプリケーションで設定されている HTTP リスナーのパス属性の末尾が ​`*`​ であることを確認してください。そうでない場合は、​`ignoreBasePath`​ が ​`false`​ に設定されている場合と同じようにリソースレベルポリシーの一致が行われます。 ### [](#クエリパラメーターの除外)クエリパラメーターの除外 正規表現は要求の URI パスコンポーネントに対してのみ照合を行い、クエリパラメーターは考慮されません。たとえば、​`/api/products.*123`​ のような正規表現パターンは ​`/api/products/123`​ には一致しますが ​`/api/products?id=123`​ には一致しません。 ## [](#関連情報)関連情報 - [ポリシーの概要](https://docs.mulesoft.com/jp/mule-gateway/policies-policy-overview) # XML 脅威保護 XML アプリケーションへの悪意のある攻撃は、通常、大きな再帰ペイロード、XPath/XSLT または SQL インジェクション、CData を伴います。XML 脅威保護ポリシーを使用することで、XML コード内で最大ノード深度、テキストノードの長さなどのサイズを制限し、悪意のある攻撃を阻止できます。たとえば、CData からの侵入を防ぐためにコメントのサイズを制限できます。 ## [](#xml-アプリケーションの保護)XML アプリケーションの保護 XML アプリケーションを保護する手順を使用して、XML 脅威保護を設定します。 XML 脅威保護を設定します。制限を設定し、\[Apply (適用)\] をクリックして XML コードの保護を開始します。次の例は、XML 脅威保護ポリシーの設定を示しています。 ![xml threat policy](/mulesoft/current/ja-jp/mule-gateway/_images/xml-threat-policy.png) ## [](#xml-脅威保護ポリシーへの応答)XML 脅威保護ポリシーへの応答 - 200 メッセージが正常に送信されました。 - 400 Bad Request (400 不正な要求) 要求が、設定された制限に違反している場合は、「Bad Request (不正な要求)」エラーが発生します。 # XML 脅威保護ポリシー

ポリシー名

XML 脅威保護

概要

API 要求内の悪意のある XML から保護する

カテゴリ

セキュリティ

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

v3.8.0

返される状況コード

400 - Bad Request
## [](#概要)概要 XML 要求を処理するアプリケーションは、要素、属性、およびネストレベルの異常な膨張により特徴付けられる攻撃を受けやすくなっています。攻撃者は再帰的な技法を使用してメモリリソースをコンシュームします。多くの場合、アプリケーションデータのサイズが劇的に増加することは、セキュリティの問題が発生していることを示します。XML 脅威保護ポリシーは、このような侵入からアプリケーションを保護するのに役立ちます。 Anypoint Platform 環境への攻撃の検出が困難である場合は、XML 脅威保護に保護レイヤーを追加したサービスアーキテクチャを設計する必要があります。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード XML 脅威保護ポリシーは、Flex Gateway のローカルモードではサポートされません。 ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード XML 脅威保護ポリシーは、Flex Gateway の接続モードではサポートされません。 ### [](#mule-ゲートウェイ)Mule ゲートウェイ UI から XML 脅威保護ポリシーを API に適用するときに、以下のパラメーターが表示されます。

項目

説明

デフォルト

必須

Maximum Node Depth (最大ノード深度)

XML ドキュメントの最大ノード深度を指定します。

-1

false

Maximum Attribute Count Per Element (要素あたりの最大属性数)

要素の最大属性数を指定します。名前空間の定義で使用される属性は含まれません。

-1

false

Maximum Child Count (子の最大数)

子の最大数。XML ドキュメント内の要素の子の最大数を指定します。

-1

false

Maximum Text Length (最大テキスト長)

XML ドキュメントに含まれるテキストノードの最大長 (文字数) を指定します。

-1

false

Maximum Attribute Length (最大属性長)

XML ドキュメント内の属性の最大長 (文字数) を指定します。

-1

false

Maximum Comment Length (最大コメント長)

XML ドキュメント内のコメント文字の最大数を指定します。

-1

false
-1 の値は、項目値に制限がないことを意味します。
## [](#例)例 次のスクリーンショットは、XML 脅威保護ポリシーで設定されたパラメーターの例を示しています。 ![xml threat policy](/mulesoft/current/ja-jp/mule-gateway/_images/xml-threat-policy.png) # アウトバウンドポリシーの無効化 Mule 4 では、送信および受信 HTTP 要求の両方にポリシーを適用できます。 送信 HTTP 要求に適用されるポリシーはアウトバウンドポリシーと呼ばれます。アウトバウンドポリシーは、ポリシーテンプレートで ​`http-policy:operation`​ ブロックを定義して実行コンポーネントを指定することによって実装します。 Mule Runtime Engine は、API に適用されたすべてのポリシーの操作ブロックを、Mule アプリケーションで定義されているすべての HTTP リクエスター要素に適用します。 HTTP プロキシの場合は、アウトバウンドポリシーが適用される HTTP リクエスターが 1 つだけ定義されます。 API を実装する Mule アプリケーションはいくつかの外部サービスを呼び出す場合があるため、このような API では複数の HTTP リクエスターを定義できます。その場合、アウトバウンドポリシーは、アプリケーションが実行する各 HTTP 要求に適用されます。 次の例は、API を実装する Mule アプリケーションフローを示しています。 Mule アプリケーションが呼び出されるたびに、外部サービスに対して 2 つの HTTP 要求が実行されます。 次の例では、HTTP 要求にヘッダーを追加することで、前の例に Mule ポリシーが適用されています。 #\[{'new-header': 'the-value'}\] Mule アプリケーションが呼び出されるたびに、Mule ポリシーが 2 回 (​`service-1`​ を呼び出すときと ​`service-2`​ を呼び出すときに 1 回ずつ) 実行されます。各 HTTP 要求には、ポリシーによって追加された ​`new-header`​ というヘッダーが含まれます。 次に、​`service-1`​ が認証用に追加のヘッダーを必要としているのに対して、​`service-2`​ は予期しないヘッダーを持つ受信要求を拒否するというシナリオを考えてみましょう。 Mule 4.3.0 では、任意の Mule アプリケーションの HTTP リクエスターにアノテーション ​`api-gateway:disablePolicies="true"`​ を指定し、アノテーションが付けられたリクエスターに対しては Mule ポリシーエンジンがポリシーを実行しないようにすることで、これらの要件に対応できます。 アノテーション ​`api-gateway:disablePolicies="true"`​ を使用する場合は、アプリケーションで次の名前空間を指定する必要があります。 `xmlns:api-gateway="http://www.mulesoft.org/schema/mule/api-gateway"` その結果、アプリケーションフローは次のようになります。 `service-2`​ を呼び出す HTTP リクエスターでアノテーションを指定することで、ポリシーは適用されなくなります。したがって、その HTTP 要求には追加のヘッダーが付加されません。 アノテーションが付けられた Mule アプリケーションを 4.3.0 より前の Mule バージョンにデプロイした場合は、アノテーションは効果がなく、ポリシーは無効化されません。ただし、アプリケーションのデプロイは行われます。 ## [](#関連情報)関連情報 - [Mule 4 のポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-overview) # イベント認証拡張機能を使用したカスタムポリシーの開発 イベント認証拡張機能を使用して、Mule イベントの認証データでクライアント ID プロパティを伝播できます。イベント認証拡張機能を使用してカスタムポリシーを開発および実装するには、次の手順を理解する必要があります。 1. 提供された​[ユースケース](#use_case)​に基づいてユースケースを評価します。 2. [プロジェクトをセットアップします](#set-up-the-project)​。 3. [YAML 設定ファイルを作成します](#create_the_YAML)​。 4. [カスタムポリシーを実装します](#implement_the_policy)​。 5. [カスタムポリシーを Exchange にアップロードします](#upload_to_exchange)​。 6. [カスタムポリシーを適用します](#apply_custom_policy)​。 ## [](#use_case)ユースケース ProTeams は、ユーザーがチームやスポーツ活動を管理できるスポーツ管理アプリケーションです。ProTeams ユーザーは、他のチームとのチャットへの参加、エキシビションや親善試合の開催、トーナメントの日程の確認などのアクションをチームを代表して実行できます。 各チームの Anypoint Platform にはクライアントアプリケーションがあり、クライアント ID 適用ポリシーを使用してサイトへの要求を確認します。プレーヤーにはチーム管理タスクを非表示にするために、マネージャー用とプレーヤー用に別々の ID が作成されています。 チームオーナーとマネージャーは、必要に応じて特定のタスクでプレーヤーの代理を務めることができます。プレーヤーは、練習試合のセットアップやチームメンバーとのチャットメッセージの開始など、チームのタスクを実行することもできます。 すべてのユーザー ID はチームのクライアント ID にマップされているため、任意のユーザー ID で行われるすべてのトランザクションに伝播されます。クライアント ID が Mule イベントの認証データに挿入されると、Mule はクライアントアプリケーションの分析データを生成します。ProTeams はこのアプリケーション分析を使用して、アプリケーション内のチームトランザクションを確認します。 このプレーヤー ID とチームクライアント ID のマッピングを作成するには、チームオーナーが要求の ​`userId`​ というヘッダーからユーザー ID を取得する新しいカスタムポリシーを開発する必要があります。ユーザー ID は、クエリパラメーターを使用して取得することもできます。その後、ポリシーでマッピングを実行します。 ProTeams はこの例を出発点として使用し、独自のマッピングロジックを追加します。 ## [](#set-up-the-project)プロジェクトのセットアップ ProTeams は、最初に​[カスタムポリシーアーキタイププロジェクト](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-getting-started)​を作成することで、カスタムポリシーを開発します。次に、アーキタイプを実行し、この例に示されている値を置き換えます。 次に、ディレクトリをワークスペースにコピーし、​`pom.xml`​ ファイル内の ​`groupId`​ と ​`artifactId`​ の値を独自の値と一致させます。 - `_YOUR_GROUP_ID_`​ を ProTeams 組織 ID (この場合は ​`Group2234`​) に置き換える。 - `​_set-authentication-policy_​`​ を必要なアーティファクト ID (この場合は ​`map-to-authentication-policy`​) に置き換える。 さらに必要に応じて、バージョンや連動関係などの他の要素を追加または変更できます。 ## [](#create_the_YAML)YAML 設定ファイルの作成 ProTeams はプロジェクトをセットアップした後に、API Manager で設定するポリシーの入力パラメーターを定義することから始めます。 次のコードスニペットは、ポリシー UI の YAML ファイルの例を示しています。 ```YAML id: Map To Authentication name: Map To Authentication description: Maps input user identifier to the associated Client ID, and propagates it via the authentication data category: Custom type: custom resourceLevelSupported: true encryptionSupported: false standalone: true requiredCharacteristics: [] providedCharacteristics: [] configuration: - propertyName: userIdExpression name: User Identifier Expression description: Mule Expression used to extract the user identifier value from API requests type: expression defaultValue: "#[attributes.headers['fks_user_id']]" optional: false sensitive: false allowMultiple: false ``` この例では、YAML ファイルにはどの要求属性からユーザー ID を抽出するかを決定する 1 つの設定プロパティのみが含まれます。この設定プロパティは DataWeave 式項目です。 `name`​ および ​`description`​ パラメーターは、それぞれプロパティの表示タイトルと説明です。​`type`​ パラメーターは項目値が DataWeave 式である必要があることを示し、​`defaultValue`​ パラメーターはポリシーを設定するときに API Manager で推奨される項目値を指定します。​`optional`​ パラメーターは ​`false`​ に設定され、この項目が必須であることを示します。 YAML ファイルのセットアップ方法についての詳細は、​[「YAML 設定ファイル」](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-mule-4-reference#yaml-configuration-file)​を参照してください。 ## [](#implement_the_policy)ポリシーの実装 ProTeams はポリシーの入力パラメーターを定義した後に、次の手順でポリシーの実装を開始できます。 1. [Maven ​`settings.xml`​ ファイルに新しいサーバーを追加します](#add-server_in-settings)​。 2. [`pom.xml`​ ファイルに連動関係を追加します。](#add_dependencies_in_pom) 3. [`template.xml`​ ファイルに条件を追加します。](#add_conditions_in_template) イベント認証拡張機能は、Mule EE Nexus リポジトリにあります。この例の POM ファイルはリポジトリへの参照をすでに保持しており、​`releases-ee`​ というログイン情報の別名で設定されています。必要に応じて、この別名を変更できます。 ### [](#add-server_in-settings)settings.xml ファイルへのサーバーの追加 リポジトリにアクセスするため、ProTeams は Maven 設定ファイルに対応するサーバーを追加する必要があります。 ```XML releases-ee your_username your_password ``` ### [](#add_dependencies_in_pom)pom.xml ファイルへの連動関係の追加 Maven ​`settings.xml`​ ファイルに新しいサーバーを追加したら、ポリシーで特定のアクションを実行するために、ProTeams はイベント認証や HTTP ポリシートランスフォーム拡張機能などの連動関係を ​`pom.xml`​ ファイルに追加します。 ```XML com.mulesoft.anypoint mule-event-authentication-extension ${authenticationExtensionVersion} mule-plugin com.mulesoft.anypoint mule-http-policy-transform-extension ${httpPolicyTransformVersion} mule-plugin org.mule.connectors mule-http-connector ``` Java で独自のコネクタを作成する方法についての詳細は、​[「Java 用 Mule SDK 入門」](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​を参照してください。 ### [](#add_conditions_in_template)template.xml ファイルへの条件の追加 ProTeams は機能ロジックを ​`template.xml file`​ に追加して、ProTeams の ID マッピングなどのポリシーでタスクを実行できるようにする必要があります。 ProTeams の値マッピングは Mule 拡張では使用できないため、独自のカスタムモジュールを作成して追加する必要があります。 ## [](#upload_to_exchange)Exchange へのアップロード カスタムポリシーを Exchange にアップロードするため、ProTeams は ​`pom.xml`​ ファイルが組織用に適切に設定されていることを確認する必要があります。 ### [](#タスクの前提条件)タスクの前提条件 ポリシーを Exchange にアップロードする前に、ProTeams は次のことを確認する必要があります。 - 一意の ID、および組織の Exchange ログイン情報のユーザー名とパスワードを使用して、Maven ​`settings.xml`​ ファイルに新しいサーバーが作成されている。 - URL が自分の地域と一致する。 **警告:**​ 同様のアクションを実行して独自のカスタムポリシーを作成する場合、テンプレートは米国地域に対応する URL を使用していることに注意してください。アカウントがこの地域に属していない場合は、この値を変更します。 - リポジトリ ID が Maven 設定の ID と一致する。 name タグを使用して、そのリポジトリの別名を定義できます。 ポリシーを Exchange にアップロードする手順は、次のとおりです。 1. ポリシー ​`pom.xml`​ ファイルに移動して distributionManagement\` セクションを​`見つけます`​。 ```XML your_server_id My Repository ${exchange.url} default ``` 2. サーバー設定を確認したら、次のコマンドを使用して Exchange へのポリシーのアップロードを開始します。 ```console > mvn deploy ``` これで、ProTeams が開発したカスタムポリシーが Exchange にアップロードされました。 ## [](#apply_custom_policy)ポリシーの適用 次に、ProTeams はデフォルトポリシーを適用するのと同じ方法でカスタムポリシーを適用します。API Manager に移動すると、使用可能な新しいポリシーが表示され、設定して使用できます。 完全なカスタムポリシーの例を表示するには、Github リポジトリ [「Custom Policies Examples (カスタムポリシーの例)」](https://github.com/mulesoft/api-gateway-custom-policies-examples)​を参照してください。 # オフラインカスタムポリシー オフラインカスタムポリシーの管理については、以下のトピックを参照してください。 - [オフラインカスタムポリシーの適用](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-offline-apply) - [オフラインカスタムポリシーの削除](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-offline-remove) # オフラインカスタムポリシーの削除 オフラインポリシーを削除するには、オフラインポリシーディレクトリに作成した JSON ファイルを削除する必要があります。ポリシーディレクトリに自動的に作成されたフォルダーを削除しても、オフラインポリシーは削除​_されません_​。 ## [](#関連情報)関連情報 - [オフラインカスタムポリシーの適用](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-offline-apply) # オフラインカスタムポリシーの適用 オフラインポリシーは、API Manager 経由ではなく、ランタイムに直接適用されます。 offline-policies ディレクトリにファイルを作成すると、Mule Runtime Engine (Mule) はファイルの存在を検出して、ポリシーの適用を開始します。 そして Mule は、JSON および XML ポリシーファイルを ​`%MULE_HOME%/policies`​ の新しいディレクトリ内に生成します。 ## [](#タスクの前提条件)タスクの前提条件 オフラインカスタムポリシーを適用する前に、以下を確認してください。 - [Mule ゲートウェイ機能](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-capabilities-mule4)​が有効化された状態で Mule Runtime Engine (Mule) がインストールされている。 - 基本エンドポイントまたはプロキシエンドポイントが設定された ​[API](https://docs.mulesoft.com/jp/api-manager/latest/api-instance-landing-page)​ が API Manager 内に存在する。 - 自動検出によって API にリンクされている ​[HTTP(S) ベースフロー](https://docs.mulesoft.com/jp/http-connector/1.10/http-listener-ref)​で Mule アプリケーションがデプロイされている。 Mule アプリケーション内で自動検出が正しく設定されている場合、アプリケーションの API は API Manager によって追跡されている、または API Manager にペアリングされているとみなすことができます。 ## [](#オフラインカスタムポリシーの適用)オフラインカスタムポリシーの適用 オフラインカスタムポリシーを適用する手順は次のとおりです。 1. 何らかの理由で Exchange からのポリシーテンプレートを使用しない場合は、オフラインポリシーを API に適用する前に、テンプレート JAR を次のディレクトリに配置してください。 `%MULE_HOME%/policies/policy-templates` 2. ポリシー設定を定義する JSON ファイルを ​`%MULE_HOME%/policies/offline-policies`​ ディレクトリに作成します。 3. ポリシー ID に基づいて JSON ファイルに名前を付けます。 4. ファイルに次の設定と仕様を含めます。 - ポリシーテンプレート情報 オフラインポリシー定義のデプロイに使用するテンプレートの Exchange グループ ID、アセット ID、およびバージョンを指定します。 - ポリシーを適用する API の ID - ポリシーを適用するリソースのリスト - ポリシーの順序 - 定義されているテンプレートが handlebars 変数を使用する場合はパラメーター 次の例は、典型的なオフラインポリシー定義を示します。 { "template" : { "groupId" : "com.mulesoft.anypoint", "assetId" : "policyTemplate", "version" : "0.1.0" }, "api": \[ { "id": "1" }, { "id": "2" } \], "order": 1, "configuration" : { "payload" : "Payload" } } 5. カスタムオフラインポリシーを適用した後は、Runtime Engine (Mule) ファイルシステムに手動でデプロイする必要があります。 ## [](#関連情報)関連情報 - [オフラインカスタムポリシーの削除](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-offline-remove) # オンラインカスタムポリシーの管理 オンラインカスタムポリシーの開発と管理については、以下のトピックを参照してください。 - [カスタムポリシーのパッケージ化](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-package) - [Exchange へのカスタムポリシーのアップロード](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-upload-to-exchange) - [HTTP ポリシーの Transform 拡張概念の確認](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-http-transform) - [Mule 4 のカスタムポリシーのキャッシュ](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-mule-4-caching) # カスタムポリシー ポリシーは、セキュリティの管理、トラフィックの制御、API の適応性の向上に役立つ規制を適用します。たとえば、ポリシーによって認証、アクセス、サービスレベルアクセス (SLA) を制御できます。特定のビジネス要件に基づいてカスタムポリシーを作成して API に適用することで、既存の機能を拡張したり、新しい機能を定義したりできます。 Mule 4 以前のカスタムポリシーを Anypoint API Manager で作成するためのワークフローは変更されていません。これまでと同じように、ポリシーを開発し、カスタムポリシーをパッケージ化して Exchange にアップロードしてから、Anypoint API Manager のドキュメントに説明されているように Anypoint API Manager を使用してポリシーを API に適用します。 詳細は以下を参照してください。 - [Mule 4 カスタムポリシーのパブリッシュ](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-mule-getting-started) - [Mule 4 カスタムポリシーワークフロー](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-getting-started) - [オフラインカスタムポリシーの管理](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-manage-offline) - [Mule 3 カスタムポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-custom-policies) # カスタムポリシー ポリシーのデフォルトセットに含まれていない API ポリシーが必要な場合、独自のカスタムポリシーを作成できます。カスタムポリシーには次のファイルが必要です。 - ポリシー定義 - ポリシーと設定可能なパラメーターが記述された YAML ファイル - ポリシー設定 - ポリシーを実装するバックエンドプロセスが含まれる XML ファイル カスタムポリシーにはポイントカット宣言も含める必要があります。詳細は、下記のポイントカットリファレンスを参照してください。 次のいずれかのランタイムを使用している場合にカスタムポリシーを作成できます。 - Mule 3.8 以降の統合ランタイム - Mule ゲートウェイランタイム 2.x 以降 Studio 6.1 以降では、Studio カスタムポリシーエディター (ベータ) を使用できます。 ## [](#制限事項)制限事項 カスタムポリシーは自己完結型である必要があります。カスタムポリシーから、別の連動ポリシー、アプリケーション上のコネクタ、共有コネクタ、またはその他の実行時に使用できるか外部ライブラリで使用できる連動関係を参照しないでください。 Mule Runtime の要素を使用してカスタムポリシーを作成することで、HTTP コールと応答を評価して処理できます。ポリシーによって API へのコールが絞り込まれ、要求のクエリパラメーターのいずれかが、設定可能な正規表現に一致します。一致しない要求は却下されます。要求が検索条件に一致しなかった場合にエラーを示す HTTP 状況とペイロードを設定します。 ## [](#カスタムポリシーの適用)カスタムポリシーの適用 ユーザーがカスタムポリシーを使用できるようにするには、API Manager でポリシーを Anypoint Platform に追加します。ユーザーは、API の API バージョン詳細ページで、\[Policies (ポリシー)\] を選択し、リストからカスタムポリシーを選択して、そのポリシーを API に適用できます。 Anypoint Platform からダウンロードした .zip ファイルを使用して非公開サーバーに API をデプロイすると、オンプレミスサーバーユーザーが新しいポリシーを適用できるようになります。ポリシーを作成する前にすでにプロキシがデプロイされていた場合でも、再ダウンロードまたは再デプロイする必要はありません。新しいポリシーは、Mule ゲートウェイまたは Mule 3.8 統合ランタイムがインストールされている場所の ​`/policies`​ フォルダーに自動的にダウンロードされます。​`wrapper.conf`​ ファイル内で組織のクライアント ID とトークンを設定します。 ## [](#失敗したポリシー)失敗したポリシー Mule Runtime 3.8 以降と Mule ゲートウェイランタイム 2.1 以降では、オンラインポリシーの形式が無効である場合や解析の例外が発生した場合は、ポリシーがレビューのために ​`policies`​ ディレクトリ内の ​`failedPolicies`​ ディレクトリに保存されます。次回のポリシーのポーリングでは、そのポリシーは解析されません。そのポリシーを削除すると、そのフォルダーからも削除されます。フォルダーにポリシーがない場合は、フォルダーが削除されます。 ### [](#既存のポリシーの使用)既存のポリシーの使用 デフォルトで存在する既存のポリシーを変更したり組み合わせたりすることができます。XML ソースコードを表示して、カスタムポリシー設定内でそれを使用できます。 オンプレミスランタイムのインストールで既存のポリシーを見つけるには、​`examples>policies`​ フォルダーを検索します。 ## [](#関連情報)関連情報 - [Mule 3 のポリシー](#api-manager::policies-mule3.adoc) - [カスタムポリシーの作成](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-creating-custom-policy) # カスタムポリシーの Java バージョンの設定 Mule ゲートウェイのカスタムポリシーでは、さまざまな Java バージョンをサポートできます。カスタムポリシーを新しいバージョンの Java にアップグレードするには、すべてのポリシー連動関係で新しい Java バージョンがサポートされることを確認して、新しい Java バージョンをポリシーの実装メタデータ YAML ファイルに追加します。 ポリシーのアップグレード後に、次の作業を実行します。 1. [カスタムポリシーをパッケージ化します](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-package)​。 2. [カスタムポリシーを Exchange に再パブリッシュします](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-upload-to-exchange)​。 3. [適用するポリシーを新しいポリシーバージョンにアップグレードします](https://docs.mulesoft.com/jp/general/upgrade-policies-proxies)​。 ## [](#before-you-begin)始める前に ポリシーの Java バージョンをアップグレードする前に、すべての連動関係がその Java バージョンと互換性があることを確認してください。 - ポリシーでカスタムコネクタを使用している場合は、​[「Custom Connectors Java Support (カスタムコネクタの Java サポート)」](https://docs.mulesoft.com/jp/general/java-support#custom-connectors)​を参照してアップグレードします。 - ポリシーで Mule API ゲートウェイによって提供される拡張機能を使用している場合は、​`pom.xml`​ ファイルの連動関係のバージョンを新しい Java バージョンがサポートされるバージョンに更新します。 カスタムポリシーでの拡張機能の使用法の例は、[HTTP ポリシートランスフォーム拡張機能](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-http-transform)を参照してください。 最初の Java 17 と互換性があるバージョンの拡張機能を見つけるには、次の表を参照してください。すべてのバージョンで Java 8 がサポートされます。

拡張機能のアーティファクト ID

最初の Java 17 と互換性があるバージョン

mule-client-id-enforcement-extension

1.2.0

mule-cors-extension

1.3.0

mule-event-authentication-extension

1.1.0

mule-federation-extension

1.4.0

mule-http-policy-transform-extension

3.2.0

mule-http-proxy-extension

1.2.0

mule-ip-filter-extension

2.1.0

mule-json-threat-protection-extension

1.2.0

mule-jwt-extension

1.3.0

mule-rest-validator-extension

2.3.0

mule-soap-fault

2.1.0

mule-throttling-extension

3.1.0

mule-tokenization-extension

1.2.0

mule-wsdl-functions-extension

1.2.0

mule-xml-threat-protection-extension

1.2.0
## [](#ポリシーの-java-バージョンの設定)ポリシーの Java バージョンの設定 ポリシーでさまざまな Java バージョンをサポートするには、​`supportedJavaVersions`​ 項目が含まれるように実装メタデータファイルを変更する必要があります。​`supportedJavaVersions`​ では、Java バージョン ​`8`​、​`11`​、​`17`​ がサポートされます。​`supportedJavaVersions`​ 項目を含めない場合、ポリシーでは Java 8 のみがサポートされます。​[始める前に](#before-you-begin)​で示しているように、すべてのポリシー連動関係でもリストされている Java バージョンをサポートする必要があります。 新しいカスタムポリシーでは、実装メタデータファイルと定義メタデータファイルが 2 つの個別の ​`YAML`​ ファイルに分割されます。ただし、以前のポリシーでは、実装メタデータファイルと定義メタデータファイルが同じ ​`YAML`​ ファイルに含まれている可能性もあります。以下のセクションを参照して、​`supportedJavaVersions`​ を関連するファイル構造に追加してください。 - [分割モデルポリシー](#split-model-policies) - [非分割モデルポリシー](#non-split-model-policies) ### [](#split-model-policies)分割モデルポリシー 分割モデルポリシーの場合は、​`supportedJavaVersions`​ 項目を実装メタデータ ​`YAML`​ に追加します。たとえば、次のようになります。 ```yaml #%Policy Implementation 1.0 name: Basic Authentication - Simple - Mule4 technology: mule4 supportedJavaVersions: ["8", "11", "17"] minRuntimeVersion: 4.1.0 releaseNotes: | * Java 17 compatibility. ``` ### [](#non-split-model-policies)非分割モデルポリシー 実装と定義のメタデータが同じ ​`YAML`​ ファイルにある以前のポリシーの場合は、次のように ​`supportedJavaVersions`​ 項目を追加します。 ```yaml id: basic-authentication-simple name: Basic authentication - Simple supportedPoliciesVersions: '>=v1' description: Enforces HTTP Basic authentication according to the details configured in the policy. category: Security violationCategory: authentication type: system resourceLevelSupported: true encryptionSupported: true standalone: true supportedJavaVersions: ["8", "11", "17"] requiredCharacteristics: [] providedCharacteristics: - Requires authentication configuration: - propertyName: username name: User Name type: string optional: false sensitive: false allowMultiple: false - propertyName: password name: User Password type: string optional: false sensitive: true allowMultiple: false ``` ## [](#関連情報)関連情報 - [Java サポート](https://docs.mulesoft.com/jp/general/java-support) - [ポリシーと API プロキシのための Java のアップグレード](https://docs.mulesoft.com/jp/general/upgrade-policies-proxies) # カスタムポリシーのパッケージ化 Mule Maven プラグインを使用して、カスタムポリシーをデプロイ可能な JAR ファイルにパッケージ化でき、このパッケージを後から API に適用できます。 1. Mule Maven プラグインを pom.xml ファイルに追加していることを確認します。この作業は、カスタムポリシーのアーキタイプによって自動的に行われます。 ```console org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} true ``` 2. プロジェクトのフォルダーのコマンドラインから、パッケージフェーズを実行します。 ```console > mvn clean package ``` このパッケージャーはアプリケーションをプロジェクトのフォルダー内の対象ディレクトリにパッケージ化し、デプロイ可能な JAR ファイルを作成します。 また、パッケージ化に必要なすべてのファイルが提供されていて、mule-artifact やポリシーの yaml で提供されている情報が有効であることを確認します。 ## [](#関連情報)関連情報 - [カスタムポリシーの開発の開始](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-getting-started) - [Exchange へのカスタムポリシーのアップロード](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-upload-to-exchange) - [カスタムポリシーの概念の確認](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-mule-4-reference) # カスタムポリシーのリソースレベルのサポートの有効化 カスタムポリシーのリソースレベルのサポートを有効にするには、Mule 3.8.1 以降で、既存のカスタムポリシーの設定ファイルと定義ファイルにそれぞれ YAML コードと XML コードを追加して、リソースレベルのポリシーをサポートします。 1. XML 定義ファイルで、標準ポイントカット定義を次のように変更します。 **変更前:** ```xml ``` **変更後:** ```json {{#pointcutData.length}} {{#pointcutData}} {{/pointcutData}} {{/pointcutData.length}} {{^pointcutData.length}} {{/pointcutData.length}} ``` 2. YAML ファイルに次のキー/値ペアを追加します。 `resourceLevelSupported: true` 3. Anypoint Platform で、\[API Manager\] をクリックします。 4. \[API Administration (API 管理)\] で、\[Custom policies (カスタムポリシー)\] を選択します。 5. \[Add Custom Policy (カスタムポリシーを追加)\] をクリックします。 6. \[Add Custom Policy (カスタムポリシーを追加)\] で、新しいポリシーに名前 (「myResourceLevelPolicy」など) を付けます。 7. 作成またはダウンロードした YAML ファイルと XML ファイルを参照して選択します。 ## [](#関連情報)関連情報 - [カスタムポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-custom-policies) - [カスタムポリシーの作成](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-creating-custom-policy) # カスタムポリシーの作成 カスタムポリシーを作成するには、ユーザーが組織のシステム管理者ロールに割り当てられている必要があります。 ## [](#設定ファイルの作成)設定ファイルの作成 この手順では、カスタムポリシーの設定ファイルを作成する方法について説明します。この手順の最後で、完全なファイルをダウンロードできます。 1. 新しいテキストファイルを開き、policy 要素、before 要素、pointcut 要素を作成します。 2. 分析のためにポリシーを追跡するための policy 要素、ID 要素、policyName 要素を作成します。 ```xml ``` 検索条件によって指定された条件が一致しない場合、このプロパティは参照先要素をコールして実行します。 7. .xml 拡張子を使用してファイルを保存します。 ## [](#定義ファイルの作成)定義ファイルの作成 この手順では、ポリシー定義ファイルを含む YAML ファイルを作成します。次に、API へのコールを絞り込むために、ポリシー定義にはクエリパラメーターとクエリパラメーターを絞り込むための正規表現が含まれます。一致しない要求は却下されます。ポリシーを適用すると、プロパティが UI の要素にマップされます。この手順の最後で、完全なファイルをダウンロードできます。 1. Anypoint Platform で、新しいテキストファイルを開き、ポリシーの必須プロパティを定義します。 2. Mule 3.8.1 以降を実行する場合は、​`resourceLevelSupported: true`​ プロパティを追加します。このプロパティは、リソースレベルポリシーをサポートします。 ```yaml id: query-param-filter name: Query Param Filter description: Filters query parameters category: Security type: custom standalone: true requiresConnectivity: false resourceLevelSupported: true providedCharacteristics: [] requiredCharacteristics: [] ``` 3. 1 つの設定要素と、regexFilter と queryParam の値を持つ 2 つの propertyName 項目を追加します。 4. パラメーターを絞り込むための正規表現を定義するプロパティと、評価する必要があるクエリパラメーターに名前を付けて定義するプロパティを追加します。 ```yaml id: query-param-filter name: Query Param Filter description: Filters query parameters category: Security type: custom standalone: true requiresConnectivity: false resourceLevelSupported: true providedCharacteristics: [] requiredCharacteristics: [] configuration: - propertyName: regexFilter name: Regex Filter description: A regular expression to filter a query parameter. Rejects unmatched requests. type: string defaultValue: optional: true sensitive: false allowMultiple: false - propertyName: queryParam name: Query Parameter description: Name of a query parameter to filter by a regular expression. type: string defaultValue: optional: false sensitive: false allowMultiple: false ``` 5. `.yaml`​ 拡張子を使用してファイルを保存します。たとえば、​`mypolicy.yaml`​ としてファイルを保存します。 ## [](#before-および-after-例外ブロックの定義)before および after 例外ブロックの定義 設定ファイルのメイン要素内に 2 つの基本的な構造を追加できます。​``​ タグと ​``​ です。どちらも省略可能ですが、ポリシーで何らかのアクションを実行するには、少なくともいずれか一方が含まれている必要があります。 次のバージョンは、カスタムポリシー例外をサポートしています。 Mule ゲートウェイ/Mule Runtime - v3.8.4 >= バージョン < v4.0.0 - v2.2.1 >= バージョン < v3.8.0 - v2.1.2 >= バージョン < v2.2.0 次のフローに示すように、​**before**​ タグ間のコンテンツは、API への受信要求があるたびに、要求がインバウンドエンドポイントに到達するとすぐに、API がフロー内の残りのメッセージプロセッサーを実行する前に実行されます。同様に、​**after**​ タグ間のコンテンツは、API への要求があるたびに、API のアウトバウンドエンドポイントに達する直前に、フロー内のメッセージプロセッサーをすべて実行し終わった後に実行されます。 ![HTTP からプロパティへの 4 つのステップが含まれるプロジェクトフローを示す図](/mulesoft/current/ja-jp/mule-gateway/_images/basic-flow.png) ``​ タグと ​``​ タグに加えて、追加フローとして ​``​ タグを追加して、別の手順を実行することもできます。これらのフローは単独では実行されず、ポリシーの ​**before**​ または ​**after**​ セクションで参照される必要があります。ポリシーを記述するときには、Mule アプリケーションを記述するときとは異なり、要素名に ​`mule:`​ サフィックスを追加する必要があります。 ```xml ``` DataWeave コンポーネントは、Mule Runtime 3.8.5 以降でカスタムポリシー内での使用がサポートされています。 ### [](#例外ブロックを拡張する-before-および-after-タグ)例外ブロックを拡張する before および after タグ カスタムポリシー定義内で before および after ブロックを定義すると、フローの Catch Exception Strategy (キャッチ例外戦略) を変更することなく拡張できます。 次の図は、デフォルトパス ​`Before > Flow > After`​ とエラーパス ​`Before Exception > Exception Strategy > After Exception`​ を示しています。 ![API ゲートウェイランタイム内のエラー処理を説明するフローチャート](/mulesoft/current/ja-jp/mule-gateway/_images/before-after-exception.png) デフォルトパスのいずれかの部分で例外が発生すると、そのパスの実行は停止され、エラーパスの実行がトリガーされます。before-exception または after-exception で例外が発生すると、エラーパスの実行が停止されます。例外戦略内でエラーが発生すると、after-exception が実行されます。 次のカスタムポリシー例は、before および after 例外ブロックの実装方法を示しています。 ```xml ``` ## [](#api-manager-へのカスタムポリシーの追加)API Manager へのカスタムポリシーの追加 1. API Manager で、​**\[Custom Policies (カスタムポリシー)\]**​ に移動し、​**\[Add Custom Policy (カスタムポリシーを追加)\]**​ をクリックします。 2. **\[Policy for Runtimes older than Mule 4 (Mule 4 より古いランタイム用のポリシー)\]**​ を選択します。 3. **\[Name (名前)\]**​ 項目で、新しいポリシーバージョンの名前を入力します。 4. カスタムポリシーの新しいバージョンの YAML ファイルと XML ファイルをアップロードします。 ![ランタイムポリシーを設定するためのフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/upgrade-custom-policy-mule3-08395.png) 5. **\[Add (追加)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [Mule 3 のカスタムポリシーバージョンを変更する](https://docs.mulesoft.com/jp/gateway/1.10/policies-custom-overview) - [設定および定義ファイルの参照](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-custom-policy-references) - [カスタムポリシーのリソースレベルのサポートの有効化](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-resource-level-custom-policy) # カスタムポリシーの例 さまざまなイベントやシナリオのカスタムポリシーを開発および実装する方法についての理解を深めるには、次の例を参照してください - [カスタム応答ポリシーの作成](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-response-example) - [イベント認証拡張機能を使用したカスタムポリシーの作成](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-set-authentication-example) # カスタムポリシー開発リファレンス カスタムポリシーを構築する場合、Mule 4 のアーキテクチャと XML スキーマ言語が多用されているため、Mule 3 エンジンよりも Mule 4 エンジンの方が強力です。 Maven を使用して、Mule 4 ポリシーを構築およびデプロイします。ポリシーは、2 つのファイルで構成されます。 1. ポリシー実装が含まれるデプロイ可能な JAR ファイル。 2. ポリシーパラメーターとメタデータが定義される YAML 設定ファイル。 Maven でポリシーをパッケージ化するには、次のファイルで開発プロジェクトが構成されている必要があります。 - XML テンプレート Mule の XML スキーマ言語を使用するポリシーの実装が含まれます。 - YAML ファイル ポリシーの設定可能なパラメーターを定義します。Anypoint API Manager は、このファイルを使用して UI を表示し、ポリシーの入力を表示します。 - テンプレートの ​`pom.xml`​ ファイル ポリシー連動関係を定義します。パッケージ化種別は、​`mule-policy`​ にする必要があります。​`pom.xml`​ ファイルでは、Maven プロジェクト開発ライフサイクルの管理に役立つ他の Maven プラグインを定義できます。 - リソース ポリシーが連動する省略可能なファイル (証明書や設定プロパティファイルなど)。 - mule-artifact.json 記述子

ポリシーでは、パッケージやリソース (Java クラスなど) をエクスポートできません。
## [](#基本的な-xml-構造)基本的な XML 構造 以下は、ポリシー設定の基本構造の例です。 ```xml (1) (2) … (3) (4) … (5) ```
1ポリシーの定義は、名前引数が含まれる ​http-policy:proxy​ 要素で始まります。 http-policy:proxy​ 要素には、​http-policy:source​ または ​http-policy:operation​ 要素が含まれている必要があります。 この例では、​http-policy:source​ が使用されています。
2http-policy:source​ ブロックには、ポリシーで設定されている処理対象の Mule フローに対して実行される実際の命令が含まれます。​http-policy:source​ ブロックでは、フローの開始時の HTTP リスナーイベントの発生前に命令を挿入したり、フローの完了後に命令を挿入したりできます。
3execute-next​ 要素の前に定義された Mule イベント操作は、HTTP リスナーでフローが開始される前に実行されます。
4http-policy:execute-next​ 要素は、Mule イベント処理を続行するために必要です。​http-policy:execute-next​ 要素では、他のポリシーまたはアプリケーションフローをトリガーできます。ポリシーでは、​http-policy:execute-next​ を実行しないことで、Mule イベント処理チェーンを停止できます。
5http-policy:execute-next​ 要素の後に定義された Mule イベント操作は、フローの完了後に実行されます。 これらの Mule イベントプロセッサーは、フローから返された Mule イベントを処理できます。
### [](#実行順序の理解)実行順序の理解 Mule アプリケーションに 2 つのポリシー A と B が含まれるケースを考えます。 ポリシー A の順序は 1 で、B の順序は 2 です。 ポリシー A は、次の設定で定義されています。 ```xml ``` ポリシー B の設定は次のようになっています。 ```xml ``` フローは次のように定義されています。 ```xml ``` HTTP 要求が Mule アプリケーションのエンドポイントに到達すると、下図の順序で実行されます。 → → → → 順序の小さいポリシーが最初に実行されます。フローは、常にポリシー操作の途中で実行されます。 このモデルでは、​`http-policy:execute-next`​ 要素の有無によって Mule イベント処理チェーンを制御できます。 たとえば、​`http-policy:execute-next`​ 要素を ​`choice`​ 要素内に配置すれば、choice の条件に応じて次の Mule イベントの実行を続行または停止できます。 以下の例では、受信リクエストヘッダーの名前が ​`myHeader`​ で、その値が ​`someValue`​ の場合にのみフローが実行されます。受信要求が制約を満たさない場合、メッセージが記録されます。 ```xml ``` ## [](#拡張機能の使用)拡張機能の使用 ポリシーは、Mule アプリケーションのように Mule 拡張機能またはプラグインを使用して Mule コア機能を拡張できます。 たとえば、フローの HTTP リスナーから HTTP 応答にヘッダーを追加するには、ポリシーが必要になります。 まず、HTTP 要求オブジェクトを変更できる Maven 連動関係を追加します。 `mule-http-policy-transform-extension`​ Mule プラグインは、HTTP 要求を変更できます。 ```xml com.mulesoft.anypoint mule-http-policy-transform-extension 1.0.0 mule-plugin ``` これらの例は、Mule 拡張機能 v1.0.0 を使用して開発されています。別のバージョンの拡張機能を使用すると、例は期待どおりに動作しない可能性があります。Mule 拡張機能バージョンを更新する場合は、​[「HTTP ポリシートランスフォーム拡張機能」](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-http-transform)​を参照してください。 次に、XML ​`http-transform`​ 名前空間を追加して、上記の連動関係の操作を公開する必要があります。 ```xml #[{'policyHeader': 'policyHeaderValue'}] ``` ポリシーでカスタムコードを使用する必要がある場合、ポリシーで次のいずれかの作業を実行します。 1. Java または XML SDK 拡張機能でプログラミングされたカスタム Mule プラグインをインポートする 2. ``​ 要素を使用して、カスタムスクリプトを追加する SDK 拡張機能を使用する方法をお勧めします。

カスタムポリシーでは、リソースやパッケージ (Java クラスなど) をエクスポートするコネクタは使用できません。たとえば、カスタムポリシーでは Java Connector や Spring Connector は使用できません。
## [](#アウトバウンドポリシー)アウトバウンドポリシー ポリシーは、フロー内のアウトバウンド HTTP 要求に適用できます。この機能により、ポリシーを使用して、フローで定義された HTTP リクエスターを介して追加のヘッダーやその他の情報をアウトバウンド HTTP トラフィックに挿入できます。 以下は、ソースブロックと操作ブロックが含まれるポリシーの例です。 ```xml (1) … … (2) ```
11 つの ​http-policy:proxy​ 要素は、両方の種別のポリシーブロックで使用されます。ソースブロックと操作ブロックは共存できます。 両方のブロックが存在する場合、各ブロックで変数を共有して、ポリシー実行全体で状態を保持できます。
2このポリシーブロックには、フローの HTTP リクエスターから HTTP 応答が返された後に実行されるコードが含まれます。 フローに HTTP リクエスター要素が含まれていない場合、このブロックは実行されません。
通常、ポリシーで ​`http-policy:operation`​ ブロックを使用すると、Mule 実行が HTTP リクエスターに到達する前と HTTP リクエスターが応答を返した後にコードを挿入できます。 操作ブロックには、フローの HTTP 要求の前後の操作を制御する ​`http-policy:execute-next`​ 要素を含めることができます。 **実行順序の例** 2 つのポリシー A と B があります。 ポリシー A の順序は 1 で、B の順序は 2 です。 ポリシー A は、次の設定で定義されています。 ```xml ``` ポリシー B の設定は次のようになっています。 ```xml ``` フローは次のように定義されています。 ```xml ``` Mule Runtime が HTTP 要求を受信するときの実行順序は次の図のようになります。 → → → → → → → → → → 操作ポリシーは、​`http:request`​ 操作の周囲にのみ挿入されます。 ## [](#エラー処理)エラー処理 Mule 4 ポリシーは、以下でスローされたエラーを処理できます。 1. ポリシー 2. Mule アプリケーション内のフロー 3. 他のポリシー エラー処理は、Mule 4 の ​`try`​ および ​`error-handler`​ 要素を使用して実現できます。 `error-handler`​ でエラーがキャッチされると、エラーが Mule イベント処理チェーンに伝播されるか、処理されて通常の Mule イベント処理が引き続き実行されます。 たとえば、次のポリシーとフローを考えます。 ```xml ``` ```xml ``` ### [](#シナリオ-1)シナリオ 1 ``​ でエラーが発生したと想定します。実行順序は下図のようになります。 → → → ``​ は実行されず、処理はフローの error-handler に続きます。 エラーを伝播しないようにフローの error-handler が設定されているため、​``​ はポリシーに戻り、ポリシーの ​`error-handler`​ の代わりに ​``​ が実行されます。 ### [](#シナリオ-2)シナリオ 2 ``​ でエラーが発生したと想定します。実行順序は下図のようになります。 → 上記の例では、フローは実行されません。 ### [](#シナリオ-3)シナリオ 3 フローのエラーハンドラーがエラーを伝播するようになったと想定します。 ```xml ``` ``​ でエラーが発生したと想定します。実行順序は下図のようになります。 → → → エラーがポリシーに伝播され、ポリシーのエラーハンドラーが引き続きエラーを処理します。 つまり、エラーハンドラーはポリシー内でフローを条件付きで実行する代替方法を提供します。 ## [](#クラスローディング分離)クラスローディング分離 ### [](#ポリシー間)ポリシー間 ポリシーには、Mule 4 アプリケーションと同じクラスローディング分離アーキテクチャがあるため、特定のポリシーで定義されたリソースまたはライブラリは他のポリシーに表示されません。 ### [](#ポリシーとアプリケーション間)ポリシーとアプリケーション間 ポリシーと Mule 4 アプリケーション間のクラスローディングは、完全に分離されません。このシナリオは、アプリケーションとドメイン間のクラスローディング分離と似ています。 アプリケーションに表示されるプラグイン、ライブラリ、リソースは、そのアプリケーションに適用されるポリシーにも表示されます。 ただし、ポリシーに表示されるプラグイン、ライブラリ、リソースは、適用されるアプリケーションに表示​**されません**​。 ### [](#連動関係の解決)連動関係の解決 同じ連動関係の異なるバージョンがポリシーとアプリケーションで使用される場合、アプリケーションの連動関係のバージョンがポリシーで使用されます。 クラスローディング分離についての詳細は、​[「クラスローディング分離」](https://docs.mulesoft.com/mule-runtime/latest/about-classloading-isolation)​のトピックを参照してください。 ## [](#変数とイベントスコープ)変数とイベントスコープ ポリシーでは、任意の数の変数を定義できます。ポリシースコープ内の変数は、ポリシーブロック間で共有できます。 たとえば、​`http-policy:source`​ ブロックで定義された変数 ​`maxCount`​ を後続の ​`http-policy:operation`​ ブロックで使用することができます。 ただし、ポリシーで定義された変数を他のポリシーやアプリケーションで使用することは​**できません**​。 また、アプリケーションで定義された変数をポリシーで使用することもできません。 ## [](#ソースポリシーの-mule-メッセージの伝播)ソースポリシーの Mule メッセージの伝播 ポリシーで Mule メッセージを変更できますが、Mule メッセージが変更された場所 (​`http-policy:execute-next`​ 要素に対する相対的な場所) によっては変更が伝播されない可能性があります。 ソースポリシーの場合、​`http-policy:execute-next`​ 要素の後で行われた Mule メッセージへの変更は、Mule イベント処理チェーンの残りの部分全体に引き続き伝播されます。 以下のポリシーとフローは、この概念を示しています。 ```xml ``` ```xml ``` クライアントに返される最終応答は、本文として「Policy Message (ポリシーメッセージ)」が含まれる HTTP 応答になります。 たとえば、​`execute-next`​ 要素の前で行われた変更は、デフォルトで次のポリシーまたはアプリケーションに伝播されません。 以下のポリシーとフローを考えます。 ```xml ``` ```xml ``` クライアントに返される最終応答は、空の本文が含まれる HTTP 応答になります。さらに、フローのロガーは空のペイロードを記録します。 ### [](#mule-メッセージの伝播)Mule メッセージの伝播 `http-policy:source`​ タグ内で、属性 ​`propagateMessageTransformations`​ を ​`true`​ に設定して伝播を有効にします。 ```xml ``` ```xml ``` クライアントに返される最終応答は、本文として「Policy Message (ポリシーメッセージ)」が含まれる HTTP 応答になります。フロー内のロガーは「Policy Message (ポリシーメッセージ)」を記録します。 この設計により、アプリケーションに影響する可能性のある意図しない変更が回避されます。 ## [](#操作ポリシーの-mule-メッセージの伝播)操作ポリシーの Mule メッセージの伝播 Mule メッセージの伝播は、ソースポリシーと似ていますが、方向が逆です。操作ポリシーの場合、​`execute-next`​ 要素の前に行われた変更は常に伝播されます。​`execute-next`​ 要素の後に行われた変更は、デフォルトで伝播されません。 伝播は、操作ポリシー定義の同じ属性 ​`propagateMessageTransformations`​ を使用して有効にできます。 ```xml … … ``` つまり、変数を使用してポリシーの情報を他のポリシーまたは Mule アプリケーションに共有することはできません。 ただし、Mule メッセージを使用してポリシーの情報を他のポリシーまたは Mule アプリケーションに共有することはできます。 Mule メッセージが設定されるポリシーブロック内の場所によっては、属性 ​`propagateMessageTransformations`​ を true に設定して Mule メッセージの伝播を有効にすることが必要になる場合もあります。 ## [](#認証-セキュリティコンテキスト)認証 (セキュリティコンテキスト) ユーザー認証は、セキュリティコンテキストオブジェクト内の認証オブジェクトを介して公開できます。 ポリシーで設定した認証オブジェクトは、他のポリシーやアプリケーションで使用できます。 認証オブジェクトは、DataWeave を使用してアクセスできます。 #\[authentication.principal\] #\[authentication.password\] #\[authentication.properties.someProperty\] 認証オブジェクトを設定する方法は、SDK Mule 拡張機能を使用した連動関係のみです。 認証オブジェクトを設定する方法については、​[「認証ハンドラー」](https://docs.mulesoft.com/mule-sdk/latest/authentication-handler)​の記事を参照してください。 Mule 4 で提供されるポリシーでは、この抽出方法を使用してクライアント情報を伝播します。 ## [](#yaml-設定ファイル)YAML 設定ファイル Mule 4 ポリシーでは、YAML ファイルを使用してメタデータとユーザーパラメーターを保存します。この柔軟な設計により、異なるユーザーパラメーターと設定が必要な複数の API でポリシーが機能します。 たとえば、レート制限ポリシーでは、ユーザーパラメーターに基づいて異なる設定を行うことができます。ユーザーは、ある API では最大 100 件/分の要求を許可し、別の API では最大 5000 件/分の要求を許可するということができます。 ユーザーパラメーターを許可するには、ポリシー開発者は YAML 設定ファイルでユーザー入力を定義します。こうすることで、API Manager でファイルが使用されて、ユーザー入力を求める UI が表示されます。 **クライアント ID 適用の YAML ファイルの例** ```yaml id: openam-access-token-enforcement (1) name: OpenAM access token enforcement (2) supportedPoliciesVersions: '>=v4' (3) description: Enforces access tokens by OpenAM. (4) category: Security (5) violationCategory: authentication (6) type: system (7) resourceLevelSupported: true (8) standalone: true (9) identityManagement: (10) type: OpenAM - OAuth 2.0 protected configuration: (11) - propertyName: scopes name: Scopes description: A space-separated list of supported scopes type: string optional: true sensitive: false allowMultiple: false - propertyName: exposeHeaders name: Expose Headers description: In a proxy scenario, defines if headers should be exposed in the request to the backend. The headers that may be sent are the user properties returned by the federation server when validating the access token with a 'X-AGW-' prefix. type: boolean optional: true defaultValue: true allowMultiple: false ```
1ポリシーの組織内の一意の ID。必須
2API Manager の UI にポリシー名を表示するために使用されるわかりやすい名前。必須
3非推奨のプロパティ。現時点では、値は「>=v1」に設定する必要があります。必須
4ポリシーで実行する内容の説明。API Manager の UI でも使用されます。必須
5ポリシーが属するカテゴリ。API Manager の UI でポリシーのグループ化や絞り込みを行うために使用されます。任意の String (文字列) 値が有効です。必須
6さまざまなポリシー違反種別に関するメトリクスを表示するために Edge によって使用される値。必須
7非推奨のプロパティ。値は「system」に設定する必要があります。必須
8ポリシーの適用時にリソースレベルのポイントカットを有効にする必要があるかどうか。必須
9非推奨のプロパティ。値は「true」に設定する必要があります。必須
10API の組織に設定される ID 管理に関する情報がポリシーで必要かどうか。省略可能
11ポリシーパラメーターが定義される場所。ここにリストされる各パラメーターは、想定されるユーザー入力として API Manager の UI に表示されます。値の配列が想定されます。必須
以下は、上記のポリシーのパラメーターを定義する構文です。 ```yaml propertyName: scopes (1) name: Scopes (2) description: A space-separated list of supported scopes (3) type: string (4) defaultValue: some String (5) optional: true (6) sensitive: false (7) allowMultiple: false (8) ```
1パラメーターの内部名。ポリシー内の一意である必要があります。
2パラメーターのわかりやすい名前。API Manager の UI に表示するために使用されます。
3パラメーターの説明。これも、API Manager の UI に表示するために使用されます。
4パラメーターの種別。
5パラメーターのデフォルト値。
6ユーザーがこの値を入力することが必須であるかどうか。
7API Manager の UI で入力するときにこのプロパティをマスクする必要があるかどうか。
8このパラメーターで複数の値を許可する必要があるかどうか。
### [](#パラメーターの型)パラメーターの型 パラメーターの種別に応じて、UI には次のようなさまざまな入力種別が表示されます。 - テキストボックス - ラジオボタン - チェックボックス 一部の表示要素では、追加の設定が必要になります。次に、追加の設定が必要な要素のリストを示します。 - **String (文字列)**​: 任意の文字列が想定されます。 - **Expression (式)**​: #\[ で始まり \] で終わる DataWeave 式が想定されます。 - **Boolean (ブール)**​: true または false。 - **Int (整数)**​: 数値が想定されます。この種別では、追加のプロパティが必要です。 ```yaml minimumValue: -1 (1) maximumValue: 2147483647 (2) ```
1パラメーターで許可される最小値。
2パラメーターで許可される最大値。
- **Radio (ラジオ)**​: オプションのグループの 1 つの値。この種別では、追加のプロパティが必要です。 ```yaml options: (1) - name: HTTP Basic Authentication Header value: httpBasicAuthenticationHeader - name: Custom Expression value: customExpression ```
1ユーザーが選択するオプションのリスト。各オプションには、UI に表示するための名前があり、ポリシーでは内部値が使用されます。
- **Keyvalues**​: キー - 値ペアのコレクション。 ## [](#handlebars)HandleBars ポリシーでは、Handlebars (ポリシーの設定可能なパラメーターを解決して、条件式などのセマンティックロジックを実装するテンプレートエンジン) がサポートされています。これは、ポリシーでユーザー入力を使用する場合の推奨方法です。 YAML 設定ファイルで定義された各ポリシーパラメーターは、最終ポリシー設定を解決するための HandleBars 変数として使用できます。

Handlebars は、Mule ポリシーの以前のバージョンで使用されていた Mustache の拡張機能です。
HandleBars 変数の型は、YAML で定義されたパラメーターの型に応じて変わります。 String (文字列)、Expression (式)、Radio (ラジオ)、Int (整数)、Boolean (ブール) は、HandleBars のプリミティブ型です。 プリミティブ型は、ポリシーテンプレートから波括弧 (​`{{{myproperty}}}`​) を使用して参照できます。 Keyvalues は、HandleBars の複合型です。複合型には内部プロパティがあり、次のように参照できます。 {{{keyvalue.key}}} {{{keyvalue.value}}} 一部のプロパティは、YAML 設定ファイルで定義されていなくてもポリシーで使用できます。 - **policyId**​: ポリシーの記録や名前付けに役立つポリシーの ID。 - **isWsdlEndpoint**​: ポリシーが適用される API が WSDL API かどうかを示します。 API が適用される組織で ID 管理が定義されると、次のプロパティも使用できます。 **identityManagementTokenUrl**​: ID 管理のイントロスペクションエンドポイント。 **identityManagementClientId**​: イントロスペクションエンドポイントの認証用のクライアント ID。 **identityManagementClientSecret**​: イントロスペクションエンドポイントの認証用のクライアントシークレット。 ## [](#ポイントカット)ポイントカット 以前のバージョンでは、カスタムポリシーを設定するのにポイントカット要素が必要でした。ポイントカットを使用して、ポリシーで操作する API を指定していました。 Mule 4 では、ポイントカット要素を設定する必要はありません。カスタムポリシーで操作する API に関する情報は、ポリシーの適用時に API Manager によって提供されます。 ポリシーがオンラインで適用されない場合の設定ガイドラインについては、オフラインポリシーを参照してください。 ## [](#高度なトピック)高度なトピック - [HTTP ポリシーの Transform 拡張の確認](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-http-transform) - [HTTP キャッシュの削除カスタムポリシーの例](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-mule-4-caching) ## [](#関連情報)関連情報 - [カスタムポリシーのパッケージ化](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-package) - [Exchange へのカスタムポリシーのアップロード](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-upload-to-exchange) # カスタム応答ポリシーの開発 カスタムポリシーを開発する準備ができたら、「Good Weather 社」の例に従って後で独自のポリシーを計画、開発、および実装する方法を学習します。ポリシーを作成する手順は、次のとおりです。 1. 提供された​[ユースケース](#use_case)​に基づいてユースケースを評価します。 2. [プロジェクトをセットアップします](#set-up-the-project)​。 3. [YAML 設定ファイルを作成します](#create_the_YAML)​。 4. [カスタムポリシーを実装します](#implment_the_policy)​。 5. [カスタムポリシーを Exchange にアップロードします](#upload_to_exchange)​。 6. [カスタムポリシーを適用します](#apply_custom_policy)​。 ## [](#use_case)ユースケース カスタムポリシーの実装方法についての理解を深めるため、特定の場所と時間の天気を予測する事業を行っている「Good Weather」社の例を考えてみます。Good Weather は、特定の場所の大気の現在の状態に関する定量的なデータを収集し、気象学を使用して、その現在の状態が経時的にどのように変化するかを予測します。 Good Weather は、現在の天気パターンに基づいて、コンシューム側アプリケーションの天気予報にカスタム応答を追加する機能を提供したいと考えています。アプリケーションは、各要求で評価される一連の条件に基づいて状況コードと応答メッセージを操作できる必要があります。 Telstra は、モバイルおよびホームコンピューティングテクノロジー用のオペレーティングシステムとアプリケーションを開発する IT 企業です。Telstra は Good Weather と連携して、モバイルと PC で毎日の天気予報を表示したいと考えています。 Good Weather は、基本認証ポリシーが適用された HTTP プロキシを使用しています。要求が到着するたびに、ポリシーはベアラートークンをチェックし、次のいずれかのタスクを実行します。 - 要求がバックエンドに到達することを許可する - 検証が成功しなかった場合は、「401 Unauthorized (401 未承認)」状況コードで要求を拒否する。 ただし、未承認アクセスがあった場合、Telstra は 401 エラーを受信するたびに異なるメッセージを含めたいと考えている場合はどうでしょうか。カスタム応答ポリシーを開発することで、一連の異なる条件に基づいて応答メッセージと状況コードを変更できます。たとえば、応答に「Unauthorized (未承認)」状況コードが含まれている場合、それに応じて応答ペイロードを変更するように指定できます。 ただし、特定の条件に基づいた検証に失敗したときにアプリケーションでユーザーにカスタム応答を提供するようにした場合、デフォルトポリシーは機能しません。たとえば、Telstra はアプリケーションがエラーコードを返すだけでなく、追加の応答ペイロードも提供したいと考えているとします。このようなシナリオでは、カスタムポリシーを作成する必要があります。 ## [](#set-up-the-project)プロジェクトのセットアップ Telstra は、最初に​[カスタムポリシーアーキタイププロジェクト](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-getting-started)​を作成することで、カスタムポリシーの開発を開始します。 次に、アーキタイプを実行し、ここで太字で示されているパラメーターを独自のパラメーターに置き換えます。 - `DgroupId`​ は Telstra の組織 ID。 - `DartifactId`​ は ​`custom-response-policy`​ 値。 必要に応じて、他の任意の値に設定できます。 - `Dversion`​ は 1.0.0。 `DartifactId`​ と ​`Dversion`​ に制限はありません。 ```console mvn -Parchetype-repository archetype:generate \ -DarchetypeGroupId=org.mule.tools \ -DarchetypeArtifactId=api-gateway-custom-policy-archetype \ -DarchetypeVersion=1.2.0 \ -DgroupId= \ -DartifactId=custom-response-policy \ -Dversion=1.0.0 \ -Dpackage=mule-policy ``` ## [](#create_the_YAML)YAML 設定ファイルの作成 Telstra はプロジェクトをセットアップした後に、連動関係とコンポーネントの追加を開始してカスタマイズします。API Manager で設定するポリシーの入力パラメーターを定義することから始めます。 1. 要求と応答の評価に使用する条件を指定します。 2. 条件がパラメーターの場合、DataWeave 式が作成されます。 3. API Manager は、同時に条件が満たされるかどうかを検証します。 4. 条件が満たされた場合、状況コードが設定されます。 5. 条件が満たされた場合、ペイロードが設定されます。 次のコードスニペットは、ポリシー UI の YAML ファイルの例を示しています。 ```YAML id: Custom Response name: Custom Response description: Modifies the payload and/or the status code when some condition is met. category: Custom type: custom resourceLevelSupported: true encryptionSupported: false standalone: true requiredCharacteristics: [] providedCharacteristics: [] configuration: - propertyName: evaluateInRequest name: Evaluate in the request description: If the condition should be evaluated in the request. type: boolean optional: true defaultValue: false - propertyName: requestCondition name: Request Condition description: Dataweave expression that will be evaluated to define if the request should be modified. type: expression optional: true sensitive: false allowMultiple: false dependsOnKey: evaluateInRequest dependsOnValue: true - propertyName: evaluateInResponse name: Evaluate in the response description: If the condition should be evaluated in the response. type: boolean optional: true defaultValue: false - propertyName: responseCondition name: Response Condition description: Dataweave expression that will be evaluated to define if the request should be modified. type: expression optional: true sensitive: false allowMultiple: false dependsOnKey: evaluateInResponse dependsOnValue: true - propertyName: mergeBothConditions name: Merge both conditions description: Check if both request and response conditions need to be met. type: boolean optional: true defaultValue: false - propertyName: statusCode name: Status Code type: int minimumValue: 0 maximumValue: 999 description: Status code to return when the condition is met. optional: true sensitive: false allowMultiple: false - propertyName: payload name: Payload type: expression description: Expression that sets the payload to return when the condition is met. optional: true sensitive: false allowMultiple: false ``` この例では、​`dependsOnKey`​ および ​`dependsOnValue`​ パラメーターは項目 ​`responseCondition`​ または ​`requestCondition`​ を表示するために、​`dependsOnKey`​ で示されるキーを ​`dependsOnValue`​ で示される値に設定する必要があることを指定しています。 UI では、これはチェックボックスの値に応じて、​`requestCondition`​ または ​`responseCondition`​ 項目のいずれかを表示する ​`evaluateInTheRequest`​ または ​`evaluateInTheResponse`​ のチェックボックスに変換されます。 YAML ファイルのセットアップ方法についての詳細は、​[「YAML 設定ファイル」](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-mule-4-reference#yaml-configuration-file)​を参照してください。 この例に基づき、UI は次のように生成されます。 ![条件を満たす場合に応答ペイロードおよび状況コードを変更するフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/custom-response-policy-ui.png) 次のスクリーンショットは、​`dependsOnKey`​ および ​`dependsOnValue`​ パラメーターを示しています。 ![2 つのチェックボックスにより、ユーザーは要求または応答の条件を評価できます](/mulesoft/current/ja-jp/mule-gateway/_images/depends-on-key-demo.png) ## [](#implment_the_policy)ポリシーの実装 Telstra はポリシーの入力パラメーターを定義した後に、次の手順でポリシーの実装を開始できます。 1. `pom.xml`​ ファイルに連動関係を追加します。 2. `template.xml`​ ファイルに条件を追加します。 ### [](#add_dependencies_in_pom)pom.xml ファイルへの連動関係の追加 新しい状況コードとペイロードを使用してカスタム応答を変換するため、Telstra は拡張機能を作成する必要があります。これにより、応答メッセージを変換する定型コードの開発を回避できます。 1. `pom.xml`​ に Telstra が使用する必要があるすべての連動関係を含めます。 この場合、​[http-policy-transform-extension](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-http-transform)​ のみが必要になります。これは、応答情報を簡単に変更するのに役立ちます。 2. ポリシー ​`pom.xml`​ ファイルの ​``​ セクションに次の連動関係を含めます。 ```XML com.mulesoft.anypoint mule-http-policy-transform-extension ${httpPolicyTransformVersion} mule-plugin ``` Java で独自のコネクタを作成する方法についての詳細は、​[「Java 用 Mule SDK 入門」](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​を参照してください。 ### [](#template-xml-ファイルへの条件の追加)template.xml ファイルへの条件の追加 次に、Telstra は YAML ファイルを Handlebars に関連付ける必要があります。YAML ファイルは、使用される式を作成したり、コードブロック全体を追加したりする XML の項目を完成させるために使用します。 Telstra は ​`template.xml`​ ファイルに次のコードを含める必要があります。 ```XML {{#if evaluateInRequest}} {{/if}} {{#if evaluateInResponse}} {{/if}} ``` 二重中括弧 ({{}}) 内のコードは、YAML ファイルで定義された設定を含むポリシーテンプレートを作成するためにテンプレートエンジンを使用する、​[Handlebars](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-mule-4-reference#handlebars)​ 構文に対応しています。テンプレートの設定に使用される値は、YAML 設定ファイルで以前に定義されたキーである必要があります。両方の値が一致する必要があります。いずれかのパラメーターのスペルが間違っていると、エラーが発生する可能性があります。 前の例では、パラメーター ​`evaluateInRequest`​ と ​`evaluateInResponse`​ は、​`requestCondition`​ と ​`responseCondition`​ で定義された評価される条件値を保持する要素を定義しています。 たとえば、ポリシーを設定するときに、特定のヘッダーが要求内に存在することを確認する必要があるとします。ただし、応答内は何も確認しないとします。この場合、ポリシー設定は次のようになります。 ![DataWeave 式のチェックボックスとテキスト項目が含まれるフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/custom-response-configuration.png) デプロイされると、テンプレートは次のコード例に示すように解決されます。応答条件を指定しなかったため、Handlebars は解決されたテンプレートにそれを含めません。 ```XML ``` 次に、Telstra は次のコードを使用してテンプレートファイルのロジックを完成させます。 ```XML {{#if mergeBothConditions}} {{#if statusCode}} {{/if}} {{#if payload}} {{/if}} #[vars.payload default payload] #[attributes.headers] {{else}} {{#if statusCode}} {{/if}} {{#if payload}} {{/if}} #[vars.payload default payload] #[attributes.headers] {{/if}} ``` ペイロードと状況コード (設定されている場合) を変更するため、​[連動関係](#add_dependencies_in_pom)​に含まれる ​`http-policy-transform-extension`​ パラメーターを使用します。 前述のように、テンプレートの一部を解決するために Handlebars が使用されていることがわかります。 これで、Telstra のカスタム応答ポリシーを Exchange にアップロードしてテストする準備が整いました。 ## [](#upload_to_exchange)Exchange へのアップロード カスタムポリシーを Exchange にアップロードするため、Telstra は ​`pom.xml`​ ファイルが組織用に適切に設定されていることを確認する必要があります。 ### [](#タスクの前提条件)タスクの前提条件 ポリシーを Exchange にアップロードする前に、Telstra は次のことを確認する必要があります。 - Maven ​`settings.xml`​ ファイルで新しいサーバーが作成されている。 - 一意の ID が割り当てられ、Exchange ログイン情報のユーザー名とパスワードが存在する。 - URL が自分の地域と一致する。 **警告:**​ 同様のアクションを実行して独自のカスタムポリシーを作成する場合、テンプレートは米国地域に対応する URL を使用していることに注意してください。アカウントがこの地域に属していない場合は、この値を変更します。 - リポジトリ ID が Maven 設定の ID と一致する。 **ヒント:**​ name タグを使用して、そのリポジトリの別名を定義できます。 ```XML your_server_id your_username your_password ``` 次に、ポリシー ​`pom.xml`​ ファイルに移動して ​`distributionManagement`​ セクションを見つけます。 ```XML your_server_id My Repository ${exchange.url} default ``` サーバーの設定を確認したら、次のコマンドを使用して Exchange へのポリシーのアップロードを開始します。 ```console > mvn deploy ``` これで、Telstra が開発したカスタムポリシーが Exchange にアップロードされました。 ## [](#apply_custom_policy)ポリシーの適用 次に、Telstra はデフォルトポリシーを適用するのと同じ方法でカスタムポリシーを適用します。API Manager に移動すると、使用可能な新しいポリシーが表示され、いつでも使用できます。 ![バージョン 1.0.0 が選択されているカスタム応答設定](/mulesoft/current/ja-jp/mule-gateway/_images/custom-response-policy-platform.png) # カテゴリ リストをポリシーのカテゴリで絞り込むことができます。 - コンプライアンス - セキュリティ - サービス品質 - 変換 - トラブルシューティング カテゴリを選択した後、ポリシーにより達成される保護の種別でリストをさらに絞り込むことができます。 ポリシーがすでに適用されている場合や、ポリシーによって提供される保護が別の適用済みのポリシーによって満たされている場合、ポリシーは使用不可として表示されます。 ## [](#ポリシーのカテゴリ)ポリシーのカテゴリ ポリシーは、実行する機能別に分類されます。たとえば、ログを使用して問題を解決するため、メッセージログポリシーはトラブルシューティングポリシーとして分類されます。次の表に、デフォルトポリシーのカテゴリ、およびそのポリシーで実行される機能を示します。
ポリシー カテゴリ 達成されること 必須

クライアント ID 適用

コンプライアンス

クライアント ID の要求

なし

CORS

コンプライアンス

CORS-enabled

なし

ヘッダーの挿入

変換

ヘッダーの挿入

なし

ヘッダー削除

変換

ヘッダー削除

なし

HTTP 基本認証

セキュリティ

認証

セキュリティマネージャー

IP ブロックリスト

セキュリティ

IP の絞り込み

なし

IP 許可リスト

セキュリティ

IP の絞り込み

なし

JSON 脅威保護

セキュリティ

JSON 脅威保護

なし

LDAP セキュリティマネージャー

セキュリティ

セキュリティマネージャー

なし

メッセージログ

トラブルシューティング

メッセージログ

なし

外部プロバイダーを使用した OAuth 2.0 アクセストークンの適用ポリシー

セキュリティ

OAuth 2.0 の保護

なし

OpenAM アクセストークン適用

セキュリティ

OAuth 2.0 の保護

なし

PingFederate アクセストークン適用

セキュリティ

OAuth 2.0 の保護

なし

レート制限

サービス品質

レートの制限

なし

レート制限、SLA ベース

サービス品質

レートの制限、クライアント ID の要求

なし

単純なセキュリティマネージャー

セキュリティ

セキュリティマネージャー

なし

調整 - SLA ベース

サービス品質

調整、レート制限、クライアント ID 必須

なし

調整

サービス品質

調整、レート制限

なし

XML 脅威保護

セキュリティ

XML 脅威保護

なし
## [](#関連情報)関連情報 - [ポリシーの RAML の準備](https://docs.mulesoft.com/jp/api-manager/latest/prepare-raml-task) # クライアント ID 適用 クライアント ID 適用ポリシーを適用して、実行時に API バージョンを管理できます。このポリシーでは、承認済みアプリケーションのみにデプロイ済み API 実装へのアクセスを許可します。各承認済みアプリケーションには、client\_id と client\_secret のログイン情報が設定されています。実行時に、承認済みアプリケーションは、API 実装への要求ごとにログイン情報を提供します。 Mule 3.8.5 以降では、次の OAuth 2.0 トークン適用ポリシーに OAuth プロバイダーからのクライアント ID が含まれます。 - 外部プロバイダーを使用した OAuth 2.0 アクセストークンの適用 - PingFederate アクセストークン適用 - OpenID Connect アクセストークン適用 OpenAM 適用ポリシーでは検証は提供されません。 クライアント ID 適用ポリシーは、すべての要求が有効なクライアントアプリケーションによって実行されていることを確認します。この適用では、要求のクライアント ID を確認し、必要に応じてシークレットがプロバイダーのシークレットと一致することを確認します。このデータは API Manager にあるため、各 Mule Runtime はキャッシュを保持し、定期的に更新します。このキャッシュは永続的で、パフォーマンスを高めると共に、プラットフォームへの接続が突然失われた場合にも役立ちます。このポリシーは、管理プレーンの状態に関係なく適用されます。 クライアント ID ベースのポリシーの一般的な使用方法を次に示します。 - クライアント ID と (必要に応じて) シークレットをヘッダーとして使用する。 - クライアント ID と (必要に応じて) シークレットをクエリパラメーターとして使用する。 - クライアント ID と (必要に応じて) シークレットをメッセージペイロードから取得する。 - クライアント ID とシークレットを基本アクセス認証ヘッダーとして使用する。 Mule Runtime 4.0 では、クライアント ID ベースのポリシーで使用されている MEL 式は DataWeave 式に置き換えられます。 API Manager では、いくつかのクライアントベースのポリシーが提供されます。 - クライアント ID 適用 - レート制限 - SLA ベース - 調整 - SLA ベース API へのアプリケーションアクセスを追跡する必要がある場合、クライアント ID 認証を処理するためにこれらのポリシーのいずれかを適用します。アプリケーションが API に対して行うすべての要求でクライアント ID とクライアントシークレットを提供していることを確認します。デフォルトでは、ログイン情報は、クエリパラメーターとして渡されることが想定されています。ユーザー要求が却下されることを防止するため、RAML ルートに特性を作成し、API のすべての操作でこの特性を参照します。API Manager の API ダッシュボードにあるポリシーリストの RAML スニペットリンクには、RAML に追加する必要がある RAML コードが含まれています。 ![API ポリシーの詳細が示されているテーブル](/mulesoft/current/ja-jp/mule-gateway/_images/raml-snippet.png) ## [](#クライアント-id-適用ポリシー)クライアント ID 適用ポリシー アプリケーションを API Portal に登録するときに、クライアントアプリケーション開発者は、ポリシーを適用するときに設定されたログイン情報 (クライアント ID とクライアントシークレット) を取得します。 クライアント ID 適用ポリシーは、ログイン情報の要件を適用します。レート制限 - SLA ベースのポリシーと調整 - SLA ベースのポリシーは、クライアント ID を参照として使用して、各アプリケーションが一定期間内に実行できる要求の数を制限します。 ## [](#クライアント-id-ベースのポリシーに関する全般情報)クライアント ID ベースのポリシーに関する全般情報 このセクションの情報は、すべてのクライアント ID ベースのポリシーに適用されます。 アプリケーションが、クライアント ID ベースのポリシーを適用する API をコールすると、API Manager では、アプリケーションからクエリパラメーターとして client\_id と client\_secret が渡されることが想定されます。デフォルトでは、クエリパラメーターは、このトピックの「API コールの必須項目」セクションで説明する形式 (クライアント ID とクライアントシークレットの式) になっています。または、client\_secret 式を削除し、クライアント ID 制限ポリシーを適用するときに表示されるダイアログに client\_id のみを指定できます。その場合、クライアント ID のみが必須になります。 \[HTTP Basic Authorization Header (HTTP 基本承認ヘッダー)\] を選択して、ログイン情報元として基本認証を使用することもできます。 ![クライアント ID 適用ポリシーを適用するためのフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/clientiddefault.png) ### [](#アプリケーションの登録)アプリケーションの登録 ユーザーは、クライアント ID ベースのポリシーを適用する API に対するすべての要求で、ID に加えてトークンを送信する必要があります。ID とトークンを取得するために、クライアントアプリケーション開発者は、API のポータルで API アクセス要求コントロールを使用して API アクセスを要求します。 ユーザーが \[Request API Access (API アクセスの要求)\] をクリックすると、既存のアプリケーションを選択するか、新しいアプリケーションを作成するように求められます。API アクセスの要求は、自動的に承認されるか、クライアント ID および SLA ベースのポリシーの場合は、API のシステム管理者の承認が必要です。 アプリケーションからの API アクセス要求の承認は、API ダッシュボードで行います。 ### [](#api-コールの必須項目)API コールの必須項目 通常、アプリケーションは、ポリシー設定に応じて次のいずれかの方法でログイン情報を提供する必要があります。 - HTTP リクエストヘッダー内 - URL 内でクエリパラメーターとして たとえば、クライアント ID ベースのポリシーを適用する API にアプリケーションから HTTP ヘッダー内で client\_id と client\_secret を渡すには、次の Mule 3.x 式を使用します。 ```text #[message.inboundProperties['client_id']] #[message.inboundProperties['client_secret']] ``` たとえば、クライアント ID ベースのポリシーを適用するために、クエリパラメーター内で client\_id と client\_secret を渡すには、次の Mule 4.x 式を使用します。 ## [](#関連情報)関連情報 - [クライアント ID 適用](https://docs.mulesoft.com/gateway/latest/policies-included-client-id-enforcement) - [レート制限 SLA ポリシー](https://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting-sla) - [About OAuth 2 Policies (OAuth 2 ポリシーについて)](#api-manager::oauth2-policies-new.adoc) - [About OAuth 2 Policy Implementation (OAuth 2 ポリシーの実装について)](#api-manager::oauth-policy-implementation-concept.adoc) - [To Configure the Proxy Connection to an External OAuth Provider (外部 OAuth プロバイダーへのプロキシ接続の設定方法)](#api-manager::apply-oauth-token-policy-task.adoc) # クライアント ID 適用ポリシー

ポリシー名

クライアント ID 適用

概要

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

カテゴリ

コンプライアンス

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

v3.8.0

返される状況コード

401 - 未承認または無効なクライアントアプリケーションのログイン情報

500 - 認証サーバーからの不正応答、または WSDL SOAP 失敗エラー
## [](#概要)概要 クライアント ID 適用ポリシーは、登録済みクライアントアプリケーションからの要求のみを許可することで、保護されたリソースへのアクセスを制限します。このポリシーは、各要求で送信されるクライアントのログイン情報が API のコンシュームを承認されていることを確認します。 クライアントアプリケーションが Anypoint Platform に登録されると、クライアント ID とクライアントシークレットで構成されるログイン情報のペアが生成されます。クライアントアプリケーションが API へのアクセスを要求したときに、アプリケーションとその API 間のコントラクトが作成されます。クライアント ID 適用ポリシーで保護されている API は、承認されたコントラクトを持つアプリケーションのみからアクセスできます。 クライアント ID 適用ポリシーを適用すると、Analytics イベントと共にクライアント ID を報告することで、API へのアクセスが追跡されます。ポリシー、コントラクト、および初期化データに関連するすべての機密情報を暗号化するように、Mule Runtime Engine (Mule) を設定できます。 クライアントアプリケーションのログイン情報を内部に適用するデフォルトポリシーは次のとおりです。 - [レート制限: SLA ベースのポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-rate-limiting-sla) - [Mule OAuth プロバイダーを使用する OAuth 2.0 アクセストークン適用ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-oauth-access-token-enforcement) - [PingFederate OAuth 2.0 トークン適用ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-pingfederate-oauth-token-enforcement) - [OpenAM OAuth 2.0 トークン適用ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-openam-oauth-token-enforcement) - [JWT 検証ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-jwt-validation) トークン適用ポリシーは、必要に応じてクライアント検証をスキップできますが、トークンが承認されたコントラクトに関連付けられていることを確認するために検証を実施することをお勧めします。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#mule-ゲートウェイ)Mule ゲートウェイ UI からポリシーを API に適用するときに、環境に Mule アプリケーションがあるか非 Mule アプリケーションがあるかに基づいて、パラメーターのリストが表示されます。 #### [](#パラメーターの設定)パラメーターの設定 Mule アプリケーションの場合、次のパラメーターが表示されます。
パラメーター 説明 必須

Credentials origin (ログイン情報の取得元)

要求のどこから値を抽出するかを指定します。

  • HTTP Basic Authentication Header (HTTP 基本認証ヘッダー): 認証ヘッダーの一部としてログイン情報が必要です。API をコンシュームするアプリケーションは、基本認証スキームを使用して要求でログイン情報を送信する必要があります。

  • Custom Expression (カスタム式): 各クライアント ID とクライアントシークレットの式を受け入れ、要求からログイン情報を抽出する場所を示します。Mule 3 の場合は MEL 式を使用し、Mule 4 と Flex の場合は DataWeave 2.0 式を使用します。ログイン情報をカスタムヘッダーまたはその他の形式で送信する場合、このオプションを使用します。クライアントシークレットの要件を省略可能として設定する場合、この項目は空白のままにできます。

いずれかのオプションを選択する必要があります。

Client ID Expression (クライアント ID 式)

API 要求からクライアント ID を取得するために使用する DataWeave 2.0 式。

はい。

Client Secret Expression (クライアントシークレット式)

API 要求からクライアントシークレットを取得するために使用する DataWeave 2.0 式。

いいえ。

Method & Resource conditions (メソッドとリソースの条件): Apply configurations to all API methods & resources (設定をすべての API メソッドおよびリソースに適用)

API に関連付けられたすべてのメソッドとリソースにポリシーを適用する必要がある場合、このオプションを選択します。

いずれかのオプションを選択する必要があります。

Method & Resource conditions (メソッドとリソースの条件): Apply Configurations to Specific Methods & Resources (特定のメソッドとリソースに設定を適用)

API に関連付けられた特定のメソッドとリソースにポリシーを適用する必要がある場合、このオプションを選択します。

いずれかのオプションを選択する必要があります。
#### [](#anypoint-service-mesh-非-mule-アプリケーション-のパラメーターの設定)Anypoint Service Mesh (非 Mule アプリケーション) のパラメーターの設定 Anypoint Service Mesh (非 Mule アプリケーション) の場合、クライアント ID 適用ポリシーを同じ方法で設定しますが、次の違いがあります。
要素 説明 必須

Credentials origin (ログイン情報の取得元)

要求のどこから値を抽出するかを指定します。

  • client_id​ および ​client_secret​ ヘッダー:

  • HTTP Basic Authentication Header (HTTP 基本認証ヘッダー): 認証ヘッダーの一部としてログイン情報が必要です。API をコンシュームするアプリケーションは、基本認証スキームを使用して要求でログイン情報を送信する必要があります。

  • Custom Headers (カスタムヘッダー): 各クライアント ID とクライアントシークレットのヘッダー名を受け入れ、要求からログイン情報を抽出するヘッダーを示します。ログイン情報をカスタムヘッダーに送信する場合、このオプションを使用します。

いずれかのオプションを選択する必要があります。

Client ID Header (クライアント ID ヘッダー)

API 要求からクライアント ID を抽出するために使用されるヘッダー名。

はい。

Client Secret Header (クライアントシークレットヘッダー)

API 要求からクライアントシークレットを抽出するために使用されるヘッダー名。

いいえ。
## [](#ポリシーのしくみ)ポリシーのしくみ クライアントアプリケーションがクライアント ID 適用ポリシーで保護された API をコンシュームできるようになる前に、クライアントアプリケーションは API へのアクセスを要求する必要があります。クライアントアプリケーションと API 間に承認されたコントラクトが存在する場合、ポリシーの設定方法に準拠したクライアントアプリケーションのログイン情報がすべての要求に含まれている必要があります。 たとえば、クエリパラメーターとしてクライアント ID とクライアントシークレットを必要とするポリシーが設定されている場合、アプリケーションは要求でそれらのログイン情報を送信する必要があります。これを適用するには、API 仕様に ​`client-id-required`​ RAML trait を追加します。 traits: client-id-required: queryParameters: client\_id: type: string client\_secret: type: string `is`​ RAML 属性を使用して、trait をリソースまたはメソッドに適用します。 /example: get: is: \[client-id-required\] description: Example description ## [](#ポリシーがログイン情報を取得する方法の設定)ポリシーがログイン情報を取得する方法の設定 さまざまなカスタム DataWeave 2.0 式を使用して、HTTP 要求からクライアント ID とクライアントシークレットの両方、またはクライアント ID のみを抽出するようにポリシーを設定できます。次の例では、「1234」のクライアント ID と「abcd」のクライアントシークレットを使用しています。 ### [](#http-ヘッダーを使用したログイン情報の取得)HTTP ヘッダーを使用したログイン情報の取得 curl を使用する要求の例: ```text curl "http://localhost/myResource" -H "client_id:1234" -H "client_secret:abcd" ``` ポリシーの設定時に使用される DataWeave 2.0 式の例: ```text #[attributes.headers['client_id']] #[attributes.headers['client_secret']] ``` この例では、client\_id と client\_secret の 2 つのヘッダー、およびログイン情報のペアを必要とするポリシーが設定されています。このポリシーは、他の種別のヘッダーも許可する柔軟性があります。これがポリシーのデフォルト設定です。 ### [](#http-クエリパラメーターを使用したログイン情報の取得)HTTP クエリパラメーターを使用したログイン情報の取得 curl を使用する要求の例: ```text curl "http://localhost/myResource?client_id=1234&client_secret=abcd" ``` Mule 4 のポリシーの設定時に使用される DataWeave 2.0 式の例: ```text #[attributes.queryParams.'client_id'] #[attributes.queryParams.'client_secret'] ``` この例では、リクエスターは指定された 2 つのクエリパラメーターを要求と共に送信する必要があります。これはサポートされている設定ですが、セキュリティリスクが発生する可能性があります。ヘッダーを使用する方法をお勧めします。DataWeave 2.0 は Mule 4 では完全にサポートされ、Flex では一部サポートされます。 Mule 3 のヘッダー付きポリシーの設定時に使用される MEL 式の例: ```text #[message.inboundProperties['client_id']] #[message.inboundProperties['client_secret']] ``` ### [](#http-要求ペイロードを使用したログイン情報の取得-mule-のみ)HTTP 要求ペイロードを使用したログイン情報の取得 (Mule のみ) curl を使用する要求の例: ```text curl "http://localhost/myResource" -d '{"client_id":"1234", "client_secret":"abcd"}' -X POST ``` ポリシーの設定時に使用される DataWeave 2.0 式の例: ```text #[payload.client_id] #[payload.client_secret] ``` 要求ペイロードからログイン情報を取得するようにポリシーを設定できますが、この方法は API 仕様に反映させることが難しいため、お勧めしません。 ### [](#基本認証ヘッダーを使用したログイン情報の取得)基本認証ヘッダーを使用したログイン情報の取得 curl を使用する要求の例: ```text curl "http://localhost/myResource" -u 1234:abcd ``` ## [](#api-仕様の設定)API 仕様の設定 クライアント ID 適用ポリシーでは、ログイン情報の要件を実装するために API 仕様を変更する必要があります。 対応するポリシーの API 仕様に追加する必要がある RAML または OAS コードが含まれる、RAML または OAS スニペットリンクがあります。このコードには、API Manager で API 仕様の \[Policies (ポリシー)\] タブにある適用済みポリシーのリストからアクセスできます。 ## [](#ポリシーの出力)ポリシーの出力 クライアント ID 適用ポリシーが適用されていて、クライアントアプリケーションのログイン情報が無効または未承認の場合、保護されるリソースに対して HTTP 要求が実行されると、HTTP 応答に WWW Authenticate ヘッダーと次の値が含まれます。

カスタムモード

ヘッダー 'WWW-Authenticate'='Client-ID-Enforcement'

基本認証モード

ヘッダー 'WWW-Authenticate'='Basic realm="mule-realm"
SOAP アプリケーションの場合、応答は SOAP エラーです。 ## [](#関連情報)関連情報 - [レート制限: SLA ベースのポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-rate-limiting-sla) - [Mule OAuth プロバイダーを使用する OAuth 2.0 アクセストークン適用ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-oauth-access-token-enforcement) - [PingFederate OAuth 2.0 トークン適用ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-pingfederate-oauth-token-enforcement) - [OpenAM OAuth 2.0 トークン適用ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-openam-oauth-token-enforcement) - [JWT 検証ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-jwt-validation) - [API Manager における API インスタンスコントラクトの管理](https://docs.mulesoft.com/jp/api-manager/latest/manage-client-apps-latest-task) - [登録済みクライアントアプリケーションのクライアント ID とクライアントシークレットの取得](https://docs.mulesoft.com/jp/api-manager/latest/access-client-app-id-task) - [OpenID Connect OAuth 2.0 トークン適用ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-openid-token-enforcement) - [Mule ゲートウェイ起動暗号化](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-encryption-mule4) # クロスオリジンリソース共有 (CORS) ポリシー

ポリシー名

クロスオリジンリソース共有 (CORS)

概要

外部ドメインに存在するリソースへのアクセスを可能にする

カテゴリ

コンプライアンス

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

v4.1.1

返される状況コード

このポリシーの戻りコードは存在しません
## [](#概要)概要 CORS は、Web アプリケーションが別のドメインで定義されたリソースにアクセスできるメカニズムです。ブラウザーは、この標準をデフォルトで実装しています。CORS ポリシーは [「CORS W3C Recommendation (CORS W3C 勧告)」](https://fetch.spec.whatwg.org/)​の標準に準拠します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#mule-ゲートウェイ)Mule ゲートウェイ UI からポリシーを API に適用するときに、以下のパラメーターが表示されます。
要素 説明 必須?

Public resource (公開リソース)

CORS 設定を公開リソースとして適用するかどうか (デフォルト)。

はい

Default group (デフォルトグループ)

CORS 設定を特定のリソースにのみ適用するかどうか (​[Public resource (公開リソース)]​ を選択解除する必要があります)

いいえ

Support credentials (ログイン情報のサポート)

ポリシーが Cookie、認証ヘッダー、TLS クライアント証明書などのログイン情報をサポートするかどうか。

いいえ
## [](#非-api-ゲートウェイ-mule-環境の-cors-の設定)非 API ゲートウェイ Mule 環境の CORS の設定 Mule Runtime Engine (Mule) が API ゲートウェイ機能で有効になっておらず、CORS 機能を実装する必要がある場合、CORS インターセプターを使用できます。CORS インターセプターは、Mule 4.0 で使用可能になった HTTP リスナー設定の要素です。 CORS 設定は、CORS ポリシー機能を公開リソースとして利用するか、選択したオリジングループ用として利用するかによって異なります。 次の例は、選択したオリジングループ構造の設定可能な要素を示しています。 ```XML (collection of origins) ... ... ... ``` 次の例は、公開リソース構造の設定可能な要素を示しています。 ```XML ``` ## [](#cors-を使用する理由)CORS を使用する理由 CORS により、お使いの環境で Web ページのセキュリティと Web の整合性を実現できます。CORS ポリシーをバックエンドに適用する必要がある理由を知るには、まず​_オリジン_​と ​_Cookie_​ の働きと、これらを操作して Web ページの整合性が損なわれる仕組みについて理解する必要があります。 ### [](#origins)Web オリジンの概念 オリジンとは、フェッチを開始した要求を指定するヘッダーです。オリジンヘッダーにはサーバー名のみが含まれます (パス情報は含まれません)。非常に基本的なレベルでは、オリジンは以下から構成されます。 - URI スキーム: `http://` - ホスト名: `www.example.com` - ポート番号: `8080` 2 つの​[オリジン](#origins)​の間で要求を承認させるには、それらのオリジンが等しくなければなりません。これら 3 つのパラメーターがすべて一致した場合にのみ、オリジンは等しいと見なされます。詳細は、 [「RFC 6454 - The Web Origin Concept (Web オリジンの概念)」](https://tools.ietf.org/html/rfc6454)​を参照してください。 ### [](#http-cookie)HTTP Cookie Web サイトでは HTTP Cookie を使用してステートフルな情報を維持しています。最も一般的な例として、Web サーバーは認証 Cookie を使用して、ユーザーがログインしているかどうかと、ユーザーがログインしているアカウントを判断します。詳細は、 [RFC 6265](https://www.ietf.org/rfc/rfc6265.txt)​ を参照してください。 SOP (同一オリジンポリシー) は、1 つの Web ページから別のページを呼び出すときに悪意のある攻撃者による Cookie の不正利用を抑止します。たとえば、銀行の Web ページに Cookie を使用してログインした場合、攻撃者はその Cookie を不正に取得して、正規ユーザーになりすまして銀行の API に対してクエリを実行しようと試みます。 SOP を使用している場合、対象 Web ページのオリジンが呼び出し側の Web ページのオリジンと同じである場合にのみ、対象 Web ページのデータへのアクセスが許可されます。オリジンの詳細については、 [Wikipedia](https://en.wikipedia.org/wiki/Same-origin_policy)​ を参照してください。 次の例は、Web ページ ​`http://www.example.com:8080`​ のオリジンを示しています。 ![結果や理由を含め、URL 比較結果を示すテーブル](/mulesoft/current/ja-jp/mule-gateway/_images/cors-policy-sop-example.png) SOP は非常に制約が厳しいため、Web ページ上では、1 つのサブオリジンから別のサブオリジンや外部のハイパーリンクにはアクセスできません。たとえば、オリジン ​`www.testapply.com`​ に 2 つのサブオリジン ​`www.eng.testapply.com`​ および ​`www.docs.testapply.com`​ がある場合、これらのサブオリジン間の通信は拒否されます。さらに、各サブオリジンから外部 Web サイトへのハイパーリンクも拒否されます。 この問題を回避するため、Web ブラウザーでは CORS 標準を実装しており、この標準に従って Web サーバーを検証し、検証に成功すれば要求を受け入れるようにしています。 たとえば、銀行のログインサーバーで CORS サーバー側プロトコルが実装されている場合は、銀行の Web ページから直接クエリを実行しなければデータにはアクセスできません。外部の (銀行以外の) ドメインからログイン API に対してクエリを実行しても拒否されます。 ## [](#cors-の仕組み)CORS の仕組み Web ページがデータを要求すると、ブラウザーは要求が同じオリジンから出されているかどうかを検出して、CORS アルゴリズムを適用するかどうかを決定します。オリジンとは違う Web ページからデータのクエリを実行した場合は、CORS ポリシーが適用されます。 CORS アルゴリズムは、情報を要求した Web ページに対して Web サーバー上とクライアント側で実行されます。CORS ポリシーのクライアント側のアルゴリズムは次のように実装されます。 - 要求が複雑 (そして潜在的に危険) であるかどうかを判断し、事前の​_プリフライト_​要求を送信して、サーバーがオリジンを受け入れるかどうかを検証する。 - 実際の要求を実行し、サーバーが正しく応答してオリジンを受け入れることを検証する。 _プリフライト_​とは Web ブラウザーからバックエンドサーバーに送信される (HTTP メソッドとして OPTIONS を使用した) 事前要求であり、要求を実行しようとしている Web ページのアイデンティティ (オリジンと他のいくつかのヘッダー) をテストします。 バックエンドがオリジンを受け入れない場合、バックエンドサーバーは特定のヘッダー (Access-Control-Allow-Origin) なしで要求に応答します。これによってクライアントは、そのサーバーではページのオリジンが許可されないことを理解して、実際の要求を実行しません。 次の図は、実際の要求を実行するかどうかを決定する JavaScript フローの XMLHttpRequest (XHR) を示しています。 ![Javascript クロスドメイン XHR コールの標準レイテンシーと追加レイテンシーのプロセスを示すフローチャート](/mulesoft/current/ja-jp/mule-gateway/_images/cors-policy-xhr-diagram.png) 図に示されているように、ブラウザーとサーバーとの間の通信に基づいて要求が検証されます。 - 要求が複雑であると見なされた場合は (上記の XHR のクライアント側の図参照)、プリフライト要求が実行されます。 サーバーがプリフライトに対して適切なレスポンスヘッダーを返さない場合、クライアントライブラリ (上の例では XHR) は実際の要求を実行できません。 - プリフライトに対して正しく完全な応答が返された場合、クライアントライブラリは特定の CORS ヘッダーを含む実際の要求を実行します。 そしてクライアントライブラリは応答の CORS ヘッダーを検証します。いずれかの必須ヘッダーが欠落している場合、クライアントライブラリは再び、要求がクライアント (通常は Web ページ) に到達しないようにブロックする必要があります。 ## [](#cors-のコンポーネント)CORS のコンポーネント リクエストヘッダー、レスポンスヘッダー、公開リソースとグループ、順序、ワイルドカードなど、CORS ポリシーのさまざまなコンポーネントを設定できます。 ### [](#cors-リクエストヘッダー)CORS リクエストヘッダー - Origin: クロスオリジン要求を実行するオリジン。 - Access-Control-Request-Method: 実際の要求で呼び出されるメソッド。 このヘッダーは、プリフライト要求で送信されます。 - Access-Control-Request-Headers: 実際の要求で送信されるカスタムヘッダー。 このヘッダーは、プリフライト要求で送信されます。GET メソッドと HEAD メソッドに対しては、シンプルであるためプリフライトを必要としないヘッダーのリストが標準によって定義されています。カスタムヘッダーに対しては、GET 要求と HEAD 要求でプリフライトが実行されます (クライアントがプリフライトを実行する必要のないパスの検証については、上記の XHR の例を参照してください)。 ### [](#cors-レスポンスヘッダー)CORS レスポンスヘッダー 応答に含まれるヘッダーは、要求がプリフライトまたは実際の要求のどちらであるかによって異なります。 - `Access-Control-Allow-Origin`​: すべての応答で必須。 このヘッダーが応答に含まれていない場合、ブラウザーやクライアントライブラリは応答が Web ページに到達しないようにブロックします。ワイルドカードの「\*」を使用して任意のオリジンを表すことができます。 - `Access-Control-Allow-Methods`​: 実行が許可されているメソッド。 このヘッダーは、OPTIONS 要求で返されます。サーバーは、許可されるメソッドのリストを応答で返し、検証をクライアントに委任する場合があります。 - `Access-Control-Allow-Headers`​: 実際の要求で許可されるヘッダー。 このヘッダーは、Access-Control-Allow-Methods と同じように機能します。 - `Access-Control-Allow-Credentials`​: Cookie を使用して実際の要求を実行できるかどうかをクライアントに通知します。 `Access-Control-Allow-Credentials`​ はブール値を返します。 - `Access-Control-Expose-Headers`​: 要求を実行した Web ページがアクセスできるヘッダーのリストをブラウザーまたはクライアントライブラリに提供します。 CORS 要求を実行している HTTP ライブラリは、ヘッダーのみを Web ページに提供することで、プライバシーとセキュリティを強化します。 - `Access-Control-Max-Age`​: ブラウザーが要求に対する 2 回目のプリフライトの実行を回避できる期間 (秒数) を指定します。 ### [](#公開リソースとグループ)公開リソースとグループ ブラウザー SOP をバイパスする必要がある場合に備えて、MuleSoft では公開リソースを設定するためのオプションを用意しており、応答に含まれるプリフライトデータを API ゲートウェイポリシーに反映できるようにしています。これにより、すべての CORS ヘッダーで実際の要求が正しく更新され、ブラウザーは応答を受け入れます。 お使いの環境において、公開リソースオプションでは十分な安全性を確保できない場合には、API に対してクエリを実行する異なるオリジンに対して複数のグループを定義してください。各グループはオリジンのリストに適用され、グループごとに異なるメソッド、ヘッダー、プリフライトキャッシュ時間、ヘッダー公開設定を指定できます。 ### [](#順序)順序 CORS ポリシーは API ゲートウェイによって常に最初に適用され、その後に他のポリシーが適用できるようになります。CORS ポリシーが適用されているアプリケーションに OPTIONS を使用している保護された要求が送信された場合、要求は保護されたリソースに到達しません。 [CORS 仕様](https://fetch.spec.whatwg.org/#resource-preflight-requests)​に従い、すべての OPTIONS 要求はプリフライトとみなされます。 ### [](#設定ワイルドカード)設定ワイルドカード グループ設定のオリジンセクションとヘッダーセクションではワイルドカード (​`*`​) を使用できます。ワイルドカードは、公開リソースが必要でありながらも、受け入れられる HTTP メソッドを制限する必要がある場合に使用します。 複数のグループを設定してあり、いずれかのグループでワイルドカードを使用してオリジンを指定してある場合、ワイルドカードを使用していない設定の方がワイルドカードによる指定よりも優先されます。 ## [](#faqs)FAQs **CORS ポリシーが適用されていないようです。** curl や Postman などのツールを使用して複雑な要求の CORS ポリシーをテストすると、CORS リクエストヘッダーが追加されず、プリフライトが実行されません。 要求で CORS ヘッダーが送信されないか、不適切なヘッダーが使用されていると、API ゲートウェイ CORS ポリシーは CORS レスポンスヘッダーを追加しません。これはポリシーが適用されないことを意味します。ライブラリで環境に適した CORS プロトコルが実装されていること、または仕様で正しいヘッダーを設定していることを確認してください。 # ゲートキーパーによるセキュリティ強化 アプリケーションをデプロイすると、アプリケーションによって公開された追跡対象のリソースが、セキュリティの短い空白時間のためにアクセス可能になる場合があります。これらのリソースにはポリシーがまだ適用されていないため、API は不要なトラフィックを受け取ることがあります。ゲートキーパーは、すべてのポリシーがエラーなく取得されて適用されるまで追跡対象リソースをブロックしてこの状況を回避します。 CloudHub 4.2.2 以降、ポリシーでコントラクトが必要な場合、およびゲートキーパーが有効になっている場合に、Mule Runtime Engine (Mule) は API のコントラクトが管理プレーンから正常にダウンロードされるまで API をブロックし続けます。ゲートキーパーは、API のブロックを解除するコントラクトが使用可能になるまで待機します。 以前のバージョンの Mule では、ランタイムがすべてのポリシーを正常に適用した後に API のブロックが解除されていました。たとえば、API にクライアント ID 適用ポリシーが適用されている場合、有効なログイン情報を含む要求が拒否されていました。 この CloudHub の更新は、​`strict`​ および ​`flexible`​ ゲートキーパーモードと同じように動作します。Mule の再起動前後にコントラクトサービスからダウンロードされたコントラクトは、使用可能とみなされます。 コントラクトが必要な可能性がある標準のポリシーを次に示します。 - [クライアント ID 適用ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-client-id-enforcement) - [レート制限 SLA ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-rate-limiting-sla) - [JWT 検証ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-jwt-validation) - [PingFederate OAuth 2.0 トークン適用ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-pingfederate-oauth-token-enforcement) - [OpenID Connect OAuth 2.0 トークン適用ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-openid-token-enforcement) - [Mule OAuth 2.0 アクセストークン適用](https://docs.mulesoft.com/jp/mule-gateway/policies-included-oauth-access-token-enforcement) ## [](#ゲートキーパーの動作)ゲートキーパーの動作 ゲートキーパーメカニズムは、ランタイムを再起動した場合、または自動検出によって API インスタンスにリンクされた追跡対象リソースを再デプロイした場合にのみ適用されます。ゲートキーパーが適用されると、API Manager ですべての API インスタンスポリシーがエラーなく適用されるまで、追跡対象の各リソースがブロックされ、​`503 - Service Unavailable`​ HTTP 状況コードが返されます。 自動検出時に API インスタンスにリンクされていないリソースは、ゲートキーパーでは無視されます。また、これらのリソースにはポリシーを適用することはできず、分析情報も生成されません。Mule インスタンスの再起動後または追跡対象の Mule アプリケーションの再デプロイ後に接続が失われると、ゲートキーパーが有効化されていない場合でも、キャッシュされているポリシー、設定、コントラクトが使用されます。 ゲートキーパーが適用され、追跡対象のリソースに不正なポリシーや定義が正しくないポリシーが適用されると、追跡対象のリソースがブロックされて ​`503 - Service Unavailable`​ HTTP 状況コードが返されます。問題のポリシーが API Manager から削除されるまで、リソースはブロックされたままになります。Mule Runtime は、すべてのポリシーと、アクティブなコントラクトをローカルにキャッシュします。 ## [](#セキュリティレベル)セキュリティレベル ゲートキーパー機能を有効または無効にするには、特定のセキュリティレベルで次のプロパティを設定します。 anypoint.platform.gatekeeper たとえば、​`flexible`​ セキュリティレベルを設定するには、次のプロパティを指定する必要があります。 anypoint.platform.gatekeeper=flexible - Mule 4 セキュリティレベルの有効な値 - `strict` - `flexible` - `disabled` - Mule 3 セキュリティレベルの有効な値 - `true` - `false` - `strict` - `flexible` Mule Runtime バージョン 4.8.0 以降の場合、ポリシー設定を編集するときはゲートキーパーによって要求がブロックされ、ポリシー順序を編集するときはゲートキーパーによって要求がブロックされません。編集中にゲートキーパーを無効にするには、​`anypoint.platform.gatekeeper`​ プロパティを ​`false`​ に設定します。 anypoint.platform.gatekeeper.block\_edit=false ### [](#セキュリティレベルの定義)セキュリティレベルの定義 下表に示すように、ゲートキーパーには ​`false`​、​`disabled`​、​`true`​、​`strict`​、または ​`flexible`​ セキュリティレベルを適用できます。

セキュリティレベル

Description (説明)​

Mule 3.x のレベル

Mule 4.x のレベル

false

ゲートキーパーは一切のセキュリティを適用せず、ポリシーがエラーなく完全に適用されるまでは API が不要なトラフィックを受け取る場合があります。

後方互換性のみを目的としています。

disabled​ に置き換えられました。

disabled

ゲートキーパーは一切のセキュリティを適用しません。この設定では、ポリシーが適用されている間に API が不要なトラフィックを受け取る場合があります。

使用不可

Available (使用可能)

true

この設定では、デフォルトのセキュリティレベルが ​Strict​ に設定されます。

後方互換性のみを目的としています。代わりに ​strict​ または ​flexible​ を使用します。

使用不可

strict

ゲートキーパーのセキュリティは最大レベルに設定されます。Mule インスタンスが再起動すると、追跡対象の各リソースにポリシーが正しく適用されるまで API が ​503​ エラーでブロックされます。ゲートキーパーが適用されている状態で Anypoint Platform との接続が失われると、接続が再確立されるまで追跡対象リソースがブロックされます。

Available (使用可能)

Available (使用可能)

flexible

ゲートキーパーのセキュリティは中間レベルに設定されます。Mule インスタンスが再起動すると、API は ​503​ エラーでブロックされます。ゲートキーパーが適用されている状態で Anypoint Platform との接続が失われると、接続が失われている間はローカルキャッシュを使用してポリシーが適用されます。キャッシュが使用できない場合は、少なくとも接続が再確立されるまでは追跡対象リソースがブロックされます。

v3.8.6 以降と v3.9.0 以降で使用可能

v4.1.0 以降で使用可能
### [](#デフォルトのゲートキーパー設定)デフォルトのゲートキーパー設定 デフォルト値でのゲートキーパーの設定を下表に示します。

ランタイムバージョン

デフォルトセキュリティレベル

3.8.5

Strict

3.8.6 以降の 3.8.x

Flexible

3.9.0

Strict

3.9.1 以降の 3.9.x

Flexible

4.0.0

Strict

4.1.0 以降

Flexible
## [](#mule-v3-x-でのゲートキーパーの問題のトラブルシューティング)Mule v3.x でのゲートキーパーの問題のトラブルシューティング 特定の種別のポリシーでゲートキーパーの問題が発生する場合があります。 ### [](#リソースレベルのポリシーが適用されてもゲートキーパーが-api-のブロックを解除しない)リソースレベルのポリシーが適用されてもゲートキーパーが API のブロックを解除しない Mule 3.x では、RAML プロキシまたは APIkit ルーターを含む API 実装に対してのみリソースレベルポリシーを適用できます。API にリソースレベルポリシーが適用されてもゲートキーパーが API を繰り返しブロックする場合は、次の理由が考えられます。 - リソースレベルポリシーの設定時に選択した URI とメソッドの式が、RAML 定義で指定されているリソースと一致しない。 このエラーを回避するには、API Manager で特定のリソースレベルポリシーを設定するときに ​`Preview Resource Matching`​ オプションを使用してください。 - Mule アプリケーションで定義されている自動検出要素で ​`apikitRef`​ 属性が指定されていない。 この問題を修復するには、ルーターが使用している APIkit 設定の名前を ​`apikitRef`​ 属性に追加してください。 # シンプルセキュリティマネージャーポリシー シンプルセキュリティマネージャーポリシーでは、ポリシーレベルで定義できるユーザー名とパスワードを使用してセキュリティマネージャーを設定できます。 ## [](#前提条件)前提条件 このドキュメントは、読者が、管理される API バージョンの API バージョン所有であること、または組織システム管理者ロールのメンバーであることを前提としています。 ## [](#このポリシーのしくみ)このポリシーのしくみ このポリシーは、セキュリティマネージャーを必要とするポリシー (基本認証ポリシーなど) によって使用されるシンプルセキュリティマネージャーとして機能します。1 つのユーザー名とパスワードの組み合わせのみを検証します。通常、テスト/デモ目的に使用されます。 このポリシーをセットアップするときには、以前に設定したユーザー名とパスワードを指定する基本認証メカニズムを使用し、API に要求を送信する必要があります。 ## [](#ポリシーの設定)ポリシーの設定
要素 説明

Username (ユーザー名)

シンプルセキュリティマネージャーポリシーが要求の認証に使用するユーザー名。

Password (パスワード)

シンプルセキュリティマネージャーポリシーが要求の認証に使用するパスワード。
## [](#関連情報)関連情報 - [LDAP セキュリティマネージャー](#api-manager::policy-mule3-ldap-security-manager.adoc) # スパイク制御ポリシー

ポリシー名

スパイク制御

概要

API トラフィックを規制する

カテゴリ

サービス品質

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

v4.1.0

返される状況コード

429 - HTTP API による要求の数が設定された制限を超えました。指定された再試行回数を超えると要求は拒否されます。

400 - SOAP v1.2 を使用している WSDL API による要求の数が設定されている制限を超過しました。指定された再試行回数を超えると要求は拒否されます (Mule のみ)。

500 - SOAP v1.1 を使用している WSDL API による要求の数が設定されている制限を超過しました。指定された再試行回数を超えると要求は拒否されます (Mule のみ)。
## [](#概要)概要 スパイク制御ポリシーは、API で処理されるメッセージ数を制限して、API 要求トラフィックを規制します。このポリシーにより、指定された時間内に処理されるメッセージ数が、設定した制限を超えなくなります。この数を超えると、要求はキューに入り、設定したポリシーに基づいて再試行されます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 スパイク制御ポリシーでは、クォータの適用は実行されません。設定パラメーターは、API およびバックエンドを保護するために制限されています。そのため、パフォーマンスを最大化するには、これらのパラメーターに設定する値をできる限り小さくします。 ### [](#mule-ゲートウェイ)Mule ゲートウェイ UI からポリシーを API に適用するときに、以下のパラメーターが表示されます。
要素 説明 必須

Number of Reqs (要求の数)

指定されたウィンドウで許可されている要求数/ミリ秒

はい

Time Period (期間)

要求の処理する期限 (ミリ秒)

はい

Delay Time in Milliseconds (遅延時間 (ミリ秒))

クォータが残っていない場合の再試行までの各要求の保持時間 (ミリ秒)

はい

Delay Attempts (遅延試行回数)

要求が再試行される回数。これを超えると拒否されます。

はい

Queuing Limit (キュー制限)

特定の期間にキューに入れることができる要求数

いいえ

Expose Headers (ヘッダーを公開)

内部 API の場合にのみ有効にします。ポリシーがアルゴリズムの動作に関する情報を X-RateLimit ヘッダーで返すことができるようにします。

いいえ

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション

はい
要求クォータを適用する方法は、​[「レート制限 SLA ポリシー」](https://docs.mulesoft.com/jp/mule-gateway/policies-included-rate-limiting-sla)​と​[「レート制限ポリシー」](https://docs.mulesoft.com/jp/mule-gateway/policies-included-rate-limiting)​を参照してください。 ## [](#ポリシーのしくみ)ポリシーのしくみ スパイク制御ポリシーは、​_スライディングウィンドウアルゴリズム_​を使用して、トラフィックの急増を緩和し、ゲートウェイインスタンスを保護します。ウィンドウの表示サイズは、結果の推移に合わせて自己調整されます。 現在のウィンドウに要求クォータが残っていない場合は、クライアントとの接続を閉じずに、後で処理するように要求をキューに入れることができます。ポリシーで要求をキューに入れるには、次の例に示すようにポリシーパラメーターを設定する必要があります。 - `Time Period`​: 1 秒 - `Number of Reqs`​: 2 - `Delay Time in Milliseconds`​: 499 ミリ秒 - `Delay Attempts`​: 1 - `Queuing Limit`​: 5 要求をキューに入れると、スレッドと HTTP 接続を保持する必要があります。ポリシーで ​`Queuing Limit`​ パラメーターを指定すると、リソースが不足しないようにゲートウェイが保護され、攻撃を受けた場合でも API が失敗しなくなります。 ## [](#要求のタイムライン)要求のタイムライン 次の図は、前のセクションで定義された設定を使用して、アルゴリズムによって受け入れられた各要求の有効期限を示しています。 ![要求の受け入れ、拒否、キューのタイムラインを示すタイムライン](/mulesoft/current/ja-jp/mule-gateway/_images/spike-control.png) 1. 最初の 2 つの要求が受け入れられ、使用可能なクォータが 0 になります。 要求 1 から 1 秒 (​`window size`​ 値) 経過後にクォータが 1 に増えます。 2. 要求 3 を受信します。 使用可能なクォータがないため、この要求は 499 ミリ秒間キューに入れられます。 3. 要求 4 を受信します。 まだ使用可能なクォータがないたえ、この要求は 499 ミリ秒間キューに入れられます。 4. 要求 3 を再試行する少し前に、要求 1 で 1 秒経過したため、ウィンドウの範囲外になり、クォータが解放されます。 5. クォータが 1 になり、要求 3 が正常に再処理されます。 要求 2 で 1 秒経過するまでクォータは 0 に戻ります。 6. 要求 4 の遅延が終了したため再処理が必要です。 要求 4 が拒否されます。使用できるクォータが残っていないため、要求 2 と 3 で 1 秒が経過していません。要求 4 はそれ以上遅延しません。 7. 要求 5 を受信します。 要求 2 ですでに 1 秒以上経過したので、この要求は受け入れられます。 この例は、要求の遅延と、キューに入れてトラフィックの急増を規制する方法を示しています。競合の多いシナリオでは、バックエンドが適切に機能し続けます (最後の Y ミリ秒に処理される要求数が X を超えない)。 API を照会するユーザーには、レイテンシーは長くなりますが、要求が処理中であることが表示される場合があります。ポリシーの正確な設定は API とそのスループットのみに依存します。 ## [](#faq)FAQ **このスライディングウィンドウはいつ開始されますか?** このウィンドウは、ポリシーが正常に適用された後の最初の要求で開始されます。 **アルゴリズムが使用するウィンドウの種別は?** アルゴリズムは、スライディングウィンドウを使用して、ポリシーで設定されている期間でトランザクションを監視します。 **クォータを使い果たすとどうなりますか?** 要求クォータを使い果たすと、スパイク制御ポリシーによって要求がキューに登録され、設定に従って再試行されます。複数回の再試行後もクォータが残っていない場合、要求は拒否されます。他の要求用のクォータは、最初の要求がポリシーで設定されている時間制限を超えてから使用可能になります。このようにして、要求が循環して処理されます。 **複数のウィンドウを設定できますか?** いいえ。 スパイク制御ポリシーにより、バックエンドサーバーが処理容量を超えた数の要求を処理しないことが保証されます。説明責任を果たす必要がある場合は、レート制限 SLA ポリシーまたはレート制限ポリシーを使用してください。 **各レスポンスヘッダーの意味は?** 各レスポンスヘッダーは、要求の現在の状態に関する情報を返します。 - X-Ratelimit-Remaining: 現在使用可能なクォータ量 - X-Ratelimit-Limit: 各ウィンドウで使用可能な最大要求数 - X-Ratelimit-Reset: 最も古い要求がスライディングウィンドウの外に出るまでの残り時間 (ミリ秒)。 クォータがまだ使用できる場合、引き続きアルゴリズムで新しい要求を処理できるため、ヘッダーは 0 (ゼロ) に設定されます。 デフォルトでは、応答の X-RateLimit ヘッダーは無効になっています。これらのヘッダーを有効にするには、ポリシーの設定時に ​**\[Expose Headers (ヘッダーを公開)\]**​ を選択します。 **スパイク制御を Mule クラスターで使用できますか?** いいえ。このポリシーはゲートウェイインスタンスを保護します。アーキテクチャで Mule クラスターを使用する場合は、スパイク制御ポリシーを使用して各インスタンスを別々に保護してください。 **レート制限 SLA やスパイク制御ではなくレート制限 SLA ポリシーを使用する必要がある状況は?** レート制限 SLA ポリシーとレート制限 SLA ポリシーは、説明責任を果たすためにハード制限を (レート制限で識別子を使用して) グループまたは (レート制限 SLA を使用して) クライアントアプリケーションに適用する場合に使用します。バックエンドを保護するには、代わりにスパイク制御を使用してください。 # デトークナイゼーションポリシー

ポリシー名

デトークナイゼーション

概要

トークナイズされた値を元の値に戻します。このポリシーは、Anypont Runtime Fabric のデプロイメントでのみ機能するように設計されています。

カテゴリ

セキュリティ

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

v4.1.1

返される状況コード

400

指定した式が無効であるか、デトークナイズする結果を返さない。

NOTE​: 返される状況コードを設定することができます。

502 - トークナイゼーションサービスへの接続が使用できないか、設定されていない。
## [](#概要)概要 デトークナイゼーションは、以前にマスクされた機密データを元の値に戻すプロセスで、機密情報の漏洩リスクを減らします。データをトークナイズして、機密情報をトークンに置き換え、機密情報の漏洩リスクを減らすことができます。 たとえば、クレジットカードの月次報告書を生成する場合、アプリケーションから銀行口座番号やクレジットカード番号が要求されることがあります。デトークナイズされた機密データは、必ず厳格なセキュリティ制御の下で読み取る必要があります。 ## [](#前提条件)前提条件 デトークナイゼーションポリシーを適用し、管理するには、以下が必要です。 - **「Manage Policies (ポリシーの管理)」**​権限の取得 - [トークナイゼーションサービスを設定し、使用する](https://docs.mulesoft.com/jp/anypoint-security/tokenization-example)​には、以下が必要です。 - Runtime Fabric のインストール - **「Manage Tokenization Services (トークナイゼーションサービスの管理)」**​権限の取得 - 稼働中のトークナイゼーションサービス ## [](#スコープと考慮事項)スコープと考慮事項 このポリシーを適用する前に、次の考慮事項を確認してください。 - ポリシーの 1 つのインスタンスでは、トークナイゼーションサービスが 1 つだけサポートされます。 設定した形式はすべて同じトークナイゼーションサービスに含まれている必要があります。 - ポリシーの 1 つのインスタンスを使用して、要求と応答の両方ではなく、どちらか一方の値をトークナイズできます。 - トークナイゼーションサービスを削除した場合、またはトークナイゼーションサービスが稼働していない場合、ポリシーはサービスとの通信を確立できません。これにより、サービスが再び使用可能になるまで、すべての要求が失敗します。 - ポリシー設定時のサービスメニューには、使用できるトークナイゼーションサービスのみが表示されます。 目的のサービスが表示されない場合、すでにデプロイされているかどうかを確認してください。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#mule-ゲートウェイ)Mule ゲートウェイ このポリシーを API に適用するときに、以下の項目が UI に表示されます。
要素 説明 必須

Direction (方向)

要求と応答 (デフォルト) のどちらからデトークナイズする値が抽出されるのか。

はい

Fail on unmatched expressions (式の不一致により失敗)

選択すると、式とトークンが一致しない場合に要求が失敗する。

いいえ

サービス

現在の組織と環境で使用可能なトークナイゼーションサービス。リストから必要なサービスを選択します。使用可能な形式は、選択したサービスによって異なります。

はい

式

デトークナイズされる情報を抽出するために使用するセレクター式。

次に例を示します。

#[payload.people.creditCardNumber]

項目の区切り文字としてドットを使用する式のみが許可されています。​[payload.people.creditCardNumber]​ は有効ですが、​#[payload[‘people’]]​ は無効です。

いいえ
セレクター式を指定しない場合、ポリシーは適用されますが、ペイロードからは何もデトークナイズされません。

形式

デトークナイズされる情報の種別。形式は選択したサービスによって異なる場合があります。リストから形式を 1 つ選択します。

リストに形式が表示されない場合、選択したトークナイゼーションサービスに少なくとも 1 つの形式が含まれていることを確認してください。
詳細は、​「トークナイゼーション形式」​記事を参照してください。

いいえ
形式を指定しない場合、ポリシーは適用されますが、ペイロードからは何もデトークナイズされません。
## [](#ポリシーのしくみ)ポリシーのしくみ デトークナイゼーションポリシーは、ペイロード内のトークナイズされた情報を元の値に戻します。ペイロード内のどのデータをデトークナイズするのかを定義するには、セレクター式を指定する必要があります。 **例** ポリシーを受信するペイロードに次の構造が含まれているとします。 ```JSON { "name":"Amun Ra", "socialSecurityNumber":"167-47-9268" } ``` 社会保障番号 (socialSecurityNumber) をデトークナイズする場合、次のセレクター式を使用して、ポリシーによってトークナイズされる情報を指定できます。 ```expression #[payload.socialSecurityNumber] ``` このセレクターを使用すると、最上位レベルに ​`socialSecurityNumber`​ キーを含む要求をポリシーが受信するたびに、指定した式に一致するトークンがすべて抽出されます。次にトークナイゼーションサービスとの接続が確立され、ペイロード内のトークナイズされた値が元の値に置き換えられます。 例の社会保障番号のデトークナイズされた値が ​_365-93-2738_​ だった場合、アプリケーションは次のペイロードを受信します。 ```json { "name":"Amun Ra", "socialSecurityNumber":"365-93-2738" } ``` ペイロードの要求または応答の値をデトークナイズするようにデトークナイゼーションポリシーを設定できます。 ### [](#要求のデトークナイズ)要求のデトークナイズ 要求をデトークナイズすると、次のイベントが発生します。 ![セキュリティ、トークナイゼーション、Mule アプリケーション間のデータフローを示す図](/mulesoft/current/ja-jp/mule-gateway/_images/policy-mule4-tokenization-67b25.png) 1. ユーザーがポリシーで保護されたアプリケーションに要求を実行します。 2. 要求は最初に Anypoint Security に送信され、その後アプリケーションのデトークナイゼーションポリシーに送信されます。 3. デトークナイゼーションポリシーにより、セレクター式を使用してトークンがペイロードから抽出されます。 4. デトークナイゼーションサービスは、トークンを受信して元の機密値に戻し、その結果をポリシーに送信します。 5. ポリシーによってトークナイズされたペイロードがデトークナイズされた値に置き換えられ、Mule アプリケーションに転送されます。 6. Mule アプリケーションは要求を処理して結果を返します。 ### [](#応答のデトークナイズ)応答のデトークナイズ 応答をデトークナイズすると、次のイベントが発生します。 ![トークナイゼーションサービスのデータフローを示す図](/mulesoft/current/ja-jp/mule-gateway/_images/policy-mule4-tokenization-9347d.png) 1. ユーザーがポリシーで保護されたアプリケーションに要求を実行します。 2. 要求は最初に Anypoint Security に送信され、その後アプリケーションのデトークナイゼーションポリシーに送信されます。 3. デトークナイゼーションポリシーはペイロードから何も抽出せずに要求をリダイレクトします。 4. Mule アプリケーションは要求を処理して結果を返します。 5. デトークナイゼーションポリシーにより、セレクター式を使用してトークンがペイロードから抽出されます。 6. デトークナイゼーションサービスは、トークンを受信して元の機密値に戻し、その結果をポリシーに送信します。 7. ペイロード内にデトークナイズされた値を含む応答がポリシーからユーザーに返されます。 ## [](#関連情報)関連情報 - [トークナイゼーションサービス](https://docs.mulesoft.com/jp/anypoint-security/tokenization) - [デトークナイゼーションポリシーリリースノート](https://docs.mulesoft.com/jp/release-notes/policies/detokenization-release-notes) # トークナイゼーションポリシー

ポリシー名

Tokenization (トークナイゼーション)

概要

機密データをトークンと呼ばれる非機密データ要素に変換する

カテゴリ

セキュリティ

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

v4.1.1

返される状況コード

400

トークンが無効であるか、トークナイゼーションが失敗した。

指定した式が無効であるか、トークナイズする結果を返さない。

返される状況コードは設定することができます。

502 - トークナイゼーションサービスへの接続が使用できないか、設定されていない。
## [](#概要)概要 トークナイゼーションは、機密データとみなされる可能性がある値または情報を、デトークナイゼーションの概念を使用してその元の値にマップできるトークンにマスクするプロセスです。API に機密データが含まれている場合、トークナイゼーションポリシーはそれを保護するための非常に効果的な方法です。 データは元の値と同じ形式で表示されますが、その実際の値は最初はわかりません。
このポリシーは、Anypont Runtime Fabric のデプロイメントでのみ機能するように設計されています。
トークナイゼーションは、サードパーティがデータにアクセスする場合に、機密データが元の値と同じになるリスクを最小限に抑えます。たとえばこのポリシーを使用して、クレジットカード番号、個人情報 (PII)、保護健康情報 (PHI)、同様の機密データを非表示にできます。 ## [](#前提条件)前提条件 トークナイゼーションポリシーを適用し、管理するには、以下が必要です。 - **「Manage Policies (ポリシーの管理)」**​権限の取得。 - トークナイゼーションサービスを​[設定](https://docs.mulesoft.com/jp/anypoint-security/tokenization-example)​し、実行するには、以下が必要です。 - Runtime Fabric のインストール - **「Manage Tokenization Services (トークナイゼーションサービスの管理)」**​権限の取得 - 稼働中のトークナイゼーションサービス ## [](#スコープと考慮事項)スコープと考慮事項 このポリシーを適用する前に、次の考慮事項を確認してください。 - ポリシーの 1 つのインスタンスでは、トークナイゼーションサービスが 1 つだけサポートされます。 設定した形式はすべて同じトークナイゼーションサービスに含まれている必要があります。 - ポリシーの 1 つのインスタンスを使用して、要求と応答の両方ではなく、どちらか一方の値をトークナイズできます。 - ポリシーは、実行時までトークナイゼーションサービスの状態を認識しません。トークナイゼーションサービスを削除した場合、またはトークナイゼーションサービスが稼働していない場合、ポリシーはサービスとの通信を確立できません。これにより、サービスが再び使用可能になるまで、すべての要求が失敗します。 ポリシー設定時のサービスメニューには、使用できるトークナイゼーションサービスのみが表示されます。 目的のサービスが表示されない場合、すでにデプロイされているかどうかを確認してください。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード トークナイゼーションポリシーは、Flex Gateway のローカルモードではサポートされません。 ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード トークナイゼーションポリシーは、Flex Gateway の接続モードではサポートされません。 ### [](#mule-ゲートウェイ)Mule ゲートウェイ UI からポリシーを API に適用するときに、以下のパラメーターが表示されます。
要素 説明 必須

Direction (方向)

要求と応答のどちらからトークナイズする値が抽出されるのか (デフォルト)。

はい

Fail on unmatched expressions (式の不一致により失敗)

選択すると、式とトークンが一致しない場合に要求が失敗する。

いいえ

サービス

現在の組織と環境で使用可能なトークナイゼーションサービス。リストから必要なサービスを選択します。使用可能な形式は、選択したサービスによって異なります。

はい

式

トークナイズされる情報を抽出するセレクター式。

次に例を示します。

#[payload.people.creditCardNumber]

項目の区切り文字としてドットを使用する式のみが許可されています。​#[payload.people.creditCardNumber]​ は有効ですが、​#[payload[‘people’]]​ は無効です。

いいえ。
セレクター式を指定しない場合、ポリシーは適用されますが、ペイロードからは何もトークナイズされません。

形式

トークナイズされる情報の種別。形式は選択したサービスによって異なります。

リストに形式が表示されない場合、選択したトークナイゼーションサービスに少なくとも 1 つの形式が含まれていることを確認してください。

いいえ
形式を指定しない場合、ポリシーは適用されますが、ペイロードからは何もトークナイズされません。
## [](#ポリシーのしくみ)ポリシーのしくみ トークナイゼーションポリシーは、メッセージペイロードの機密データ部分をトークナイズされた値に置き換えます。どの情報をトークナイズするのかを定義するには、セレクター式を使用する必要があります。 ### [](#例)例 ポリシーを受信するペイロードに次の構造が含まれているとします。 ```JSON { "name":"Amun Ra", "socialSecurityNumber":"365-93-2738" } ``` 社会保障番号 (socialSecurityNumber) をトークナイズする場合、次のセレクター式を使用できます。 ```expression #[payload.socialSecurityNumber] ``` 最上位レベルに ​`socialSecurityNumber`​ を含む要求をポリシーが受信するたびに、まず指定した式に一致するトークンがすべて抽出されます。次にトークナイゼーションサービスとの接続が確立され、最後にペイロード内のトークナイズされた値が、サービスから提供された値に置き換えられます。 例の社会保障番号のトークナイズされた値が 167-47-9268 だった場合、アプリケーションは次のペイロードを受信します。 ```json { "name":"Amun Ra", "socialSecurityNumber":"167-47-9268" } ``` ペイロードの要求または応答の値をトークナイズするようにトークナイゼーションポリシーを設定できます。 ### [](#要求のトークナイズ)要求のトークナイズ 要求をトークナイズすると、次のイベントが発生します。 ![セキュリティ、トークナイゼーション、Mule アプリケーション間のデータフローを示す図](/mulesoft/current/ja-jp/mule-gateway/_images/policy-mule4-tokenization-67b25.png) 1. ユーザーがポリシーで保護されたアプリケーションに要求を実行します。 2. 要求は最初に Anypoint Security に送信され、その後アプリケーションのトークナイゼーションポリシーに送信されます。 3. トークナイゼーションポリシーにより、セレクター式に一致するすべてのトークンが抽出されます。 4. トークナイゼーションサービスは、トークンを受信して変換した後、その結果をポリシーに返します。 5. ポリシーによってペイロードがトークナイズされた値に置き換えられ、Mule アプリケーションに転送されます。 6. Mule アプリケーションは要求を処理して結果を返します。 ### [](#応答のトークナイズ)応答のトークナイズ 応答をトークナイズすると、次のイベントが発生します。 ![トークナイゼーションサービスのデータフローを示す図](/mulesoft/current/ja-jp/mule-gateway/_images/policy-mule4-tokenization-9347d.png) 1. ユーザーがポリシーで保護されたアプリケーションに要求を実行します。 2. 要求は最初に Anypoint Security に送信され、その後アプリケーションのトークナイゼーションポリシーに送信されます。 3. トークナイゼーションポリシーは Mule の応答をトークナイズし、ペイロードから何も抽出せずに要求をリダイレクトします。 4. Mule アプリケーションは要求を処理して結果を返します。 5. トークナイゼーションポリシーにより、セレクター式を使用してトークンがペイロードから抽出されます。 6. トークナイゼーションサービスは、トークンを受信して変換した後、その結果をポリシーに返します。 7. ペイロード内にトークナイズされた値を含む応答がトークナイゼーションポリシーからユーザーに返されます。 ## [](#関連情報)関連情報 - [トークナイゼーションサービス](https://docs.mulesoft.com/jp/anypoint-security/tokenization) - [トークナイゼーション形式](https://docs.mulesoft.com/jp/anypoint-security/tokenization-formats) - [トークナイゼーションポリシーリリースノート](https://docs.mulesoft.com/jp/release-notes/policies/tokenization-release-notes) # プロキシサーバー経由の Mule ゲートウェイトラフィックのルーティング プロキシサーバー経由で外部通信を制限するファイアウォールの内側で Mule Runtime Engine が実行されている場合、プロキシサーバー経由で API Manager にトラフィックをルーティングするように Mule ゲートウェイを設定できます。 Mule ゲートウェイは、プロキシを使用した通信で、基本、NTLM、Kerberos v5 (SPNEGO 経由) 認証スキームをサポートします。 ## [](#configure-the-proxy-server)プロキシサーバーの設定 プロキシサーバー経由で接続するように Mule ゲートウェイを設定するには、​`$MULE_HOME/conf/wrapper.conf`​ ファイルに次のプロパティを追加してプロキシサーバー設定をセットアップします。 - `wrapper.java.additional.=-Danypoint.platform.proxy_host={hostname}` - `wrapper.java.additional.=-Danypoint.platform.proxy_port={port}` - `wrapper.java.additional.=-Danypoint.platform.proxy_username={username}` - `wrapper.java.additional.=-Danypoint.platform.proxy_password={password}`
これらのパラメーターは、起動時に Java に渡される追加オプションです。​<n>​ 要素は、設定の追加パラメーターの数を指します。​1​ から始まり、連続した数値で順次増分されます。
ログイン情報が指定されている場合、Mule ゲートウェイは NTLM よりも基本認証を優先します。基本認証に失敗した場合、Mule ゲートウェイは NTLM で認証します。 ### [](#プロキシ認証での-kerberos-の使用)プロキシ認証での Kerberos の使用 Kerberos を使用して認証するには、​[プロキシサーバーの設定](#configure-the-proxy-server)​のパラメーターと次の新しいプロパティを追加します。 - `wrapper.java.additional.=-Danypoint.platform.proxy_kerberos_krb5_path={/path/to/krb5.conf}` - `wrapper.java.additional.=-Danypoint.platform.proxy_kerberos_jaas_path={/path/to/kerberos.jaas}`
API Kerberos 認証は 2024 年 7 月 2 日以降にリリースされた Mule Runtime バージョン 4.3.x および 4.4.x と Mule Rruntime バージョン 4.6.5、4.7.1、およびそれ以降でのみサポートされます。
#### [](#kerberos-krb5-パス)Kerberos KRB5 パス プロパティ ​`anypoint.platform.proxy_kerberos_krb5_path`​ では、KRB5 サーバーを見つけるために使用される ​`krb5.conf`​ ファイルを指定します。このファイルの例を次に示します。 ```text [libdefaults] kdc_realm = service.ws.apache.org default_realm = service.ws.apache.org udp_preference_limit = 1 kdc_tcp_port = 64718 [realms] service.ws.apache.org = { kdc = localhost:64718 } ``` #### [](#kerberos-jaas-パス)Kerberos JAAS パス プロパティ ​`anypoint.platform.proxy_kerberos_jaas_path`​ では、認証に使用する JAAS ファイルのパスを指定します。このファイルの例を次に示します。 ```text alice { com.sun.security.auth.module.Krb5LoginModule required refreshKrb5Config=true useKeyTab=false keyTab="/my/krbwd/alice.keytab" principal="alice"; }; com.sun.security.jgss.login { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true storeKey=true keyTab="/my/krbwd/alice.keytab" principal="alice"; }; com.sun.security.jgss.initiate { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true storeKey=true keyTab="/my/krbwd/alice.keytab" principal="alice"; }; com.sun.security.jgss.accept { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true storeKey=true keyTab="/my/krbwd/alice.keytab" principal="alice"; }; ``` IMPORTANT: Mule ゲートウェイで ​`anypoint.platform.proxy_username`​ および ​`anypoint.platform.proxy_password`​ で指定されたログイン情報を使用するように、認証されるプリンシパル (この例では ​`alice`​) の ​`useKeyTab`​ を ​`false`​ に設定します。 ## [](#関連情報)関連情報 - [プロキシサーバー経由のエージェントへの接続](https://docs.mulesoft.com/runtime-manager/rtm-agent-proxy-config) # ヘッダー削除ポリシー

ポリシー名

ヘッダーの削除

概要

要求または応答からヘッダーを削除する

カテゴリ

変換

返される状況コード

500 - 評価されなかった式が設定に含まれる。
## [](#概要)概要 キー-値ペアを使用して、削除するヘッダーのインバウンドおよびアウトバウンドマップを指定すると、ヘッダー削除ポリシーにより、リストされたすべてのヘッダーがメッセージの要求または応答から削除されます。 ![プロキシを介して API にアクセスするクライアントのヘッダー挿入および削除ポリシーを設定するプロセスを示すフローチャート](/mulesoft/current/ja-jp/mule-gateway/_images/header-inject-remove-diagram.png) 必要に応じて、ヘッダーの値に DataWeave 式を含めることができます。この例では、設定されている次の式に一致するすべてのヘッダーがメッセージに挿入されます。 `“#[attributes.requestPath]”`
次のヘッダーは削除できません。 user-agent、 accept、 host、 content-type、 content-length、 date、 transfer-encoding、 connection、
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#mule-ゲートウェイ)Mule ゲートウェイ UI からヘッダー削除ポリシーを API に適用する場合、次のパラメーターを設定できます。
パラメーター 説明

Inbound Header Map (インバウンドヘッダーマップ)

メッセージ処理の先頭で削除するヘッダー名または正規表現のリスト (カンマ区切り)。例: Cache-Control, Access-Control.*

Outbound Header Map (アウトバウンドヘッダーマップ)

メッセージ処理の末尾で削除するヘッダー名または正規表現のリスト (カンマ区切り)。例: Access-Control-Allow-Credentials

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション
## [](#ポリシーのしくみ)ポリシーのしくみ ヘッダー削除ポリシーのパラメーターに一致するすべてのヘッダーがメッセージから削除されるため、パラメーターの設定方法については注意する必要があります。 たとえば、次のパラメーター設定では、単語 ​`Access-Control`​ で始まるヘッダー (​`Access-Control-Allow-Credentials`​ ヘッダーや ​`Access-Control-Allow-Origin`​ ヘッダーなど) がメッセージから削除されます。この設定により、​`Cache-Control`​ ヘッダーも削除されます。 ![メッセージ処理の開始時に削除されるヘッダー](/mulesoft/current/ja-jp/mule-gateway/_images/remove-inbound-header.png) Figure 1. インバウンドヘッダー # ヘッダー削除ポリシー API Manager は、要求または応答に対して HTTP ヘッダーを削除するポリシーをサポートしています。ポリシーは、要求または応答を送信する前に有効になります。ヘッダー削除ポリシーは、次のアクションを実行します。 - 指定した 1 つ以上のヘッダーがクライアントからバックエンドサービスに送信された場合に、その受信を防止する。 - バックエンドサービスからクライアントへの応答に、指定した 1 つ以上のヘッダーが含まれることを防止する。 ## [](#ヘッダー削除ポリシーの適用)ヘッダー削除ポリシーの適用 このポリシーを適用するには、次の手順を実行します。 1. 左側のナビゲーションから、​**\[API Administration (API 管理)\]**​ を選択します。 2. ポリシーを適用するバージョンを選択します。 3. 左側のナビゲーションから、​**\[Policies (ポリシー)\]**​ を選択します。 ポリシーの詳細ページが表示されます。クライアントまたは別のポリシーによりヘッダーがすでに提供されている場合、その値はヘッダーで上書きされます。 4. **\[Apply New Policy (新規ポリシーを適用)\]**​ をクリックします。 \[Select Policy (ポリシーを選択)\] ダイアログボックスが表示されます。 5. ポリシーリストから、​**\[Header Removal (ヘッダー削除)\]**​ ラジオボタンを選択して ​**\[Configure Policy (ポリシーを設定)\]**​ をクリックします。 \[Apply Header Removal policy (ヘッダー削除ポリシーを適用)\] ページが表示されます。 6. \[Inbound Header Map (インバウンドヘッダーマップ)\] ボックスで、インバウンドヘッダーの名前を入力します。 たとえば、このボックスに ​`in-header`​ を入力します。 7. \[Outbound Header Map (アウトバウンドヘッダーマップ)\] ボックスで、アウトバウンドヘッダーの名前を入力します。 たとえば、このボックスに ​`out-header`​ を入力します。 ![メッセージ処理中にヘッダーを削除できるフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/apply-header-removal-policy.png) 8. **\[Apply (適用)\]**​ をクリックします。 追加したヘッダー削除ポリシーが \[Policies (ポリシー)\] ページに表示されます。 # ヘッダー挿入ポリシー

ポリシー名

ヘッダーの挿入

概要

要求または応答にヘッダーを追加する

カテゴリ

変換

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

v4.1.0

返される状況コード

500 - 評価されなかった式が設定に含まれる。
## [](#概要)概要 ヘッダー挿入ポリシーでは、メッセージの要求または応答に HTTP ヘッダーが追加されます。API でこのポリシーを設定する場合、メッセージ処理に追加するヘッダーのインバウンドおよびアウトバウンドマップをキー-値ペアの形式で指定する必要があります。 ![プロキシを介して API にアクセスするクライアントのヘッダー挿入および削除ポリシーを設定するプロセスを示すフローチャート](/mulesoft/current/ja-jp/mule-gateway/_images/header-inject-remove-diagram.png) 必要に応じて、ヘッダーの値または名前に DataWeave 式を含めることができます。この例では、設定されている次の式に一致するすべてのヘッダーがメッセージに挿入されます。 `“#[attributes.requestPath]”` 挿入されるヘッダーがすでにメッセージ属性に存在する場合、ポリシーは既存のヘッダーの値を上書きせずに新しいヘッダーを作成します。

複数の値のサポートは特定のヘッダーにのみ限定され、これらのヘッダーは設定された値を使用して上書きされます。これらのヘッダーは、​access-control-allow-origin​、​content-type​、​content-length​、​transfer-encoding​ です。

既存の他のメッセージヘッダーを上書きするには、ヘッダーを追加する前に既存のヘッダーを削除してください。​「ヘッダー削除​ポリシー」を参照してください。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#mule-ゲートウェイ)Mule ゲートウェイ UI からポリシーを API に適用するときに、以下のパラメーターが表示されます。
パラメーター 説明

Inbound Header Map (インバウンドヘッダーマップ)

メッセージ処理の最初に挿入されるヘッダーのリスト。

インバウンドヘッダーキー

メッセージの先頭でヘッダー名として使用する文字列または DataWeave 式。

インバウンドヘッダー値

メッセージの先頭でヘッダー値として使用する文字列または DataWeave 式。

Outbound Header Map (アウトバウンドヘッダーマップ)

メッセージ処理の最後に挿入されるヘッダーのリスト。

アウトバウンドヘッダーキー

メッセージ処理の最後にヘッダー名使用する文字列または DataWeave 式。

アウトバウンドヘッダー値

メッセージ処理の最後にヘッダー値として使用する文字列または DataWeave 式。

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション

ヘッダーキーは、 HTTP 1.1​ 標準に準拠している必要があります。
# ヘッダー挿入ポリシー API Manager は、要求または応答に対して HTTP ヘッダーを追加するポリシーをサポートしています。ポリシーは、要求または応答を送信する前に有効になります。ヘッダー挿入ポリシーは、次のアクションを実行します。 - クライアントからバックエンドサービスへの要求に 1 つ以上のヘッダーを追加するか、既存のヘッダーの値を上書きする。 - バックエンドサービスからの応答に 1 つ以上のヘッダーを追加するか、バックエンドサービスからのレスポンスヘッダー値を上書きする。 ## [](#ヘッダー挿入ポリシーの適用)ヘッダー挿入ポリシーの適用 このポリシーを適用するには、次の手順を実行します。 1. 左側のナビゲーションから、​**\[API Administration (API 管理)\]**​ を選択します。 2. ポリシーを適用するバージョンを選択します。 3. 左側のナビゲーションから、​**\[Policies (ポリシー)\]**​ を選択します。 ポリシーの詳細ページが表示されます。 4. **\[Apply New Policy (新規ポリシーを適用)\]**​ をクリックします。 \[Select Policy (ポリシーを選択)\] ダイアログボックスが表示されます。 5. ポリシーリストから、​**\[Header Injection (ヘッダーの挿入)\]**​ ラジオボタンを選択して ​**\[Configure Policy (ポリシーを設定)\]**​ をクリックします。 \[Apply Header Injection policy (ヘッダー挿入ポリシーを適用)\] ページが表示されます。 6. \[Inbound Header Map (インバウンドヘッダーマップ)\] ボックスで、インバウンドヘッダーのキー-値ペアを入力し、​![プラス記号が含まれるボタン](/mulesoft/current/ja-jp/mule-gateway/_images/in-header-out-header-add-icon.png)​ をクリックします。 たとえば、そのボックスに ​`in-header`​、値ボックスに ​`3`​ を入力します。 7. \[Outbound Header Map (アウトバウンドヘッダーマップ)\] ボックスで、アウトバウンドヘッダーのキー-値ペアを入力します。 たとえば、そのボックスに ​`out-header`​、値ボックスに ​`4`​ を入力します。必要に応じて、ヘッダーの値に MEL 式を含めることができます。 たとえば、ヘッダーテキストに次の式を含めて「user-agent」の名前を置き換えることができます。 `'#[message.inboundProperties['user-agent']]'` ![ヘッダー挿入を設定できるフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/apply-header-injection-policy.png) 8. **\[Apply (適用)\]**​ をクリックします。 追加したヘッダー挿入ポリシーが \[Policies (ポリシー)\] ページに表示されます。 # ポート、IP、ホスト名の許可 ネットワーク内で Anypoint Platform のホスト名やポートを許可リストに追加して、ランタイムの Mule ゲートウェイ機能と、MuleSoft が管理するオンライン Anypoint Platform の API やサービスが通信できるようにする必要のある場合があります。 次の表に、Runtime Manager エージェントと Runtime Manager コンソールとの間の通信を許可するために許可リストに追加するポートまたは IP/ホスト名を示します。
プレーン Host (ホスト) Port (ポート)

US

anypoint.mulesoft.com

443

US

runtime-manager.anypoint.mulesoft.com

443

US

analytics-ingest.anypoint.mulesoft.com

443

US

data-authenticator.anypoint.mulesoft.com

443

US

exchange-files.anypoint.mulesoft.com

443

US

exchange2-asset-manager-kprod.s3.amazonaws.com

443

US-GOV

runtime-manager.gov.anypoint.mulesoft.com

443

US-GOV

data-authenticator.gov.anypoint.mulesoft.com

443

US-GOV

gov.anypoint.mulesoft.com

443

US-GOV

exchange-files.gov.anypoint.mulesoft.com

443

US-GOV

exchange2-asset-manager-kgprod.s3.us-gov-west-1.amazonaws.com

443

EU

eu1.anypoint.mulesoft.com

443

EU

runtime-manager.eu1.anypoint.mulesoft.com

443

EU

analytics-ingest.eu1.anypoint.mulesoft.com

443

EU

data-authenticator.eu1.anypoint.mulesoft.com

443

EU

exchange-files.eu1.anypoint.mulesoft.com

443

EU

exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

443
## [](#関連情報)関連情報 - [ポート、IP アドレス、ホスト名の許可](https://docs.mulesoft.com/jp/runtime-manager/rtm-agent-allowlists) # ポイントカット参照 ポイントカットは、ポリシーが適用されるリソースを示します。 たとえば、API Manager でポリシーを適用している場合、このポリシーではポイントカットを使用して、適用先の Mule アプリケーションのエンドポイントを決定します。 カスタムポリシーにはポイントカット宣言を含める必要があります。ポイントカットでは、リテラル文字列を使用して、ポリシーの影響を受けるアプリケーション内のリソースを指定することができます。または、より幅広いリソースのセットにポリシーを適用する必要がある場合には、正規表現を使用することもできます。 Anypoint Platform にデプロイされている API にポリシーを適用する場合、ポイントカットをデフォルトプロパティの ​`apiName`​ と ​`apiVersion`​ に設定します。こうすることで、ポリシーを有効にする対象の API にのみ、そのポリシーが適用されます。ポイントカットは次のようになります。 ```xml ``` これは、Mule 3.x を使用している場合のみ必要であることに注意してください。 ポイントカットを ​`regex=”.*”`​ などの幅広い正規表現に設定すると、望ましくない影響が発生する可能性があります。 プラットフォームを介してこのポリシーを 1 つの API に適用すると、デプロイしている他の API にも影響を及ぼす可能性があります。 オンサイトデプロイメントでポリシーを使用している場合は、ポリシーを複数の API に同時に適用するようにポイントカットを変更する必要がある場合があります。 ## [](#リソースレベルポリシーの有効化)リソースレベルポリシーの有効化 API が Mule 3.x の Mule 3.8.4 以降のバージョンで実行されている場合は、次のコードを使用してリソースレベルポリシーを含めます。 ```json {{#pointcutData}} {{/pointcutData}} {{^pointcutData.length}} {{/pointcutData.length}} ``` また、YAML に次のプロパティを含めます: `resourceLevelSupported: true` ## [](#ポイントカットのカスタマイズ)ポイントカットのカスタマイズ ポイントカット内では、次の種類の要素を参照できます。 - エンドポイント - アプリケーション - リソース 複数の要素が 1 つのポイントカット内で指定されている場合、それらは AND 式を使用している場合と同じように実装されます。 ```xml ``` 複数の要素が別々のポイントカット親要素で指定されている場合、それらは OR 式を使用している場合と同じように実装されます。 ## [](#参照アプリケーション)参照アプリケーション ```xml ``` ## [](#参照エンドポイント)参照エンドポイント ```xml ``` 次の例では、プロパティからの値を使用します。 ```xml ``` 次の例も有効です。 ```xml ``` 前の 2 つの例が機能するには、Mule の起動時または wrapper.conf ファイル内で ​`http.port`​ を次のように定義します。 `wrapper.java.additional.4=-Dhttp.port=8081` `http.port`​ がアプリケーションレベルで定義されている場合、ポリシーを適用したときに解析の例外が発生します。 ## [](#参照リソース)参照リソース ```xml ``` 特定のメソッド (GET、POST、PUT など) を参照できます。 たとえば、​``​ は、すべての POST、PUT、PATCH メソッドに適用されます。 デフォルトを使用した例 ```xml ``` この例では、パスを、RAML ファイルで指定される baseUri に指定できます。 リソースの第 1 レベルの絞り込みの例 ```xml ``` Mule によって提供される Java クラスのみを使用できます。 カスタムポリシーの作成には、Mule で使用可能な任意のメッセージプロセッサーを使用できますが、Java クラスは Mule によって提供されるもののみを使用できます。Mule アプリケーションの作成とは異なり、カスタムポリシーを作成するときにカスタム Java クラスを定義してコールすることはできません。これは、ポリシーを使用してカスタム Java クラスをバンドルする方法がないためです。 ## [](#関連情報)関連情報 - [設定および定義ファイルの参照](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-custom-policy-references) - [カスタムポリシーの作成](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-creating-custom-policy) # ポリシーと SLA 層の適用方法 この手順では、ポリシーを設定して API に適用します。必要に応じて SLA 層をセットアップできます。 この手順では、ポリシーを設定して適用する方法を説明します (例: レート制限 SLA ベースのポリシー)。 ## [](#sla-層について)SLA 層について アプリケーションの SLA レベルに応じてアプリケーションから API へのコールを 3 要求または 5 要求に制限する、次のようなアクセス層を作成します。 - 要求を 3 回/分に制限する層。承認を必要としない。 - 要求を 5 回/分に制限する層。API にアクセスするアプリケーションの API バージョンオーナーの承認を必要とする。 この手順では、アクセスを 1 つの API リソースに制限します。その他のリソースへのアクセスは無制限です。アプリケーションが保護されたリソースをコンシュームしようとすると、ポリシーが適用されます。要求には、期待されるユーザー名とパスワードが含まれている必要があります。アプリケーションから API への SLA 制限内で繰り返されるコールは成功しますが、それ以外は失敗します。 ## [](#必要な-raml-スニペットの追加方法)必要な RAML スニペットの追加方法 API のタイプが RAML なのか HTTP なのかを確認します (不明な場合)。API バージョンの詳細ページの \[Status (状況)\] で \[Configure Endpoint (エンドポイントの設定)\] をクリックし、\[Type (タイプ)\] が RAML であることを確認します。 SLA ベースのレート制限やその他の特定のポリシーを使用する場合は、RAML API に特定の RAML スニペットを追加する必要があります。API インスタンスの適用済みポリシーのリストに、ポリシーに必要な RAML スニペットへのリンクが表示されます。 レート制限ポリシーはクライアント ID ベースなので、クライアント ID とシークレットをクエリパラメーターとしてセットアップします。ポリシーを適用するための traits (特性) を RAML に追加します。RAML を次のように編集します。 1. ルートレベルに ​`traits:`​ というセクションを追加し、クエリパラメーターを定義します。 ```yaml traits: - client-id-required: queryParameters: client_id: type: string client_secret: type: string ``` 2. 各メソッドの trait を参照し、各メソッドに次のクエリパラメーターが必要であることを指定します。RAML ファイル内の各メソッドの後に、​`is: [client-id-required]`​ を追加します。次に例を示します。 ```yaml /users: get: is: [client-id-required] description: Gets a list of JSONPlaceholder users. ``` ## [](#層の追加方法)層の追加方法 1. API Manager の \[API Administration (API 管理)\] で、バージョンをクリックします。 2. API がリソースレベルのポリシーをサポートすることを確認します。API バージョンの詳細ページの \[Status (状況)\] で \[Configure Endpoint (エンドポイントの設定)\] をクリックし、\[Type (タイプ)\] が RAML であることを確認します。 3. \[SLA Tiers (SLA 層)\] を選択し、\[Add SLA Tier (SLA 層を追加)\] をクリックします。次のように層に制限をセットアップします。 - Name (名前): Free (無料) - Approval (承認): Automatic (自動) - 制限 - \# of Reqs (要求数): 3 - Time Period (期間): 1 - Time Unit (時間単位): Minute (分) 4. \[Add SLA Tier (SLA 層を追加)\] を再度クリックし、次のように層に制限をセットアップします。 - Name (名前): Premium (プレミアム) - Approval (承認): Manual (手動) - 制限 - \# of Reqs (要求数): 5 - Time Period (期間): 1 - Time Unit (時間単位): Minute (分) ## [](#ポリシーの適用方法)ポリシーの適用方法 この手順では、上記のとおり SLA 層を追加し終わったところか、API Manager > \[API Administration (API 管理)\] に移動したことを前提とします。後者の場合は、API インスタンスをクリックし、次の手順に従ってポリシーを適用します。 1. \[Policies (ポリシー)\] を選択します。 2. \[Apply New Policy (新規ポリシーを適用)\] をクリックし、\[Select Policy (ポリシーを選択)\] で \[Rate Limiting - SLA-based policy (レート制限 - SLA ベースのポリシー)\] を選択して \[Configure (設定)\] をクリックします。または、\[Rate Limiting (レート制限)\] > \[Configure Policy (ポリシーを設定)\] を選択します。 3. \[Limits (制限)\] で、要求数、期間、測定単位を設定します。 4. API の ​`/users`​ リソースでポリシーを設定します。 - \[Method & Resource Conditions (メソッドとリソースの条件)\] で、\[Apply Configurations to Specific Methods & Resources (特定のメソッドとリソースに設定を適用)\] を選択します。 - \[Method (メソッド)\] で \[GET\] を選択します。 - \[URI Template Regex (URI テンプレート正規表現)\] に ​`/users`​ と入力して ​`/users`​ リソースのみにレート制限を適用するか、​`.*`​ と入力して API のすべてのリソース URI にレート制限を適用します。 - Mule 4 の場合は、\[Expose Headers (ヘッダーを公開)\] チェックボックスをオンにして、トークン適用およびレート制限ポリシーのヘッダー伝播を設定します。 - \[Apply (適用)\] をクリックします。 API に RAML 仕様が添付されている場合、\[Preview Resource Matching (リソース一致をプレビュー)\] をクリックして、検索条件が適用されるリソースを確認します。 ## [](#関連情報)関連情報 - [RAML スニペットへのリンク](https://docs.mulesoft.com/jp/api-manager/latest/prepare-raml-task) - [レート制限および調整](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-rate-limiting-and-throttling) - [Rate Limiting and Throttling - SLA-Based Policies (レート制限および調整 - SLA ベースのポリシー)](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-rate-limiting-and-throttling-sla-based-policies) - [SLA 層の削除方法](https://docs.mulesoft.com/jp/api-manager/latest/defining-sla-tiers) # ポリシーのカテゴリ ポリシーは、実行する機能別に分類されます。たとえば、ログを使用して問題を解決するため、メッセージログポリシーはトラブルシューティングポリシーとして分類されます。次の表に、内部ポリシーのカテゴリ、およびそのポリシーで実行される機能を示します。
カテゴリ ポリシー 機能

セキュリティ

基本認証 - LDAP

LDAP ログイン情報を認証する。

セキュリティ

基本認証 - シンプル

単一ユーザーのパスワードを認証する。

セキュリティ

IP ブロックリスト

IP アドレスの範囲をブロックする。

セキュリティ

IP 許可リスト

IP アドレスの事前承認済み範囲からのアクセスのみを許可する。

セキュリティ

JSON 脅威保護

API 要求内の悪意のある JSON 構造から保護する。

セキュリティ

XML 脅威保護

API 要求内の悪意のある XML 要素から保護する。

セキュリティ

JWT

JWT トークンを検証する。

セキュリティ

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

MuleSoft OAuth プロバイダーポリシーを使用してトークンアクセスを適用する。

セキュリティ

OpenAM アクセストークン適用

Open AM 認証サーバーを使用して保護されたリソースへのアクセスを制限する。

セキュリティ

PingFederate アクセストークン適用

PingFederate 認証サーバーを使用して保護されたリソースへのアクセスを制限する。

セキュリティ

Tokenization (トークナイゼーション)

機密データを非機密データ要素トークンに変換する。

セキュリティ

デトークナイゼーション

トークナイズされた値を元のデータに変換する。

コンプライアンス

クライアント ID 適用

有効なクライアントのログイン情報を持つクライアントアプリケーションへのアクセスを許可する。

コンプライアンス

CORS

Web ページで実行されたコールが異なるドメインからのリソースとやりとりを行うことを可能にする。

変換

ヘッダーの挿入

ポリシーの要求または応答メッセージにヘッダーを追加する。

変換

ヘッダーの削除

ポリシーの要求または応答メッセージからヘッダーを削除する。

サービス品質

HTTP キャッシュ

API 実装から HTTP 応答を保存する。

サービス品質

レート制限

指定した時間内に API が受け入れ可能な要求数を制限できるようにする。

サービス品質

レート制限、SLA ベース

SLA 層に基づいて API 要求を制限できるようにする。

サービス品質

スパイク制御

API トラフィックを制御する。

トラブルシューティング

メッセージログ

API が呼び出されたときにカスタムメッセージを記録する。
## [](#関連情報)関連情報 - [内部ポリシーディレクトリ](https://docs.mulesoft.com/jp/mule-gateway/policies-included-directory) # ポリシーの並び替え この手順では、Anypoint Platform によって提供されたポリシーを並び替えます。ただし、CORS、調整、レート制限ポリシーは例外です。これらのポリシーの優先順位は最も高くなっています。これらのポリシーを適用すると、他のポリシーをそれより高いレベルに設定することはできません。 カスタムポリシーのポリシー実行順序を設定するには、policy タグ、before ブロック、after ブロックのいずれかを設定します。 1. Anypoint Platform で ​**\[API Manager\]**​ をクリックし、\[API Administration (API 管理)\] で ​**API バージョン**​をクリックします。 2. API バージョンの詳細ページで、​**\[Policies (ポリシー)\]**​ を選択します。 3. 適用済みポリシーのリストの最上部で、​**\[Edit Policy Order (ポリシー順序を編集)\]**​ をクリックして優先度を変更します。 4. **\[Reorder Applied Policies (適用済みポリシーの並び替え)\]**​ で、上矢印と下矢印を使用して、ポリシーの順序を再編成します。 たとえば、レート制限、IP 許可リスト、および XML 脅威保護ポリシーを適用する場合、並び替えることができるのは IP 許可リストと XML 脅威保護のみです。これは、レート制限が他のポリシーよりも優先されるためです。 5. **\[Apply order (順序を適用)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [ポリシーの無効化、編集、削除](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-disable-edit-remove) - [カスタムポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-custom-policies) # ポリシーの並び替え Mule ゲートウェイで特定のポリシーをその他のポリシーより前に実行するには、内部ポリシーとカスタム API レベルポリシーの実行順序を設定することができます。ただし、API レベルポリシーを自動ポリシーより前に実行するように設定することはできません。 API Manager を介してポリシーを並び替えます。
クロスオリジンリソース共有 (CORS) ポリシー​の実行順序を設定することはできません。Mule ゲートウェイでは、CORS ポリシーは自動ポリシーおよび API レベルポリシーより前に実行されます。
## [](#mule-ゲートウェイ)Mule ゲートウェイ Mule Gateway でポリシーを並び替える手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、ポリシーを並び替える API の名前をクリックします。 3. 左側のナビゲーションメニューから、​**\[Policies (ポリシー)\]**​ をクリックします。 4. 適用済みポリシーのリストの最上部で、​**\[Reorder policies (ポリシーを並び替え)\]**​ をクリックします。 5. **\[Reorder Applied Policies (適用済みポリシーの並び替え)\]**​ セクションで、上矢印と下矢印を使用して、ポリシーの順序を再編成します。 6. **\[Apply order (順序を適用)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [内部ポリシーディレクトリ](https://docs.mulesoft.com/jp/mule-gateway/policies-included-directory) # ポリシーの無効化、編集、削除 1. Anypoint Platform で \[API Manager\] をクリックし、\[API Administration (API 管理)\] で API インスタンスをクリックします。 2. API ダッシュボードで、\[Policies (ポリシー)\] を選択します。 3. \[>\] をクリックし、変更するポリシーのポリシーコントロールを展開します。 4. \[Actions (アクション)\] > \[Disable (無効化)\]、\[Edit (編集)\]、または \[Remove (削除)\] をクリックします。 # ポリシーの種類 内部ポリシー、カスタムポリシー、または自動ポリシーを、それぞれのスコープ、管理、そして使いやすさで作成できます。ポリシーをすべての API に均一に適用するか、または​_リソースレベルポリシー_​を適用して、指定した条件に基づいて API を選択できます。 ## [](#内部-mule-ゲートウェイポリシー)内部 Mule ゲートウェイポリシー MuleSoft には、認証、セキュリティ管理、脅威保護、トークナイゼーションなどの領域ですぐに使用できるポリシーが用意されています。Anypoint Platform の API Manager を使用して、これらのポリシーを任意の API エンドポイントに適用できます。 適用したポリシーは、そのライフサイクル全体にわたって API Manager によって管理されます。デフォルトポリシーを特定の API に適用できます。環境内のすべての API にポリシーを自動的に適用するには、それを自動ポリシーとして設定する必要があります。 ## [](#自動ポリシー)自動ポリシー 環境内のすべての API にデフォルトまたはカスタムポリシーを適用し、そのポリシーを​_自動ポリシー_​にすることができます。ただし、自動ポリシーを作成するには、API Manager 環境システム管理者などの特定のアクセス権が必要です。 ## [](#カスタムポリシー)カスタムポリシー MuleSoft にはすぐに使用できる内部ポリシーがいくつか用意されていますが、特定のビジネスニーズに合わせてカスタムポリシーを作成することもできます。既存のポリシーをカスタマイズするか、まったく新しいカスタムポリシーを作成できます。これらのポリシーは、オンラインまたはオフラインに分類されます。 ### [](#オンラインカスタムポリシー)オンラインカスタムポリシー オンラインカスタムポリシーは、API Manager によって適用および管理されます。これは、ポリシーを適用するためのデフォルトの推奨される方法です。オンラインポリシーでは、Anypoint Platform を活用してポリシーのライフサイクルを管理できます。これにより、適用されたポリシーは常に API Manager と同期され、起動時にゲートキーパーメカニズムによって保護されます。 ### [](#オフラインカスタムポリシー)オフラインカスタムポリシー オフラインカスタムポリシーは、ランタイムに直接適用され、手動で管理されます。API Manager と簡単に非同期になる可能性があるため、この種類のポリシーの使用はお勧めしません。 オフラインカスタムポリシーは、起動時にゲートキーパーメカニズムによって保護されません。さらに、オフラインポリシーではクライアントのログイン情報の検証もサポートされていません。 ## [](#関連情報)関連情報 - [内部ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-overview) - [カスタムポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-overview) - [自動ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-automated-overview) - [リソースレベルのポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-resource-level-overview) # ポリシーの適用 Mule ゲートウェイでは、​**API Manager**​ を介して内部ポリシーを適用します。次の手順でこの方法を示します。 ポリシーは、API 全体 (デフォルト) または API の特定のメソッドやリソースに適用できます。

Mule ゲートウェイでポリシーを適用するには、自動検出によって API にリンクされている ​HTTP ベースまたは HTTPS ベースのフロー​を使用して、最初に Mule アプリケーションがデプロイされている必要があります。
ポリシーを適用する手順は次のとおりです。 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、ポリシーを適用する API の名前をクリックします。 3. 左側のナビゲーションメニューから、​**\[Policies (ポリシー)\]**​ をクリックします。 4. **\[+ Add policy (+ ポリシーを追加)\]**​ をクリックします。 5. 適用するポリシーを選択します。 6. 必須の設定パラメーターを設定します。 ポリシー設定パラメーターについては、​[「内部ポリシーディレクトリ」](https://docs.mulesoft.com/jp/mule-gateway/policies-included-directory)​を参照してください。 7. **\[Apply (適用)\]**​ をクリックします。 # ポリシーの適用 API Manager を使用して非公開サーバーでポリシーを適用したり、Anypoint Platform エージェントを使用してポリシーを Mule ゲートウェイランタイムまたは Mule 3.8.0 以降にダウンロードしたりできます。ポリシーはランタイムまたはポリシーフォルダーに保存されます。各ランタイムは、API Manager アカウントのクライアント ID とクライアントシークレットで設定されます。これで、Anypoint Platform エージェントと Anypoint Platform アカウント間の接続が定義されます。 ## [](#前提条件)前提条件 ポリシーを追加、削除、または適用する前に、次を確認してください。 \* 組織のシステム管理者または API バージョンオーナーロール \* API URL \+ API URL を設定するには、API バージョンの詳細ページの \[Status (状況)\] に移動して \[Configure Endpoint (エンドポイントの設定)\] をクリックし、実装 URI を設定します。 レート制限および調整ポリシーを使用する場合は、Jetty ではなく HTTP エンドポイント使用します。Jetty トランスポートの制限により、レート制限および調整ポリシーは、Jetty インバウンドエンドポイントを使用する API では機能しません。 ## [](#ポリシーの適用と削除)ポリシーの適用と削除 API バージョンの API URL を設定すると、\[Applications (アプリケーション)\]、\[Policies (ポリシー)\]、\[SLA Tiers (SLA 層)\] のコントロールを使用できるようになります。\[Apply New Policy (新規ポリシーを追加)\] をクリックすると、MuleSoft によって提供されたポリシーと組織によって追加されたカスタムポリシーのリストが表示されます。 要件を満たす別のポリシーがすでに適用されている場合、または現在のポリシーを適用するための前提条件として別のポリシーが必要な場合、\[Apply (適用)\] ボタンは無効です。 ## [](#ポリシーの順序付け)ポリシーの順序付け 次のいずれかのリリースを使用している場合、ポリシーが実行される順序を設定できます。 - Studio 6.0 以降で作成。自動検出が有効の Anypoint Platform にデプロイされている。 - Mule 3.8 統一ランタイム以降 - Mule ゲートウェイランタイム 2.2.0 以降 ## [](#ポリシーのデフォルトの適用順序)ポリシーのデフォルトの適用順序 API バージョンの詳細ページで \[Policies (ポリシー)\] を選択し、\[>\] をクリックしてポリシーのコントロールを展開すると、ポリシーのデフォルトの順序が表示されます。順序が設定されていないカスタムポリシーは、Mule によって提供されたポリシーの後に実行されます。 ## [](#ポリシーログ)ポリシーログ ログはポリシーのアクティビティを維持します。次のログにはポリシーの順序が表示されます。 INFO 2015-09-28 15:37:54,214 \[\[leagues-rest\].httpListenerConfig.worker.01\] org.mule.api.processor.LoggerMessageProcessor: POLICY A INFO 2015-09-28 15:37:54,214 \[\[leagues-rest\].httpListenerConfig.worker.01\] org.mule.api.processor.LoggerMessageProcessor: POLICY B ## [](#ポリシー関連の通知)ポリシー関連の通知 組織オーナーがポリシーの適用順序を定義すると、既存の API オーナーが自分の API にポリシーを設定してある場合は、競合が発生することがあります。競合が発生した場合、API Manager は双方に通知します。API オーナーは、ポリシーを更新して競合を解決する必要があります。 ## [](#ポリシーのポーリング時間)ポリシーのポーリング時間 ポリシーのポーリング時間は 60 秒です。UI でポリシーを適用してからポリシーが有効になるまで、最小で 60 秒の遅延が発生します。ポリシーの順序を無効化、編集、または変更した場合でも同じ遅延が発生します。 ## [](#コントラクトのポーリング時間)コントラクトのポーリング時間 コントラクトのポーリング時間は 15 秒です。UI でコントラクトを適用してからコントラクトが有効になるまで、最小で 15 秒の遅延が発生します。コントラクトの状況を変更した場合 (コントラクトを取り消した場合など) でも同じ遅延が発生します。 ## [](#ポリシーの-apikit-コンソールの設定)ポリシーの APIkit コンソールの設定 ポリシーは、API とコンソールの両方または API のみに適用できます。 コンソールの設定によって、RAML ベースの自動生成プロキシの設定方法が決まります。 # メッセージログポリシー

ポリシー名

メッセージログ

概要

受信した要求からの情報、バックエンドからの応答、または同じ API エンドポイントに適用されている他のポリシーからの情報を使用してカスタムメッセージを記録する

カテゴリ

トラブルシューティング

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

v3.8.0

返される状況コード

このポリシーの戻りコードは存在しません
## [](#概要)概要 メッセージログポリシーは、受信した要求からの情報、バックエンドからの応答、または同じ API エンドポイントに適用されている他のポリシーからの情報を使用してカスタムメッセージを記録します。 Mule ゲートウェイの場合、このポリシーは Apache log4j と Apache log4j2 のどちらでも機能します。 ## [](#前提条件)前提条件 Anypoint Platform 組織のシステム管理者ロールか、API を作成または管理するための権限が必要です。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#mule-ゲートウェイ)Mule ゲートウェイ UI を使用してメッセージログポリシーを API に適用する場合は、以下のパラメーターを設定できます。 ![新しいログ設定を追加するフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/apim-message-logging-policy-ui.png)
パラメーター 説明 必須?

Message (メッセージ)

ログに記録するメッセージを抽出する DataWeave 式。 Mule 4 ゲートウェイに関する注意: ペイロードがメッセージログの一部として使用される場合は、リスナーを反復不可能に設定しないでください。

必須

Conditional (条件付き)

メッセージをログに記録するかどうかを指定する DataWeave ブール式。

省略可能

Category (カテゴリ)

ログが実行されたパッケージとクラスを示すログメッセージのプレフィックス。

省略可能

Level (レベル)

記録するメッセージのレベル (INFO (情報)、WARN (警告)、ERROR (エラー)、DEBUG (デバッグ)) を定義します。

必須

Before Calling API (API のコール前)

このポリシーが適用される順序を考慮して、API エンドポイントがコールされる前にメッセージを記録するようにログポリシーを設定します。

省略可能

After Calling API (API のコール後)

このポリシーが適用される順序を考慮して、API エンドポイントがコールされた後にメッセージを記録するようにログポリシーを設定します。

省略可能
#### [](#ui-から設定するメッセージログポリシーの例)UI から設定するメッセージログポリシーの例 メッセージログポリシーの使用方法をよく理解できるように、Les Vetments という架空の洋品小売業者を考えてみましょう。E コマースポータルを正常に運営するため、Les Vetments は Web サイト上で実行された要求の状況コードを監査する必要があります。 たとえば、顧客が商品を購入または返品したり、会社がカタログの商品を追加または削除したりした場合には、トランザクションを記録する必要があります。Les Vetments の IT マネージャーは、会社の API にメッセージログポリシーを適用して、コードを変更することなくあらゆるデータやトランザクションの変更を記録して表示できるようにします。 受信および送信 HTTP メッセージの属性を記録するため、Les Vetments では、次の UI 設定でメッセージログポリシーを API に適用します。 - **Message (メッセージ)**​: #\[属性\] ペイロード中の属性を記録する必要があります。 - **Conditional (条件)**​: 空白 Les Vetments ではすべての属性を必要とするため、メッセージを絞り込むための Mule 式は指定しません。 - **Category (カテゴリ)**​: 空白 ログ文ではプレフィックスは不要です。 - **Level (レベル)**​: Info (情報) すべての種別のメッセージを記録します。Info (情報) ログレベルには、Warn (警告)、Error (エラー)、Debug (デバッグ) ログメッセージも含まれます。 - **Before Calling API (API のコール前)**​: オン API のコール前に発生したすべてのトランザクションが記録されます。 - **After Calling API (API のコール後)**​: オン API のコール後に発生したすべてのトランザクションが記録されます。 この設定後は、顧客が Les Vetments のカタログにアクセスしたり、カートの商品を追加または削除したり、Les Vetments のカタログの商品が追加または削除されたりするたびに、ログが生成されます。 ```text ********************************************************************** * Policy: message-logging-1351146-proxy * * OS encoding: UTF-8, Mule encoding: UTF-8 * * * ********************************************************************** 21:56:50.147 11/30/2020 Worker-0 [MuleRuntime].uber.06: [message-logging-771181-proxy].771181-message-logging.CPU_LITE @71625864 INFO event:184152a0-3370-11eb-b732-0a8c1820c088 org.mule.extension.http.api.HttpRequestAttributes { Request path=/proxy/1 Raw request path=/proxy/1 Method=GET Listener path=/proxy/* Local Address=/172.25.159.101:8081 Query String= Relative Path=/proxy/1 Masked Request Path=/1 Remote Address=/18.191.37.179:21836 Request Uri=/proxy/1 Raw request Uri=/proxy/1 Scheme=http Version=HTTP/1.1 Headers=[ host=logging-policy.us-e2.cloudhub.io x-real-ip=204.14.236.154 accept=*/* user-agent=curl/7.54.0 x-forwarded-for=204.14.236.154 x-forwarded-port=80 x-forwarded-proto=http x-sigsci-agentresponse=200 x-sigsci-mac=7caf3820a5c07d06ef827f1565678167 ] Query Parameters=[] URI Parameters=[] } 21:56:50.254 11/30/2020 Worker-0 [MuleRuntime].uber.07: [logging-policy].proxy.CPU_LITE @f0ce617 INFO event:184152a0-3370-11eb-b732-0a8c1820c088 org.mule.extension.http.api.HttpResponseAttributes { Status Code=200 Reason Phrase=OK Headers=[ date=Tue, 01 Dec 2020 00:56:50 GMT content-type=application/json; charset=utf-8 set-cookie=__cfduid=d8afa23a4627ebef39cbc54fea223cb231606784210; expires=Thu, 31-Dec-20 00:56:50 GMT; path=/; domain=.typicode.com; HttpOnly; SameSite=Lax x-powered-by=Express x-ratelimit-limit=1000 x-ratelimit-remaining=999 x-ratelimit-reset=1606784265 vary=Origin, Accept-Encoding access-control-allow-credentials=true cache-control=max-age=43200 pragma=no-cache expires=-1 x-content-type-options=nosniff etag=W/"53-hfEnumeNh6YirfjyjaujcOPPT+s" via=1.1 vegur cf-cache-status=MISS accept-ranges=bytes cf-request-id=06bd666d0a0000386b7a1fc000000001 expect-ct=max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" report-to={"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report?s=qUAIXoQ7qqqvFzjcwGrmK2r2PcSfDZ75jFJd0Gi0BLBUMHAcnC9wJ9I%2FEHJtk%2Bra%2FXWqkA%2F5%2FlzoWoC6YS2Lew%2BqKgjhaphHqx5WrZ0CKHMalhcM9it%2Fks0qzQGwbsRzQg%3D%3D"}],"group":"cf-nel","max_age":604800} nel={"report_to":"cf-nel","max_age":604800} cf-ray=5fa8d9c1a8c6386b-IAD ] } 12:18:31.770 11/18/2020 Worker-0 agw-policy-set-deployment.01 INFO Applied policy message-logging-1351146 version 1.0.0 to API testLoggingNew-v1-v1:16481163 (16481163) in application messagelog ``` ヘッダーを記録するため、Les Vetments では ​**\[Message (メッセージ)\]**​ 項目で次のコードスニペットを使用します。 `#[attributes.headers]` イベントや実行したアクションに基づいてログメッセージをカスタマイズするため、Les Vetments では ​**\[Message (メッセージ)\]**​ 項目で次のコードスニペットを使用します。 `#['User ' authentication.clientId ' performed action ' attributes.method ' on ' attributes.requestPath ' with Payload: ' ++ payload]` #### [](#mule-4-の-xml-で設定するメッセージログポリシーの例)Mule 4 の XML で設定するメッセージログポリシーの例 次のフローはログポリシーの例を示します。 ```xml ``` ## [](#ポリシーのしくみ)ポリシーのしくみ ポリシーのログ記録は次の順序で実行されます。 1. 要求が API に送信されます。 2. 次の条件を満たす場合は、メッセージがログに記録されます。 - ポリシーに定義されているログのレベルとカテゴリが、設定ファイルに定義されたロガーに含まれている。 - ポリシーの \[Conditional (条件付き)\] 項目が設定されていないか、または設定されている条件が満たされた。 3. API 応答が返されます。メッセージログポリシーは、ポリシーやフローの実行に干渉しません。 4. メッセージがアプリケーションログに表示されます。 ## [](#ログ形式について)ログ形式について メッセージログの形式は次のとおりです。 - Flex: ` [flex-gateway-envoy][] wasm log .default..default.svc main: [req: ] [accessLog] ` `policy-name`​: ポリシーバインドの名前を表示します。 `api-name`​: API インスタンスの名前を表示します。 `request uuid`​: メッセージをトリガーした要求の一意の識別子を表示します。 - Mule: ` : ` `date`​ は、メッセージログの日付とタイムスタンプです。 `thread name`​ は、メッセージが表示されるイベントスレッドの名前です。 `level`​ は、INFO (情報)、WARN (警告)、ERROR (エラー)、DEBUG (デバッグ) などのログレベルまたはメッセージタイプです。 `category`​ は、通常はログが発生したパッケージとクラスを示します。デフォルト値は ​`org.mule.runtime.logging.policy-`​ です。 `message`​: 記録するメッセージを表示します (例: `the payload`​)。 `2018-01-25 18:57:29,907 [WrapperListener_start_runner] INFO org.mule: the payload` `2022-05-04T14:50:43.035570800Z [flex-gateway-envoy][debug] wasm log ingress-http-auth.default.ingress-http.default.svc main: [req: 61c7fdcb-8d22-4cb1-852b-0d5073f23950] [accessLog] the payload` ## [](#イベント中の状態の記録)イベント中の状態の記録 メッセージのログは、要求フロー中に特定の間隔で発生します。 - API フローをログに記録する前: ![API フローをログに記録する前の状態を示すシーケンス図](/mulesoft/current/ja-jp/mule-gateway/_images/apim-message-logging-policy-states-1.png) - API フローをログに記録した後: ![API フローをログに記録した後の状態を示すシーケンス図](/mulesoft/current/ja-jp/mule-gateway/_images/apim-message-logging-policy-states-2.png) - API フローの後のエラーハンドラー: ![エラーハンドラーが実行した後の状態を示すシーケンス図](/mulesoft/current/ja-jp/mule-gateway/_images/apim-message-logging-policy-states-3.png) ## [](#関連情報)関連情報 - [Mule 4 の Mule メッセージ](https://docs.mulesoft.com/mule-runtime/latest/about-mule-message) # リソースレベルのポリシー Mule 3.8.1 以降を使用して、次の条件を満たす API のリソースレベルとメソッドレベルに 1 つ以上の提供されたポリシーを適用できます。 - API に RAML エンドポイントがある。 - APIkit または RAML プロキシを使用して API を作成している。 APIkit を使用して、RAML ベースの API を作成し、基本エンドポイントを設定できます。または、既存の API の場合は RAML ベースの API を作成し、プロキシを使用してエンドポイントを設定できます。 リソースレベルで適用されたポリシーはすべてのメソッドまたはリソース内で選択したメソッドに影響します。 既存のカスタムポリシーでこの機能をサポートするには、コードを追加します。 複数の条件を適用してリソースとメソッドを絞り込むことができます。URI テンプレート正規表現は、API の 1 つ、複数、またはすべてのメソッドに適用できます。 ## [](#サポートされていないポリシー)サポートされていないポリシー 次のポリシーはリソースに適用できません。 - クロスオリジンリソース共有 - LDAP セキュリティマネージャー - 単純なセキュリティマネージャー ## [](#使用シナリオ)使用シナリオ リソースレベルポリシーは想像できる限りのあらゆる用途に使用できます。例をいくつか示します。 - 特定のリソースへのポリシーの適用 - API のサブセットの保護 - 複数のリソースへの異なる制限の設定 ## [](#リソースレベルポリシーの適用)リソースレベルポリシーの適用 サンプル API のシミュレーションは次のようになります。 ![ユーザー権限とそれぞれのユーザー権限に許可された対応する HTTP メソッドに関連する API 要求](/mulesoft/current/ja-jp/mule-gateway/_images/users-api-cropped.png) リソースレベルポリシーは、Java 正規表現をサポートしています。たとえば、ワイルドカードを使用してポリシーを複数のリソースに適用できます。ポリシーを API に適用する場合は、適用対象のリソースを指定します。 Mule 3 でリソースレベルポリシーを使用する場合、リソーステンプレート定義に API ベースパスを含めないでください。 複数の条件を適用してリソースとメソッドを絞り込むことができます。URI テンプレート正規表現は、API の 1 つ、複数、またはすべてのメソッドに適用できます。 正規表現内で {userid} などのプレースホルダーを使用​_しない_​でください。式でプレースホルダーを使用すると、プレースホルダーが実際のノードに一致しないため、失敗します。プレースホルダー例の {userid} の場合、ノードは実際には次のようになります。 `/api/users/671962fc-f076-4b19-bc38-45ba3a4e4095/permissions/1234` - 671962fc-f076-4b19-bc38-45ba3a4e4095 がユーザー ID です。 - 1234 は権限の ID です。 1 人のユーザーとそのリソースより下位のすべてのノードを表すリソース ​`/api/users/{userid}`​ にポリシーを適用するには、次の式を使用します。 `/api/users/.*` 権限リソース ​`/api/users/{userId/permissions}`​ と ​`/api/users/{userid}/permissions/{permissionId}`​ のみにポリシーを適用するには、次の式を使用します。 /api/users/.\*/permissions.\* ### [](#api-のサブセットの保護)API のサブセットの保護 作成、更新、削除操作にセキュリティを追加し、参照のみの操作は保護しないままにすることができます。たとえば、特定のメソッドとリソースに HTTP 基本認証ポリシーを適用するとします。POST、PUT、PATCH、DELETE の各メソッドを選択し、次の式を使用して API のすべてのリソース URI を対象とします。 `.*` この式は、書き込み操作にセキュリティを適用し、GET (参照のみ) は保護しないままにします。リソースのサブセットのみを対象とするには、より詳細な式を使用します。 ### [](#複数のリソースへの異なる制限の設定)複数のリソースへの異なる制限の設定 ユーザー固有の操作に、ユーザーのアクションに応じて異なる制限を使用してレート制限を適用できます。たとえば、レート制限を複数回適用して、一部のリソースへの要求を他のリソースよりも厳しく制限することができます。たとえば、次のノードでユーザーごとに参照、作成、削除操作に異なる制限を設定できます。 /api/users/.\*/.\* → /api/users/{userId}/assignments; /api/users/{userId}/assignments/{param}/values; /api/users/{userId}/permissions; /api/users/{userId}/permissions/{permissionId} まず、レート制限ポリシーを特定のメソッドとリソースに適用し、GET (参照) メソッドを選択して、次の正規表現を使用します。 /api/users/.\*/.\* 次に、ポリシーを設定して、たとえば 1 時間あたり 100 件の要求に制限します。 次に、もう一度レート制限ポリシーを特定のメソッドとリソースに適用し、今度は POST (作成) メソッドを選択して、前回と同じ正規表現を使用します。1 時間あたり 50 件の要求に設定します。 最後に、もう一度レート制限ポリシーを特定のメソッドとリソースに適用し、DELETE (削除) メソッドを選択します。今回も前回と同じ正規表現を使用します。そして、たとえば 2 時間あたり 25 件の要求に設定します。 ## [](#関連情報)関連情報 - [リソースレベルのポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-resource-level-policies) - [カスタムポリシーのリソースレベルのサポートの有効化](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-resource-level-custom-policy) # リソースレベルのポリシー 他の設定を行わない限り、ポリシーはデフォルトでは API 全体に適用されます。ただし、条件に基づいてアクセスが制御されるポリシーの粒度レベルを追加して実装できます。この粒度のポリシーは​_リソースレベルポリシー_​と呼ばれます。 粒度のリソースレベルでは、ポリシーは条件に一致する要求のみに適用されます。 クロスオリジンリソース共有 (CORS) ポリシーを除くすべてのポリシーは、リソースレベルです。 Mule 4 では、リソースレベルポリシーは RAML API に加えて HTTP ベースの API もサポートします。 API 内のメソッド (数は無制限) に対して ​[URI テンプレート正規表現](#api-manager::configure-uri-template-regex.adoc)​を使用することで、複数の条件を適用してリソースや HTTP メソッドを絞り込むことができます。 ## [](#リソースレベルポリシーを実装するための使用シナリオ)リソースレベルポリシーを実装するための使用シナリオ リソースレベルのシナリオは多くの方法で使用できます。一例を紹介します。 - 特定のリソースにポリシーを適用する。 - API のサブセットを保護する。 - 複数のリソースに異なる制限を設定する。 API に RAML または OAS 仕様が関連付けられている場合は、​**\[Preview Resource Matching (リソース一致をプレビュー)\]**​ オプションを使用して、検索条件の影響を受けるリソースを決定できます。 ![ユーザー権限とそれぞれのユーザー権限に許可された対応する HTTP メソッドに関連する API 要求](/mulesoft/current/ja-jp/mule-gateway/_images/users-api-cropped.png) リソースレベルポリシーは、Java 正規表現をサポートしています。たとえば、ワイルドカードを使用してポリシーを複数のリソースに適用できます。ポリシーを API に適用する場合は、適用対象のリソースを指定します。 ## [](#リソースレベルポリシーを実装するためのガイドライン)リソースレベルポリシーを実装するためのガイドライン リソースレベルポリシーを実装する場合は、以下の点に注意してください。 - 正規表現内で {userid} などのプレースホルダーを使用しないでください。 式でプレースホルダーを使用すると、プレースホルダーが実際のノードに一致しないため、失敗します。プレースホルダー例の {userid} では、ノードは次のようになります。 `/api/users/671962fc-f076-4b19-bc38-45ba3a4e4095/permissions/1234` 671962fc-f076-4b19-bc38-45ba3a4e4095 がユーザー ID です。 1234 は権限の ID です。 1 人のユーザーとすべてのリソースノードを表すリソース ​`/api/users/{userid}`​ にポリシーを適用するには、次の式を使用します。 `userid`​ は、1 人のユーザーとすべてのリソースノード ​`/api/users/.*`​ を表します。 権限リソース ​`/api/users/{userId/permissions}`​ と ​`/api/users/{userid}/permissions/{permissionId}`​ のみにポリシーを適用するには、次の式を使用します。 `/api/users/.**/permissions.**` ## [](#関連情報)関連情報 - [URI テンプレート正規表現の設定](#api-manager::configure-uri-template-regex.adoc) - [アウトバウンドポリシーの無効化](#api-manager::disable-outbound-policies.adoc) # レート制限: SLA ベースのポリシー

ポリシー名

レート制限 SLA

概要

SLA に基づいた期間中に処理される要求の最大数を定義することで、API へのアクセスを監視します。

カテゴリ

サービス品質

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

v4.1.0

返される状況コード

400 - 無効なクライアントログイン情報が返されたか、または SOAP v1.2 を使用する WSDL API によってクォータを超過しました (Mule のみ)。

401 - 指定されたクライアントログイン情報 (クライアント ID またはクライアントシークレット) が無効であるため、要求がブロックされました。

429 - クォータを超過しました。現在のウィンドウが完了するまで要求はブロックされます。

500 - 無効なクライアントログイン情報が返されたか、または SOAP v1.1 を使用する WSDL API によってクォータを超過しました (Mule のみ)。
## [](#概要)概要 レート制限サービスレベル契約 (SLA) ポリシーにより、API が特定の期間中に受け取ることができる要求数を制限することで、API への受信トラフィックを制御できます。期間が終了する前にこの制限に達すると、ポリシーはすべての要求を拒否して、バックエンド API の負荷増大を回避します。 レート制限 SLA ポリシーを API に適用するには、先にその API と登録済みクライアントアプリケーションとの間でコントラクトを作成する必要があります。特定の期間中に API が受け取ることのできる要求の数は、API Manager の ​[\[contracts (コントラクト)](https://docs.mulesoft.com/jp/api-manager/latest/manage-client-apps-latest-task)\]​ セクションで定義します。 各要求は、クライアント ID と (ポリシー設定によって) 省略可能なクライアントシークレットによって識別される必要があります。登録済みクライアントアプリケーションのクライアントログイン情報の取得方法は、​[「登録済みクライアントアプリケーションのクライアントログイン情報の取得」](https://docs.mulesoft.com/jp/api-manager/latest/access-client-app-id-task)​を参照してください。 また、Mule Runtime Engine (Mule) クラスターで実行するようにポリシーを設定することもできます。クラスターポリシー設定では、クォータはクラスター内のすべてのノードで共有されます。これらのオプションの詳細は、​[「例」](#examples)​を参照してください。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#mule-ゲートウェイ)Mule ゲートウェイ UI からポリシーを API に適用するときに、環境に Mule アプリケーションがあるか非 Mule アプリケーションがあるかに基づいて、パラメーターのリストが表示されます。 ### [](#ポリシーのパラメーターの設定-2)ポリシーのパラメーターの設定 次のパラメーターが表示されます。
パラメーター 説明 例

Client ID Expression (クライアント ID 式)

API のコントラクトについてクライアントアプリケーションの ID を解決する DataWeave 式

レート制限アルゴリズムは、ID ごとに 1 つだけ作成されます。 ​#[attributes.headers['client_id']]​ この例では、‘client_id’ という HTTP ヘッダーを探して、その値を使用しています。

Client Secret Expression (クライアントシークレット式)

API のコントラクトについてクライアントアプリケーションのクライアントシークレットを解決する DataWeave 式

省略可能な値です。 例: #[attributes.headers['client_secret']]

Distributed (分散)

このフラグを有効にして相互接続されたランタイムを使用する場合、クォータはすべてのノード間で共有されます

Expose Headers (ヘッダーを公開)
### [](#anypoint-service-mesh-非-mule-アプリケーション-のポリシーパラメーターの設定)Anypoint Service Mesh (非 Mule アプリケーション) のポリシーパラメーターの設定 レート制限 SLA ポリシーは、次の違いを除き、Anypoint Service Mesh (Mule 以外のアプリケーション) と同様に機能します。 - このポリシーでは、ヘッダーを公開するオプションが提供されない - 次の表で説明しているように、パラメーターを取得するクライアント ID とクライアントシークレットが異なる。
要素 説明 必須

Credentials Origin (ログイン情報の取得元)

クライアント ID とクライアントシークレットのログイン情報の取得元:

  • client_id​ および ​client_secret​ ヘッダー

  • カスタムヘッダー

はい

Client ID Header (クライアント ID ヘッダー)

API 要求のクライアント ID を抽出するヘッダー名

はい ([Credentials origin (ログイン情報の取得元)] を ​[Custom ヘッダー (カスタムヘッダー)]​ に設定する場合)

Client Secret Header (クライアントシークレットヘッダー)

API 要求のクライアントシークレットを抽出するヘッダー名

いいえ
## [](#ポリシーのしくみ)ポリシーのしくみ レート制限 SLA ポリシーは、現在のウィンドウ (使用可能なクォータ) 内で要求数を監視し、使用可能なクォータが 0 より大きい場合にのみ、要求がバックエンドに到達できるようにします。 ウィンドウで使用可能なクォータはクライアントごとに別々に定義されるため、クライアントアプリケーションは API との間で SLA (コントラクト) を定義する必要があります。したがって、要求が SLA の制限内にあるかどうかを検証するには、要求からクライアント ID と必要に応じてクライアントシークレットを取得する手段を定義する必要があります。 クライアントアプリケーションと API との間でコントラクトを作成すると、API ゲートウェイは API Manager 設定を監視することで、自動的にこれらのコントラクトを管理します。さらに API ゲートウェイは、Anypoint Platform 管理プレーンで予期しないダウンタイムが発生した場合に備えて、高可用性戦略を実装します。 レート制限 SLA ポリシーの仕組みをわかりやすくするため、ID が「ID#1」のクライアントについて 10 秒ごとに 3 件の要求という設定で、ウィンドウ内のクォータに基づいて受信要求が許可または拒否される例を見てみましょう。 ![指定された時間枠内の受け入れられたクライアント要求と拒否されたクライアント要求の両方を示すタイムラインチャート](/mulesoft/current/ja-jp/mule-gateway/_images/rate-limiting-sla-general.png) この例では、次のようになります。 - ID が「ID#1」のクライアントの要求: 最初のウィンドウでは、3 番目の要求でクォータに達したため、以降の要求はウィンドウが終了するまで拒否されます。2 番目のウィンドウでは、3 件の要求のうち 2 件しか処理されていません。このウィンドウは終了したため、残りのクォータは未使用となります。 受け入れられた要求は API を経由してバックエンドに送られます。一方、拒否された要求は ​`429 status for HTTP`​ (API が WSDL であれば 400 または 500) を返してバックエンドには到達しません。 - ID が「ID#2」のクライアントの要求: このクライアントは API との間で定義されているコントラクトを持たないため、すべての要求が拒否され、要求は 1 つも許可されません。 1 つの API は、それぞれ SLA が異なる複数のコントラクトを持つことができます。レート制限 SLA ポリシーは、コントラクトごとに 1 つのレート制限アルゴリズムを作成することで、各クライアントの使用可能なクォータ (およびウィンドウ) を別々に監視します。API に最初の要求が送られた時点で、​_遅延作成_​戦略によってアルゴリズムが作成されます。 ## [](#examples)例 クライアント ID#設定がクラスタリングされた場合に、クライアント ID#1 に対する 10 秒ごとに 3 件の要求のコントラクトがどのように機能するのかを見てみましょう (Mule のみ)。 12:00:00 ちょうどにリセットされ、長さが 10 秒で、ノード 2 台の Mule クラスターで実行されるウィンドウを考えてみましょう。両方のノードは同時にそれぞれのウィンドウを開始して終了し、クラスターではウィンドウごとにクライアント ID#1 で合計 3 件の要求が許可されます。 ![2 つのノードの経時的な要求の受け入れと拒否を示す折れ線チャート](/mulesoft/current/ja-jp/mule-gateway/_images/rate-limiting-clusterizable.png) この例では、次のようになります。 - クライアント ID#1 の要求: ポリシーがクラスタリングされているため、クラスター全体で 3 件の要求を受け入れます。ポリシーのクラスタリングが無効化されると、Mule クラスターはウィンドウごとに 6 件の要求 (ノードごとに 3 件の要求) を受け入れることができます。 - クライアント ID#2 の要求: このクライアントは特定の API との間で定義されているコントラクトを持たないため、すべての要求が拒否されます。 分散されたカウンターによってノードの同期が必要となり、その結果としてパフォーマンスが低下します。このポリシーでは、キャッシュメカニズムを使用して動作を予測し、スループットを最大化します。ただし、最悪ケースのシナリオではレイテンシーが大きくなることがあります。クラスタリング設定を使用するかどうかは、ユースケースによって決まります。 ## [](#ポリシーの設定)ポリシーの設定 レート制限 SLA ポリシーを設定する場合は、ポリシーの価値を最大限に引き出せるように、環境の特定の側面を考慮する必要があります。 ### [](#クラスター設定とスタンドアロン設定の選択)クラスター設定とスタンドアロン設定の選択 サーバーで認証メカニズムとして 1 つのクライアントアプリケーションしか使用していない場合は、レート制限ポリシーと同じ推奨事項が適用されます。複数の Mule インスタンスを使用している場合は、異なるクライアントアプリケーションをロードバランサーの異なるサーバーにマッピングすることがあります。 このようなシナリオでは、クラスターを使用する必要はありません。スタンドアロンノードの場合は、それぞれのノードが排他的に実行しているクライアントに対してレート制限アルゴリズムを作成します。一方、サーバーの高可用性を実現するために複数のクライアントアプリケーションを設定する場合があります。 Mule クラスターでは、クラスター全体の各クライアントについて SLA クォータを数えるため、このユースケースではクラスターが最適です。レート制限 SLA ポリシーは、ワークロードが分散されていても分散されていなくても機能するように設計されています。バックエンドは過剰な要求を受け取らないため、最大容量を超えることはありません。 ### [](#クラスターノードのウィンドウサイズの選択)クラスターノードのウィンドウサイズの選択 クラスター設定では、一貫性を保つためにノードがクラスター全体で情報を共有する必要があります。共有プロセスによりレイテンシーが発生するため、パフォーマンスについて確認するときには考慮する必要があります。 最悪のシナリオでは、クラスターの一貫性のためにレイテンシーの影響を受ける要求の数は一定で、設定された割り当ての実際のサイズとは関係がありません。そのため、期間が短いほど、遅延する可能性がある要求の割合は大きくなります。 したがって、レート制限ポリシーとレート制限 SLA ポリシーの設定では、クラスターシナリオでのみ 1 分より長いウィンドウサイズを設定する必要があります。 ### [](#レート制限-sla-ポリシーの永続性の選択-mule-のみ)レート制限 SLA ポリシーの永続性の選択 (Mule のみ) レート制限 SLA ポリシーは、数日、数ヶ月、あるいは数年に渡って永続するウィンドウを使用するように設定できます。たとえば、1 年間に 100 万件の要求をコンシュームできるようにしたいものの、その期間全体に渡ってノードが稼動しているかどうか、あるいは Mule の再起動が発生するメンテナンスが必要になるかどうかについては確信が持てないとします。 アルゴリズムはすでに数か月間実行されているため、クライアントは重要な情報を失います。永続性では、現在のポリシー状態を定期的に保存することによってこの問題を解決します。再デプロイメントや再起動が発生した場合、アルゴリズムは最後の既知の永続的な状態から再作成されるか、クリーンな状態から開始されます。 永続性はデフォルトで有効になっていますが、次のプロパティを false に設定することで無効にできます。 `throttling.persistence_enabled` また、永続性の頻度を調整できます。デフォルトは 10 秒です。 `throttling.persistent_data_update_freq`

永続性は CloudHub では使用できません。
## [](#faq)FAQ **このウィンドウはいつ開始されますか?** このウィンドウは、ポリシーが正常に適用された後の最初の要求で開始されます。 **アルゴリズムが使用するウィンドウの種別は?** 固定ウィンドウです。 **クォータを使い果たすとどうなりますか?** アルゴリズムは、最初の要求を受信したときにオンデマンドで作成されます。このイベントによって、期間が固定されます。各要求は、期間が終了するまで、現在のウィンドウの要求クォータをコンシュームします。 要求クォータを使い果たすと、レート制限 SLA ポリシーは要求を拒否します。ウィンドウが終了すると、要求クォータはリセットされ、同じ固定サイズの新しいウィンドウが開始されます。 **SLA で複数の制限を定義するとどうなりますか?** ポリシーはウィンドウあたりの要求クォータ設定を使用して各制限のアルゴリズムを作成します。そのため、複数の制限が設定されている場合、要求が受け入れられるには、すべてのアルゴリズムに現在のウィンドウで使用可能な要求クォータが存在する必要があります。 **各レスポンスヘッダーの意味は?** 各レスポンスヘッダーは、要求の現在の状態に関する情報を返します。 - X-Ratelimit-Remaining: 使用可能な要求クォータ - X-Ratelimit-Limit: 各ウィンドウで使用可能な最大要求数 - X-Ratelimit-Reset: 新しいウィンドウが開始されるまでの残り時間 (ミリ秒) デフォルトでは、応答の X-RateLimit ヘッダーは無効になっています。これらのヘッダーを有効にするには、ポリシーの設定時に ​**\[Expose Headers (ヘッダーを公開)\]**​ を選択します。 **Mule クラスターを CloudHub で設定できますか?** いいえ。この機能は、Runtime Fabric、ハイブリッド、およびスタンドアロン Mule 設定でのみ使用できます。 **レート制限 SLA やスパイク制御ではなくレート制限ポリシーを使用する必要がある状況は?** レート制限 SLA ポリシーとレート制限 SLA ポリシーは、説明責任を果たすためにハード制限を (レート制限で識別子を使用して) グループまたは (レート制限 SLA を使用して) クライアントアプリケーションに適用する場合に使用します。バックエンドを保護するには、代わりにスパイク制御を使用してください。 # レート制限および調整 ここでは、Mule 3.x 以前にデプロイされた API に関する調整とレート制限ポリシーのトピックに対応する、調整とレート制限の基盤となるテクノロジーについて詳しく説明します。説明の多くは、Mule Runtime 4.x にデプロイされた API にも該当します。 ## [](#用語)用語 レート制限と調整では、次の用語が使用されます。 - 制限: 一連のペア - 割り当てと期間 - 割り当て: API Manager で設定する ​`# of Reqs` - 期間: API Manager ペア - 期間と時間単位 - 再試行: 要求をキューに登録する調整機能 - コントラクト: アプリケーションと SLA の間の関係 ## [](#制限)制限 API Manager で制限を選択すると、制限および調整アルゴリズムの​_期間_​あたりの​_割り当て_​設定が定義されます。アルゴリズムは、最初の要求を受信したときにオンデマンドで作成されます。このイベントによって、期間が固定されます。 各要求は、期間が終了するまで、現在の期間の割り当てをコンシュームします。 割り当てが枯渇した場合のアクションは、ポリシーによって異なります。 - レート制限では、要求は拒否されます。 - 調整では、要求は再試行のためにキューに登録されます。 期間が終了すると、割り当てはリセットされ、同じ固定サイズの新しい期間が開始されます。 ポリシーは各制限の​_期間_​あたりの​_割り当て_​設定を使用してアルゴリズムを作成します。そのため、複数の制限が設定されている場合、要求が受け入れられるには、すべてのアルゴリズムに現在の期間で使用可能な割り当てが存在する必要があります。 ## [](#レスポンスヘッダー)レスポンスヘッダー 次のアクセス制限ポリシーは、要求の現在の状態に関する情報を含むヘッダーを返します。 - X-Ratelimit-Remaining: 使用可能な割り当て量。 - X-Ratelimit-Limit: 期間あたりに使用可能な最大要求数。 - X-Ratelimit-Reset: 新しい期間が開始されるまでの残り時間 (ミリ秒)。 ## [](#調整再試行)調整再試行 調整は、急増を緩和することを目的としているため、Mule Runtime は要求を遅延させて、後で再試行できます。次の例は、要求の拒否と受け入れがどのように行われるかを示しています。 ### [](#拒否される要求)拒否される要求 ポリシー設定: 5 件の要求/10 秒の期間、500ms の遅延で 1 回の再試行 ![throttling rejected request](/mulesoft/current/ja-jp/mule-gateway/_images/throttling-rejected-request.png) ユーザーは最初の 6 秒間で 5 件の要求を送信し、そのすべてが受け入れられます。8 秒の時点で新しい要求を受信しますが、割り当てが残っていないため、この要求は 500ms 遅延されます。 8.5 秒の時点でキューに登録された要求が再処理されます。期間がまだ終了していないため、割り当ては使用できないままです。再試行回数も残っていないため、この要求は拒否されます。 ### [](#受け入れられる要求)受け入れられる要求 ポリシー設定: 5 件の要求/10 秒の期間、500ms の遅延で 1 回の再試行 ![throttling accepted request](/mulesoft/current/ja-jp/mule-gateway/_images/throttling-accepted-request.png) ユーザーは最初の 9 秒間で 5 件の要求を送信し、そのすべてが受け入れられます。 9.7 秒の時点で新しい要求を受信しますが、割り当てが残っていないため、この要求は 500ms 遅延されます。 10 秒の時点で期間が終了し、割り当ては 5 にリセットされます。 開始から 10.2 秒後 (現在の期間の 0.2 秒の時点) に、キューに登録された要求が再処理されます。今回は、使用可能な割り当てがあるため、要求は受け入れられます (使用可能な割り当ては 4 に減ります)。 ### [](#configuration-設定)Configuration (設定) 調整ポリシーは HTTP スタック上で機能するため、キューに登録された各要求が再処理されるには、ユーザーと API の間で開かれた接続が保持される必要があります。このプロセスは大量のリソースを要するため、期間が長い場合は、HTTP または下層の TCP がタイムアウトのために接続をキャンセルすることがあります。 ゲートウェイ 2.x と Mule Runtime 3.x では強制されていませんが、使用期間は短くすることをお勧めします。1 秒の最大期間は短いとみなされます。このポリシーをスタンドアロン環境で使用することをお勧めします。 ## [](#クラスターとスタンドアロン)クラスターとスタンドアロン 弾力性を実現する 1 つの方法は冗長性を使用することです。つまり、同じ API に複数の Mule Runtime インスタンスを使用します。 この状況で考慮すべきことは、レート制限 (SLA ありまたはなし) を共有するかどうかということです。複数の Mule Runtime をクラスターで実行するように設定して、設定した制限を共有し、すべてのノードを全体として扱うことができます。 次に、さまざまなシナリオに対応した分析を示します。 ### [](#分散処理)分散処理 _n_​ 個のノードがあり、次のようになっています。 - 各ノードにはそれぞれのバックエンドがある。 - 最速の応答が必要である。 - 処理される要求数は、バックエンドの容量によってのみ制限される。 - SLA レベルが​_ない_​か、各ノードに 1 つだけある。 たとえば、2 つのノードが必要で、1 つは会社の有料ユーザーに割り当て、もう 1 つはその他に割り当てる場合などです。 このシナリオの分散処理では、クラスターの必要はありません。単に最も弱いノードのバックエンド容量を下回るポリシーを設定します。SLA のないシナリオでは、ノードがダウンした場合にロードバランサーが役立つことがあります。 ### [](#中央処理)中央処理 _n_​ 個のノードがあり、次のようになっています。 - バックエンドが一元化されている。 - 処理される要求数は、バックエンドの容量によってのみ制限される。 - SLA レベルが​_ない_​か、すべてのノードの SLA は 1 つで、同じである。 たとえば、すべてのノードが会社の有料ユーザーに割り当てられている場合などです。 前方にロードバランサーがあれば、クラスターの必要はありません。バックエンドの最大容量を ​_q_​ とすると、ポリシーを次のように設定します。 ![ポリシー数式の例](/mulesoft/current/ja-jp/mule-gateway/_images/quota-policy-formula.png) ここで、​![式内のオメガを表している記号](/mulesoft/current/ja-jp/mule-gateway/_images/omega.png)​ は、バックエンドの最大容量を下回る小さな数値です。 ロードバランサーがない場合、各ノードが処理するトラフィックを事前に設定できないため、スタンドアロンよりもクラスターノードをお勧めします。これらのポリシーは、ワークロードのバランスが完全に取れている場合でも、非常に不均衡な場合でも機能するように設計されています。バックエンドは余分な要求を受信しません。 ### [](#複数のワーカー)複数のワーカー _n_​ 個の CloudHub ワーカーがあり、次のようになっています。 - 各ワーカーは同じ API を表している。 - アプリケーションのワークロードはワーカー間に等しく分散されている。 アプローチは、​_中央処理_​のユースケースと同じです。 ### [](#複数のコントラクトの使用)複数のコントラクトの使用 _n_​ 個のノードがあり、次のようになっています。 SLA が適用されている。 レート制限 SLA が適用されていて、各ノードが複数の SLA からの要求を受け入れる必要がある場合は、各ノードが各 SLA からの何件の要求を処理するかを事前に決定できないため、クラスターが適しています。 ### [](#クラスター内の期間の長さ)クラスター内の期間の長さ クラスターでは、クラスター内での一貫性を保つためにノードは情報を共有する必要があります。共有プロセスによりレイテンシーが発生するため、パフォーマンスについて確認するときには考慮する必要があります。 最悪の場合、クラスターの一貫性のためにレイテンシーの影響を受ける要求の数は一定で、設定された割り当ての実際のサイズとは関係がありません。そのため、期間が短いほど、遅延する可能性がある要求の割合は大きくなります。したがって、レート制限ポリシーとレート制限 SLA ポリシーの設定では、1 分より長い期間​_のみ_​を設定することを強くお勧めします。 ### [](#レイテンシーの最小化)レイテンシーの最小化 クラスターアルゴリズムは、共有する情報の量を最小化することによって、パフォーマンスを最大化します。レスポンスヘッダー (X-Rate-Limit ヘッダー) は、クラスター内で使用可能な割り当てのサイズを予測するヒューリスティックを使用して計算されるため、要求のたびに再同期する必要がありません。ヘッダー情報内のエラーは常に 10% 未満です。それでも、受け入れられる要求の量が定義された割り当てより大きくなることはありません。 ### [](#configuration-設定-2)Configuration (設定) Mule ゲートウェイランタイム 2.x と Mule Runtime 3.x では、SLA ありまたはなしのレート制限ポリシーは、クラスター内で自動的に分散実行されます。この機能を無効にすることはできません。 ## [](#永続性)永続性 レート制限および調整アルゴリズムで日、月、年といった長い期間を使用するように設定できます。たとえば、クライアントとしてユーザー X が 1 年に 100 万件の要求をコンシュームすることを許可したいとします。ノードが期間中ずっと稼働しているか、それともメンテナンスが必要になるかを予測することはできません。メンテナンスを行うとランタイムを再起動する可能性があります。アルゴリズムはすでに数か月間実行されているため、クライアントは重要な情報を失います。永続性では、現在のポリシー状態を定期的に保存することによってこの問題を解決します。再デプロイメントや再起動が発生した場合、アルゴリズムは最後の既知の永続的な状態から再作成されるか、クリーンな状態から開始されます。 永続性はデフォルトで有効になっていますが、次のプロパティを false に設定することで無効にできます。 `throttling.persistence_enabled` また、永続性の頻度を調整できます。デフォルトは 10 秒です。 `throttling.persistent_data_update_freq` **IMPORTANT:**​ この機能は CloudHub では無効になっています。 ## [](#関連情報)関連情報 - [SLA 層の削除方法](https://docs.mulesoft.com/jp/api-manager/latest/defining-sla-tiers) - [リソースレベルポリシーについて](https://docs.mulesoft.com/gateway/latest/policies-resource-level-overview) # レート制限ポリシー

ポリシー名

レート制限

概要

一定期間に処理される要求の最大数を定義することで、API へのアクセスを監視します。

カテゴリ

サービス品質

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

v4.1.0

返される状況コード

400 - SOAP v1.2 を使用する WSDL API によってクォータを超過しました (Mule のみ)。現在のウィンドウの処理が完了するまで要求はブロックされます。

429 - クォータを超過しました。現在のウィンドウが完了するまで要求はブロックされます。

500 - SOAP v1.1 を使用する WSDL API によってクォータを超過しました (Mule のみ)。現在のウィンドウの処理が完了するまで要求はブロックされます。
## [](#概要)概要 レート制限ポリシーにより、API が特定の期間中に受け取ることができる要求数を制限することで、API への受信トラフィックを制御できます。この制限に達すると、ポリシーはすべての要求を拒否して、バックエンド API の負荷増大を回避します。 レート制限ポリシーを設定するときには、クォータ (要求数) と時間ウィンドウ (期間) の値を自由に組み合わせて指定できます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#mule-ゲートウェイ)Mule ゲートウェイ UI からレート制限ポリシーを API に適用する場合は、次のパラメーターを設定できます。
パラメーター 説明 例

Identifier (識別子)

DataWeave または正規文字列を使用したセレクターキー

#[attributes.method]​ は、HTTP で使用できるメソッドごとに異なるグループを作成します。たとえば、ポリシーレート制限の GET 要求のグループを POST 要求とは別に作成します。

Number of Reqs (要求の数)

ウィンドウで使用可能なクォータ

正の数

Time Period (期間)

クォータが適用される時間

正の数

Time Unit (時間単位)

時間の単位 (ミリ秒、秒、分、時)

Minutes (分)

Distributed (分散)

このフラグを有効にして相互接続されたランタイムを使用する場合、クォータはすべてのノード間で共有されます。

オンまたはオフ

Expose Headers (ヘッダーを公開)

応答の一部として ​x-ratelimit ヘッダー​を公開するかどうかを定義するオプション

オンまたはオフ
## [](#ポリシーのしくみ)ポリシーのしくみ レート制限ポリシーは、現在のウィンドウ (使用可能なクォータ) 内で要求数を監視し、使用可能なクォータが 0 より大きい場合にのみ、要求がバックエンドに到達できるようにします。 ポリシー設定で識別子を使用することで、複数の要求グループに対してポリシーを設定できます。各グループは、それぞれのウィンドウで別々の使用可能なクォータを持ちます。 レート制限ポリシーの仕組みをわかりやすくするため、10 秒ごとに 3 件の要求という設定で、ウィンドウ内のクォータに基づいて受信要求が許可または拒否される例を見てみましょう。 ![2 つの時間枠での受け入れられた要求と拒否された要求のタイムライン](/mulesoft/current/ja-jp/mule-gateway/_images/rate-limiting-generic-example.png) 最初のウィンドウでは、3 番目の要求でクォータに達したため、以降の要求はウィンドウが終了するまで拒否されます。2 番目のウィンドウでは、3 件の要求のうち 2 件しか処理されていないため、ウィンドウが終了しても、残りのクォータは少なくなります。 受け入れられた要求は API を経由してバックエンドに送られます。一方、拒否された要求は 429 の HTTP 状況コード (API が WSDL であれば 400 または 500) を返してバックエンドには到達しません。 一方、拒否された要求は 429 の HTTP 状況コード (API が WSDL であれば 400 または 500) を返してバックエンドには到達しません。 ## [](#例)例 上記の 10 秒ごとに 3 件の要求という設定で、レート制限ポリシーがクラスター用に設定され、識別子を使用する場合を考えてみましょう。 ### [](#正規文字列を使用した識別子の設定)正規文字列を使用した識別子の設定 UI を使用してポリシー設定に識別子を追加することで、要求のグループを定義できます。設定された制限は、各グループに別々に適用されます。レート制限ポリシー設定では、HTTP メソッドごとに 1 つのバケットに対して識別子 ​`#[attributes.method]`​ を使用できます。 UI の ​`Identifier`​ は非必須パラメーターです。デフォルトでは ​`Identifier`​ は値を持ちません。デフォルトを使用するか、または値を指定するかにより、ポリシーは次のように機能します。 - 未設定 (デフォルト) レート制限は、バケットまたはグループごとにすべての要求に適用されます。 - 必須 HTTP ヘッダーを使用するように設定 各ヘッダーには個別のクォータが割り当てられます。ヘッダー値では大文字と小文字が区別されます。クォータは​_遅延作成_​を使用して作成されます。 - 非必須 HTTP ヘッダーを使用するように設定 カスタムヘッダー、ペイロード、クエリパラメーター、または式の値には、個別のクォータが割り当てられます。 識別子が要求で送信されない場合、デフォルトで空の値に設定され、独自のクォータが使用されます。この動作では、未制御のクライアントによってコンシュームされる API にレート制限ポリシーを適用できると同時に、識別子を送信するクライアントの特別なバケットに対応します。 次の例は、10 秒おきに 3 つの要求の設定で識別子 ​`#[attributes.method]`​ を使用した場合に、一定期間に発生するイベントの順序を示しています。 ![経時的な GET 要求と POST 要求の受け入れと拒否を示す折れ線チャート](/mulesoft/current/ja-jp/mule-gateway/_images/rate-limiting-configure-identifiers-example.png) この例では、次のようになります。 - すべての HTTP メソッドでは 10 秒おきに 3 つの要求が許可されます (この例では、API に対して GET 要求と POST 要求のみが実行されています)。 - レート制限ポリシーは、固定されたウィンドウで機能します。 詳細は、図中のウィンドウサイズの括弧を参照してください。 - ウィンドウの開始時間は独立しています。 - エンジンはメソッドの最初の要求を受信するとレート制限アルゴリズムをスプールする​_遅延作成_​戦略を使用します。 ### [](#dataweave-式を使用した識別子の設定)DataWeave 式を使用した識別子の設定 レート制限エンジンは HTTP に依存せず、DataWeave 式の解決のみに左右されます。複雑なレート制限シナリオに対応するために UI の ​`Identifier`​ 式を変更することができます。 たとえば、すべてのクラス A およびクラス C の LAN 要求に 1 つのバケット、それ以外の要求に別のバケットを使用する識別子をレート制限ポリシーに設定できます。次の画像は前の文の 2 つ目のバケットを示し、DataWeave 式 ​`#[attributes.queryParam[‘customIdentifier’]]`​ をポリシー識別子として使用する 10 秒ごとに 3 件のクォータに相当します。 ![時間間隔で整理された受け入れられた要求と拒否された要求の両方を示すタイムライン](/mulesoft/current/ja-jp/mule-gateway/_images/rate-limiting-configure-identifiers-dataweave.png) この例では、次のようになります。 - 識別子のない要求はすべて空の識別子に解決されます。したがって、1 つのレート制限アルゴリズムを使用します。 - 識別子ごとに異なるバケットが使用され、各バケットには独立したクォータが割り当てられます。 この設定では、要求を実行した IP の地域に対応する false または true のバケットが作成されます。​`false`​ 値と ​`true`​ 値は、HTTP ではなくブール値のドメインに対応します。 いずれにせよ、エンジンは解決された式を文字列として扱うため、ポリシーは正常に機能します。この場合、値は自動的にブールから文字列にキャストされます。スクリプトに ​`output text/plain ---`​ を追加することで、DataWeave でキャストを明示的に定義できます。

HTTP RFC のヘッダー名では、大文字と小文字は区別されません。MuleSoft HTTP 用 Anypoint Connector は、ヘッダー名を小文字に変換します。ただし、DataWeave キーでは大文字と小文字が区別されます。したがって、​Identifier​ 式を作成するときには、小文字のヘッダーを参照するようにしてください。
### [](#無制限の識別子セットの設定)無制限の識別子セットの設定 すべての識別子結果では 1 つのアルゴリズムが使用されます。DataWeave 式が無制限の (非常に大規模な) 共用ドメインを返さないように注意して作成してください。このようなドメインが返されると、同じ数のアルゴリズムをメモリ内でホストしなければならなくなります (アルゴリズムが​_遅延作成_​戦略で作成されるため、可能なすべての識別子に対して最低 1 つの要求を実行する必要があります)。 たとえば、DataWeave 式で、インターネットに公開された Mule Runtime Engine での識別子として IP アドレスを使用するとします。インターネット上のすべての公開 IPv4 IP がこの Mule インスタンスに対して要求を実行すると、1 つの Mule インスタンスで 3,706,452,992 件のアルゴリズムが実行されます。 アルゴリズムの平均サイズが 250 バイトであれば、レート制限アルゴリズムのサイズは約 1 テラバイトになります。そのため、有限数の識別子に解決される DataWeave 式を使用することで、結果のセットをできるだけ小さくしてください。 ### [](#クラスター用のポリシーの設定-mule-のみ)クラスター用のポリシーの設定 (Mule のみ) 同じ 3 件の要求の設定例で、ウィンドウが 12:00:00 ちょうどに開始され、10 秒ごとにリセットされて、2 ノードのクラスターを使用するとします。両方のノードは同時にそれぞれのウィンドウを開始して終了し、クラスターではウィンドウごとに合計 3 件の要求が許可されます。 ![2 つのノードの受け入れられた要求と拒否された要求を追跡するタイムラインチャート](/mulesoft/current/ja-jp/mule-gateway/_images/rate-limiting-configure-clusters.png) ポリシーがクラスタリングされているため、クラスター全体で 3 件の要求を受け入れます。クラスタリングポリシーが無効化されると、Mule クラスターはウィンドウごとに 6 件の要求 (ノードごとに 3 件の要求) を受け入れることができます。 分散されたカウンターによってノードの同期が必要となり、その結果として発生するパフォーマンスの低下を回避するため、ポリシーではキャッシュメカニズムを使用して動作を予測し、スループットを最大化します。ただし、一部のシナリオではレイテンシーが増大するため、クラスタリング設定を使用する場合は注意が必要です。
クラスター用のレート制限ポリシーを設定する場合は、Mule Runtime Engine インスタンスが Mule クラスターの一部として実行されている必要があります。
## [](#レート制限ポリシーの設定)レート制限ポリシーの設定 レート制限ポリシーを設定する場合は、ポリシーの価値を最大限に引き出せるように、環境の特定の側面を考慮する必要があります。 ### [](#クラスター設定とスタンドアロン設定の選択)クラスター設定とスタンドアロン設定の選択 次のような設定により、環境で分散処理が行われている場合があります。 - 同じ API に対して複数のサーバーがある。 - 各サーバーにはそれぞれのバックエンドがある。 - 処理できる要求数はバックエンドによってのみ制限される。 - 最速の応答時間が求められる。 このようなシナリオでは、ポリシーをクラスタリング設定で実行する必要はありません。単純に、最も弱いノードのバックエンド容量を下回るようにポリシー制限を設定すれば十分です。ノードが停止した場合には、ロードバランサーが役立つことがあります。 あるいは、次のような設定により、環境で中央処理が行われている場合があります。 - 同じ API に対して複数のサーバーがある。 - 単一のバックエンドにすべてのプロキシが接続されている。 - プロキシの前にロードバランサーが設けられている。 このようなシナリオでは、クラスターは不要です。ただし、バックエンドの最大容量を超えないようにポリシーを設定する必要があります。 環境にロードバランサーが含まれていない場合は、スタンドアロンインスタンスではなくクラスターを使用することで、変動するトラフィックレベルにノードが対応できるようにしてください。レート制限ポリシーは、ワークロードが分散されていても分散されていなくても機能するように設計されています。バックエンドは過剰な要求を受け取らないため、最大容量を超えることはありません。 ### [](#クラスターノードのウィンドウサイズの選択)クラスターノードのウィンドウサイズの選択 1 分より長い処理ウィンドウを使用するように環境を設定することで、クラスター内のノードが情報を共有することで発生する潜在的なレイテンシーを防止します。 この設定の推奨事項は、クラスターシナリオでのレート制限ポリシーとレート制限 SLA ポリシーの両方に適用されます。 ### [](#レート制限ポリシーの永続性の選択-mule-のみ)レート制限ポリシーの永続性の選択 (Mule のみ) レート制限ポリシーは、数日、数か月、あるいは数年に渡って永続するウィンドウを使用するように設定できます。たとえば、1 年間に 100 万件の要求をコンシュームできるようにしたいものの、その期間全体に渡ってノードが稼動しているかどうか、あるいは Mule Runtime Engine の再起動が発生するメンテナンスが必要になるかどうかについては確信が持てないとします。 アルゴリズムはすでに数か月間実行されているため、クライアントは重要な情報を失います。永続性では、現在のポリシー状態を定期的に保存することによってこの問題を解決します。再デプロイメントや再起動が発生した場合、アルゴリズムは最後の既知の永続的な状態から再作成されるか、クリーンな状態から開始されます。 永続性はデフォルトで有効になっていますが、次のプロパティを false に設定することで無効にできます。 `throttling.persistence_enabled` また、永続性の頻度を調整できます。デフォルトは 10 秒です。 `throttling.persistent_data_update_freq`

永続性は CloudHub では使用できません。 CloudHub 2.0 の ObjectStore v2 で提供される永続性はサポートされていません。
## [](#faq)FAQ **このウィンドウはいつ開始されますか?** このウィンドウは、ポリシーが正常に適用された後の最初の要求で開始されます。 **アルゴリズムが使用するウィンドウの種別は?** 固定ウィンドウです。 **クォータを使い果たすとどうなりますか?** アルゴリズムは、最初の要求を受信したときにオンデマンドで作成されます。このイベントによって、期間が固定されます。各要求は、期間が終了するまで、現在のウィンドウの要求クォータをコンシュームします。 要求クォータを使い果たすと、レート制限ポリシーは要求を拒否します。ウィンドウが終了すると、要求クォータはリセットされ、同じ固定サイズの新しいウィンドウが開始されます。 **複数の制限を定義するとどうなりますか?** ポリシーはウィンドウあたりの要求クォータ設定を使用して各制限のアルゴリズムを作成します。そのため、複数の制限が設定されている場合、要求が受け入れられるには、すべてのアルゴリズムに現在のウィンドウで使用可能な要求クォータが存在する必要があります。 **各レスポンスヘッダーの意味は?** 各レスポンスヘッダーは、要求の現在の状態に関する情報を返します。 - X-Ratelimit-Remaining: 使用可能な要求クォータ - X-Ratelimit-Limit: 各ウィンドウで使用可能な最大要求数 - X-Ratelimit-Reset: 新しいウィンドウが開始されるまでの残り時間 (ミリ秒) デフォルトでは、応答の X-RateLimit ヘッダーは無効になっています。これらのヘッダーを有効にするには、ポリシーの設定時に ​**\[Expose Headers (ヘッダーを公開)\]**​ を選択します。 **Mule クラスターを CloudHub で設定できますか?** いいえ。この機能は、RTF、ハイブリッド、およびスタンドアロン Mule 設定でのみ使用できます。 **レート制限 SLA やスパイク制御ではなくレート制限ポリシーを使用する必要がある状況は?** レート制限ポリシーと​**レート制限 SLA**​ ポリシーは、説明責任を果たすためにハード制限を (レート制限で識別子を使用して) グループまたは (​**レート制限 SLA**​ を使用して) クライアントアプリケーションに適用する場合に使用します。バックエンドを保護するには、代わりに​**スパイク制御**​を使用してください。 # レート制限ポリシー \[Apply (適用)\] をクリックしてポリシーを適用すると、ポリシー設定ダイアログが表示されます。要求の数、要求を受信する期間、時間単位を設定します。たとえば、\[policy configuration (ポリシー設定)\] ダイアログの \[Limits (制限)\] セクションでは、次の制限を設定できます。
# of Reqs (要求数) Time Period (期間) Time Unit (時間単位)

123

2000

Millisecond (ミリ秒)

100

1000

Millisecond (ミリ秒)
レート制限ポリシーの場合、API が 2000 ミリ秒以内に 123 件の要求を受信すると API はそれ以降の要求を拒否し、API が 1000 ミリ秒以内に 100 件の要求を受信すると API はそれ以降の要求を拒否します。調整ポリシーの場合、要求は拒否されずキューに登録されます。 ## [](#関連情報)関連情報 - [レート制限 SLA ポリシー](https://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting-sla) # 内部 Mule ゲートウェイポリシー すべての内部ポリシーの説明については、​[「内部ポリシーディレクトリ」](https://docs.mulesoft.com/jp/mule-gateway/policies-included-directory)​を参照してください。 API に適用される API は前のリリースと同じですが、いくつか例外があります。 アプリケーション、ランタイムとコネクタ、ポリシー間のクラスローダー分離があります。分離要件を満たすために、アプリケーションと同様に、ポリシーは自己完結型で、実行に必要なライブラリが含まれるようにパッケージされています。 ポリシーは非ブロックです。他のすべてのポリシーよりも優先される CORS を除き、すべてのポリシーを順序付けることができます。 MEL 式は DataWeave に置き換えられています。 ## [](#ポリシー管理と-mule-4)ポリシー管理と Mule 4 Mule 4 では、アプリケーション、ランタイム、コネクタ、ポリシー間のクラスローダー分離があります。 ポリシーには他に次の変更があります。 - すべてのポリシーは非ブロックです。非ブロックについては、Mule 4 のドキュメントを参照してください。 - すべてのポリシーは、最初に実行される CORS を除き、順序付けできます。 - RAML ベースの API に限定されていたリソースレベルのポリシーサポートが HTTP API に拡張されています。 - ランタイム以外にポリシーを配布できるため、アップグレードが簡略化されます。 Mule 4 では、ポリシーのパッケージ、サイズ、およびスコープが変更されています。 ## [](#提供されるポリシーと-mule-4)提供されるポリシーと Mule 4 API Governance のポリシーには次の重要な変更があります。 - API Manager で、2 つの HTTP 基本認証ポリシーが提供されるようになりました。一方は、Web リソースにアクセス制御を適用するための最も簡易な手法に基づくポリシーで、もう一方は LDAP 設定に対するポリシーです。 API を 2017 年 7 月から 2017 年 11 月にアップグレードする場合、セキュリティマネージャーのセットアップ情報は不要になります。ポリシーでこの情報が取り込まれます。 - ヘッダー伝搬がデフォルトで行われることはなくなりました。\[Expose Headers (ヘッダーを公開)\] チェックボックスをオンにして、トークン適用およびレート制限ポリシーのためにヘッダー伝搬を設定できます。 - クラスターノード (デフォルト) 間で割り当てを共有するかどうかをレート制限ポリシーに設定できます。 ## [](#関連情報)関連情報 - [ポリシーの適用](https://docs.mulesoft.com/jp/mule-gateway/policies-included-apply) - [ポリシーの並び替え](https://docs.mulesoft.com/jp/mule-gateway/policies-reorder) # 内部ポリシー ポリシーを API に適用するプロセスで、適用できるポリシーのリストが表示されます。 ![セキュリティポリシーとその要件を示すテーブル](/mulesoft/current/ja-jp/mule-gateway/_images/select-policy.png) ポリシーがすでに適用されている場合、または提供される保護が、適用されたポリシーによってすでに達成されている場合、そのポリシーは使用できなくなったように見えます。リストをポリシーのカテゴリで絞り込むことができます。 - コンプライアンス - セキュリティ - サービス品質 カテゴリを選択すると、実現する保護の種類によってリストをさらに絞り込むことができます。検索条件で指定された保護のレベルを実現するための要件もリストされます。 ![ポリシーオプションが表示され、選択が必要なフォーム](/mulesoft/current/ja-jp/mule-gateway/_images/policy-filters.png) Anypoint Platform には、次のポリシーがあります。 - [ヘッダーの追加](#api-manager::policy-mule3-add-headers-policy.adoc) 要求または応答に対して HTTP ヘッダーを挿入します。 - [Remove Headers](#api-manager::policy-mule3-remove-headers-policy.adoc) 要求または応答に対して HTTP ヘッダーを削除します。 - [クライアント ID 適用](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-client-id-based-policies) API へのコールに有効なクライアント ID とクライアントシークレットを含める必要があるという要件を適用します。脚注を参照してください。 - [クロスオリジンリソース共有](#api-manager::policy-mule3-cors-policy.adoc) Web ページで実行された JavaScript XMLHttpRequest (XHR) コールが発生元以外のドメインからのリソースとやりとりを行うことを可能にします。CORS は、一般に、すべてのブラウザーによって適用される「同じ発生元のポリシー」に対するソリューションとして実装されます。このポリシーは、すべての発生元を有効にし、API のすべてのリソースを公開します。 - [HTTP 基本認証ポリシー](#api-manager::policy-mule3-http-basic-authentication-policy.adoc) セキュリティマネージャーポリシーで設定された詳細に従って認証を適用します。 - [JSON 脅威保護](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-json-threat) 問題の原因となり得る悪意のある JSON に対して対象 API を保護します。 - [LDAP セキュリティマネージャー](#api-manager::policy-mule3-ldap-security-manager.adoc) LDAP ベースのセキュリティマネージャーを対象 API に挿入します。 - [外部プロバイダーを使用した OAuth 2.0 アクセストークンの適用ポリシー](#api-manager::policy-mule3-mule-oauth-2.0-token-validation-policy.adoc) エンドポイントが、必須で有効な OAuth 2.0 トークンを要求するように API を設定します。OAuth プロバイダーとして機能する外部 Mule アプリケーションを参照する必要があります。このポリシーを使用する前に、提供されたスニペットを使用して API の RAML を更新してください。 - [OpenAM アクセストークン適用](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-openam-oauth-token-enforcement-policy) エンドポイントが、必須で有効な OpenAM トークンを要求するように API を設定します。このポリシーは、OpenAM 統合 ID 管理システムを使用している組織でのみ使用できます。 - [OpenID Connect OAuth 2.0 トークン適用](https://docs.mulesoft.com/gateway/latest/policies-included-openid-token-enforcement) エンドポイントが、必須で有効なトークンを要求するように API を設定します。このポリシーは、OpenID Connect 管理システムを使用している組織でのみ使用できます。 - [レート制限 – SLA ベース](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-rate-limiting-and-throttling) API によって処理される一定期間あたりのメッセージ数を SLA 層で指定される最大値に制限します。最大値を超えるメッセージは拒否されます。適用は、要求で渡されるクライアント ID に基づきます。脚注を参照してください。 - [レート制限](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-apply-rate-limiting) API によって処理される一定期間あたりのメッセージ数をポリシーで指定される最大値に制限します。レート制限は、ソースに関係なくすべての API コールに適用されます。最大値を超えるメッセージは拒否されます。 - [単純なセキュリティマネージャー](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-simple-security-manager) デモ目的のために、ハードコードされたユーザー名とパスワードを使用して設定できるプレースホルダーセキュリティマネージャーをサポートします。 - [調整 - SLA ベース](#api-manager::policy-mule3-rate-limiting-and-throttling-sla-based-policies.adoc) API によって処理される一定期間あたりのメッセージ数を SLA 層で指定される最大値に調整します。最大値を超えるメッセージは後で処理するためにキューに登録されます。適用は、要求で渡されるクライアント ID に基づきます。脚注を参照してください。 - [調整](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-throttling-rate-limit) API によって処理される一定期間あたりのメッセージ数をポリシーで指定される最大値に調整します。調整は、ソースに関係なくすべての API コールに適用されます。最大値を超えるメッセージは後で処理するためにキューに登録されます。 - [XML 脅威保護](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-xml-threat) 問題の原因となり得る悪意のある XML に対して対象 API を保護します。 **注意**​: このポリシーを使用する前に、提供されたスニペットを使用して API の RAML を更新してください。 ## [](#関連情報)関連情報 - [RAML/OAS ベースの特性とポリシーの概念](https://docs.mulesoft.com/jp/api-manager/latest/prepare-raml-task) # 内部ポリシーディレクトリ ## [](#mule-gateway-に含まれているポリシー)Mule Gateway に含まれているポリシー
ポリシー 概要

基本認証: LDAP

LDAP で定義されたユーザー-パスワードを使用して基本認証メカニズムに基づいてアクセスを許可する

基本認証: シンプル

1 つのユーザー-パスワードを使用して基本認証メカニズムに基づいてアクセスを許可する

クライアント ID 適用

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

クロスオリジンリソース共有 (CORS)

外部ドメインに存在するリソースへのアクセスを可能にする

デトークナイゼーション

トークナイズされた値を元の値に戻す

ヘッダーの挿入

要求または応答にヘッダーを追加する

ヘッダーの削除

要求または応答からヘッダーを削除する

HTTP キャッシュ

API 実装から HTTP 応答をキャッシュする

IP 許可リスト

IP アドレスのリストまたは範囲からのアクセス要求を許可する

IP ブロックリスト

単一の IP アドレスまたは IP アドレスの範囲からの API エンドポイントへのアクセスをブロックする

JSON 脅威保護

API 要求内の悪意のある JSON から保護する

JWT 検証

JWT トークンを検証する

メッセージログ

受信した要求からの情報、バックエンドからの応答、または同じ API エンドポイントに適用されている他のポリシーからの情報を使用してカスタムメッセージを記録する

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

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

OpenAM OAuth 2.0 トークン適用

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

OpenID Connect OAuth 2.0 アクセストークン適用

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

PingFederate OAuth 2.0 トークン適用

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

レート制限

一定期間に処理される要求の最大数を定義することで、API へのアクセスを監視します。

レート制限: SLA ベース

SLA に基づいた期間中に処理される要求の最大数を定義することで、API へのアクセスを監視します。

スパイク制御

API トラフィックを規制する

トークナイゼーション

機密データをトークンと呼ばれる非機密データ要素に変換する

XML 脅威保護

API 要求内の悪意のある XML から保護する
## [](#関連情報)関連情報 - [Flex Gateway ポリシーの概要](https://docs.mulesoft.com/gateway/latest/gateway-secure-apis) - [ゲートウェイ別のポリシーの可用性](https://docs.mulesoft.com/jp/policies/policies-availability-by-gateway) # 基本認証: LDAP ポリシー

ポリシー名

基本認証: LDAP

概要

LDAP で定義されたユーザー-パスワードを使用して基本認証メカニズムに基づいてアクセスを許可する

カテゴリ

セキュリティ

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

v4.0.0

返される状況コード

401 - 未承認または無効なクライアントアプリケーションのログイン情報
## [](#概要)概要 Lightweight Directory Access Protocol (LDAP) 認証ポリシーは、LDAP 認証メカニズムを使用して API へのアクセスを制限する方法を指定します。このポリシーは、Flex および Mule 4 以降で使用できます。 エラーに遭遇すると、基本認証 - LDAP ポリシーは ​`WWW-Authenticate: Basic realm="mule-realm"`​ の形式で「WWW-Authenticate」 HTTP ヘッダー項目を返します。 LDAP は上下反転した木であり、それぞれの葉にユーザー名-パスワードのペアおよび関連付けられたメタデータがあります。各レベルは木の枝のように分かれています。LDAP の詳細については、 [「LDAP^ について」](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol)​を参照してください。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#mule-ゲートウェイ)Mule ゲートウェイ UI から基本認証 - LDAP ポリシーを API に適用する場合は、LDAP または Active Directory に接続するための以下のパラメーターを設定できます。
パラメーター 説明

LDAP Server URL (LDAP サーバー URL)

ポート番号を含む、LDAP または LDAPS サーバーの URL。

LDAP User DN (LDAP ユーザー DN)

LDAP のユーザーをトラバースおよびリストするためのアクセス権を持つユーザーまたはユーザーグループの名前。

LDAP User Password (LDAP ユーザーパスワード)

ユーザーまたはユーザーグループのパスワード。パスワードはセキュアな値でなければなりません。これは、指定すると表示または再取得できなくなる値です。

LDAP Search Base (LDAP 検索ベース)

ディレクトリツリー内の検索の開始点。

LDAP Search Filter (LDAP 検索条件)

Active Directory または OpenLDAP モデルの検索条件。例を参照してください。
LDAP または Active Directory に正常に接続するには、すべてのパラメーターが必要です。 ## [](#active-directory-の設定例)Active Directory の設定例 以下の値を設定することで、Active Directory の LDAP 認証を設定できます。
項目 リテラル文字列値の例 セキュアプロパティプレースホルダーの例

LDAP Server URL (LDAP サーバー URL)

ldap://174.19.33.17:389/

${ldap.server.url}

LDAP Secure Server URL (SSL) (LDAP セキュアサーバー URL (SSL))

ldaps://my-company-ldap.cloudhub.io:1010/

${ldap.server.url}

LDAP Server User DN (LDAP サーバーユーザー DN)

CN=Administrator,CN=Users,DC=my-company,DC=com

${ldap.user.dn}

LDAP User Password (LDAP ユーザーパスワード)

somePassword

${ldap.password}

LDAP Search Base (LDAP 検索ベース)

CN=Users,DC=my-company,DC=com

${ldap.search.base}

LDAP Search Filter (LDAP 検索条件)

(sAMAccountName={0})

${ldap.search.filter}
例の検索条件文字列は Active Directory アプリケーションに固有です。 ## [](#openldap-の設定例)OpenLDAP の設定例 以下の値を設定することで、OpenLDAP の LDAP 認証を設定できます。
項目 リテラル文字列値の例 セキュアプロパティプレースホルダーの例

LDAP Server URL (LDAP サーバー URL)

ldap://174.19.33.17:389/

${ldap.server.url}

LDAP Secure Server URL (SSL) (LDAP セキュアサーバー URL (SSL))

ldaps://my-company-ldap.cloudhub.io:1010/

${ldap.server.url}

LDAP Server User DN (LDAP サーバーユーザー DN)

cn=Manager,dc=my-company,dc=com

${ldap.user.dn}

LDAP User Password (LDAP ユーザーパスワード)

somePassword

${ldap.password}

LDAP Search Base (LDAP 検索ベース)

ou=people,dc=my-company,dc=com

${ldap.search.base}

LDAP Search Filter (LDAP 検索条件)

(uid={0})

${ldap.search.filter}
例の検索条件文字列は OpenLDAP アプリケーションに固有です。 ## [](#ポリシーのしくみ)ポリシーのしくみ 基本認証 - LDAP ポリシーは、保護されているリソースに対する要求を捕捉して、​`Authorization`​ HTTP ヘッダーを確認します。 そして、Base64 でエンコードされているユーザー名とパスワードを抽出して、設定されている LDAP インスタンスに対して、提供されている LDAP コンテキストにおいてユーザーのログイン情報が正しいかどうかを判断するように要求します。 ログイン情報に対する基本認証: LDAP ポリシーは、以下の方法を使用して設定できます。 - 指定されているレベルでユーザー名とパスワードのペアを検索する。 - 指定されているレベルとその下位レベルでユーザー名とパスワードのペアを検索する。ただし、この検索オプションは包括的であるため、パフォーマンスが低下することがあります。 ### [](#検索スコープ)検索スコープ 検索スコープオプションは、使用しているポリシーバージョンによって異なります。検索スコープオプションは、LDAP 1.0.0 では 1 レベル、LDAP 1.1.0 では 2 レベル (サブツリー) となります。 `one level`​ または ​`subtree`​ の検索スコープは、​`LDAP Search in subtree`​ オプションを使用して選択します。 `LDAP search base`​ は、ディレクトリ内の検索の開始点です。 ### [](#1-レベル検索スコープ)1 レベル検索スコープ このオプションを使用すると、検索条件は ​`LDAP search base`​ 直下のオブジェクトのみに影響しますが、​`LDAP search base`​ 自身は含まれません。 次の例では、第 1 レベルに 4 つのエントリ (2 つのユーザーと 2 つのグループ) があります。検索にはこれらのエントリのみが含まれます。 ![階層チャートに組織構造およびユーザー ID が表示されます](/mulesoft/current/ja-jp/mule-gateway/_images/search-scope.png) 検索条件を ​`(uid={0})`​ に設定した場合、​`Jane`​ と ​`Paul`​ のみが見つかります。グループエントリは考慮されません。 #### [](#サブツリー検索スコープ)サブツリー検索スコープ このオプションを使用すると、基本認証 - LDAP ポリシーは ​`LDAP search base`​ の下のサブツリーも調べ、​`LDAP search base`​ レベルも含めます。ただし、この動作によりパフォーマンスが影響を受けます。 上の例では、分析される領域には組織全体が含まれます。組織のすべてのレベルでグループエントリとユーザーエントリが考慮されます。 ![階層チャートに会社の組織構造が表示されます](/mulesoft/current/ja-jp/mule-gateway/_images/search-scope2.png) ## [](#基本認証ポリシーが適用された-api-への要求の作成)基本認証ポリシーが適用された API への要求の作成 基本認証 - LDAP ポリシーを API に適用した後は、その API への要求には次のヘッダーを含める必要があります。 Authorization: Basic `username:password`​ の値は Base64 でエンコードされた文字列である必要があります。たとえば、Mac OS X や Linux システムでは、ユーザー名とパスワードの要件は次のように実装されます。 `echo -n ':' | base64` Mule Runtime Engine (Mule) はヘッダーのログイン情報を分割し、要求を LDAP サーバーに検索条件と共に送信します。 LDAP は ​`username`​ と検索条件から登録済みユーザーを見つけた後に、ログイン情報を検証します。有効な結果が Mule に返されます。 ![LDAP サーバーを介したクライアント認証のメッセージフローを示すシーケンス図](/mulesoft/current/ja-jp/mule-gateway/_images/ldap-verification.png) 無効な要求の例を下図に示します。 ![認証のメッセージフローを示すシーケンス図](/mulesoft/current/ja-jp/mule-gateway/_images/ldap-verification-invalid.png) 基本認証 - LDAP ポリシーは HTTP 401 状況コードをスローします。これは、認証ヘッダーが不正である、提供されていない、または無効であることを示します。 # 基本認証: 簡易ポリシー

ポリシー名

基本認証: シンプル

概要

1 つのユーザー-パスワードを使用して基本認証メカニズムに基づいてアクセスを許可する

カテゴリ

セキュリティ

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

v4.0.0

返される状況コード

400 - SOAP 1.2 を使用した WSDL API での未承認または無効なクライアントアプリケーションのログイン情報

401 - HTTP または RAML API での未承認または無効なクライアントアプリケーションのログイン情報

500 - SOAP 1.1 を使用した WSDL API での未承認または無効なクライアントアプリケーションのログイン情報
## [](#概要)概要 基本認証: 簡易ポリシーは、要求を出すアプリケーションに対してユーザー名とパスワードを強制的に提供させることで API を保護します。 このポリシーは、 [基本 HTTP 認証標準](https://tools.ietf.org/html/rfc7617)​に準拠します。 エラーに遭遇すると、このポリシーは「WWW-Authenticate」 HTTP ヘッダー項目を返します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#mule-ゲートウェイ)Mule ゲートウェイ 基本認証: 簡易ポリシーを API に適用した後は、その API への要求に次のヘッダーを含める必要があります。 Authorization: Basic `username:password`​ の値は Base64 でエンコードされた文字列である必要があります。たとえば、Mac OS X や Linux システムでは、ユーザー名とパスワードの要件は次のように実装されます。 `echo -n ':' | base64` # 自動ポリシー 自動ポリシーを使用し、Mule で実行されているすべての API に同じポリシーを適用することで、セキュリティ要件とロギング要件を適用します。ポリシーの自動化により、安全で一貫した API をすばやく設計、構築してデプロイできます。 自動ポリシーを使用すると、対象環境で重要なポリシーが自動的に適用され、エラーが減少するため、確信を持って API をデプロイできます。システム管理者は、ポリシーを忘れずに手動で挿入して共通の標準を適用する必要がなくなります。 すべての​[内部ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-directory)​と​[カスタムポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-overview)​を自動ポリシーとして設定でき、それらを、環境下で実行されている API に適用できます。 ## [](#mule-の自動ポリシー)Mule の自動ポリシー Mule Runtime Engine (Mule) の自動ポリシーには以下のルールが適用されます。 - 自動ポリシーは、MuleSoft でホストされるコントロールプレーンを使用する Mule 4 API でのみ使用できます。 - 自動ポリシーはすべてのランタイムデプロイメント対象 (CloudHub、Runtime Fabric、およびハイブリッド) をサポートします。 - 自動ポリシーは、すでに特定の API プロキシに適用されている同じ種別のポリシーよりも優先されます。 たとえば、Mule 4.1.2 を実行している API プロキシの IP 許可リストポリシーで IP 範囲 192.168.100.0/22 (192.168.100.0 ～ 192.168.103.255) のみが許可されている場合に、IP 範囲 192.168.100.14/24 (192.168.100.0 ～ 192.168.100.255) のみを許可する新しい IP 許可リスト自動ポリシーを作成し、サポートされるすべての Mule バージョン (4.1.1 以上) に適用すると、この後者の自動ポリシーが優先されます。 上記の例では、IP 範囲は自動ポリシーの適用時に変更されます。 また、すでに適用されている自動ポリシーがある場合、その特定の種別のポリシーを、特定の API プロキシの提供ポリシーとして適用することはできません。 - システム管理者は、ポリシーを適用する環境に外部 ID プロバイダー (IdP、OpenID など) が含まれる場合は、これらの ID プロバイダーに特有のポリシーを適用できます。 この場合は、同じ IdP が設定されている API にのみポリシーが適用されます。たとえば、PingFederate アクセストークン適用ポリシーを適用すると、PingFederate を IdP として使用するように設定されている API にのみポリシーが適用されます。

自動ポリシーで保護されている API インスタンスには​アラート​を追加できません。
## [](#関連情報)関連情報 - [自動ポリシーの適用](https://docs.mulesoft.com/jp/mule-gateway/policies-automated-applying) # 自動ポリシーの適用 「​**組織の管理者**​」または「​**環境管理者**​」のユーザー、あるいは環境内の「​**ポリシーの管理**​」ロールを持つユーザーは、自動ポリシーの作成、編集、削除ができます。 ## [](#タスクの前提条件)タスクの前提条件 自動ポリシーを適用する前に、以下を確認してください。 - [Mule ゲートウェイ機能](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-capabilities-mule4)​が有効化された状態で Mule Runtime Engine (Mule) がインストールされている。 - 基本エンドポイントまたはプロキシエンドポイントが設定された ​[API](https://docs.mulesoft.com/jp/api-manager/latest/api-instance-landing-page)​ が API Manager 内に存在する。 - 自動検出によって API にリンクされている ​[HTTP(S) ベースフロー](https://docs.mulesoft.com/jp/http-connector/1.10/http-listener-ref)​で Mule アプリケーションがデプロイされている。 Mule アプリケーション内で自動検出が正しく設定されている場合、アプリケーションの API は API Manager によって追跡されている、または API Manager にペアリングされているとみなすことができます。 ほとんどの場合は、自動生成プロキシによってこれらの前提条件が処理されます。Mule ゲートウェイは、実行時に API Manager で API に適用される自動ポリシーを調整します。 ## [](#自動ポリシーを適用する)自動ポリシーを適用する 自動ポリシーを適用する手順は次のとおりです。 1. **\[API Manager\]**​ の左ナビゲーションメニューで ​**\[Automated Policies (自動ポリシー)\]**​ を選択します。 2. **\[Apply new automated policy (新しい自動ポリシーを割り当て)\]**​ をクリックします。 3. 提供ポリシーとして設定する提供ポリシーを選択します。 Mule 4 の任意の提供ポリシーを自動ポリシーとして設定できます。 各提供ポリシーの設定方法については、​[使用可能な提供ポリシーのリスト](https://docs.mulesoft.com/jp/policies/policies-availability-by-gateway)​を参照してください。カスタムポリシーの作成方法については、記事​[「カスタムポリシーの作成」](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-creating-custom-policy)​を参照してください。 自動ポリシーを設定する場合、ポリシー設定ページの下部に ​**\[Rule of Applications (アプリケーションのルール)\]**​ サブセクションがあります。これにより、ポリシーの影響を受ける一連のランタイムを規定します。 - **All runtimes (すべてのランタイム)**​: ランタイムに関係なくポリシーをすべての API インスタンスに適用します。 - **Flex Gateways only (Flex Gateway のみ)**​: ポリシーをすべての Flex Gateway API インスタンスに適用します。 - **Mule Gateways only (Mule ゲートウェイのみ)**​: ポリシーを Mule 4.1.1 以降で実行されているすべての Mule ゲートウェイ API インスタンスに適用します。Mule ゲートウェイのみに適用する場合は、次のパラメーターを設定します。 - バージョン範囲 自動ポリシーを継承する Mule Runtime バージョンの範囲を設定できます。 たとえば、​**\[From Version (最小バージョン)\]**​ の入力が「4.1.2」で、​**\[To (最大バージョン)\]**​ が「4.1.4」の場合、自動ポリシーはこの範囲内のすべてのデプロイ済み API に適用されます。4.1.5 に基づいてデプロイされた API はポリシーの影響を受けません。 値は ​`4.1.x`​ のように含めることができます。たとえば、4.1.1 ～ 4.1.x の範囲を追加した場合、ランタイムのすべてのパッチリリースが対象になります。4.1.0 に基づく API プロキシは、4.1.1 よりも低いため、この範囲に含まれません。 設定しているポリシーの種別が、アプリケーションのルールの影響を受ける API プロキシに提供ポリシーとしても存在する場合、続行する前に競合を解決する必要があります。解決方法についての詳細は、以下の​[\[Conflict Management\]](<#Conflict Management>)​セクションを参照してください。 - **Java バージョン**​ ポリシーを ​**\[All Java versions (すべての Java バージョン)\]**​ に適用するか ​**\[Choose specific Java versions (特定の Java バージョンを選択)\]**​ するかを選択します。ポリシーを特定の Java バージョンに適用することを選択する場合は、​**Java 8**​、​**Java 17**​、またはその両方を選択します。 4. **\[Apply (適用)\]**​ をクリックします。
自動ポリシーを本番環境に適用する前に下位の環境に適用し、自動ポリシーが既存の API コントラクトに影響しないことを確認することをお勧めします。
## [](#競合管理)競合管理 自動ポリシーは API レベルのポリシーよりも優先されるため、API レベルのポリシーとしてすでに適用されている自動ポリシーを追加すると、選択されたランタイム範囲を使用してデプロイされた API では、競合が検出されます。これを、続行する前に解決する必要があります。 競合が検出された場合、競合する API のリストを含むポップアップが表示されます。メッセージが表示され、競合する最初の 10 個の API と合計数が示されます。次のエンドポイントを使用して、すべての API のリストにアクセスできます。 ```CURL curl -X GET \ https://anypoint.mulesoft.com/xapi/v1/automated-policies/{groupId}/{assetId}/conflicting-apis \ -H 'Authorization: Bearer {token}' ``` 競合を解決するには、設定済みの API のリストから API を選択し、競合するポリシーを手動で無効化または削除するか、設定済みの API に対してすべての競合するポリシーを上書きするように選択します。この最後のオプションを選択した場合、API の競合するポリシーは無効化されます。自動ポリシーを削除すると、API のポリシーは自動的に再有効化されます。 ## [](#新しい-api-のデプロイ)新しい API のデプロイ 新しい API を管理する場合、環境に適用された自動ポリシーの状況に関する情報を \[​**Policies (ポリシー)**​\] タブで参照できます。自動ポリシーは、アプリケーションが \[Active (アクティブ)\] の状況になるまで表示されません。 アプリケーションがデプロイされると、適用された自動ポリシーのリストが API の ​**\[Policies (ポリシー)\]**​ タブに表示されます。 環境に対する​**「ポリシーの参照」**​ロールを持つユーザーは、適用された自動ポリシーのリストを参照できます。 アプリケーションをデプロイした環境に、デプロイしたランタイムを対象としない自動ポリシー、たとえば、4.1.2 ～ 4.1.4 のランタイム範囲に影響する自動ポリシーがある場合、ユーザーが 4.1.5 ランタイムにデプロイすると、通知が組織と環境の管理者に送信され、このアクティビティが通知されます。 ### [](#カバー率の状況を表示する)カバー率の状況を表示する 自動ポリシーで API インスタンスがカバーされるかどうか、またはなぜカバーされないかを確認するには、API インスタンスの ​**\[Coverage status (カバー率の状況)\]**​ を参照します。通常、インスタンスがカバーされない原因はランタイム種別またはランタイムバージョンです。 自動ポリシーでカバーされる API インスタンスを表示する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. \[API Administration (API 管理)\] で、​**\[Automated Policies (自動ポリシー)\]**​ をクリックします。 3. カバー率を表示するポリシーのその他のオプションボタン (​!["\[More Options (その他のオプション)](/mulesoft/current/ja-jp/mule-gateway/_images/more-options-menu.png) メニューを表す横に表示された 3 つの円",1%,1%\]​) をクリックし、​**\[See covered APIs (カバーされる API を確認)\]**​ をクリックします。 4. **\[Coverage status (カバー率の状況)\]**​ 列で API インスタンスのカバー率の状況を参照します。
カバー率の状況で絞り込むには、カバー率の状況ドロップダウンをクリックして、カバー率の状況オプションを選択します。
## [](#適用されたポリシーの監査)適用されたポリシーの監査 自動ポリシーの影響を受けたすべての API のリストを監査し、取得することができます。レポートはランタイムバージョンおよび操作により絞り込むことができます。 環境内のすべての自動ポリシーのリストを取得する方法 ```curl curl -X GET \ https://anypoint.mulesoft.com/apimanager/api/v1/organizations/{organizationId}/automated-policies?environmentId={envId} \ -H 'Authorization: Bearer {token}' ``` 自動ポリシーの範囲に含まれる API、または自動ポリシーが適用されない API のリストを取得する方法。 ```curl curl -X GET \ https://anypoint.mulesoft.com/apimanager/api/v1/organizations/{organizationId}/automated-policies/{automatedPolicyId}/apis \ -H 'Authorization: Bearer {token}' ``` ## [](#関連情報)関連情報 - [内部ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-directory) # 設定および定義ファイルの参照 カスタムポリシーを作成するための、設定ファイル (XML) と定義ファイル (YAML) の完全な技術的リファレンスを次に示します。 ## [](#ポリシー設定-xml-ファイル)ポリシー設定 XML ファイル ポリシー設定は、ポリシーの実際の実行を実装する XML ファイルです。この設定は、Mule Runtime アプリケーションを作成するときにフロー内の要素を活用することによってこれを実現します。Mule Runtime で使用できるすべての要素をカスタムポリシーで使用できます。 ポリシー設定では、ポリシーの実装を実行する実際のプロセスを定義します。Mule アプリケーションのような構造で、コンテンツを次のタグで囲みます。 ```xml ``` 開始 ​``​ タグには、ポリシー内で使用されるすべての Mule XSD ファイルへの参照を含めます。追加できる Mule 要素の中には、対応する XSD 参照も追加する必要があるものもあります。 ``​ 要素のパラメーターにプロパティ ​`id`​ と ​`policyName`​ を追加すると、分析のために API に関するデータを収集できます。 デフォルトでは、カスタムポリシーを作成すると、次のデフォルト設定プロパティにアクセスできます。これらは、設定 XML ファイル内で参照できます。
プロパティ 説明

policyId

現在のポリシーの一意の ID

endpointUri

API のインバウンドエンドポイントの完全な URI

apiId

API の一意の ID 番号

apiVersionId

API バージョンの一意の ID 番号

apiName

API の名前

isRamlEndpoint

エンドポイントが RAML 定義ファイルにリンクされているかどうかを決定するブール値

isWsdlEndpoint

エンドポイントが WSDL 定義ファイルにリンクされているかどうかを決定するブール値

isHttpEndpoint

エンドポイントが HTTP プロトコルに従っているかどうかを決定するブール値
これらのデフォルトプロパティに加えて、新しいプロパティをポリシー定義 YAML ファイルで指定して、それらをポリシー設定 XML ファイルで参照することができます。 ### [](#policy-タグのプロパティ)policy タグのプロパティ policy タグのプロパティは、カスタムポリシー XML 設定の重要な部分です。 - ``​ タグ内の ​`order`​ プロパティ - および 内の ​`order`​ プロパティ これらのプロパティは、ポリシーの実行順序を決定します。 `requiresContracts`​ プロパティは、クライアント検証に不可欠です。 「Custom Policy Properties Reference (カスタムポリシープロパティリファレンス)」には、これらのプロパティに関する詳細が記載されています。 カスタムポリシーの設定 XML では、ポリシー定義のデフォルトのプロパティセットと、ポリシーテンプレート YAML ファイルで定義されたプロパティにアクセスできます。プロパティを参照するには、次のように 2 つの中括弧で囲まれた名前を入力します。 {{propertyName}} このトピックでは、​`order`​ および ​`requiresContracts`​ プロパティについて説明します。 ## [](#policy-タグの-order-プロパティ)policy タグの order プロパティ `order`​ プロパティを使用してポリシーの実行順序を設定できますが、メッセージプロセッサーでのポリシー実行順序の設定が、policy タグでの実行順序の設定よりも優先されます。順序は 2 よりも大きな整数で設定します。順序値 0 ～ 2 はそれぞれ CORS ポリシー、調整ポリシー、レート制限ポリシー用に予約されています。これらのポリシーは他のポリシーより前に実行する必要があります。次の例は、​``​ タグ内での ​`order`​ プロパティの設定方法を示しています。 ```xml ``` ## [](#before-タグまたは-after-タグの-order-プロパティ)before タグまたは after タグの order プロパティ 別の方法として、 タグと タグ内でポリシーの実行順序を設定できます。​`before`​ タグと ​`after`​ タグ内での ​\`order \`​ プロパティの設定は、policy タグ内の他のどの設定よりも優先されます。順序は、2 よりも大きい整数に設定します。次に例を示します。 ```xml ``` ## [](#policy-タグの-requirescontracts)policy タグの requiresContracts 次のバージョンは、設定 XML の policy タグの ​`requiresContracts`​ プロパティをサポートしています。 - Mule ゲートウェイランタイム 2.2.0 以降 - Mule Runtime 3.8 以降 それより前のバージョンでは、Mule ゲートウェイランタイムがデフォルトでクライアントログイン情報をキャッシュするため、このプロパティは必要ありません。 **重要**​: `requiresContracts`​ プロパティの有効化は、クライアント検証に不可欠です。Anypoint Platform がダウンした場合、ポリシーはクライアントの検証を継続できます。検証チェックはメモリ内で行われるため、ネットワーク上で HTTP 要求を使用するチェックよりも本質的にパフォーマンスが高くなります。 クライアント ID を検証するカスタムポリシーは、多くの場合、MuleSoft が提供する、クライアントを認証するポリシー (クライアント ID 適用ポリシーや SLA ベースのポリシーなど) のバリエーションです。 クライアント ID を検証するカスタムポリシーでは、次のスニペット例のように、​`requiresContracts`​ を含めて、このブール値プロパティを true に設定します。 ```xml ... ``` API クライアントの ID と認証ログイン情報は、Mule ゲートウェイランタイムまたは Mule Runtime にダウンロードされ、保存されます。検証はランタイム内で行われるため、検証のためにアウトバウンド HTTP 要求を送信する必要はありません。 デフォルトでは、クライアント情報のダウンロードと取得はバックグラウンドで 15 秒ごとに実行されます。ポーリング頻度は、​`anypoint.platform.poll_clients_freq`​ プロパティを使用して設定できます。このプロパティの設定は、\[CloudHub properties (CloudHub プロパティ)\] タブまたは ​`/conf`​ フォルダー内の ​`wrapper.conf`​ ファイルで行います。 ## [](#ポリシー定義-yaml-ファイル)ポリシー定義 YAML ファイル ポリシー定義ファイルでは、ポリシーの実装時に UI として表示されるポリシーの概要レベルのプロパティ、設定可能プロパティ、表示ラベル、ヒントを定義します。 次の例は、IP 許可リストポリシー定義 YAML ファイルを示しています。 ```yaml id: ip-whitelist name: IP Allowlist description: Limits all service calls to a defined set of IP addresses. category: Security standalone: true requiresConnectivity: false resourceLevelSupported: true providedCharacteristics: - IP filtered requiredCharacteristics: [] configuration: - propertyName: ipExpression name: IP expression description: | Mule Expression for extracting the IP address from this API request. for example, #[message.inboundProperties['http.headers']['X-Forwarded-For']] type: expression defaultValue: optional: true sensitive: false allowMultiple: false - propertyName: ips name: Allowlist description: Limited list of IP addresses allowed API access type: ipaddress optional: false sensitive: false allowMultiple: true ``` 定義する新しいプロパティには、ユーザーがポリシーを適用するときに何を設定するかに基づいて値を指定します。IP 許可リストポリシーの例では、​`ipExpression`​ プロパティと ​`ips`​ プロパティの値が必須です。ポリシー設定 XML ファイルは、これらのプロパティを参照します。ユーザーは、それらに値を割り当てるように求められます。 新しいポリシーに関連するポリシー定義値には次のものがあります。
パラメーター 説明

name (名前)

string (文字列) - ポリシー名。

description (説明)

string (文字列) - ポリシーを適用するときにポリシーの詳細に表示される説明。

category (カテゴリ)

string (文字列) - ポリシーのカテゴリ。

standalone (スタンドアロン)

boolean (ブール値) - ポリシーが単独で機能できる場合は true、別のポリシーの一部としてのみ適用可能な場合は false。

providedCharacteristics

array (配列) - このポリシーを適用することによって満たされる省略可能な特性のリスト。

requiresConnectivity

boolean (ブール値) - レガシー内部パラメーター。この機能は実装されていません。

resourceLevelSupported

boolean (ブール値) - true はユーザーがポリシーを特定の API リソースに適用できることを意味し、false はポリシーがすべての API リソースに適用されることを意味します。(Mule 3.8.1 以降)

requiredCharacteristics

array (配列) - このポリシーを適用できるようにするために満たすべき必須特性のリスト。必須特性は、それらを提供する他のポリシーを適用することによって満たすことができます。これによって、ポリシー間の連動関係が可能になります。任意の文字列入力は特性名として有効ですが、その特性を提供する他のポリシーが 1 つ以上存在する必要があります。大文字と小文字は区別されます。

configuration (設定)

array (配列) - ポリシーに関連付けられた設定可能なプロパティのセット。各プロパティのパラメーターの詳細については後述します。

ramlSnippet

string (文字列) - RAML 0.08 仕様で示されたセキュリティスキーム。

ramlV1Snippet

string (文字列) - RAML 1.0 仕様で示されたセキュリティスキーム。
### [](#providedcharacterics-パラメーター)providedCharacterics パラメーター 通常、​`providedCharacteristics`​ を設定するのは、同時に適用できないポリシー間の競合を避けるためです。たとえば、同時に適用できる OAuth 2.0 ポリシーは 1 つのみです。​`OAuth 2.0 protected`​ を使用して、OAuth 2.0 ポリシーを 1 つのみ指定します。 既存の特性のリストは次のとおりです。 - `Client ID required` - `CORS enabled` - `Baseline Rate Limiting` - `SLA Rate Limiting` - `Requires authentication` - `IP filtered` - `JSON threat protected` - `Security manager` - `OAuth 2.0 protected` - `OAuth 2.0 provider` - `XML threat protected` このリストは無制限です。任意の文字列入力が特性名として有効です。リスト項目では大文字と小文字が区別されます。 ### [](#configuration-パラメーター)configuration パラメーター `configuration`​ パラメーターは、プロパティのセットをリストします。各プロパティには次のパラメーターを含めることができます。
パラメーター 説明

propertyName

string (文字列) - 内部参照用のプロパティ名。

name

string (文字列) - 設定ウィンドウで表示されるプロパティ名。

description

string (文字列) - 設定ウィンドウで表示されるプロパティの説明。

type

string (文字列) - データ型。string (文字列)、boolean (ブール値)、int (整数)、ipaddress、expression (式) (MEL)、keyvalues、rateLimits。type = int の場合、minimumValue と maximumValue を定義します。

optional

boolean (ブール値) - 値の割り当てが省略可能である場合は true。

sensitive

boolean (ブール値) - この項目に含まれる情報が機密情報である場合は true (通常は、パスワードやトークンに使用されます)。サーバーからポリシー情報が要求されると、これらの機密項目は除外されます。

allowMultiple

boolean (ブール値) - 複数の値を割り当てることができる場合は true。

minimumValue

int (整数) - 型が int (整数) で必須の値のみに使用します。

maximumValue

int (整数) - 型が int (整数) で必須の値のみに使用します。

defaultValue

型が int (整数)、boolean (ブール値)、string (文字列)、expression (式) のプロパティにのみ使用します。
#### [](#propertyname-の構文)propertyName の構文 次のスニペットは、次の型の propertyName パラメーターを定義する方法を示しています。 - Integer (整数) - Boolean (ブール) - String (文字列) - Map (マップ) #### [](#integer-整数)Integer (整数) type = int の場合、minimumValue と maximumValue を定義する必要があります。 ```yaml configuration: - propertyName: aint name: Test Int single between 5 and 10 description: Some Description type: int minimumValue: 5 maximumValue: 10 optional: true sensitive: false allowMultiple: false ``` #### [](#boolean-ブール)Boolean (ブール) ```yaml configuration: - propertyName: aboolean name: Test Boolean single description: Some Description type: boolean optional: true sensitive: false allowMultiple: false defaultValue: false ``` #### [](#string-文字列)String (文字列) ```yaml configuration: - propertyName: astring name: Test String single description: Some Description type: string optional: true sensitive: false allowMultiple: false ``` #### [](#map-マップ)Map (マップ) ```yaml configuration: - propertyName: amap name: Test Key/Value Map description: Some Description type: keyvalues optional: true sensitive: false allowMultiple: true ``` #### [](#ramlsnippet-および-ramlv1snippet-パラメーター)ramlSnippet および ramlV1Snippet パラメーター カスタムポリシーの YAML に、​`ramlSnippet`​ パラメーターと ​`ramlV1Snippet`​ パラメーターを含めることができます。カスタムポリシーを Anypoint Platform に追加すると、RAML .80 スニペットまたは RAML 1 スニペットへのリンクが \[Applied policies (適用済みポリシー)\] リストに表示されます。 次のスニペットは、MuleSoft が提供する調整 - SLA ベースのポリシーの YAML ファイルのスニペット内の ​`ramlSnippet`​ パラメーターと ​`ramlV1Snippet`​ パラメーターを示しています。 id: test name: test description: Rosario Central ... configuration: - propertyName: omar name: arnaldo ... - propertyName: rosario name: central ... ramlSnippet: | traits: - client-id-required: queryParameters: client\_id: type: string client\_secret: type: string ... /products: get: is: \[client-id-required\] description: Gets a list of all the inventory products. ramlV1Snippet: | traits: client-id-required: queryParameters: client\_id: type: string client\_secret: type: string ... /products: get: is: \[client-id-required\] description: Gets a list of all the inventory products. ## [](#関連情報)関連情報 - [カスタムポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-custom-policies) - [カスタムポリシーの作成](https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-creating-custom-policy) # 調整およびレート制限 レート制限ポリシーでは、一定期間内に API が受け入れる要求の数を制限します。API は制限を超えた要求を拒否します。ミリ秒から年までの範囲の期間を使用して、複数の制限を設定できます。 調整ポリシーでは、制限を超えた要求を後続の期間に処理できるようにキューに登録します。一定回数の試行後に処理を行えない場合には、API は最終的に要求を拒否します。試行間の遅延と再試行回数の制限を設定できます。 レート制限ポリシーと調整ポリシーでは、すべての要求または一部のリソース (Mule 3.x 以前では API が APIkit ベースである必要があります) に制限を適用します。サービスレベルアクセス (SLA) ベースのレート制限ポリシーと調整ポリシーでは、さらに詳細に要求元アプリケーションに付与されているアクセス権のレベルによって要求を制限します。これらのポリシーには、突然の再起動 (停電) に備えてポリシーの現在の状態を保持する永続性エンジンが含まれています。 レート制限や調整制限の設定方法は、ポリシーが SLA ベースかどうかによって異なります。ポリシーが SLA ベース​_でない_​場合は、ポリシーを適用するときに制限を設定します。 ![期間ごとに許可される最大要求制限](/mulesoft/current/ja-jp/mule-gateway/_images/limits.png) この例では、2 秒 (期間) あたり 10 件の要求 (割り当て) という 1 つの制限を設定しています。 ポリシーが SLA ベースである場合は、Mule Runtime は API のすべてのコントラクトを取得します。コントラクトは、SLA とアプリケーション間の関係を定義します。 クラスターで Mule Runtime を設定する場合、分散アクセス制御用のポリシーを設定できます。 レート制限ポリシーと調整ポリシーは API アクセスを制限するように設定されていますが、その目的は異なります。レート制限は、API へのアクセスにハード制限を適用することによって API を保護します。調整は、トラフィックの急増を緩和することによって API アクセスを形成します。 ## [](#関連情報)関連情報 - [リソースレベルポリシーについて](https://docs.mulesoft.com/gateway/latest/policies-resource-level-overview) - [調整およびレート制限リファレンス](https://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting) - [SLA 層の削除方法](https://docs.mulesoft.com/jp/api-manager/latest/defining-sla-tiers)