Procedimientos: Migración desde Azure Access Control Service
Advertencia
Este contenido es el punto de conexión anterior de Azure AD v1.0. Use la Plataforma de identidad de Microsoft.
Microsoft Azure Access Control Service (ACS), un servicio de Azure Active Directory (Azure AD), se retirará el 7 de noviembre de 2018. Para entonces, las aplicaciones y servicios que utilizan Access Control deben migrarse completamente a un mecanismo de autenticación diferente. En este artículo se describen las recomendaciones para los clientes actuales que pretenden dejar de usar Access Control. Si actualmente no utiliza 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 sencilla de autenticar y autorizar a los usuarios que quieran obtener acceso a los servicios y aplicaciones web. Permite que muchas características de autenticación y autorización se factoricen a partir del código. Los programadores y arquitectos de Microsoft .NET, las aplicaciones web ASP.NET y los servicios web de Windows Communication Foundation (WCF) usan principalmente Access Control.
Los casos de uso de Access Control pueden dividirse en tres categorías principales:
- Autenticar determinados servicios en la nube de Microsoft, incluidos Azure Service Bus y Dynamics CRM. Las aplicaciones cliente que pueden obtener tokens de Access Control que pueden usarse a fin de autenticar estos servicios para realizar diversas acciones.
- Agregar el proceso de autenticación a aplicaciones web personalizadas y preestablecidas (como SharePoint). Mediante la autenticación "pasiva" de Access Control, las aplicaciones web pueden permitir que se inicie sesión con una cuenta de Microsoft (anteriormente Live ID), con cuentas de Google, Facebook, Yahoo, Azure AD y los Servicios de federación de Active Directory (AD FS).
- Proteger los servicios web integrados personalizados con tokens que haya emitido Access Control. Mediante la autenticación "activa", los servicios web pueden garantizar que solo se permite el acceso de clientes conocidos que se hayan autenticado con Access Control.
Cada uno de estos casos de uso y sus estrategias recomendadas de migración se describen en las secciones siguientes.
Advertencia
En la mayoría de los casos, se requieren cambios de código significativos para migrar los servicios y las aplicaciones existentes a las tecnologías más recientes. Le recomendamos que comience la planificación y la ejecución de la migración inmediatamente para evitar la posibilidad de que se produzcan interrupciones o tiempos de inactividad.
Access Control tiene los siguientes componentes:
- Un servicio de token seguro (STS) que recibe las solicitudes de autenticación y emite de vuelta tokens de seguridad.
- El Portal de Azure clásico, donde se crean, eliminan, habilitan y deshabilitan los espacios de nombres de Access Control.
- Un portal de administración de Access Control donde puede personalizar y configurar los espacios de nombres de Access Control.
- Un servicio de administración que se puede usar para automatizar las funciones de los portales.
- Un motor de reglas de transformación de tokens que se puede usar para definir una lógica compleja a fin de manipular el formato de salida de los tokens emitidos por Access Control.
Para utilizar estos componentes, debe crear uno o varios espacios de nombres de Access Control. Un espacio de nombres es una instancia dedicada de Access Control con el que se comunican los servicios y las aplicaciones. Asimismo, está aislado del resto de los 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 con el siguiente aspecto:
https://<mynamespace>.accesscontrol.windows.net
Toda comunicación con las operaciones de administración y STS se realiza en esta dirección URL. Use rutas de acceso diferentes para distintos fines. Para determinar si sus aplicaciones o servicios utilizan Access Control, supervise todo el tráfico a https://<espacio de nombres>.accesscontrol.windows.net. Access Control maneja todo el tráfico dirigido a esta dirección URL y debe interrumpirse.
La excepción a esto es todo el tráfico a https://accounts.accesscontrol.windows.net. El tráfico a esta dirección URL ya se controla mediante un servicio diferente y no se ve afectado debido al desuso de Access Control.
Para obtener más información sobre Access Control, consulte Access Control Service 2.0 (archivado).
Averigüe qué aplicaciones se verán afectadas
Siga los pasos descritos en esta sección para averiguar qué aplicaciones se verán afectadas por la retirada de ACS.
Descargue e instale ACS PowerShell
Vaya a la Galería de PowerShell y descargue Acs.Namespaces.
Ejecute lo siguiente para instalar el módulo:
Install-Module -Name Acs.NamespacesEjecute lo siguiente para obtener una lista de todos los comandos posibles:
Get-Command -Module Acs.NamespacesPara obtener ayuda sobre un comando específico, ejecute:
Get-Help [Command-Name] -Fulldonde
[Command-Name]es el nombre del comando de ACS.
Enumeración del espacio de nombres de ACS
Conéctese a ACS con el cmdlet Connect AcsAccount.
Puede que tenga que ejecutar
Set-ExecutionPolicy -ExecutionPolicy Bypassantes de poder ejecutar los comandos y que tenga que ser el administrador de esas suscripciones para poder ejecutar los comandos.Enumere las suscripciones de Azure disponibles con el cmdlet Get AcsSubscription.
Enumere los espacios de nombres de ACS con el cmdlet Get AcsNamespace.
Compruebe qué aplicaciones que se verán afectadas
Use el espacio de nombres del paso anterior y vaya a
https://<namespace>.accesscontrol.windows.netPor ejemplo, si uno de los espacios de nombres es contoso-test, vaya a
https://contoso-test.accesscontrol.windows.netEn 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.
Repita los pasos 1 y 2 para otros espacios de nombres de ACS que tenga.
Calendario de retiradas
A partir de noviembre de 2017, todos los componentes de Access Control son totalmente compatibles y están 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.
Aquí está el calendario que indica el desuso de los componentes de Access Control:
- Noviembre de 2017: la experiencia de administración de Azure AD en el la versión clásica de Azure Portal se retira. En este momento, la administración del espacio de nombres de Access Control estará disponible en esta nueva dirección URL dedicada:
https://manage.windowsazure.com?restoreClassic=true. Use esta URL para ver los espacios de nombres existentes y habilitar, deshabilitar y eliminar diversos espacios de nombres si así lo desea. - 2 de abril de 2018: el Portal de Azure clásico se ha retirado por completo, 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. No podrá deshabilitar o habilitar, eliminar o enumerar los espacios de nombres de Access Control. Sin embargo, el portal de administración de Access Control será totalmente funcional y se ubicará en
https://<namespace>.accesscontrol.windows.net. Todos los demás componentes de Access Control también seguirán funcionando con normalidad. - 7 de noviembre de 2018: todos los componentes de Access Control se cierran 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, las solicitudes enviadas a Access Control (ubicado en
<namespace>.accesscontrol.windows.net) darán un error. Debe haber migrado todos los servicios y aplicaciones existentes a otras tecnologías bastante antes de esta fecha.
Nota:
Una directiva deshabilita los espacios de nombres que no han solicitado un token durante un período de tiempo. A partir de principios de septiembre de 2018, este período de tiempo es actualmente de 14 días de inactividad, pero se reducirá a 7 días de inactividad en las próximas semanas. Si tiene espacios de nombres de Access Control que actualmente están deshabilitados, puede descargar e instalar PowerShell ACS para volver a habilitarlos.
Estrategias de migración
En las secciones siguientes se describen recomendaciones detalladas para la migración de Access Control a otras tecnologías de Microsoft.
Clientes de los Servicios en la nube de Microsoft
Cada uno de los Servicios en la nube de Microsoft que aceptan tokens que haya emitido Access Control ahora admite al menos una forma alternativa de autenticación. El mecanismo de autenticación correcto varía para cada servicio. Recomendamos que consulte la documentación específica de cada servicio para obtener una guía oficial. Para mayor comodidad, cada conjunto de documentación se proporciona aquí:
| Servicio | Guía |
|---|---|
| Azure Service Bus | Migración a firmas de acceso compartido |
| Azure Service Bus Relay | Migración a firmas de acceso compartido |
| Azure Managed Cache | Migración a Azure Cache for Redis |
| Azure DataMarket | Migración a las API de servicios de Azure AI |
| BizTalk Services | Migración a la característica Logic Apps de Azure App Service |
| Azure Media Services | Migración a la autenticación de Azure AD |
| Azure Backup | Actualización del agente de Azure Backup |
Clientes de SharePoint
Los clientes de SharePoint 2013, 2016 y SharePoint Online han usado durante mucho tiempo ACS para fines de autenticación en escenarios en la nube, locales e híbridos. Algunas características de y casos de uso de SharePoint resultarán afectados por la retirada de ACS, pero otros no. En la tabla siguiente se resume la guía de migración para algunas de las características más populares de SharePoint que hacen uso de ACS:
| Característica | Guía |
|---|---|
| Autenticación de usuarios desde Azure AD | Anteriormente, Azure AD no admitía los tokens de SAML 1.1 que necesitaba SharePoint para la autenticación, y ACS se usaba como intermediario que permitía la compatibilidad de SharePoint con formatos de token de Azure AD. Ahora, puede conectar SharePoint directamente a Azure AD con la aplicación SharePoint local de la galería de aplicaciones de Azure AD. |
| Autenticación de aplicaciones y autenticación de servidor a servidor en SharePoint local | No resulta afectado por la retirada de ACS; no se requieren cambios. |
| Autorización de confianza baja para complementos de SharePoint (proveedor hospedado y SharePoint hospedado) | No resulta afectado por la retirada de ACS; no se requieren cambios. |
| Búsqueda de SharePoint en la nube híbrida | No resulta afectado por la retirada de ACS; no se requieren cambios. |
Aplicaciones web que usan autenticación pasiva
Access Control proporciona a arquitectos y desarrolladores de aplicaciones web que utilizan Access Control para autenticar usuarios, las siguientes características y capacidades :
- Integración profunda con Windows Identity Foundation (WIF).
- Federación con Google, Facebook, Yahoo, Azure Active Directory y cuentas de AD FS y 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 dominio de inicio, integrada en WIF, que permite a los usuarios seleccionar el tipo de cuenta que usan para iniciar sesión. Esta experiencia es totalmente personalizable y la proporciona la aplicación web.
- La transformación de token que permite la variada personalización de las notificaciones que recibe la aplicación web de ACS, incluyendo:
- El paso de las notificaciones desde los proveedores de identidad.
- La incorporación de notificaciones personalizadas adicionales.
- La lógica de if-then simple para emitir notificaciones bajo ciertas condiciones.
Por desgracia, 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 Microsoft Entra ID, Azure Active Directory B2C (Azure AD B2C) u otro servicio de autenticación en la nube.
Migración a Microsoft Entra ID
Una forma de migración sería integrar las aplicaciones y servicios directamente con Microsoft Entra ID. Microsoft Entra ID es el proveedor de identidades basado en la nube de cuentas profesionales o educativas de Microsoft. Microsoft Entra ID es el proveedor de identidades para Microsoft 365, Azure y muchos servicios más. Proporciona funcionalidades de autenticación federada similares a Access Control, pero no admite todas sus características.
El ejemplo principal es la federación con proveedores de identidades sociales, como Facebook, Google y Yahoo. Si sus usuarios inician sesión con estos tipos de credenciales, Microsoft Entra ID no es la mejor opción.
Asimismo, Microsoft Entra ID no admite necesariamente los mismos protocolos de autenticación que Access Control. Por ejemplo, aunque tanto Access Control como Microsoft Entra ID admiten OAuth, existen diferencias sutiles entre cada implementación. Las diferentes implementaciones requieren que modifique el código como parte de una migración.
Sin embargo, Microsoft Entra ID proporciona varias ventajas potenciales para los clientes de Access Control. De forma nativa, es compatible con las cuentas educativas o profesionales de Microsoft hospedadas en la nube y que normalmente usan clientes de Access Control.
Igualmente, un inquilino de Microsoft Entra ID también se puede federar en una o más instancias de Active Directory local mediante AD FS. De esta manera, la aplicación puede autenticar a usuarios basados en la nube y usuarios que estén hospedados de manera local. También admite el protocolo WS-Federation, con el que la integración con una aplicación web mediante WIF resulta bastante sencilla.
En la siguiente tabla se comparan las características de Access Control pertinentes a las aplicaciones web, con aquellas que están disponibles en Microsoft Entra ID.
En líneas generales, Microsoft Entra ID probablemente no sea la opción adecuada para la migración, si solo permite a los usuarios iniciar sesión con sus cuentas educativas o profesionales de Microsoft.
| Capacidad | Soporte técnico de Access Control | Compatibilidad con Microsoft Entra ID |
|---|---|---|
| Tipos de cuentas | ||
| Cuentas educativas o profesionales de Microsoft | Compatible | Compatible |
| Cuentas de Windows Server Active Directory y AD FS | : se admite a través de la federación con un inquilino de Microsoft Entra - Compatible a través de la federación directa con AD FS. |
Solo se admite a través de la federación con un inquilino de Microsoft Entra |
| Cuentas desde otros sistemas de administración de identidades empresariales | - Posible a través de la federación con un inquilino de Microsoft Entra - Compatible a través de la federación directa. |
Posible a través de la federación con un inquilino de Microsoft Entra |
| Cuentas de Microsoft para uso personal | Compatible | Compatible mediante el protocolo v2.0 OAuth de Microsoft Entra ID, pero no a través de ningún otro protocolo |
| Cuentas de Facebook, Google, Yahoo | Compatible | No se admite ningún tipo. |
| Compatibilidad con el SDK y protocolos | ||
| WIF | Compatible | Compatible, pero con instrucciones limitadas disponibles. |
| El certificado del proveedor de identidades de WS-Federation | Compatible | Compatible |
| OAuth 2.0 | Soporte para Draft 13 | Compatibilidad con RFC 6749, la especificación más moderna. |
| WS-Trust | Compatible | No compatible |
| Formatos de tokens | ||
| JWT | Compatible en versión beta | Compatible |
| SAML 1.1 | Compatible | Versión preliminar |
| SAML 2.0 | Compatible | Compatible |
| SWT | Compatible | No compatible |
| Personalizaciones | ||
| UI de selección de cuenta o detección de dominio de inicio personalizable | Código descargable que se puede incorporar en las aplicaciones | No compatible |
| Carga de certificados de firma de tokens personalizados | Compatible | Compatible |
| Personalización de notificaciones en tokens | - Paso a través de notificaciones de entrada desde proveedores de identidad - Obtención de token de acceso del proveedor de identidades como una notificación - Emisión de notificaciones de salida basadas en valores de las notificaciones de entrada - Emisión de notificaciones de salida con valores constantes |
- No se puede pasar a través notificaciones desde proveedores de identidades federados. - No se puede obtener el token de acceso del proveedor de identidades como una notificación - No se pueden emitir notificaciones de salida basadas en valores de notificaciones de entrada. - Se pueden emitir notificaciones de salida con valores constantes. - Se pueden emitir notificaciones de salida en función de las propiedades de los usuarios que se sincronizan con Microsoft Entra ID |
| Automation | ||
| Automatización de las tareas de configuración y administración | Compatible a través del servicio de administración de Access Control | Compatible mediante Microsoft Graph API |
Si decide que Microsoft Entra ID es la forma adecuada para migrar sus aplicaciones y servicios, debe tener en cuenta dos maneras de integrar su aplicación con Microsoft Entra ID.
Para utilizar WS-Federation o WIF para realizar integraciones con Microsoft Entra ID, le recomendamos que siga la solución descrita en Configuración del inicio de sesión único federado para una aplicación ajena a la galería. En este artículo se detalla la configuración de Microsoft Entra ID para el inicio de sesión único basado en SAML, pero funciona también para configurar WS-Federation. La siguiente solución requiere una licencia de Microsoft Entra ID P1 o P2. Este enfoque tiene dos ventajas:
- Obtiene toda la flexibilidad de la personalización de tokens de Microsoft Entra. Puede personalizar las notificaciones que emite Microsoft Entra ID para que coincidan con las que emite Access Control. Esta opción incluye especialmente la notificación del id. de usuario o del identificador de nombre. Para continuar recibiendo identificadores de usuario consistentes de todos sus usuarios una vez haya cambiado de tecnología, debe asegurarse de que los id. de usuario que emita Microsoft Entra ID coincidan con los que emita Access Control.
- Puede configurar un certificado de firma de tokens específico para su aplicación y cuya vigencia controle.
Nota:
Esta solución requiere una licencia de Microsoft Entra ID P1 o P2. Si es un cliente de Access Control y necesita una licencia Premium para configurar el inicio de sesión único de una aplicación, póngase en contacto con nosotros. Estaremos encantados de proporcionarle licencias de desarrollador.
Una solución alternativa es seguir este código de ejemplo que ofrece instrucciones ligeramente diferentes acerca de cómo configurar WS-Federation. Este ejemplo de código no usa WIF, sino el middleware OWIN de ASP.NET 4.5. Sin embargo, las instrucciones para el registro de aplicaciones son válidas para las aplicaciones que usan WIF y no requieren una licencia de Microsoft Entra ID P1 o P2.
Si elige esta solución, debe entender la sustitución de claves de firma de Microsoft Entra ID. Esta solución usa la clave de firma global de Microsoft Entra ID para emitir tokens. De forma predeterminada, WIF no actualiza automáticamente las claves de firma. Cuando Microsoft Entra ID rote sus claves de firma globales, la implementación de WIF debe estar preparada para aceptar los cambios. Para más información, consulte Sustitución de claves de firma de Microsoft Entra ID.
Si puede realizar la integración con Microsoft Entra ID a través de los protocolos de OpenID Connect u OAuth, se recomienda hacerlo. Tenemos una extensa documentación y guías sobre cómo integrar Microsoft Entra ID en una aplicación web, que están disponibles en nuestra Guía del desarrollador de Microsoft Entra.
Migrar a Azure Active Directory B2C
La otra forma de migración que hay que tener en cuenta es B2C de Azure AD. Azure AD B2C es un servicio de autenticación en la nube que, de modo similar a Access Control, permite a los desarrolladores externalizar la lógica de administración de identidades y la autenticación a un servicio en la nube. Es un servicio de pago (con niveles Premium y gratuito) diseñado para aquellas aplicaciones orientadas al cliente 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. Gracias a Azure AD B2C, los usuarios pueden iniciar sesión mediante una cuenta de Microsoft, Facebook, Google, LinkedIn, GitHub o Yahoo entre otras. Además, Azure AD B2C admite "cuentas locales" o nombres 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 es compatible con la amplitud de protocolos de autenticación y formatos de token que pueden necesitar los clientes de Access Control. Tampoco se puede usar Azure AD B2C para obtener tokens y consultar información adicional sobre el usuario del proveedor de identidad, Microsoft o de otro modo.
En la siguiente tabla se comparan las características de Access Control pertinentes a las aplicaciones web, con aquellas que están disponibles en Azure AD B2C. En general, B2C de Azure AD es, probablemente, la elección correcta para la migración si su aplicación está orientada hacia el consumidor, o si admite muchos tipos diferentes de cuentas.
| Capacidad | Soporte técnico de Access Control | Compatibilidad de Azure AD B2C |
|---|---|---|
| Tipos de cuentas | ||
| Cuentas educativas o profesionales de Microsoft | Compatible | Compatible a través de directivas personalizadas |
| Cuentas de Windows Server Active Directory y AD FS | Compatible a través de la federación directa con AD FS | Compatible a través de federación de SAML mediante directivas personalizadas |
| Cuentas desde otros sistemas de administración de identidades empresariales | Compatible a través de la federación directa mediante WS-Federation | Compatible a través de federación de SAML mediante directivas personalizadas |
| Cuentas de Microsoft para uso personal | Compatible | Compatible |
| Cuentas de Facebook, Google, Yahoo | Compatible | Facebook y Google se admiten de forma nativa, Yahoo se admite a través de la federación de OpenID Connect mediante directivas personalizadas. |
| Compatibilidad con el SDK y protocolos | ||
| Windows Identity Foundation (WIF) | Compatible | No compatible |
| El certificado del proveedor de identidades de WS-Federation | Compatible | No compatible |
| OAuth 2.0 | Soporte para Draft 13 | Compatibilidad con RFC 6749, la especificación más moderna. |
| WS-Trust | Compatible | No compatible |
| Formatos de tokens | ||
| JWT | Compatible en versión beta | Compatible |
| SAML 1.1 | Compatible | No compatible |
| SAML 2.0 | Compatible | No compatible |
| SWT | Compatible | No compatible |
| Personalizaciones | ||
| UI de selección de cuenta o detección de dominio de inicio personalizable | Código descargable que se puede incorporar en las aplicaciones | Interfaz de usuario totalmente personalizable a través de CSS personalizadas |
| Carga de certificados de firma de tokens personalizados | Compatible | Las claves de firma personalizadas, no los certificados, se admiten a través de directivas personalizadas |
| Personalización de notificaciones en tokens | - Paso a través de notificaciones de entrada desde proveedores de identidad - Obtención de token de acceso del proveedor de identidades como una notificación - Emisión de notificaciones de salida basadas en valores de las notificaciones de entrada - Emisión de notificaciones de salida con valores constantes |
- Puede pasar a través de notificaciones de proveedores de identidad; directivas personalizadas necesarias para algunas notificaciones - No se puede obtener el token de acceso del proveedor de identidades como una notificación - No se pueden emitir notificaciones de salida según los valores de las notificaciones de entrada a través de directivas personalizadas - Se pueden emitir notificaciones de salida con valores constantes a través de directivas personalizadas |
| Automation | ||
| Automatización de las tareas de configuración y administración | Compatible a través del servicio de administración de Access Control | - Creación de usuarios permitidos mediante Microsoft Graph API - No se pueden crear mediante programación las directivas, las aplicaciones ni los inquilinos de B2C |
Si decide que Azure AD B2C es la forma adecuada para migrar sus aplicaciones y servicios, debe comenzar con los recursos siguientes:
Migrar a la identidad de Ping o Auth0
En algunos casos, es posible que Microsoft Entra ID y Azure AD B2C no sean suficientes para reemplazar Access Control en las aplicaciones web sin tener que realizar cambios importantes en el código. Algunos ejemplos comunes pueden incluir:
- Aplicaciones web que usen WIF o WS-Federation para el inicio de sesión con proveedores de identidades sociales como Google o Facebook.
- Aplicaciones web que realicen una federación directa a un proveedor de identidades de empresa mediante el protocolo WS-Federation.
- Aplicaciones web que requieren el token de acceso que emite un proveedor de identidades sociales (como Google o Facebook) como una notificación en los tokens que emite Access Control.
- Aplicaciones web con reglas complejas de transformación de tokens que Microsoft Entra ID o Azure AD B2C no pueden reproducir.
- Aplicaciones web de varios inquilinos que utilizan ACS para administrar de forma centralizada la federación de varios proveedores de identidades.
En estos casos, conviene considerar la posibilidad de migrar la aplicación web a otro servicio de autenticación en la nube. Le recomendamos que tenga en cuenta las opciones siguientes. Cada una de ellas ofrece capacidades similares a Access Control:
Auth0 es un servicio de identidad en la nube flexible que ha creado una guía de migración de alto nivel para los clientes de Access Control y es compatible con casi todas las características de ACS.
La identidad de Ping le ofrece dos soluciones similares a ACS. PingOne es un servicio de identidad en la nube que admite muchas de las características de ACS, mientras que PingFederate es un producto de identidad local similar que ofrece más flexibilidad. Si quiere obtener más detalles acerca de cómo usar estos productos, consulte Ping's ACS retirement guidance (Guía de retirada de ACS de Ping).
Nuestro objetivo al trabajar con la identidad de Ping y Auth0 es asegurarnos de que todos los clientes de Access Control tengan una ruta de migración que minimice la cantidad de trabajo necesario para mover las aplicaciones y servicios de Access Control.
Servicios web que usan la autenticación activa
Access Control ofrece las siguientes características y funcionalidades para los servicios web que están protegidos con tokens que el mismo Access Control emitió:
- La 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 creada para la identidad del servicio.
- Un SWT firmado mediante una clave simétrica o un certificado X509.
- Un token SAML que emitió un proveedor de identidad 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 simples de transformación de token.
Las identidades de servicio de Access Control se suelen usar para implementar la autenticación de servidor a servidor (S2S).
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 de cuentas profesionales o educativas de Microsoft. Microsoft Entra ID es el proveedor de identidades para Microsoft 365, Azure y muchos servicios más.
Asimismo, también puede utilizar Microsoft Entra ID para realizar la autenticación de un servidor a otro mediante la implementación de Microsoft Entra para la concesión de credenciales de cliente OAuth. En la tabla siguiente se comparan las funcionalidades de Access Control en la autenticación de servidor a servidor, con aquellas que están disponibles en Microsoft Entra ID.
| Capacidad | Soporte técnico de Access Control | Compatibilidad con Microsoft Entra ID |
|---|---|---|
| Procedimiento para registrar un servicio web | Crear un usuario de confianza en el portal de administración de Access Control | Creación de una aplicación web de Microsoft Entra en el Azure Portal |
| Procedimiento de registro de un cliente | Crear una identidad de servicio en el portal de administración de Access Control | Creación de otra aplicación web de Microsoft Entra en el Azure Portal |
| Protocolo usado | - Protocolo WRAP de OAuth - Concesión de credenciales del cliente de OAuth 2.0 Draft 13 |
Concesión de credenciales del cliente de OAuth 2.0 |
| Métodos de autenticación del cliente | - Contraseña simple - SWT firmado - Token SAML del proveedor de identidades federadas |
- Contraseña simple - SWT firmado |
| Formatos de tokens | - JWT - SAML 1.1 - SAML 2.0 - SWT |
Solo JWT |
| Transformación de token | - Incorporación de notificaciones personalizadas - Lógica de emisión de notificaciones if-then simple |
Incorporación de notificaciones personalizadas |
| Automatización de las tareas de configuración y administración | Compatible a través del servicio de administración de Access Control | Compatible mediante Microsoft Graph API |
Para obtener información sobre escenarios de implementación entre servidores, consulte los siguientes recursos:
- Sección Servicio a servicio de la Guía del desarrollador de Microsoft Entra
- Daemon code sample by using simple password client credentials (Ejemplo de código Daemon que usa credenciales de cliente con contraseñas simples)
- Daemon code sample by using certificate client credentials (Ejemplo de código Daemon que usa credenciales de cliente con certificados)
Migrar a la identidad de Ping o Auth0
En algunos casos, es posible que las credenciales del cliente de Microsoft Entra y la concesión de implementación de OAuth no sean suficientes para reemplazar Access Control en la arquitectura sin tener que realizar cambios importantes en el código. Algunos ejemplos comunes pueden incluir:
- Autenticación de servidor a servidor mediante formatos de token distintos de los JWT.
- Autenticación de servidor a servidor mediante un token de entrada que proporciona un proveedor de identidades externo.
- Autenticación de servidor a servidor con las reglas de transformación de tokens que Microsoft Entra ID no puede reproducir.
En estos casos, conviene considerar la posibilidad de migrar la aplicación web a otro servicio de autenticación en la nube. Le recomendamos que tenga en cuenta las opciones siguientes. Cada una de ellas ofrece capacidades similares a Access Control:
Auth0 es un servicio de identidad en la nube flexible que ha creado una guía de migración de alto nivel para los clientes de Access Control y es compatible con casi todas las características de ACS.
La identidad de Ping ofrece dos soluciones similares a ACS. PingOne es un servicio de identidad en la nube que admite muchas de las características de ACS, mientras que PingFederate es un producto de identidad local similar que ofrece más flexibilidad. Si quiere obtener más detalles acerca de cómo usar estos productos, consulte Ping's ACS retirement guidance (Guía de retirada de ACS de Ping).
Nuestro objetivo al trabajar con la identidad de Ping y Auth0 es asegurarnos de que todos los clientes de Access Control tengan una ruta de migración que minimice la cantidad de trabajo necesario para mover las aplicaciones y servicios de Access Control.
Autenticación de paso a través
Para la autenticación de paso a través con la transformación de tokens arbitraria, no hay ninguna tecnología de Microsoft equivalente a ACS. Si eso es lo que necesitan los clientes, Auth0 puede que sea quien proporciona la solución de aproximación más cercana.
Preguntas, problemas y comentarios
Somos conscientes de que muchos clientes de Access Control no encontrarán una ruta de acceso de migración clara después de leer este artículo. Es posible que necesite un poco más de ayuda para poder determinar el plan correcto que debe seguir. Si desea analizar los escenarios de migración y otras cuestiones, deje un comentario en esta página.