Vaya al menú de Azure Portal. Seleccione Todos los recursos y, a continuación, seleccione la cuenta de Azure Maps.
En Configuración en el panel izquierdo, seleccione Autenticación.
Se crean tres valores cuando se crea la cuenta de Azure Maps. Se usan para admitir dos tipos de autenticación en Azure Maps:
Autenticación de Microsoft Entra: Client ID representa la cuenta que se va a usar para las solicitudes de API REST. El valor de Client ID debe almacenarse en la configuración de la aplicación y recuperarse antes de realizar solicitudes HTTP de Azure Maps que usan la autenticación de Microsoft Entra.
Autenticación de clave compartida: Primary Key y Secondary Key se usan como clave de suscripción para la autenticación de clave compartida. La autenticación de clave compartida se basa en pasar la clave generada por la cuenta de Azure Maps con cada solicitud a Azure Maps. Se recomienda volver a generar periódicamente las claves. Para mantener las conexiones actuales durante la regeneración, se proporcionan dos claves. Se puede usar una clave mientras se regenera la otra. Cuando regenere las claves, debe actualizar todas las aplicaciones que acceden a esta cuenta para usar las nuevas claves. Para obtener más información, consulte Autenticación con Azure Maps.
Importante
En el caso de las aplicaciones de producción, se recomienda implementar Microsoft Entra ID y el control de acceso basado en rol de Azure (RBAC de Azure). Para obtener información general sobre los conceptos de Microsoft Entra, consulte Autenticación con Azure Maps.
Escenario: Autenticación mediante claves compartidas con Azure Key Vault
Las aplicaciones que usan la autenticación mediante claves compartidas deben almacenar las claves en un almacén seguro. En este escenario, se explica cómo almacenar de forma segura la clave de una aplicación como un secreto en Azure Key Vault. En lugar de almacenar la clave compartida en la configuración de la aplicación, es la aplicación quien debe recuperar la clave compartida como un secreto de Azure Key Vault. Para simplificar la regeneración de claves, se recomienda que las aplicaciones usen una clave cada vez. Después, las aplicaciones pueden volver a generar la clave no utilizada e implementar la clave regenerada en Azure Key Vault, todo ello mientras se mantienen las conexiones actuales con una clave. Para saber cómo configurar un almacén de Azure Key Vault, consulte Guía del desarrollador de Azure Key Vault.
Importante
En este escenario, se accede indirectamente a Microsoft Entra ID a través de Azure Key Vault. Sin embargo, se recomienda usar la autenticación de Microsoft Entra directamente. El uso de Microsoft Entra ID evita la complejidad adicional y los requisitos operativos de usar la autenticación mediante claves compartidas y la configuración de un almacén de claves.
Cree una entidad de servicio de Microsoft Entra mediante la creación de un registro de aplicación o una identidad administrada. La entidad de servicio creada es responsable de acceder al almacén de claves de Azure Key Vault.
Asigne temporalmente acceso a los secretos con el permiso set para el desarrollador.
Establezca la clave compartida en los secretos del almacén de claves y haga referencia al identificador del secreto en la configuración de la aplicación de demonio.
Quite el permiso set de los secretos.
Para recuperar el secreto de la clave compartida de Azure Key Vault, implemente la autenticación de Microsoft Entra en la aplicación de demonio.
Cree una solicitud de la API REST de Azure Maps con la clave compartida.
Ahora, la aplicación de demonio puede recuperar la clave compartida del almacén de claves.
Escenario: control de acceso basado en roles en Microsoft Entra
Cuando se crea una cuenta de Azure Maps, se muestra el valor Client ID de Azure Maps en la página Detalles de autenticación de Azure Portal. Este valor representa la cuenta que debe usarse para las solicitudes de la API REST. Este valor debe almacenarse en la configuración de la aplicación y debe recuperarse antes de realizar las solicitudes HTTP. El objetivo del escenario es permitir que la aplicación de demonio se autentique en Microsoft Entra ID y llame a las API REST de Azure Maps.
Sugerencia
Para habilitar las ventajas de los componentes de identidades administradas, se recomienda el hospedaje en Azure Virtual Machines, Virtual Machine Scale Sets o App Services.
Hospedaje de un demonio en recursos de Azure
Cuando ejecute aplicaciones en recursos de Azure, puede configurar identidades administradas por Azure para lograr un esfuerzo de administración de credenciales mínimo y de bajo costo.
Las siguientes son algunas de las ventajas de las identidades administradas:
Autenticación mediante criptografía de claves públicas con certificados X509 administrada por el sistema de Azure.
Seguridad de Microsoft Entra con certificados X509 en lugar de secretos de cliente.
Azure administra y renueva todos los certificados asociados al recurso de la identidad administrada.
Simplificación de la administración operativa de credenciales, ya que la identidad administrada elimina la necesidad de un servicio de almacén de secretos protegido, como Azure Key Vault.
Hospedaje de un demonio en recursos que no son de Azure
Las identidades administradas solo están disponibles cuando se ejecutan en un entorno de Azure. Por tanto, debe configurar una entidad de servicio mediante un registro de aplicación de Microsoft Entra para la aplicación de demonio.
Consulte la Guía del desarrollador de Azure Key Vault para almacenar de forma segura el certificado o el secreto. Usará este secreto para obtener tokens de Microsoft Entra ID.
Concesión de acceso basado en roles para usuarios de Azure Maps
Para conceder el control de acceso basado en rol de Azure (Azure RBAC ), se asignan un grupo o una entidad de seguridad de Microsoft Entra a una o varias definiciones de roles de Azure Maps.
Para obtener pasos detallados sobre cómo asignar un rol de Azure Maps disponible a la identidad administrada o a la entidad de servicio creadas, consulte Asignación de roles de Azure mediante Azure Portal.
Para administrar de forma eficaz la aplicación de Azure Maps y el acceso a los recursos por parte de una gran cantidad de usuarios, consulte Grupos de Microsoft Entra.
Para obtener información sobre cómo administrar eficazmente un directorio grande para los usuarios, consulte Microsoft Entra ID.
Advertencia
Las definiciones de roles de Azure Maps integradas proporcionan un acceso de autorización muy amplio a muchas API REST de Azure Maps. Para restringir al mínimo el acceso a las API, consulte cómo crear una definición de roles personalizada y asignar la identidad asignada por el sistema a la definición de roles personalizada. Esto proporciona el privilegio mínimo necesario para que la aplicación acceda a Azure Maps.
Solicitud de un token con una identidad administrada
Muestre las características de Microsoft Entra ID para modernizar las soluciones de identidad, implementar soluciones híbridas e implementar la gobernanza de identidades.