|
|
|
====== Multi-factor authentication with IdPv3 ======
|
|
|
|
* Meeting notes below
|
|
|
|
* [[specifications|Specifications]]
|
|
|
|
* [[questions|Questions & Answers]]
|
|
|
|
* [[techwatch|Technology Watch]]
|
|
|
|
|
|
|
|
===== 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 for use on [[https://mfa-dev.ed.switch.ch/index.html|mfa-dev]]
|
|
|
|
^ Username ^ Password ^ TOTP seed (base32) ^
|
|
|
|
| ''student1'' | ''password1'' | ''QJWAYZKBYCEGOTMLVLHRWK2XR5GER4YO'' |
|
|
|
|
| ''student2'' | ''password2'' | ''HDRCSSKZFXBBEMVT5DY74JIB425NAEZJ'' |
|
|
|
|
|
|
|
|
----
|
|
|
|
|
|
|
|
===== Output of the first brainstorming session =====
|
|
|
|
==== The landscape ====
|
|
|
|
{{ :brainstorm1.jpg?400 | MFA landscape }}
|
|
|
|
==== 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 ====
|
|
|
|
* 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 ====
|
|
|
|
* 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 ====
|
|
|
|
* 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 ====
|
|
|
|
* Need: no real need yet, want a demonstrator
|
|
|
|
* Target population: all edu-ID users
|
|
|
|
* Target environment: IdPv3
|
|
|
|
|
|
|
|
[[questions|Questions from UniGE to Swiss edu-ID]]
|
|
|
|
===== Output of the second brainstorming session =====
|
|
|
|
{{ :brainstorm2.jpg?400 | MFA scenarios}}
|
|
|
|
|
|
|
|
===== 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
|
|
|
|
* UNIGE can provide the SMS gateway for initial tests at SWITCH and later for it's members login on Swiss edu-ID's IdP.
|
|
|
|
* Using a radius backend can help integrating these solutions without developing specific login flows (UNIL did that with their radius provider)
|
|
|
|
* Login flow - it should be possible to choose from multiple second-factor solutions
|
|
|
|
* 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 ====
|
|
|
|
* 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
|
|
|
|
* [[techwatch|Technology watch]]: verify the availability of new login flows that could be used for our own needs - SWITCH & UNIGE - Q4 2015 & Q1 2016
|
|
|
|
* Login flow development for Google Auth - SWITCH:EDM - S1 2016
|
|
|
|
* integration / implementation of the backend radius and study of the possibility of using other techniques (SMS, Yubikey) - UNIGE:AHU,DPE,CBR - S1 2016
|
|
|
|
* Definition of organizational procedures (provisioning, exceptions handling, (self-)enrolment, communication, helpdesk, incident management, etc.) - UNIGE:PLH - S1 2016
|
|
|
|
* 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) =====
|
|
|
|
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)
|
|
|
|
* PLH: aspects organisationnels, instanciation des utilisateurs / enrôlement, processus d'enregistrement, processus de support
|
|
|
|
* EDY: IdP: code jar. Jsp. Login flow, fichiers de config, liens avec BDD / Radius, francisation customisation logo
|
|
|
|
|
|
|
|
Voici cependant quelques compléments qui ont été discutés en séance:
|
|
|
|
|
|
|
|
* On délègue toujours au Radius? Même pour Google Auth?
|
|
|
|
* L'IdP MFA peut différer de l'IdP MDP: des règles de gestion spécifiques doivent pouvoir être appliquées, notamment pour le timeout, le SSO, les notifications, ...
|
|
|
|
* Aujourd'hui les timeouts sont les suivants: IdP = 10h, SP = 1h. Il faut envisager des délais (beaucoup) plus courts pour une session MFA, genre 5-10 minutes.
|
|
|
|
* L'IdP actuel fait du SSO, hors ici, nous souhaitons a priori désactiver cette fonctionnalité
|
|
|
|
* Il existe 1 fonctionnalité dans l'IdP pour informer (au niveau interface) sur l'expiration du mot de passe ou le nombre d'essais restants. Il ne faut pas que cela interfère avec la 2FA
|
|
|
|
* Architecture: du coup, il n'est pas encore clair de savoir s'il faut mettre en œuvre un second IdP en place pour MFA, complètement distinct de l'IdP mot de passe ou s'il s'agit d'appliquer des configurations différentes au sein d'un seul IdP
|
|
|
|
* End users: ajout d'un scénario du type //Accès de secours//
|
|
|
|
* //As a university staff (and VIP), I want to be able to immediately access a SP requiring 2FA, even if I forgot my mobile phone. It means that I am granted a fallback access for a limited period of time but only after proving my identity, in a way or another.//
|
|
|
|
* End users: ajout d'un scénario de "l'utilisateur réticent"
|
|
|
|
* //As a university staff, I do not want to use my personal mobile phone to access university's IT ressources. I think that University should give me the means to do this, and furthermore I do not have a mobile phone.//
|
|
|
|
* Nous ne savons pas forcément comment traiter ce cas aujourd'hui.
|
|
|
|
* End users: ajout d'un scénario Password Recovery
|
|
|
|
* //As a university student, I want to be able to reset my password using an online selfcare service and 2FA to prove my identity//
|
|
|
|
* Ce point n'est pas traité pas shibboleth mais par le Password Desk (outil SSPR NetIQ). Par contre les n° de mobile utilisés sont les mêmes que pour l'authent MFA.
|
|
|
|
* End users: ajout d'un scénario HelpDesk
|
|
|
|
* //As a Help Desk operator, I need tools to deliver a temporary access in MFA to a user who is temporarily not able to use his second factor. Especially, if he is a VIP.//
|
|
|
|
* Pour les sections End users et Operators / services, il faudrait indiquer explicitement ce qui sera traité via shibboleth de ce qui sera traité en dehors.
|
|
|
|
* SP operator: utilisation de la 2FA pour valider les actions des utilisateurs
|
|
|
|
* //For sensitive applications, I want to be able to use 2FA to validate user actions but not to use 2FA for global authentication and access to these applications.//
|
|
|
|
* Par exemple, on veut qu'un utilisateur de l'application saisie des notes sur le web puisse saisir les notes, ce qui peut prendre du temps, en authent. Simple, et seulement utiliser la 2FA au moment de l'envoi du relevé de notes dans le système.
|
|
|
|
* **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 ====
|
|
|
|
* 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.png? |}}
|
|
|
|
|
|
|
|
===== Notes of the working session of 6.4.2016 =====
|
|
|
|
{{:mockup-mfa-idp.pdf|Mock login screens}}
|
|
|
|
==== 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 ====
|
|
|
|
are [[meetings|here]] |
