Intégration d’Okta avec la fédération multilatérale InCommon

Présentation de l’intégration d’Okta et d’InCommon

Pour les établissements d’enseignement supérieur et les centres de recherche partenaires, l’utilisation du framework InCommon est essentielle. Traditionnellement, Okta ne prend pas en charge le modèle de fédération bilatérale utilisé par InCommon ; cependant, il existe une solution. Ce guide propose une vue d’ensemble technique et présente des modèles architecturaux pour intégrer un tenant Okta à un modèle de fédération multilatérale tel qu’InCommon ou eduGAIN, afin de vous permettre de participer à la Fédération InCommon en tant que fournisseur d’identité (IdP) ou fournisseur de services (SP).

Principaux cas d’usage de l’intégration

Ce guide s’adresse aux architectes de l’identité au sein d’institutions qui utilisent Okta comme principale plateforme d’identité, mais qui ont besoin d’interopérabilité avec la communauté élargie de la recherche et de l’enseignement (R&E) via InCommon, que ce soit en tant qu’IDP InCommon ou SP InCommon.

Nous allons examiner deux scénarios principaux : 

1. Okta en tant qu’IdP InCommon : permettre aux étudiantes et étudiants authentifiés dans des établissements équipés d’Okta d’accéder à des ressources InCommon tierces
2. Okta en tant que SP InCommon : sécuriser les applications institutionnelles avec Okta tout en permettant à l’ensemble de la communauté InCommon d’y accéder

Même si nous présenterons Okta des deux côtés de la transaction, ces modèles s’appliquent également à d’autres solutions de gestion des identités et des accès (IAM) d’entreprise.

Contextualisation de la terminologie de la fédération : IdP vs. SP

L’utilisation des termes fournisseur d’identité (IdP) et fournisseur de services (SP), bien qu’adaptée, peut dépendre du contexte. 

• Dans le modèle d’architecture 1 (Okta en tant qu’IdP InCommon) : Okta est l’IdP pour les applications universitaires et l’IdP pour l’adaptateur de fédération, Cirrus Bridge. L’adaptateur agit en tant que fournisseur de services (SP) pour Okta. Cependant, dans ce cas d’usage, Cirrus Bridge joue également le rôle d’IdP InCommon, permettant aux étudiants et aux membres du corps enseignant d’accéder via l’authentification unique (SSO) à des ressources tierces agissant en tant que SP InCommon. Dans ce cas, Okta est un IdP, Cirrus Bridge est à la fois un SP et un IdP, et les ressources tierces sont des SP.
• Dans le modèle d’architecture 2 (Okta en tant que SP InCommon) : Okta est l’IdP pour les applications de l’institution de recherche utilisées à la fois par les étudiants et les enseignants de l’institution de recherche. Parallèlement, Okta permet aux utilisateurs et utilisatrices externes InCommon d’accéder à l’application.  Pour les utilisateurs et utilisatrices externes d’InCommon, Okta est un SP et le proxy Cirrus est l’IdP.  Cependant, le Cirrus Proxy est un fournisseur de services InCommon. 

Comparer les modèles de fédération : bilatéral ou multilatéral

Le modèle de fédération bilatérale d’Okta

Okta est la solution d’IAM leader du marché, conçue pour fournir un accès à Security Assertion Markup Language (SAML), OpenID Connect (OIDC) et aux applications header-based on-premise. De nombreux établissements d’enseignement supérieur et de recherche utilisent Okta, et dans certains cas, un même établissement peut agir à la fois en tant qu’IdP et en tant que SP. L’architecture de fédération Okta repose sur une relation de confiance unique, configurée en point à point entre un seul IdP et un seul SP. 

Cette approche point à point est appelée fédération bilatérale, qui constitue le modèle standard utilisé par tous les principaux fournisseurs commerciaux d’IAM. Ce modèle offre un contrôle granulaire et constitue la norme pour les applications d’entreprise et commerciales. 

Le modèle de fédération multilatérale d’InCommon

Contrairement à l’approche bilatérale d’Okta, qui nécessite une connexion spécifique et préconfigurée pour chaque partenariat de fédération, InCommon fonctionne selon un modèle de fédération multilatérale. Il s’agit d’un framework de confiance de type plusieurs-à-plusieurs qui permet à des milliers d’établissements participants d’interopérer sans avoir à créer de relations bilatérales individuelles. 

Un registre central de confiance rend cela possible en hébergeant un service de métadonnées qui contient les métadonnées SAML pour l’ensemble des membres. InCommon propose ce registre de confiance sous la forme du « Legacy SAML Metadata Aggregate » ou du « Metadata Query (MDQ) Service ». Un SP peut faire confiance à l’ensemble de la fédération InCommon et, en consommant ces métadonnées, accepter l’authentification de tout IdP enregistré. 

Si la fédération multilatérale et le service de métadonnées constituent les principaux éléments différenciateurs entre un modèle commercial et le modèle de la communauté R&E, ce ne sont pas les seules différences. InCommon définit également des exigences standardisées en matière d’authentification et d’attributs :

• Exprimer des assertions d’authentification multifacteur (MFA) spécifiques conformes au profil MFA de REFEDS. 
• Publier des bundles standardisés d’attributs utilisateur, fondés sur des frameworks de consentement prédéfinis. 

Comme Okta ne prend pas en charge nativement la consommation dynamique des métadonnées requise pour la fédération multilatérale, vous devez utiliser un adaptateur de fédération comme intermédiaire.

L’architecture de l’adaptateur de fédération : un prérequis pour l’intégration 

Pour combler la lacune entre le modèle bilatéral d’Okta et le modèle multilatéral d’InCommon, vous devez utiliser un adaptateur spécialisé à la fois du côté IdP et du côté SP de la connexion.  

• En tant qu’IdP InCommon (modèle 1) : cet adaptateur traite le flux de métadonnées InCommon et communique avec Okta via une connexion SAML bilatérale standard. 
• En tant que fournisseur de services InCommon (modèle 2) : cet adaptateur invite la personne utilisatrice à identifier son institution d’origine, recherche les métadonnées associées à cette institution, génère la demande d’authentification appropriée à destination de cet institution, puis consomme et valide l’assertion SAML reçue. 

Choisir un adaptateur : Shibboleth ou Cirrus Identity

La communauté R&E adopte largement deux principales solutions d’adaptateur : Cirrus Identity et Shibboleth.

• Cirrus Identity : une solution commerciale SaaS conçue spécifiquement à cet effet. Elle simplifie le déploiement et la gestion. Cirrus propose deux solutions différentes : Cirrus Bridge, pour le cas d’usage 1 (InCommon IDP) ; et Cirrus Proxy pour le cas d’usage 2 (InCommon SP). Cirrus propose une documentation détaillée pour ces intégrations, qui fait office de référence principale :

  • Documentation Cirrus Bridge

  • Documentation Cirrus Proxy

  • Guide d’installation de Cirrus Bridge spécifique à Okta

  • Intégration d’Okta avec Cirrus

• Shibboleth : un projet logiciel open source largement utilisé dans la communauté de la recherche et de l’enseignement. Vous pouvez le déployer en on-premise ou dans un cloud privé. Le logiciel IdP Shibboleth fait office de composant adaptateur. Principales ressources : 

  • Page d’accueil du projet Shibboleth

  • Documentation du fournisseur d’identité Shibboleth

  • Guide Shibboleth d’InCommon

Cirrus Identity et Shibboleth fonctionnent tous deux avec Okta et un adaptateur InCommon. Le choix de votre solution dépend des préférences de votre entreprise.

Modèle d’architecture 1 : Okta en tant que fournisseur d’identité InCommon

Dans ce scénario, une université utilise Okta pour ses étudiants, son corps enseignant et son personnel. L’université alimente Okta à partir de ses systèmes d’information sur les étudiants et/ou de ressources humaines, et propose le provisioning, l’authentification unique (SSO) et la MFA pour différentes applications, notamment Google Workspace, Microsoft Entra ID, Canvas et Blackboard. Okta attribue également des comptes aux utilisateurs dans Active Directory. L’objectif est de permettre aux utilisateurs de l’université d’accéder à des services externes fédérés via InCommon, tels que des revues de recherche, des services de bibliothèque tiers et des applications NSF. 

Configuration de l’architecture

1. L’université enregistre Cirrus Bridge comme IdP officiel dans le registre de confiance InCommon.
2. Cirrus Bridge est configuré pour pointer en amont vers le tenant Okta de l’université en tant qu’IdP SAML faisant autorité.
3. Okta gère l’authentification principale des utilisateurs, l’application de la MFA ainsi que la gestion de base du cycle de vie des identités.

Fonctionnement des flux d’authentification pour Okta en tant qu’IdP

Pour un flux initié par l’IDP, commencez par la connexion facultative 

1. L’utilisateur non authentifié se connecte directement au tableau de bord Okta destiné aux utilisateurs finaux.
2. L’utilisateur ou l’utilisatrice clique sur un lien vers l’application InCommon externe cible.
3. Okta génère une assertion SAML et l’envoie à Cirrus Bridge.
4. Cirrus Bridge traduit l’assertion dans un format multilatéral et la transmet à la ressource cible.

Pour un flux initié par le SP, n’utilisez pas la connexion facultative et effectuez la connexion lorsque cela est nécessaire.

1. L’utilisateur accède directement à la ressource InCommon tierce cible.
2. La ressource redirige l’utilisateur vers Cirrus Bridge en utilisant la recherche de métadonnées InCommon.
3. Cirrus Bridge redirige l’utilisateur vers Okta pour la vérification des identifiants principaux.
4. Après une authentification réussie, Okta émet un token à Cirrus Bridge, qui redirige ensuite l’utilisateur vers la ressource.

Modèle d’architecture 2 : Okta en tant que fournisseur de services InCommon

Dans ce scénario, un institut de recherche utilise Okta pour sécuriser l’accès à ses applications. Au lieu d’émettre des identifiants distincts pour chaque utilisateur ou utilisatrice, l’établissement souhaite accepter des utilisateurs et utilisatrices provenant de la Fédération InCommon. Cela permet à ces utilisateurs et utilisatrices d’accéder aux applications de l’institution de recherche en utilisant leurs propres identifiants universitaires, sans avoir à créer un nouveau compte. L’institution de recherche souhaite également permettre une connexion directe à son personnel de recherche. 

Configuration de l’architecture

1. Cirrus Proxy est enregistré en tant que SP InCommon dans le registre multilatéral.
2. Okta est configuré pour faire confiance à Cirrus Proxy en tant qu’IdP entrant grâce à une configuration SAML bilatérale.
3. Les applications cibles restent intégrées directement à Okta en tant qu’authentification unique (SSO) standard sur les applications.

Flux de découverte de l’identité et d’authentification

Un élément clé lors de l’activation de l’accès InCommon dans Okta consiste à veiller à ce que les utilisateurs se connectent via les chemins appropriés.

Flux de connexion direct pour les membres du personnel interne

1. Le personnel de recherche interne accède directement à l’application via son compte Okta.
2. Okta authentifie directement les utilisateurs internes sans faire appel au pipeline de découverte externe.

Flux de connexion initié par le SP pour les utilisateurs externes InCommon

Un utilisateur ou une utilisatrice externe accède directement à l’application ou passe par le tableau de bord de son université d’origine. À ce stade, il est possible d’inviter l’utilisateur ou l’utilisatrice à saisir ses identifiants en utilisant l’une des deux méthodes ci-dessous. L’approche sera définie en fonction des besoins de l’institution.  

1. Utilisateur > Accéder à la ressource > Okta présente le widget de connexion avec un lien vers l’écran de découverte sur Cirrus Proxy 

   • L’utilisateur peut se connecter directement via le widget Okta ou choisir « Connexion avec InCommon », ce qui l’amène à l’écran de découverte de l’IDP sur Cirrus Proxy.

2. Utilisateur ou utilisatrice > Accéder à la ressource > Cirrus Proxy présente une page de connexion avec un lien vers le widget Okta

   • L’utilisateur voit immédiatement l’écran de découverte de l’IdP Cirrus Proxy

   • Le personnel peut se connecter directement via le widget Okta

Dans cet exemple, l’utilisateur ou l’utilisatrice choisit d’utiliser InCommon pour l’authentification.

1. L’utilisateur est redirigé vers l’interface de découverte Cirrus Proxy pour sélectionner son établissement d’origine.
2. Cirrus Proxy interroge le service MDQ, extrait les métadonnées SAML de l’établissement d’origine, puis redirige l’utilisateur vers la page de connexion de son université locale.
3. Après une connexion réussie à l’université d’origine, l’IdP d’origine envoie une assertion SAML à Cirrus Proxy.
4. Cirrus Proxy valide l’assertion et envoie une assertion formatée à Okta, accordant à l’utilisateur l’accès à l’application.

Simplifiez votre fédération multilatérale avec Okta

L’intégration d’Okta avec des fédérations multilatérales n’a pas à être complexe. Notre intégration Cirrus Federation Bridge permet l’authentification et le provisioning pour les utilisateurs finaux des établissements d’enseignement supérieur et de recherche. 

Contrairement à d’autres toolkits de gestion des identités, Okta ne vous oblige pas à consacrer du temps et des ressources à connecter manuellement des applications web à vos annuaires d’utilisateurs. Au lieu de cela, nous intégrons directement les applications à notre service, afin que vous puissiez simplement les déployer auprès de vos utilisateurs.

Télécharger le livre blanc sur les intégrations d’applications pour en savoir plus sur la façon dont nous simplifions les connexions d’applications dans l’ensemble de votre écosystème.