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

Сведения об учетных данных API и диспетчере учетных данных

  • Статья

ПРИМЕНЕНИЕ: всех уровней управления API

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

Примечание.

  • В настоящее время можно использовать диспетчер учетных данных для настройки и управления подключениями (ранее называвшимися авторизациями) для API OAuth 2.0.
  • В диспетчере учетных данных не вводятся критические изменения. Поставщики учетных данных и подключения OAuth 2.0 используют существующие API авторизации Управление API и поставщика ресурсов.

Примечание.

В настоящее время эта функция недоступна в рабочих областях.

Управляемые подключения для API OAuth 2.0

С помощью диспетчера учетных данных можно значительно упростить процесс проверки подлинности и авторизации пользователей, групп и субъектов-служб в одной или нескольких службах SaaS, использующих OAuth 2.0. Используя менеджер учетных данных в Управлении API, легко настраивайте OAuth 2.0, согласие, получайте токены, сохраняйте их в хранилище учетных данных и обновляйте их без написания ни одной строки кода. Используйте политики доступа для делегирования проверки подлинности экземпляру службы API Management, служебным субъектам, пользователям или группам. Для получения сведений об OAuth 2.0 см. платформу удостоверений Майкрософт и поток кода авторизации OAuth 2.0.

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

Схема диспетчера учетных данных управления API и поддерживаемых поставщиков идентификации SaaS.

Примеры вариантов использования

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

  • Легко подключитесь к серверной части SaaS, добавив хранимый токен авторизации и используя запросы через прокси.

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

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

  • Предоставьте конечную точку для получения токена, получите кэшированный токен и вызовите бэкенд SaaS от имени пользователя с любого вычислительного устройства, например консольного приложения или демона Kubernetes. Объедините любимый пакет SDK SaaS на поддерживаемом языке.

  • Функции Azure в автономных сценариях при подключении к нескольким бэкендам SaaS.

  • Durable Functions становятся ближе к Logic Apps за счёт соединения с SaaS.

  • При подключении OAuth 2.0 каждый API в API Management может быть пользовательским разъемом Logic Apps.

Как работает диспетчер учетных данных?

Учетные данные токена в диспетчере учетных данных состоят из двух частей: управления и время выполнения.

  • Часть управления в диспетчере учетных данных отвечает за установку и настройку поставщика учетных данных для маркеров OAuth 2.0, активацию процесса согласия для поставщика удостоверений и установку одного или нескольких соединений с поставщиком учетных данных для доступа к учетным данным. Дополнительные сведения см. в разделе "Управление подключениями".

  • Часть среды выполнения использует get-authorization-context политику для получения и хранения токенов доступа и обновления подключения. При поступлении вызова в Управление API и выполнении политики get-authorization-context, сначала проверяется, является ли существующий маркер авторизации допустимым. Если срок действия маркера авторизации истек, Управление API использует поток OAuth 2.0 для обновления сохраненных маркеров от поставщика удостоверений. Затем маркер доступа используется для авторизации доступа к серверной службе. Дополнительные сведения см. в разделе "Время выполнения подключений".

Когда следует использовать диспетчер учетных данных?

Ниже приведены три сценария использования диспетчера учетных данных.

Сценарий конфигурации

После настройки поставщика учетных данных и подключения диспетчер API может проверить подключение. Менеджер API настраивает тестовый серверный API OAuth для использования политики get-authorization-context, используя управляемую идентичность экземпляра. Затем диспетчер API может протестировать подключение, вызвав тестовый API.

Схема начального сценария настройки диспетчера учетных данных.

Сценарий автоматического выполнения

По умолчанию при создании подключения политика доступа и подключение предварительно настраиваются для управляемой идентичности экземпляра API Management. Для использования такого подключения разные пользователи могут войти в клиентское приложение, например статичное веб-приложение, которое затем вызывает внутренний API, предоставляемый через Управление API. Чтобы сделать этот вызов, подключение выполняется с применением политики get-authorization-context. Так как вызов API использует предварительно настроенное подключение, которое не связано с контекстом пользователя, то одни и те же данные возвращаются всем пользователям.

Схема сценария управляемой идентификации для диспетчера учетных данных.

Сценарий с участием пользователя (делегированный)

Чтобы включить упрощенную проверку подлинности для пользователей клиентских приложений, таких как статические веб-приложения, которые вызывают внутренние API SaaS, требующие контекста пользователя, можно включить доступ к подключению от имени пользователя Или удостоверения группы Microsoft Entra. В этом случае конфигурированный пользователь должен войти в систему и предоставить согласие только один раз, и экземпляр системы управления API будет создавать и затем управлять их подключением. Когда Управление API получает входящий вызов, который будет перенаправляться во внешнюю службу, он присоединяет маркер доступа из подключения к запросу. Это идеально подходит, когда запросы и ответы API предназначены для отдельного пользователя (например, получение сведений о профиле конкретного пользователя).

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

Как настроить диспетчер учетных данных?

Требования

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

  • Экземпляр системы управления API должен иметь исходящее подключение к Интернету на порту 443 (HTTPS).

Доступность

  • Все уровни служб управления API

  • Не поддерживается в локальном шлюзе

  • Не поддерживается в национальных облаках или в следующих регионах: australiacentral, australiacentral2, indiacentral

Примеры с пошаговыми инструкциями

Вопросы безопасности

Токен доступа и другие секреты (например, секреты клиента) шифруются с использованием конвертного шифрования и хранятся во внутреннем мультитенантном хранилище. Данные шифруются с помощью AES-128 с помощью ключа, уникального для каждого данных. Эти ключи шифруются асимметрично с помощью главного сертификата, хранящегося в Azure Key Vault, и поворачиваются каждый месяц.

Ограничения

Ресурс Ограничение
Максимальное количество поставщиков учетных данных на экземпляр службы 1,000
Максимальное количество подключений на поставщика учетных данных 10 000
Максимальное количество политик доступа на подключение 100
Максимальное количество запросов авторизации в минуту на подключение 250

Вопросы и ответы

Когда обновляются токены доступа?

Для подключения кода авторизации типа маркеры доступа обновляются следующим образом: когда get-authorization-context политика выполняется во время выполнения, Управление API проверяет, является ли сохраненный маркер доступа допустимым. Если срок действия токена истек или скоро истечет, служба управления API использует токен обновления для получения нового токена доступа и нового токена обновления из настроенного поставщика удостоверений. Если срок действия маркера обновления истек, возникает ошибка, и подключение должно быть повторно авторизовано, прежде чем оно будет работать.

Что будет, если срок действия секрета клиента у поставщика удостоверений истёк?

Во время выполнения система управления API не может получить новые токены, и возникает ошибка.

  • Если подключение имеет код авторизации типа, необходимо обновить секрет клиента на уровне поставщика учетных данных.

  • Если подключение имеет тип учетных данных клиента, необходимо обновить секрет клиента на уровне подключения.

Поддерживается ли эта функция при использовании службы управления API, запущенной в виртуальной сети?

Да, если исходящее подключение через порт 443 включено в тег службы AzureConnectors . Более подробную информацию можно найти в разделе Справочник по конфигурации виртуальной сети.

Что происходит при удалении поставщика учетных данных?

Все базовые подключения и политики доступа также удаляются.

Кэширует ли служба управления API токены доступа?

На классических и v2 уровнях службы маркер доступа кэшируется экземпляром управления API за 3 минуты до истечения срока действия маркера. Если до истечения срока действия маркера доступа остаётся меньше 3 минут, кэшированное время будет рассчитано до истечения срока действия маркера доступа.

Маркеры доступа не кэшируются на уровне потребления.

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