Autentique y autorice una aplicación con Microsoft Entra ID para acceder a las entidades de Azure Service Bus
Azure Service Bus admite el uso de Microsoft Entra ID para autorizar solicitudes a entidades de Service Bus (colas, temas, suscripciones o filtros). Con microsoft Entra ID, puede usar el control de acceso basado en rol de Azure (RBAC de Azure) para conceder permisos a una entidad de seguridad, que puede ser un usuario, un grupo, una entidad de servicio de aplicación o una identidad administrada para los recursos de Azure. Una ventaja clave de usar Microsoft Entra ID con Azure Service Bus es que ya no es necesario almacenar las credenciales en el código. En su lugar, puede solicitar un token de acceso de OAuth 2.0 desde la plataforma de identidad de Microsoft. Si la autenticación se realiza correctamente, Microsoft Entra ID devuelve un token de acceso a la aplicación, y esta puede entonces usar el token de acceso para autorizar una solicitud de los recursos de Service Bus.
Importante
Puede deshabilitar la autenticación de clave SAS o local para un espacio de nombres de Service Bus y permitir solo la autenticación de Microsoft Entra. Para instrucciones paso a paso, consulte Deshabilitación de la autenticación local.
Información general
Cuando una entidad de seguridad (un usuario, un grupo o una aplicación) intenta acceder a una entidad de Service Bus, la solicitud debe estar autorizada. Con Microsoft Entra ID, el acceso a un recurso es un proceso de dos pasos.
- En primer lugar, se autentica la identidad de la entidad de seguridad y se devuelve un token de OAuth 2.0. El nombre del recurso para solicitar un token es
https://servicebus.azure.net
. - Luego, el token se pasa como parte de una solicitud al servicio Service Bus para autorizar el acceso al recurso especificado.
El paso de autenticación exige que una solicitud de aplicación contenga un token de acceso de OAuth 2.0 en tiempo de ejecución. Si una aplicación se está ejecutando dentro de una entidad de Azure, como puede ser una máquina virtual de Azure, un Conjunto de escalado de máquinas virtuales o una aplicación de Azure Functions, puede usar una identidad administrada para acceder a los recursos. Para más información sobre cómo autenticar solicitudes realizadas por una identidad administrada al servicio Service Bus, consulte Autenticar el acceso a los recursos de Azure Service Bus con Microsoft Entra ID e identidades administradas para Azure Resources.
El paso de la autorización exige que se asignen uno o varios roles de Azure a la entidad de seguridad. Azure Service Bus proporciona roles de Azure que abarcan conjuntos de permisos para recursos de Service Bus. Los roles que se asignan a una entidad de seguridad determinan los permisos que esa entidad de seguridad tendrá en los recursos de Service Bus. Para más información sobre la asignación de roles de Azure a Azure Service Bus, consulte Roles integrados de Azure para Azure Service Bus.
Las aplicaciones nativas y las aplicaciones web que realizan solicitudes a Service Bus también pueden autorizar con Microsoft Entra ID. En este artículo se muestra cómo solicitar un token de acceso y usarlo para autorizar solicitudes de recursos de Service Bus.
Roles integrados de Azure para Azure Service Bus
Microsoft Entra concede derechos de acceso a recursos protegidos mediante Azure RBAC. Azure Service Bus define un conjunto de roles integrados de Azure que abarcan conjuntos de permisos comunes utilizados para acceder a las entidades Service Bus y también puede definir roles personalizados para acceder a los datos.
Cuando un rol de Azure se asigna a una entidad de seguridad de Microsoft Entra, Azure concede a esa entidad de seguridad acceso a los recursos. El acceso puede tener como ámbito el nivel de suscripción, el grupo de recursos, el espacio de nombres o la entidad de Service Bus (cola, tema o suscripción). Una entidad de seguridad de Microsoft Entra puede ser un usuario, un grupo, una entidad de servicio de aplicación o una identidad administrada para los recursos de Azure.
En el caso de Azure Service Bus, la administración de los espacios de nombres y de todos los recursos relacionados mediante Azure Portal y la API de administración de recursos de Azure, ya se ha protegido mediante el modelo de Azure RBAC. Azure proporciona los siguientes roles integrados para autorizar el acceso a un espacio de nombres de Service Bus:
- Propietario de datos de Azure Service Bus: use este rol para conceder acceso completo a los recursos de Service Bus.
- Emisor de datos de Azure Service Bus: use este rol para proporcionar acceso de envío a un espacio de nombres de Service Bus y sus entidades.
- Receptor de datos de Azure Service Bus: use este rol para proporcionar acceso de recepción al espacio de nombres de Service Bus y sus entidades.
Ámbito de recursos
Antes de asignar un rol de Azure a una entidad de seguridad, determine el ámbito de acceso que debería tener la entidad de seguridad. Los procedimientos recomendados dictan que siempre es mejor conceder únicamente el ámbito más restringido posible.
En la lista siguiente se describen los niveles en los que puede definir el ámbito de acceso a recursos Service Bus, empezando por el ámbito más restringido:
Cola, tema o suscripción: la asignación de roles se aplica a la entidad de Service Bus específica. Actualmente, Azure Portal no admite la asignación de usuarios, grupos o identidades administradas a los roles de Azure de Service Bus en el nivel de suscripción del tema.
Espacio de nombres de Service Bus: la asignación de roles abarca toda la topología de Service Bus en el espacio de nombres y en la cola o suscripción de tema que tiene asociada.
Grupo de recursos: la asignación de roles se aplica a todos los recursos de Service Bus del grupo de recursos.
Suscripción de Azure: la asignación de roles se aplica a todos los recursos de Service Bus de todos los grupos de recursos de la suscripción.
Nota:
Tenga en cuenta que las asignaciones de roles de Azure pueden tardar hasta cinco minutos en propagarse.
Para más información sobre cómo se definen los roles integrados, consulte Descripción de definiciones de roles. Para más información acerca de la creación de roles personalizados de Azure, consulte Roles personalizados de Azure.
Autenticación desde una aplicación
Una ventaja clave del uso de Microsoft Entra ID con Service Bus es que ya no necesita almacenar las credenciales en el código. En su lugar, puede solicitar un token de acceso de OAuth 2.0 desde la Plataforma de identidad de Microsoft. Microsoft Entra autentica la entidad de seguridad (un usuario, un grupo, una entidad de servicio o una identidad administrada para los recursos de Azure) que ejecuta la aplicación. Si la autenticación se realiza correctamente, Microsoft Entra devuelve el token de acceso a la aplicación y la aplicación puede entonces usar dicho token para autorizar las solicitudes de Service Bus.
En las secciones siguientes se muestra cómo configurar su aplicación web o aplicación nativa para la autenticación con la Plataforma de identidad de Microsoft 2.0. Para obtener más información sobre la Plataforma de identidad de Microsoft 2.0, consulte la Introducción a la Plataforma de identidad de Microsoft (v2.0).
Para información general sobre el flujo de concesión de código OAuth 2.0, consulte Autorización del acceso a aplicaciones web de Microsoft Entra mediante el flujo de concesión de código OAuth 2.0.
Registro de la aplicación con un inquilino de Microsoft Entra
El primer paso para usar Microsoft Entra ID con el fin de autorizar las entidades de Service Bus es registrar la aplicación cliente con un inquilino de Microsoft Entra desde Azure Portal. Al registrar la aplicación cliente, facilita información sobre la aplicación a AD. Microsoft Entra ID proporciona un id. de cliente (también denominado id. de aplicación) que se puede usar para asociar la aplicación con el runtime de Microsoft Entra. Para más información sobre el identificador de cliente, consulte Objetos de aplicación y de entidad de servicio de Microsoft Entra ID.
Siga los pasos descritos en Inicio rápido: Registro de una aplicación con la Plataforma de identidad de Microsoft para registrar la aplicación con Microsoft Entra ID.
Nota:
Si registra la aplicación como una aplicación nativa, puede especificar cualquier URI válido para el URI de redirección. Para las aplicaciones nativas, no es necesario que este valor sea una dirección URL real. Para las aplicaciones web, el URI de redirección debe ser un URI válido, ya que especifica la dirección URL a la que se proporcionan los tokens.
Una vez que ha registrado su aplicación, verá el id. de la aplicación (o id. de cliente) y Id. de directorio (inquilino)en Configuración:
Importante
Anote los valores TenantId y ApplicationId. Necesitará estos valores para ejecutar la aplicación.
Para obtener más información sobre cómo registrar una aplicación con Microsoft Entra ID, consulte Integración de aplicaciones con Microsoft Entra ID.
Creación de un secreto de cliente
La aplicación necesita un secreto de cliente para demostrar su identidad al solicitar un token. Para agregar el secreto de cliente, siga estos pasos.
Vaya a su registro de aplicaciones en Azure Portal si todavía no se encuentra en la página.
Seleccione Certificados y secretos en el panel izquierdo.
En Secretos de cliente, seleccione Nuevo secreto de cliente para crear un nuevo secreto.
Proporcione una descripción para el secreto, elija el intervalo de expiración deseado y, a continuación, seleccione Agregar.
Copie inmediatamente el valor del nuevo secreto en una ubicación segura. El valor completo se le muestra solo una vez.
Permisos para la API de Service Bus
Si la aplicación de ejemplo es una aplicación de consola, debe registrar una aplicación nativa y agregar permisos de API para Microsoft.ServiceBus en el conjunto de permisos necesarios. Las aplicaciones nativas también necesitan un URI de redireccionamiento en Microsoft Entra ID, que actúa como identificador. No es necesario que este URI sea un destino de red. Use https://servicebus.microsoft.com
para este ejemplo, dado que el ejemplo de código ya utiliza ese URI.
Asignación de roles de Azure mediante Azure Portal
Asigne uno de los roles de Service Bus a la entidad de servicio de la aplicación en el ámbito deseado (entidad, espacio de nombres de Service Bus, grupo de recursos, suscripción de Azure). Para asignar roles, consulte Asignación de roles de Azure mediante Azure Portal.
Una vez que defina el rol y su ámbito, puede probar este comportamiento con el ejemplo de GitHub.
Autenticación del cliente de Service Bus
Una vez que haya registrado la aplicación y se le haya concedido permisos para enviar o recibir datos en Azure Service Bus, puede autenticar el cliente con la credencial de secreto de cliente, lo que le permitirá realizar solicitudes en Azure Service Bus.
Para ver una lista de escenarios en los que se admite la adquisición de tokens, consulte la sección Escenarios del repositorio de GitHub Biblioteca de autenticación de Microsoft (MSAL) para .NET.
Con la biblioteca Azure.Messaging.ServiceBus más reciente, puede autenticar ServiceBusClient con ClientSecretCredential, que se define en la biblioteca Azure.Identity.
TokenCredential credential = new ClientSecretCredential("<tenant_id>", "<client_id>", "<client_secret>");
var client = new ServiceBusClient("<fully_qualified_namespace>", credential);
Si usa los paquetes anteriores de .NET, consulte los ejemplos de RoleBasedAccessControl en el repositorio de ejemplos de azure-service-bus.
Pasos siguientes
- Para más información sobre Azure RBAC, consulte ¿Qué es el control de acceso basado en rol de Azure (Azure RBAC) de Azure?
- Para información sobre cómo asignar y administrar las asignaciones de roles de Azure con Azure PowerShell, la CLI de Azure o la API de REST, consulte estos artículos:
- Incorporación o eliminación de asignaciones de roles de Azure con Azure PowerShell
- Incorporación o eliminación de asignaciones de roles de Azure mediante la CLI de Azure
- Incorporación o eliminación de asignaciones de roles de Azure mediante la API REST
- Incorporación o eliminación de asignaciones de roles de Azure mediante plantillas de Azure Resource Manager
Para obtener más información sobre la mensajería de Service Bus, consulte los siguientes temas: