* Design MFA pour IdP 3.3 [[https://shibboleth.net/pipermail/dev/2016-April/008171.html|MFA enhancements in 3.3]] [[https://issues.shibboleth.net/jira/browse/IDP-962|IDP-962]]
* Quelle version de base? 3.2 ou 3.3-dev?
* Quelle méthode de déploiement (pour UniGE)? [[https://forge.switch.ch/issues/3664|3664]]
==== 3.2 ou 3.3? ====
=== 3.2 ===
* + actuelle version stable
* + développement de login flows connu
* - les login flows compliqués devront être retravaillés pour 3.3
=== 3.3 ===
* + meilleur support MFA
* + possibilité d'essayer cette nouvelle fonction et d'influencer sur son développement
* - nouveau code pas encore stabilisé
* - date de sortie encore vague et tardive (Q3/Q4 2016)
Une mise à jour de l'IdP du projet Swiss edu-ID en version 3.2 est prévue d'ici 2 mois. Pas de plan particulier pour de futures mises à jour.
=== Proposition ===
Je commence le développement d'un premier login flow très simple en me basant sur la version **3.2** (voir [[https://forge.switch.ch/issues/3674|3674]]). On refera le point sur l'état de la 3.3 à la prochaine réunion.
* Produit [[https://www.netiq.com/products/self-service-password-reset/|Self Service Password Reset]] mentionné comme possible solution d'enrôlement.
* Le NIST cesse de recommander le SMS comme "out of band verifier", voir [[https://pages.nist.gov/800-63-3/sp800-63b.html#out-of-band|5.1.3.2. Out of Band Verifiers]] dans //DRAFT NIST Special Publication 800-63B Digital Authentication Guideline//.
* Quelle direction: RADIUS ou flow 1 écran? -> RADIUS
* Qui fait quoi les deux prochaines semaines?
* ED: commence développement partie RADIUS [[https://forge.switch.ch/versions/134|w34]]
* PLH ouvert au feedback sur {{:ge173-specs_pour_gt_mfa.pdf|spécifications}}
* DP/CB: tests nouveau code
==== Questions ====
* Pourrait-on envisager une authnContextClassRef commune à plusieurs institutions pour signifier l'usage d'une authentification forte (sans qu'elle soit liée à une technologie en particulier)? -> Oui, c'est ce qu'a défini le [[https://spaces.internet2.edu/display/MIPWG/MFA+Interoperability+Profile+Working+Group+Home|MFA Interoperability Profile Working Group]] avec le [[https://spaces.internet2.edu/display/MIPWG/Final+Products+of+the+MFA+Interoperability+Profile+Working+Group|InCommon MFA Profile]].
* Quelle authnContextClassRef est demandée par le SP lors du renouvellement d'une session expirée? -> La configuration de la protection de l'URL demandée s'applique et détermine la classe.
* Quels sont les différents réglages de durée de session sur le SP en fonction de la méthode d'authentification? -> Il n'y a pas de réglage par méthode d'authentification sur le SP. Les timeouts sur l'élément [[https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions|Sessions]]: ''lifetime'', ''timeout'' et ''maxTimeSinceAuthn'' s'appliquent à toutes les méthodes.
* Nouveau dépôt Git [[https://gitlab.switch.ch/etienne.dysli-metref/idpv3-mfa.git]]
* UniGE
* la partie MFA pour l'IdP a été installée sur nos IdPs de lab et de test.
* le formulaire d'entrée du second facteur (simple-form.vm, cf. message de Pierre Lehmann) a été customisé (en particulier l'input pour le code OTP n'est plus de type "password").
* deux SPs dont un accessible dans le portail ont été configurés (dans apache) pour divers tests:
* authentification/SSO avec mot de passe seul.
* authentification/SSO avec mot de passe seul et second facteur avec SSO.
* authentification/SSO avec mot de passe et second facteur sans SSO (forcé).
* authentification/SSO avec second facteur, seulement si accès depuis hors le réseau de l'université.
* authentification dans un iframe du portail (avec ajustement de la taille du formulaire).
* le serveur Radius a été augmenté pour permettre:
* l'envoi du code par SMS ainsi que sa vérification (dans le formulaire on donne successivement "sms" puis le code reçu).
* l'utilisation d'une clé YubiKey (proxy vers un autre serveur Radius).
* permettre la saisie du code TOTP avec deux formats (123456 et 123 456).
* un système d'enrôlement à GoogleAuth a été mis au point (avec authentification à deux facteurs: mot de passe et une smartcard nécessaire pour l'impression du QRCode).
* une démonstration auprès des demandeurs a eu lieu ce lundi.
==== A discuter ====
* problème de l'erreur côté SP lorsque deux chemins sont protégés différemment (cf mon message du 5 octobre 2016).
* choix de l'identifiant de authnContextClassRef (p.ex. http://id.incommon.org/assurance/mfa)
* améliorations du code du module MFA dans l'IdP:
* redondance du service Radius (configuration dans TinyRadius).
* remontée des erreurs Radius à l'utilisateur (TOTP + SMS): au minimum lui indiquer que qqch ne va pas et qu'il doit recommencer.
* mapping du nom de login (username) sur un attribut (p.ex. idp.radius.userid-attribute = eduPersonUniqueId)
* unit tests pour vérifier que l'IdP et en particulier la partie MFA fonctionne après un déploiement
* UniGE: développement procédure enrôlement pour Google Authenticator
* Discuté:
* Il y a des personnes qui refusent de donner leur numéro de téléphone mobile ou d'utiliser leur smartphone personnel comme token. => Ni Google Auth, ni SMS OTP sont possibles et leur distribuer une Yubikey serait trop cher. Toutefois, si ces personnes sont raccordées au réseau filaire dans les locaux de l'UniGE, elles ont accès aux services sans second facteur. Ces "refuseurs" ne sont donc coupés que de l'accès à distance.
* ED: message d'erreur sur page OTP, variables dans templates Velocity, comportement SP lors de changement de authnContextClassRef
* PLH: séance avec client (RH) -> Les applications RH seront entièrement protégées par MFA (pas de mélange dans une session). Ces applications seront regroupées dans un onglet du portail, lui-même protégé par MFA (SP supplémentaire).
* PLH, AHU: continuent développement des procédures d'enrôlement
* Implémentation bouton SMS et mise en prod sur 3.2 avant de passer à la version 3.3.
* ED: renommé "send sms" en "request sms" dans les messages et le code
* ED: publication version 1.0.0
* CB: version 1.0.0 installée en test, démo
* Suite du projet en décembre et janvier? première réunion le 11.1.2017 pour voir si d'autres sont nécessaires
Problème quand le bouton "demander sms" est situé avant le bouton "envoyer" sur la page: si l'utilisateur appuie sur ''entrée'' dans le champ OTP, un SMS est envoyé au lieu de soumettre le code OTP. Le premier élément ''<inputtype="submit">'' dans l'élément ''form'' est pris comme action par défaut (voir HTML5 [[https://www.w3.org/TR/html5/forms.html#implicit-submission|implicit submission]]). Une solution pourrait être de dupliquer l'élément ''form'' pour que le bouton "demander sms" soit seul dans un formulaire.
===== 2017-01-11 =====
* ED va adapter cette extension pour l'IdP 3.3 dans le cadre du projet edu-ID (Q3 2017), y compris processus d'enrôlement.
* OJ: La configuration avec Apache 2.4 fonctionne bien, en particulier pour combiner les conditions sur l'adresse IP du client et la méthode d'authentification.
* Ils reste un comportement inconsistant du point de vue de l'utilisateur: lorsqu'il passe d'un SP1 demandant seulement un mot de passe à un SP2 demandant un second facteur, l'écran du second facteur apparaît directement; alors que s'il passe à une autre URL sur le même SP mais cette fois protégée par MFA, il faut une étape supplémentaire (attraper l'erreur 401 dans Apache) pour faire apparaître l'écran du second facteur.
* PLH: Un onglet supplémentaire "RH" a été ajouté au portail et regroupe toutes les applications demandant l'authentification forte. En attente de retour d'expérience du client et des utilisateurs.
* Est-il possible de remplacer le bouton "Recevoir un code par SMS" par un lien? Histoire de ne pas avoir deux éléments HTML ''type=submit'' dans la page.
* Discussion sur le problème de la livraison du second facteur à l'utilisateur: rapidité vs. vérification.
* Prochaine réunion dans un mois (8.2.2017)
===== 2017-02-08 =====
* UniGE: procédure d'enrôlement simplifiée pour mettre en place la MFA plus facilement: création du deuxième facteur uniquement à partir de la vérification du premier facteur (mot de passe).
* Prochaine réunion dans un mois (8.3.2017)
==== Lien à la place d'un bouton pour l'envoi d'un SMS ====
Il faut remplacer l'élément ''<buttontype=submit.../>'' par un lien pointant vers la même URL que le formulaire avec le paramètre ''_eventId'', c'est-à-dire: <code><ahref="${flowExecutionUrl}&_eventId=requestsmsotp">...</a></code>Voir à ce sujet la documentation de Spring Webflow [[http://docs.spring.io/spring-webflow/docs/2.4.x/reference/htmlsingle/#webflow-event-link|11.6.3. Using a HTML link to signal an event]]. La variable ''${flowExecutionUrl}'' est automatiquement remplacée.
===== 2017-03-08 =====
* rien de nouveau
* prochaine réunion 12.4.2017 14:30
===== 2017-04-12 =====
Réunion annulée par manque de contenu. ;-)
===== 2017-05-17 =====
Réunion annulée car aucune discussion ne s'avère nécessaire. Les dernières nouvelles selon PLH:
> Nous avons présenté au métier RH l'intégration de la MFA dans notre portail institutionnel pour répondre à leurs beoins ainsi que les interfaces de connexions MFA.
> Il s'avère qu'ils n'ont pas de remarques particulières sur les interfaces Shibboleth et elles leur semblent adaptées.
> Nous continuons donc le projet car il reste du travail sur d'autres demandes qu'ils ont.
Le projet n'est pas encore en production à l'UniGE. Une phase pilote, pour un déploiement progressif, va démarrer.
