Аутентификация

Статья
07/24/2024

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

Типы проверки подлинности

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

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

Проверка подлинности ключа доступа

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

В этом методе проверки подлинности запросы подписываются с помощьюпроверки подлинности на основе хэша кода проверки подлинности сообщений (HMAC).

Прежде чем приступить к работе, убедитесь, что у вас есть:

Ключ доступа к службам коммуникации Azure
Конечная точка службы коммуникации Azure
Путь URL-адреса и вызываемая команда HTTP
Среда разработки, которая может создавать хэши HMACs, SHA256 и выполнять операции Base64.

После получения этих элементов вы можете продолжить подписывание запроса.

Подписывание HTTP-запроса

Убедитесь, что доступны следующие значения:
- Метод HTTP-запроса (например, GET или PUT)
- Метка времени универсального времени (UTC) для запроса в соответствии со стандартом RFC1123
- Узел HTTP-запроса (компонент URI <authority>, указанный в RFC2396)
- Хэш текста HTTP-запроса с помощью алгоритма SHA256
- Путь HTTP-запроса (<path> и <query> сцеплены компонентами ?, как указано в RFC2396)
```
Verb=<http_method>
Timestamp=<current_datetime>
Host=<uri_authority>
ContentHash=SHA256(<request_body>)
URIPathAndQuery=<uri_path>?<uri_query>
```
Создайте строку для подписи, сцепляя значения следующим образом:
```
StringToSign=Verb + "\n"
URIPathAndQuery + "\n"
Timestamp + ";" + Host + ";" + ContentHash
```
Создайте подпись HMAC-256 в кодировке UTF-8, созданной на предыдущем шаге. Затем закодируйте результаты как Base64. Кроме того, необходимо декодировать ключ доступа в Base64. Используйте следующий формат (показан как псевдокод):
```
Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_access_key>)))
```

Добавьте в запрос следующие заголовки:

x-ms-date: <Timestamp>
x-ms-content-sha256: <ContentHash>
host: <URIPathAndQuery>   
Authorization: "HMAC-SHA256 SignedHeaders=x-ms-date;host;x-ms-content-sha256&Signature=<Signature>"

После получения запроса служба проверяет подпись и метку времени для защиты от определенных атак безопасности, включая атаки воспроизведения. Чтобы узнать, как подписать HTTP-запрос на различных языках программирования, ознакомьтесь с руководством по подписи заголовков HMAC.

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

Платформа Azure предоставляет доступ на основе ролей (Azure RBAC) для управления доступом к ресурсам. Субъект безопасности Azure RBAC представляет пользователя, группу, субъект-службу или управляемое удостоверение, запрашивающее доступ к ресурсам Azure.

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

Azure RBAC включает в себя множество встроенных ролей, их можно назначать в разных областях и создавать собственные пользовательские роли. Она включает более 100 встроенных ролей. Существует пять основных ролей Azure — владелец, участник, читатель, администратор управления доступом на основе ролей и администратор доступа пользователей. Дополнительные сведения об этих ролях см. в руководстве по управлению доступом на основе ролей.

Разрешения, поддерживаемые службами коммуникации Azure (ACS)

ACS предлагает определенные разрешения (acs.read и acs.write), которые позволяют управлять доступом к различным ресурсам.

разрешение acs.read: предоставляет возможность получения или просмотра данных.
разрешение acs.write: разрешает изменение или создание данных в тех же типах ресурсов.

Кроме того, ACS поддерживает разрешения, связанные с электронной почтой:

acs.email.read: включает чтение или доступ к данным служб, связанных с электронной почтой.
acs.email.write: позволяет изменять или создавать данные служб, связанных с электронной почтой.

Эти разрешения важны для обеспечения детального контроля доступа и безопасности ресурсов ACS.

Получение дополнительного маркера RBAC

Чтобы получить маркер для ACS, можно использовать MSAL (библиотека проверки подлинности Майкрософт). Ниже приведено пошаговое руководство.

Регистрация приложения в Azure AD. Убедитесь, что ваше приложение зарегистрировано в Azure AD.
Установите MSAL: установите библиотеку MSAL для платформы (например, Microsoft.Identity.Client для .NET).
Настройка MSAL: настройте MSAL с идентификатором клиента, идентификатором клиента и секретом клиента приложения.
Получение маркера: используйте MSAL для получения маркера с необходимой областью (https://communication.azure.com/.default).

Подробные инструкции и примеры кода см. в официальной документации ПО MSAL и документации по маркеру доступа.

Пример HTTP-запроса для выдачи маркера доступа ACS

Просьба:

POST https://my-resource.communication.azure.com/identities/{identity}/:issueAccessToken?api-version=2023-10-01
Authorization: Bearer <your-access-token>
Content-Type: application/json
{
  "scopes": [
    "chat",
    "voip"
  ]
}

Ответ:

{
  "token": "token",
  "expiresOn": "2023-10-10T21:39:39.3244584+00:00"
}

Полезные ссылки на Azure RBAC

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

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

Создание и получение маркеров доступа пользователей

Маркеры доступа пользователей создаются вами в доверенной среде. Создание их с помощью пакета SDK удостоверений Служб коммуникации Azure — самый простой способ. Дополнительные сведения см. в создании маркеров доступа пользователей и управлении ими.

Использование маркера доступа пользователя в запросе

Получив подходящий маркер доступа пользователей, вы можете включить его в запросы к REST API служб коммуникации Azure. Для этого необходимо предоставить его в заголовке Authorization с помощью схемы проверки подлинности Bearer HTTP Authorization: Bearer <token>.

См. также

Дополнительные сведения о проверке подлинности Служб коммуникации Azure также можно просмотреть:

подписать HTTP-запрос.
документации по концептуальной проверке подлинности. Предоставляет сведения об использовании пакетов SDK для проверки подлинности в ИНТЕРФЕЙСах REST API.
создание службы маркеров доступа пользователей . Руководство по Службам коммуникации Azure, в котором показано, как создать надежную службу проверки подлинности для создания маркеров доступа пользователей с помощью функций Azure.

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