Корректная конфигурация аутентификации открытого идентификатора за WAF на основе пути - PullRequest
Новая
       44

Корректная конфигурация аутентификации открытого идентификатора за WAF на основе пути

0 голосов
/ 29 октября 2019

У меня проблема с настройкой приложения Open Auth ID .net Core 2 в качестве службы приложений за брандмауэром веб-приложений с использованием маршрутизации на основе пути.

Моим приложением является myapp.azurewebsites.net с сетевым ограничением, которое делает его недоступным из общедоступного Интернета. Я развернул WAF в той же VNET и разрешил трафик между WAF и службой приложений, используя маршрут на основе пути "/ Admin *".

Эффект состоит в том, что https://myapp.azurewebsites.net не доступен через Интернет, но https://myWAF/Admin доступен и сопоставляется со службой приложения.

Эта установка работает нормально, но когда яввести аутентификацию Open ID в мое основное приложение .net, исходящий заголовок Location включает свой myapp.azurewebsites.net/signin-oidc в качестве URI ответа.

Это не работает, потому что хост не доступен из Интернета. Я предпринял несколько попыток:

  • Я добавил URL WAF (https://myWAF/Admin/signin-oidc) в URL регистрации приложения в Azure App Registrations, чтобы позволить AAD принять измененный URL (как законный * 1018). *
  • Я запрограммировал app.UseForwardedHeaders (принудительное повторное использование всех заголовков X-Forwarded) в моем файле startup.cs, который не оказывает никакого влияния на заголовок Location, отправляемый моей службой приложений. Я предполагаю, что WAFотправляет заголовки X-Forwarded, но если это так, стек Open Auth ID их не использует.
  • Я кодировал перезапись заголовка в WAF, чтобы заменить myapp.azurewebsites.net URL-адресом WAFЭто правильно заменяет URL-адрес и разрешает обратный вызов, но затем завершается с ошибкой корреляции (которая, похоже, является общей ошибкой стека Open ID, означающей «одноразовый номер не совпадает». Возможно, что одноразовый номер основан на URL-адресе, являющемсяперезвонил - который в моем случае меняется из-за перенаправления WAF, но это предположение).

Мне кажется, чтоЯ должен иметь возможность использовать заголовки X-Forwarded в моем приложении, чтобы обойти необходимость кодирования перезаписей заголовков в WAF, но я не могу найти пример, где это успешно используется для изменения URI ответаотправлено с помощью Open ID.

Мой вопрос;Является ли использование заголовка X-Forwarded правильным подходом к обработке прокси в контексте OAuth, или перезапись заголовка в WAF является правильным подходом?

Я установил

1 Ответ

0 голосов
/ 30 октября 2019

После долгих исследований я обнаружил следующее:

  1. WAF не отправляет стандартный X-Forwarded-Host в службы приложений, а вместо этого отправляет X-Original-Host. Документировано здесь https://feedback.azure.com/forums/217313-networking/suggestions/33657763-add-the-x-forwarded-host-header-to-application-gat

  2. ForwardedHeaderOptions, которые ASP.net Core 2 использует в своем промежуточном программном обеспечении ForwardedHeaders, имеют возможность заменить ожидаемый и поддерживаемый «X-Forwarded-Host» на произвольное имя заголовка другого хоста,Это поведение может быть вызвано следующим образом, чтобы заменить использование x-Forwarded-Host на определенный WAF X-Original-Host.

    options.ForwardedHostHeaderName = "X-ORIGINAL-HOST";

  3. WAF не передает путь маршрута на основе пути вниз по стеку заголовка Http, как ожидается в заголовке PathBase. Это должно быть добавлено в заголовки запроса либо в WAF с помощью перезаписи заголовка, либо внутри приложения следующим образом (в данном случае путь к приложениям - / Admin);

    app.Use ((context, next) => {context.Request.PathBase = new PathString ("/ Admin"); вернуть next ();});

...