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

В руководстве вы узнаете:

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

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

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

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

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

Необходимые компоненты

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

• Node.js (LTS)

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

  

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

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

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

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

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

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

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

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

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

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

Интерфейсное приложение должно знать 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"

4. Интерфейс вызывает серверную часть

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

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

   

2. Выберите ссылку Get user's profile.

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

   

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

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

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

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

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

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

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

1. В меню портала Azure выберите Группы ресурсов или выполните поиск по запросу Группы ресурсов на любой странице и выберите этот пункт.

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

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

4. На странице "Добавление поставщика удостоверений" выберите Корпорацию Майкрософт в качестве поставщика удостоверений для входа в удостоверения Майкрософт и Microsoft Entra.

5. Примите параметры по умолчанию и нажмите кнопку "Добавить".

   

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

   

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

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

1. В меню портала Azure выберите Группы ресурсов или выполните поиск по запросу Группы ресурсов на любой странице и выберите этот пункт.

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

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

4. На странице "Добавление поставщика удостоверений" выберите Корпорацию Майкрософт в качестве поставщика удостоверений для входа в удостоверения Майкрософт и Microsoft Entra.

5. Примите параметры по умолчанию и нажмите кнопку "Добавить".

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

Предоставление интерфейсным приложениям доступа к серверной части

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

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

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

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

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

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

   

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

Интерфейсное приложение теперь имеет необходимые разрешения для доступа к внутреннему приложению в качестве пользователя, вошедшего в систему. На этом шаге вы настроите Служба приложений проверку подлинности и авторизацию, чтобы предоставить вам доступный маркер доступа для доступа к серверной части. Для этого шага требуется идентификатор клиента серверной части, скопированный из параметра Enable authentication and authorization for backend app.

В 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 Connect.
• offline_access приведен здесь для удобства (если требуется обновить маркеры).
• api://<back-end-client-id>/user_impersonation — это предоставляемый API в регистрации серверного приложения. Это область, которая предоставляет токен JWT, который включает серверное приложение в качестве аудитории токенов.

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

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

6. Настройте серверную Служба приложений для принятия маркера только из интерфейсной Служба приложений

Кроме того, необходимо настроить серверную Служба приложений только для принятия маркера из интерфейсного Служба приложений. Это может привести к ошибке "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"

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

7. Интерфейс вызывает прошедший проверку подлинности серверной части

Интерфейсный приложение должно передать проверку подлинности пользователя с правильной 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
   }
   

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

7. Серверная часть возвращает профиль интерфейсу

Если запрос от внешнего интерфейса не авторизован, серверная служба приложений отклоняет запрос с кодом ошибки HTTP 401, прежде чем запрос достигнет кода приложения. Когда внутренний код достигается (так как он включает авторизованный маркер), извлеките носительToken, чтобы получить 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
    }
}

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

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

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

   

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

   

4. Выберите Get user's profile. Это передает проверку подлинности в маркер носителя серверной части.

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

   

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

9. Очистка ресурсов

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

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

   az group delete --name myAuthResourceGroup
   

2. Используйте идентификатор клиента приложений проверки подлинности, которые вы ранее нашли и запишите в Enable authentication and authorization разделах для внутренних и интерфейсных приложений.

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 для пользователя, выполнившего вход.
• Область внешнего приложения для маркераuser_impersonation. Если область не включает эту область, это может быть проблема с временем. Проверьте параметры внешнего приложения login в ресурсах Azure. Подождите несколько минут для репликации проверки подлинности.

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

1. В портал Azure для веб-приложения выберите "Средства разработки" —> "Дополнительные средства", а затем нажмите кнопку "Перейти>". Откроется новая вкладка браузера или окно.

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

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

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

4. Убедитесь, что свойство package.json name совпадает с веб-именем или 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.