Назад | Перейти на главную страницу

ADFS idP, который сначала проверяет с другим idP?

Процесс авторизации, который я пытаюсь определить, возможен:

  1. Пользователь переходит к https://app.example.com/
  2. app.example.com не имеет сеанса для пользователя, поэтому он отправляет их https://adfs.example.com
  3. adfs.example.com нет сеанса для пользователя
    • у пользователя нет сеанса
      1. adfs.example.com действует как ИП и спрашивает https://notadfsidp.example.com для аутентификации
      2. у пользователя есть сеанс с 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, чтобы пользователь получил возможность единого входа при повторном доступе к приложению.