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

Сведения об учетных данных 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, субъектам-службам, пользователям или группам. Общие сведения о потоке кода авторизации 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 может выступать в качестве настраиваемого соединителя 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. Для использования такого подключения разные пользователи могут войти в клиентское приложение, например статичное веб-приложение, которое затем вызывает внутренний API, предоставляемый через Управление API. Чтобы сделать этот вызов, подключения применяются с помощью get-authorization-context политики. Так как вызов API использует предварительно настроенное подключение, которое не связано с контекстом пользователя, то одни и те же данные возвращаются всем пользователям.

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

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

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

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

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

Требования

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

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

Availability

  • Все уровни служб Управление 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 токены доступа?

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

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

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