Это отлично, гораздо лучше, чем плагин oauth2, который не работал. А этот работает (с Keycloak).
Однако поддержка нескольких источников OIDC была бы очень желательной функцией.
Это интересная идея. Расскажите, пожалуйста, подробнее о вашем случае использования, чтобы объяснить преимущества, и, если возможно, укажите, какие источники входа вы хотели бы использовать.
Отвечаю на вопрос из поста №2 выше: наш сценарий использования и какие источники входа нам необходимы.
Мы ведём публичное сообщество для исследовательской инициативы ЕС на хостинге Discourse в управляемом облаке внутри ЕС.
Нам необходимо одновременно активировать два провайдера OIDC:
- EU Login — провайдер идентификации Европейской комиссии. Им пользуются сотрудники Комиссии, заинтересованные стороны в области политики и участники проектов, финансируемых ЕС. Это стандартный OIDC, документ обнаружения доступен по адресу
https://ecas.ec.europa.eu/cas/oauth2/.well-known/openid-configuration. - EGI Check-in — федерированный академический прокси-сервер идентификации, который работает с учётными записями учреждений и ORCID. Он используется во всей европейской исследовательской инфраструктуре. Также это стандартный OIDC.
Ни один из этих провайдеров не покрывает пользователей другого. Сотрудник по политике входит через EU Login и не имеет академической исследовательской учётной записи. Исследователь входит через учётную запись университета или через ORCID через наш прокси и не имеет учётной записи EU Login. Наше сообщество состоит из обеих групп, поэтому выбор одного провайдера означает, что мы оттолкнём половину людей, для которых предназначен форум.
Оба провайдера используют обычный OIDC, и каждый из них работает самостоятельно. Проблема в том, что плагин discourse-openid-connect предоставляет только одно пространство имён настроек без нумерации: openid_connect_client_id, а не openid_connect_1_client_id и openid_connect_2_client_id. На одном сайте можно настроить только один провайдер OIDC.
Мы хотели бы видеть поддержку нескольких провайдеров. Наиболее естественным решением было бы пространство имён настроек для каждого провайдера, будь то нумерованные настройки или список, управляемый администратором, где у каждого провайдера были бы свой документ обнаружения, учётные данные клиента, область действия (scope) и название кнопки.
Ранее в 2021 году уже обсуждалась похожая проблема в теме Multiple openid-connect authentication providers, где потребовалось несколько областей Keycloak. Это то же самое ограничение, но в другой форме.
Мы готовы предоставить дополнительную информацию или протестировать реализации, если это поможет.
1 лайк
Один из вариантов — настроить сервис Authentik и “федерацию” с этими двумя провайдерами. Так вы сможете обеспечить внутренний SSO для своей команды и проксированный SSO для внешних пользователей. Это будет немного сложнее, учитывая необходимость хостинга собственного SSO, но, возможно, быстрее, чем патч OIDC-плагина, в зависимости от ваших ресурсов.
Тем не менее, я вижу настройки (Corporate Login Provider) повсюду в настройках Discourse, поэтому было бы действительно хорошо иметь возможность добавить свои. Может быть, стоит форкнуть OIDC-плагин и изменить названия?
4 лайка
Спасибо за подсказку. Сервис EGI Check-in уже является прокси-сервером IdP, позволяющим использовать множество IdP.
Текущее ограничение состоит в том, что политика EU Login не допускает использования прокси. Они требуют прямого подключения к сервису.
1 лайк
В этом случае, если другой сервис поддерживает Oauth2, вы можете настроить его с помощью Discourse OAuth2 Basic, чтобы сохранить OIDC для EU EIDAS. Раньше также был плагин SAML, возможно, он был устаревшим.
2 лайка
Спасибо за предложение. Действительно, в настоящее время мы изучаем возможность использования Discourse OAuth2 Basic вместе с EGI Check-in.
Я хотел обратить внимание сообщества на этот случай, так как поддержка нескольких OIDC-провайдеров, скорее всего, будет полезна большему числу организаций в будущем и упростит работу.
Вариант с SAML не рассматривался, но он может стать третьим вариантом, который стоит принять во внимание. Я нашёл плагин: GitHub - discourse/discourse-saml: Support for SAML in Discourse · GitHub
2 лайка