Federaciones multilaterales y Azure AD - El reto
Las Federaciones multilaterales facilitan la colaboración en varias organizaciones de todo el mundo. Es un componente fundamental para la arquitectura de gestión de identidades y acceso en la educación superior y en investigación. Azure AD no es compatible con la federación multilateral de forma nativa, pero hay soluciones disponibles para llenar el vacío.
Estrategia de Azure AD y IAM(gestion de ID)
Muchos campus están migrando a Azure AD como parte de una implementación de Microsoft 365, o una estrategia de TI "en la nube primero", o para consolidar SSO y aprovechar otras ofertas de Microsoft como MFA. En algunos casos, los campus siguen ejecutando Active Directory de forma local y sincronizan la información de cuentas con Azure AD. Otros campus están migrando toda su infraestructura SSO a la nube, con Azure AD en el centro.
En una era de fuertes recortes presupuestarios y equipos de IAM tensos, la consolidación de servicios y plataformas tiene mucho sentido.
Desafortunadamente, una desventaja importante de Azure AD es que no admite directamente la participación en federaciones multilaterales como InCommon u otras federaciones de confianza de eduGAIN.
La meta de este post es para:
- Describir el valor de la federación multilateral para agilizar la prestación de servicios en múltiples organizaciones.
- Explicar por qué Azure AD no admite la federación multilateral de forma inmediata.
- Proporcionar una descripción general de las soluciones que admiten la federación multilateral para proveedores de identidad de Azure AD.
¿Por qué la federación multilateral?
Azure AD se puede usar para iniciar sesión en miles de aplicaciones desde Azure App Gallery o en aplicaciones SAML personalizadas. Estos tipos de integraciones se denominan interacciones bilaterales: el administrador de la aplicación de Azure AD y el propietario de la aplicación intercambian información sobre claves de firma, URL, requisitos de atributos, metadatos, etc. para que la integración funcione.
El acceso global es clave
¿Qué sucede si usted es un equipo de investigación interuniversitario que desarrolla una aplicación y los investigadores universitarios de todo el mundo necesitan acceder a esta aplicación? ¿Necesitas ponerte en contacto con cientos de universidades de todo el mundo para realizar cientos de integraciones bilaterales? ¿Cómo sabías a quién contactar? ¿Todas estas tareas podrían ser manejadas por un tercero de confianza?
Desde el lado del operador del proveedor de identidad en una universidad, ¿desea evaluar, examinar y configurar cada aplicación que un investigador o estudiante quiera usar? Estas tareas tendrán que repetirse en miles de escuelas. ¿Podría esto también ser manejado por un tercero de confianza?
En la educación superior existe un tercero de confianza, el operador de la federación. El operador de la federación realiza muchas tareas: evalúa a los miembros, recopilar metadatos sobre sus proveedores de identidad y proveedores de servicios / aplicaciones, proporciona un marco para la interoperabilidad y muchas más tareas. En los Estados Unidos, la federación de identidad es InCommon, en Canadá es la Canadian Access Federation, el Reino Unido tiene la UK Access Management Federation, y la mayoría de las federaciones de países participan en eduGAIN, un servicio que permite el acceso entre federaciones nacionales.
Una función importante del operador de la federación es agregar metadatos (cosas como claves de firma, URL de inicio de sesión, información de contacto, tipos de cifrado admitidos, categorías de entidades) sobre las aplicaciones de los miembros y los proveedores de identidad y ponerlos a disposición de sus miembros de forma segura. Esto permite a los operadores IdP definir reglas generales como la liberación de atributos para “categorías de entidad” específicas. Una de esas categorías que ya está definida en los metadatos de la federación es para las aplicaciones que cumplen con los criterios para ser aplicaciones de “Research & Investigation (R&S)”. Los proveedores de identidad que participan en la federación pueden publicar un conjunto acordado de atributos, como la dirección de correo electrónico, el nombre y la información de afiliación, a esos servicios etiquetados con R & S.
En resumen, la federación multilateral proporciona un marco de confianza que permite a un proveedor de servicios confiar en cientos de proveedores de identidad a la vez, sin una integración laboriosa y que requiere mucho tiempo con cada proveedor de identidad de forma independiente.
¿Por qué no puedo registrar mi IdP de Azure AD con InCommon?
Muchos participantes de la federación desean usar Azure AD como su principal fuente de autenticación para las aplicaciones. La galería de aplicaciones les facilita agregar aplicaciones que no pertenecen a la federación, la compatibilidad con MFA les permite proteger fácilmente a los usuarios, las reglas de políticas enriquecidas les permiten controlar quién puede acceder a qué y cuándo, y los informes les brindan información sobre qué aplicaciones vale la pena proporcionar.
Sin embargo, las escuelas participantes que desean usar Azure AD en una federación multilateral enfrentan varios desafíos, entre ellos:
- Azure AD no consulta ni consume metadatos de la federación multilateral
- A los IdP de la federación les gusta definir reglas basadas en atributos en los metadatos de la federación, como REFEDS Research and Scholarship, como se describe anteriormente, en lugar de la aplicación en sí. Azure AD no tiene un mecanismo equivalente.
- Las reglas de federación requieren que el entityID de su proveedor de identidad SAML sea una URL en el dominio de la escuela. De fábrica, el proveedor de identidad SAML de Azure AD se encuentra en el dominio de windows.net y no se puede registrar en la federación.
- La política de sustitución de claves de firma de Azure AD no se adapta bien a las políticas del operador de la federación. Los operadores de la federación quieren que los IdP registren nuevas claves varios días antes del uso para proporcionar tiempo para que la actualización se propague a todos los miembros (un enfoque de inserción). Azure AD recomienda que las aplicaciones extraigan metadatos periódicamente directamente de Microsoft para obtener información sobre nuevas claves de firma.
- Los niveles de suscripción de Azure AD no premium no permiten que el administrador personalice la publicación de atributos y, en su lugar, publique un conjunto predeterminado. Los proveedores de servicios en los metadatos de federación (como InCommon) esperan que estos atributos se denominen de forma diferente a los valores predeterminados de Azure.
- Las aplicaciones de federación señalan los requisitos de varios factores de una manera incompatible con Azure AD (consulte el contexto de autenticación de REFEDS MFA).
- Las federaciones tienen requisitos básicos de participación en evolución. Incluso si Microsoft actualiza Azure AD para cumplir con las brechas descritas anteriormente, mantenerse al día con los estándares y especificaciones en evolución en el espacio de IAM de investigación y educación superior requeriría la asignación continua de recursos de ingeniería, administración de cuentas y políticas de Microsoft.
Aunque Azure AD no se integra con la federación multilateral, proporciona herramientas para agregar integraciones SAML personalizadas. El truco consiste en cerrar la brecha entre los proveedores de servicios enumerados en los metadatos SAML de la federación y la instancia de Azure AD de una organización determinada.
Federación Multilateral con Azure AD
Dos de las soluciones más populares para establecer un proveedor de identidad habilitado para una federación multilateral son los proyectos de código abierto: Shibboleth y SimpleSAMLphp. Ambos se pueden implementar de forma local o en la nube. Estas soluciones se pueden configurar para autenticarse en Azure AD e integrar metadatos de federación multilateral para otros proveedores de identidad y proveedores de servicios.
Algunos campus carecen de los recursos de personal interno para ejecutar estos proyectos internamente. Para abordar ese desafío, Cirrus Identity ofrece una solución Bridge completamente administrada y alojada en la nube. Cirrus Bridge soluciona las discrepancias entre las expectativas de la Federación y las capacidades de Azure AD. Con Cirrus Bridge, las universidades pueden usar Azure AD como su IdP principal y participar en InCommon / eduGAIN. Dado que Bridge es un servicio gestionado, las universidades no tienen que asignar muchos recursos de TI al servicio y pueden centrarse en otras prioridades.
Cirrus Bridge está registrado como aplicación en Azure AD y como IdP en InCommon. Mediante políticas locales y basadas en metadatos, puede traducir, transformar y filtrar datos de atributos que provienen de Azure AD al formato deseado que necesitan las aplicaciones de federación. Cirrus Bridge admite la publicación de atributos REFEDS Research and Scholarship, así como el contexto de autenticación REFEDS MFA. En nuestro servicio actual, una vez que el puente está configurado en el portal de Azure AD, todas las aplicaciones de federación aparecen como una única aplicación de puente en Azure AD. En desarrollo está nuestra próxima versión, que permitirá a los clientes conectar aplicaciones de federación específicas con aplicaciones de Azure AD específicas y, por lo tanto, aprovechar aún más de las características de Azure AD que les encantan (informes, política de acceso, etc.) con aplicaciones de federación.
Cirrus Identity es miembro desde hace mucho tiempo de la comunidad de gestión de identidades de investigación y educación superior. Participamos activamente en el reciente grupo de trabajo Proveedor de Identidad como Servicio creado por el Comité Asesor Técnico de InCommon. También somos una de las empresas fundadoras del programa InCommon Catalyst que pronto se formalizará.