Подписание запросов API к службам приложений Azure с помощью токена доступа MSI - PullRequest
Новая
       35

Подписание запросов API к службам приложений Azure с помощью токена доступа MSI

0 голосов
/ 05 июня 2018

У меня есть веб-приложение, работающее в службах приложений Azure.Внешний интерфейс (javascript + html + css) связывается с внутренним интерфейсом (Flask).Оба работают на одном и том же экземпляре службы приложения.

Мое приложение защищено проверкой подлинности Active Directory (настроенной с использованием портала Azure).

Проверка подлинности пользователя в приложении работает отлично.Когда пользователь переходит к приложению, он перенаправляется на логин нашего клиента Azure AD.Когда они пытаются войти в систему, их разрешение на приложение контролируется их членством в группе Azure AD. Этот бит работает, как и ожидалось

Сложность заключается в том, что клиентскому интерфейсу необходимо отправлять аутентифицированные запросы, чтобы они действительно достигли внутреннего сервера.Они должны быть аутентифицированы с использованием токена участника службы, а не токена пользователя.И для этого мы используем новый, рекомендуемый подход;Управляемый идентификатор службы (MSI), а не рабочий процесс учетной записи субъекта-службы напрямую.

Существует два этапа:

1) Добавление заголовка авторизации 2) Обеспечение доступа субъекту MSI (т.е. принадлежит к группе AD)

1) Сервер генерирует токен доступа, используя следующий код: 

credentials = azure_active_directory.MSIAuthentication()
session = credentials.signed_session()
return session.headers.get("Authorization")

Затем мы добавляем заголовок {"Authorization": "Bearer"}, гдеявляется результатом вышеуказанного кода.

Кажется, это работает как ожидалось - мы видим длинные алфавитно-цифровые маркеры доступа

2) Хитрыйнемного было гарантировать, что MSI был добавлен в группу AD.Графические интерфейсы на myapps.microsoft.com и mygroups.microsoft.com позволяют добавлять только пользователей.Вместо этого я использовал интерфейс командной строки Azure и выполнил следующее:

a) Получить идентификатор участника MSI msiobjectid=$(az webapp identity show --resource-group <resource-group-name> --name <azure app services name> --query principalId)

b) Добавить участника в группу az ad group member add --group <group name> --member-id $msiobjectid

Мы все еще получаем 401 Unauthorized, и мы исчерпали всю документацию: (

Следует отметить, что я только выполнил шаг 2 (добавление принципала в группу Azure AD через AzureCLI) около часа назад. Возможно, есть задержка?

Редактировать: мой сценарий наиболее близок к https://github.com/uglide/azure-content/blob/master/articles/app-service-api/app-service-api-dotnet-service-principal-auth.md, за исключением: а) Я использую MSI, а не принципала прямого обслуживания, и б) яиметь дополнительный уровень авторизации, то есть группы объявлений, ограничивающие доступ к приложению нескольким пользователям, а не всему арендатору.

1 Ответ

0 голосов
/ 06 июня 2018

Я полагаю, что вы получили все это задом наперед.

Ваш сценарий - бэкэнд SPA +.

Что вам нужно реализовать, это неявный поток предоставления OAuth 2.0, как описано здесь .

Implicit Flow

Источник для диаграммы: dzimchuk.net

С учетом access_token помещенный в хранилище сеансов агента пользователя, вы можете затем вызвать свой бэкэнд.Используйте adal.js , чтобы сделать вашу жизнь проще.

Поскольку ваш сервер Python IS является конфиденциальным клиентом, теперь вы можете запросить токен доступа из конечной точки MSI длянужной аудитории (ресурс Azure), вызовите ее, затем отфильтруйте результаты, чтобы она соответствовала вашей логике прав доступа.

Обратите внимание, что на момент написания только часть ресурсов Azure может использовать MSI-выданные токены доступа .

...