クライアント管理用の複数のクライアントプロバイダーの設定

外部クライアントプロバイダーを有効にすると、クライアントプロバイダーは、クライアントアプリケーションが API にアクセスできるようにするトークンを発行する認証サーバーとして機能します。クライアントアプリケーションへのアクセスを要求すると、対応するクライアント ID とクライアントシークレットが API 仕様で指定されている IdP で作成されます。

API がクライアント ID 適用ポリシーを適用し、OAuth ポリシーを適用しない場合でも、クライアントアプリケーションは外部クライアントプロバイダーで作成されます。

OAuth ポリシーが API ゲートウェイにデプロイされると、プラットフォームは IdP 設定 (トークン URL やトークンイントロスペクション URL など) を自動的にポリシーに挿入します。

外部 IdP が 1 つも有効化されていない場合は、Access Manager がデフォルトの認証サーバーとして機能します。

複数の外部クライアントプロバイダーの実装方法についての理解を深めるために、「Good Weather」という名前の気象予報会社の例を考えてみましょう。Good Weather は、特定の場所の大気の現在の状態に関する定量的なデータを収集し、気象学を使用して、その現在の状態が経時的にどのように変化するかを予測します。

Good Weather では、ルート組織の下でいくつかのサブ組織が稼動しています。これらのサブ組織は、実行する機能 (エンジニアリングや予報など) によって分かれています。予報部門は、さまざまなソースから最新の気象データを調査して収集します。このデータは、さまざまなクライアントアプリケーションでコンシュームされます。気象予報データをホストするアプリケーションはエンジニアリング部門が管理しています。

Good Weather では、気象予報データの正確さとセキュリティを保証する必要があるため、気象予報関連の API は予報部門の従業員のみがアクセスできるようになっています。また Good Weather では、本番用 API が常に唯一の信頼できる情報源であることを保証したいと考えています。

セキュリティを確保して、組織、環境、API ごとのアクセス分離を保証するため、Good Weather の IT チームは、予報部門に対して外部クライアントプロバイダーを設定します。

複数のクライアントプロバイダーをオンボーディングするための手順は、クライアントプロバイダーと社内のビジネス組織がどのように設定されているかによって異なります。

ベストプラクティス

API を保護する溜め、環境ごとに 1 つの外部クライアントプロバイダーを作成してください。本番環境には既存のクライアントプロバイダーを割り当て、新しいプロバイダーは QA や他の環境 (Sandbox など) に追加します。ただし、管理 API とそれらのコンシューマーへの潜在的な影響を確認してください。

本番環境と本番以外の環境で同じ IdP を使用しないでください。複数の本番環境や、複数の本番以外の環境では同じ IdP を使用できます。

複数のクライアントプロバイダーを設定する場合、ネイティブ Anypoint Platform クライアントプロバイダーと外部クライアントプロバイダーの両方を同じ環境で使用できます。

複数のクライアントプロバイダーを実装する前に、​ガイドライン​を参照してください。

Anypoint Platform で複数のクライアントプロバイダーを実装する前に、以下の点を慎重に確認して理解してください。

ロールと組織のニーズに応じて、下記のタスクを実行して複数のクライアントプロバイダーを実装します。

Good Weather のユースケースに戻りましょう。同社は、以下のフローを使用して組織で複数の外部クライアントプロバイダーを実装しています。

図に示されているように、最初に外部クライアントプロバイダーを設定してから、適切な環境に割り当てます。特定の環境内で API を作成または修正すると、新しいクライアントプロバイダーが表示されます。適切なクライアントプロバイダーを選択し直すことができます。

1 つの環境から別の環境に API を昇格するときに、次のいずれかを行うことでポリシーの不一致を防止します。

API コンシューマーは、特定の環境の API インスタンスに基づいて API へのアクセスを要求できます。

複数の外部クライアントプロバイダーを設定する手順は次のとおりです。