Как защитить мое Azure WebApp с помощью встроенного механизма аутентификации - PullRequest
0 голосов
/ 06 июля 2018

Я создал Flask-Webservice с Python, который работает независимо внутри док-контейнера.Затем я загрузил образ докера в реестр контейнеров Azure.Оттуда я могу создать WebService (для контейнеров) несколькими щелчками мыши на портале Azure, который запускает этот контейнер.Все идет нормально.Он ведет себя так, как я хочу.

Но, конечно, я не хочу, чтобы кто-нибудь получал доступ к сервису.Поэтому мне нужна какая-то аутентификация.К счастью (или я так подумал), есть встроенный механизм аутентификации (я думаю, что он основан на OAuth ... Я не очень хорошо разбираюсь в вопросах безопасности).Его документация немного редка о том, что на самом деле происходит, и также концентрируется на решениях в C #.

Сначала я создал проект с Google, как описано здесь , а затем настроилWebApp-аутентификация с использованием Client-Id и Secret.Я, конечно, дал Google источник java-сценария и callback-url, а также.

Когда я сейчас выхожу из своей учетной записи Google и пытаюсь выполнить GET-запрос к моему веб-сервису в браузере (GET должен просто вернуть "hello world "-String), меня приветствует экран входа в систему ... как я и ожидал.

Когда я снова захожу в Google, меня перенаправляют на URL-адрес обратного вызова в браузере с каким-то видоминформации в параметрах.

токен что ли?Это выглядит примерно так:

https://myapp.azurewebsites.net/.auth/login/google/callback?state=redirxxx&code=xxx&authuser=xxx&session_state=xxx&prompt=xxx).

Здесь что-то идет не так, потому что появляется ошибка.

Произошла ошибка.

Извините, страница, которую вы ищете, в данный момент недоступна.Повторите попытку позже.

Если вы являетесь системным администратором этого ресурса, вам следует проверить подробности в журнале ошибок.

С уважением, nginx.

Насколько я знаю, nginx - это серверное программное обеспечение, на котором размещен мой код.Я могу представить, что он также должен обрабатывать процесс аутентификации.Очевидно, он пропускает все запросы к моему коду, когда аутентификация отключена, но блокирует неаутентифицированный доступ в противном случае и перенаправляет на страницу входа в Google.Затем Google проверяет, авторизована ли ваша учетная запись для приложения, и перенаправляет вас на обратный вызов с токеном доступа вместе с ним.Затем он возвращает cookie, который должен предоставить моему браузеру доступ к приложению.(Я просто воспроизвожу здесь документацию).

Итак, мой вопрос: что идет не так.Мой браузер не принимает куки.Неужели я что-то не так при настройке Google+ или аутентификации в WebApp.Нужно ли использовать определенный стек разработки, чтобы использовать аутентификацию.Разве он не поддерживается ни для одной из технологий, которые я использую (Python, Flask ...).

EDIT

@ miknik:

В документации Microsoft по аутентификации / авторизациитам написано

Модуль аутентификации и авторизации работает в той же песочнице, что и код вашего приложения.Когда он включен, каждый входящий HTTP-запрос проходит через него, а затем обрабатывается кодом приложения.

...

Модуль запускается отдельно от кода приложения и настраивается с использованием параметров приложения.Никаких SDK, определенных языков или изменений в коде вашего приложения не требуется.

Так что, хотя вы, вероятно, правы, информация в callback-redirect является разрешением / кодом авторизации, а затем этим кодомтеперь нужно использовать для получения токена доступа от Google, я не совсем понимаю, как это будет работать в моей ситуации.

Насколько я понимаю, Microsofts WebApp для Container-Resource на Azure должен позаботитьсяавтоматического получения токена и возврата его как части ответа на запрос обратного вызова.В документации указано 4 шага:

  1. Вход пользователя: перенаправляет клиента на /.auth/login/.
  2. Пост-аутентификация: поставщик перенаправляет клиента на /.auth/login//callback.
  3. Установить аутентифицированный сеанс: служба приложений добавляет аутентифицированный cookie-файл в ответ.
  4. Обслуживание аутентифицированного контента: клиент включает cookie аутентификации в последующие запросы (автоматически обрабатываются браузером).

Мне кажется, что шаг 2 завершился неудачно, и это было бы именно то, что вы написали: что разрешение на использование сервера должно использоваться сервером для получения токена доступа, но это не так.

Но я также не имею никакого контроля над этим. Возможно, кто-то может прояснить ситуацию, исправив меня в некоторых других вещах:

Во-первых, я не могу понять, какие части моей проблемы представляют какую роль в OAuth-схеме.

  • Я думаю, что я Владелец , и, добавляя пользователей в список в Google + -Проекте, я разрешаю им использовать мой сервис.
  • Google, очевидно, сервер авторизации
  • мой WebService (или, еще лучше, мой WebApp для контейнеров) - это сервер ресурсов
  • и, наконец, приложение или почтальон, который делает запросы, это Клиент

В описаниях OAuth я прочитал, что проблемный шаг сводится к следующему: сервер ресурсов получает токен доступа от сервера авторизации и передает его клиенту . А ресурс Azures WebApps запрашивается (и включается), чтобы вызываться с помощью callback-url. Я прав где-то в этом?

Увы, я согласен, что не совсем понимаю весь протокол. Но я считаю, что большинство описаний в сети менее чем полезно, поскольку они не относятся к Azure. Если кто-то знает хорошее объяснение, общее или специфичное для Azure, оставьте комментарий.

1 Ответ

0 голосов
/ 12 июля 2018

Я нашел способ заставить это работать, и я стараюсь объяснить, что пошло не так, как можно лучше. Пожалуйста, поправьте меня, если я ошибаюсь или использую неправильные слова.

Как я и подозревал, проблема была не столько в том, что я не понимал OAuth (или, по крайней мере, как Azure управляет им), но во внутренней работе службы веб-приложений Azure (плюс некоторые плохие программы с моей стороны). Azure работает на собственном сервере и не использует встроенный сервер фляги. Фактическая проблема заключалась в том, что моя программа-фляга не реализовала интерфейс WSGI. Как я понял, это еще один стандарт для сценариев Python для взаимодействия с любым сервером. Поэтому, хотя элементарные вызовы с сервера (я думаю, что Azure использует nginx) были возможны, более сложные вызовы, такие как перенаправление на URL обратного вызова, перешли на dev / null.

Я создаю новое приложение, следуя этому учебнику , а затем защищаю его, следуя аутентификации / авторизации-учебнику , и все работает нормально. Код в руководстве реализует WSGI и, вероятно, в большей степени соответствует ожиданиям Azure. Мое решение для докера было слишком простым.

Мой вывод: прочитайте этот WSGI-стандарт, о котором мне всегда предупреждает фляжка, и я не слушал и не реализовывал его в любом коде, который выходит за рамки возможностей при разработке.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...