クライアント管理用の複数のクライアントプロバイダーの設定
複数のクライアントプロバイダーを使用して、ビジネス組織のセキュリティや規制を適用しやすくすることができます。これらのクライアントプロバイダー (OpenAM や PingFederate など) を使用することで、クライアントのログイン情報やアクセストークンなどの運営データを保護できます。
Anypoint Platform のネイティブクライアントプロバイダーを使用するか (デフォルト)、または外部クライアントプロバイダーを設定できます。組織や環境ごとに異なるクライアントプロバイダーを割り当てるには、組織で実装するクライアントプロバイダーでの OAuth による認証を事前にクライアントアプリケーションで有効化しておく必要があります。
API Manager 2.2.14 では、複数のクライアント ID プロバイダー (IdP) をサポートするようになったため、デフォルトの Anypoint Platform ネイティブクライアント IdP または 1 つ以上の外部クライアント IdP を環境で使用できます。
クライアントプロバイダーは次のように使い分けることができます。
-
本番、QA、Sandbox などの環境ごと
-
内部 API と外部 API
クライアントプロバイダーが内部 API に合わせて設定されている場合でも、Anypoint Platform と通信できるように、公開インターネットからもアクセス可能である必要があります。
複数の外部クライアントプロバイダーを使用する仕組み
外部クライアントプロバイダーを有効にすると、クライアントプロバイダーは、クライアントアプリケーションが 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 の作成と変更は、以前と同じ手順で行えます。作成した環境には、ネイティブ Anypoint Platform クライアントプロバイダーが割り当てられます。既存の API や環境への影響はありません。
-
外部クライアントプロバイダーが設定されている場合
環境で PingFederate などの外部クライアントプロバイダーが設定されている場合は、複数クライアントプロバイダー機能をオンボーディングした時点で、クライアントプロバイダーが自動的に移行されます。ただし、新しい環境を作成したときは、アクセス管理で正しいクライアントプロバイダーを環境に手動で割り当てる必要があります。
ベストプラクティス
API を保護する溜め、環境ごとに 1 つの外部クライアントプロバイダーを作成してください。本番環境には既存のクライアントプロバイダーを割り当て、新しいプロバイダーは QA や他の環境 (Sandbox など) に追加します。ただし、管理 API とそれらのコンシューマーへの潜在的な影響を確認してください。
本番環境と本番以外の環境で同じ IdP を使用しないでください。複数の本番環境や、複数の本番以外の環境では同じ IdP を使用できます。
複数のクライアントプロバイダーを実装する前に、ガイドラインを参照してください。
複数のクライアントプロバイダーを実装するためのガイドライン
Anypoint Platform で複数のクライアントプロバイダーを実装する前に、以下の点を慎重に確認して理解してください。
-
API が次の条件を満たす場合は、クライアントプロバイダーの既存の API インスタンスを変更することはできません。
-
コントラクトを持っている
-
PingFederate ポリシーや OpenID ポリシーなどのプロバイダー関連のポリシーが適用されている (ただし、クライアントプロバイダーの種別が変更されていない場合は例外)
-
API グループに属している
-
-
以前に API の昇格およびインポート時に外部クライアントプロバイダーを環境に割り当てなかった場合、API Manager 2.2.14 以降では、ネイティブプロバイダーがデフォルトで使用されます。
これらの API には、適切な外部クライアントプロバイダーを割り当て直すことができます。
-
以前にネイティブプロバイダーを使用していた環境に外部クライアントプロバイダーを割り当てる場合は、次のようになります。
-
該当の環境の既存の API では、Anypoint Platform のネイティブクライアントプロバイダーが引き続き使用されます。
-
新しい API では、新しい外部 IdP が使用されます。
-
-
デフォルトのネイティブ Anypoint Platform クライアントプロバイダーまたは 1 つ以上の外部クライアントプロバイダーを使用できます。
外部クライアントプロバイダーを API に割り当てた後でも、API が属する環境からすべてのプロバイダーを削除することで、デフォルトのネイティブ Anypoint Platform クライアントプロバイダーを使用するように設定を戻すことができます。
-
環境からクライアントプロバイダーを削除した後も、そのクライアントプロバイダーを使用していたすべての既存 API とクライアントアプリケーションは動作を継続できます。
-
クライアントプロバイダーをルート組織から削除すると、そのクライアントプロバイダーを使用していたすべての既存 API とクライアントアプリケーションは、デフォルトのネイティブ Anypoint Platform クライアントプロバイダーを使用するようになります。
コントラクトはそのまま残りますが、設定が削除されているため、該当するプロバイダーを認証していたポリシーは失敗します。
-
外部クライアントプロバイダーが割り当てられた環境で作成された API は、ネイティブの Anypoint Platform クライアントプロバイダーではなく、常に外部クライアントプロバイダーを使用します。1 つの回避策を次に示します。
-
環境用の外部クライアントプロバイダーを無効にします。
-
Anypoint Platform のネイティブクライアントプロバイダーを使用する API を作成します。
-
外部クライアントプロバイダーを再度有効にします。
-
ロールに基づいて複数のクライアントプロバイダーを実装するためのタスク
ロールと組織のニーズに応じて、下記のタスクを実行して複数のクライアントプロバイダーを実装します。
| タスク | ロール | 実行する場所 | 注意事項 |
|---|---|---|---|
デフォルトを含む複数の IdP を環境に割り当てる。 |
Business Group Administrator (ビジネスグループ管理者) |
アクセス管理 |
複数の IdP を使用することで、API Manager での API 設定で IdP を選択できるようになりますので、複数のチームが同じ環境を使用して API を構築していて、それぞれが別々の IdP を使用したい場合に便利です。また、内部コンシューマーと外部コンシューマー向けに別々の API インスタンスを作成していて、コンシューマー別に異なる IdP が必要なユースケースでも便利です。 |
IdP 設定を変更する前に、API コンシューマーへの中断が発生する可能性に関する通知を受け取る。 |
Business Group Administrator (ビジネスグループ管理者) |
アクセス管理 |
なし |
クライアント管理者ページにおいて、アプリケーションが属するクライアントプロバイダーの確認で、同じ名前の異なるアプリケーションを区別できるようにする。 |
API Manager 管理者 |
アクセス管理 |
なし |
ビジネスグループ管理者によって設定されたデフォルトの IdP に自動的にマップするように API Manager で API を設定する。別の IdP が使用できる場合は、オーナーが変更できるようにする。 |
API オーナー |
API Manager |
なし |
1 つの環境から別の環境に API を昇格またはインポートするときに、対象環境から IdP を指定します。 |
API オーナー |
API Manager |
ターゲット環境で IdP が 1 つ (デフォルト) しか存在しない場合は、自動的に API に割り当てられます。 |
特定の環境に存在する API インスタンスに基づいて API へのアクセスを要求する。 |
アプリケーションユーザー |
Exchange |
アクセスを要求する API を選択する場合は、最初にアクセスを要求する API インスタンスを選択する必要があります。API インスタンスは、環境に基づいて絞り込まれます。 |
複数のクライアントプロバイダーを設定するためのユーザーフロー
Good Weather のユースケースに戻りましょう。同社は、以下のフローを使用して組織で複数の外部クライアントプロバイダーを実装しています。
図に示されているように、最初に外部クライアントプロバイダーを設定してから、適切な環境に割り当てます。特定の環境内で API を作成または修正すると、新しいクライアントプロバイダーが表示されます。適切なクライアントプロバイダーを選択し直すことができます。
1 つの環境から別の環境に API を昇格するときに、次のいずれかを行うことでポリシーの不一致を防止します。
-
両方の環境で同じプロバイダー種別 (PingFederate や OpenAm など) を使用する。
-
昇格した API に適用されているプロバイダー関連のポリシーをすべて削除する。
API コンシューマーは、特定の環境の API インスタンスに基づいて API へのアクセスを要求できます。
複数のクライアントプロバイダーを設定する
複数の外部クライアントプロバイダーを設定する手順は次のとおりです。
-
[Access Management (アクセス管理)] で、最初にクライアント管理を有効化します。
クライアントプロバイダーを組織で実装するためには、Anypoint 管理者として事前に OAuth によるクライアントアプリケーションの認証を有効化する必要があります。
-
[Access Management (アクセス管理)] で環境にクライアントプロバイダーを割り当てます。
Anypoint 管理者として、クライアントプロバイダーを設定して特定の環境に割り当てます。
-
API Manager で、新しい IdP を使用して API を作成または修正します。
API オーナーとして、API を作成するか、Anypoint Exchange から API をインポートするか、または API Manager で API を修正します。必要に応じて、API を 1 つの環境から別の環境に昇格するか、もしくは前述のように API をインポートまたはエクスポートします。
-
API Manager でポリシーを設定します。
API Manager 管理者として、関連付けられているクライアントプロバイダーに基づいて API にポリシーを適用できます。
-
Exchange で、ビジネス組織の特定の環境内で API インスタンスへのアクセスを要求します。
API コンシューマーとして、登録されているクライアントアプリケーションから非公開 Exchange または公開ポータルを使用して、API インスタンスへのアクセスを要求できます。