Introduction
Beaucoup de spécialistes en cybersécurité conviennent que l’authentification multifactorielle (MFA) est sans doute le moyen le plus efficace d’éviter le piratage des mots de passe. La MFA accroît la sécurité en réclamant à l’utilisateur qu’il s’identifie de deux ou plusieurs manières, indépendantes et distinctes (quelque chose qu’il a, qu’il sait ou qu’il est). L’industrie technologique avance rapidement vers l’authentification bifactorielle (2FA) ou multifactorielle pour autoriser l’accès à une application ou à un service Web.
CANARIE a récemment mené à bien un projet de validation auprès d’un petit nombre de participants de la Fédération canadienne d’accès (FCA) qui souhaitaient ajouter la MFA de la Research and Education FEDerations (REFEDS) à leur fournisseur d’identités (IdP) utilisant la gestion fédérée des identités (GFI).
Des questions? Veuillez visiter notre page de soutien.
Qu’est-ce que la REFEDS?
La Research and Education FEDerations (REFEDS) est un groupe qui fait valoir les exigences du secteur de la recherche et de l’éducation dans l’espace grandissant de la gestion des accès et des identités. Ce groupe œuvre avec d’autres organisations afin d’orienter les activités pertinentes dans le sens que souhaitent ses membres.
Le groupe Research and Education FEDerations (REFEDS)
Configurations couvertes
Ce guide explique quelles mesures prendre pour configurer les diverses plateformes des fournisseurs d’identités du milieu de la recherche et de l’éducation (R-E) avec les techniques MFA populaires de DUO Security ou de Microsoft Azure, en l’occurrence :
- Shibboleth avec la MFA de DUO;
- Shibboleth Proxy avec la MFA d’Azure;
- ADFSToolkit avec la MFA de DUO;
- ADFSToolkit avec la MFA d’Azure.
Qui devrait lire ce guide?
La configuration est extrêmement technique et ne s’adresse qu’à ceux qui maîtrisent bien la gestion des identités et des accès et qui :
- doivent appliquer et maintenir la GFI dans leur institution;
- aimeraient appliquer la MFA sur leur site.
La MFA et le REFEDS
L’approche de la REFEDS-MFA rehausse et simplifie l’identification unique par langage de balisage des assertions de sécurité (SAML SSO) en recourant à un signal commun pour amorcer la MFA. Les diverses possibilités qu’offre la MFA sont donc réunies par l’attribution d’une seule valeur à la variable AuthenticationContextClass qui figure dans la demande d’authentification du fournisseur de service. Quand ce dernier ajoute le profil REFEDS-MFA à sa demande, l’IdP est tenu d’utiliser une méthode d’identification respectant une MFA d’au moins deux facteurs indépendants et distincts, sinon plus.
Soulignons que le fournisseur de service peut rendre la MFA obligatoire en l’incluant dans sa demande d’authentification. Dans un tel cas, les IdP devront tous fournir la preuve qu’il y a eu MFA dans leur réponse, avant que les utilisateurs puissent accéder au service. En revanche, le fournisseur d’identités qui souhaite appliquer la MFA pourra le faire, que le fournisseur de service exige cette dernière ou pas.
Nous vous suggérons vivement de lire le document REFEDS MFA FAQ pour en apprendre davantage.
Le tableau qui suit donne un aperçu des différents contextes d’authentification SAML. Il vous aidera à choisir la bonne méthode d’authentification et son contexte. Certains sites sur le campus pourraient déjà avoir implanté la MFA en partie, sans qu’elle soit aussi stricte que la REFEDS-MFA. Nous encourageons ceux qui aimeraient recourir à la MFA de façon sélective à utiliser un attribut AuthenticationContextClass qu’ils pourront contrôler localement, comme l’illustre la documentation à l’URL indiqué.
L’application de la MFA sélective déborde du cadre du guide que vous avez entre les mains.
| Nature de l’authentification | Contexte et précisions |
| L’utilisateur qui n’ouvre pas de séance active s’authentifie au moyen d’un seul facteur (habituellement son identifiant et son mot de passe). | Contexte : urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport Contexte par défaut employé par le fournisseur de service s’il ne spécifie pas explicitement une autre méthode d’authentification |
| L’utilisateur s’authentifie avec le premier facteur auquel s’en ajoute un ou plusieurs autres (quelque chose qu’il sait, qu’il a ou qu’il est), peu importe la nature du deuxième facteur d’authentification antérieur. | Contexte : https://refeds.org/profile/mfa Contexte par défaut de la REFEDS MFA. Il doit être explicitement configuré par le fournisseur de service, ou l’IdP doit le réclamer. |
| FACULTATIF : L’utilisateur s’authentifie avec le premier facteur et un ou plusieurs facteurs supplémentaires (quelque chose qu’il sait, qu’il a ou qu’il est). L’IdP détermine la rigueur des facteurs réclamés. | Contexte : https://<domain>.ca/profile/mfa/local-enterprise-mfa Contexte optionnel qui englobe les exigences particulières d’un site en matière de MFA. Le fournisseur de service doit le configurer explicitement ou l’IdP doit le réclamer. |
Contraintes applicables au système et aux composants de l’IdP
Avant de procéder à une des configurations MFA expliquées plus loin (voir version requise des composants ci-dessous), le fournisseur d’identités qui aimerait implanter la REFEDS MFA doit disposer d’un service IdP totalement fonctionnel avec la configuration de base.
| Configuration de l’IdP et de la MFA | Composant | Version minimale requise |
| Shibboleth et MFA de DUO | IdP Shibboleth | V4.1.4 pour Linux ou Windows |
| Version OIDC Common | 1.1.0 | |
| Version OIDC OP | 3.0.0 | |
| Version DUO_OIDC | 1.1.1 | |
| Shibboleth et MFA d’AzureAD | IdP Shibboleth Proxy | V4.1.4pour Linux ou Windows |
| ADFS / ADFSToolkit et MFA de DUO | ADFS et configuration de batterie de serveurs MS-SQL | Server 2019 |
| ADFSToolkit | V2.1.0 RC1<à venir> | |
| Module d’extension d’ADFSToolkit pour REFEDS MFA | V2.1.0 RC1<à venir> | |
| Module d’extension DUOSecurity ADFS | 1.2.0.17 | |
| DUOSecurity Service | Universal Prompt (PAS iFrame) | |
| ADFS / ADFSToolkit et MFA d’AzureAD | ADFS et dorsale de batteries de serveurs MS-SQL | Server 2019 |
Compétences requises
Installation avec l’IdP Shibboleth
La configuration suppose que vous connaissez l’IdP Shibboleth, que vous savez comment installer le logiciel et que vous connaissez son agencement.
Notez que la version Shibboleth v4.1 et les versions ultérieures utilisent la nouvelle méthode de configuration avec module d’extension décrite dans ce guide.
Installation avec l’IdP ADFSToolkit
La configuration suppose que vous savez comment installer et configurer le logiciel ADFS, utiliser PowerShell et ses modules d’extension, et que vous maîtrisez les commandes de l’Active Directory PowerShell.
Pour mettre en place
Shibboleth et DUO-OIDC
Si vous avez déjà un site utilisant DUO, l’idéal consiste à appliquer REFEDS-MFA pour Shibboleth avec la MFA de DUO et l’IdP Shibboleth.
ATTENTION – Les étapes qui suivent commencent toutes avec un IdP Shibboleth autorisant l’ouverture d’une séance avec l’identifiant et le mot de passe de l’utilisateur, et en mesure de résoudre les attributs de ce dernier.
1re étape. Vérifiez la configuration et assurez-vous qu’elle accepte DUO OIDC.
Cette installation recourt aux plus récentes fonctionnalités de DUO, dont DUO-OpenID Connect (OIDC). Si le site utilise l’approche antérieure (DUO iFrame), vous devriez d’abord lire le billet Breaking up with the iFrame sur le blogue et désinstaller iFrame avant de commencer.
2e étape. Préparez les modules et les dépendances de l’IdP.
Le Wiki de Shibboleth précise les techniques et les paramètres requis dans un guide détaillé intitulé Quick Step Guide. Voici les tâches spécifiques qui activeront DUO OIDC avec la REFEDS MFA.
Tâche : Télécharger les outils d’aide à la configuration de l’IdP
Clonez la bibliothèque des widgets IdP de CANARIE sur GitHub ou téléchargez-la et décomprimez-la localement.
Tâche : Installer les modules d’extension et les bibliothèques
Exécutez idp-widgets/bin/prep-idp4mfa.sh
Cette commande installe les bibliothèques communes de DUO et d’OIDC sur l’IdP.
3e étape. Autoriser et activer la configuration DUO
Tâche : Activez la configuration DUO sur le site DUO
Suivez les instructions du guide d’application DUO pour préparer la configuration DUO.
Tâche : Déterminez les propriétés de DUO pour l’IdP dans conf/aiuthn/duo-oidc.properties
Modifiez ce qui suit dans conf/authn/duo-oidc.properties en fonction des paramètres DUO :
idp.duo.oidc.apiHost = hostname
idp.duo.oidc.clientId = clientid
idp.duo.oidc.redirectURL = https://<IDP-hostname>/idp/profile/Authn/Duo/2FA/duo-callback
idp.duo.oidc.secretKey = key
4e étape. Configurer les paramètres de la MFA dans l’IdP
Tâche : Modifier idp.properties afin qu’il n’y ait plus qu’un seul flux MFA
Assurez-vous que le flux MFA est activé dans idp.properties :
idp.authn.flows=MFA
Dans le Wiki de Shibboleth, à MFA, on peut lire ce qui suit (traduction).
Notez que lorsqu’on utilise le flux MFA, il est normal qu’il soit le seul à être activé par idp.authn.flows. Les flux MFA commandés par des règles ou un script ne devraient pas être activés, car ils pourraient être exécutés par l’IdP d’une manière qui irait à l’encontre de ce que vous souhaitez.
Tâche : Actualiser le flux MFA dans mfa-authn-config.xml
Voici, aux fins d’illustration, un flux défini dans le fichier conf/authn/mfa-authn-config.xml. Si vous ne voyez pas ce fichier, c’est que le module « idp.authn.MFA » n’a pas encore été activé (lire la documentation).
<util:map id="shibboleth.authn.MFA.TransitionMap">
<!-- First rule runs the Password login flow. -->
<entry key="">
<bean parent="shibboleth.authn.MFA.Transition" p:nextFlow="authn/Password" />
</entry>
<!-- Second rule runs a function if Password succeeds, to determine whether an additional factor is required. -->
<entry key="authn/Password">
<bean parent="shibboleth.authn.MFA.Transition" p:nextFlowStrategy-ref="checkSecondFactor" />
</entry>
<!-- An implicit final rule will return whatever the final flow returns. -->
</util:map>
<!-- Example script to see if second factor is required. Currently just returns the DuoOIDC flow -->
<bean id="checkSecondFactor" parent="shibboleth.ContextFunctions.Scripted" factory-method="inlineScript">
<constructor-arg>
<value>
<![CDATA[
nextFlow = "authn/DuoOIDC";
// Check if second factor is necessary for request to be satisfied.
//authCtx = input.getSubcontext("net.shibboleth.idp.authn.context.AuthenticationContext");
// mfaCtx = authCtx.getSubcontext("net.shibboleth.idp.authn.context.MultiFactorAuthenticationContext");
//if (mfaCtx.isAcceptable()) {
// nextFlow = null;
//}
nextFlow; // pass control to second factor or end with the first
]]>
</value>
</constructor-arg>
</bean>
Tâche : Actualiser conf/authn/authn.properties pour appliquer la REFEDS MFA
Mettez le fichier authn.properties à jour afin qu’il inclue les valeurs principales de la REFEDS MFA que permet la MFA (surlignées en vert). Ces chaînes sont identiques à celles de l’AuthenticationContext que devrait traiter l’IdP.
…
idp.authn.Duo.supportedPrincipals = \
saml2/https://refeds.org/profile/mfa, \
saml2/http://example.org/ac/classes/mfa, \
saml1/http://example.org/ac/classes/mfa
...
idp.authn.MFA.supportedPrincipals = \
saml2/https://refeds.org/profile/mfa, \
saml2/http://example.org/ac/classes/mfa, \
saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport, \
saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:Password, \
saml1/http://example.org/ac/classes/mfa, \
saml1/urn:oasis:names:tc:SAML:1.0:am:password
Tâche : Relancer l’IdP et le tester
Pour tester l’IdP, vous devrez recourir au fournisseur d’un service d’essai. Celui-ci amorcera sa demande avec l’AuthenticationContext de la REFEDS-MFA. Après avoir relancé votre IdP, visitez le site d’essai de la FCA à https://validator.caftest.canarie.ca et sélectionnez l’ouverture de séance avec la MFA pour vérifier votre configuration et la valider.
Notez que pour qu’il y ait validation, vos métadonnées doivent déjà être en circulation. Pour implanter votre propre fournisseur de service d’essai, veuillez lire la partie « Installation de la MFA avec le fournisseur de service Shibboleth », plus bas.
Après ouverture de la séance, vérifiez le statut du fournisseur de service ici : http://validator.cafteste.canarie.ca/Shibboleth.sso/Session
La séance devrait s’ouvrir avec la REFEDS MFA.
Shibboleth et la MFA d’Azure
L’application de la REFEDS-MFA pour Shibboleth avec la MFA d’Azure exige que l’IdP Shibboleth soit configuré comme une procuration SAML. En d’autres termes, l’IdP enverra la demande à Azure AD avec un AuthenticationContext spécifique qui déclenchera la MFA. La demande est ensuite reconvertie sous sa forme originale au retour.
Remarquez que s’il ne recourt pas déjà à la MFA, l’utilisateur d’Azure AD ne pourra ouvrir de séance tant qu’il n’aura pas sélectionné ni activé les fonctionnalités MFA sur son compte.
Plus de précisions à ce sujet dans le Wiki de Shibboleth.
La sixième tâche par procuration, qui convertit la demande, présente un intérêt particulier.
6e tâche par procuration – Traitement des demandes REFEDS AuthnContext
Pour l’instant, Azure n’explique pas comment modifier le comportement de l’attribut AuthnContext dans ses assertions SAML. Cependant, Shibboleth autorise la conversion des demandes par procuration et de leur réponse avec authn/authn-comparison.xml. L’exemple que voici montre comment sont traitées les demandes REFEDS MFA.
<util:map id="shibboleth.PrincipalProxyRequestMappings">
<entry>
<key>
<bean parent="shibboleth.SAML2AuthnContextClassRef"
c:classRef="https://refeds.org/profile/mfa" />
</key>
<list>
<bean parent="shibboleth.SAML2AuthnContextClassRef"
c:classRef="http://schemas.microsoft.com/claims/multipleauthn" />
</list>
</entry>
</util:map>
<util:map id="shibboleth.PrincipalProxyResponseMappings">
<entry>
<key>
<bean parent="shibboleth.SAML2AuthnContextClassRef"
c:classRef="http://schemas.microsoft.com/claims/multipleauthn" />
</key>
<list>
<bean parent="shibboleth.SAML2AuthnContextClassRef"
c:classRef="https://refeds.org/profile/mfa" />
</list>
</entry>
</util:map>
Pour tester votre configuration, visitez le site d’essai de la FCA et sélectionnez l’ouverture de séance MFA afin d’activer la configuration et de la valider.
ADFS/ADFSToolkit
Marche à suivre pour qu’ADFS accepte la REFEDS-MFA
- Utilisez la version la plus récente d’ADFSToolkit.
- Installez la plus récente version de votre technologie MFA et assurez-vous qu’elle fonctionne de façon indépendante, ainsi qu’elle devrait le faire.
- Activez le thème « pagination » d’ADFS.
- Lisez le guide d’installation et de configuration de la REFEDS MFA pour ADFSToolkit (en anglais).
- Prévoyez comment le service MFA et ses fonctionnalités seront déployés entre les utilisateurs.
Installer la REFEDS-MFA n’est qu’une facette de l’application de la MFA à vos utilisateurs. Ce guide se concentre sur l’infrastructure technique qu’exige l’installation de la MFA. Il n’aborde pas la logistique nécessaire pour apprendre à l’utilisateur comment s’inscrire à la MFA, comment s’en servir et comment rétablir l’usage de jetons MFA pour accéder à nouveau à son compte.
Suivez les instructions pour installer et configurer la MFA d’ADFSToolkit ici afin que votre instance ADFS ait le nouveau module d’extension DLL nécessaire à la REFEDS-MFA. Vous disposerez aussi de quelques cmdlets PowerShell pour vous aider dans l’installation et la configuration.
Une fois que vous aurez installé les modules de soutien de la REFEDS-MFA, le recalcul des parties utilisatrices d’ADFS que supervise ADFSToolkit garantira le bon fonctionnement de la méthode MFA que vous aurez choisie (à savoir, DUO-OICD ou Azure MFA).
Pour que les modules d’extension d’ADFSToolkit fonctionnent correctement par DLL, vous devrez installer une connexion paginée, c’est-à-dire la version de base de Microsoft ou une version spécifiquement adaptée à vos besoins.
ADFS/ADFS Toolkit et DUO-OIDC
Pour installer la REFEDS-MFA pour ADFS/ADFSToolkit et permettre l’intégration de DUO-OIDC, lisez la documentation sur la configuration à partir de DUO et procédez de la manière indiquée.
Signalons que si certains sites utilisent l’ancienne approche iFrame de DUO, vous devrez lire le billet Breaking up with the iFrame du blogue et d’abord désinstaller iFrame.
L’installation de DUO terminée, nous vous recommandons de procéder à un test indépendant avec une de vos parties utilisatrices pour vérifier que tout fonctionne, ou d’utiliser Claims X-Ray, la partie utilisatrice d’essai de Microsoft. Choisissez le processus de vérification SAML-P qui vous permettra de vérifier rapidement comment se déroule l’ouverture de la séance.
ADFS/ADFS Toolkit et la MFA d’Azure
Pour implanter la MFA d’Azure avec ADFS, vous devrez :
- synchroniser votre Active Directory et votre locataire Azure AD;
- configurer les paramètres MFA appropriés du locataire.
Nous vous recommandons de prendre connaissance des détails sur la MFA d’Azure AD et de lire la FAQ sur la REFEDS MFA afin de vous assurer que les modes d’accès souhaités sont bien supportés.
On ne considère plus le service SMS (texto) comme un facteur de sécurité supplémentaire assez sûr, car les messages peuvent être facilement modifiés ou interceptés. Cette solution ne convient donc pas à la MFA. Bien qu’on la propose toujours en option, on en décourage vivement l’usage comme facteur d’authentification.
Microsoft explique en détail comment s’inscrire au service MFA d’Azure AD avec ADFS. Nous vous encourageons à ne le faire qu’après l’avoir testé le service avec un utilisateur sur un système d’essai, afin de vous assurer qu’il est possible de le configurer sans perturbation des utilisateurs sur la plateforme de production.
Installation de la MFA avec le fournisseur de service Shibboleth
Les fournisseurs de service qui utilisent Shibboleth SP liront les documents de référence mentionnés ci-dessous pour savoir comment configurer correctement la REFEDS MFA (Authentication Context) et permettre à l’application d’accéder à la MFA.
https://wiki.shibboleth.net/confluence/display/SP3/Requiring+Multi-Factor+Authentication
Des questions? Veuillez visiter notre page de soutien.