Типы аутентификации

ОБЛАСТЬ ПРИМЕНЕНИЯ: ПАКЕТ SDK версии 4

В Bot Framework существуют две широкие категории проверки подлинности: проверка подлинности бота и проверка подлинности пользователей. Каждый из них имеет связанный маркер , чтобы разрешить доступ к защищенным ресурсам. На следующем рисунке показаны элементы, участвующие как в боте, так и в проверке подлинности пользователей.

На этом рисунке:

• Платформа узла — это платформа размещения ботов. Она может быть Azure или любой выбранной платформой узла.
• Служба бота Подключение or упрощает взаимодействие между ботом и каналом. Он преобразует сообщения, полученные из каналов в объекты действий, и отправляет их в конечную точку обмена сообщениями бота. Аналогичным образом он преобразует объекты действий, полученные от бота, в сообщения, понятные каналом, и отправляет их в канал.
• Адаптер Bot — это адаптер Bot Framework по умолчанию. Это:
  • Преобразует полезные данные JSON в объект действия.
  • Создает контекст поворота и добавляет в него объект действия.
  • Выполняет по промежуточному слоям, если таковые есть.
  • Перенаправит контекст поворота боту.

Примечание.

При использовании пользовательского адаптера канала сам адаптер выполняет задачи, выполняемые службой Бота Подключение or и адаптером бота по умолчанию. Кроме того, он предоставляет механизм проверки подлинности для связанного API веб-перехватчика. Пример см. в разделе Подключение бота в Slack с помощью адаптера Slack.

Проверка подлинности бота

Бот определяется его MicrosoftAppID и MicrosoftAppPassword, которые хранятся в файлах параметров бота (appsettings.json.NET), (JavaScript), config.py.env (Python)) или в секретах или диспетчере ключей. Дополнительные сведения см. в разделе MicrosoftAppID и MicrosoftAppPassword.

При регистрации бота в портал Azure Azure создает приложение регистрации идентификатора Microsoft Entra. Если вы используете интерфейс командной строки Bot Framework, необходимо специально выполнить шаг, чтобы создать регистрацию идентификатора Записи Майкрософт. Эта регистрация имеет идентификатор приложения (MicrosoftAppID) и секрет клиента (MicrosoftAppPassword). Azure использует эти значения для создания маркера, с помощью которого бот может получить доступ к защищенным ресурсам.

Когда канал отправляет запрос боту через службу Бота Подключение or, он указывает маркер в заголовке авторизации запроса. Бот выполняет проверку подлинности вызовов из службы бота Подключение or, проверяя подлинность маркера.

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

Описанные операции автоматически выполняются пакетом SDK Bot Framework.

Дополнительные сведения см. в документации по REST API по проверке подлинности запросов из службы Бота Подключение or в бот и аутентификации запросов от бота к службе бота Подключение or.

Каналы

Как правило, каналы взаимодействуют с ботом через службу бота Подключение or, поэтому предыдущие принципы проверки подлинности обычно применяются. Некоторые каналы и функции имеют уникальные рекомендации по проверке подлинности.

Direct Line

Помимо стандартных поддерживаемых каналов клиентское приложение может взаимодействовать с ботом с помощью канала Direct Line.

Клиентское приложение выполняет проверку подлинности запросов к Direct Line (версии 3.0) с помощью секрета, полученного на странице конфигурации канала Direct Line в портал Azure или, лучше, используя маркер, полученный во время выполнения. Секрет или маркер указываются в заголовке авторизации каждого запроса.

Важно!

При использовании проверки подлинности Azure AI Служба Bot с Веб-чат необходимо учитывать некоторые важные аспекты безопасности. См. сведения о безопасности в руководстве по проверке подлинности REST.

Дополнительные сведения см. в статье "Сохранить секрет скрытым", обменять секрет на токен и создать внедрение.

Веб-чат.

Веб-чат имеет две реализации: канал и элемент управления.

• При регистрации бота в Azure канал Веб-чат автоматически настраивается для разрешения тестирования бота. Дополнительные сведения см. в разделе Подключение бота для Веб-чат.
• С помощью канала Direct Line можно использовать элемент управления Веб-чат для предоставления доступа к боту в клиентском приложении. Дополнительные сведения об элементе управления см. в Веб-чат Bot Framework.

Навыки

Навык и потребитель навыка — это два разных бота, каждый из которых имеет собственный идентификатор приложения и пароль.

• Потребитель может пересылать действия пользователей в навык и пересылать ответы навыка пользователю.
• Для навыка потребитель навыка выступает в качестве канала. Потребитель имеет конечную точку узла навыка, которая выступает в качестве URL-адреса службы, в которую навык отправляет действия.
• Дополнительные сведения о навыках см. в обзоре навыков.

Проверка подлинности на уровне службы выполняется службой Bot Connector. Эта платформа использует токены носителя и идентификаторы приложения бота для идентификации каждого бота.

Важно!

Для этого требуется, чтобы все боты (потребитель навыков и все необходимые навыки) имели допустимые учетные данные приложения.

Проверка утверждений

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

Пример проверки утверждений см. в статье о реализации навыка и реализации потребителя навыка.

Bot Framework Emulator

Эмулятор Bot Framework имеет собственный поток проверки подлинности и собственные маркеры. Эмулятор имеет собственный канал и встроенный сервер.

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

Иногда бот должен получать доступ к защищенным онлайн-ресурсам от имени пользователя. Для этого боту необходимо авторизоваться. Это связано с тем, что для выполнения определенных операций, таких как проверка электронной почты, проверка состояния полета или размещение заказа, бот должен вызвать внешнюю службу, например Microsoft Graph, GitHub или службу REST компании. OAuth используется для проверки подлинности пользователя и авторизации бота.

Примечание.

Два макроса используются для бота для доступа к ресурсам пользователя.

1. Проверка подлинности. Процесс проверки удостоверения пользователя.
2. Авторизация. Процесс проверки того, что бот может получить доступ к ресурсам пользователя.

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

Дополнительные сведения см. в разделе "Проверка подлинности пользователей".

Поставщики удостоверений

Поставщик удостоверений выполняет проверку подлинности удостоверений пользователя или клиента и выдает одноразовые маркеры безопасности. Он предоставляет проверку подлинности пользователей как услугу. Клиентские приложения, например веб-приложения, делегируют аутентификацию доверенному поставщику удостоверений.

Бот может использовать доверенный поставщик удостоверений для:

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

Примечание.

Маркер, выданный во время проверки подлинности Бота, не совпадает с маркером, выданным во время проверки подлинности пользователя. Первый используется для обеспечения безопасного взаимодействия между ботом, каналами и, в конечном счете, клиентскими приложениями. Второй используется для авторизации бота для доступа к защищенному ресурсу от имени пользователя.

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

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