Сведения об учетных данных 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.

  • Платформа «Устойчивые функции» становится на шаг ближе к «Logic Apps» благодаря подключению SaaS.

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

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

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

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

  • Часть среды выполнения использует get-authorization-context политику для получения и хранения токенов доступа и обновления подключения. Когда вызов поступает в API Management и политика 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, работающего в виртуальной сети?

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

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

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

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

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

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

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

  • Last updated on