toolbox_archive.md

-======  Multi-factor authentication with IdPv3 ======
+#  Multi-factor authentication with IdPv3 #
+
   * Meeting notes below
   * [Specifications](toolbox_archive/specifications)
   * [Questions & Answers](toolbox_archive/questions)
   * [Technology Watch](toolbox_archive/techwatch)
 
-===== Project locations =====
+## Project locations ##
 
   * This wiki
   * Issues, planning and roadmap on [[https://forge.switch.ch/projects/idpv3-mfa|SWITCH Forge]]
   * Source code on [[https://gitlab.switch.ch/etienne.dysli-metref/idpv3-mfa|SWITCH's GitLab]]<code bash>git clone https://gitlab.switch.ch/etienne.dysli-metref/idpv3-mfa.git</code>
 
-===== Test accounts with OTP =====
+## Test accounts with OTP ##
+
 Test accounts for use on [[https://mfa-dev.ed.switch.ch/index.html|mfa-dev]]
 ^ Username     ^ Password      ^ TOTP seed (base32)                   ^
 | ''student1'' | ''password1'' | ''QJWAYZKBYCEGOTMLVLHRWK2XR5GER4YO'' |
@@ -18,42 +20,58 @@ Test accounts for use on [[https://mfa-dev.ed.switch.ch/index.html|mfa-dev]]
 
 ----
 
-===== Output of the first brainstorming session =====
-==== The landscape ====
+## Output of the first brainstorming session ##
+
+### The landscape ###
+
 ![MFA landscape](uploads/5c5a250a6e5fc726e4488c7280779d93/brainstorm1.jpg)
-==== Questions for those looking to deploy MFA ====
+
+### Questions for those looking to deploy MFA ###
+
   * What do you want to gain with MFA?
   * What hardware can you rely on? (mobile/smart phones)
   * What risks and expected quality levels correspond to your use case?
   * What is the target user group? homogeneity <-> risk
   * What are the available budget and effort sizes? for development and deployment
-==== Considerations about Shibboleth and the SAML environment ====
+
+### Considerations about Shibboleth and the SAML environment ###
+
   * Connection between a login flow and [[ http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf | SAML Authentication Context Classes ]]. What class to use for a new flow?
   * Is it possible to combine login flows (sequence, alternative, choice, ...)? if so, how? Answer from devs: [[https://shibboleth.net/pipermail/dev/2015-July/006954.html|no]].
   * Flow support for forced authentication and passive authentication.
   * Where does the verification of the second factor happen? Inside or outside the IdP process? Are existing extension points sufficient?
-===== Use cases =====
-==== Uni Genève ====
+
+## Use cases ##
+
+### Uni Genève ###
+
   * Main need: Higher security for a HR web application that contains personal data. The application is already protected by a Shibboleth SP.
     * Other needs: sensitive business web applications (via SPs) such as exam scores management e.g., health data access, systems administration, mobility and remote access/VPN, sensitive research projects (including collaboration with industry)
   * Target population: all university staff
   * Target environment: IdPv3
 
-==== Uni Lausanne ====
+### Uni Lausanne ###
+
   * Need: Higher security for servers and VPN access. Currently available on their IdPv2 but no SP uses it.
   * Target population: system administrators, maybe other IT staff
   * Target environment: RADIUS interface for IdPv3, servers and VPN
-==== Swiss edu-ID ====
+
+### Swiss edu-ID ###
+
   * Need: no real need yet, want a demonstrator
   * Target population: all edu-ID users
   * Target environment: IdPv3
 
 [Questions from UniGE to Swiss edu-ID](toolbox_archive/questions)
-===== Output of the second brainstorming session =====
+
+## Output of the second brainstorming session ##
+
 ![MFA scenarios](uploads/62357a415625c21c16a49d33dae92cf2/brainstorm2.jpg)
 
-===== Notes of the working session of 28.10.15 =====
-==== Notes ====
+## Notes of the working session of 28.10.15 ##
+
+### Notes ###
+
   * Google Auth is the solution that interests both SWITCH for Swiss edu-ID and UNIGE for secure access to web services
   * UNIGE could provide radius backend for initial tests at SWITCH
   * Other solutions interest UNIGE, especially SMS and Yubikey
@@ -63,7 +81,9 @@ Test accounts for use on [[https://mfa-dev.ed.switch.ch/index.html|mfa-dev]]
   * There are not many MFA login flows for IdPv3 but it is quite possible they become available in the coming months from other entities/consortia
   * For now, no other universities will participate in the project
   * Open question: how to take into account blind people?
-==== Décisions ====
+
+### Décisions ###
+
   * The main target is Google Auth. Additionnal means can be managed via a radius backend
   * Main steps and schedule:
     * Writing specifications - SWITCH:EDM - and bid for collegiate validation - 12.2015
@@ -74,7 +94,8 @@ Test accounts for use on [[https://mfa-dev.ed.switch.ch/index.html|mfa-dev]]
     * Pilote and production implementation - Q3 & Q4 2016
   * For now, we use the discourse tool to exchange during the specification phase. A meeting will be scheduled by Etienne when a first draft of the specs will be available
 
-===== Notes of the working session of December 2015 (UniGE) =====
+## Notes of the working session of December 2015 (UniGE) ##
+
 Globalement, les spécifications décrites correspondent bien à la cible que nous avions comprise, avec les acteurs impliqués comme suit:
   * PRODS et OJE: SP. Implémenté dans Apache mode shibboleth, plusieurs classes standardisées, cf. security level. Voir si limitation avec OJE et DBA avec aide PRODS/Sys
   * AHU: serveurs d'authentification, déploiement du back end Radius (il existe déjà plusieurs serveurs radius qu'on peut réutiliser, ou spécifiques, pas de VM a priori)
@@ -106,20 +127,25 @@ Voici cependant quelques compléments qui ont été discutés en séance:
     * **NB** Pour l'instant, la réauthentification est utilisée pour faire cela, mais ça pose des problèmes de complexité au sein du portail qui gère une authentification globale pour l'ensemble du portail, et n'apporte pas la sécurité attendue (1 seul facteur d'authentification = mdp).
     * Cible: utilisation d'un déclenchement sur action de l'utilisateur dans l'interface (typiquement clic sur un bouton), via un deuxième SP et un changement d'URL? Possibilité d'utiliser seulement le second facteur
     * A discuter avec l'équipe portail
-==== Autres aspects ====
+
+### Autres aspects ###
+
   * L'architecture doit être résiliente: il faut prévoir la redondance pour chaque composant de la nouvelle chaîne d'authentification.
   * L'appli RH cible est exposée comme une frame via le portail portail.unige.ch qui est accessible via le mot de passe standard ISIs
     * Or l'IdP n'est pas fait pour le portail et les frames, notamment problèmes de taille et de lisibilité. Il faudrait une application/SP par écran?
     * A discuter avec l'équipe portail
   * Voici une idée de ce que pourrait donner l'IdP MFA: ![mfa_login_form_mockup](uploads/bba6c4537bfdf4c6d0f4826b0bf64f51/mfa_login_form_mockup.png)
 
-===== Notes of the working session of 6.4.2016 =====
+## Notes of the working session of 6.4.2016 ##
+
 [Mock login screens](uploads/e8b0e7197993cc178a32db07838d664e/mockup-mfa-idp.pdf)
 
-==== Questions ====
+### Questions ###
+
   * Is it possible to specify the desired authentication method (SAML authnContextClassRef) on specific URLs in the Apache configuration?\\ **Yes**, according to [[https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig|NativeSPApacheConfig]], any [[https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPContentSettings|content setting]] can be given with the ''ShibRequestSetting'' directive, in particular ''authnContextClassRef'', ''authnContextComparison'' and ''forceAuthn''. Additionally, it is possible to request more than one authentication method.
   * Same question as above with "force authentication".\\ **Yes** with ''ShibRequestSetting forceAuthn true'', see above.
   * Is there a session timeout per authentication method on the SP?\\ **Yes**, but not directly. Session timeouts can be changed per application (in the SP sense). For example, An [[https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationOverride|ApplicationOverride]] could specify a [[https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions|Sessions]] element with MFA-specific timeouts (available settings are ''lifetime'', ''timeout'' and ''maxTimeSinceAuthn''), then this application can be referenced in the Apache configuration with ''ShibRequestSetting applicationId foo''.
 
-==== more meetings ====
+### more meetings ###
+
 are [here](toolbox_archive/meetings)