|
|
|
====== Multi-factor authentication with IdPv3 ======
|
|
|
|
* Meeting notes below
|
|
|
|
* [Specifications](specifications)
|
|
|
|
* [Questions & Answers](questions)
|
|
|
|
* [Technology Watch](techwatch)
|
|
|
|
* [Specifications](toolbox_archive/specifications)
|
|
|
|
* [Questions & Answers](toolbox_archive/questions)
|
|
|
|
* [Technology Watch](toolbox_archive/techwatch)
|
|
|
|
|
|
|
|
===== Project locations =====
|
|
|
|
|
| ... | ... | @@ -48,7 +48,7 @@ Test accounts for use on [[https://mfa-dev.ed.switch.ch/index.html|mfa-dev]] |
|
|
|
* Target population: all edu-ID users
|
|
|
|
* Target environment: IdPv3
|
|
|
|
|
|
|
|
[Questions from UniGE to Swiss edu-ID](questions)
|
|
|
|
[Questions from UniGE to Swiss edu-ID](toolbox_archive/questions)
|
|
|
|
===== Output of the second brainstorming session =====
|
|
|
|
|
|
|
|
|
| ... | ... | @@ -67,7 +67,7 @@ Test accounts for use on [[https://mfa-dev.ed.switch.ch/index.html|mfa-dev]] |
|
|
|
* 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
|
|
|
|
* [Technology watch](techwatch): verify the availability of new login flows that could be used for our own needs - SWITCH & UNIGE - Q4 2015 & Q1 2016
|
|
|
|
* [Technology watch](toolbox_archive/techwatch): 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
|
| ... | ... | @@ -122,4 +122,4 @@ Voici cependant quelques compléments qui ont été discutés en séance: |
|
|
|
* 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 [here](meetings) |
|
|
|
are [here](toolbox_archive/meetings) |
