Переход «Милы» на единую систему авторизации!


С прошлого поста прошло довольно-таки много времени… Я бы поздравил всех с праздниками, но сделал это лично, каждому другу и подруге в ЛС. В этом посте буду немногословен, но должен предупредить пользователей панели Мила о том, что в конце января наступят изменения, описанные в этом посте. Итак, давайте приступим!

Но сначала кратко расскажу о том, что от вас требуется. Это не сложно и касается лишь пользователей панели, так что пост можно продолжить читать без этого, если хочется более развёрнутого описания.

Что требуется от владельцев серверов:

Теперь, с 31-го января вступает в работу единая авторизация через Mlado.ru или подтверждение входа кодом, но как минимум одна из этих мер должна присутствовать.

  • Это не должно вызвать затруднений, так как новая система тоже использует логин и пароль.
  • Помимо этого, в ней есть возможность подключать внешнюю авторизацию через ключи безопасности (т.к. Yubikey), системы хранения аккаунтов (Bitwarden, 1Password) и прочих поставщиков passkey-систем.
  • Я прошу не пугаться новых мер, так как даже двухфакторку можно легко настроить на вашу почту. Не нужно ничего устанавливать, не нужно привязывать смартфон и производить прочие физические манипуляции.

  • Зайдите в свой аккаунт Mila;
  • Перейдите в профиль.
  • Нам нужна вкладка OAuth, нажмите на ‘Link MLADO’.
  • Зарегистрируйтесь в нём через почту и пароль, подтвердите вход кодом, отправленным этой же системой через email.

  • Зайдите в свой профиль.
  • Перейдите во вкладку 2FA.
  • Если вы подключаете почту, вам достаточно ввести код из письма, отправленного панелью.
  • Если вы подключаете внешнюю систему 2FA, вам достаточно отсканировать QR-код в вашем приложении для одноразовых кодов.

О том, что произойдёт с системой авторизации, её история и технические подробности.

  • Это изменение больше служит цели не городить кучу аккаунтов, а собрать их в одном месте, нежели улучшить безопасность сервисов.
  • С ростом пользователей панели появились проблемы:
    • пароль может не подходить по соображениям безопасности,
    • от админов не требовалось дополнительное1 подтверждение входа,
    • для каждого сервиса требовался отдельный аккаунт,
    • а при входе в один сервис, можно было получить доступ к другому 2.
  • Так как полу-закрытых сервисов стало больше, возникла проблема с управлением аккаунтами меж ними.
  • Обычно, крупные компании используют собственные системы аккаунтов, называемые в техническом кругу системами «Единого Входа«.
  • Они пошли от определённых стандартов, например OpenID, OAuth, LDAP, что вместе входят в один термин — SSO, синонимом и дословным переводом «Единого Входа», происходящим от Англ. «Single Sign-On«.
  • На моих сервисах тоже издавна существовала подобная система. Сначала она была довольно неуклюжа, работала на софте, что имел совсем иное назначение, но позволял привязывать к нему аутентификацию.
  • Позже сервисы мигрировали на систему «Casdoor«, что не была полностью совместима, не имела интеграции с веб-страницами3 и во многом полагалась на внешние системы.
  • Сейчас же, система унифицирована и единственное, что находится вне основной системы, это логотип на внешнем CDN (Спасибо, Лостя! ^^).

Сноски
  1. (код на почту или смартфон) ↩︎
  2. (например система оркестрирования, использующая Gitea для входа, что давала доступ через Github) ↩︎
  3. В данном случае я ссылаюсь на ограничение просмотра страниц с помощью интеграции OIDC-поставщика в reverse-proxy, как поля auth_request для Nginx. ↩︎


Добавить комментарий