Exportar (0) Imprimir
Expandir todo

Autenticación y autorización del Service Bus con el servicio de control de acceso

Service Bus de Windows Azure admite el uso de Active Directory Access Control de Windows Azure (también conocido como Access Control Service o ACS) para la autorización de operaciones de Service Bus.

Active Directory Access Control de Windows Azure (también conocido como Access Control Service o ACS)

ACS facilita la autenticación, es decir, establece la identidad del llamador. Para ello, ACS tiene dos medios. Establece la identidad basándose en una lista de identidades de servicio (o cuentas) con ámbitos de espacio de nombres usando un esquema clásico de nombre de usuario y contraseña, o delega estableciendo la identidad en un proveedor de identidad externo, como los Servicios de federación de Active Directory (ADFS), Windows Live ID, Facebook, Google ID, Yahoo ID u OpenID.

Una vez establecida la identidad, ACS tiene (o recibe) numerosas “notificaciones” acerca de la identidad. Estas notificaciones realizan declaraciones acerca de la persona (o la cuenta no personal) y están firmadas digitalmente por el proveedor de identidad que ha emitido las notificaciones, lo cual proporciona garantías a ACS sobre que las notificaciones son correctas o al menos cumplen las normas de gobierno del emisor. En otras palabras, un conjunto de notificaciones que afirman que la identidad representada es “Bill Gates, Presidente de Microsoft Corporation” es probablemente más fiable si la emite la pasarela de ADFS de Microsoft y menos si lo emite un tercero. Las notificaciones que están disponibles de manera uniforme en todos los proveedores de identidad y también para las identidades del servicio incorporadas de ACS son la notificación del proveedor (que identifican al propio proveedor) y la notificación “nameidentifier”, que es un identificador exclusivo del proveedor para la identidad dada.

En segundo lugar, ACS facilita la autorización al permitir que las notificaciones emitidas por proveedores de identidades se asignen a notificaciones que el "usuario de confianza" comprende. Service Bus es este usuario de confianza, es decir, confía en ACS para controlar la autenticación y la autorización. La asignación de notificaciones tiene dos fines: en primer lugar, normaliza las notificaciones desde gran cantidad de distintas “jergas” de notificaciones en un único conjunto de notificaciones que comprende el servicio y, en segundo lugar, la asignación actúa como conjunto de reglas de autorización. Si no hay asignación para una identidad dada a un conjunto de notificaciones que comprenda el servicio, la identidad no tiene acceso al servicio.

La autenticación y la autorización siempre fluyen a través del cliente y el cliente es el único componente que requiere la visibilidad de red directa para todas las partes. Por ejemplo, es posible usar un servicio ADFS que no esté expuesto fuera del firewall corporativo junto con ACS, puesto que ACS y ADFS nunca hablan entre sí directamente. Cuando el cliente desee realizar una operación en un recurso protegido, como enviar un mensaje a una cola del Service Bus, necesita obtener pruebas de que esté autorizado a hacerlo. Dicha prueba se obtiene, de ACS, en forma de “token”. El token es simplemente un contenedor para un conjunto de notificaciones y está firmado digitalmente por el emisor. Si ACS está configurado para establecer la identidad usando un proveedor de identidad externo, como ADFS, hay al menos dos tokens en juego. El primer token se obtiene de un proveedor de identidad tal como ADFS, que proporciona uno de muchos tipos de pruebas de la identidad del usuario como entrada. Dicho token se entrega posteriormente a ACS, que lo evalúa, ejecuta las reglas y lo emite para el usuario de confianza.

Service Bus y ACS

Service Bus y ACS están especialmente relacionados, ya que cada espacio de nombres de servicio de Service Bus está emparejado con un espacio de nombres de servicio de ACS del mismo nombre, con el sufijo “–sb”. El motivo para esta especial relación es el modo con que Service Bus y ACS administran su mutua relación de confianza y los secretos criptográficos asociados.

Service Bus puede federarse con ACS V1 y con ACS V2. Todos los espacio de nombres de servicio creados antes de la versión de septiembre de 2011 de Service Bus están federados con ACS V1, y todos los espacio de nombres de servicio creados después de la actualización del servicio están federados con ACS V2. Este tema solo abarca ACS V2, que es la versión actual del servicio ACS.

Dentro del “-sb” ACS espacio de nombres de servicio, que puede explorar desde el portal de Windows Azure seleccionando el Service Bus espacio de nombres de servicio y haciendo a continuación clic en el icono ACS de la cinta, se encuentra una definición de usuario de confianza “ServiceBus” después de la navegación por “aplicaciones de usuario de confianza”. La definición del usuario de confianza tiene una asignación del valor de “Dominio kerberos” a la raíz del espacio de nombres de servicio del Service Bus (usando el esquema “http”) y configura el tipo de token en “SWT” y el tiempo de expiración de los tokens en 1200 segundos. Además, las claves de firma no se pueden administrar ni se puede acceder a ellas a través del portal o del API.

Asociado con la definición de usuario de confianza del “ServiceBus” está un “Grupo de reglas predeterminado para Service Bus” que contiene la asignación básica que permite al “propietario” de un espacio de nombres de servicio actuar como superusuario en el espacio de nombres de servicio. El grupo de reglas contiene, por defecto, tres sencillas reglas que asignan la notificación “nameidentifier” de la entrada para la identidad del servicio a las tres notificaciones de permisos que comprende el Service Bus: “Send” para todas las operaciones de envío, “Listen” para abrir agentes de escucha o recibir mensajes y “Manage” para observar o administrar el estado del inquilino de Service Bus. Service Bus pasa por alto todas las demás notificaciones contenidas en tokens emitidos para él. La identidad del servicio del “propietario” es una identidad de servicio regular en el ACS de ACS. Se puede, y se recomienda, crear más. De hecho, el uso de la identidad “propietario” debe restringirse para realizar tareas administrativas.

Definición y ámbito del usuario de confianza

Cuando un cliente solicita un token de autorización para enviar un mensaje a una cola que reside, por ejemplo, en https://tenant.servicebus.windows.net/my/test, la solicitud del token incluirá una forma normalizada de la dirección de destino como el dominio kerberos de destino pretendido. Esta “normalización” solo usa un esquema URI común entre todos los protocolos. En consecuencia, la solicitud de un token para interactuar con una entidad del Service Bus que resida en https://tenant.servicebus.windows.net/my/test o en sb://tenant.servicebus.windows.net/my/test siempre se realizará usando un URI de dominio kerberos mediante el esquema “http” http://tenant.servicebus.windows.net/foo/bar. En consecuencia, todas las definiciones de usuario de confianza deberán usar asimismo el esquema URI “normalizado” http para el URI de dominio kerberos.

Cuando la solicitud llega a ACS, ACS comparará la URI de dominio kerberos con definiciones de usuarios de confianza mediante una “comparación de prefijo más largo”, lo que significa que el usuario de confianza cuya dirección “URI de dominio kerberos” es el prefijo más largo disponible de la dirección para la que se solicita el token, la definición del usuario de confianza y las definiciones de regla asociadas están seleccionadas y se ejecutan. La definición predeterminada del usuario de confianza “ServiceBus” tiene como ámbito todo el espacio de nombres de servicio del Service Bus correspondiente, es decir, que el URI de dominio kerberos, correspondiente a la dirección raíz de espacio de nombres de servicio del Service Bus es un prefijo a todas las posibles direcciones en un espacio de nombres de servicio del Service Bus. Debido a ello, las definiciones de reglas habilitadas en esta definición de parte de confianza otorgan total acceso a todo el espacio de nombres de servicio del Service Bus.

El modo de crear un conjunto con ámbito de reglas de autorización para una cola que resida, por ejemplo, en https://tenant.servicebus.windows.net/my/test, es crear una nueva definición de usuario de confianza, proporcionando la dirección de la cola o un prefijo de dicha dirección como URI de dominio kerberos de la nueva definición, bien a través del portal de ACS o bien del API de administración de ACS. En el portal, los pasos son:

  • En Aplicaciones de usuario de confianza, haga clic en Agregar.

  • Escriba algún nombre para mostrar, como MyTest.

  • Escriba http://tenant.servicebus.windows.net/MyTest como URI de dominio kerberos para el ámbito.

  • Elija SWT como formato del token.

  • Defina Directiva de cifrado en Ninguna.

  • Defina Duración del token en 1200 segundos.

  • Haga clic en Guardar.

El resultado es una definición de usuario de confianza que es exclusiva para esta dirección. Dado que su URI de dominio kerberos es un sufijo de la definición de usuario de confianza “ServiceBus” integrada, la definición hereda automáticamente las claves de firma correctas de modo que Service Bus confíe en los tokens emitidos basándose en la nueva definición. No obstante, dado que no hay reglas asociadas para la nueva definición de usuario de confianza, hasta ahora, nadie podrá obtener acceso a la cola, ni siquiera el “propietario”, pues no hay herencia implícita automática de reglas entre definiciones de usuario de confianza, ni siquiera si forman una jerarquía.

Después de crear la nueva definición, habrá un “Grupo de reglas predeterminado para <displayname>” en la sección del portal de ACS. Este nuevo grupo está vacío de manera predeterminada. Con el fin de permitir el acceso a la cola, es necesario agregar reglas al grupo, lo cual se explica en la siguiente sección. Alternativamente, se puede habilitar un grupo de reglas ya existente con reglas para la definición del usuario de confianza. Cada grupo de reglas puede considerarse una lista de control de acceso independiente que se puede habilitar en cualquier lugar en la jerarquía del usuario de confianza. Para permitir la herencia similar a la de un sistema de archivos, por ejemplo para heredar las reglas predeterminadas de la raíz del espacio de nombres de servicio del Service Bus, simplemente se pueden habilitar el “Grupo de reglas predeterminado para ServiceBus” correspondiente y cualquier otro grupo de reglas en la definición del usuario de confianza, lo cual requiere la activación de la casilla derecha en la sección “Grupos de reglas” de la definición de Usuario de confianza en el portal. En aquellos casos en los que deba aplicarse un conjunto común de reglas de acceso a través de numerosos recursos, por ejemplo reglas comunes para un conjunto de recursos paralelos tales como colas hermanas en http://tenant.servicebus.windows.net/my/test y http://tenant.servicebus.windows.net/my/zoo, la definición del usuario de confianza también se puede ubicar en el ámbito de la rama de espacio de nombres de servicio compartida, como http://tenant.servicebus.windows.net/my.

En otros casos, los escenarios pueden hacer que se administre el control de acceso de manera diferente para aspectos de la misma entidad del Service Bus, como diferentes permisos en diferentes suscripciones de un tema. En estos casos, se puede crear una definición de usuario de confianza con el ámbito de un nombre de suscripción en particular, como http://tenant.servicebus.windows.net/my/test/subscriptions/sub1/, y hacer que dicha definición contenga las reglas que se apliquen solamente a la suscripción nombrada en particular.

Definición de reglas

Las reglas se definen en grupos y generalmente asignan una notificación de entrada con una de salida. Todas las reglas de un grupo generan un resultado combinado, por lo que si hay tres reglas coincidentes para un conjunto de notificaciones dado que origine tres notificaciones de salida distintas, el token de autorización emitido contendrá las tres notificaciones. Para Service Bus, las tres notificaciones de permiso son “Send” para todas las operaciones de envío, “Listen” para abrir agentes de escucha o recibir mensajes y “Manage” para observar o administrar el estado del inquilino de Service Bus. Para ser precisos, “Send”, “Listen” y “Manage” son los valores permitidos de la acción “net.windows.servicebus.action” de tipo de notificación. Para crear una regla para Service Bus, se requiere asignar una notificación de entrada, como el nameidentifier de una identidad de servicio, a la notificación de permiso que se desee. Para conceder a la identidad de servicio “contoso” el permiso para "enviar" en una cola, la definición de regla deberá consiguientemente asignar la notificación del nameidentifier del emisor con el valor “contoso” a una notificación de salida personalizada del tipo “net.windows.servicebus.action” con el valor “Send”. Otorgar a la identidad de servicio las tres notificaciones de permiso requiere tres reglas diferentes. El objetivo de tener solo tres notificaciones de permiso es limitar la complejidad de la definición de reglas.

Uso de proveedores de tokens

Un proveedor de tokens es una construcción genérica en la API administrada de .NET para Service Bus que permite la conversión de cierta forma de credencial en un token de autorización emitido por el servicio ACS, que después se puede pasar a Service Bus para realizar la operación deseada. TokenProvider es una clase base abstracta con tres implementaciones concretas, accesible mediante patrones de diseño Factory Method para los escenarios más básicos:

  • Secreto compartido: permite la obtención de un token basándose en una identidad de servicio (y en la clave compartida asociada con dicha identidad) que se ha definido en el espacio de nombres relacionado “-sb” del espacio de nombres de servicio de Service Bus en ACS. La identidad del servicio preaprovisionada creada cuando se crea el espacio de nombres de servicio se denomina “propietario” y su secreto compartido está disponible a través del portal de administración.

  • Simple Web Token (SWT): permite la obtención de un token basado en un token SWT anteriormente obtenido y transferido a ACS mediante el proveedor de tokens. El token se transmite a ACS como token binario usando una solicitud WS-Trust/WS-Federation RST/RSTR. Consulte la documentación de ACS para obtener información sobre el modo de configurar los proveedores de WS-Federation.

  • SAML: permite la obtención de un token basado en un token SAML anteriormente obtenido y transferido a ACS mediante el proveedor de tokens. El token se transmite a ACS como solicitud WS-Trust/WS-Federation RST/RSTR. Consulte la documentación de ACS para obtener información sobre el modo de configurar los proveedores de WS-Federation.

Las API MessagingFactory, NamespaceManager y TransportClientEndpointBehavior del Service Bus aceptan las instancias de TokenProvider. Se llama al proveedor de tokens cuando se requieren tokens, lo que incluye escenarios en los que una conexión de larga duración debe obtener un nuevo token una vez que el existente ha superado su expiración (que es de manera predeterminada 1200 segundos). Los escenarios de federación que requieren la interacción del usuario requieren la implementación de un proveedor de tokens personalizado.

Como ejemplo, un proveedor de tokens personalizado para permitir a un determinado usuario de Facebook enviar mensajes a una cola determinada deberá presentar al usuario, a través de ACS con la adecuada interfaz de usuario de Facebook, establecer la identidad de Facebook, redirigir mediante ACS para intercambiar el token de Facebook por un token de ACS para Service Bus y, a continuación, extraer el token de ACS según se redirecciona la solicitud a la aplicación local. El sitio Codeplex del Service Bus contendrá una colección cada vez mayor de ejemplos de proveedores de tokens para la personalización.

Adiciones de comunidad

Mostrar:
© 2014 Microsoft