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

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

• Внедрение собственной модели удостоверений (BYOI) позволяет повторно использовать существующие удостоверения из системы управления удостоверениями и сопоставлять их с удостоверениями Служб коммуникации Azure.
• Хорошо работает с любой существующей системой удостоверений и не зависит от конкретного поставщика удостоверений.
• Сохраняйте данные пользователя, такие как их имя, частные, так как не нужно дублировать их в Службы коммуникации Azure.
• Организации, использующие Microsoft Entra ID для управления идентификацией и доступом, теперь могут получить доступ к ресурсам Azure Communication Services напрямую с пользователями Microsoft Entra ID. Эта новая поддержка аутентификации с Entra ID устраняет необходимость разработки или эксплуатации собственной службы управления идентификацией или прокси-службы авторизации. Эта функция сейчас доступна в общедоступной предварительной версии.

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

Принести собственное удостоверение (BYOI): интеграция с системой управления удостоверениями

Службы коммуникации Azure поддерживают модель переноса собственного идентификатора (BYOI), что позволяет интегрироваться с существующей системой управления идентификацией. Вы можете создать удостоверения пользователей в Службах коммуникации Azure и сопоставить их с собственной системой удостоверений пользователя. Этот подход позволяет управлять удостоверениями пользователей и маркерами доступа без дублирования данных пользователей в Службах коммуникации Azure.

** В следующих разделах вас направят через ключевые концепции модели использования собственной идентификации (BYOI):

• Как сопоставить удостоверения пользователей: сопоставление удостоверений пользователей в модели принеси своё удостоверение (BYOI).
• Создание маркеров доступа и управление ими: маркеры доступа.
• Как реализовать клиент-серверную архитектуру для управления удостоверениями: клиент-серверная архитектура для модели удостоверений на основе собственной идентификации (BYOI).

Сопоставление удостоверений пользователя в модели «Используй свою идентификацию» (BYOI)

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

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

Управление сопоставлением между удостоверениями пользователей Службы коммуникации Azure и собственной системой удостоверений является вашей ответственностью в качестве разработчика и не предоставляется по умолчанию. Например, можно добавить столбец CommunicationServicesId в существующую таблицу пользователей для хранения связанного идентификатора Служб коммуникации Azure. Подробное описание разработки сопоставления находится в разделе «Клиент-серверная архитектура для модели «принеси своё собственное удостоверение» (BYOI).

(Предварительная версия) Упрощение сопоставления идентификаций с помощью customId

Ранее разработчики отвечали за поддержание сопоставления между собственной системой удостоверений пользователей и удостоверениями Служб коммуникации Azure. Введя параметр customId, теперь можно связать собственные идентификаторы пользователей, такие как адреса электронной почты или внутренние идентификаторы пользователей, непосредственно во время создания удостоверения служб коммуникации.

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

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

Токены доступа

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

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

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

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

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

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

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

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

• voip
• voip.join

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

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

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

Клиент-серверная архитектура для модели «принеси собственное удостоверение» (BYOI)

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

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

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

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

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

Microsoft Entra ID: интеграция с Entra ID

Службы коммуникации Azure теперь поддерживают аутентификацию с помощью Microsoft Entra ID, позволяя вам получать доступ к ресурсам Служб коммуникации Azure непосредственно через пользователей Entra ID. Эта новая поддержка аутентификации с помощью Entra ID устраняет необходимость разработки или эксплуатации собственной службы управления удостоверениями или прокси-службы авторизации, упомянутых в разделе «Архитектура клиента-сервера».

В следующих разделах описаны основные аспекты интеграции идентификатора Microsoft Entra ID.

• Как получить маркеры доступа и управлять ими: маркеры доступа с помощью идентификатора Microsoft Entra.
• Реализация клиентской архитектуры с помощью идентификатора Microsoft Entra: архитектура клиента для идентификатора Microsoft Entra.
• Текущие ограничения и рекомендуемые рекомендации. Ограничения.

Токены доступа с идентификатором Microsoft Entra ID

Поддерживаются только маркеры доступа к Службам коммуникации Azure для проверки подлинности и авторизации в Службах коммуникации Azure, включая функции чата и звонков. Дополнительные сведения о структуре маркеров и управлении ими см. в разделе "Маркеры доступа". Во время открытого предварительного просмотра Microsoft Entra ID, только области маркеров доступа для вызовов (VoIP) поддерживаются посредством интеграции Entra ID.

Интеграция Microsoft Entra ID позволяет выполнять проверку подлинности пользователей с помощью Entra ID, получать токен доступа пользователя Entra ID с разрешениями API для приложения клиентов Служб коммуникации Azure и обменять его на токен доступа к Службам коммуникации Azure. Общие пакеты SDK для Служб коммуникации Azure предлагают простую проверку подлинности, автоматически получая маркер доступа к Службам коммуникации Azure для пользователя Entra ID. Дополнительные сведения о реализации логики с помощью общего пакета SDK служб коммуникации Azure см. в статье "Получение маркеров доступа для пользователей идентификатора Microsoft Entra ID"

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

Маркеры доступа к службам коммуникации Azure выдаются с тем же сроком действия, что и маркер доступа пользователя Идентификатора Microsoft Entra.

Архитектура клиента для идентификатора Microsoft Entra

Интеграция Microsoft Entra ID позволяет упростить архитектуру, непосредственно используя Entra ID для проверки подлинности и авторизации. Ниже описан процесс.

1. Пользователь запускает клиентское приложение.
2. Клиентское приложение проверяет подлинность пользователя с помощью идентификатора Microsoft Entra. Клиентское приложение получает маркер доступа пользователя Entra ID с разрешениями API для приложения клиентов Служб коммуникации Azure.
3. Клиентское приложение получает маркер доступа к Службам коммуникации Azure для пользователя Entra ID с помощью одного из следующих методов:
   • Использование общих SDK служб коммуникации Azure: клиент инициализирует CommunicationTokenCredential с параметрами учетных данных токена Entra ID, которые автоматически обрабатывают получение токена доступа Служб коммуникации Azure для пользователя Entra ID в фоновом режиме. Затем приложение использует эти учетные данные для доступа к API служб коммуникации Azure.
   • Настраиваемая реализация: Клиентское приложение обращается к API обмена токенов Entra ID для получения токена доступа к Службам коммуникации Azure. Затем полученный маркер доступа к службам коммуникации Azure используется для доступа к API Служб коммуникации Azure.

Эта архитектура устраняет необходимость отдельной службы управления удостоверениями, так как идентификатор Microsoft Entra обрабатывает проверку подлинности пользователей и авторизацию напрямую.

Ограничения

Интеграция идентификатора Microsoft Entra в настоящее время находится в предварительной версии и имеет следующие ограничения:

• Непрерывная оценка доступа недоступна. Чтобы немедленно отозвать маркеры доступа, следуйте инструкциям в разделе "Отмена маркеров доступа".
• При удалении пользователя Entra ID связанные данные не удаляются автоматически из ресурса Служб связи. Чтобы убедиться, что все данные удалены, следуйте инструкциям в разделе "Удаление удостоверения".
• Разрешения API чата (сообщений) (Chat, Chat.Join, Chat.Join.Limited) нельзя предоставлять или использовать через интеграцию Microsoft Entra ID в общедоступной предварительной версии. Поддерживаются только разрешения, связанные с VoIP (VoIP, VoIP.Join). Используйте модель идентификации BYOI для получения токенов доступа к чату до генеральной доступности.

Дальнейшие шаги

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