Поделиться через

Безопасный доступ к порталу разработчика "Управление API"

ОБЛАСТЬ ПРИМЕНЕНИЯ: Разработчик | Базовый | Базовая версия 2 | Стандартный | Standard v2 | Премиум | Премиум версии 2

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

Примечание.

По умолчанию портал разработчика включает анонимный доступ. Это означает, что любой пользователь может просматривать портал и содержимое, например API без входа, хотя такие функции, как использование тестовой консоли, ограничены. Вы можете включить параметр, требующий входа пользователей для просмотра портала разработчика. В меню портал Azure в левом меню экземпляра Управление API на портале разработчика выберите параметры удостоверений>. В разделе "Анонимные пользователи" выберите "Перенаправить анонимных пользователей" на страницу входа.

Варианты проверки подлинности

  • Внешние пользователи — предпочтительный вариант, когда портал разработчика используется внешним образом, — включить доступ через внешний идентификатор Microsoft Entra.

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

    Инструкции по включению проверки подлинности внешнего идентификатора Microsoft Entra на портале разработчика см. в статье "Как авторизовать учетные записи разработчика с помощью внешнего идентификатора Microsoft Entra".

    Примечание.

    Управление API обеспечивает устаревшую поддержку Azure Active Directory B2C в качестве внешнего поставщика удостоверений. Однако мы рекомендуем использовать внешний идентификатор Microsoft Entra в качестве поставщика удостоверений вместо Azure Active Directory B2C для новых развертываний портала разработчика управления API.

    Это важно

    Начиная с 1 мая 2025 г. Azure AD B2C больше не будет доступен для приобретения для новых клиентов. Дополнительные сведения см. в разделе "Вопросы и ответы".

  • Внутренние пользователи — предпочтительный вариант, когда портал разработчика используется внутренне, — использовать корпоративный идентификатор Microsoft Entra. Идентификатор Microsoft Entra предоставляет простой единый вход (SSO) для корпоративных пользователей, которым требуется доступ и обнаружение API через портал разработчика.

    Инструкции по включению проверки подлинности Microsoft Entra на портале разработчика см. в статье "Как авторизовать учетные записи разработчика с помощью идентификатора Microsoft Entra в Azure Управление API".

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

    Внимание

    Хотя вы можете использовать базовую проверку подлинности для защиты доступа пользователей к порталу разработчика, рекомендуется настроить более безопасный метод проверки подлинности, например Идентификатор Microsoft Entra илиВнешний идентификатор Microsoft Entra.

Консоль тестирования портала разработчика

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

Если API, предоставляемый через Azure Управление API, защищен с помощью OAuth 2.0, то есть вызывающее приложение (носитель) необходимо получить и передать действительный маркер доступа. Вы можете настроить Управление API для создания допустимого маркера от имени пользователя тестовой консоли портал Azure или портала разработчика. Дополнительные сведения см. в статье "Авторизация тестовой консоли портала разработчика", настроив авторизацию пользователя OAuth 2.0.

Чтобы включить тестовую консоль для получения допустимого маркера OAuth 2.0 для тестирования API:

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

  2. Затем настройте API с параметрами для этого сервера авторизации. На портале настройте авторизацию OAuth 2.0 на странице параметров API. Авторизация пользователя безопасности>.>

    Снимок экрана: параметры OAuth для API на портале.

Эта конфигурация OAuth 2.0 для тестирования API не зависит от конфигурации, необходимой для доступа пользователей к порталу разработчика. Однако поставщик удостоверений и пользователь могут совпадать. Например, приложению интрасети может потребоваться доступ пользователя к порталу разработчика с помощью единого входа с корпоративным удостоверением. Это же корпоративное удостоверение может получить маркер через тестовую консоль для вызываемой серверной службы с тем же контекстом пользователя.

Сценарии

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

Сценарий 1. API интрасети и приложения

  • Участник управления API и разработчик серверной части API хотят опубликовать API, защищенный OAuth 2.0.
  • API будет использоваться классическими приложениями, пользователи которых войдите с помощью единого входа с помощью идентификатора Microsoft Entra.
  • Разработчики классических приложений также должны обнаруживать и тестировать API с помощью портала разработчиков службы Управление API.

Основные параметры конфигурации:

Настройка Справочные материалы
Авторизация пользователей разработчика на портале разработчика Управление API с помощью корпоративных удостоверений и идентификатора Microsoft Entra. Авторизация учетных записей разработчиков через Microsoft Entra ID в службе управления Azure API
Настройте тестовую консоль на портале разработчика, чтобы получить действительный токен OAuth 2.0 для разработчиков классических приложений и позволить им использовать серверный API.

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

Маркер можно использовать в сочетании с ключом подписки службы Управление API.		 Авторизация тестовой консоли портала разработчика путем настройки авторизации пользователя с помощью OAuth 2.0

Подписки в службе управления API Azure
Проверьте токен OAuth 2.0 и утверждения при вызове API через службу Управление API с помощью маркера доступа. Проверка политики JWT

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

Сценарий 2. Внешний API, партнерское приложение

  • Участник управления API и разработчик api серверной части хотят выполнить быстрое подтверждение концепции для предоставления устаревшего API через управление API Azure. API через службу Управление API будет доступен извне (через Интернет).
  • API использует проверку подлинности сертификата клиента и будет использоваться новым общедоступным одностраничным приложением (SPA), разработанным партнером.
  • Spa использует OAuth 2.0 с OpenID Connect (OIDC).
  • Разработчики приложений будут получать доступ к API в тестовой среде через портал разработчика, используя тестовую конечную точку серверной части для ускорения разработки внешнего интерфейса.

Основные параметры конфигурации:

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

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

Управление учетными записями пользователей в службе управления API Azure
Проверьте токен OAuth 2.0 и утверждения, когда SPA вызывает Управление API с помощью маркера доступа. В этом случае аудитория — служба Управление API. Проверка политики JWT
Настройте службу Управление API для использования проверки подлинности на основе сертификата клиента в серверной части. Защита служб серверной части с помощью проверки подлинности сертификата клиента в Azure Управление API

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

Сценарий 3. Внешний API, SaaS, открытый для общего доступа

  • Участник управления API и разработчик api серверной части записывают несколько новых API, которые будут доступны разработчикам сообщества.

  • API-интерфейсы будут общедоступными, при этом полный набор функций будет предоставляться в платной версии, защищенной с помощью OAuth 2.0. После приобретения лицензии разработчику будут предоставлены собственные учетные данные клиента и ключ подписки, действительный для использования в рабочей среде.

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

  • Заинтересованные пользователи портала разработчиков с ключом тестовой подписки могут изучить функциональные возможности API в тестовом контексте без необходимости приобретать лицензию. Тестовая консоль портала разработчика представляет вызывающее приложение и создает маркер доступа по умолчанию для серверного API.

    Внимание

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

Основные параметры конфигурации:

Настройка Справочные материалы
Настройте продукты в службе Управление API Azure, представляющие различные API, предоставляемые разработчикам сообщества.

Настройте подписки, чтобы разработчики могли использовать интерфейсы API.		 Руководство по создавать и публиковать продукт;

Подписки в службе управления API Azure
Настройте доступ разработчика сообщества к порталу разработчика с помощью внешнего идентификатора Microsoft Entra. Затем внешний идентификатор Microsoft Entra External ID можно настроить для работы с одним или несколькими смежными поставщиками социальных сетей. Авторизация учетных записей разработчиков с помощью внешнего идентификатора Microsoft Entra в службе "Управление API Azure"
Настройте тестовую консоль на портале разработчика, чтобы получить действительный маркер OAuth 2.0 для серверного API с помощью потока учетных данных клиента. Авторизация тестовой консоли портала разработчика путем настройки авторизации пользователя с помощью OAuth 2.0

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

Перейдите к следующему шагу, делегировав регистрацию пользователя или подписку на продукт и расширив процесс на основе собственной логики.

Связанный контент

  • Last updated on