| Table of Contents |
|---|
High-level tasks:
- mithril model and API changes - ave phone number, get services. Changes in concept user, party employee, party_users.
- Change Create employee process - add 2nd factor phone number, add phone number verification step
- Change approve employee process - two-step approval, resend sms
- Change login process - step, resend sms, otp counter, block user after n logins failed
- Existing users migration - move the mobile phone number to the 2nd factor
- Mithril admin changes - show 2nd factor, block/unblock user
- Introduce user endpoints to MIS
Assumtions:
- We keep using oauth 2.0 flow.
- 2factor auth will be introduced for all users at the same time
- mobile phone number for all the existing users should be automatically used as the 2nd factor
- 2nd factor can be changed only via create employee request
- 2nd factor - OTP delivered via sms
- 2-factor auth can be applied to all the admin consoles: mithrill, uaddresses, nhs.admin - configurable
Key aspects of implementation
- We implemented only 2FA (but Many_FA)
- User must authorize for 2FA (second step) only after successful login with emal+password (first step)
- We support a few kind of factors, but user have only 1 active factor at the same time
- Now we implement only `SMS` factor type
- We add blocking process (in case OTP error) for verifying step
- We create additional blocking process (in case error password) for normal login process (login + password)
- Logic 2FA process based on same token_types (access_token_type && 2fa_access_token_type)
- 2FA data store at separate entity `mithril.authentication_factors` (without status model, but with logical state for 2fa & user item)
- OTP data store at existing separate entity `mithril.otp` (with status model)
- At same time we have 1 active OTP for 1 factor
Authorize Flow
Change Factor Flow
Authorize Flow (sequence diagram)
Tests
2FA Authentication Test Scenarios page.
Children pages:
| Child pages (Children Display) |
|---|