IAP (アイデンティティー認識型プロキシー) とは、一般的にリバース プロキシーとして、またはリバース プロキシーと負荷分散機能を組み合わせたソフトウェアの一部として動作するソフトウェアのことです。 この概念が標準的なアーキテクチャー コンポーネントと異なる点は、バックエンド システムや外部認証パターンのみに依存するのではなく、IAP が受信リクエストの認証において役割を担っていることです。
このトピックの内容は、ほぼ ArcGIS Enterprise にのみ該当するものです。ほとんどの ArcGIS Online ワークフローはアイデンティティー認識型プロキシーと直接やり取りすることはありませんが、ArcGIS Online にアイテムとして追加された外部サービスや URL は、この方法で保護できます。
リバース プロキシーまたはロード バランサーが使用されるほとんどのデプロイメントでは、コンポーネントは主に透過モードで動作します。つまり、クライアントからのリクエストはプロキシーによって大幅に編集または変更されるのではなく、バックエンド システムに直接転送されます。リクエストがこのプロキシーを介して行われたことをバックエンド システムに知らせるためのリクエスト ヘッダーが追加されることがあります。 これらのアーキテクチャーでは、リバース プロキシーまたはロード バランサーを通過するユーザーの ArcGIS システムへの認証は、この中間レイヤーなしでソフトウェアに直接アクセスするユーザーと機能的に同じです。
IAP を使用する場合、リバース プロキシーはまず、トークン、API キー、サイト固有の Cookie などの認証情報またはオブジェクトを探してユーザーが認証されているかどうかを確認します。認証情報またはオブジェクトが存在しないか無効な場合、バックエンド システムへのリクエストは、IAP 構成に基づいてすぐに認証プロバイダーまたはプロセスにリダイレクトされます。 ユーザーがそのアイデンティティー プロバイダーを通じて適切に認証され、有効なセキュリティー トークンまたは資格情報とともに IAP インターフェイスに戻された後にのみ、リクエストはバックエンド システムに転送されます。 重要なのは、このセキュリティー識別子はバックエンド システムの外部で保持されることです。つまり、バックエンド システムは通常、ユーザーの IAP ネゴシエーション セッションを認識しません。 ArcGIS Enterprise が IAP の背後に配置されているシナリオでは、IAP が開始した最初のログイン後、ユーザーは ArcGIS とのセッションを確立するために ArcGIS で指定された IdP に再認証する必要があることに注意が必要です。
アイデンティティー認識型プロキシーの概念に含まれる機能をサポートするように、さまざまなソフトウェア コンポーネントとシステムを構成できますが、一般的な例には次のようなものがあります。
リスナー ルール実際には、「事前認証」レイヤーを提供するリバース プロキシーや、トークン、Cookie、またはその他の認証情報を通過させる必要があるリバース プロキシーは、ArcGIS アーキテクチャーの議論の目的上、アイデンティティー認識型プロキシーと見なすことができます。 IAP の中には、構成の自由度が高いものや低いもの、特定の URL の除外を許可するもの、単純なフォームベースのログインから OpenID Connect や SAML ベースのログイン オプションまでさまざまな認証方法を提供するものがあります。
IAP は、ユーザーが主に Web ブラウザーを介して Web アプリケーションにアクセスし、バックエンド API へのリクエストがアプリケーションと同じドメインにある、カスタムの公開 Web アプリケーションやエンドポイントを保護するためによく使用されます。ユーザーは最初のログインを再利用して、さらにリクエストを行うことができます。 一部のバックエンド API は、IAP を通過するヘッダーやその他のリクエスト プロパティー (ユーザーのユーザー名を示す署名など) を使用するよう策定されており、その情報を使用して API のレスポンス コンテンツやロジックに影響を与えることがあります。
ほとんどの ArcGIS クライアント アプリケーション (Web、デスクトップ、モバイルベース) では、OAuth を使用して ArcGIS への認証を開始します。 このプロセスには、クライアント アプリの ArcGIS への登録、ログイン セッションの開始、有効な認証情報の提供、応答コードを使用したトークンの生成が含まれ、これらの各クライアント タイプで一貫しています。 この OAuth ログイン プロセスには、いくつかの異なる Web ページまたは HTTP リクエストが含まれ、通常は組み込みブラウザー内 (ネイティブ アプリの場合) または同じブラウザー ウィンドウ (Web アプリの場合) で発生します。
ArcGIS OAuth プロセス、特に結果として得られる ArcGIS アクセス トークンのアプリ内使用は、クライアントがバックエンド システムへの透過的なアクセス権を持っていることを前提としています。 別の言い方をすれば、ArcGIS クライアントは ArcGIS システムへの認証方法のみを理解しています。ブラウザーの OAuth プロセスには、ユーザーを SAML または OIDC アイデンティティー プロバイダーに送信することが含まれる場合がありますが、最終的には生成された OAuth コードがユーザーに返され、ネイティブ アプリの追加のブラウザー ウィンドウが閉じられます。 OAuth ログインが完了すると、クライアントは透過的な HTTP リクエスト (ArcGIS トークンを含む) を ArcGIS Online または ArcGIS Enterprise エンドポイントに送信してさらに使用できると想定しており、IDP によって設定された認証情報やセッションは使用されなくなったり、ArcGIS に関連しなくなったりします。 IAP のシナリオでは、IAP は、各受信リクエスターが以前に IAP に対して認証されているかどうかを常にチェックしているため、いくつかの一般的な問題が発生する可能性があります。
ArcGIS OAuth ログイン プロセスには、通常、OAuth プロセスの開始方法をガイドする 2 つの構成済みプロパティー (client_id と portal_url) があります。
https://www.arcgis.com または組織固有のサブドメイン (https://myorg.maps.arcgis.com など) です。/portal) を含む https://gis.mydomain.org/portal のようなものです。ArcGIS クライアント アプリケーションの動作でこのプロセスにアプローチするには、まず (portal_url) + ‘/sharing/rest/info?f=json’’ のようなリクエストを送信して、構成された URL が有効な ArcGIS Enterprise または ArcGIS Online システムであるかどうかを確認します。
このリクエストは、システムがそのクライアント アプリケーションでサポートされているバージョンであることを確認するために、使用されている API バージョンを識別する短い JSON レスポンスを返します。
ArcGIS アプリケーションがユーザーに ArcGIS Enterprise の URL を入力して接続するように求めると、ArcGIS クライアントから /sharing/rest/info?f=json への最初のリクエストでは、多くの場合、ユーザーを IAP ログイン ページにリダイレクトする 302 HTTP 応答が返されます。
これにより、ArcGIS クライアント アプリケーションはエンドポイントを有効なものとして受け入れません。エンドポイント自体が ArcGIS デプロイメントとしてではなく、HTML ログイン ページとして表されるからです。 そうすると、クライアント アプリケーションは悪意のある Web サイトが ArcGIS Enterprise デプロイメントを模倣するのを防ごうとしているため、拒否されます。たとえば、ドッペルゲンガー ドメインを使用して情報を要求したり、ユーザーに認証情報の入力を求めて、認証情報を盗んで悪用するようなケースです。
ArcGIS Pro や ArcGIS モバイル アプリなどのネイティブ アプリの場合、OAuth ログインは埋め込みブラウザーを介して完了します。そのブラウザーで IAP セッションが正常に確立される場合もありますが、ブラウザーを閉じると、通常設定されている (ユーザーがすでに IAP に認証されていると識別するための) Cookie が失われるため、ネイティブ アプリケーションから直接開始された ArcGIS への後続のリクエストは、新たな 302 応答でブロックされます。
いくつかのワークフローは、慎重に設計すれば IAP 機能とうまく組み合わせることができます。
アイデンティティー認識型プロキシーは、アプリケーション保護の比較的一般的なクラスとして広く普及していますが、現在、その実装には標準化や一貫性がほとんどないため、IAP に類似する広範なシステムのサポートを確実に実装することは困難です。 Esri は、ネイティブ アプリケーションからのより多くの IAP ベースのワークフローに対する今後のサポートについて調査しています。将来的には、さまざまなソフトウェア配布に適用できる、一般的に実装可能な標準ベースの方法でサポートを提供することを目指しています。