Модель удостоверений

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

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

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

Удостоверение пользователя и сопоставление

При создании удостоверения пользователя с помощью пакета SDK или REST API Службы коммуникации Azure создает уникальный идентификатор пользователя. Внешние идентификаторы, такие как номера телефонов, идентификаторы пользователей или приложений или имена пользователей, нельзя использовать непосредственно в Службы коммуникации Azure. Вместо этого необходимо использовать удостоверения служб коммуникации и поддерживать сопоставление с собственной системой идентификаторов пользователя по мере необходимости. Создание удостоверений пользователей Службы коммуникации Azure является бесплатным и плата взимается только в том случае, если пользователь использует модальности связи, например чат или звонок. Использование созданного удостоверения Служб коммуникации зависит от вашего сценария. Например, можно сопоставить удостоверение 1:1, 1:N, N:1 или N:N, а также использовать его для пользователей или приложений. Пользователь может участвовать в нескольких сеансах связи, одновременно используя несколько устройств. Управление сопоставлением между удостоверениями пользователей Службы коммуникации Azure и собственной системой удостоверений является вашей ответственностью в качестве разработчика и не входит в систему. Например, можно добавить CommunicationServicesId столбец в существующую таблицу пользователей для хранения связанного удостоверения Службы коммуникации Azure. Схема сопоставления подробно описана в разделе "Архитектура сервера клиента".

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

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

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

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

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

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

• chat
• chat.join
• chat.join.limited

Возможность / область маркера	чат	chat.join	chat.join.limited
Создание потока чата	Y	N	N
Обновление потока чата с идентификатором	Y	N	N
Удаление потока чата с идентификатором	Y	N	N
Добавление участника в поток чата	Y	Y	N
Удаление участника из потока чата	Y	Y	N
Получение потоков чата	Y	Y	Y
Получение потока чата с идентификатором	Y	Y	Y
Получение ReadReceipt	Y	Y	Y
Создание ReadReceipt	Y	Y	Y
Создание сообщения для потока чата с идентификатором	Y	Y	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 InProgress	Y	Y
Присоединение вызова VoIP InProgress в виртуальных комнатах, когда пользователь уже приглашен в комнату	Y	Y
Все остальные операции вызова, такие как отключение или отключение звука, общий доступ к экрану и т. д.	Y	Y
Все другие операции в вызове, такие как отключение и отключение звука, общий доступ к экрану и т. д. в виртуальных комнатах.	Определяется ролью пользователя	Определяется ролью пользователя

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

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

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

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

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

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

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

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

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

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

• Сведения о том, как выдавать маркеры, см. в статье "Создание маркеров доступа и управление ими".
• Общие сведения о проверке подлинности см. в статье Аутентификация в Службах коммуникации Azure.
• Дополнительные сведения о местонахождении данных и конфиденциальности см. в разделе "Доступность и расположение данных в регионе".
• Сведения о быстром создании удостоверений и маркеров для тестирования см. в кратком руководстве по созданию удостоверений.
• Полный пример простой службы управления удостоверениями см. в руководстве по доверенной службе.
• Для более расширенного примера управления удостоверениями, который интегрируется с идентификатором Записи и Microsoft Graph, перейдите к примеру героя службы проверки подлинности.