Я только что настроил Shibboleth IdP3.2 со своим веб-приложением, которое аутентифицирует пользователей на сервере LDAP в бэкэнде.
Я мог протестировать этот процесс аутентификации на локальном компьютере. Но, развертывая код на CI-сервере, я понял, что процесс аутентификации не может быть завершен успешно.
Причина этого сбоя в том, что поставщик услуг (SP) не может получить доступ к (IdP). Исходя из нашего первоначального исследования, мы выбрали SAML в качестве протокола аутентификации по сравнению с другими протоколами, такими как CAS, потому что он не нуждался в обмене данными по обратному каналу. Пока пользователь имеет доступ как к SP, так и к IdP, процесс аутентификации будет работать (SP и IdP не должны взаимодействовать друг с другом).
При тестировании мы обнаружили, что разрешение атрибута прошло успешно, но последующее разрешение артефакта не удалось. При разрешении артефактов IdP напрямую связывается с SP и ожидает ответа. SP не может отправить ответ IdP, так как он недоступен. Следовательно, аутентификация не выполняется. (Журналы Tomcat показывают: unknownHostException)
Некоторые потоки SAML в системе единого входа в веб-браузере не требуют прямого взаимодействия между SP и IdP, как видно из блок-схемы в этом ссылка.
Предусматривает ли Shibboleth IdP такое внедрение? Есть ли способ реализовать Shibboleth IdP без обратной связи?
РЕШЕНИЕ:
Как упомянул Стефан, существуют альтернативные привязки, такие как HTTP-Redirect и HTTP-POST, которые не используют обмен данными по обратному каналу. Подробнее об этих привязках можно узнать на "здесь" rel_czCvugVD1v2
Я изменил метаданные SP, чтобы сделать HTTP-POST привязкой по умолчанию, сославшись на это ссылка.
Мне не нужно было вносить какие-либо изменения в конфигурацию Shibboleth IdP, поскольку эти альтернативные привязки уже поддерживались, что подтверждается файлом метаданных.
