Cómo migrar desde Azure Access Control Service

Microsoft Azure Access Control Service (ACS), un servicio de Azure Active Directory (Azure AD), se retirará el 7 de noviembre de 2018. Las aplicaciones y los servicios que actualmente usan Access Control deben migrarse completamente a un mecanismo de autenticación diferente. En este artículo se describen las recomendaciones para los clientes actuales, ya que tiene previsto dejar de usar Access Control. Si actualmente no usa Access Control, no es necesario realizar ninguna acción.

Información general

Access Control es un servicio de autenticación en la nube que ofrece una manera fácil de autenticar y autorizar a los usuarios para acceder a sus aplicaciones y servicios web. Permite que muchas características de autenticación y autorización se factoricen fuera de tu código. Access Control se usa principalmente para desarrolladores y arquitectos de clientes de Microsoft .NET, ASP.NET aplicaciones web y servicios web de Windows Communication Foundation (WCF).

Los casos de uso de Access Control se pueden dividir en tres categorías principales:

• Autenticación en determinados servicios en la nube de Microsoft, incluidos Azure Service Bus y Dynamics CRM. Las aplicaciones cliente obtienen tokens de Access Control para autenticarse en estos servicios para realizar diversas acciones.
• Agregar autenticación a aplicaciones web, tanto personalizadas como empaquetadas previamente (como SharePoint). Mediante la autenticación "pasiva" de Access Control, las aplicaciones web pueden admitir el inicio de sesión con una cuenta de Microsoft (anteriormente Live ID) y con cuentas de Google, Facebook, Yahoo, Azure AD y Servicios de federación de Active Directory (AD FS).
• Protección de servicios web personalizados con tokens emitidos por Access Control. Mediante la autenticación "activa", los servicios web pueden asegurarse de que solo permiten el acceso a clientes conocidos que se han autenticado con Access Control.

Cada uno de estos casos de uso y sus estrategias de migración recomendadas se describen en las secciones siguientes.

Access Control tiene los siguientes componentes:

• Un servicio de token seguro (STS), que recibe solicitudes de autenticación y emite tokens de seguridad a cambio.
• El Portal de Azure clásico, donde se crean, eliminan y habilitan y deshabilitan los espacios de nombres de Access Control.
• Un portal de administración independiente de Access Control, donde se personalizan y configuran espacios de nombres de Access Control.
• Un servicio de administración, que puede usar para automatizar las funciones de los portales.
• Un motor de reglas de transformación de tokens, que puede usar para definir lógica compleja para manipular el formato de salida de los tokens que emite Access Control.

Para usar estos componentes, debe crear uno o varios espacios de nombres de control de acceso. Un espacio de nombres es una instancia dedicada de Access Control con la que se comunican las aplicaciones y los servicios. Un espacio de nombres está aislado de todos los demás clientes de Access Control. Otros clientes de Access Control usan sus propios espacios de nombres. Un espacio de nombres en Access Control tiene una dirección URL dedicada que tiene el siguiente aspecto:

https://<mynamespace>.accesscontrol.windows.net

Todas las comunicaciones con el STS y las operaciones de administración se realizan en esta dirección URL. Utilizas caminos diferentes para diferentes propósitos. Para determinar si las aplicaciones o los servicios usan Access Control, supervise cualquier tráfico hacia https://<namespace>.accesscontrol.windows.net. El control de acceso gestiona cualquier tráfico a esta dirección URL, y este debe dejar de permitirse.

La excepción a esto es cualquier tráfico a https://accounts.accesscontrol.windows.net. El tráfico a esta dirección URL ya está controlado por un servicio diferente y no se ve afectado por la desactivación de Access Control.

Para obtener más información sobre Access Control, consulte Access Control Service 2.0 (archivado).

Averiguar cuáles de las aplicaciones se verán afectadas

Siga los pasos de esta sección para averiguar cuál de las aplicaciones se verá afectada por la retirada de ACS.

Descarga e instalación de ACS PowerShell

1. Vaya a la Galería de PowerShell y descargue Acs.Namespaces.

2. Instalación del módulo mediante la ejecución de

   Install-Module -Name Acs.Namespaces
   

3. Para obtener una lista de todos los comandos posibles, ejecute

   Get-Command -Module Acs.Namespaces
   

   Para obtener ayuda sobre un comando específico, ejecute:

    Get-Help [Command-Name] -Full
   

   donde [Command-Name] es el nombre del comando de ACS.

Enumera los espacios de nombres de ACS

1. Conéctese a ACS mediante el cmdlet Connect-AcsAccount .

   Es posible que tenga que ejecutar Set-ExecutionPolicy -ExecutionPolicy Bypass antes de poder ser el administrador de esas suscripciones y ejecutar comandos.

2. Enumere las suscripciones de Azure disponibles mediante el cmdlet Get-AcsSubscription .

3. Enumere los espacios de nombres de ACS mediante el cmdlet Get-AcsNamespace .

Comprobación de qué aplicaciones se verán afectadas

1. Utiliza el espacio de nombres del paso anterior y dirígete a https://<namespace>.accesscontrol.windows.net

   Por ejemplo, si uno de los espacios de nombres es contoso-test, diríjase a https://contoso-test.accesscontrol.windows.net

2. En Relaciones de confianza, seleccione Aplicaciones de usuario de confianza para ver la lista de aplicaciones que se verán afectadas por la retirada de ACS.

3. Repita los pasos del 1 al 2 para cualquier otro espacio de nombres de ACS que tenga.

Programación de retirada

A partir de noviembre de 2017, todos los componentes de Control de acceso son totalmente compatibles y operativos. La única restricción es que no se pueden crear nuevos espacios de nombres de Access Control a través del Portal de Azure clásico.

Esta es la programación para dejar de usar componentes de Access Control:

• Noviembre de 2017: la experiencia de administración de Azure AD en el Portal de Azure clásico se retira. En este momento, la administración de espacios de nombres para Access Control está disponible en una nueva dirección URL dedicada: https://manage.windowsazure.com?restoreClassic=true. Use esta dirección URL para ver los espacios de nombres existentes, habilitar y deshabilitar espacios de nombres y eliminar espacios de nombres, si decide hacerlo.
• 2 de abril de 2018: el Portal de Azure clásico se retira completamente, lo que significa que la administración del espacio de nombres de Access Control ya no está disponible a través de ninguna dirección URL. En este momento, no puede deshabilitar ni habilitar, eliminar ni enumerar los espacios de nombres de Access Control. Sin embargo, el portal de administración de Control de acceso será totalmente funcional y se encuentra en https://<namespace>.accesscontrol.windows.net. Todos los demás componentes del Control de acceso siguen funcionando con normalidad.
• 7 de noviembre de 2018: Todos los componentes de Control de acceso se apagan permanentemente. Esto incluye el portal de administración de Access Control, el servicio de administración, STS y el motor de reglas de transformación de tokens. En este momento, se produce un error en las solicitudes enviadas al Control de acceso (ubicado en <namespace>.accesscontrol.windows.net). Debe haber migrado todas las aplicaciones y servicios existentes a otras tecnologías antes de este tiempo.

Estrategias de migración

En las secciones siguientes se describen recomendaciones de alto nivel para migrar de Access Control a otras tecnologías de Microsoft.

Clientes de servicios en la nube de Microsoft

Cada servicio en la nube de Microsoft que acepta tokens emitidos por Access Control ahora admite al menos una forma alternativa de autenticación. El mecanismo de autenticación correcto varía para cada servicio. Se recomienda consultar la documentación específica de cada servicio para obtener instrucciones oficiales. Para mayor comodidad, se proporciona aquí cada conjunto de documentación:

Clientes de SharePoint

Los clientes de SharePoint 2013, 2016 y SharePoint Online han usado ACS durante mucho tiempo para fines de autenticación en escenarios híbridos, locales y en la nube. Algunas características y casos de uso de SharePoint se verán afectados por la retirada de ACS, mientras que otras no. En la tabla siguiente se resumen las instrucciones de migración para algunas de las características de SharePoint más populares que aprovechan ACS:

Aplicaciones web que usan autenticación pasiva

En el caso de las aplicaciones web que usan Access Control para la autenticación de usuarios, Access Control proporciona las siguientes características y funcionalidades para desarrolladores y arquitectos de aplicaciones web:

• Integración profunda con Windows Identity Foundation (WIF).
• Federación con cuentas de Google, Facebook, Yahoo, Azure Active Directory, AD FS, y cuentas Microsoft.
• Compatibilidad con los siguientes protocolos de autenticación: OAuth 2.0 Draft 13, WS-Trust y Web Services Federation (WS-Federation).
• Compatibilidad con los siguientes formatos de token: JSON Web Token (JWT), SAML 1.1, SAML 2.0 y Simple Web Token (SWT).
• Una experiencia de detección de identidad del hogar, integrada en WIF, que permite a los usuarios seleccionar el tipo de cuenta con la que inician sesión. Esta experiencia se hospeda en la aplicación web y es totalmente personalizable.
• Transformación de tokens que permite una personalización enriquecida de las reclamaciones recibidas por la aplicación web de Access Control, entre las que se incluyen:
  • Transferencia de aserciones desde proveedores de identidad.
  • Agregar reclamos personalizados adicionales.
  • Lógica if-then sencilla para emitir declaraciones bajo ciertas condiciones.

Desafortunadamente, no hay un servicio que ofrezca todas estas funcionalidades equivalentes. Debe evaluar qué funcionalidades de Access Control necesita y, a continuación, elegir entre usar El identificador de Entra de Microsoft, Azure Active Directory B2C (Azure AD B2C) u otro servicio de autenticación en la nube.

Migración a Microsoft Entra ID

Una ruta de acceso que se debe tener en cuenta es integrar las aplicaciones y los servicios directamente con el identificador de Microsoft Entra. Microsoft Entra ID es el proveedor de identidades basado en la nube para cuentas profesionales o educativas de Microsoft. Microsoft Entra ID es el proveedor de identidades de Microsoft 365, Azure y mucho más. Proporciona funcionalidades de autenticación federadas similares a Access Control, pero no admite todas las características de Access Control.

El ejemplo principal es la federación con proveedores de identidades sociales, como Facebook, Google y Yahoo. Si los usuarios inician sesión con estos tipos de credenciales, Microsoft Entra ID no es la solución para usted.

Microsoft Entra ID tampoco admite necesariamente los mismos protocolos de autenticación que Access Control. Por ejemplo, aunque Access Control y Microsoft Entra ID admiten OAuth, existen diferencias sutiles entre cada implementación. Las distintas implementaciones requieren que modifique el código como parte de una migración.

Sin embargo, microsoft Entra ID proporciona varias ventajas potenciales a los clientes de Access Control. Admite de forma nativa las cuentas profesionales o educativas de Microsoft hospedadas en la nube, que suelen usar los clientes de Access Control.

Una entidad de Microsoft Entra también puede federarse con una o más instancias de Active Directory local a través de AD FS. De este modo, la aplicación puede autenticar usuarios y usuarios basados en la nube hospedados en el entorno local. También admite el protocolo WS-Federation, lo que facilita la integración con una aplicación web mediante WIF.

En la tabla siguiente se comparan las características de Access Control que son relevantes para las aplicaciones web con esas características que están disponibles en microsoft Entra ID.

En un nivel alto, microsoft Entra ID es probablemente la mejor opción para la migración si permite que los usuarios inicien sesión solo con sus cuentas profesionales o educativas de Microsoft.

Si decide que Microsoft Entra ID es la mejor ruta de migración para sus aplicaciones y servicios, debe tener en cuenta dos maneras de integrar su aplicación con Microsoft Entra ID.

Para usar WS-Federation o WIF para integrarse con Microsoft Entra ID, se recomienda seguir el enfoque descrito en Configurar el inicio de sesión único federado para una aplicación que no esté en la galería. El artículo hace referencia a la configuración del identificador de Microsoft Entra para el inicio de sesión único basado en SAML, pero también funciona para configurar WS-Federation. Para seguir este enfoque, se requiere una licencia P1 o P2 de Microsoft Entra ID. Este enfoque tiene dos ventajas:

• Obtiene la flexibilidad completa de la personalización del token de Microsoft Entra. Puede personalizar las notificaciones emitidas por microsoft Entra ID para que coincidan con las notificaciones emitidas por Access Control. Esto incluye especialmente el identificador de usuario o la reclamación de identificador de nombre. Para seguir recibiendo identificadores de usuario coherentes para los usuarios después de cambiar las tecnologías, asegúrese de que los identificadores de usuario emitidos por el identificador de Entra de Microsoft coincidan con los emitidos por Access Control.
• Puede configurar un certificado de firma de tokens específico de la aplicación y con una duración que controle.

Un enfoque alternativo consiste en seguir este ejemplo de código, que proporciona instrucciones ligeramente diferentes para configurar WS-Federation. Este ejemplo de código no usa WIF, sino el middleware de ASP.NET 4.5 OWIN. Sin embargo, las instrucciones para el registro de aplicaciones son válidas para las aplicaciones que usan WIF y no requieren una licencia P1 o P2 de Microsoft Entra ID.

Si elige este enfoque, debe comprender la rotación de claves de firma en Microsoft Entra ID. Este enfoque usa la clave de firma global de Microsoft Entra para emitir tokens. De forma predeterminada, WIF no actualiza automáticamente las claves de firma. Cuando Microsoft Entra ID gira sus claves de firma global, la implementación de WIF debe estar preparada para aceptar los cambios. Para obtener más información, vea Información importante sobre la sustitución de claves de firma en Microsoft Entra ID.

Si puede realizar la integración con microsoft Entra ID a través de los protocolos OpenID Connect o OAuth, se recomienda hacerlo. Tenemos una amplia documentación e instrucciones sobre cómo integrar Microsoft Entra ID en su aplicación web disponible en nuestra guía para desarrolladores de Microsoft Entra.

Migración a Azure Active Directory B2C

La otra ruta de migración que se debe tener en cuenta es Azure AD B2C. Azure AD B2C es un servicio de autenticación en la nube que, como Access Control, permite a los desarrolladores subcontratar su lógica de administración de identidades y autenticación en un servicio en la nube. Es un servicio de pago (con niveles gratis y premium) diseñado para aplicaciones orientadas al consumidor que pueden tener hasta millones de usuarios activos.

Al igual que Access Control, una de las características más atractivas de Azure AD B2C es que admite muchos tipos diferentes de cuentas. Con Azure AD B2C, puede permitir que los usuarios inicien sesión mediante sus cuentas de Microsoft, Facebook, Google, LinkedIn, GitHub, Yahoo y más. Azure AD B2C también admite "cuentas locales" o nombre de usuario y contraseñas que los usuarios crean específicamente para la aplicación. Azure AD B2C también proporciona una amplia extensibilidad que puede usar para personalizar los flujos de inicio de sesión.

Sin embargo, Azure AD B2C no admite la amplitud de protocolos de autenticación y formatos de token que los clientes de Access Control podrían necesitar. Tampoco puede usar Azure AD B2C para obtener tokens y solicitar información adicional sobre el usuario al proveedor de identidad, ya sea Microsoft u otro.

En la tabla siguiente se comparan las características de Access Control que son relevantes para las aplicaciones web con las que están disponibles en Azure AD B2C. En un nivel alto, Azure AD B2C es probablemente la opción adecuada para la migración si la aplicación está orientada al consumidor o si admite muchos tipos diferentes de cuentas.

Si decide que Azure AD B2C es la mejor ruta de migración para sus aplicaciones y servicios, comience con los siguientes recursos:

• Documentación de Azure AD B2C
• Directivas personalizadas de Azure AD B2C
• Precios de Azure AD B2C

Migrar a Ping Identity o Auth0

En algunos casos, es posible que encuentre que Microsoft Entra ID y Azure AD B2C no son suficientes para reemplazar Access Control en las aplicaciones web sin realizar cambios importantes en el código. Algunos ejemplos comunes pueden incluir:

• Aplicaciones web que usan WIF o WS-Federation para el inicio de sesión con proveedores de identidades sociales, como Google o Facebook.
• Aplicaciones web que realizan la federación directa a un proveedor de identidades de empresa a través del protocolo WS-Federation.
• Aplicaciones web que requieren el token de acceso emitido por un proveedor de identidades sociales (como Google o Facebook) como una reclamación en los tokens emitidos por el Control de Acceso.
• Las aplicaciones web con reglas complejas de transformación de tokens que Microsoft Entra ID o Azure AD B2C no pueden reproducirse.
• Aplicaciones web multicliente que utilizan ACS para gestionar de forma centralizada la federación con muchos proveedores de identidad diferentes.

En estos casos, es posible que quiera considerar la posibilidad de migrar la aplicación web a otro servicio de autenticación en la nube. Se recomienda explorar las siguientes opciones. Cada una de las siguientes opciones ofrece funcionalidades similares a Access Control:

Auth0 es un servicio de identidad en la nube flexible que ha creado instrucciones de migración de alto nivel para los clientes de Access Control y admite casi todas las características que acS hace.

Ping Identity ofrece dos soluciones similares a ACS. PingOne es un servicio de identidad en la nube que admite muchas de las mismas características que ACS y PingFederate es un producto de identidad local similar que ofrece más flexibilidad. Consulte la guía de jubilación de ACS de Ping para obtener más detalles sobre el uso de estos productos.

Nuestro objetivo de trabajar con Ping Identity y Auth0 es asegurarse de que todos los clientes de Access Control tengan una ruta de migración para sus aplicaciones y servicios que minimice la cantidad de trabajo necesario para pasar de Access Control.

Servicios web que usan la autenticación activa

En el caso de los servicios web protegidos con tokens emitidos por Access Control, Access Control ofrece las siguientes características y funcionalidades:

• Capacidad de registrar una o varias identidades de servicio en el espacio de nombres de Access Control. Las identidades de servicio se pueden usar para solicitar tokens.
• Compatibilidad con los protocolos OAuth WRAP y OAuth 2.0 Draft 13 para solicitar tokens mediante los siguientes tipos de credenciales:
  • Una contraseña sencilla que se crea para la identidad de servicio
  • Un SWT firmado mediante una clave simétrica o un certificado X509
  • Un token SAML emitido por un proveedor de identidades de confianza (normalmente, una instancia de AD FS)
• Compatibilidad con los siguientes formatos de token: JWT, SAML 1.1, SAML 2.0 y SWT.
• Reglas de transformación de tokens simples.

Las identidades de servicio de Access Control se suelen usar para implementar la autenticación de servidor a servidor.

Migración a Microsoft Entra ID

Nuestra recomendación para este tipo de flujo de autenticación es migrar a Microsoft Entra ID. Microsoft Entra ID es el proveedor de identidades basado en la nube para cuentas profesionales o educativas de Microsoft. Microsoft Entra ID es el proveedor de identidades de Microsoft 365, Azure y mucho más.

También puede usar el identificador de Entra de Microsoft para la autenticación de servidor a servidor mediante la implementación de Microsoft Entra de la concesión de credenciales de cliente de OAuth. En la tabla siguiente se comparan las funcionalidades de Access Control en la autenticación de servidor a servidor con las que están disponibles en microsoft Entra ID.

Para obtener instrucciones sobre cómo implementar escenarios de servidor a servidor, consulte los siguientes recursos:

• Sección Servicio-a-servicio de la guía para desarrolladores de Microsoft Entra
• Ejemplo de código de daemon utilizando credenciales de cliente de contraseña simple
• Ejemplo de código de demonio utilizando credenciales de cliente basadas en certificado

Migrar a Ping Identity o Auth0

En algunos casos, es posible que encuentre que las credenciales de cliente de Microsoft Entra y la implementación de concesión de OAuth no son suficientes para reemplazar Access Control en la arquitectura sin cambios importantes en el código. Algunos ejemplos comunes pueden incluir:

• Autenticación de servidor a servidor mediante formatos de token distintos de JWT.
• Autenticación de servidor a servidor mediante un token de entrada proporcionado por un proveedor de identidades externo.
• Autenticación de servidor a servidor con reglas de transformación de tokens que Microsoft Entra ID no puede replicar.

En estos casos, puede considerar la posibilidad de migrar la aplicación web a otro servicio de autenticación en la nube. Se recomienda explorar las siguientes opciones. Cada una de las siguientes opciones ofrece funcionalidades similares a Access Control:

Auth0 es un servicio de identidad en la nube flexible que ha creado instrucciones de migración de alto nivel para los clientes de Access Control y admite casi todas las características que acS hace.

ofrece dos soluciones similares a ACS. PingOne es un servicio de identidad en la nube que admite muchas de las mismas características que ACS y PingFederate es un producto de identidad local similar que ofrece más flexibilidad. Consulte la orientación sobre la jubilación de ACS de Ping para obtener más información sobre el uso de estos productos.

Nuestro objetivo de trabajar con Ping Identity y Auth0 es asegurarse de que todos los clientes de Access Control tengan una ruta de migración para sus aplicaciones y servicios que minimice la cantidad de trabajo necesario para pasar de Access Control.

Autenticación de paso directo

Para la autenticación de paso a través con transformación de tokens arbitrarios, no hay ninguna tecnología de Microsoft equivalente a ACS. Si eso es lo que necesitan los clientes, Auth0 podría ser el que proporciona la solución de aproximación más cercana.

Preguntas, preocupaciones y comentarios

Entendemos que muchos clientes de Access Control no encontrarán una ruta de migración clara después de leer este artículo. Es posible que necesite ayuda o orientación para determinar el plan adecuado. Si desea analizar los escenarios y preguntas de migración, deje un comentario en esta página.