US-init_Lab-access-control.txt

*Предложение за контрол на достъпа до init Lab*

0. TL;DR: Потвърден тел.номер при отваряне, ПИН при отключване,
	Добавяне на API, затягане на security и tracebility

1. Канали за управление на достъпа до лаба
	1. Стационарен телефон
	2. Булфон
	3. Уеб интерфейс (фауна)
	4. (предложение) REST HTTPS API

2. Политика за отваряне (ако е отключено):
задължителна идентификация, без специален достъп
	2.1 - MSISDN (тел.номер) - ОК
	2.2 - MSISDN (тел.номер) + ПИН - ОК
	2.3 - E-mail + Password - Not OK?
		(предложение) да въведем потвърждение на тел.номер ако
		потребителя иска да може да отваря вратата
	2.4 - API Тoken - ОК?
		Токена да ползва правата на акаунта
		от точка 2.3 (т.е. мейл+пасс, и повтърден номер)
		При изтекла сесия във Фауна, да пренасочва за логин

3. Политика за отключване/заключване:
задължителна оторизация по 2 фактора
	3.1 - MSISDN (тел.номер) + ПИН - ОК
	3.2 - MSISDN (тел.номер) + ПИН - ОК?
		тук фактора реално е само ПИН, номера е user-supplied
		но ако съвпада с този в акаунта и ПИН-а е верен,
		би трябвало да е ОК
	3.3 - E-mail + Password - Not ОК?
		(предложение) да се въведе задължително изискване за ПИН. Освен това
		тел.номера трябва да е потърден както при политиката за отваряне
	3.4 - API Тoken + ПИН - OK?

4. (предложение) Смяна на ПИН - само след мейл потвърждение

5. (предложение) Блокиране на логин/ПИН
	5.1 При 3 пъти грешна парола за даден мейл, се блокира акаунта.
	5.2 При 3 пъти подаден грешен ПИН на акаунт, да се блокира ПИН-а.
	5.3 Блокираните данни се отблокират само ръчно от УС.
	5.4 При 5.1 или 5.2 се праща мейл до УС с името на акаунта, мейла,
телефона и IP адресите от които е грешния логин/ПИН, както и IP на регистрация
	
6. (предложение) Доверените членове да уведомяват възможно най-бързо при
загуба/кражба на устройство.

7. (предложение) Валидацията на MSISDN (тел.номер) да може да се извършва по
един от следните начини:
	7.1 SMS до номера (мога да предоставя gateway за 5 ст/SMS, с около 200
		предплатени съобщения кредит в него за тестови цели)
	7.2 SMS от номера до наш дивайс (примерно GSM GW с предплатена карта)
	7.3 Обаждане до номера на лаба, като преди това чакащия за верификация
		номер се вкарва в списък, и ако до 30 мин звънне, вместо да чуе
		IVR за отваряне/отключване, Стивън Хокинг ще му продиктува 6-цифрен
		код за верификаця на номера
	7.4 Обаждане от някъде до номера - по-скоро не, кой ще плаща разговора?
		Вариант ли е ако намерим third-party услуга, която да предоставя
		обаждане до номер от техен IVR и диктуване на код? (аз лично съм
		против)
	7.5 Ръчно от УС

8. Аргументи
- Много по-лесно е да се направи регистрация с фейк мейл, отколкото
да се спуфи телефонен номер.
- При кражба на мейл/парола, няма да може да се отключи без ПИН.
- При кражба на устройство с логнат акаунт на него, не можем да направим
кой знае какво, защото най-вероятно мейла ще е логнат в клиента на ОС,
така че можем да разчитаме само на security code/fingerprint/pattern. Ще
разчитаме на 6.