Notas de la versión

Actualizado: 19 de junio de 2015

Se aplica a: Azure

En este tema se describen las nuevas características de cada versión de Microsoft Azure Active Directory Access Control (también conocida como Access Control Service o ACS), se explica cómo cada versión del producto difiere de sus predecesores y resalta los cambios importantes que podrían afectar al código escrito para una versión anterior.

• Marzo de 2015: migrar espacios de nombres de ACS a OpenID Connect de Google

• Junio de 2014: compatibilidad con Google como proveedor de identidades

• Notas de la versión de la actualización de julio de 2013

• Notas de la versión de la actualización de diciembre de 2012

• Notas de la versión de la actualización de septiembre de 2012

• Notas de la versión de la actualización de junio de 2012

• Notas de la versión de la actualización de mayo de 2012

• Notas de la versión de la actualización de enero de 2012

• Notas de la versión de actualización de julio de 2011

Marzo de 2015: migrar espacios de nombres de ACS a OpenID Connect de Google

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, consulte Migración de espacios de nombres de ACS a Google OpenID Conectar.

Junio de 2014: compatibilidad con Google como proveedor de identidades

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 de ACS existentes que usaron Google seguirán funcionando hasta el 20 de abril de 2015. Si la aplicación requiere compatibilidad con cuentas de Google, se recomienda registrar la aplicación directamente con ellas.

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.

Notas de la versión de la actualización de julio de 2013

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, consulte Limitaciones del servicio ACS y códigos de error de ACS.

Notas de la versión de la actualización de diciembre de 2012

Características nuevas

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

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 mediante el protocolo WS-Federation ahora pueden aprovechar las funcionalidades 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 usuario del proveedor de identidades y salir de otras aplicaciones de usuario de confianza que usan el mismo proveedor de identidades.

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

• ACS reconoce mensajes wsignoutcleanup1.0 de proveedores de identidades y responde enviando mensajes wsignoutcleanup1.0 a aplicaciones de usuario de confianza.

• ACS reconoce los mensajes wsignout1.0 y los mensajes forjados de aplicaciones de usuario de confianza y responde enviando mensajes wsignout1.0 a proveedores de identidades y mensajes wsignoutcleanup1.0 a aplicaciones de usuario de confianza.

Para obtener más información, vea Ejemplo de código: ASP.NET MVC 4 con cierre de sesión federado y 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 Access Control espacios de nombres en el nuevo Portal de administración de Azure

El nuevo Portal de administración de Azure (https://manage.WindowsAzure.com) incluye una ruta al conocido portal de administración de ACS donde se crean y administran Access Control espacios de nombres.

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, a continuación, haga clic en Active Directory. (Sugerencia de solución de problemas: falta el elemento "Active Directory" o no está disponible)

2. Haga clic en un espacio de nombres Access Control y, a continuación, haga clic en Administrar.

Para crear un espacio de nombres Access Control, haga clic en Nuevo, App Services, 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 Service Bus en , 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 al bus de servicio, consulte el campo Espacio de nombres de servicio en la parte superior de la página Servicio de Access Control. 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 How to: Manage the Access Control Namespace for a Service Bus.

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”.

Capacidad de federar inquilinos de directorio con espacios de nombres Access Control

Azure Active Directory inquilinos ahora se pueden usar como proveedores de identidades en Access Control espacios de nombres. Esto permite muchos escenarios, como permitir que la aplicación web acepte identidades organizativas de inquilinos de directorio e identidades de consumidor de proveedores sociales, como Facebook, Google, Yahoo!, cuentas microsoft o cualquier otro proveedor de OpenID. Puede encontrar instrucciones detalladas sobre cómo implementar el escenario en esta publicación, Aprovisionamiento de un inquilino de Azure Active Directory como proveedor de identidades en un espacio de nombres de 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, consulteDeveloper Preview: SAMLProtocol.

Problemas conocidos

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

Azure Co-Administrators ahora puede administrar Access Control espacios de nombres. Sin embargo, se requiere una acción para propagar los coadministradores preexistentes a un espacio de nombres de Access Control ya existente.

Antes de la actualización de noviembre de 2012, se resolvió un problema por el que, de forma predeterminada, solo el administrador del servicio de Azure principal podía administrar Access Control espacios de nombres creados en la suscripción. Si un coadministrador de Azure intentó acceder al Portal de administración de ACS para un espacio de nombres de Access Control, recibiría uno de los siguientes códigos de error de ACS:

• ACS50000: error al emitir un token.

• ACS60000: error al procesar reglas para usuario de confianza mediante el emisor "uri:WindowsLiveID"

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

Este problema se resuelve ahora para los nuevos espacios de nombres Access Control creados por cualquier administrador de servicios de Azure o coadministrador. 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 Azure Portal (https://windows.azure.com/) con credenciales de administrador de servicios o de administrador de cuentas.

2. Quite y vuelva a agregar el coadministrador mediante las instrucciones de Incorporación y eliminación de Co-Administrators para las suscripciones de Azure (https://msdn.microsoft.com/library/windowsazure/gg456328.aspx)

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

Notas de la versión de la actualización de septiembre de 2012

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

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

El atributo "entityID" de los metadatos de WS-Federation publicados por Access Control espacios de nombres siempre está en minúsculas. 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, a continuación, se muestra un ejemplo del atributo :

<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 el espacio de nombres Access Control del espacio de nombres de Access Control en el token emitido por ACS (que siempre es menor en minúsculas) no coincide con las mayúsculas y minúsculas del espacio de nombres de 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 de Access Control a través del portal de administración de ACS o el servicio de administración ahora deben tener un tamaño de clave pública que no sea 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 no hay certificados de firma de tokens configurados con el campo "Crear principal", el espacio de nombres Access Control usará el certificado de firma de tokens no principal existente que tenga la fecha de inicio válida más antigua 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 un certificado de espacio de nombres global o una clave 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

Notas de la versión de la actualización de junio de 2012

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

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

Esta actualización presenta compatibilidad con el formato BETA de JSON Web Token (JWT) en ACS. JWT es un formato de token ligero y codificado en JSON que se puede firmar mediante un certificado X.509 o una clave simétrica, y ACS puede emitirlo a las 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 seleccionable en la sección Aplicaciones de usuario de confianza del Portal de administración de ACS y también se puede configurar a través del servicio de administración de ACS.

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

Notas de la versión de la actualización de mayo de 2012

A principios de mayo de 2012, ACS recibió una actualización que contenía el siguiente cambio:

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 id. para cada uno de los tipos de entidad que admite, como se describe en la referencia de la API del servicio de administración de ACS. Estas propiedades de identificador se establecen y administran automáticamente mediante ACS.

En esta actualización del servicio, ACS se está migrando a un esquema de base de datos diferente 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 mejorar la seguridad, esta versión de ACS actualiza la intercalación de base de datos SQL subyacente que se usa para comparar las notificaciones de entrada de SQL_Latin1_General_CP1_CI_AS a Latin1_General_100_BIN2. Este cambio permite que ACS admita juegos de caracteres adicionales y 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.

Notas de la versión de la actualización de enero de 2012

El 25 de enero de 2012, ACS 2.0 recibió una actualización que contenía los siguientes cambios:

• Cambio en respuestas de error de ACS para solicitudes de autenticación con errores

• Cambio en códigos de error de OAuth 2.0 para solicitudes de autenticación con errores

Cambio en respuestas de error de ACS para solicitudes de autenticación con errores

En la versión anterior, ACS respondió con códigos de error diferentes cuando un cliente se autenticaba con un emisor inexistente (código de error: ACS50026) o 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/contraseña, respectivamente. Encontrará más información en la tabla siguiente:

Respuesta de autenticación	Antes	Después
Emisor inexistente	ACS50026 EmisorNoEncontrado	ACS50008 SWTnoVálido, ACS50009 InvalidSaml, OR ACS50012 ErrorDeAutenticación
Credenciales incorrectos	ACS50006 FirmaNoVálida

Cambio en códigos de error de OAuth 2.0 para solicitudes de autenticación con errores

También en la versión anterior, ACS respondió con diferentes códigos de error de OAuth 2.0 cuando un cliente se autenticaba con un emisor no existente (invalid_client) o credenciales incorrectas (invalid_grant). Este comportamiento también se ha actualizado y ACS devolverá invalid_request cuando la solicitud de OAuth 2.0 tenga un formato incorrecto, invalid_client si el cliente produce un error en la autenticación o la aserción proporcionada para la autenticación tiene un formato incorrecto o no es válido, y invalid_grant si el código de autorización tiene un formato incorrecto o no es válido. Encontrará más información en la tabla siguiente:

Respuesta de autenticación	Ejemplos	Antes	Después
Emisor inexistente		invalid_client	invalid_client
Credenciales incorrectos	SWT está firmado con una clave incorrecta. El identificador de cliente y las credenciales coinciden con los configurados en ACS.	invalid_grant
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.	invalid_grant
Aserción con formato incorrecto	Falta la firma de SWT. La aserción SAML no es un XML válido.	invalid_request
Código de autorización con formato incorrecto		invalid_grant	invalid_grant
Código de autorización no válido		invalid_grant
Solicitud de OAuth2 con formato incorrecto		invalid_request	invalid_request

Notas de la versión de actualización de julio de 2011

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

• Requisitos previos

• Nuevas características

• Cambios

• Problemas conocidos

• Problemas conocidos

Requisitos previos

Todos los espacios 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 los clientes nuevos o existentes. Para obtener más información sobre los requisitos previos actuales de ACS, consulte Requisitos previos de ACS.

Nuevas características

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

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 notificación de entrada. 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 segunda notificación de entrada en una nueva regla haciendo 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 las reglas con dos notificaciones de entrada, consulte Reglas y grupos de reglas.

2. Localización en once idiomas

El Portal de administración de ACS y la página de inicio de sesión hospedado en ACS para aplicaciones de usuario de confianza ahora admiten la localización en once idiomas escritos, como inglés, francés, alemán, italiano, japonés, coreano, ruso, español, portugués (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 mediante un nuevo menú del selector de idioma que aparece en la esquina superior derecha del portal.

• URL : el idioma que se muestra en el Portal de administración de ACS se puede cambiar agregando un parámetro "lang" al final de la dirección URL de la 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 se muestra un ejemplo de dirección URL del Portal de administración de ACS con un parámetro que establece el idioma mostrado en francés:

  https://your-namespace.accesscontrol.windows.net/?lang=fr

• Preferencias del explorador web : si el parámetro url "lang" o el selector de idioma nunca se ha usado para establecer una preferencia de idioma, el Portal de administración de ACS y las páginas de inicio de sesión hospedadas en ACS determinarán el idioma predeterminado que se mostrará en función de las preferencias de idioma establecidas en la configuración del explorador web.

Cambios

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, el conjunto de codificación de caracteres para todas las respuestas HTTP del punto de conexión de OAuth 2.0 era US-ASCII. 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.

Problemas conocidos

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 del Portal de administración de ACS solo puede mostrar emisores de notificaciones asociados a un proveedor de identidades o 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 está configurada para usar un tipo de emisor de notificaciones que no es compatible con el portal de administración. 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 el espacio de nombres Access Control mediante el servicio de administración de ACS y este emisor no tiene un proveedor de identidades asociado.

• Cuando se crea un emisor con el fin de declarar notificaciones en una solicitud de token sobre el protocolo WRAP de OAuth, mientras se usa una identidad de servicio con nombre idéntico para autenticarse con ACS.

Cuotas

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

Limitaciones de los servicios

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