Отвечаю на вопрос из поста №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. Это то же самое ограничение, но в другой форме.
Мы готовы предоставить дополнительную информацию или протестировать реализации, если это поможет.