Я включил SSO на корпоративном сайте Discourse, что позволяет внешним пользователям из нашего приложения входить в систему. Однако некоторым сотрудникам с корпоративными адресами электронной почты необходим доступ в качестве модераторов или администраторов. Поскольку эти сотрудники не зарегистрированы в приложении, мы не можем создать для них учетные записи SSO.
Существует ли встроенное решение для раздельной обработки их входа, чтобы они могли аутентифицироваться с помощью своей корпоративной почты, даже если для внешних пользователей включен SSO?
Но, насколько я знаю, это работает только для администраторов, верно? Я хочу реализовать вход для сотрудников и модераторов, то есть пользователей с повышенными правами, но не администраторов.
Если я правильно понял, то вы не можете использовать SSO. Первая буква «S» означает «единый». Думаю, вам придется использовать несколько входов через OAuth2.
Почему ваши администраторы не могут использовать вашу систему аутентификации?
У меня нет решения, но, кажется, я помню, что эта точная проблема уже возникала несколько раз в прошлом. Жаль, что вы не можете назначить пользователей модераторами и предоставить им доступ к сайту через маршрут /u/admin-login.
Если это имеет значение, какой метод SSO вы используете? Это DiscourseConnect, OAuth2 или OpenID Connect?
Мы хотим, чтобы наши администраторы, сотрудники и модераторы использовали корпоративную почту для входа в систему. Однако наш текущий механизм единого входа (SSO) основан на аутентификации через SMS-код (OTP) по номеру телефона, при этом пользователь должен быть зарегистрирован в нашем приложении с использованием своего адреса электронной почты, что для этих пользователей нецелесообразно.
Хотя мы могли бы реализовать кастомную логику для включения в белый список определенных адресов электронной почты в рамках SSO, мы рассматриваем более готовое решение. Например, если бы SSO мог сосуществовать с локальным входом, мы могли бы отключить локальный вход для обычных пользователей, но разрешить администраторам и внешним пользователям входить в систему с помощью адреса электронной почты и пароля. К сожалению, я не считаю, что SSO и локальный вход могут сосуществовать таким образом.
Это верно. Когда включен DiscourseConnect, пользователи могут входить в систему только через сайт провайдера аутентификации DiscourseConnect.
У меня была идея, что маршрут /u/admin-login работает для всего персонала (администраторов и модераторов), но сейчас, глядя на это, я вижу, что он позволяет только администраторам обходить вход через DiscourseConnect. Возможно, можно разработать плагин, который позволит членам пользовательской группы входить в систему с помощью метода admin-login, но, вероятно, лучше найти способ подключить внешних пользователей к вашему сайту аутентификации SSO.
Звучит правильно. Лучшее решение — обеспечить работу вашего SSO. Не очень логично, что для ваших сотрудников SSO «невозможно» настроить, но, возможно, именно поэтому я работаю сам. (Но ваши сотрудники не используют ваше приложение? Если используют, то добавить их электронные адреса через API должно быть довольно просто).
Но именно люди, принимающие плохие решения, обеспечивают мне работу! Когда я не убеждаю людей использовать существующие функции, мне нравится заставлять Discourse делать то, для чего он не предназначен (например, устанавливать Discourse).
Я с радостью разработаю или помогу вам разработать плагин, который позволит маршруту /u/admin-login (или другому) работать для членов вашей групповой команды (которая автоматически включает пользователей с корпоративной почтой), а также создам страницу, где они смогут ввести свой email и получить ссылку для входа.
Возможно, это даже могло бы автоматически перенаправлять анонимных пользователей вашей VPN на страницу входа или делать что-то ещё, чтобы процесс был более бесшовным для ваших сотрудников.
(Но ваши сотрудники не используют ваше приложение? Если используют, то добавить их электронные адреса через API должно быть довольно просто).