... | ... | @@ -102,7 +102,7 @@ Je serai en vacances du 14 au 29 mai donc la réunion du 18.5 tombe et la procha |
|
|
|
|
|
* 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 [Sessions](https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions): ''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.
|
|
|
|
|
|
## 2016-08-24 ##
|
|
|
|
... | ... | @@ -190,7 +190,7 @@ Je serai en vacances du 14 au 29 mai donc la réunion du 18.5 tombe et la procha |
|
|
* 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 ''<input type="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.
|
|
|
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 `<input type="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 ##
|
|
|
|
... | ... | @@ -198,7 +198,7 @@ Problème quand le bouton "demander sms" est situé avant le bouton "envoyer" su |
|
|
* 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.
|
|
|
* 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)
|
|
|
|
... | ... | @@ -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 ''<button type=submit .../>'' par un lien pointant vers la même URL que le formulaire avec le paramètre ''_eventId'', c'est-à-dire: <code><a href="${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.
|
|
|
Il faut remplacer l'élément `<button type=submit .../>` par un lien pointant vers la même URL que le formulaire avec le paramètre `_eventId`, c'est-à-dire: <code><a href="${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.
|
|
|
|
|
|
## 2017-03-08 ##
|
|
|
|
... | ... | |