Modelo de identidad
Azure Communication Services es un servicio independiente de identidad, que ofrece varias ventajas:
- Reutilice las identidades existentes desde el sistema de administración de identidades y simplemente asígnelas con identidades de Azure Communication Services.
- Proporciona flexibilidad de integración, ya que el modelo independiente de identidad funciona bien con el sistema de identidad existente.
- Puede conservar los datos del usuario, como su nombre, privado, ya que no es necesario duplicarlos en Azure Communication Services.
El modelo de identidad de Azure Communication Services funciona con dos conceptos clave.
Identidad de usuario/asignación
Identifica de forma única a un usuario a través de un identificador de usuario, que azure Communication Services genera cuando se crea un usuario. Los identificadores externos, como los números de teléfono, los usuarios, los dispositivos, las aplicaciones y los GUID, no se pueden usar para una identidad de Azure Communication Services. Puede crear identidades de usuario de Azure Communication Service de forma gratuita. Los cargos solo se incurren cuando el usuario consume modalidades de comunicaciones como un chat o una llamada. La identidad de los usuarios se puede asignar a la identidad de usuario de Azure Communication Services en las configuraciones 1:1, 1:N, N:1, N:N. Un usuario puede participar en varias sesiones de comunicación mediante varios dispositivos simultáneamente. La asignación entre la identidad de usuario de Azure Communication Services y la identidad de usuario privada del cliente se mantiene y mantiene el cliente. Por ejemplo, los clientes pueden agregar una CommunicationServicesId columna en su tabla de usuario para almacenar la identidad de Azure Communication Services asociada.
Tokens de acceso
Una vez creada una identidad de usuario, se concede a un usuario la capacidad de participar en comunicaciones mediante chat o llamadas, mediante tokens de acceso. Por ejemplo, solo un usuario con token de chat puede participar en el chat y el usuario con el token de VoIP puede participar en una llamada VoIP. Un usuario puede tener varios tokens simultáneamente. Azure Communication Services admite varios tipos de tokens para tener en cuenta a los usuarios que requieren acceso completo frente al acceso limitado. Los tokens de acceso tienen las siguientes propiedades.
| Propiedad | Descripción |
|---|---|
| identidad | Identifica de forma única un token |
| Expiración | Un token de acceso es válido durante un período de tiempo comprendido entre 1 y 24 horas. Después de expirar, el token de acceso se invalida y no se puede usar para acceder a ningún primitivo. Para generar un token con una validez personalizada, especifique el período de validez deseado al generar el token. Si no se especifica ninguna validez personalizada, el token será válido durante 24 horas. Se recomienda usar tokens de duración corta para reuniones puntuales y tokens de duración más largos para agentes que usan la aplicación durante períodos de tiempo más largos. |
| Ámbito | El parámetro scope define un conjunto noempty de primitivos (Chat/VoIP) que se puede usar. |
Un token de acceso es un json Web Token (JWT) y tiene protección de integridad. Es decir, no se pueden cambiar sus notificaciones después de que se emita. Por lo tanto, un cambio manual de propiedades, como la identidad, la expiración o los ámbitos hará que el token de acceso no sea válido. Si se usan primitivos con tokens no válidos, se denegará el acceso a los primitivos. Azure Communication Services admite los siguientes ámbitos para los tokens de acceso.
Ámbitos de token de chat
Se admiten tres tipos de ámbitos de token de chat. A continuación se describen los permisos de cada token.
- chat
- chat.join
- chat.join.limited
| Ámbito de funcionalidad/token | chat | chat.join | chat.join.limited |
|---|---|---|---|
| Creación de subprocesos de chat | Y | N | N |
| Actualización del subproceso de chat con el identificador | Y | N | N |
| Eliminar subproceso de chat con el identificador | Y | N | N |
| Agregar participante a un subproceso de chat | Y | Y | No |
| Eliminación del participante de una conversación de chat | Y | Y | No |
| Obtener subprocesos de chat | Y | Y | Y |
| Obtención del subproceso de chat con el identificador | Y | Y | Y |
| Obtener ReadReceipt | Y | Y | Y |
| Creación de ReadReceipt | Y | Y | Y |
| Creación de un mensaje para el subproceso de chat con identificador | Y | Y | Y |
| Obtención de un mensaje con el identificador de mensaje | Y | Y | Y |
| Actualización de su propio mensaje con el identificador de mensaje | Y | Y | Y |
| Eliminar su propio mensaje con el identificador de mensaje | Y | Y | Y |
| Envío de indicadores de escritura | Y | Y | Y |
| Obtención del participante para el identificador de subproceso | Y | Y | Y |
Ámbitos de token de VoIP
Se admiten dos tipos de ámbitos de token de VoIP. A continuación se describen los permisos de cada token.
- Voip
- voip.join
| Ámbito de funcionalidad/token | Voip | voip.join |
|---|---|---|
| Iniciar una llamada VoIP | Y | No |
| Inicie una llamada VoIP en Salas virtuales cuando el usuario ya esté invitado a la sala. | Y | Y |
| Unirse a una llamada VoIP de InProgress | Y | Y |
| Únase a una llamada VoIP de InProgress en Salas virtuales, cuando el usuario ya esté invitado a la sala. | Y | Y |
| Todas las demás operaciones en llamada, como silenciar o desactivar, compartir pantalla, etc. | Y | Y |
| Todas las demás operaciones en llamada, como silenciar o desactivar, compartir pantalla, etc. en Salas virtuales | Determinado por el rol de usuario | Determinado por el rol de usuario |
Revocar o actualizar el token de acceso
- La biblioteca de identidades de Azure Communication Services se puede usar para revocar un token de acceso antes de su hora de expiración. La revocación del token no es inmediata. Puede tardar hasta 15 minutos en propagarse.
- La eliminación de una identidad, recurso o suscripción revocará todos los tokens de acceso.
- Si quiere eliminar la capacidad de un usuario para acceder a una funcionalidad específica, revoque todos los tokens de acceso. Después, emita un nuevo token de acceso que tenga un conjunto de ámbitos más limitado.
- La rotación de claves de acceso revoca todos los tokens de acceso activos creados mediante una clave de acceso anterior. En este caso, todas las identidades pierden el acceso a Azure Communication Services y deben emitir nuevos tokens de acceso.
Consideraciones
- Se recomienda emitir los tokens de acceso en el servicio del servidor y no en la aplicación del cliente. El razonamiento es que la emisión requiere una clave de acceso o una autenticación de Microsoft Entra. Por motivos de seguridad, no se recomienda compartir secretos con la aplicación del cliente.
- La aplicación cliente debe usar un punto de conexión de servicio de confianza que pueda autenticar a los clientes. El punto de conexión debe emitir tokens de acceso en su nombre. Para más información, vea Arquitectura de cliente y servidor.
- Si almacena en caché los tokens de acceso en una memoria auxiliar, se recomienda usar cifrado. Un token de acceso es información confidencial. Se puede usar para actividades malintencionadas si no se protege. Alguien que tenga un token de acceso puede iniciar el SDK y acceder a la API. La API accesible solo está restringida en función de los ámbitos que tiene el token de acceso.
- Se recomienda emitir tokens de acceso que solo tengan los ámbitos necesarios.
Pasos siguientes
- Para una introducción a la administración de tokens de acceso, consulte Creación y administración de tokens de acceso.
- Para una introducción a la autenticación, consulte Autenticación en Azure Communication Services.
- Para una introducción a la residencia y la privacidad de los datos, consulte Disponibilidad de regiones y residencia de datos.
- Para obtener información sobre cómo crear rápidamente identidades para pruebas, consulte el inicio rápido para crear identidades rápidamente.