Esta documentación está archivada y no tiene mantenimiento.

Notas de la versión

Publicada: abril de 2011

Actualizado: junio de 2015

Se aplica a: Azure

En este tema se describen las nuevas características de las versiones de Active Directory Access Control de Microsoft Azure (también conocido como Access Control Service o ACS), se explica en qué se diferencia cada versión del producto de las anteriores y se destacan los cambios importantes que pueden afectar al código escrito para una versión anterior.

ACS ha implementado una característica para ayudar a los propietarios de espacios de nombres de ACS a migrar sus configuraciones de proveedor de identidades de Google de OpenID 2.0 a OpenID Connect. Los clientes tendrán hasta el 1 de junio de 2015 para migrar sus espacios de nombres de ACS a OpenID Connect y hasta el 1 de enero de 2017 para migrar su código de back-end para usar identificadores de OpenID Connect.Si no se llevan a cabo las acciones necesarias antes de estas fechas límite, se interrumpirá el funcionamiento de las aplicaciones. Para obtener instrucciones detalladas, vea Migración de espacios de nombres ACS a OpenID Connect de Google.

A partir de 19 de mayo de 2014, los nuevos espacios de nombres de ACS no pueden usar Google como proveedor de identidades. Esto no afecta a los espacios de nombres ACS que usaban Google y se registraron antes del 19 de mayo de 2014. Esta nueva limitación existe porque Google está en proceso de cancelar la compatibilidad con OpenID 2.0, de la que depende ACS, y ya no permite registrar nuevas aplicaciones. Los espacios de nombres ACS existentes que usaban Google seguirán funcionando hasta el 20 de abril de 2015. Si su aplicación requiere compatibilidad con cuentas de Google, le recomendados que la registre con ellos directamente.

Si un usuario intenta iniciar sesión en un nuevo espacio de nombres ACS con su cuenta de Google, será redirigido a una página de error con el código HTTP 400.

Nuevo espacio de nombres ACS y error de Google

Para mejorar la disponibilidad y el rendimiento de ACS para todos los usuarios, ACS ha implementado un límite de 30 solicitudes de token por segundo por cada espacio de nombres. Si un espacio de nombres supera este límite durante un período prolongado, ACS rechazará las solicitudes de token del espacio de nombres durante el intervalo y devolverá el error HTTP 429/ACS90055 “Demasiadas solicitudes”. Para obtener más información, vea Lmitaciones del servicio ACS y Códigos de error de ACS.

Nuevas características

La actualización de diciembre de 2012 de ACS incluye las siguientes nuevas características:

Admite el cierre de sesión única federada con el protocolo WS-Federation

Las aplicaciones web que usan ACS para habilitar el inicio de sesión único (SSO) con proveedores de identidades que usan el protocolo WS-Federation ahora pueden aprovechar las capacidades de cierre de sesión único. Cuando un usuario cierra la sesión de una aplicación web, ACS puede cerrar automáticamente la sesión del proveedor de identidades y de otras aplicaciones de usuario de confianza que usen el mismo proveedor de identidades.

Esta característica está habilitada para proveedores de identidades de WS-Federation, incluido Servicios de federación de Active Directory 2.0 y Windows Live ID (cuenta de Microsoft). Para habilitar el cierre de sesión único, ACS realiza las tareas siguientes para los extremos del protocolo WS-Federation:

  • ACS reconoce mensajes de wsignoutcleanup1.0 de proveedores de identidades y responde mediante el envío de mensajes de wsignoutcleanup1.0 a aplicaciones de usuario de confianza.

  • ACS reconoce mensajes de wsignout1.0 y de wreply de aplicaciones de usuario de confianza y responde mediante el envío de mensajes de wsignout1.0 a proveedores de identidades y mensajes de wsignoutcleanup1.0 a aplicaciones de usuario de confianza.

Para obtener más información, consulte Ejemplo de código: ASP.NET MVC 4 con cierre de sesión federado y el documento sobre autenticación pasiva para ASP.NET en WIF.

Soporte descontinuado para ACS 1.0

Access Control Service 1.0 se ha descontinuado a partir de esta versión, incluida la compatibilidad para migrar de Access Control Service 1.0 a Access Control Service 2.0.

Navegación a los Espacio de nombres Access Control en el nuevo Portal de administración de Azure

El nuevo Portal de administración de Azure (http://manage.WindowsAzure.com) incluye una ruta al conocido portal de administración de ACS, donde puede crear y administrar Espacio de nombres Access Control.

Para navegar hasta el portal de administración de ACS:

  1. Vaya al Portal de administración de Microsoft Azure (https://manage.WindowsAzure.com), inicie sesión y haga clic en Active Directory. (Sugerencia para solución de problemas: falta el elemento "Active Directory" o no está disponible)

  2. Haga clic en un Espacio de nombres Access Control y, después, haga clic en Administrar.

Para crear un espacio de nombres Access Control, haga clic en Nuevo, Servicios de aplicaciones, Access Control y, a continuación, en Creación rápida. (O haga clic en espacios de nombres Access Control antes de hacer clic en Nuevo.)

Para obtener ayuda con las tareas de administración de ACS en el Portal de administración de Microsoft Azure, haga clic en Active Directory y luego en Ayuda (?). (O haga clic en Active Directory, haga clic en espacios de nombres Access Control y, a continuación, haga clic en Ayuda.)

Navegación al Espacio de nombres Access Control para un bus de servicio

Al crear un espacio de nombres de Bus de servicio en el , el portal crea automáticamente un Espacio de nombres Access Control para el bus de servicio.

Para configurar y administrar el Espacio de nombres Access Control para un bus de servicio:

  1. Inicie sesión en el Portal de administración de Azure.

  2. Haga clic en Bus de servicio y seleccione un bus de servicio.

  3. Haga clic en Clave de acceso y, después, en Abrir Portal de administración de ACS.

Para comprobar que el Espacio de nombres Access Control está asociado con el bus de servicio, consulte el campo Espacio de nombres de servicio (en la parte superior de la página Access Control Service). El nombre del espacio de nombres está formado por el nombre del bus de servicio con el sufijo “-sb”.

Para obtener más información, vea Procedimiento: Administrar el espacio de nombres de control de acceso para un bus de servicio.

Mejoras del portal de administración de ACS para visualizar claves de proveedores de identidades de WS-Federation y ocultar contraseñas

Esta versión contiene dos mejoras relacionadas con la visualización y el uso de certificados, claves y contraseñas en el portal de administración de ACS 2.0:

  • Los certificados de firma son ahora visibles en la sección Editar proveedor de identidades de WS-Federation: anteriormente, los certificados importados de metadatos de WS-Federation que se usaban para validar la firma de tokens emitidos por el proveedor de identidades no eran visibles en el portal de administración de ACS. Ahora, en la sección Editar proveedor de identidades de WS-Federation se muestra información sobre los certificados importados, incluidas las fechas de expiración y el estado. Estos certificados se pueden actualizar ahora con la nueva casilla “Reimportar datos de URL de metadatos de WS-Federation al guardar”.

  • Las contraseñas y las claves de firma simétricas ahora están ocultas de manera predeterminada: para evitar que se muestren de forma accidental contraseñas y claves simétricas, estos valores ahora están ocultos de manera predeterminada en las pantallas Editar de todo el portal. Para mostrar de forma intencional el valor de una contraseña o de una clave simétrica (por ejemplo, para que se pueda copiar en una aplicación), ahora es necesario presionar el botón “Mostrar contraseña” o “Mostrar clave”.

Posibilidad de federar inquilinos de directorio con Espacio de nombres Access Control

Los inquilinos de Azure Active Directory ahora se pueden usar como proveedores de identidades en Espacio de nombres Access Control. Esto permite muchos escenarios, como habilitar la aplicación web para que acepte identidades de organizaciones de inquilinos de directorio e identidades de consumidor de proveedores sociales (como cuentas de Facebook, Google, Yahoo, Microsoft o cualquier otro proveedor de OpenID). Encontrará instrucciones detalladas para implementar el escenario en esta entrada sobre cómo aprovisionar un inquilino de Azure Active Directory como un proveedor de identidades en un espacio de nombres ACS.

Compatibilidad con el protocolo SAML 2.0 para aplicaciones de usuario de confianza (Developer Preview)

ACS ahora es compatible con el protocolo SAML 2.0 para emitir tokens a aplicaciones de usuario de confianza. La compatibilidad con el protocolo SAML 2.0 se ha publicado como una versión Developer Preview, lo que quiere decir que la implementación del protocolo SAML 2.0 aún está sujeta a cambios. Para obtener más información, consulte Developer Preview: Protocolo SAML.

Problemas conocidos

En la actualización de diciembre de 2012 de Active Directory Access Control de Microsoft Azure (también conocido como Access Control Service o ACS) se identificaron los siguientes problemas conocidos:

Los coadministradores de Azure pueden ahora administrar los Espacio de nombres Access Control. Sin embargo, es necesario tomar medidas para propagar los coadministradores ya existentes en Espacio de nombres Access Control ya existentes.

Antes de la actualización de noviembre de 2012, solucionamos un problema donde, de manera predeterminada, solo el administrador principal del servicio de Azure podía administrar Espacio de nombres Access Control creados en la suscripción. Si un coadministrador de Azure intentaba acceder al portal de administración de ACS para un Espacio de nombres Access Control, recibía uno de los siguientes códigos de error de ACS:

  • ACS50000: Se produjo un error en la emisión de un token.

  • ACS60000: Se produjo un error al procesar reglas para un usuario de confianza con el emisor “uri:WindowsLiveID”

  • ACS60001: No se generaron notificaciones de salida durante el procesamiento de las reglas.

Este problema se ha solucionado ahora para los nuevos Espacio de nombres Access Control creados por cualquier administrador o coadministrador del servicio de Azure. Pero los clientes con espacios de nombres que existían antes de la corrección necesitan completar la siguiente solución alternativa para que los datos del coadministrador se propaguen a dichos espacios de nombres:

  1. Inicie sesión en el portal de Azure (https://windows.azure.com/) con credenciales de administrador de cuenta o de administrador de servicio.

  2. Quite y vuelva a agregar al coadministrador; para ello, siga los pasos que se indican en Agregar un coadministrador a una suscripción de Azure (http://msdn.microsoft.com/es-es/library/azure/gg456328.aspx)

  3. Cierre la sesión en el portal de Azure y vuelva a iniciarla con las credenciales de coadministrador. De esta forma, podrá administrar los Espacio de nombres Access Control.

En septiembre de 2012, Active Directory Access Control de Microsoft Azure (también conocido como Access Control Service o ACS) recibió una actualización con los cambios siguientes:

El valor entityID publicado en los metadatos de WS-Federation emitidos por ACS es ahora en minúscula de manera coherente

El atributo “entityID” en los metadatos de WS-Federation publicados por Espacio de nombres Access Control ahora siempre está en minúscula. En versiones anteriores, se usaba el espacio de nombres con las mayúsculas y minúsculas usadas al crearlo en el portal de Azure. El atributo “entityID” identifica el Espacio de nombres Access Control a las aplicaciones de usuario de confianza y estos son algunos ejemplos:

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://lowercase-namespace.accesscontrol.windows.net/" ID="_e4a0006c-c23c-41c0-8f87-baa110afaf1d">

Este cambio era necesario para solucionar posibles problemas de validación de tokens en los que la diferencia del uso de mayúsculas del Espacio de nombres Access Control en el token emitido por ACS (que siempre era en minúsculas) no coincidía con el uso de mayúsculas del Espacio de nombres Access Control importado por el usuario de confianza. Los usuarios de confianza que usan Windows Identity Foundation no se ven afectados por los problemas de distinción entre mayúsculas y minúsculas.

Los certificados X.509 cargados en ACS ahora tienen una restricción de tamaño de clave pública de 4096 bits

Todos los certificados X.509 cargados en un Espacio de nombres Access Control a través del portal de administración o el servicio de administración de ACS ahora deben tener un tamaño de clave pública superior a 4096 bits. Esto incluye a certificados usados para la firma, el cifrado y el descifrado de tokens.

En Windows, se puede comprobar el tamaño de la clave pública de un certificado si abre el archivo del certificado (.CER), selecciona la pestaña “Detalles” y activa el valor del campo “Clave pública”. Los certificados que usan el algoritmo de firma sha256RSA segura tendrán una clave pública de 2048 bits.

Los certificados existentes que tengan un tamaño de clave superior a 4096 bits seguirán funcionando con ACS, pero estos certificados no se pueden volver a guardar en ACS hasta que se reemplacen por un certificado compatible.

Cambio secundario en el algoritmo de selección de “clave principal” que se usa cuando ACS firma un token con un certificado X.509

En el portal de administración y el servicio de administración de ACS existe el campo “Convertir en principal” para los certificados de firma de tokens que, cuando se selecciona, hace que ACS firme tokens con dicho certificado. Con esta versión, si ningún certificado de firma configurado tiene activado el campo “Convertir en principal”, el Espacio de nombres Access Control usará el certificado de firma de tokens no principal que tenga la fecha de inicio válida más temprana para firmar el token. ACS sigue sin firmar tokens con un certificado de firma de tokens no principal si existe un certificado principal que no es válido o ha expirado.

JWT Beta: Cambio en el comportamiento de firma al usar una clave o certificado de espacio de nombres global para firmar un token JWT

Cuando se publicó la compatibilidad en fase de pruebas con el formato JSON Web Token (JWT) en junio de 2012, ACS usó el orden de precedencia siguiente para determinar la clave que debe usarse para firmar los tokens JWT emitidos a cada aplicación de usuario de confianza:

  • Clave de firma simétrica asignada a un usuario de confianza, si está disponible

  • Certificado de firma X.509 asignado a un usuario de confianza, si está disponible

  • Clave de firma simétrica asignada al Espacio de nombres Access Control

  • Certificado de firma X.509 asignado al Espacio de nombres Access Control

A partir de esta versión, las claves simétricas que abarquen todo el espacio de nombres ya no se admitirán para firmar tokens JWT. A continuación, encontrará el nuevo orden de precedencia para firmar tokens JWT:

  • Clave de firma simétrica asignada a un usuario de confianza, si está disponible

  • Certificado de firma X.509 asignado a un usuario de confianza, si está disponible

  • Certificado de firma X.509 asignado al Espacio de nombres Access Control

En junio de 2012, ACS recibió una actualización que contenía esta nueva característica:

El formato JWT ahora está disponible para aplicaciones de usuario de confianza (Beta)

Esta actualización es la primera versión que admite el formato JSON Web Token (JWT) BETA en ACS. JWT es un formato de token ligero con codificación JSON que se puede firmar con un certificado X.509 o con una clave simétrica, y que puede ser emitido por ACS a aplicaciones de usuario de confianza en cualquiera de los protocolos siguientes:

  • OAuth 2.0

  • WS-Federation

  • WS-Trust

El formato de token JWT es ahora una opción que se puede seleccionar en la sección Aplicaciones de usuario de confianza de Portal de administración de ACS y, además, también se puede configurar mediante el Servicio de administración de ACS.

Para obtener más información sobre el formato de token JWT, consulte la especificación de JSON Web Token. En el futuro, estarán disponibles ejemplos de código ACS con tokens JWT.

ImportantImportante
La compatibilidad de JWT se considera en fase “Beta” en ACS, lo que quiere decir que todos los detalles de la implementación de JWT están sujetos a cambios. Los desarrolladores pueden realizar pruebas con este formato de token. Pero JWT no debe usarse en servicios de producción, ya que el comportamiento puede cambiar sin aviso previo.

A principios de mayo de 2012, ACS recibió una actualización con el cambio siguiente:

Cambios en las propiedades de id. de entidad expuestas a través del servicio de administración

El servicio de administración de ACS expone actualmente una propiedad de identificador para cada tipo de entidad admitido, como se describe en Referencia de API de servicio de administración de ACS. Estas propiedades de identificador se establecen automáticamente y son administradas por ACS.

En esta actualización del servicio, ACS se migra a un esquema de base de datos distinto y, como resultado, estos identificadores expuestos a través del servicio de administración cambiarán para todos los tipos de entidad.

No es común (y, en general, no se lo recomendamos) que las aplicaciones almacenen o tengan una dependencia codificada de forma rígida de estos identificadores para consultar entidades específicas a través del servicio de administración. En su lugar, le recomendamos que los tipos de entidad RelyingParty, ServiceIdentity, RuleGroup e Issuer se consulten con la propiedad Nombre y, además, que otros tipos de entidad se consulten con un id. de entidad principal (p. ej., RuleGroupId en el caso de reglas o IssuerId en el caso de proveedores de identidades).

Cambios en la intercalación de base de datos para el procesamiento de reglas

Para ampliar la compatibilidad con idiomas internacionales y para mejorar la seguridad, esta versión de ACS actualiza la intercalación de base de datos SQL subyacente usada para comparar notificaciones de entrada de SQL_Latin1_General_CP1_CI_AS a Latin1_General_100_BIN2. Este cambio permite que ACS sea compatible con más juegos de caracteres y con combinaciones de juegos de caracteres. En las aplicaciones que dependen de notificaciones de entrada que contienen cadenas con varios juegos de caracteres, que no son compatibles con SQL_Latin1_General_CP1_CI_AS, se pueden mostrar notificaciones distintas o adicionales como resultado de esta nueva intercalación. Los clientes que quieran aprovechar esta nueva capacidad pueden validar la compatibilidad de sus aplicaciones con la nueva intercalación de SQL.

El 25 de enero de 2012, ACS 2.0 recibió una actualización con los cambios siguientes:

En la versión anterior, ACS respondía con diferentes códigos de error cuando un cliente se autenticaba con un emisor inexistente (código de error: ACS50026) o cuando se proporcionaban credenciales incorrectas (código de error: ACS50006). Estos códigos de error se emitían anteriormente cuando un cliente intentaba autenticarse con un nombre de identidad de servicio no válido, o bien si usaba un token SWT o de SAML emitido por un proveedor de identidades no válido.

ACS devolverá los códigos de error ACS50008, ACS50009 o ACS50012 para una autenticación con errores en los casos de SWT, SAML y nombre de usuario y contraseña, respectivamente. Encontrará más información en la tabla siguiente:

 

Respuesta de autenticación Antes Una vez

Emisor inexistente

ACS50026 EmisorNoEncontrado

ACS50008 SWTnoVálido,

ACS50009 SAMLnoVálido, O BIEN

ACS50012 ErrorDeAutenticación

Credenciales incorrectos

ACS50006 FirmaNoVálida

Al igual que en la versión anterior, ACS respondía con diferentes códigos de error de OAuth 2.0 cuando un cliente se autenticaba con un emisor inexistente (cliente_no_válido) o con credenciales incorrectas (concesión_no_válida). Este comportamiento también se ha actualizado y ACS devolverá solicitud_no_válida cuando la solicitud de OAuth 2.0 tenga un formato incorrecto, cliente_no_válido si el cliente no puede autenticarse o si la aserción proporcionada para la autenticación no tiene el formato correcto o no es válida, y concesión_no_válida si el código de autorización no tiene el formato correcto o no es válido. Encontrará más información en la tabla siguiente:

 

Respuesta de autenticación Ejemplos Antes Una vez

Emisor inexistente

cliente_no_válido

cliente_no_válido

Credenciales incorrectos

SWT está firmado con una clave incorrecta. El id. de cliente y las credenciales no coinciden con los configurados en ACS.

concesión_no_válida

Error de autenticación

Error de validación de la URI de audiencia. Error de validación de certificado. La aserción de una identidad de servicio contiene notificaciones emitidas automáticamente.

concesión_no_válida

Aserción con formato incorrecto

Falta la firma de SWT. La aserción SAML no es un XML válido.

solicitud_no_válida

Código de autorización con formato incorrecto

concesión_no_válida

concesión_no_válida

Código de autorización no válido

concesión_no_válida

Solicitud de OAuth2 con formato incorrecto

solicitud_no_válida

solicitud_no_válida

Las notas de la versión para la actualización de julio de 2011 de ACS 2.0 contienen los elementos siguientes:

Todos los Espacio de nombres Access Control reciben automáticamente la actualización de julio de 2011. Esta actualización no contiene cambios en los requisitos previos de ACS para clientes nuevos o existentes. Para obtener más información sobre los requisitos previos actuales de ACS, consulte Requisitos previos de ACS.

La actualización de julio de 2011 a ACS contiene las siguientes nuevas características:

1. Las reglas ahora admiten hasta dos notificaciones de entrada

El motor de reglas de ACS ahora admite un nuevo tipo de regla que permite configurar hasta dos notificaciones de entrada, en lugar de solo una. Las reglas con dos notificaciones de entrada se pueden usar para reducir el número total de reglas necesarias para realizar funciones complejas de autorización de usuarios.

En el Portal de administración de ACS se puede especificar una nueva notificación de entrada; para ello, haga clic en Agregar una segunda notificación de entrada en el editor de reglas. En el servicio de administración, las reglas con dos notificaciones de entrada se pueden configurar con el tipo de entidad ReglaCondicional. Las reglas con una notificación de entrada aún se pueden configurar con el tipo de entidad Regla para garantizar la compatibilidad con versiones anteriores.

Para obtener más información sobre reglas con dos notificaciones de entrada, consulte Grupos de reglas y reglas.

2. Localización en once idiomas

El Portal de administración de ACS y la página de inicio de sesión hospedada por ACS para aplicaciones de usuario de confianza ahora admiten la localización a once idiomas escritos (inglés, francés, alemán, italiano, japonés, coreano, ruso, español, portugués de Brasil, chino simplificado y chino tradicional). También está disponible la opción “inglés (internacional)”, que usa un formato de fecha alternativo para establecer y mostrar correctamente fechas de entrada en vigor y de expiración de claves. Se puede cambiar el idioma escrito que se muestra para estas interfaces de usuario de una de las tres formas siguientes:

  • Selector de idioma: en el Portal de administración de ACS, el idioma mostrado se puede cambiar al instante con un nuevo menú selector de idioma que aparece en la esquina superior derecha del portal.

  • URL: el idioma mostrado en el Portal de administración de ACS se puede cambiar si se agrega el parámetro “lang” al final de la URL de solicitud. Los valores válidos para este parámetro son los códigos de idioma de la ISO 639-1/3166 que se correspondan con un idioma admitido. Algunos valores de ejemplo son en, de, es, fr, it, ja, ko, ru, pt-br, zh-cn y zh-tw. A continuación, encontrará una URL de ejemplo del Portal de administración de ACS con un parámetro que establece el idioma mostrado a francés:

    https://su-espaciodenombres.accesscontrol.windows.net/?lang=fr

  • Preferencias del explorador web: si el parámetro “lang” de la URL o el selector de idioma no se han usado nunca para establecer una preferencia de idioma, el Portal de administración deACS y las páginas de inicio de sesión hospedadas por ACS determinarán el idioma predeterminado que se mostrará según las preferencias de idioma definidas en la configuración del explorador web.

Estos son algunos cambios de comportamiento de servicio importantes en esta versión:

1. La codificación es ahora UTF-8 para todas las respuestas de OAuth 2.0

En la versión inicial de ACS, la codificación de caracteres definida para todas las respuestas HTTP desde el extremo de OAuth 2.0 era ASCII (EE. UU.). En la actualización de julio de 2011, la codificación de caracteres de todas las respuestas HTTP se ha definido como UTF-8 para admitir juegos de caracteres extendidos.

Este es un problema conocido en esta versión:

El editor de reglas no puede mostrar emisores personalizados que no estén asociados con proveedores de identidades

Actualmente, el editor de reglas en el portal de administración de ACS solo puede mostrar emisores de notificaciones que estén asociados con un proveedor de identidades o con ACS. Si se carga una regla que hace referencia a un emisor que no se corresponde con ninguno de estos, se mostrará el siguiente error:

  • ACS80001: Esta regla se configura para usar un tipo de emisor de notificaciones que el portal de administración no admite. Use el servicio de administración para ver y modificar esta regla.

Hay dos escenarios admitidos en los que un emisor puede existir sin un proveedor de identidades asociado en ACS:

  • En un escenario de delegación de OAuth 2.0, se crea un registro de emisor en Espacio de nombres Access Control mediante el servicio de administración de ACS y este emisor no tiene asociado ningún proveedor de identidades.

  • Cuando se crea un emisor con el objetivo de validar notificaciones en una solicitud de token a través del protocolo OAuth WRAP al usar una identidad de servicio con un nombre idéntico para autenticarse con ACS.

A partir de esta versión, ACS no impone límites en el número de proveedores de identidades, aplicaciones de usuario de confianza, grupos de reglas, reglas, identidades de servicio, tipos de notificaciones, registros de delegación, emisores, claves y direcciones que se pueden crear para un Espacio de nombres Access Control determinado.

Para obtener más información sobre las limitaciones del servicio, consulte Lmitaciones del servicio ACS.

Mostrar: