Authentification

Lorsque vous effectuez des appels REST, plusieurs étapes sont nécessaires pour s’authentifier correctement. Les kits SDK Azure Communication Services gèrent ce processus pour vous, mais les demandes effectuées manuellement signifient que vous devez le gérer vous-même.

Types d’authentification

Azure Communication Services a trois types d’authentification, ils sont utilisés à des fins différentes :

  • l’authentification par clé d’accès pour les opérations de sms, de traversée réseau, d’automatisation des appels, d’identité et de jeton d’accès. L’authentification par clé d’accès convient aux applications s’exécutant dans un environnement de service approuvé.
  • l’authentification RBAC Azure pour contrôler l’accès aux ressources en tirant parti d’Azure RBAC en attribuant des rôles Azure.
  • l’authentification par jeton d’accès utilisateur pour conversation et appel. Les jetons d’accès utilisateur permettent à vos applications clientes de s’authentifier directement auprès d’Azure Communication Services. Ces jetons sont générés sur un service d’approvisionnement de jetons côté serveur que vous créez. Ils sont ensuite fournis aux appareils clients qui utilisent le jeton pour initialiser les bibliothèques clientes chat et appelant.

Authentification par clé d’accès

L’authentification par clé d’accès est utilisée lorsque les demandes ne sont pas effectuées par votre application utilisateur final. Exécutez ces requêtes dans un environnement de service approuvé.

Dans cette méthode d’authentification, les requêtes sont signées à l’aide d’un code d’authentification de message basé sur le hachage (HMAC) généré par le client.

Avant de commencer, vérifiez que vous disposez des points suivants :

  • Votre clé d’accès Azure Communication Services
  • Votre point de terminaison Azure Communication Service
  • Chemin d’URL et verbe HTTP que vous appelez
  • Un environnement de développement, qui peut générer des HMACs, des hachages SHA256 et effectuer des opérations Base64.

Une fois que vous avez ces éléments, vous pouvez continuer à signer votre demande.

Signature d’une requête HTTP

  1. Vérifiez que les valeurs suivantes sont disponibles :

    • Méthode de requête HTTP (par exemple, GET ou PUT)
    • Horodatage UTC coordonné pour la requête en fonction de la norme RFC1123
    • Hôte de requête HTTP (composant URI <authority> tel que spécifié dans RFC2396)
    • Hachage du corps de la requête HTTP à l’aide de l’algorithme SHA256
    • Chemin de requête HTTP (<path> et <query> concaténés par des composants ? comme spécifié dans RFC2396)
    Verb=<http_method>
    Timestamp=<current_datetime>
    Host=<uri_authority>
    ContentHash=SHA256(<request_body>)
    URIPathAndQuery=<uri_path>?<uri_query>
    
  2. Construisez la chaîne à signer en concaténant les valeurs de la manière suivante :

    StringToSign=Verb + "\n"
    URIPathAndQuery + "\n"
    Timestamp + ";" + Host + ";" + ContentHash
    
  3. Générez une signature HMAC-256 de la chaîne encodée UTF-8 que vous avez créée à l’étape précédente. Ensuite, encodez vos résultats en base64. Vous devez également décoder votre clé d’accès en base64. Utilisez le format suivant (illustré sous forme de pseudo-code) :

    Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_access_key>)))
    
  4. Ajoutez les en-têtes suivants à la requête :

    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>"
    

Lors de la réception de la demande, le service valide la signature et l’horodatage pour se protéger contre certaines attaques de sécurité, y compris les attaques de relecture. Pour savoir comment signer la requête HTTP dans différents langages de programmation, consultez le didacticiel de signature d’en-tête HMAC .

Authentification RBAC Azure

La plateforme Azure fournit un accès en fonction du rôle (RBAC Azure) pour contrôler l’accès aux ressources. Le principal de sécurité RBAC Azure représente un utilisateur, un groupe, un principal de service ou une identité managée qui demande l’accès aux ressources Azure.

L’authentification Microsoft Entra offre une sécurité et une facilité d’utilisation supérieures sur d’autres options d’autorisation. Par exemple, à l’aide de l’identité managée, vous évitez d’avoir à stocker votre clé d’accès de compte dans votre code, comme vous le faites avec l’authentification par clé d’accès. Bien que vous puissiez continuer à utiliser l’authentification par clé d’accès avec des applications de services de communication, Microsoft recommande de passer à l’ID Microsoft Entra, le cas échéant.

Azure RBAC inclut de nombreux rôles intégrés, peuvent être attribués à différentes étendues et vous permettent de créer vos propres rôles personnalisés. Il comprend plus de 100 rôles intégrés. Il existe cinq rôles Azure fondamentaux : Propriétaire, Contributeur, Lecteur, Administrateur de contrôle d’accès en fonction du rôle et Administrateur de l’accès utilisateur. Pour plus d’informations sur ces rôles, consultez le didacticiel sur le contrôle d’accès en fonction du rôle.

Autorisations prises en charge par Azure Communication Services (ACS)

ACS offre des autorisations spécifiques (acs.read et acs.write) qui autorisent l’accès contrôlé à diverses ressources.

  • autorisation acs.read : accorde la possibilité de récupérer ou d’afficher des données.
  • autorisation acs.write : autorise la modification ou la création de données au sein de ces mêmes types de ressources.

En outre, ACS prend en charge les autorisations liées à l’e-mail :

  • acs.email.read : permet de lire ou d’accéder aux données des services liés à l’e-mail.
  • acs.email.write : autorise la modification ou la création de données de services liés à l’e-mail.

Ces autorisations sont essentielles pour garantir le contrôle d’accès granulaire et la sécurité sur les ressources ACS.

Obtention d’un jeton RBAC supplémentaire

Pour acquérir un jeton pour ACS, vous pouvez utiliser MSAL (Bibliothèque d’authentification Microsoft). Voici un guide pas à pas :

  1. Inscrire une application dans Azure AD : vérifiez que votre application est inscrite dans Azure AD.
  2. Installez MSAL : installez la bibliothèque MSAL pour votre plateforme (par exemple, Microsoft.Identity.Client pour .NET).
  3. Configurez MSAL : configurez MSAL avec l’ID client, l’ID de locataire et la clé secrète client de votre application.
  4. Acquérir un jeton : utilisez MSAL pour acquérir un jeton avec l’étendue nécessaire (https://communication.azure.com/.default).

Pour obtenir des instructions détaillées et des exemples de code, reportez-vous à la documentation msAL officielle et documentation sur le jeton d’accès.

Exemple de requête HTTP pour émettre un jeton d’accès ACS

Demander:

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"
  ]
}

Réponse:

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

Authentification par jeton d’accès utilisateur

Les jetons d’accès utilisateur permettent à vos applications clientes de s’authentifier directement auprès d’Azure Communication Services en tant qu’utilisateur ou identité particulier.

Génération / obtention d’un jeton d’accès utilisateur

Les jetons d’accès utilisateur sont générés par vous dans un environnement approuvé. Les générer à l’aide du Kit de développement logiciel (SDK) Azure Communication Services Identity est le moyen le plus simple. Pour plus d’informations, consultez création et gestion des jetons d’accès utilisateur.

Utilisation d’un jeton d’accès utilisateur dans une requête

Une fois que vous disposez d’un jeton d’accès utilisateur approprié, vous pouvez l’inclure dans vos demandes à l’API REST d’Azure Communication Services. Pour ce faire, vous devez le fournir dans l’en-tête Authorization à l’aide du schéma d’authentification HTTP du porteur Authorization: Bearer <token>.

Voir aussi

Pour plus d’informations sur l’authentification Azure Communication Services, vous pouvez également consulter :