ESUP-OTP

Arborescence des pages

Vous regardez une version antérieure (v. /wiki/spaces/esupotp/pages/1549008900/FAQ) de cette page.

afficher les différences afficher l'historique de la page

« Afficher la version précédente Vous regardez la version actuelle de cette page. (v. 20) afficher la version suivante »

Peut-on permettre à un informaticien de proximité de dépanner ponctuellement un utilisateur dans l'incapacité temporaire d'utiliser son second facteur (téléphone volé, OTP indisponible…) ?

Oui. Lorsqu'un utilisateur est bloqué, un informaticien habilité disposant des droits de gestionnaire dans esup-otp-manager peut effectuer un dépannage ponctuel, notamment :

  • en se rendant dans le menu "Manager" de l'interface d'administration ;
  • en sélectionnant l'utilisateur concerné ;
  • en générant une nouvelle série de codes de secours pour cet utilisateur (ce qui invalide automatiquement les anciens codes) ;
  • en communiquant un de ces nouveaux codes directement à l'utilisateur, par téléphone ou de vive voix, après vérification de son identité selon les usages internes.

Comment permettre aux utilisateurs de réinitialiser leur deuxième facteur de manière autonome en cas d’impossibilité de l’utiliser (vol ou perte de l’appareil servant à récupérer le code OTP, par exemple) ?

La gestion de ce type de situation est actuellement laissée à l’appréciation de chaque établissement, car les procédures de réinitialisation dépendent fortement de leur organisation interne et de leur PSSI.

Les approches possibles consistent à

A - Activer les codes de secours 

  • Activer la méthode bypass et inviter les utilisateurs à générer un ou plusieurs (paramétrable) codes de secours qui leur permettront de réinitialiser leurs facteurs d'authentification

→ l'inconvénient principal, c'est que l'utilisateur peut ne pas avoir généré son code de secours ou ne l'aura pas avec lui le jour où il en aura besoin

B - Activer la méthode mail

  • les utilisateurs pourront recevoir un code OTP par mail

→ avantage : pratique pour l'utilisateur final

→ inconvénient : dépendant d'un mail perso. Si l'utilisateur se fait usurper son mail perso, cette procédure est compromise ; on note également que selon les recommandations de la CNIL, l'envoi d'OTP par mail ne peut être assimilé à un 2e facteur.

C - FranceConnect (délégation à tiers de confiance)

  • autoriser les utilisateurs à accéder au manager via son compte FranceConnect
  • on peut rehausser le niveau en n'acceptant que les authentifications FranceConnect avec mfa ou avec un niveau minimum eidas2 

→ Limite : tous les utilisateurs ne peuvent pas avoir de compte FranceConnect (étranger avec un séjour de moins de 5 ans...)

D - Authentification NFC (carte multi-service étudiant / professionnelle)

  • activer l'authentification NFC pour tout utilisateur ayant activé la MFA
  • l'utilisateur peut s'authentifier en badgeant avec sa carte multiservice sur l'application mobile Esup Auth

→ l'utilisateur doit être muni d'un dispositif avec lecteur NFC

Comment générer un code OTP pour un utilisateur via l'API ?

1. Appeler PUT /protected/users/:uid/methods/bypass/activate pour activer la méthode,

2. Puis POST /protected/users/:uid/methods/bypass/secret?codes_number=1 pour générer un code à usage unique.

PS : pour les méthodes /protected , bien mettre l'api_password dans le header headers.Authorization = 'Bearer ' + api_password; 

Comment proposer dans esup-otp-cas le MFA uniquement à ceux qui ont au moins une méthode de MFA d'activée ?

Différentes configurations permettent de déclencher ou non le MFA dans Apereo CAS.

Il est par exemple possible de conditionner le déclenchement du MFA dans Apereo CAS en utilisant un script Groovy, configuré dans le fichier cas.properties :

cas.authn.mfa.groovy-script.location=file:/etc/cas/config/mfaGroovyTrigger.groovy

Un tel script doit retourner l'ID du mfa à déclencher par CAS, ou null si le MFA ne doit pas être déclenché.

Dans esup-otp–cas, l'ID définit pour esup-otp est "mfa-esupotp".

Le script peut permettre de décider dynamiquement, pour chaque utilisateur, chaque service consommé, si le MFA doit être activé.

Il peut s’appuyer ainsi sur :

  • les attributs récupérés (LDAP) ;

  • le nom/identifiant du service accédé ;

  • des appels à des API distantes ;

  • ou encore, les services/librairies internes à CAS, y compris ceux issus du module esup-otp-cas.

Voici un exemple concret de script Groovy qui interroge le service esupOtpService pour vérifier si l’utilisateur dispose d’au moins une méthode d’authentification forte activée dans esup-otp et qui déclenche la MFA uniquement si c'est le cas :

import java.util.*

class SampleGroovyEventResolver {
    def String run(service, registeredService, authentication, httpRequest, logger, ... args) {
        def ctx = org.apereo.cas.util.spring.ApplicationContextProvider.getApplicationContext()
        def esupOtpService = ctx.getBean("esupOtpService")
        def esupOtpUserInfos = esupOtpService.getUserInfos(authentication.principal.id)
        def esupOtpMethods = esupOtpUserInfos.get("user").get("methods").toMap().values()
        def oneMfaMethodIsActive = esupOtpMethods.stream().anyMatch { method ->
            method instanceof Map && method.get("active")
        }
        return oneMfaMethodIsActive ? "mfa-esupotp" : null
    }
}

Comment inciter l'activation du MFA via esup-otp-cas lors de l'authentification CAS ?

Il est possible d’afficher un message d’interruption pendant l’authentification Apereo CAS, afin de sensibiliser ou inciter l’utilisateur à activer l’authentification multifacteur (MFA) via esup-otp-cas.

Ce mécanisme d’interrupt peut notamment être piloté à l’aide d’un script Groovy. Il suffit de spécifier le chemin du script dans le fichier cas.properties :

cas.interrupt.groovy.location=file:/etc/cas/config/interrupt.groovy

Ce script est exécuté après l’authentification, mais avant la redirection finale vers le service cible.

Il peut afficher un message personnalisé, accompagné de liens, et peut également bloquer ou non la suite du processus (en empêchant éventuellement l’établissement d’une session SSO).

Le script peut s’appuyer sur :

  • les attributs récupérés (LDAP) ;

  • le nom/identifiant du service accédé ;

  • des appels à des API distantes ;

  • ou encore, les services/librairies internes à Apereo CAS, y compris ceux issus du module esup-otp-cas.

Voici un exemple de script Groovy qui utilise esupOtpService pour détecter si l’utilisateur n’a activé aucune méthode de MFA, et lui propose alors un message d’incitation avec un lien vers l’interface d’activation :


import java.util.*
import org.apereo.cas.interrupt.InterruptResponse

def run(principal, attributes, service, registeredService, requestContext, logger, ... args) {
    def ctx = org.apereo.cas.util.spring.ApplicationContextProvider.getApplicationContext()
    def esupOtpService = ctx.getBean("esupOtpService")
    def esupOtpUserInfos = esupOtpService.getUserInfos(principal.id)
    def esupOtpMethods = esupOtpUserInfos.get("user").get("methods").toMap().values()
    def oneMfaMethodIsActive = esupOtpMethods.stream().anyMatch { method ->
        method instanceof Map && method.get("active")
    }
    if (!oneMfaMethodIsActive && !service.id.startsWith("https://esup-otp-manager.example.org/") {
        def message = "Vous n'avez pas encore activé votre authentification renforcée avec ESUP-OTP, il serait souhaitable de le faire."
        def links = ["Application ESUP-OTP" : "https://esup-otp-manager.example.org/preferences"]
        def block = false
        def ssoEnabled = false
        return new InterruptResponse(message, links, block, ssoEnabled)
    }
    return null
}

Ce que fait ce script :

  • Il interroge le service esupOtpService pour connaître les méthodes MFA activées de l’utilisateur.

  • Si aucune méthode n’est active et que le service désiré n'est pas esup-otp-manager  :

    • il affiche un message incitant à activer le MFA ; ce message est affiché dès la première authentification (TGT), mais aussi à chaque authentification sur chaque service (ST), ce grâce au ssoEnabled valué à false.

    • il fournit un lien vers esup-otp-manager ;

    • tout en lui permettant tout de même d'accéder au service demandé, ce grâce au block valué à false.

  • Si au moins une méthode est active, aucun message n’est affiché.

💡 Cette approche est non bloquante mais pédagogique, et permet de faire évoluer progressivement la population vers l’activation du MFA.

Peut-on demander à nos utilisateurs (étudiants ou personnels) d’utiliser leur téléphone personnel comme second facteur d’authentification pour accéder à des services sécurisés de l’établissement ?

Oui, l’utilisation d’un téléphone personnel comme facteur de possession dans une authentification multifacteur (MFA) est possible, y compris dans un contexte professionnel ou universitaire, à condition de respecter certaines précautions définies par la CNIL.

La CNIL ne proscrit pas cet usage. Elle reconnaît qu’un terminal personnel comme un smartphone peut tout à fait servir de facteur de possession (ce que l’utilisateur a), en complément d’un mot de passe (ce que l’utilisateur sait).

Cependant, elle recommande :

  • de privilégier des méthodes minimisant la collecte de données personnelles : par exemple, une application PUSH ou d'OTP (comme esup-otp) ne nécessitant pas le numéro de téléphone est préférable à l’envoi de code OTP par SMS.

  • d’évaluer les impacts pour les utilisateurs : certains étudiants peuvent ne pas posséder de smartphone ou ne pas vouloir l’utiliser à des fins universitaires. Il est alors conseillé de prévoir une solution alternative, sans que celle-ci ne soit plus contraignante ou discriminante.

Quelles alternatives au téléphone personnel peut-on proposer comme second facteur pour l’authentification multifacteur (MFA) ?

Générateurs d’OTP
La génération d’un code OTP basé sur une clé secrète (fournie via le QR-code généré par esup-otp-manager) peut être effectuée à l’aide :

  • d’une application mobile comme Esup Authenticator (ou Google Authenticator) ;

  • ou de nombreuses autres solutions logicielles compatibles (extensions de navigateur, outils en ligne de commande, etc.) ;

  • ou encore des solutions (jetons) matérielles avec afficheur LCD.

Carte multi-services NFC
Utilisée comme facteur de possession via le projet esup-nfc-tag, cette carte nécessite un lecteur NFC accessible à l’utilisateur. Cette solution peut être adaptée dans les environnements déjà équipés.

Authentification WebAuthn
Basée sur des normes ouvertes (FIDO2/WebAuthn), elle permet d’utiliser :

  • un appareil compatible comme une clé USB de type Yubikey,

  • ou des solutions logicielles comme Windows Hello, Touch ID ou Face ID.
    C’est une alternative intégrée dans certains navigateurs récents.

Grille de codes à usage unique
Cette solution papier peut être proposée en dernier recours. Bien que fonctionnelle, elle est moins pratique et sécurisée que les options précédentes.

Liste de codes de secours
Techniquement valide, elle sert essentiellement de solution de secours, en cas de perte, vol ou indisponibilité du facteur principal de possession.

Faut-il déclarer la mise en place de la MFA sur CAS dans le registre des traitements RGPD ?

Oui, dans la plupart des cas, il est recommandé d'actualiser le registre des traitements lorsque la MFA est activée sur CAS, car elle modifie le processus d'authentification et peut impliquer de nouvelles données personnelles.

La connexion via CAS ne se limite pas à l'authentification : elle transmet aussi des informations personnelles (nom, prénom, mail, etc.) aux services tiers. Ce transfert constitue un traitement soumis au RGPD.

  • Si la MFA repose sur un facteur interne et discret (ex. : application OTP sans collecte de données personnelles, carte multiservice, clé USB FIDO2), une simple mention dans les mesures de sécurité du traitement existant peut suffire.
  • Si le second facteur implique des données personnelles nouvelles, comme un numéro de téléphone pour OTP par SMS ou un mail personnel, une mise à jour du registre est fortement recommandée.

Comment connaître les stats d'usage de ESUP-OTP  ?

Actuellement, ESUP-OTP ne fournit pas de statistiques d'usage (nombre de personnes ayant activé la MFA, le type de méthode activée...). Il est prévu de fournir une page de statistique via le manager mais les développements ne sont pas encore planifiés.

  • On peut sortir des informations en faisant des requêtes sur la base MongoDB

Stats méthodes activées

db.UserPreferences.find().map(e => Object.keys(e).filter(method => e[method].active).sort().join(" ")).sort().toArray().reduce((h, actives) => { h[actives] = (h[actives] || 0) + 1; return h }, {})

Pour avoir des statistiques enrichies avec les profils des utilisateurs, vous pouvez traiter les logs ESUP-OTP par Agimus-NG.

Vous pouvez ainsi des visualisations et des tableaux de bord mis à jour en temps réel.


  • Aucune étiquette