Руководство по сквозной проверке подлинности и авторизации в службе приложений Azure

Проверка подлинности в этой процедуре предоставляется на уровне платформы хостинга службой приложений Azure. Необходимо развернуть интерфейсное и серверное приложение и настроить проверку подлинности для успешного использования этого веб-приложения.

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

Изучив это руководство, вы:

Предварительные условия

Если у вас нет аккаунта Azure, создайте бесплатную учетную запись перед началом.

• Node.js (LTS)

• Используйте среду Bash в Azure Cloud Shell. Дополнительные сведения см. в статье "Начало работы с Azure Cloud Shell".

  

• Если вы предпочитаете выполнять справочные команды CLI локально, установите Azure CLI. Если вы работаете в Windows или macOS, Azure CLI можно запустить в контейнере Docker. Дополнительные сведения см. в статье Как запустить Azure CLI в контейнере Docker.

  • Если вы используете локальную установку, выполните вход в Azure CLI с помощью команды az login. Чтобы выполнить аутентификацию, следуйте инструкциям в окне терминала. Сведения о других параметрах входа см. в статье "Проверка подлинности в Azure с помощью Azure CLI".

  • Установите расширение Azure CLI при первом использовании, когда появится соответствующий запрос. Дополнительные сведения о расширениях см. в статье Использование расширений и управление ими с помощью Azure CLI.

  • Выполните команду az version, чтобы узнать установленную версию и зависимые библиотеки. Чтобы обновиться до последней версии, выполните команду az upgrade.

Получение профиля пользователя

Интерфейсное приложение настроено для безопасного использования внутреннего API. Интерфейсное приложение предоставляет пользователю вход через аккаунт Microsoft, а затем позволяет пользователю получить свой поддельный профиль с сервера. В этом руководстве используется поддельный профиль для упрощения действий по выполнению сценария.

Перед выполнением исходного кода на клиентской части служба приложений внедряет аутентифицированный accessToken из заголовка службы приложений x-ms-token-aad-access-token. Затем интерфейсный исходный код обращается к серверу и отправляет его accessToken на внутренний сервер. Фронтэнд-сервер отправляет токен в качестве bearerToken, чтобы безопасно получить доступ к бэкэнд API. Сервер проверяет bearerToken перед его передачей в ваш исходный код на стороне сервера. После получения bearerTokenвнутреннего исходного кода его можно использовать.

В следующем руководстве этой серии bearerToken заменяется на токен с областью доступа к API Microsoft Graph. API Microsoft Graph возвращает сведения о профиле пользователя.

Клонирование примера приложения

В Azure Cloud Shell выполните следующую команду, чтобы клонировать пример репозитория.

git clone https://github.com/Azure-Samples/js-e2e-web-app-easy-auth-app-to-app

Создание и развертывание приложений

Создайте группу ресурсов, план веб-приложения и веб-приложение, а затем разверните его на одном шаге.

Настройка параметра приложения

Интерфейсное приложение должно знать URL-адрес внутреннего приложения для запросов API. Чтобы настроить параметр приложения, используйте следующую команду Azure CLI. URL-адрес должен быть https://<back-end-app-name>.azurewebsites.net.

az webapp config appsettings set --resource-group myAuthResourceGroup --name <front-end-app-name> --settings BACKEND_URL="https://<back-end-app-name>.azurewebsites.net"

Клиентская часть вызывает серверную часть

Перейдите в интерфейсное приложение и верните поддельный профиль из серверной части. Это действие проверяет, успешно ли интерфейс запрашивает профиль из серверной части, а серверная часть возвращает профиль.

1. Откройте интерфейсное веб-приложение в браузере: https://<front-end-app-name>.azurewebsites.net

   

2. Выберите ссылку "Получить профиль пользователя ".

3. Просмотрите поддельный профиль, возвращенный из внутреннего веб-приложения.

   

   Значение withAuthenticationfalse указывает, что проверка подлинности еще не настроена.

Настройка проверки подлинности

В этом разделе описано, как включить проверку подлинности и авторизацию для двух веб-приложений. В этом руководстве в качестве поставщика удостоверений используется Microsoft Entra ID.

Вы также настраиваете интерфейсное приложение следующими способами:

• Предоставьте фронтенд-приложению доступ к бэкенд-приложению
• Настроить службу приложений, чтобы вернуть доступный токен.
• Используйте токен в вашем коде

Дополнительные сведения см. в разделе Настройка проверки подлинности Microsoft Entra для приложения App Services.

Включение проверки подлинности и авторизации для серверного приложения

1. На портале Azure найдите и выберите группы ресурсов.

2. В разделе Группы ресурсов найдите и выберите свою группу ресурсов. В разделе "Обзор" выберите серверное приложение.

3. В левом меню внутреннего приложения выберите "Параметры>проверки подлинности" и выберите "Добавить поставщика удостоверений".

4. На странице Добавление поставщика удостоверений в поле Поставщик удостоверений выберите Microsoft, чтобы войти с использованием удостоверений Microsoft и Microsoft Entra.

5. Выберите значение срока действия секрета клиента.

   

6. Для других значений примите параметры по умолчанию и нажмите кнопку "Добавить".

7. Откроется страница Проверка подлинности. Скопируйте идентификатор клиента приложения Microsoft Entra в Блокнот. Это значение понадобится позже.

   

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

Включение проверки подлинности и авторизации для интерфейсного приложения

1. На портале Azure найдите и выберите группы ресурсов.

2. В разделе Группы ресурсов найдите и выберите свою группу ресурсов. В разделе "Обзор" выберите интерфейсное приложение.

3. В меню слева в интерфейсном приложении выберите "Параметры>" и выберите "Добавить поставщика удостоверений".

4. На странице Добавление поставщика удостоверений в поле Поставщик удостоверений выберите Microsoft, чтобы войти с использованием удостоверений Microsoft и Microsoft Entra.

5. Выберите значение срока действия секрета клиента. Для других значений примите параметры по умолчанию и нажмите кнопку "Добавить".

6. Откроется страница Проверка подлинности. Скопируйте идентификатор клиента приложения Microsoft Entra в Блокнот. Это значение понадобится позже.

Предоставить приложению фронтэнд доступ к приложению бэкенд

Вы включили проверку подлинности и авторизацию для обоих приложений. Чтобы завершить проверку подлинности, необходимо выполнить три действия.

• Предоставление серверного приложения в качестве API путем определения области
• Предоставление интерфейсным приложениям доступа к внутреннему приложению
• Настроить службу приложений, чтобы вернуть доступный токен.
• Используйте токен в вашем коде

В этом разделе описано, как предоставить интерфейсное приложение доступ к внутреннему приложению от имени пользователя. Технически вы предоставляете приложению AD внешнего интерфейса разрешения на доступ к приложению AD серверной части от имени пользователя.

1. На странице проверки подлинности для внешнего приложения в разделе "Поставщик удостоверений" выберите имя внешнего приложения. Эта регистрация приложения была автоматически создана для вас.

2. Выберите "Управление разрешениями>API " в меню слева.

3. Выберите Добавить разрешение, а затем — Мои API><имя_серверного_приложения>.

4. На странице разрешений API запроса для внутреннего приложения выберите делегированные разрешения и user_impersonation, а затем нажмите кнопку "Добавить разрешения".

   

Настройте службу приложений для возвращения действующих токенов доступа

Теперь интерфейсное приложение имеет необходимые разрешения для доступа к внутреннему приложению в качестве пользователя, вошедшего в систему. В этом разделе настройте аутентификацию и авторизацию App Service для получения токена доступа для доступа к бэкенду. Для этого шага требуется ID клиента бэкэнда, который вы скопировали из раздела "Включить проверку подлинности и авторизацию для приложения бэкэнда".

В Cloud Shell выполните следующие команды в интерфейсном приложении, чтобы добавить scope параметр в параметр identityProviders.azureActiveDirectory.login.loginParametersпроверки подлинности. Замените <front-end-app-name> и <back-end-client-id>.

az extension add --name authV2
authSettings=$(az webapp auth show -g myAuthResourceGroup -n <front-end-app-name>)
authSettings=$(echo "$authSettings" | jq '.properties' | jq '.identityProviders.azureActiveDirectory.login += {"loginParameters":["scope=openid offline_access api://<back-end-client-id>/user_impersonation"]}')
az webapp auth set --resource-group myAuthResourceGroup --name <front-end-app-name> --body "$authSettings"

Команды добавляют loginParameters свойство с другими настраиваемыми областями действия. Ниже приведено описание запрошенной области:

• openid уже запрашивается Службой приложений по умолчанию. Дополнительные сведения см. в разделе "Области подключения OpenID".
• offline_access включается здесь для удобства, если вы хотите обновить маркеры.
• api://<back-end-client-id>/user_impersonation — это открытый API в регистрации серверного приложения. Это область, которая предоставляет JWT, которая включает серверное приложение в качестве аудитории токенов.

Теперь приложения настроены. Фронтенд теперь готов к доступу к серверной части с соответствующим токеном доступа.

Сведения о том, как настроить маркер доступа для других поставщиков, см. раздел о том, как обновить маркеры идентификационных данных.

Настройте серверную службу приложений для принятия токена только от фронтэнд-службы приложений.

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

Этот подход можно реализовать с помощью того же процесса Azure CLI, который использовался на предыдущем шаге.

1. appId Получите интерфейсную службу приложений. Это значение можно получить на странице проверки подлинности в интерфейсной службе приложений.

2. Запустите следующий интерфейс командной строки Azure, заменив <back-end-app-name> и <front-end-app-id>.

authSettings=$(az webapp auth show -g myAuthResourceGroup -n <back-end-app-name>)
authSettings=$(echo "$authSettings" | jq '.properties' | jq '.identityProviders.azureActiveDirectory.validation.defaultAuthorizationPolicy.allowedApplications += ["<front-end-app-id>"]')
az webapp auth set --resource-group myAuthResourceGroup --name <back-end-app-name> --body "$authSettings"

Фронтенд вызывает аутентифицированную серверную часть

Интерфейсное приложение должно передать аутентификацию пользователя с правильной user_impersonation областью серверу. Ниже приведены действия, описанные в примере кода для этой функции.

Просмотрите исходный код интерфейсного приложения:

1. Используйте внешний заголовок службы приложений, внедренный x-ms-token-aad-access-token программным способом, чтобы получить доступ пользователя к AccessToken.

   // ./src/server.js
   const accessToken = req.headers['x-ms-token-aad-access-token'];
   

2. Используйте accessToken в заголовке Authentication для значения bearerToken.

   // ./src/remoteProfile.js
   // Get profile from backend
   const response = await fetch(remoteUrl, {
       cache: "no-store", // no caching -- for demo purposes only
       method: 'GET',
       headers: {
           'Authorization': `Bearer ${accessToken}`
       }
   });
   if (response.ok) {
       const { profile } = await response.json();
       console.log(`profile: ${profile}`);
   } else {
       // error handling
   }
   

   В этом руководстве возвращается фальшивый профиль для упрощения сценария. В следующем руководстве этой серии показано, как обменять серверную часть bearerToken на новый маркер с областью нижестоящей службы Azure, например Microsoft Graph.

Серверная часть пересылает профиль пользовательскому интерфейсу

Если запрос с внешнего интерфейса не авторизован, серверная служба приложений отклоняет запрос с кодом ошибки HTTP 401 , прежде чем запрос достигнет кода приложения. Когда достигается серверный код, поскольку он включает авторизованный маркер, извлеките bearerToken, чтобы получить accessToken.

Просмотрите исходный код внутреннего приложения:

// ./src/server.js
const bearerToken = req.headers['Authorization'] || req.headers['authorization'];

if (bearerToken) {
    const accessToken = bearerToken.split(' ')[1];
    console.log(`backend server.js accessToken: ${!!accessToken ? 'found' : 'not found'}`);

    // TODO: get profile from Graph API
    // provided in next article in this series
    // return await getProfileFromMicrosoftGraph(accessToken)

    // return fake profile for this tutorial
    return {
        "displayName": "John Doe",
        "withAuthentication": !!accessToken ? true : false
    }
}

Перейдите к приложениям

1. Используйте внешний веб-сайт в браузере. URL-адрес: https://<front-end-app-name>.azurewebsites.net/.

2. Браузер запрашивает проверку подлинности в веб-приложении. Завершите проверку подлинности.

   

3. После завершения проверки подлинности интерфейсное приложение возвращает домашнюю страницу приложения.

   

4. Выберите "Получить профиль пользователя". Это действие передает вашу аутентификацию в токен носителя для серверного уровня.

5. Серверная часть отвечает с поддельным именем жёстко запрограммированного профиля: John Doe.

   

   Значение withAuthenticationtrue указывает, что проверка подлинности настроена сейчас.

Очистите ресурсы

На предыдущем шаге вы создали ресурсы Azure в группе ресурсов.

1. Удалите группу ресурсов, выполнив следующую команду в Cloud Shell. Ее выполнение может занять до минуты.

   az group delete --name myAuthResourceGroup
   

2. Используйте идентификатор клиента приложений-аутентификаторов, который вы ранее нашли и отметили для разделов приложений бэкенда и фронтенда.

3. Удалите регистрационные записи приложений для клиентских и серверных приложений.

   # delete app - do this for both frontend and backend client ids
   az ad app delete <client-id>
   

Часто задаваемые вопросы

Как мне проверить эту аутентификацию на моем локальном компьютере разработки?

Проверка подлинности в этой процедуре предоставляется на уровне платформы хостинга службой приложений Azure. Нет эквивалентного эмулятора. Необходимо развернуть клиентское и серверное приложение и настроить проверку подлинности для каждого из них, чтобы использовать её.

Приложение не отображает поддельный профиль, как его отлаживать?

Интерфейсные и внутренние приложения имеют /debug маршруты для отладки проверки подлинности, когда это приложение не возвращает поддельный профиль. Интерфейсный маршрут отладки предоставляет критически важные компоненты для проверки:

• Переменные среды:

  • BACKEND_URL настроен(а/о) правильно в качестве https://<back-end-app-name>.azurewebsites.net. Не включайте завершающую косую черту или путь.

• Заголовки HTTP:

  • Заголовки x-ms-token-* внедряются.

• Отображается имя профиля Microsoft Graph для пользователя, выполнившего вход.

• Область применения токена фронтенд приложения имеет . Если область видимости не включает это значение, это может быть проблема с синхронизацией. Проверьте параметры внешнего приложения login в ресурсах Azure. Подождите несколько минут, пока закончится обработка данных проверки подлинности.

Был ли исходный код приложения правильно развернут на каждом веб-приложении?

1. На портале Azure для веб-приложения выберите Инструменты разработки>Расширенные средства, затем выберите Перейти. Это действие открывает новую вкладку браузера или окно.

2. На новой вкладке браузера выберите Просмотр каталога>Сайт wwwroot.

3. Убедитесь, что в каталоге находятся следующие элементы:

   • package.json
   • node_modules.tar.gz
   • /src/index.js

4. Убедитесь, что свойство package.jsonname совпадает с веб-именем, либо frontend, либо backend.

5. Если вы изменили исходный код и хотите повторно развернуть, используйте команду az webapp up из каталога с файломpackage.json для этого приложения.

Было ли приложение запущено правильно?

Оба веб-приложения должны возвращать что-то при запросе домашней страницы. Если вы не можете достучаться до /debug в веб-приложении, значит, приложение не было запущено правильно. Просмотрите журналы ошибок для этого веб-приложения.

1. На портале Azure для веб-приложения выберите Инструменты разработки>Расширенные средства, затем выберите Перейти. Это действие открывает новую вкладку браузера или окно.
2. На новой вкладке браузера выберите Обзор каталога>Журналы развертывания.
3. Просмотрите каждый журнал, чтобы найти все сообщаемые проблемы.

Может ли интерфейсное приложение взаимодействовать с серверным приложением?

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

• Серверное веб-приложение возвращает все ошибки в интерфейсное приложение, если оно было достигнуто. Если оно не достигнуто, интерфейсное приложение сообщает код состояния и сообщение.

  • 401. Пользователь не прошел проверку подлинности правильно. Это сообщение может указывать, что область не задана правильно.
  • 404: URL-адрес не соответствует маршруту, который есть на сервере.

• Используйте потоковые журналы серверного приложения, чтобы наблюдать за запросом на клиентской стороне для профиля пользователя. В исходном коде console.logесть отладочная информация, с помощью которой можно определить, где произошел сбой.

Что происходит при истечении срока действия внешнего маркера?

Срок действия токена доступа истекает через некоторое время. Сведения об обновлении маркеров доступа без повторной проверки подлинности пользователей в приложении см. в разделе об обновлении маркеров поставщиков удостоверений.

Если у меня есть приложение на основе браузера в интерфейсном приложении, оно может напрямую взаимодействовать с серверной частью?

Этот подход требует, чтобы код сервера передавал маркер доступа коду JavaScript, работающему в клиентском браузере. Так как в браузере нет способа защитить маркер доступа, мы не рекомендуем этот подход. В настоящее время мы рекомендуем шаблон Backend-for-Frontend.

Если применить к примеру в этом руководстве, код браузера в клиентском приложении будет делать вызовы API в сеансе, прошедшем проверку подлинности, к коду сервера, выступающему в качестве посредника. Затем код сервера в клиентском приложении будет выполнять вызовы API к серверному приложению, используя значение заголовка x-ms-token-aad-access-token в качестве маркера носителя. Все вызовы из кода браузера в код сервера защищены прошедшим проверку подлинности сеансом.

Следующий шаг

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