Modelo de identidad
Azure Communication Services es un servicio independiente de identidad, que ofrece varias ventajas:
- Vuelva a usar las identidades existentes del sistema de administración de identidades y asígnelas con identidades de Azure Communication Services.
- Funciona bien con cualquier sistema de identidad existente y no tiene ninguna dependencia en un proveedor de identidades específico.
- Mantenga en privado los datos de sus usuarios, como su nombre, ya que no necesita duplicarlos en Azure Communication Services.
El modelo de identidad de Azure Communication Services funciona con dos conceptos clave.
Identidad de usuario/asignación
Al crear una identidad de usuario a través del SDK o la API REST, Azure Communication Services crea un identificador de usuario único. Los identificadores externos, como números de teléfono, identificadores de usuario, dispositivo o aplicación, o nombres de usuario no se pueden usar directamente en Azure Communication Services. En su lugar, debe usar las identidades de Communication Services y mantener una asignación a su propio sistema de identificador de usuario según sea necesario. La creación de identidades de usuario de Azure Communication Service es gratuita y sólo se incurre en gastos cuando el usuario consume modalidades de comunicación como un chat o una llamada. La forma de usar la identidad de Communication Services generada depende de su escenario. Por ejemplo, puede asignar una identidad 1:1, 1:N, N:1 o N:N, y puede usarla para usuarios o aplicaciones humanas. Un usuario puede participar en varias sesiones de comunicación mediante varios dispositivos simultáneamente. La administración de una asignación entre las identidades de usuario de Azure Communication Services y su propio sistema de identidades es su responsabilidad como desarrollador y no viene integrada. Por ejemplo, puede agregar una CommunicationServicesId columna en la tabla de usuario existente para almacenar la identidad de Azure Communication Services asociada. Un diseño de asignación se describe con más detalle en Arquitecturade cliente-servidor.
Tokens de acceso
Después de crear una identidad de usuario, un usuario necesita un token de acceso con ámbitos específicos para participar en comunicaciones mediante chat o llamadas. Por ejemplo, solo un usuario con un token con el ámbito puede participar en el chat chat y un usuario con un token con voip ámbito puede participar en una llamada VoIP. Un usuario puede tener varios tokens simultáneamente. Azure Communication Services admite varios ámbitos de token para tener en cuenta a los usuarios que requieren acceso total frente al acceso limitado. Los tokens de acceso tienen las siguientes propiedades.
| Propiedad | Descripción |
|---|---|
| Asunto | Identidad de usuario representada por el token. |
| Expiración | Un token de acceso es válido durante al menos 1 hora y hasta 24 horas. Una vez expirado, el token de acceso no es válido y no se puede usar para acceder al servicio. Para crear un token con una hora de expiración personalizada, especifique la validez deseada en minutos (>=60, <1440). De forma predeterminada, el token es válido durante 24 horas. Se recomienda usar tokens de duración corta para reuniones puntuales y tokens de duración más larga para los usuarios que usan la aplicación durante períodos de tiempo más largos. |
| Ámbitos | Los ámbitos definen a qué primitivos de comunicación (Chat/VoIP) se puede acceder con el token. |
Un token de acceso es un JSON Web Token (JWT) y tiene protección de integridad. Es decir, sus notificaciones no se pueden cambiar sin invalidar el token de acceso porque la firma del token ya no coincide. Si se utilizan primitivas de comunicación con tokens no válidos, se deniega el acceso. Aunque los tokens no están cifrados ni ofuscados, la aplicación no debe depender del formato del token ni de sus notificaciones. El formato del token puede cambiar y no forma parte del contrato de API oficial. Azure Communication Services admite los siguientes ámbitos para los tokens de acceso.
Ámbitos de los tokens de chat
Se admiten tres ámbitos de token de chat diferentes. Los permisos para cada ámbito se describen en la siguiente tabla.
chatchat.joinchat.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 | S | No |
| Eliminación del participante de una conversación de chat | Y | S | 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 ámbitos de token voIP. Los permisos para cada ámbito se describen en la siguiente tabla.
voipvoip.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 durante la llamada, como silenciar/activar silencio, compartir pantalla, etc. | Y | Y |
| Todas las demás operaciones en llamada, como silenciar o desactivar, compartir pantalla, etc. en Virtual Rooms | Determinado por el rol de usuario | Determinado por el rol de usuario |
Puede usar el voip.join ámbito junto con Salas para crear una llamada programada en la que solo los usuarios invitados obtengan acceso y donde los usuarios tengan prohibido crear otras llamadas.
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, un recurso o una suscripción revoca todos los tokens de acceso.
- Si desea quitar la capacidad de un usuario para acceder a una funcionalidad específica, revoque todos los tokens de acceso para el usuario. 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 todas las fichas de acceso activas que se crearon utilizando una clave de acceso anterior. Por lo tanto, todas las identidades pierden el acceso a Azure Communication Services y necesitan nuevos tokens de acceso.
Arquitectura de cliente y servidor
Debe crear y administrar tokens de acceso de usuario a través de un servicio de confianza y no crear tokens en la aplicación cliente. La cadena de conexión o las credenciales de Microsoft Entra necesarias para crear tokens de acceso de usuario deben protegerse, pasarlas a un cliente podría arriesgar la pérdida del secreto. Si no se administran correctamente los tokens de acceso, se pueden generar cargos adicionales en el recurso cuando los tokens se dispensan libremente y se usan incorrectamente por otra persona.
Si almacena en caché los tokens de acceso a un almacén de respaldo, se recomienda cifrar los tokens. Un token de acceso da acceso a datos sensibles y puede utilizarse para actividades maliciosas si no está protegido. Cualquier persona con el token de acceso de un usuario puede acceder a los datos de chat del usuario o participar en llamadas que suplantan al usuario.
Asegúrese de incluir solo esos ámbitos en el token que la aplicación cliente necesita para seguir el principio de seguridad de privilegios mínimos.
- Un usuario inicia la aplicación cliente.
- La aplicación cliente se pone en contacto con el servicio de administración de identidades.
- El servicio de administración de identidades autentica al usuario de la aplicación. Puede omitir la autenticación para escenarios en los que el usuario es anónimo, pero tenga cuidado de añadir otras medidas de protección como la limitación y CORS a su servicio para mitigar el abuso de tokens.
- Cree o busque una identidad de Communication Services para el usuario.
- Escenario de identidad estable: su servicio de administración de identidades mantiene una correspondencia entre las identidades de las aplicaciones y las identidades de Communication Services. (Las identidades de aplicación incluyen los usuarios y otros objetos direccionables, como servicios o bots). Si la identidad de la aplicación es nueva, se crea una nueva identidad de comunicación y se almacena una asignación.
- Escenario de identidad efímero: el servicio de administración de identidades crea una nueva identidad de comunicación. En este escenario, el mismo usuario termina con una identidad de comunicación diferente para cada sesión.
- El servicio de administración de identidades emite un token de acceso de usuario para la identidad aplicable y lo devuelve a la aplicación cliente.
Azure App Service o Azure Functions son dos alternativas para operar el servicio de administración de identidades. Estos servicios se escalan fácilmente y tienen características integradas para autenticar a los usuarios. Se integran con OpenID y proveedores de identidades de terceros como Facebook.
Pasos siguientes
- Para obtener información sobre cómo emitir tokens, 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 obtener información sobre la residencia y privacidad de los datos, consulte Disponibilidad de la región y residencia de datos.
- Para obtener información sobre cómo crear rápidamente identidades y tokens para pruebas, consulte el inicio rápido de creación rápida de identidades .
- Para ver una muestra completa de un servicio sencillo de administración de identidades, consulte el tutorial Servicio de confianza.
- Para obtener un ejemplo de administración de identidades más avanzado que se integra con Entra ID y Microsoft Graph, vaya al ejemplo principal del servicio de autenticación.