1. Homepage
  2. Mule ゲートウェイ
  3. Mule 3 のポリシー
  4. 内部ポリシー

  5. クライアント ID 適用

クライアント 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 コードが含まれています。

raml snippet

クライアント ID 適用ポリシー

アプリケーションを API Portal に登録するときに、クライアントアプリケーション開発者は、ポリシーを適用するときに設定されたログイン情報 (クライアント ID とクライアントシークレット) を取得します。

クライアント ID 適用ポリシーは、ログイン情報の要件を適用します。レート制限 - SLA ベースのポリシーと調整 - SLA ベースのポリシーは、クライアント ID を参照として使用して、各アプリケーションが一定期間内に実行できる要求の数を制限します。

クライアント ID ベースのポリシーに関する全般情報

このセクションの情報は、すべてのクライアント ID ベースのポリシーに適用されます。

アプリケーションが、クライアント ID ベースのポリシーを適用する API をコールすると、API Manager では、アプリケーションからクエリパラメーターとして client_id と client_secret が渡されることが想定されます。デフォルトでは、クエリパラメーターは、このトピックの「API コールの必須項目」セクションで説明する形式 (クライアント ID とクライアントシークレットの式) になっています。または、client_secret 式を削除し、クライアント ID 制限ポリシーを適用するときに表示されるダイアログに client_id のみを指定できます。その場合、クライアント ID のみが必須になります。

[HTTP Basic Authorization Header (HTTP 基本承認ヘッダー)] を選択して、ログイン情報元として基本認証を使用することもできます。

clientidDefault

アプリケーションの登録

ユーザーは、クライアント ID ベースのポリシーを適用する API に対するすべての要求で、ID に加えてトークンを送信する必要があります。ID とトークンを取得するために、クライアントアプリケーション開発者は、API のポータルで API アクセス要求コントロールを使用して API アクセスを要求します。

ユーザーが [Request API Access (API アクセスの要求)] をクリックすると、既存のアプリケーションを選択するか、新しいアプリケーションを作成するように求められます。API アクセスの要求は、自動的に承認されるか、クライアント ID および SLA ベースのポリシーの場合は、API のシステム管理者の承認が必要です。

アプリケーションからの API アクセス要求の承認は、API ダッシュボードで行います。

API コールの必須項目

通常、アプリケーションは、ポリシー設定に応じて次のいずれかの方法でログイン情報を提供する必要があります。

  • HTTP 要求のヘッダー内

  • URL 内でクエリパラメーターとして

たとえば、クライアント ID ベースのポリシーを適用する API にアプリケーションから HTTP ヘッダー内で client_id と client_secret を渡すには、次の Mule 3.x 式を使用します。

#[message.inboundProperties['client_id']]
#[message.inboundProperties['client_secret']]

たとえば、クライアント ID ベースのポリシーを適用するために、クエリパラメーター内で client_id と client_secret を渡すには、次の Mule 4.x 式を使用します。

関連情報