Conclusiones clave:
La integración de Okta con marcos de federación multilaterales como InCommon o EduGAIN requiere un adaptador de federación (como Cirrus Identity o Shibboleth) para conectar la arquitectura SAML bilateral de Okta con el registro de metadatos dinámicos de InCommon.
Las instituciones pueden implementar Okta como proveedor de identidad (IdP) de InCommon para el acceso saliente o como proveedor de servicios (SP) para la colaboración entrante.
Introducción a la integración de Okta e InCommon
Para las instituciones de educación superior y los centros de investigación asociados, la utilización del marco InCommon es esencial. Tradicionalmente, Okta no admite el modelo de federación bilateral utilizado por InCommon; sin embargo, existe una solución. Esta guía proporciona una descripción técnica general y patrones arquitectónicos para integrar un inquilino de Okta con un modelo de federación multilateral como InCommon o eduGAIN, lo que le permite participar en la Federación InCommon como proveedor de identidad (IdP) o como proveedor de servicios (SP).
Casos de uso de integración principal
Esta guía está diseñada para arquitectos de identidad en instituciones que utilizan Okta como su plataforma de identidad principal, pero que requieren interoperabilidad con la comunidad de investigación y educación (I+E) más amplia a través de InCommon, ya sea como proveedor de identidad (IDP) de InCommon o proveedor de servicios (SP) de InCommon.
Exploraremos dos escenarios principales:
- Okta como IdP de InCommon: conceder a los estudiantes autenticados en instituciones que utilizan Okta acceso a Recursos de terceros de InCommon
- Okta como proveedor de servicios de InCommon: proteger las aplicaciones institucionales con Okta al tiempo que se permite el acceso a la comunidad InCommon en general
Si bien mostraremos Okta en ambos lados de la transacción, los modelos se aplican a otras soluciones de gestión de identidades y accesos (IAM) empresariales.
Contextualización de la terminología de federación: IdP frente a proveedor de servicios
El uso de los términos proveedor de identidad (IdP) y proveedor de servicios (SP), si bien es apropiado, puede depender del contexto.
- En el patrón arquitectónico 1 (Okta como IdP de InCommon): Okta es el IdP para las aplicaciones universitarias y el IdP para el adaptador de federación, Cirrus Bridge. El adaptador actúa como un proveedor de servicios (SP) para Okta. Sin embargo, en este caso de uso, Cirrus Bridge también funciona como un IdP de InCommon, lo que permite a los estudiantes y profesores obtener SSO para recursos de terceros que actúan como SP de InCommon. En este caso, Okta es un IdP, Cirrus Bridge es tanto un proveedor de servicios como un IdP, y los recursos de terceros son proveedores de servicios.
- En el patrón arquitectónico 2 (Okta como InCommon proveedor de servicios): Okta es el IdP para las aplicaciones de la institución de investigación utilizadas tanto por los estudiantes como por el profesorado de la institución de investigación. Al mismo tiempo, Okta permite el acceso a la aplicación a usuarios externos de InCommon. Para los usuarios externos de InCommon, Okta es un proveedor de servicios (SP) y Cirrus Proxy es el proveedor de identidad (IdP). Sin embargo, Cirrus Proxy es un proveedor de servicios de InCommon.
Comparación de modelos de federación: bilateral frente a multilateral
Modelo de federación bilateral de Okta
Okta es el servicio de IAM líder del mercado, diseñado para proporcionar acceso al lenguaje de marcado para aserciones de seguridad (SAML), OpenID Connect (OIDC) y aplicaciones locales basadas en encabezados. Muchas instituciones de educación superior e investigación utilizan Okta y, en algunos casos, una sola institución puede funcionar tanto como proveedor de identidad (IdP) como proveedor de servicios (SP). La arquitectura de federación de Okta se basa en una relación de confianza única, punto a punto, configurada entre un único IdP y un único proveedor de servicios.
Este enfoque punto a punto se conoce como federación bilateral, que es el modelo estándar utilizado por todos los principales proveedores comerciales de gestión de identidades y accesos (IAM). Este modelo proporciona un control granular y es estándar para aplicaciones empresariales y comerciales.
El modelo de federación multilateral de InCommon
A diferencia del enfoque bilateral de Okta, que requiere una conexión específica y preconfigurada para cada asociación de federación, InCommon opera con un modelo de federación multilateral. Se trata de un marco de confianza de muchos a muchos que permite la interoperabilidad de miles de instituciones participantes sin crear relaciones bilaterales individuales.
Un registro central de confianza lo hace posible al alojar un servicio de metadatos que contiene los metadatos SAML de todos los miembros. InCommon proporciona este registro de confianza como el “Agregado de metadatos SAML heredado” o el “Servicio de consulta de metadatos (MDQ)”. Un proveedor de servicios puede confiar en toda la federación InCommon y, al consumir estos metadatos, aceptar la autenticación de cualquier IdP registrado.
Si bien la federación multilateral y el servicio de metadatos son los principales factores diferenciadores entre un modelo comercial y el modelo de la comunidad de I+E, no son las únicas diferencias. InCommon también define requisitos estandarizados de autenticación y atributos:
- Expresar afirmaciones específicas de autenticación multifactor (MFA) que cumplan con el perfil MFA de REFEDS.
- Publicación de paquetes estandarizados de atributos de usuario basados en marcos de consentimiento predeterminados.
Dado que Okta no admite de forma nativa el consumo dinámico de metadatos necesario para la federación multilateral, debe utilizar un adaptador de federación como intermediario.
La arquitectura del adaptador de federación: un requisito previo para la integración
Para salvar la brecha entre el modelo bilateral de Okta y el modelo multilateral de InCommon, debe utilizar un adaptador especializado tanto en el lado del IdP como en el del proveedor de servicios de la conexión.
- Como proveedor de identidad InCommon (patrón 1): este adaptador procesa el flujo de metadatos de InCommon y se comunica con Okta a través de una conexión SAML bilateral estándar.
- Como proveedor de servicios (SP) de InCommon (patrón 2): este adaptador solicita al usuario que identifique su institución de origen, busca los metadatos de dicha institución, genera la solicitud de autenticación correcta para esa institución y, a continuación, consume y valida la afirmación SAML entrante.
Elegir un adaptador: Shibboleth vs. Cirrus Identity
La comunidad de investigación y educación acepta ampliamente dos soluciones de adaptadores principales: Cirrus Identity y Shibboleth.
Cirrus Identity: Una solución comercial basada en SaaS diseñada específicamente para este propósito. Simplifica la implementación y la gestión. Cirrus ofrece dos soluciones diferentes: Cirrus Bridge, utilizada en el caso de uso 1 (InCommon IDP); y Cirrus Proxy, utilizada en el caso de uso 2 (InCommon proveedor de servicios). Cirrus proporciona documentación detallada para estas integraciones, que sirve como referencia principal:
Shibboleth: un proyecto de software de código abierto ampliamente utilizado en la comunidad de investigación y educación. Puede implementarse en local o en una nube privada. El software Shibboleth IdP actúa como componente adaptador. Los recursos clave incluyen:
Tanto Cirrus Identity como Shibboleth funcionarán al usar Okta y un adaptador InCommon. La solución que elija dependerá de las preferencias de su organización.
| Artículo destacado | Cirrus Bridge/Proxy | Shibboleth |
|---|---|---|
| Modelo de implementación | SaaS (Software como servicio) | Autogestionado (local o como máquina virtual en la nube) |
| Ventajas |
|
|
| Desventajas |
|
|
Patrón de arquitectura 1: Okta como proveedor de identidad de InCommon
En este escenario, una universidad utiliza Okta para sus estudiantes, profesores y personal. La universidad alimenta Okta con sus sistemas de información estudiantil y/o de recursos humanos, y proporciona aprovisionamiento, Single Sign-On (SSO) y autenticación multifactor (MFA) para varias aplicaciones, incluidas Google Workspace, Microsoft Entra ID, Canvas y Blackboard. Okta también aprovisiona usuarios a Active Directory. El objetivo es permitir a los usuarios universitarios acceder a servicios externos federados por InCommon, como revistas de investigación, servicios de bibliotecas de terceros y aplicaciones de la NSF.
Configuración de la arquitectura
- La universidad registra Cirrus Bridge como su proveedor de identidad oficial en el registro de confianza de InCommon.
- Cirrus Bridge está configurado para apuntar en etapa inicial al inquilino de Okta de la universidad como su IdP SAML autoritativo.
- Okta se encarga de la autenticación principal de usuarios, la aplicación de la autenticación multifactor y la gestión fundamental del ciclo de vida de las identidades.
Cómo funcionan los flujos de autenticación para Okta como proveedor de identidad (IdP)
Para un flujo iniciado por el IDP, comience con el inicio de sesión opcional
- El usuario no autenticado inicia sesión directamente en el panel de usuario final de Okta.
- El usuario hace clic en un enlace a la aplicación externa InCommon de destino.
- Okta genera una afirmación SAML y la envía a Cirrus Bridge.
- Cirrus Bridge traduce la afirmación a un formato multilateral y la transmite al recurso de destino.
Para un flujo iniciado por el proveedor de servicios, no utilice el inicio de sesión opcional y realice el inicio de sesión cuando sea necesario.
- El usuario navega directamente al recurso InCommon de terceros de destino.
- El recurso redirige al usuario a Cirrus Bridge mediante la búsqueda de metadatos de InCommon.
- Cirrus Bridge redirige al usuario a Okta para la verificación de credenciales principales.
- Tras una autenticación exitosa, Okta emite un token a Cirrus Bridge, que redirige al usuario de vuelta al recurso.
Patrón de arquitectura 2: Okta como proveedor de servicios de InCommon
En este escenario, una institución de investigación utiliza Okta para proteger el acceso a sus aplicaciones. En lugar de emitir credenciales separadas para cada usuario, la institución quiere aceptar usuarios de la federación InCommon. Esto permite a dichos usuarios acceder a las aplicaciones de la institución de investigación utilizando sus propias credenciales universitarias sin necesidad de crear una nueva cuenta. La institución de investigación también desea habilitar el inicio de sesión directo para su personal de investigación.
Configuración de la arquitectura
- Cirrus Proxy está registrado como proveedor de servicios (SP) de InCommon en el registro multilateral.
- Okta está configurado para confiar en Cirrus Proxy como proveedor de identidad (IdP) de entrada mediante una configuración SAML bilateral.
- Las aplicaciones de destino permanecen integradas directamente con Okta como inicio de sesión único (SSO) estándar en las aplicaciones.
Flujos de descubrimiento y autenticación de identidad
Un componente importante al habilitar el acceso de InCommon a Okta es garantizar que los usuarios inicien sesión a través de las rutas correctas.
Flujo de inicio de sesión directo para el personal interno
- El personal de investigación interno accede a la aplicación directamente a través de su cuenta de Okta.
- Okta autentica a los usuarios internos directamente sin recurrir al pipeline de detección externo.
Flujo de inicio de sesión iniciado por el proveedor de servicios para usuarios externos de InCommon
Un usuario externo accede directamente a la aplicación o desde el panel de control de su universidad de origen. En este punto, se le pueden solicitar al usuario sus credenciales utilizando cualquiera de los dos métodos que se describen a continuación. El enfoque se basará en los requisitos de la institución.
Usuario > Acceso a recursos > Okta presenta un widget de inicio de sesión con un enlace a la pantalla de detección en Cirrus Proxy
El usuario puede iniciar sesión directamente a través del widget de Okta o seleccionar “Iniciar sesión con InCommon”, lo que lo lleva a la pantalla de detección de IDP en Cirrus Proxy
Usuario > Acceso a recursos > Cirrus Proxy presenta una página de inicio de sesión con un enlace a un widget de Okta
Al usuario se le muestra inmediatamente la pantalla de detección de Cirrus Proxy IDP.
El personal puede iniciar sesión directamente a través del widget de Okta
En este ejemplo, el usuario elige utilizar InCommon para la autenticación.
- El usuario es redirigido a la interfaz de detección de Cirrus Proxy para seleccionar su institución de origen.
- Cirrus Proxy consulta el servicio MDQ, recupera los metadatos SAML de la institución de origen y redirige al usuario a la página de inicio de sesión de su universidad local.
- Tras el exitoso inicio de sesión en la universidad de origen, el proveedor de identidad (IdP) de origen envía una afirmación SAML a Cirrus Proxy.
- Cirrus Proxy valida la afirmación y envía una afirmación formateada a Okta, otorgando al usuario acceso a la aplicación.
Optimice su federación multilateral con Okta
Integrar Okta con federaciones multilaterales no tiene por qué ser complejo. Nuestra integración con Cirrus Federation Bridge permite la autenticación y el aprovisionamiento para usuarios finales en instituciones de educación superior e investigación.
A diferencia de otros kits de herramientas de gestión de identidades, Okta no requiere que dedique tiempo ni recursos a conectar manualmente las aplicaciones web a sus directorios de usuarios. En cambio, integramos las aplicaciones directamente en nuestro servicio, para que pueda implementarlas fácilmente para sus usuarios.
Descargue el documento técnico sobre integraciones de aplicaciones para obtener más información sobre cómo simplificamos las conexiones de aplicaciones en todo su ecosistema.
