Процесс авторизации, который я пытаюсь определить, возможен:
https://app.example.com/
app.example.com
не имеет сеанса для пользователя, поэтому он отправляет их https://adfs.example.com
adfs.example.com
нет сеанса для пользователя adfs.example.com
действует как ИП и спрашивает https://notadfsidp.example.com
для аутентификацииnotadfsidp
так что отправляются обратно в adfs
как заверенные и в свою очередь app
как подтвержденоhttps://app.example.com
как подтвержденоСитуация:
У меня есть "портал", который использует CAS для аутентификации пользователей. Из-за обстоятельств, не зависящих от меня, сервер CAS захватывает учетные данные пользователя при входе в систему, чтобы их можно было использовать для единого входа в различные службы (это ключ в работе). Одна или несколько служб, для которых они могут использовать единый вход, поддерживаются локальным экземпляром ADFS. Таким образом, идеальная ситуация состоит в том, что, когда они переходят к одной из этих служб, сервер ADFS может узнать от сервера CAS, что они вошли в систему, и порталу не придется использовать их сохраненные учетные данные для аутентификации их с помощью ADFS.
Если описанный выше поток невозможен, можно ли отправить серверу ADFS какое-либо сообщение, в котором говорится, что пользователь прошел аутентификацию в другом месте, и они должны получить сеанс с сервером ADFS?
Примечание: мои познания в SAML очень ограничены, и у меня нет никаких знаний об администрировании сервера ADFS (это коллега).
Изменить № 1: мне нужно, чтобы аутентификация была прозрачной. Другими словами, после аутентификации пользователя на notadfsidp
любое посещение adfs
из app
не потребует от пользователя каких-либо действий.
На практике это работает с помощью Home Realm Discovery.
https://notadfsidp.example.com настроен как поставщик утверждений на https://adfs.example.com.
Когда пользователь переходит к https://app.example.com/ они перенаправлены на https://adfs.example.com, Затем они видят экран HRD, где выбирают https://notadfsidp.example.com как IDP. Они там проходят аутентификацию.
Поскольку приложение. доверяет adfs.example.com и доверяет notadfsidp.example.com, теперь пользователь аутентифицирован.
Во-первых, https://notadfsidp.example.com также должен быть сервером ADFS и он действует как IDP собственно в вашем сценарии.
Сервер ADFS https://adfs.example.com не будет автоматически запрашивать аутентификацию у другого сервера ADFS. Пользователи должны выбрать вручную IDP (или называемый поставщиком утверждений в мире ADFS) через функцию обнаружения домашней области, как показано ниже.
После завершения аутентификации токен пользователя будет кэширован в файлах cookie браузера и ADFS, чтобы пользователь получил возможность единого входа при повторном доступе к приложению.