Compartir a través de

Autenticación

  • Artículo

Al realizar llamadas REST, se requieren varios pasos para autenticarse correctamente. Los SDK de Azure Communication Services controlan este proceso por usted, pero realizar solicitudes manualmente significa que tendrá que controlarlo usted mismo.

Tipos de autenticación

Azure Communication Services tiene tres tipos de autenticación, que se usan con fines diferentes:

  • autenticación de clave de acceso para las operaciones de SMS, Network Traversal, Call Automation, Identity y access token. La autenticación de clave de acceso es adecuada para las aplicaciones que se ejecutan en un entorno de servicio de confianza.
  • autenticación RBAC de Azure para controlar el acceso a los recursos mediante el aprovechamiento de RBAC de Azure mediante la asignación de roles de Azure.
  • de autenticación de token de acceso de usuario para chat y llamadas. Los tokens de acceso de usuario permiten que las aplicaciones cliente se autentiquen directamente en Azure Communication Services. Estos tokens se generan en un servicio de aprovisionamiento de tokens del lado servidor que cree. A continuación, se proporcionan a los dispositivos cliente que usan el token para inicializar las bibliotecas cliente chat y llamada.

Autenticación de clave de acceso

La autenticación de clave de acceso se usa cuando la aplicación de usuario final no realiza solicitudes. Ejecute estas solicitudes dentro de un entorno de servicio de confianza.

En este método de autenticación, las solicitudes se firman mediante un código de autenticación de mensajes basado en hash (HMAC) generado por el cliente.

Antes de empezar, asegúrese de que tiene:

  • Su clave de acceso de Azure Communication Services
  • El punto de conexión de Azure Communication Service
  • La ruta de acceso url y el verbo HTTP que está llamando
  • Un entorno de desarrollo, que puede generar HMAC, hash SHA256 y realizar operaciones base64.

Una vez que tenga estos elementos, puede continuar con la firma de la solicitud.

Firma de una solicitud HTTP

  1. Asegúrese de que tiene los siguientes valores disponibles:

    • Método de solicitud HTTP (por ejemplo, GET o PUT)
    • Marca de tiempo de hora universal coordinada (UTC) para la solicitud según el estándar RFC1123
    • Host de solicitud HTTP (componente de URI de <authority> tal y como se especifica en RFC2396)
    • Cuerpo de la solicitud HTTP con hash mediante el algoritmo SHA256
    • Ruta de acceso de solicitud HTTP (el <path> y <query> concatenado por componentes de ?, tal como se especifica en RFC2396)
    Verb=<http_method>
Timestamp=<current_datetime>
Host=<uri_authority>
ContentHash=SHA256(<request_body>)
URIPathAndQuery=<uri_path>?<uri_query>

  2. Construya la cadena que se va a firmar mediante la concatenación de los valores de la siguiente manera:

    StringToSign=Verb + "\n"
URIPathAndQuery + "\n"
Timestamp + ";" + Host + ";" + ContentHash

  3. Genere una firma HMAC-256 de la cadena codificada UTF-8 que creó en el paso anterior. A continuación, codifique los resultados como Base64. También debe descodificar la clave de acceso en Base64. Use el formato siguiente (que se muestra como pseudocódigo):

    Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_access_key>)))

  4. Agregue los siguientes encabezados a la solicitud:

    x-ms-date: <Timestamp>
x-ms-content-sha256: <ContentHash>
host: <URIPathAndQuery>   
Authorization: "HMAC-SHA256 SignedHeaders=x-ms-date;host;x-ms-content-sha256&Signature=<Signature>"

Al recibir la solicitud, el servicio valida la firma y la marca de tiempo para protegerse contra determinados ataques de seguridad, incluidos los ataques de reproducción. Para obtener información sobre cómo firmar la solicitud HTTP en varios lenguajes de programación, visite el tutorial de firma de encabezadoS HMAC .

Autenticación RBAC de Azure

La plataforma Azure proporciona acceso basado en rol (RBAC de Azure) para controlar el acceso a los recursos. La entidad de seguridad de Azure RBAC representa un usuario, grupo, entidad de servicio o identidad administrada que solicita acceso a los recursos de Azure.

La autenticación de Microsoft Entra proporciona mayor seguridad y facilidad de uso en otras opciones de autorización. Por ejemplo, mediante el uso de la identidad administrada, evita tener que almacenar la clave de acceso de la cuenta en el código, como sucede con la autenticación de clave de acceso. Aunque puede seguir usando la autenticación de claves de acceso con aplicaciones de servicios de comunicación, Microsoft recomienda pasar a Microsoft Entra ID siempre que sea posible.

Azure RBAC incluye muchos roles integrados, se pueden asignar en distintos ámbitos y le permite crear sus propios roles personalizados. Incluye más de 100 roles integrados. Hay cinco roles fundamentales de Azure: propietario, colaborador, lector, administrador de control de acceso basado en roles y administrador de acceso de usuario. Para obtener más información sobre estos roles, visite el tutorial de control de acceso basado en rol de .

Permisos admitidos por Azure Communication Services (ACS)

ACS ofrece permisos específicos (acs.read y acs.write) que permiten el acceso controlado a varios recursos.

  • permiso acs.read: concede la capacidad de recuperar o ver datos.
  • permiso acs.write: permite la modificación o creación de datos dentro de esos mismos tipos de recursos.

Además, ACS admite permisos relacionados con el correo electrónico:

  • acs.email.read: permite leer o acceder a los datos de servicios relacionados con el correo electrónico.
  • acs.email.write: permite modificar o crear datos de servicios relacionados con el correo electrónico.

Estos permisos son cruciales para garantizar un control de acceso granular y una seguridad sobre los recursos de ACS.

Obtención de un token de RBAC adicional

Para adquirir un token para ACS, puede usar MSAL (Biblioteca de autenticación de Microsoft). Esta es una guía paso a paso:

  1. Registrar una aplicación en Azure AD: asegúrese de que la aplicación está registrada en Azure AD.
  2. Instalación de MSAL: instale la biblioteca MSAL para la plataforma (por ejemplo, Microsoft.Identity.Client para .NET).
  3. Configuración de MSAL: configure MSAL con el identificador de cliente de la aplicación, el identificador de inquilino y el secreto de cliente.
  4. Adquirir un token: use MSAL para adquirir un token con el ámbito necesario (https://communication.azure.com/.default).

Para obtener instrucciones detalladas y ejemplos de código, consulte la documentación oficial de MSAL y documentación del token de acceso.

Solicitud HTTP de ejemplo para emitir el token de acceso de ACS

Pedir:

POST https://my-resource.communication.azure.com/identities/{identity}/:issueAccessToken?api-version=2023-10-01
Authorization: Bearer <your-access-token>
Content-Type: application/json
{
  "scopes": [
    "chat",
    "voip"
  ]
}

Respuesta:

{
  "token": "token",
  "expiresOn": "2023-10-10T21:39:39.3244584+00:00"
}

Autenticación de token de acceso de usuario

Los tokens de acceso de usuario permiten que las aplicaciones cliente se autentiquen directamente en Azure Communication Services como un usuario o una identidad concretos.

Generación o obtención de tokens de acceso de usuario

Los tokens de acceso de usuario los genera dentro de un entorno de confianza. Generarlos mediante el SDK de identidad de Azure Communication Services es la manera más fácil. Para obtener más información, consulte creación y administración de tokens de acceso de usuario.

Uso de un token de acceso de usuario en una solicitud

Una vez que tenga un token de acceso de usuario adecuado, puede incluirlo en las solicitudes a la API REST de Azure Communication Services. Para ello, debe proporcionarlo en el encabezado Authorization mediante el esquema de autenticación HTTP de portador Authorization: Bearer <token>.

Consulte también

Para más información sobre la autenticación de Azure Communication Services, también puede revisar: