Share via

Защита API службы управления API Azure с помощью Azure AD B2C

  • Статья

Узнайте, как ограничить доступ к API службы управления API Azure для клиентов, которые прошли проверку подлинности с помощью Azure Active Directory B2C (Azure AD B2C). Выполните инструкции, описанные в этой статье, чтобы создать и протестировать политику входящего трафика в Azure API Management, которая предоставляет доступ только к тем запросам, которые включают в себя действительный маркер доступа, выданный Azure AD B2C.

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

Перед началом работы убедитесь, что у вас есть следующие ресурсы:

Получение идентификатора приложения Azure AD B2C

При защите API службы управления API Azure с помощью Azure AD B2C требуется несколько значений для политики входящего трафика, создаваемой в Azure API Management. Сначала запишите идентификатор приложения, созданного ранее в клиенте Azure AD B2C. Если вы используете созданное приложение для выполнения предварительных требований, используйте идентификатор приложения для webapp1.

Чтобы зарегистрировать приложение в клиенте Azure AD B2C, можно использовать новый унифицированный интерфейс Регистрации приложений или устаревший интерфейс приложений. Дополнительные сведения о новых функциях регистрации.

  1. Войдите на портал Azure.
  2. Если у вас есть доступ к нескольким клиентам, выберите значок Параметры в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню каталогов и подписок.
  3. На левой панели выберите Azure AD B2C. В качестве альтернативы можно выбрать Все службы, а затем найти и выбрать Azure AD B2C.
  4. Выберите Регистрация приложений и откройте вкладку Собственные приложения.
  5. Запишите значение в столбце ИД приложения (клиент) для webapp1 или другого ранее созданного приложения.

Получение конечной точки издателя маркера

Затем получите известный URL-адрес конфигурации для одного из пользовательских потоков Azure AD B2C. Вам также понадобится URI конечной точки издателя маркера, который вы хотите поддерживать в Azure API Management.

  1. На портале Azure перейдите к клиенту Azure AD B2C.

  2. В разделе Политики выберите Потоки пользователей.

  3. Выберите имеющуюся политику (например, B2C_1_signupsignin1), а затем Выполнить поток пользователя.

  4. Запишите URL-адрес в гиперссылке, которая отображается под заголовком Выполнить поток пользователя в верхней части страницы. Этот URL-адрес является известной конечной точкой обнаружения OpenID Connect для потока пользователя и применяется в следующем разделе при настройке политики входящего трафика в Azure API Management.

    Screenshot of the well-known URI hyperlink on the

  5. Нажмите на гиперссылку, чтобы перейти на известную страницу конфигурации OpenID Connect.

  6. На странице, которая открывается в браузере, запишите значение issuer. Например:

    https://<tenant-name>.b2clogin.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/v2.0/

    Это значение будет использоваться в следующем разделе при настройке API в Azure API Management.

У вас должно быть записано два URL-адреса для следующего раздела: URL-адрес известной конечной точки конфигурации OpenID Connect и URI издателя. Например:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/B2C_1_signupsignin1/v2.0/.well-known/openid-configuration
https://<tenant-name>.b2clogin.com/99999999-0000-0000-0000-999999999999/v2.0/

Настройка политики входящего трафика в Azure API Management.

Теперь все готово к добавлению политики входящего трафика в службе управления API Azure, которая проверяет вызовы API. Добавив политику проверки веб-маркера JSON (JWT), которая проверяет аудиторию и издателя в маркере доступа, можно гарантировать, что принимаются только вызовы API с действительным маркером.

  1. В портале Azure перейдите к экземпляру Azure API Management.

  2. Выберите Интерфейсы API.

  3. Выберите API, который требуется защитить с помощью Azure AD B2C.

  4. Выберите вкладку Конструктор.

  5. В разделе Обработка входящего трафика выберите </>, чтобы открыть редактор кода политики.

  6. Разместите следующий тег <validate-jwt> в политике <inbound>, а затем выполните следующее:

    a. Обновите значение url в элементе <openid-config> с помощью известного URL-адреса конфигурации политики.
    b. Обновите элемент <audience>, указав идентификатор приложения, созданного ранее в клиенте B2C (например, webapp1).
    c. Обновите элемент <issuer>, указав конечную точку издателя маркера, записанную ранее.

    <policies>
    <inbound>
        <validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
            <openid-config url="https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/B2C_1_signupsignin1/v2.0/.well-known/openid-configuration" />
            <audiences>
                <audience>44444444-0000-0000-0000-444444444444</audience>
            </audiences>
            <issuers>
                <issuer>https://<tenant-name>.b2clogin.com/99999999-0000-0000-0000-999999999999/v2.0/</issuer>
            </issuers>
        </validate-jwt>
        <base />
    </inbound>
    <backend> <base /> </backend>
    <outbound> <base /> </outbound>
    <on-error> <base /> </on-error>
</policies>

Проверка безопасного доступа к API

Чтобы убедиться, что доступ к API предоставляется только вызывающим объектам, прошедшим проверку подлинности, можно проверить конфигурацию службы управления API Azure, вызвав API с помощью Postman.

Чтобы вызвать API, требуется маркер доступа, выданный Azure AD B2C, и ключ подписки Azure API Management.

Получение маркера доступа.

Сначала требуется маркер, выданный Azure AD B2C для использования в заголовке Authorization в Postman. Вы можете получить его, используя функцию Запустить сейчас в потоке регистрации или входа пользователя, который вы создали на этапе предварительных требований.

  1. На портале Azure перейдите к клиенту Azure AD B2C.

  2. В разделе Политики выберите Потоки пользователей.

  3. Выберите существующий поток регистрации или входа пользователя (например, B2C_1_signupsignin1).

  4. Для параметра Приложение выберите webapp1.

  5. Для параметра URL-адрес ответа выберите https://jwt.ms.

  6. Выберите Выполнить поток пользователя.

    Screenshot of the

  7. Завершите процесс входа в систему. Вы будете перенаправлены на страницу https://jwt.ms.

  8. Запишите закодированное значение маркера, отображаемое в браузере. Это значение маркера используется для заголовка авторизации в Postman.

    Screenshot of the encoded token value displayed on jwt.ms.

Получение ключа подписки на API

Клиентское приложение (в данном случае Postman), которое вызывает опубликованный API, должно содержать допустимый ключ подписки службы управления API в HTTP-запросах к API. Чтобы получить ключ подписки для включения в HTTP-запрос Postman, выполните следующие действия.

  1. На портале Azure перейдите к экземпляру службы Azure API Management.
  2. Выберите Подписки.
  3. Выберите многоточие (...) рядом с пунктом Продукт: без ограничений и затем выберите Показать/скрыть ключи.
  4. Запишите первичный ключ продукта. Этот ключ используется для заголовка Ocp-Apim-Subscription-Key в HTTP-запросе в Postman.

Screenshot of the

Проверка безопасного вызова API

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

  1. Создайте новый запрос GET в Postman. В поле URL-адреса запроса укажите конечную точку списка докладчиков API, опубликованного в качестве предварительного требования. Например:

    https://contosoapim.azure-api.net/conference/speakers

  2. Затем добавьте следующие заголовки.

    Ключ Значение
    Authorization Записанное ранее закодированное значение маркера с префиксом Bearer (после "Bearer" должен быть пробел)
    Ocp-Apim-Subscription-Key Записанный ранее ключ подписки на Azure API Management.

    URL-адрес и заголовки запроса GET должны быть похожи на показанные на следующем изображении:

    Screenshot of the Postman UI showing the GET request URL and headers.

  3. Нажмите кнопку Отправить в Postman, чтобы выполнить запрос. Если все настроено правильно, вы должны получить ответ JSON с коллекцией докладчиков (ниже показана усеченная версия):

    {
  "collection": {
    "version": "1.0",
    "href": "https://conferenceapi.azurewebsites.net:443/speakers",
    "links": [],
    "items": [
      {
        "href": "https://conferenceapi.azurewebsites.net/speaker/1",
        "data": [
          {
            "name": "Name",
            "value": "Scott Guthrie"
          }
        ],
        "links": [
          {
            "rel": "http://tavis.net/rels/sessions",
            "href": "https://conferenceapi.azurewebsites.net/speaker/1/sessions"
          }
        ]
      },
[...]

Проверка небезопасного вызова API

Теперь, когда вы выполнили успешный запрос, проверьте случай сбоя, чтобы убедиться, что вызовы API с недопустимым маркером отклоняются, как и ожидалось. Один из способов выполнить тест — добавить или изменить несколько символов в значении маркера, а затем выполнить тот же запрос GET, как и раньше.

  1. Добавьте несколько символов к значению токена, чтобы имитировать недопустимый токен. Например, можно добавить "НЕДОПУСТИМЫЙ" в значение токена, как показано ниже:

    Screenshot of the Headers section of Postman UI showing the string INVALID added to token.

  2. Нажмите кнопку Отправить, чтобы выполнить запрос. При использовании недопустимого маркера ожидаемый результат является кодом состояния несанкционированного доступа 401:

    {
    "statusCode": 401,
    "message": "Unauthorized. Access token is missing or invalid."
}

Если вы видите код состояния 401, это значит, что только вызывающие объекты с действительным маркером доступа, выданным Azure AD B2C, могут успешно выполнять запросы к API Azure API Management.

Поддержка нескольких приложений и издателей

Несколько приложений обычно взаимодействуют с одним REST API. Чтобы разрешить API принимать маркеры, предназначенные для нескольких приложений, добавьте идентификаторы приложений в элемент <audiences> в политике входящего трафика Azure API Management.

<!-- Accept tokens intended for these recipient applications -->
<audiences>
    <audience>44444444-0000-0000-0000-444444444444</audience>
    <audience>66666666-0000-0000-0000-666666666666</audience>
</audiences>

Аналогичным образом для поддержки нескольких издателей маркеров добавьте их URI конечной точки в элемент <issuers> в политике входящего трафика Azure API Management.

<!-- Accept tokens from multiple issuers -->
<issuers>
    <issuer>https://<tenant-name>.b2clogin.com/99999999-0000-0000-0000-999999999999/v2.0/</issuer>
    <issuer>https://login.microsoftonline.com/99999999-0000-0000-0000-999999999999/v2.0/</issuer>
</issuers>

Миграция на b2clogin.com

Если у вас есть API Azure API Management, который проверяет маркеры, выданные устаревшей конечной точкой login.microsoftonline.com, необходимо перенести API и приложения, вызывающие его, чтобы использовать маркеры, выданные b2clogin.com.

Для выполнения поэтапной миграции можно использовать следующую общую процедуру.

  1. Добавьте поддержку в политику входящего трафика Azure API Management для маркеров, выдаваемых как b2clogin.com, так и login.microsoftonline.com.
  2. Обновите приложения по одному за раз, чтобы получить маркеры из конечной точки b2clogin.com.
  3. После того как все ваши приложения будут правильно получать маркеры от b2clogin.com, удалите поддержку маркеров, выданных login.microsoftonline.com, из API.

В следующем примере политики входящего трафика Azure API Management показано, как принимать маркеры, выданные b2clogin.com и login.microsoftonline.com. Кроме того, политика поддерживает запросы API из двух приложений.

<policies>
    <inbound>
        <validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
            <openid-config url="https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/B2C_1_signupsignin1/v2.0/.well-known/openid-configuration" />
            <audiences>
                <audience>44444444-0000-0000-0000-444444444444</audience>
                <audience>66666666-0000-0000-0000-666666666666</audience>
            </audiences>
            <issuers>
                <issuer>https://login.microsoftonline.com/99999999-0000-0000-0000-999999999999/v2.0/</issuer>
                <issuer>https://<tenant-name>.b2clogin.com/99999999-0000-0000-0000-999999999999/v2.0/</issuer>
            </issuers>
        </validate-jwt>
        <base />
    </inbound>
    <backend> <base /> </backend>
    <outbound> <base /> </outbound>
    <on-error> <base /> </on-error>
</policies>

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

Дополнительные сведения о политиках Azure API Management см. в статье Индекс справочника по политикам Azure API Management.

Сведения о миграции веб-API на основе OWIN на адрес b2clogin.com можно найти в статье Перенос веб-API на основе OWIN в b2clogin.com.