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

Модель идентификации

  • Статья

Службы коммуникации Azure — это служба, независимая от идентификации, которая предлагает несколько преимуществ:

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

Модель идентификации в службах коммуникации Azure работает с двумя ключевыми понятиями.

Личность пользователя / сопоставление

Службы коммуникации Azure создают уникальный идентификатор пользователя при создании удостоверения пользователя с помощью пакета SDK или REST API. Нельзя использовать внешние идентификаторы, такие как номера телефонов, идентификаторы пользователей и устройств или приложений или имена пользователей непосредственно в Службах коммуникации Azure. Вместо этого необходимо использовать удостоверения служб коммуникации и поддерживать сопоставление с собственной системой идентификаторов пользователя по мере необходимости.

Вы можете бесплатно создавать удостоверения пользователей Службы коммуникации Azure. Только плата взимается, если пользователь использует службы коммуникации, такие как чат или звонок. Использование созданного удостоверения Служб коммуникации зависит от вашего сценария. Например, можно сопоставить идентификатор 1:1, 1:N, N:1 или N:N, а также использовать его для пользователей-человек или приложений. Конечный пользователь может участвовать в нескольких сеансах обмена данными с несколькими устройствами одновременно.

Управление сопоставлением между удостоверениями пользователей Службы коммуникации Azure и собственной системой удостоверений является вашей ответственностью в качестве разработчика и не предоставляется по умолчанию. Например, можно добавить столбец CommunicationServicesId в существующую таблицу пользователей для хранения связанного идентификатора Служб коммуникации Azure. Схема сопоставления подробно описана в разделе "Архитектура сервера клиента".

Маркеры доступа

После создания удостоверения пользователя конечному пользователю необходимо получить токен доступа с определенными правами для участия в коммуникациях через чат или звонки. Например, только пользователь с маркером chat области может участвовать в чате. Только пользователь с маркером voip области может участвовать в вызове VoIP.

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

Недвижимость Описание
Тема Идентификация пользователя, представленная токеном.
Истечение срока действия Маркер доступа действителен по крайней мере на 1 час и до 24 часов. После истечения срока действия маркер доступа является недопустимым и не может использоваться для доступа к службе. Чтобы создать маркер с настраиваемым сроком действия, укажите нужную действительность в минутах (>=60, <1440). По умолчанию маркер действителен в течение 24 часов. Мы рекомендуем использовать токены с коротким сроком действия для отдельных собраний и токены с более длительным сроком действия для пользователей, которым требуется ваше приложение в течение длительного времени.
Области Области определяют, к каким службам (Chat/VoIP) можно получить доступ с помощью токена.

Маркер доступа — это веб-токен JSON (JWT) и имеет защиту целостности. То есть его утверждения не могут быть изменены без недопустимого маркера доступа, так как подпись маркера больше не совпадает. Если примитивы связи используются с недопустимыми маркерами, доступ запрещен. Несмотря на то, что токены не шифруются или не обфусцируются, ваше приложение не должно зависеть от формата токена или его утверждений. Формат токена может измениться и не является частью официального контракта API. Службы коммуникации Azure поддерживают следующие области для маркеров доступа.

Области маркера чата

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

  • chat
  • chat.join
  • chat.join.limited
Возможность / область маркера chat chat.join chat.join.limited
Создание потока чата Y N N
Обновление темы чата с идентификатором Y N N
Удаление темы чата с ID Й N N
Добавление участника в поток чата Y Y N
Удаление участника из потока чата Y Y N
Получить темы чата Y Y Y
Получить поток чата с идентификатором Y Y Y
Получение подтверждения о прочтении Y Y Y
Создание ReadReceipt Y Y Y
Создание сообщения для потока чата с идентификатором Y И Y
Получение сообщения с идентификатором сообщения Y Y У
Обновление собственного сообщения с идентификатором сообщения У Y Да
Удалите свое собственное сообщение с идентификатором сообщения Y Y Y
Отправить индикатор ввода текста Y Y Y
Получение участника для идентификатора потока Y Y И

Области токенов VoIP

Модель идентификации поддерживает две области применимости токенов VoIP. Разрешения для каждой области описаны в следующей таблице.

  • voip
  • voip.join
Возможность / сфера действия токена voip voip.join
Запуск вызова VoIP Y N
Запустите вызов VoIP в виртуальных комнатах, когда пользователь уже приглашен в комнату Y Y
Присоединитесь к текущему вызову VoIP Y Y
Присоединитесь к вызову VoIP InProgress в виртуальных комнатах, если вас уже пригласили в комнату. Y Y
Все другие операции в вызове, такие как отключение и включение звука, общий доступ к экрану и т. д. Й Y
Все другие операции в вызове, такие как отключение и отключение звука, общий доступ к экрану и т. д., в виртуальных комнатах Определяется ролью пользователя Определяется ролью пользователя

Область voip.join можно использовать вместе с комнатами для создания запланированного вызова. В этом сценарии только приглашенные пользователи получают доступ и пользователи запрещены создавать другие вызовы.

Отзыв или обновление маркера доступа

  • Библиотеку удостоверений службы коммуникации Azure можно использовать для аннулирования токена доступа до истечения срока его действия. Отзыв токена не производится немедленно. Для распространения может потребоваться до 15 минут.
  • Удаление удостоверения, ресурса или подписки отменяет все токены доступа.
  • Если вы хотите удалить возможность доступа пользователя к определенным функциям, отмените все маркеры доступа для пользователя. Затем выдайте новый маркер доступа с ограниченным набором областей.
  • Смена ключей доступа отменяет все активные маркеры доступа, созданные с помощью бывшего ключа доступа. Поэтому все удостоверения теряют доступ к Службам коммуникации Azure и нуждаются в новых маркерах доступа.

Архитектура клиентского сервера

Создавайте маркеры доступа пользователей и управляйте ими с помощью доверенной службы, а не создавайте маркеры в клиентском приложении. Для создания токенов доступа пользователей требуется строка подключения или учетные данные Microsoft Entra. Не забудьте защитить учетные данные, передача которых клиенту может привести к утечке секрета. Сбой правильного управления маркерами доступа может привести к дополнительным расходам на ресурс, когда маркеры предоставляются свободно и неправильно используются кем-либо другим.

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

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

Схема, демонстрирующая архитектуру маркера доступа пользователей.

  1. Пользователь запускает клиентское приложение.
  2. Клиентское приложение обращается к службе управления удостоверениями.
  3. Служба управления удостоверениями проверяет подлинность пользователя приложения. Вы можете пропустить проверку подлинности в сценариях, где пользователь является анонимным, но будьте осторожны и добавьте другие защитные меры, такие как ограничение скорости и CORS, в вашу службу для предотвращения злоупотребления токенами.
  4. Создайте или найдите удостоверение служб коммуникации для пользователя.
    1. Стабильный сценарий идентификации: служба управления удостоверениями поддерживает сопоставление удостоверений приложений и удостоверений служб коммуникации. (Удостоверения приложений включают пользователей и другие адресные объекты, такие как службы или боты.) Если удостоверение приложения является новым, создается новое удостоверение связи и сохраняется сопоставление.
    2. Эфемерный сценарий идентификации: служба управления удостоверениями создает новое удостоверение для связи. В этом сценарии один и тот же пользователь получает другое удостоверение связи для каждого сеанса.
  5. Служба управления удостоверениями выдает маркер доступа пользователя для соответствующего удостоверения и возвращает его клиентскому приложению.

Приложения Azure App Service и Azure Functions являются двумя альтернативами для функционирования службы управления удостоверениями. Эти службы легко масштабируется и имеют встроенные функции для проверки подлинности пользователей. Они интегрированы с OpenID и сторонними поставщиками удостоверений, такими как Facebook.

Следующие шаги