Partager via

Modèle d’identité

  • Article

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

  • Réutilisez les identités existantes à partir de votre système de gestion des identités et mappez-les 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.

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

Identité/mappage de l’utilisateur

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. Les identificateurs externes tels que les numéros de téléphone, les ID d’utilisateur/d’appareil/d’application ou les noms d’utilisateur ne peuvent pas être utilisés 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. La création d’identités utilisateur Azure Communication Service est gratuite et les frais sont facturés uniquement lorsque l’utilisateur consomme des moyens de communication telles 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. Un utilisateur 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 Architecture client-serveur.

Jetons d’accès

Une fois qu’une identité d’utilisateur est créée, un utilisateur a besoin d’un jeton d’accès avec des étendues spécifiques pour participer aux communications à l’aide de conversations ou d’appels. Par exemple, seul un utilisateur disposant d’un jeton avec l’étendue chat peut participer à la conversation et un utilisateur avec un jeton avec é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.

Propriété Description
Objet Identité de l’utilisateur qui est 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 les réunions ponctuelles et des jetons de durée de vie plus longue pour les utilisateurs qui utilisent votre application pendant des périodes plus longues.
Étendues Les étendues définissent les primitives de communication (Conversation/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

Trois étendues de jeton de conversation différentes sont prises en charge. 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 O N N
Mettre à jour le thread de conversation avec l’ID O N N
Supprimer le thread de conversation avec l’ID O N N
Ajouter un participant à un fil de conversation A Y N
Supprimer un participant d’un fil de conversation A Y N
Répertorier les threads de conversation A O A
Obtenir le thread de conversation avec l’ID A O A
Obtenir ReadReceipt A O A
Créer ReadReceipt A O A
Créer un message pour le thread de conversation avec l’ID A O A
Obtenir le message avec l’ID de message A O A
Mettre à jour votre propre message avec l’ID de message A O A
Supprimer votre propre message avec l’ID de message A O A
Envoyer un indicateur de saisie A O A
Obtenir le participant pour l’ID de thread A O A

Étendues de jeton VoIP

Deux étendues de jeton VoIP sont prises en charge. 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 O N
Démarrez un appel VoIP dans Virtual Rooms lorsque l’utilisateur est déjà invité à la salle A A
Rejoindre un appel VoIP en cours A A
Rejoindre un appel VoIP en cours dans Virtual Rooms, lorsque l’utilisateur est déjà invité à la salle A A
Toutes les autres opérations en appel telles que activer le micro/désactiver le micro, le partage d’écran, etc. A A
Toutes les autres opérations en appel telles que activer le micro/désactiver le micro, le partage d’écran, etc. 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é où seuls les utilisateurs invités ont accès et où les utilisateurs sont interdits de 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 entraîne la révocation de 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. Par conséquent, toutes les identités perdent l’accès à Azure Communication Services et ont besoin de nouveaux jetons d’accès.

Architecture du serveur client

Vous devez créer et gérer des jetons d’accès utilisateur via un service approuvé et non créer des jetons dans votre application cliente. La chaîne de connexion ou les informations d’identification Microsoft Entra nécessaires pour créer des jetons d’accès utilisateur doivent être protégés, leur transmission à un client risque de fuiter le 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 qu’ils sont 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 ces étendues dans le jeton dont votre application cliente a besoin pour suivre le principe de sécurité des privilèges minimum.

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.

Étapes suivantes