В нашей текущей конфигурации работает поставщик услуг Shibboleth, реализующий единый вход с несколькими внешними IdP SAML. Мы планируем создать нового поставщика удостоверений на основе IdentityServer4, который будет работать с поставщиками OID C, а также поддерживать устаревшие поставщики SAML. Представление нового IdP потребовало бы отправки наших метаданных с обновленными доменными именами существующим партнерам SAML, что крайне нежелательно с точки зрения бизнеса. Чтобы обойти обмен метаданными при переходе на новый IdP, я думал о том, чтобы представить промежуточного провайдера идентификации Shibboleth, находящегося на устаревшем сервере, который мог бы общаться с существующим провайдером услуг Shibboleth.
Вот как я думаю, это будет работать. Пользователь пытается войти в систему с помощью нового поставщика удостоверений. Браузер перенаправляет на промежуточный IdP на устаревшем сервере, который, в свою очередь, перенаправляет на IdP партнера. Когда пользователь входит в IdP партнера, он перенаправляет обратно к конечной точке подтверждения устаревшего сервера в соответствии с существующими метаданными. Устаревший сервер наконец перенаправляет обратно к новому провайдеру идентификации. По сути, пользователь делает дополнительный переход на пути от моего нового IdP к партнеру SAML IdP и обратно.
Я не смог найти ничего, описывающего этот сценарий единого входа и способ настройки Shibboleth. Будет ли этот сценарий иметь смысл вообще? Любые идеи будут оценены.