Это становится довольно распространенной проблемой, когда все больше сервисов переходят на OpenIdConnect, например. рабочий процесс SAML, работающий параллельно с проверкой подлинности Office365 OIDC. Ваш подход имеет смысл.
Как вы говорите, IdP должен преобразовать утверждения JWT OIDC в атрибуты SAML, которые должен использовать SP, и существуют различные варианты мостового соединения между SAML и OIDC.
Если вы хотите пойти по платному маршруту, у Overt есть мост Shibboleth / ADFS с облачным IdP .
Или вы можете установить 'стандартный' IdP и разработать свой собственный мост. По сути, он делегировал бы аутентификацию провайдеру OIDC и превратил бы заявки в SAML, возможно, дополненный поиском LDAP, чтобы получить больше атрибутов.
Или вы можете использовать «стандартный» IdP и установить apache и mod_auth_openidc перед ним для управления аутентификацией OIDC и обработкой заявок.
Что касается безопасности, пока вы можете доверять OIDC, вы должны быть в порядке. О доверии SAML уже позаботились метаданные SAML IdP / SP. Аутентификация будет обрабатываться OIDC, а заявки JWT будут отправляться на ваш SAML IdP, поэтому, пока вы защищаете маршрут между IdP и OIDC, он должен быть таким же безопасным, как и маршрут SAML.
В случае Office365 в качестве поставщика OIDC IdP необходимо будет зарегистрировать в качестве приложения-арендатора, а претензии будут отправлены на его replyUrl.