Partager via

Modèle d’identité

Azure Communication Services est un service indépendant de l’identité, qui offre plusieurs avantages :

  • Adoptez un modèle BYOI (Apportez votre propre identité), ce qui vous permet de réutiliser les identités existantes à partir de votre système de gestion des identités et de les mapper avec des identités Azure Communication Services.
  • Fonctionne avec n’importe quel système d’identité existant et n’a aucune dépendance sur un fournisseur d’identité spécifique.
  • Conservez les données de votre utilisateur, telles que leur nom, privé, car vous n’avez pas besoin de le dupliquer dans Azure Communication Services.
  • Les organisations qui utilisent l’ID Microsoft Entra pour la gestion des identités et des accès peuvent désormais accéder aux ressources Azure Communication Services directement avec les utilisateurs de l’ID Entra. Cette nouvelle prise en charge de l’authentification Entra ID élimine la nécessité de développer ou d’exploiter votre propre service proxy d’identité ou d’autorisation. Cette fonctionnalité est actuellement en préversion publique.

Le modèle d’identité Azure Communication Services fonctionne avec deux concepts clés.

Apportez votre propre identité (BYOI) : intégration à votre système de gestion des identités

Azure Communication Services prend en charge un modèle BYOI (Apportez votre propre identité), ce qui vous permet d’intégrer votre système de gestion des identités existant. Vous pouvez créer des identités utilisateur dans Azure Communication Services et les mapper à votre propre système d’identité utilisateur. Cette approche vous permet de gérer les identités utilisateur et les jetons d’accès sans dupliquer les données utilisateur dans Azure Communication Services.

Les sections suivantes vous guident tout au long des concepts clés du modèle BYOI (Apportez votre propre identité) :

Mappage d’identité utilisateur dans le modèle BYOI (Bring Your Own Identity)

Lorsque vous créez une identité d’utilisateur via le Kit de développement logiciel (SDK) ou l’API REST, Azure Communication Services crée un identificateur d’utilisateur unique. Vous ne pouvez pas utiliser d’identificateurs externes tels que des numéros de téléphone, des ID d’utilisateur/appareil/application ou des noms d’utilisateur directement dans Azure Communication Services. Au lieu de cela, vous devez utiliser les identités Communication Services et gérer un mappage avec votre propre système d’ID utilisateur en fonction des besoins.

Vous pouvez créer gratuitement des identités utilisateur Azure Communication Service. Les seuls frais sont facturés lorsque l’utilisateur consomme des services de communication tels qu’une conversation ou un appel. La façon dont vous utilisez votre identité Communication Services générée dépend de votre scénario. Par exemple, vous pouvez mapper une identité 1:1, 1:N, N:1 ou N:N, et vous pouvez l’utiliser pour les utilisateurs humains ou les applications. Votre utilisateur final peut participer simultanément à plusieurs sessions de communication, à l’aide de plusieurs appareils.

La gestion d’un mappage entre les identités utilisateur Azure Communication Services et votre propre système d’identité est votre responsabilité en tant que développeur et n’est pas intégrée. Par exemple, vous pouvez ajouter une colonne CommunicationServicesId dans votre table d’utilisateurs existante pour stocker l’identité Azure Communication Services associée. Une conception de mappage est décrite plus en détail sous l’architecture client-serveur pour le modèle BYOI (Apportez votre propre identité).

(Aperçu) Simplifier le mappage d’identité avec customId

Important

Cette fonctionnalité est disponible à partir de la version du Kit de développement logiciel (SDK) Identity et de la version 1.4.0-beta1 de 2025-03-02-previewl’API REST.

Note

Cette fonctionnalité est actuellement en préversion.

Auparavant, les développeurs étaient responsables de la maintenance d’un mappage entre leur propre système d’identité utilisateur et les identités Azure Communication Services. Avec l’introduction du customId paramètre, vous pouvez désormais associer vos propres identificateurs d’utilisateur, tels que les adresses e-mail ou les ID d’utilisateur internes, directement lors de la création d’une identité Communication Services.

Lorsque vous créez un utilisateur avec un customId, Azure Communication Services retourne la même identité si vous appelez à nouveau la méthode avec le même customId. Cela élimine la nécessité de stocker et de gérer le mappage vous-même.

Cette fonctionnalité est prise en charge dans le Kit de développement logiciel (SDK) et l’API REST, et est particulièrement utile pour les scénarios où vous souhaitez conserver une identité cohérente entre les sessions, les appareils ou les services sans surcharge de stockage supplémentaire.

Jetons d’accès

Une fois que vous avez créé une identité utilisateur, l’utilisateur final a alors besoin d’un jeton d’accès avec des périmètres spécifiques pour participer aux communications par le biais de conversations chat ou d’appels. Par exemple, seul un utilisateur disposant d’un jeton d’étendue chat peut participer au chat. Seul un utilisateur disposant d'un jeton avec l'étendue voip peut participer à un appel VoIP.

Un utilisateur peut avoir plusieurs jetons simultanément. Azure Communication Services prend en charge plusieurs étendues de jetons pour prendre en compte les utilisateurs qui ont besoin d’un accès complet et d’un accès limité. Les jetons d’accès ont les propriétés suivantes.

Property Description
Subject Identité de l’utilisateur représentée par le jeton.
Expiration Un jeton d’accès est valide pendant au moins 1 heure et jusqu’à 24 heures. Une fois expiré, le jeton d’accès n’est pas valide et ne peut pas être utilisé pour accéder au service. Pour créer un jeton avec un délai d’expiration personnalisé, spécifiez la validité souhaitée en minutes (>=60, <1440). Par défaut, le jeton est valide pendant 24 heures. Nous vous recommandons d’utiliser des jetons de durée de vie courte pour des réunions uniques et des jetons de durée de vie plus longs pour les utilisateurs qui ont besoin de votre application pendant des périodes plus longues.
Scopes Les étendues définissent les services (Chat/VoIP) accessibles avec le jeton.

Un jeton d’accès est un JSON Web Token (JWT) et dispose d’une protection d’intégrité. Autrement dit, ses revendications ne peuvent pas être modifiées sans invalider le jeton d’accès, car la signature du jeton ne correspond plus. Si les primitives de communication sont utilisées avec des jetons non valides, l’accès est refusé. Même si les jetons ne sont pas chiffrés ni obfusqués, votre application ne doit pas dépendre du format de jeton ou de ses revendications. Le format de jeton peut changer et ne fait pas partie du contrat d’API officiel. Azure Communication Services prend en charge les étendues suivantes pour les jetons d’accès.

Étendues de jeton de conversation

Le modèle d’identité prend en charge trois étendues de jeton de conversation différentes. Les autorisations pour chaque étendue sont décrites dans le tableau suivant.

  • chat
  • chat.join
  • chat.join.limited
Fonctionnalité/Étendue du jeton chat chat.join chat.join.limited
Créer un fil de conversation Y N N
Mettre à jour le thread de conversation avec l’ID Y N N
Supprimer le thread de conversation avec l’ID Y N N
Ajouter un participant à un fil de conversation Y Y N
Supprimer un participant d’un fil de conversation Y Y N
Répertorier les threads de conversation Y Y Y
Obtenir le thread de conversation avec l’ID Y Y Y
Obtenir ReadReceipt Y Y Y
Créer ReadReceipt Y Y Y
Créer un message pour le fil de discussion avec l’identifiant Y Y Y
Obtenir le message avec l’ID de message Y Y Y
Mettre à jour votre propre message avec l’ID de message Y Y Y
Supprimer votre propre message avec l’ID de message Y Y Y
Envoyer un indicateur de saisie Y Y Y
Obtenir le participant pour l’ID de thread Y Y Y

Étendues de jeton VoIP

Le modèle d'identité prend en charge deux étendues de portée de jeton VoIP. Les autorisations pour chaque étendue sont décrites dans le tableau suivant.

  • voip
  • voip.join
Fonctionnalité/Étendue du jeton voip voip.join
Démarrer un appel VoIP Y N
Démarrez un appel VoIP dans Virtual Rooms lorsque l’utilisateur est déjà invité à la salle Y Y
Rejoindre un appel VoIP en cours Y Y
Rejoindre un appel VoIP en cours dans Virtual Rooms, lorsque l’utilisateur est déjà invité à la salle Y Y
Toutes les autres opérations pendant l'appel telles que couper/rétablir le son, le partage d’écran, etc. Y Y
Toutes les autres opérations en appel telles que activer le micro/désactiver le micro, le partage d’écran et ainsi de suite dans Virtual Rooms Déterminé par le rôle d’utilisateur Déterminé par le rôle d’utilisateur

Vous pouvez utiliser l’étendue voip.join avec Salles pour créer un appel planifié. Dans ce scénario, seuls les utilisateurs invités obtiennent l’accès et les utilisateurs ne sont pas autorisés à créer d’autres appels.

Révoquer ou mettre à jour le jeton d’accès

  • La bibliothèque d’identités Azure Communication Services peut être utilisée pour révoquer un jeton d’accès avant son délai d’expiration. La révocation du jeton n’est pas immédiate. La propagation peut prendre jusqu’à 15 minutes.
  • La suppression d’une identité, d’une ressource ou d’un abonnement révoque tous les jetons d’accès.
  • Si vous voulez retirer à un utilisateur la possibilité d’accéder à des fonctionnalités spécifiques, révoquez tous les jetons d’accès de l’utilisateur. Émettez ensuite un nouveau jeton d’accès avec un ensemble d’étendues plus limité.
  • Une rotation des clés d’accès révoque tous les jetons d’accès actifs qui ont été créés en utilisant une clé d’accès antérieure. Ainsi, toutes les identités perdent l’accès à Azure Communication Services et ont besoin de nouveaux jetons d’accès.

Architecture du serveur client pour le modèle BYOI (Bring Your Own Identity)

Créez et gérez des jetons d’accès utilisateur via un service approuvé et ne créez pas de jetons dans votre application cliente. Vous avez besoin de la chaîne de connexion ou des informations d’identification Microsoft Entra pour créer des jetons d’accès utilisateur. N’oubliez pas de protéger les informations d’identification, en les transmettant à un client risque de fuite du secret. Le fait de ne pas gérer correctement les jetons d’accès peut entraîner des frais supplémentaires sur votre ressource lorsque les jetons sont distribués librement et mal utilisés par quelqu’un d’autre.

Si vous mettez en cache les jetons d’accès dans un magasin de stockage, nous vous recommandons d’utiliser le chiffrement des jetons. Un jeton d’accès donne accès aux données sensibles et peut être utilisé pour une activité malveillante s’il n’est pas protégé. Toute personne disposant du jeton d’accès d’un utilisateur peut accéder aux données de conversation de cet utilisateur ou participer à des appels en empruntant l’identité de l’utilisateur.

Veillez à inclure uniquement les périmètres dans le jeton dont votre application cliente a besoin pour suivre le principe de sécurité du moindre privilège.

Diagramme montrant l’architecture des jetons d’accès utilisateur.

  1. Un utilisateur démarre l’application cliente.
  2. L’application cliente contacte votre service de gestion des identités.
  3. Le service de gestion des identités authentifie l’utilisateur de l’application. Vous pouvez ignorer l’authentification pour les scénarios où l’utilisateur est anonyme, mais veillez à ajouter ensuite d’autres mesures de protection telles que la limitation et CORS à votre service pour atténuer l’abus de jeton.
  4. Créez ou recherchez une identité Communication Services pour l’utilisateur.
    1. Scénario d’identité stable : votre service de gestion des identités gère un mappage entre les identités d’application et les identités Communication Services. (les identités d’application incluent vos utilisateurs et d’autres objets adressables, tels que des services ou des bots). Si l’identité de l’application est nouvelle, une identité de communication est créée et un mappage est stocké.
    2. Scénario d’identité éphémère : le service de gestion des identités crée une identité de communication. Dans ce scénario, le même utilisateur se retrouve avec une identité de communication différente pour chaque session.
  5. Le service de gestion des identités émet un jeton d’accès utilisateur pour l’identité applicable et le retourne à l’application cliente.

Azure App Service ou Azure Functions sont deux alternatives à l’exploitation du service de gestion des identités. Ces services se mettent à l’échelle facilement et disposent de fonctionnalités intégrées pour authentifier les utilisateurs. Ils sont intégrés avec OpenID et des fournisseurs d’identité tiers tels que Facebook.

ID Microsoft Entra : Intégration à l’ID Entra

Important

Cette fonctionnalité d’Azure Communication Services est actuellement en préversion. Les fonctionnalités en préversion sont disponibles publiquement et peuvent être utilisées par tous les clients Microsoft nouveaux et existants.

Ces interfaces de programmation d’applications et kits de développement logiciel (SDK) en préversion sont fournis sans contrat au niveau du service. Nous vous recommandons de ne pas les utiliser pour les charges de travail de production. Certaines fonctionnalités peuvent ne pas être prises en charge ou les fonctionnalités peuvent être limitées.

Pour plus d’informations, consultez Conditions d’utilisation supplémentaires pour les préversions de Microsoft Azure.

Azure Communication Services prend désormais en charge l’authentification d’ID Microsoft Entra, ce qui vous permet d’accéder directement aux ressources Azure Communication Services avec les utilisateurs d’Entra ID. Cette nouvelle prise en charge de l’authentification entra ID élimine la nécessité de développer ou d’exploiter votre propre service proxy d’identité ou d’autorisation mentionné dans la section Architecture client-serveur.

Les sections suivantes vous guident tout au long des aspects essentiels de l’intégration de Microsoft Entra ID :

Jetons d’accès avec Microsoft Entra ID

Seuls les jetons d’accès Azure Communication Services sont pris en charge pour l’authentification et l’autorisation dans Azure Communication Services, notamment les fonctionnalités de conversation et d’appel. Pour plus d’informations sur la structure et la gestion des jetons, consultez Jetons d’accès. Pendant la préversion publique de l’ID Microsoft Entra, seules les étendues de jeton d’accès d’appel (VoIP) sont prises en charge par le biais de l’intégration d’ID Entra.

Avec l’intégration de l’ID Microsoft Entra, vous authentifiez les utilisateurs via l’ID Entra, obtenez un jeton d’accès utilisateur Entra ID avec des autorisations d’API pour l’application clients Azure Communication Services et échangez-le pour un jeton d’accès Azure Communication Services. Les kits SDK communs Azure Communication Services offrent une authentification transparente en obtenant automatiquement un jeton d’accès Azure Communication Services pour l’utilisateur Entra ID. Pour plus d’informations sur l’implémentation de la logique avec le Kit de développement logiciel (SDK) Commun Azure Communication Services, consultez Obtenir des jetons d’accès pour les utilisateurs de Microsoft Entra ID

Les autorisations d’API pour l’application clients Azure Communication Services sont nommées de manière cohérente avec les étendues de jeton d’accès Azure Communication Services décrites dans les sections Étendues des jetons de conversation et étendues de jeton VoIP. Le tableau suivant montre le mappage entre les autorisations d’API et les étendues des jetons d’accès.

Important

Les autorisations d’API de conversation (Chat, , Chat.Join, Chat.Join.Limited) ne sont pas encore prises en charge via l’ID Microsoft Entra dans la préversion publique. Pour l’instant, seules les autorisations voIP (VoIP, VoIP.Join) sont disponibles. La prise en charge des conversations est prévue pour une prochaine mise à jour.

Autorisation de l'API des clients de Azure Communication Services Étendue du jeton d’accès Azure Communication Services
Chat (Aperçu public d'Entra ID : VoIP uniquement – chat à venir) chat
Chat.Join (Aperçu public d'Entra ID : VoIP uniquement – discussion à venir) chat.join
Chat.Join.Limited (Entra ID public preview : VoIP uniquement – chat à venir) chat.join.limited
VoIP voip
VoIP.Join voip.join

Les jetons d’accès Azure Communication Services sont émis avec la même expiration que le jeton d’accès utilisateur Microsoft Entra ID.

Architecture du client pour l’ID Microsoft Entra

Avec l’intégration de l’ID Microsoft Entra, vous pouvez simplifier votre architecture directement à l’aide de l’ID Entra pour l’authentification et l’autorisation. Les étapes suivantes décrivent le processus :

Diagramme montrant l’architecture d’intégration d’ID Microsoft Entra.

  1. Un utilisateur démarre l’application cliente.
  2. L’application cliente authentifie l’utilisateur via l’ID Microsoft Entra. L’application cliente obtient un jeton d’accès utilisateur Entra ID avec des autorisations d’API pour l’application cliente Azure Communication Services.
  3. L’application cliente obtient un jeton d’accès Azure Communication Services pour l’utilisateur Entra ID à l’aide de l’une des méthodes suivantes :
    • Utilisation des Kits de développement logiciel (SDK) courants Azure Communication Services : le client initialise CommunicationTokenCredential avec les options d'identification de jeton Entra, qui prennent en charge automatiquement l'acquisition d’un jeton d’accès Azure Communication Services pour l’utilisateur Entra ID en arrière-plan. L’application utilise ensuite ces informations d’identification pour accéder aux API Azure Communication Services.
    • Implémentation personnalisée : l'application cliente appelle l'API Exchange Entra ID token for Azure Communication Services access token pour obtenir un jeton d'accès à Azure Communication Services. Le jeton d’accès Azure Communication Services obtenu est ensuite utilisé pour accéder aux API Azure Communication Services.

Cette architecture élimine la nécessité d’un service de gestion des identités distinct, car Microsoft Entra ID gère directement l’authentification et l’autorisation des utilisateurs.

Limites

L’intégration de l’ID Microsoft Entra est actuellement en préversion et présente les limitations suivantes :

  • L’évaluation continue de l’accès n’est pas disponible. Pour révoquer immédiatement les jetons d’accès, suivez les instructions fournies dans Révoquer les jetons d’accès.
  • La suppression d’un utilisateur Entra ID ne supprime pas automatiquement toutes les données associées de la ressource Communication Services. Pour vous assurer que toutes les données sont supprimées, suivez les instructions de Suppression d’une identité.
  • Les autorisations d’API de conversation (Chat, , Chat.Join, Chat.Join.Limited) ne peuvent pas être accordées ou utilisées via l’intégration d’ID Microsoft Entra dans la préversion publique. Seules les autorisations voIP (VoIP, VoIP.Join) sont prises en charge. Utilisez le modèle d’identité BYOI pour obtenir des jetons d'accès au chat jusqu'à la disponibilité générale.

Étapes suivantes

  • Last updated on