Автоматически создавать учетные записи с внешним провайдером SSO? (пропустить запрос «Создать новую учетную запись»)

Я только что настроил экземпляр Discourse и добавил в него плагин discourse-openid-connect, подключив Keycloak в качестве провайдера OIDC.

После выполнения трёх условий, указанных здесь, в последней версии я наблюдаю следующее поведение: при аутентификации через Keycloak, если пользователь уже вошёл в систему, нажатие кнопки «Войти» приводит к предложению «Создать новую учётную запись», где поля заполняются данными из Keycloak о пользователе.

Есть ли способ пропустить этот шаг, требующий дополнительных действий от пользователя? Эти поля и так автоматически заполняются данными из Keycloak, поэтому нет необходимости заставлять пользователя их изменять специально для Discourse.

Создание учётной записи должно происходить неявно, аналогично тому, как это реализовано в Grafana? Моя цель — чтобы каждый сервис, предоставляемый сообществом, поддерживал такой бесшовный опыт: пользователю достаточно иметь только одну учётную запись сообщества, с которой он зарегистрировался.

Это может показаться нелогичным, если рассматривать внешние методы аутентификации, такие как Google, Facebook, GitHub и т. д. Пользователь может зарегистрировать учётную запись сообщества через Keycloak, используя один из этих провайдеров, но сам Keycloak, который используется только внутри организации, должен работать со всеми отдельными сервисами. Поэтому неявное/автоматическое согласие и регистрация являются желательными.

Новичок в Discourse, у меня настроен и работает провайдер SSO OAuth2. Новые пользователи видят запрос при первом входе и аутентификации в Discourse. Как я могу упростить этот процесс и автоматически создавать учетные записи пользователей? Значения, отображаемые на этом экране, верны и нужны только один раз. Что я могу сделать, чтобы убрать этот экран и упростить процесс создания учетных записей для пользователей моего сообщества?

В настоящее время это невозможно. При первой регистрации пользователям необходимо нажать кнопку «Создать новую учётную запись» на форме регистрации.

Поведение, которое вы ищете, аналогично тому, как работает реализация SSO в Discourse. В этом случае учётные записи создаются в фоновом режиме без заполнения пользователем формы регистрации. Похоже, что реализовать аналогичный функционал для входов через OAuth2 должно быть возможно, однако могут быть случаи, когда провайдер OAuth2 передаёт недостаточно информации для создания учётной записи.

Я не уделял этому много времени после своего поста здесь, но в итоге использовал функцию SSO для Discourse через сервис-мост, который я нашёл для OpenID-Connect. Это был Python-сервис с Docker-контейнером, что упростило развёртывание в моём окружении с docker-compose.

Таким образом, Keycloak предоставлял уже зарегистрированную и авторизованную учётную запись, а при посещении Discourse пользователь автоматически регистрировался с данными, полученными через мост (если я правильно помню). Прошло довольно много времени с тех пор, как я с этим работал, но это было несколько более удобной процедурой, чем поддержка OAuth/OpenID-Connect в Discourse (по крайней мере, на тот момент; не проверял, были ли внесены улучшения).

В любом случае, синхронизация данных учётной записи происходит не так, как ожидается. Пользователю нужно выйти из Discourse и войти снова, чтобы синхронизация произошла, и даже тогда, насколько я помню, некоторые данные (например, группы/роли) не синхронизировались из-за определённых нюансов.

Чтобы обеспечить правильную синхронизацию, нужно отслеживать обновления данных пользователя у провайдера и инициировать обновление в Discourse через его API. В противном случае могут возникнуть дублирующиеся данные, которые не синхронизированы, или запутанная синхронизация для пользователей.


Так что, если текущая интеграция OAuth2 SSO, которую вы используете, — это не функция SSO для Discourse (которая, насколько я знаю, обычно требует SSO-моста), а альтернативный плагин, то переход на версию без плагина с использованием SSO-моста, вероятно, даст тот желаемый опыт, о котором вы говорите (если я правильно помню).

Меня также интересует возможность избежать появления окна «Создать новую учётную запись» при использовании OAuth2.
Может быть, где-то можно добавить опцию для его пропуска, если все поля уже заполнены?

Я только что добавил новые настройки сайта, которые помогут решить эту проблему. Чтобы пропустить экран «Создать новую учётную запись», включите sso_overrides_username, sso_overrides_email и sso_overrides_name.

Затем, чтобы полностью пропустить всплывающее окно, включите external_auth_skip_create_confirm.

Если вы не видите эту опцию, убедитесь, что у вас установлена последняя версия с тестами passed.

external_auth_skip_create_confirm включен

У нас возникла проблема:

  1. В нашем Discourse уже существует учётная запись test__EMAIL__
  2. Если я вхожу через OpenID с именем пользователя: test и адресом электронной почты: test__EMAIL__,
    появляется окно «Новая учётная запись», предлагающее новое имя пользователя test1 и тот же адрес электронной почты test__EMAIL__.

При этом нет возможности связать старую учётную запись с OpenID.

Проверяет ли ваш провайдер OpenID Connect адреса электронной почты пользователей? Мы можем «доверять» электронной почте из OIDC только в том случае, если она была проверена и соответствующий булевый флаг установлен правильно.

Нет OID-провайдера — Keycloak с федерацией пользователей LDAP
Мы нашли решение: старый пользователь может подключиться через OpenID в интерфейсе настроек пользователя

@david у нас версия 2.5.2 stable — этой опции нет… Можно ли перенести эту опцию в ветку stable? Она нам нужна, но в продакшене мы используем только стабильную ветку…

К сожалению, нет, мы не переносим новые функции в стабильную ветку. Следите за каналом #releases, чтобы узнать, когда будет выпущена следующая стабильная версия.

@david
Не совсем ясно, о чём идёт речь в следующей стабильной версии… Минорная версия 2.5.3? Или версия 2.6.0?

Следующая основная версия будет 2.6.0. Минорные версии (2.5.x) будут выпускаться только для исправления уязвимостей безопасности.

@david
Спасибо! Теперь всё понятно. Будет ли версия 2.6.0 выпущена в этом году или нет? )))

У нас пока нет подтверждённой даты, но да, есть хорошие шансы, что это произойдёт в этом году :slight_smile: