Azure Active Directory アプリケーション プロキシの CORS の問題を理解して解決する

  • [アーティクル]

クロス オリジン リソース共有 (CORS) が原因で、Azure Active Directory アプリケーション プロキシ経由で公開するアプリや API で問題が発生することがあります。 この記事では、Azure AD アプリケーション プロキシでの CORS の問題と解決策について説明します。

通常、ブラウザーのセキュリティ機能により、Web ページでは AJAX 要求を別のドメインに送信することはできません。 この制限は、同一オリジン ポリシーと呼ばれ、悪意のあるサイトが、別のサイトから機密データを読み取れないようにします。 ただし、他のサイトから Web API を呼び出したほうが良い場合もあります。 W3C 標準である CORS によって、サーバーは同一オリジン ポリシーを緩和したり、一部のクロスオリジン要求を許可して他の要求は拒否したりできます。

CORS の問題の理解と識別

次のように、2 つの URL のスキーム、ホスト、ポートが同一である (RFC 6454) 場合、2 つの URL のオリジンは同じです。

  • http://contoso.com/foo.html
  • http://contoso.com/bar.html

以下の URL は、前の 2 つとはオリジンが異なります。

  • http://contoso.net - 異なるドメイン
  • http://contoso.com:9000/foo.html - 異なるポート
  • https://contoso.com/foo.html - 異なるスキーム
  • http://www.contoso.com/foo.html - 異なるサブドメイン

同一オリジン ポリシーは、正しいアクセス制御ヘッダーを使用する場合を除き、他のオリジンからのリソースにアプリがアクセスするのを防ぎます。 CORS ヘッダーが存在しないか正しくない場合、クロス オリジン要求は失敗します。

CORS の問題はブラウザーのデバッグ ツールを使用して識別できます。

  1. ブラウザーを起動して Web アプリをブラウズします。
  2. F12 キーを押してデバッグ コンソールを起動します。
  3. トランザクションを再現し、コンソール メッセージを確認します。 CORS 違反があると、オリジンに関するコンソール エラーが発生します。

次のスクリーンショットでは、[Try It](テスト) ボタンを選択すると、https://corswebclient-contoso.msappproxy.net が Access-Control-Allow-Origin ヘッダーに見つからなかったという CORS エラー メッセージが表示されました。

CORS の問題

アプリケーション プロキシでの CORS の課題

次の例は、Azure AD アプリケーション プロキシの CORS の一般的なシナリオを示しています。 内部サーバーは、CORSWebService Web API コントローラーと、CORSWebService を呼び出す CORSWebClient をホストします。 CORSWebClient から CORSWebService への AJAX 要求があります。

オンプレミスの同一オリジン要求

CORSWebClient アプリは、オンプレミスでホストしたときは動作しますが、Azure AD アプリケーション プロキシ経由で公開すると、読み込みに失敗するかエラーで終了します。 アプリケーション プロキシ経由で、異なるアプリとして CORSWebClient アプリと CORSWebService アプリを別々に公開した場合、2 つのアプリは異なるドメインでホストされます。 CORSWebClient から CORSWebService への AJAX 要求はクロス オリジン要求であり、失敗します。

アプリケーション プロキシの CORS 要求

アプリケーション プロキシの CORS の問題に対する解決策

上記の CORS の問題は、複数ある方法のいずれかで解決できます。

オプション 1: カスタム ドメインの設定

アプリのオリジン、コード、またはヘッダーを変更する必要なしに、同じオリジンから公開するには、Azure AD アプリケーション プロキシのカスタム ドメインを使用します。

オプション 2:親ディレクトリを公開する

両方のアプリの親ディレクトリを公開します。 この解決策は、Web サーバー上にアプリが 2 つしかない場合は特に有効です。 各アプリを別々に公開する代わりに、共通の親ディレクトリを公開してオリジンを同じにすることができます。

次の例は、CORSWebClient アプリのポータルである Azure AD アプリケーション プロキシのページを示しています。 [内部 URL] が contoso.com/CORSWebClient に設定されている場合、アプリから contoso.com/CORSWebService ディレクトリに対しては、これらがクロス オリジンであるため、正常に要求を実行できません。

アプリの個別公開

代わりに、CORSWebClient ディレクトリと CORSWebService ディレクトリの両方を含む親ディレクトリを公開するように [内部 URL] を設定します。

親ディレクトリの公開

結果として得られるアプリの URL は、CORS の問題を効果的に解決します。

  • https://corswebclient-contoso.msappproxy.net/CORSWebService
  • https://corswebclient-contoso.msappproxy.net/CORSWebClient

オプション 3:HTTP ヘッダーを更新する

オリジン要求に一致するように、Web サービス上でカスタム HTTP 応答ヘッダーを追加します。 インターネット インフォメーション サービス (IIS) で実行されている Web サイトの場合、IIS マネージャーを使用してヘッダーを変更します。

IIS マネージャーでのカスタム応答ヘッダーの追加

この変更には、コードの変更は一切必要ありません。 Fiddler のトレースで確認できます。

**Post the Header Addition**\
HTTP/1.1 200 OK\
Cache-Control: no-cache\
Pragma: no-cache\
Content-Type: text/plain; charset=utf-8\
Expires: -1\
Vary: Accept-Encoding\
Server: Microsoft-IIS/8.5 Microsoft-HTTPAPI/2.0\
**Access-Control-Allow-Origin: https\://corswebclient-contoso.msappproxy.net**\
X-AspNet-Version: 4.0.30319\
X-Powered-By: ASP.NET\
Content-Length: 17

オプション 4:アプリを変更する

適切な値と共に Access-Control-Allow-Origin ヘッダーを追加することによって、CORS をサポートするようにアプリを変更することができます。 ヘッダーを追加する方法は、アプリのコードの言語によって異なります。 最も多くの作業量が必要なため、コードの変更は最もお勧めしない選択肢です。

オプション 5:アクセス トークンの有効期間を延長する

アプリが認証のために login.microsoftonline.com にリダイレクトし、アクセス トークンの期限が切れた場合など、一部の CORS の問題は解決できません。 このとき、CORS の呼び出しは失敗します。 このシナリオの回避策は、ユーザーのセッション中に期限が切れるのを防ぐために、アクセス トークンの有効期間を延長することです。 このための手順については、Azure AD の構成可能なトークン有効期間に関する記事を参照してください。

関連項目