Solution 2 : Microsoft Entra ID avec Shibboleth comme proxy SAML

Dans la solution 2, Microsoft Entra ID agit en tant que fournisseur d'identité principal (IdP). Le fournisseur de fédération agit en tant que proxy SAML (Security Assertion Markup Language) pour les applications CAS (Central Authentication Service) et les applications de fédération multilatérale. Dans cet exemple,Shibboleth agit en tant que proxy SAML pour fournir un lien de référence.

Étant donné que Microsoft Entra ID est le principal IdP, toutes les applications des étudiants et des professeurs sont intégrées à Microsoft Entra ID. Toutes les applications Microsoft 365 sont également intégrées à l’ID Microsoft Entra. Si Microsoft Entra Domain Services est utilisé, il est également synchronisé avec Microsoft Entra ID.

La fonctionnalité proxy SAML de Shibboleth s'intègre à Microsoft Entra ID. Dans Microsoft Entra ID, Shibboleth apparaît comme une application d'entreprise hors galerie. Les universités peuvent obtenir l’authentification unique (SSO) de leurs applications CAS et participer à l’environnement InCommon. En outre, Shibboleth fournit une intégration des services d’annuaire LDAP (Lightweight Directory Access Protocol).

Avantages

Les avantages de cette solution inclus :

• Authentification cloud pour toutes les applications : Toutes les applications s’authentifient via l’ID Microsoft Entra.

• Facilité d’exécution : Cette solution offre une facilité d’exécution à court terme pour les universités qui utilisent déjà Shibboleth.

Considérations et compromis

Voici certaines des contreparties de l’utilisation de cette solution :

• Complexité et risque de sécurité plus élevés : Une empreinte locale peut signifier une complexité plus élevée pour l’environnement et des risques de sécurité supplémentaires, par rapport à un service géré. Les frais généraux et frais associés à la gestion de ces composants locaux peuvent également augmenter.

• Expérience d’authentification non optimale : Pour les applications de fédération multilatérale et les applications CAS, l’expérience d’authentification pour les utilisateurs peut ne pas être transparente en raison des redirections via Shibboleth. Les options de personnalisation de l’expérience d’authentification pour les utilisateurs sont limitées.

• Intégration limitée de l’authentification multifacteur tierce : Le nombre d’intégrations disponibles pour les solutions d’authentification multifacteur tierces peut être limitée.

• Aucune prise en charge granulaire de l’accès conditionnel : Sans prise en charge granulaire de l’accès conditionnel, vous devez choisir entre le dénominateur le moins courant (optimiser pour moins de frictions, mais avoir des contrôles de sécurité limités) ou le dénominateur commun le plus élevé (optimiser pour les contrôles de sécurité au détriment de la friction utilisateur). Votre capacité à prendre des décisions granulaires est limitée.

Ressources de migration

Les ressources suivantes peuvent faciliter votre migration vers cette architecture de la solution.

Ressource de migration	Descriptif
Ressources pour la migration des applications vers Microsoft Entra ID	Liste de ressources pour vous aider à migrer l’accès et l’authentification des applications vers Microsoft Entra ID
Configuration de Shibboleth en tant que proxy SAML	Article Shibboleth qui décrit comment utiliser la fonctionnalité de proxy SAML pour connecter l'IdP Shibboleth à Microsoft Entra ID
Considérations sur le déploiement de l’authentification multifacteur Microsoft Entra	Aide pour configurer l’authentification multifacteur Microsoft Entra

Étapes suivantes

Consultez ces articles connexes sur la fédération multilatérale :

Présentation de la fédération multilatérale

Conception de la ligne de base de la fédération multilatérale

Solution de fédération multilatérale 1 : Microsoft Entra ID avec Cirrus Bridge

Solution de fédération multilatérale 3 : Microsoft Entra ID avec AD FS et Shibboleth

Arbre de décision de fédération multilatérale