toolbox_archive/specifications.md

+====== Specifications for MFA with IdPv3 ======
+A lightweight specification that should get more precise as areas of this project are further explored.
+
+===== User stories =====
+From https://www.mountaingoatsoftware.com/agile/user-stories:
+> User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
+>
+> //As a <type of user>, I want <some goal> so that <some reason>.//
+>
+> User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.
+
+==== End users ====
+
+As a university staff with a smart phone,\\
+I want to use the Google Authenticator mobile application when authenticating on the IdP,\\
+so that I can access SPs requiring 2FA.
+
+As a university staff with only a mobile phone (no smart phone),\\
+I want to receive an OTP via SMS when authenticating on the IdP,\\
+so that I can access SPs requiring 2FA.
+
+As a user authenticating on the IdP,\\
+I want to be able to choose the second authentication factor,\\
+so that I can use the most convenient method for me.
+
+//Backup access//
+As a regular 2FA user temporarily unable to use my second factor,\\
+I want to be granted a fallback access for a limited period of time,\\
+so that I can access SPs requiring 2FA.\\
+-> process independent of Shibboleth (helpdesk-provided OTP)
+
+As a reluctant university staff,\\
+I want the University to give me the means to access protected resources,\\
+so that I can access SPs requiring 2FA without using my own personal device.\\
+-> process independent of Shibboleth (physical token?)
+
+//Password recovery//
+As a university student,\\
+I want to be able to reset my password using a 2FA-protected online self-service,\\
+so that my password cannot be changed by others.\\
+-> process independent of Shibboleth
+
+==== Operators/services ====
+
+As a SP-protected web application operator,\\
+I want to force users to authenticate with two factors,\\
+so that their account and the personal information it contains are better protected.
+
+As a SP-protected web application operator,\\
+I want to be able to use 2FA only to validate sensitive user actions,\\
+so that sensitive actions are strongly protected and users are not required to use 2FA all the time.\\
+-> handled by the application which must request stronger authentication to Shibboleth when it needs it
+
+As an IdP operator,\\
+I want to provide a 2FA login flow,\\
+so that SPs can get stronger authentication.
+
+As a VPN gateway operator,\\
+I want to authenticate 2FA users over RADIUS,\\
+so that both users with or without 2FA are authenticated over the same protocol.\\
+-> RADIUS authentication is independent of Shibboleth
+
+As a university account administrator,\\
+I want to verify user's identities before they can use 2FA,\\
+so that I can provide a stronger verification level to applications using 2FA.\\
+-> process independent of Shibboleth
+===== Architecture =====
+![idpv3-mfa_architecture](uploads/db3a93905741734390c531f4b3d8381f/idpv3-mfa_architecture.png)
+==== Assumptions ====
+  * There is an "authentication server" outside of the IdP that verifies OTPs and stores token keys. It also supports a user registration process and allows to revoke second factors when required.
+  * A brief [[description of a radius authentication test server]] for an rfc6238 TOTP 2nd factor.
+===== Documents =====
+[Spécifications UniGE](uploads/682fd6d12b502befb66be5ab1be51941/ge173-specs_pour_gt_mfa.pdf)
\ No newline at end of file