Интеграция единого входа с приложением с собственной аутентификацией

Question

Мне было поручено интегрировать единый вход в существующее приложение, поэтому я работал над несколькими демонстрационными примерами.Первым было стандартное демо для Spring Security, и я заработал это.Сейчас я пытаюсь создать демонстрационную версию концепции, в которой я создал игрушечную версию рассматриваемого приложения только с двумя экранами: один для входа в систему и один для отображения некоторой информации о пользователе, который вошел в систему. Я хочуинтегрировать SSO с этим приложением, чтобы у пользователя было два способа аутентификации: либо путем ввода учетных данных непосредственно на экране входа в систему, либо с помощью запроса SSO SAML ...

Поэтому я скопировал библиотеки SAML и конфигурации изстандартная демонстрация SSO в моем приложении для проверки концепции, и мне кажется, что SSO работает, хотя и не очень хорошо, потому что я больше не могу добраться до своего экрана входа в систему, то есть я все еще хочу, чтобы это былоповедение по умолчанию для тех, кто вводит базовый URL для приложения.Как мне настроить приложение, чтобы добиться этого?

Answer 1

Я решил эту проблему, изменив конфигурацию Spring Security, чтобы вместо использования общего /**, требующего аутентификации SSO для большинства страниц приложения, теперь требуется только такая аутентификация для одной HTML-страницы sso.htm . Эта «страница» действительно транслируется приложением как запрос к контроллеру, который обрабатывает специфичную для приложения обработку запроса SSO. Начальная страница приложения, redirect.jsp , теперь содержит некоторую логику для выбора страницы, на которую следует перенаправить пользователя, в зависимости от того, попал ли он или она на эту страницу напрямую (т. Е. Введя URL-адрес по умолчанию для приложения) или через сообщение SAML от надежного поставщика удостоверений.

Примечание: Чтобы это работало, начальная страница не может быть обозначена в конфигурации Spring Security как защищенная или незащищенная страница. Если бы он был защищен, то к этой странице можно было получить доступ только после аутентификации SSO, поэтому пользователь был бы заблокирован от входа в систему без SSO. Если он не защищен, контекст безопасности не будет доступен с этой страницы, поэтому логика страницы не сможет определить, имеет ли данный пользователь учетные данные SAML, и запрос SSO-аутентификации для приложения никогда не будет выполнен.

После того, как пользователь прошел аутентификацию, либо с помощью учетных данных, введенных на экране входа в систему, либо по запросу SSO, с этого момента непрерывная аутентификация приложением этого пользователя для просмотра его страниц будет такой же, то есть не будет дополнительной аутентификации SSO готово. Но когда пользователь выходит из приложения (или выходит из-за истечения времени ожидания сеанса), выполняется проверка, чтобы проверить, была ли выполнена аутентификация SSO для этого пользователя. Если это так, то в дополнение к выходу из приложения для пользователя также выполняется локальный SSO-выход, то есть сеанс SSO-аутентификации для приложения завершается, но пользователь остается в системе со своим провайдером идентификации. Таким образом, такой пользователь может снова войти в рассматриваемое приложение, либо напрямую через экран входа в приложение, либо попросив провайдера идентификации выдать новое сообщение SAML.

Надеюсь, это поможет кому-то еще ...