* Design MFA pour IdP 3.3 [MFA enhancements in 3.3](https://shibboleth.net/pipermail/dev/2016-April/008171.html)[IDP-962](https://issues.shibboleth.net/jira/browse/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]]
* Quelle méthode de déploiement (pour UniGE)? [3664](https://forge.switch.ch/issues/3664)
### 3.2 ou 3.3? ###
...
...
@@ -34,14 +34,14 @@ Une mise à jour de l'IdP du projet Swiss edu-ID en version 3.2 est prévue d'ic
#### 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.
Je commence le développement d'un premier login flow très simple en me basant sur la version **3.2** (voir [3674](https://forge.switch.ch/issues/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//.
* Produit [Self Service Password Reset](https://www.netiq.com/products/self-service-password-reset/) mentionné comme possible solution d'enrôlement.
* Le NIST cesse de recommander le SMS comme "out of band verifier", voir [5.1.3.2. Out of Band Verifiers](https://pages.nist.gov/800-63-3/sp800-63b.html#out-of-band) 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]]
* ED: commence développement partie RADIUS [w34](https://forge.switch.ch/versions/134)
* PLH ouvert au feedback sur les [spécifications](uploads/682fd6d12b502befb66be5ab1be51941/ge173-specs_pour_gt_mfa.pdf)
* 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]].
* 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 [MFA Interoperability Profile Working Group](https://spaces.internet2.edu/display/MIPWG/MFA+Interoperability+Profile+Working+Group+Home) avec le [InCommon MFA Profile](https://spaces.internet2.edu/display/MIPWG/Final+Products+of+the+MFA+Interoperability+Profile+Working+Group).
* 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.
* 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 [Sessions](https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions): ''lifetime'', ''timeout'' et ''maxTimeSinceAuthn'' s'appliquent à toutes les méthodes.
@@ -129,8 +129,8 @@ Je serai en vacances du 14 au 29 mai donc la réunion du 18.5 tombe et la procha
### Done ###
* [[https://forge.switch.ch/versions/139|w42]]
* Nouveau dépôt Git [[https://gitlab.switch.ch/etienne.dysli-metref/idpv3-mfa.git]]
*[w42](https://forge.switch.ch/versions/139)
* Nouveau dépôt Git https://gitlab.switch.ch/edu-id/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").
...
...
@@ -159,7 +159,7 @@ Je serai en vacances du 14 au 29 mai donc la réunion du 18.5 tombe et la procha
* 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
...
...
@@ -176,7 +176,7 @@ Je serai en vacances du 14 au 29 mai donc la réunion du 18.5 tombe et la procha
* 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.
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 [implicit submission](https://www.w3.org/TR/html5/forms.html#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 ##
...
...
@@ -209,7 +209,7 @@ Problème quand le bouton "demander sms" est situé avant le bouton "envoyer" su
### 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.
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 [11.6.3. Using a HTML link to signal an event](http://docs.spring.io/spring-webflow/docs/2.4.x/reference/htmlsingle/#webflow-event-link). La variable ''${flowExecutionUrl}'' est automatiquement remplacée.
