Modelo de identidad

Azure Communication Services es un servicio independiente de identidad, que ofrece varias ventajas:

• Adopte un modelo de "BYOI" (Bring Your Own Identity), que le permite reutilizar las identidades existentes de su sistema de gestión de identidades y mapearlas 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.
• Las organizaciones que usan microsoft Entra ID para la administración de identidades y acceso ahora pueden acceder a los recursos de Azure Communication Services directamente con los usuarios de Entra ID. Esta nueva compatibilidad con la autenticación entra ID elimina la necesidad de desarrollar o operar su propio servicio de proxy de autorización o administración de identidades. Esta característica está actualmente en versión preliminar pública.

El modelo de identidad de Azure Communication Services funciona con dos conceptos clave.

Bring Your Own Identity (BYOI): integración con el sistema de administración de identidades

Azure Communication Services admite un modelo bring your own identity (BYOI), que permite integrarlo con el sistema de administración de identidades existente. Puede crear identidades de usuario en Azure Communication Services y asignarlas a su propio sistema de identidad de usuario. Este enfoque le permite administrar identidades de usuario y tokens de acceso sin duplicar los datos de usuario en Azure Communication Services.

Las secciones siguientes le guiarán por los conceptos clave del modelo bring your own identity (BYOI):

• Asignación de identidades de usuario: asignación de identidades de usuario en el modelo traiga su propia identidad (BYOI).
• Cómo crear y administrar tokens de acceso: tokens de acceso.
• Implementación de una arquitectura de cliente-servidor para la administración de identidades: arquitectura de cliente-servidor para el modelo bring your own identity (BYOI).

Asignación de identidades de usuario en el modelo bring your own identity (BYOI)

Al crear una identidad de usuario a través del SDK o la API REST, Azure Communication Services crea un identificador de usuario único. No puede usar identificadores externos, como números de teléfono, identificadores de usuario, dispositivo o aplicación, o nombres de usuario directamente en Azure Communication Services. En su lugar, debe usar las identidades de Servicios de Comunicación y mantener un mapeo con su propio sistema de ID de usuario según sea necesario.

Puede crear identidades de usuario de Azure Communication Service de forma gratuita. Los únicos cargos se incurren cuando el usuario consume servicios 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. El usuario final 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 mapeo se describe con mayor detalle en la Arquitectura cliente-servidor para el modelo traiga su propia identidad (BYOI).

(Versión preliminar) Simplifica la asignación de identidades con customId

Anteriormente, los desarrolladores eran responsables de mantener una asignación entre su propio sistema de identidad de usuario y las identidades de Azure Communication Services. Con la introducción del customId parámetro , ahora puede asociar sus propios identificadores de usuario (como direcciones de correo electrónico o identificadores de usuario internos) directamente al crear una identidad de Communication Services.

Al crear un usuario con customId, Azure Communication Services devolverá la misma identidad si vuelve a llamar al método con el mismo customId. Esto elimina la necesidad de almacenar y administrar la asignación usted mismo.

Esta característica se admite tanto en el SDK como en la API REST, y es especialmente útil para escenarios en los que desea mantener una identidad coherente entre sesiones, dispositivos o servicios sin sobrecarga de almacenamiento adicional.

Tokens de acceso

Después de crear una identidad de usuario, el usuario final 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 de chat ámbito puede participar en el chat. Solo un usuario con un token de 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.

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

El modelo de identidad admite tres ámbitos de token de chat diferentes. Los permisos para cada ámbito se describen en la siguiente tabla.

• chat
• chat.join
• chat.join.limited

Ámbitos de token de VoIP

El modelo de identidad admite dos ámbitos de token voIP. Los permisos para cada ámbito se describen en la siguiente tabla.

• voip
• voip.join

Puede usar el voip.join ámbito junto con Salas para crear una llamada programada. En este escenario, solo los usuarios invitados obtienen acceso y los usuarios no pueden crear ninguna otra llamada.

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.
• Al eliminar una identidad, un recurso o una suscripción, se 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-servidor para el modelo bring your own identity (BYOI)

Cree y administre tokens de acceso de usuario a través de un servicio de confianza y no cree tokens en la aplicación cliente. Necesita la cadena de conexión o las credenciales de Microsoft Entra para crear tokens de acceso de usuario. Recuerde proteger las credenciales y pasarlas a un cliente corre el riesgo de perder el 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.

1. Un usuario inicia la aplicación cliente.
2. La aplicación cliente se pone en contacto con el servicio de administración de identidades.
3. 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.
4. Cree o busque una identidad de Communication Services para el usuario.
   1. 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 a 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.
   2. 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.
5. 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.

Microsoft Entra ID: Integración con Entra ID

Azure Communication Services ahora admite la autenticación de id. de Entra de Microsoft, lo que le permite acceder a los recursos de Azure Communication Services directamente con los usuarios de Entra ID. Esta nueva compatibilidad con la autenticación entra ID elimina la necesidad de desarrollar o operar su propio servicio de proxy de autorización o administración de identidades mencionado en la sección Arquitectura de cliente-servidor.

Las secciones siguientes le guiarán a través de los aspectos esenciales de la integración de Microsoft Entra ID:

• Cómo obtener y administrar tokens de acceso: tokens de acceso con Microsoft Entra ID.
• Implementación de una arquitectura de cliente con Microsoft Entra ID: Arquitectura de cliente para el identificador de Microsoft Entra.
• Limitaciones actuales y guía recomendada: limitaciones.

Tokens de acceso con Microsoft Entra ID

Solo se admiten tokens de acceso de Azure Communication Services para la autenticación y autorización en Azure Communication Services, incluidas las funcionalidades de chat y llamada. Para más información sobre la estructura y administración de tokens, consulte Tokens de acceso. Durante la versión preliminar pública de Microsoft Entra ID, solo se admiten ámbitos de tokens de acceso para llamadas (VoIP) a través de la integración de Microsoft Entra ID.

Con la integración de Microsoft Entra ID, autentica a los usuarios a través de Entra ID, obtiene un token de acceso de usuario de Entra ID con permisos de API para la aplicación Clientes de Azure Communication Services y lo intercambia por un token de acceso de Azure Communication Services. Los SDK comunes de Azure Communication Services ofrecen autenticación sin problemas mediante la obtención automática de un token de acceso de Azure Communication Services para el usuario de Entra ID. Para más información sobre cómo implementar la lógica con el SDK común de Azure Communication Services, consulte Obtención de tokens de acceso para usuarios de Microsoft Entra ID.

Los permisos de API para la aplicación clientes de Azure Communication Services se denominan de forma coherente con los ámbitos de token de acceso de Azure Communication Services descritos en las secciones Ámbitos de token de chat y ámbitos de token de VoIP. En la tabla siguiente se muestra la asignación entre los permisos de API y los ámbitos del token de acceso.

Los tokens de acceso de Azure Communication Services se emiten con la misma expiración que el token de acceso de usuario de Microsoft Entra ID.

Arquitectura de cliente para el identificador de Entra de Microsoft

Con la integración de Microsoft Entra ID, puede simplificar la arquitectura mediante el uso directo de Entra ID para la autenticación y autorización. En los pasos siguientes se describe el proceso:

1. Un usuario inicia la aplicación cliente.
2. La aplicación cliente autentica al usuario a través de Microsoft Entra ID. La aplicación cliente obtiene un token de acceso de usuario de Entra ID con permisos de API para la aplicación Azure Communication Services Clients.
3. La aplicación cliente obtiene un token de acceso de Azure Communication Services para el usuario de Entra ID mediante uno de los métodos siguientes:
   • Uso de los SDK comunes de Azure Communication Services: el cliente inicializa CommunicationTokenCredential con opciones de credencial de Entra ID, que gestiona automáticamente la obtención de un token de acceso de Azure Communication Services para el usuario de Entra ID en segundo plano. A continuación, la aplicación usa esta credencial para acceder a las API de Azure Communication Services.
   • Implementación personalizada: la aplicación cliente llama a la API de intercambio del token Entra ID de Azure Communication Services para obtener un token de acceso de Azure Communication Services. A continuación, el token de acceso de Azure Communication Services resultante se usa para acceder a las API de Azure Communication Services.

Esta arquitectura elimina la necesidad de un servicio de administración de identidades independiente, ya que el identificador de Microsoft Entra controla directamente la autenticación y autorización del usuario.

Limitaciones

La integración de Microsoft Entra ID está actualmente en versión preliminar y tiene las siguientes limitaciones:

• La evaluación continua del acceso no está disponible. Para revocar los tokens de acceso inmediatamente, siga las instrucciones de Revocación de tokens de acceso.
• Al quitar un usuario de Entra ID, no se quitan automáticamente todos los datos asociados del recurso de Communication Services. Para asegurarse de que se eliminan todos los datos, siga las instrucciones de Eliminación de una identidad.
• Los permisos de la API de chat (mensajería) (Chat, Chat.Join, Chat.Join.Limited) no se pueden conceder ni usar a través de la integración de Microsoft Entra ID en la versión preliminar pública. Solo se admiten los permisos relacionados con VoIP (VoIP, VoIP.Join). Use el modelo de identidad BYOI para obtener tokens de acceso de chat hasta disponibilidad general.

Pasos siguientes

• Para emitir tokens, consulte Creación y administración de tokens de acceso para usuarios finales.
• Para una introducción a la autenticación, consulte Autenticación en Azure Communication Services.
• Para obtener más información sobre cómo funciona la autenticación en los escenarios de Microsoft Entra ID de un inquilino y multiinquilino, consulte Tenencia en Microsoft Entra ID.
• Para obtener un inicio rápido sobre cómo autenticar a los usuarios de Microsoft Entra ID, consulte Autenticación de usuarios de Microsoft Entra ID.
• Para obtener información sobre la residencia y privacidad de los datos, consulte Disponibilidad de la región y residencia de datos.
• Para obtener un ejemplo completo de un servicio de administración de identidades simple, consulte Tutorial de servicio de confianza.
• Para obtener un ejemplo de administración de identidades más avanzado que se integra con Entra ID y Microsoft Graph, consulte Ejemplo principal del servicio de autenticación.