Страница плагина аутентификации SAML здесь указывает, что «Аутентификация SAML доступна для планов хостинга Enterprise».
Означает ли это, что я не смогу использовать аутентификацию SAML в моей саморазмещаемой бесплатной версии Discourse? В идеале я хотел бы использовать аутентификацию Azure AD для моего экземпляра Discourse.
Вы можете его использовать. Плагин доступен по адресу GitHub - discourse/discourse-saml: Support for SAML in Discourse · GitHub.
Это сообщение относится к нашему хостингу. Это означает, что вы не можете использовать плагин SAML на стандартном или бизнес-тарифе.
Тем не менее, для Azure-AD вам, скорее всего, не понадобится SAML. Посмотрите Discourse OpenID Connect (OIDC) для более простой настройки. В конце есть специальные примечания для Azure-AD.
Значит, все плагины, перечисленные в каталоге плагинов, можно использовать на моем бесплатном экземпляре Discourse с самостоятельным хостингом?
Абсолютно верно! И существует гораздо больше #официальных плагинов, чем указано на сайте, которые вы можете свободно использовать. Обязательно также ознакомьтесь с #компонентом-темой.
Ещё раз спасибо за дополнительную информацию.
Итак, цель заключается в том, чтобы внутренние пользователи использовали Azure AD для аутентификации и регистрации, а внешние пользователи могли регистрироваться через локальную учётную запись или другие плагины регистрации учётных записей. Именно поэтому SAML был моей первой идеей.
Могу ли я ограничить плагин аутентификации OpenID Connect только Azure AD и применить это ограничение исключительно к внутренним пользователям?
OpenID Connect, как и SAML, являются «провайдерами аутентификации». Настроив один из них на вашем сайте, пользователи по умолчанию смогут выбрать вход локально или через провайдера аутентификации. Хорошим примером является Meta: у вас есть выбор между локальным входом, Facebook, Google, GitHub и т. д.
В вашем случае пользователи смогут выбрать между локальным входом и OpenID или между локальным входом и SAML. Вы можете выбрать любой вариант, который вам удобнее и проще настроить для вашей инфраструктуры.
Это можно сделать с помощью любого из плагинов, так как управление тем, кто может войти, осуществляется через Azure AD, а не через плагин, используемый для подключения к Azure.
Однако возможно ли скрыть эту возможность от внешних пользователей? Я не хочу, чтобы наши клиенты пытались войти в систему, полагая, что у них есть такая возможность через Azure AD.
А как насчёт отдельной страницы входа/регистрации, известной только внутренним пользователям, где единственным вариантом аутентификации будет Azure AD?
Вы можете скрыть ссылку для входа через CSS, тогда ни один пользователь её не увидит. После этого вы можете поделиться (или опубликовать на внутреннем сайте) прямой ссылкой на вход через OpenID или SAML для ваших внутренних пользователей. Поскольку пользователи не авторизованы при переходе на страницу входа, невозможно определить, являются ли они внутренними или нет.
Вы также можете изменить текст кнопки, чтобы избежать путаницы. Например, на изображении ниже мы подписали кнопку для «внутренних пользователей» как «Сотрудники Discourse». Если кто-то, не являющийся сотрудником Discourse, попытается её использовать, таковы правила:
Джoshua, я искренне благодарен за вашу оперативную и информативную помощь. Большое спасибо и берегите себя!
