У нас настроен экземпляр ADFS 2.0. Мы используем его для единого входа в сторонние веб-приложения. Все прекрасно работает с существующим приложением App1 с SAML 2.0, включая сквозную передачу IWA, когда пользователи перенаправляются на наш сервер ADFS.
Я только что настроил второе доверие проверяющей стороны для другого приложения, App2, с помощью SAML 2.0. Мы используем все настройки ADFS по умолчанию, включая конечные точки. На странице конфигурации SAML этого приложения я сказал ему, что наша конечная точка SAML "https://adfs.mydomain.com/adfs/ls/". Все работает нормально, за исключением того, что пользователям предлагается ввести учетные данные; ADFS не использует IWA для этих учетных записей.
Я тестирую с локальной рабочей станции, присоединенной к домену, с использованием IE9. Внутренний DNS указывает на наш локальный сервер ADFS, присоединенный к домену, внешний DNS указывает на наш прокси ADFS DMZ. "* .mydomain.com" находится в зоне надежных сайтов в IE посредством GPO и применяется. IWA включен в IE. IE очищает свой кеш / файлы cookie / историю каждый раз, когда я его закрываю. Оба приложения используют вход в систему, инициированный SP, и оба отправляют свои утверждения на один и тот же URL-адрес конечной точки на нашей стороне.
Если я попытаюсь войти в App2 в чистом сеансе, мне откроется страница входа в ADFS. Если я ввожу учетные данные, я вхожу в приложение и могу продолжить.
Если я пытаюсь войти в App1 в чистом сеансе, я немедленно перенаправляюсь в ADFS, IWA проходит, и я вхожу в приложение и могу продолжить.
Если я пытаюсь войти в App2 в том же сеансе после входа в App1, я перенаправляюсь в ADFS, используется существующий сеанс входа в систему ADFS, инициированный App1, а затем я немедленно перенаправляюсь на URL-адрес службы утверждения App2 и выдается страница с ошибкой.
Я думаю, что мне чего-то не хватает в конфигурации RPT. Все, что мне предоставил поставщик услуг, - это URL-адрес конечной точки службы потребителей с использованием привязки POST. Пришлось угадывать правила претензий. SP не использует шифрование.
App2 Обслуживание клиентов было ... трудным. Их техническая поддержка находится за границей, поэтому я получаю ответы только один раз в день около полуночи по местному времени. Большинство их ответов являются стандартными «копировать и вставлять из базы знаний». Они предпочитают вход в систему, инициированный IdP, но говорят, что поддерживают инициированный SP - что кажется правдой, поскольку SSO действительно работает в чистом сеансе после входа в систему на странице входа ADFS.
Кто-нибудь знает, что мне не хватает?
Метод аутентификации можно настроить и запросить. Те же идентификаторы используются в SAML и WS-Fed.
Запрошенный в WS-Fed переходит в whr =, а в SAML - в класс контекста аутентификации. В SAML можно указать «Сравнение» (точное, минимальное и т. Д., Но тогда вы должны согласовать порядок). ADFS (в настоящий момент) не обращает внимания на атрибут сравнения.
Часто политики могут быть определены для использования определенных уровней для конкретных приложений (RP / SP). Иногда его можно настроить по-разному в зависимости от адреса источника и т. Д.