Вход и пользователи
В Control Plane и в портал тенанта входят без пароля: по коду, который приходит на почту, или ключом входа — Face ID, Touch ID, отпечатком, Windows Hello или ключом из менеджера паролей. Учётные записи и их роли хранит сама платформа.
Как входят
- На странице входа человек указывает свою почту и получает письмо с кодом из шести цифр.
- Код действует 10 минут, на него есть пять попыток; новый можно запросить через минуту.
- После входа по коду устройство, которое умеет хранить ключи, предлагает сохранить ключ входа. В следующий раз хватит его — браузер предлагает ключ прямо в поле почты. Код остаётся запасным способом.
Ключи входа видны в профиле (меню учётной записи → «Профиль»): там их добавляют и удаляют. Там же — браузеры, в которых человек сейчас вошёл, и его история авторизаций.
Форма входа не говорит, есть ли учётная запись с указанным адресом: письмо уходит только заведённым адресам, а ответ одинаков для любого.
| Сессия длится | |
|---|---|
| Пользователь платформы | 12 часов, потом вход заново |
| Пользователь тенанта | 30 дней и продлевается, пока им пользуются |
Выход завершает сессию на сервере, а не только в браузере.
Сессии и устройства
В профиле, в разделе «Мои устройства», перечислены браузеры, в которых человек сейчас вошёл: устройство, IP-адрес, когда вошёл и когда был последний запрос. Сессию на любом другом устройстве можно завершить, а кнопка «Завершить все остальные» оставляет только текущую.
Администратор видит то же у своих людей: из списка пользователей открывается окно «Сессии и входы» — активные сессии человека с кнопкой «Завершить все сессии» и его последние события. В Control Plane это списки пользователей платформы и пользователей тенанта, в портале тенанта — страница «Пользователи».
Браузер с завершённой сессией узнаёт об этом при следующем запросе: человек попадает на страницу входа, и она говорит, что сессия завершена, а если её вытеснил вход на другом устройстве — то и это.
Число одновременных сессий одного человека ограничивает настройка SIGN_IN_MAX_SESSIONS: сверх лимита новый вход завершает сессию, которой дольше всех не пользовались. По умолчанию — 0, без ограничения.
Письмо о входе с нового устройства
Когда в учётную запись входят из браузера, из которого в неё ещё не входили, на её почту приходит письмо: когда, с какого устройства и IP-адреса и каким способом. Там же сказано, что делать, если входил не владелец учётной записи: открыть профиль, завершить сессии на других устройствах и сообщить администратору. Ссылок в письме нет, как и в письме с кодом.
Браузер узнаётся по случайному идентификатору в cookie, который живёт 400 дней, а «ещё не входили» значит «не входили за то время, что хранится история». После самого первого входа письма нет: человек только что получил приглашение. В браузере, где cookie очистили, вход снова считается новым.
История авторизаций
Платформа записывает входы — с кодом из письма, ключом входа или через провайдера, — неудачные попытки, выходы и завершённые сессии: когда, кто, с какого устройства и IP-адреса и, для завершённой сессии, почему и кто её завершил. Из неудачных попыток записываются неверный код, незнакомый ключ входа и вход через провайдера с адресом, для которого нет учётной записи. Запросы кода и отказы по частоте не записываются: их можно слать без конца, и история засорилась бы.
- Свою историю человек видит в профиле.
- В Control Plane у администратора платформы в разделе «Журналы» две вкладки: «Действия» и «История авторизаций». Во второй — история всех пользователей платформы и тенантов с фильтрами по человеку, событию, IP-адресу, периоду и тенанту.
- В портале тенанта такие же «Журналы» есть у владельца и администраторов тенанта — с историей его пользователей.
Из строки истории ссылка «Действия за день» ведёт на вкладку «Действия», отфильтрованную по этому человеку и этому дню. «Вся история» в окне «Сессии и входы» открывает вкладку истории, отфильтрованную по человеку.
История хранится SIGN_IN_HISTORY_DAYS дней, по умолчанию 180; более старые записи удаляются.
Учётные записи
Адрес почты — это и есть учётная запись: на всей установке один адрес принадлежит одному человеку.
- Пользователей платформы заводит администратор платформы в Control Plane, в разделе «Пользователи платформы»: имя, почта и роли. Свою учётную запись администратор не блокирует, не удаляет и не лишает прав администратора — это делает другой; последний активный администратор остаётся.
- Пользователей тенанта заводит платформа на странице тенанта или сам тенант в своём портале — в пределах своих прав.
Новый пользователь получает приглашение: письмо со ссылкой на страницу входа. Пользователь тенанта попадает на страницу в оформлении своего тенанта, и письма ему приходят в этом же оформлении, см. Оформление.
Блокировка и смена адреса сразу завершают все сессии этого человека; удаление убирает и его ключи входа.
Вход через другие системы
Если у сотрудников уже есть учётные записи в системе входа организации — Keycloak, ADFS, Azure AD или другой с OpenID Connect, — её можно добавить кнопкой на страницу входа обоих порталов. Администратор платформы делает это в Control Plane, в разделе «Провайдеры входа»: надпись на кнопке, адрес провайдера (issuer), Client ID и, для конфиденциального клиента, его секрет. У провайдера регистрируют клиента и адреса возврата, которые Control Plane показывает после сохранения, — по одному на каждый портал.
Провайдер подтверждает, кто человек, а учётную запись не создаёт. Войти можно в ту учётную запись, чей адрес провайдер называет подтверждённым; с первого входа она связывается с человеком у провайдера и дальше находится по этой связи, даже если почта у провайдера сменится. Учётные записи по-прежнему заводят в Control Plane и в портале тенанта.
Для входа через провайдеров нужен SECRETS_KEY бекэнда — один и тот же у Control Plane и портала тенанта: им шифруется секрет клиента в общей базе и защищается сам вход.
Первый администратор
Пока в платформе нет ни одного пользователя, войти некому. Первого администратора добавляют на сервере, в окружении бекэнда:
bash
python -m app.tools.users add admin@example.com --name "Анна Петрова"Он входит в Control Plane по коду, как все, и дальше заводит остальных сам. Той же командой добавляют администратора, если единственный потерял доступ к своей почте. python -m app.tools.users list показывает пользователей платформы, remove <email> — удаляет.
Что нужно установке
| Настройка бекэнда | Зачем |
|---|---|
CP_URL, TP_URL | Адреса порталов, как их открывают пользователи. Изменения принимаются только с их страниц, ключи входа работают на них, приглашения ведут на них. Задают оба — и у Control Plane, и у портала тенанта: из Control Plane приглашение пользователю тенанта ведёт на портал тенанта |
SMTP_HOST, SMTP_PORT, SMTP_SECURITY, SMTP_USER, SMTP_PASSWORD, SMTP_FROM | Почтовый сервер установки: через него уходят коды и приглашения. SMTP_SECURITY — ssl (порт 465), starttls (587) или none (локальный релей) |
MAIL_LANGUAGE | Язык приглашений: ru или en. Письмо с кодом пишется на языке страницы входа |
SIGN_IN_MAX_SESSIONS | Сколько сессий одновременно может быть у одного человека; сверх этого новый вход завершает ту, которой дольше всех не пользовались. 0 — без ограничения, по умолчанию |
SIGN_IN_HISTORY_DAYS | Сколько дней хранится история авторизаций, по умолчанию 180 |
Без почты кода не получит никто
Без почтового сервера вход по коду не работает — страница входа сообщает, что письмо с кодом отправить не удалось, — новые пользователи не получают приглашений, а о входе с нового устройства никто не узнаёт. Обойтись без почты можно, только если все входят через провайдера.
Ключи входа — только на доменном имени
Браузер привязывает ключ к адресу сайта, поэтому ключи входа работают на доменном имени по HTTPS и не работают на IP-адресе. Ключ, сохранённый в Control Plane, к порталу тенанта не подходит — у каждого адреса свои ключи.
Запросы кода ограничены: не чаще раза в минуту и не больше пяти в час на адрес, двадцати в час с одного IP. Порталы раздаёт сам бекэнд, и браузер ходит к API по тому же адресу — отдельного сервера входа нет.