* 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 ===
### 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 ===
#### 3.3 ####
* + meilleur support MFA
* + possibilité d'essayer cette nouvelle fonction et d'influencer sur son développement
* - nouveau code pas encore stabilisé
...
...
@@ -26,37 +32,48 @@
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 ===
#### 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.
* PLH: [spécifications](uploads/682fd6d12b502befb66be5ab1be51941/ge173-specs_pour_gt_mfa.pdf) mises à disposition du groupe
...
...
@@ -78,27 +97,38 @@ Je serai en vacances du 14 au 29 mai donc la réunion du 18.5 tombe et la procha
* ED: commence développement partie RADIUS [[https://forge.switch.ch/versions/134|w34]]
* PLH ouvert au feedback sur les [spécifications](uploads/682fd6d12b502befb66be5ab1be51941/ge173-specs_pour_gt_mfa.pdf)
* DP/CB: tests nouveau code
==== Questions ====
### 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
...
...
@@ -116,7 +146,9 @@ Je serai en vacances du 14 au 29 mai donc la réunion du 18.5 tombe et la procha
* 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 ====
### 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:
...
...
@@ -125,34 +157,43 @@ Je serai en vacances du 14 au 29 mai donc la réunion du 18.5 tombe et la procha
* 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 =====
## 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.
...
...
@@ -160,18 +201,27 @@ Problème quand le bouton "demander sms" est situé avant le bouton "envoyer" su
* 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 =====
## 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 ====
### 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 =====
## 2017-03-08 ##
* rien de nouveau
* prochaine réunion 12.4.2017 14:30
===== 2017-04-12 =====
## 2017-04-12 ##
Réunion annulée par manque de contenu. ;-)
===== 2017-05-17 =====
## 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.
