Несколько запросов авторизации в одном приложении Spring

Question

Мой вопрос в основном вращается вокруг того, возможно ли иметь две формы входа в систему с отдельными источниками аутентификации истины, представленные одному и тому же пользователю в приложении Spring.

Я хотел бы, чтобы в мою сборку Maven были добавлены различные классы конфигурации безопасности (или один и тот же класс со статическими классами внутренней конфигурации) в зависимости от того, какой профиль выбран: UAT или Production. Или управляйте этим с помощью среды развертывания (см. Ниже о фреймах).

В любом случае у приложения должна быть собственная подсказка аутентификации для "привилегированного" доступа (например, страниц администратора), и я хотел бы увидеть страницу входа в приложение для этого.

Тем не менее, в случае профиля UAT, я хотел бы видеть дополнительную страницу входа в систему, прежде чем любой пользователь сможет просмотреть любую страницу, а также страницу входа для функции администратора, если эти защищенные страницы доступны.

Идея состоит в том, чтобы показать приложение в UAT точно так же, как оно будет работать в производственной среде, но не позволяя любому пользователю видеть любую страницу без предварительной аутентификации с помощью отдельной формы входа.

Я готов рассмотреть любые идеи, но мой идеальный случай - позволить это с помощью различных наборов конфигурации Spring Security.

---

Что я пробовал / рассматривал

Динамический фильтр Мне посчастливилось реализовать эту идею, зарегистрировав динамический фильтр, который перехватывает любой запрос и пересылается сервлету, единственная цель которого состояла в том, чтобы обрабатывать показ другой страницы входа и обрабатывать внешнюю аутентификацию (все упаковано в банку, включенную в время сборки для UAT), но это не было приложением Spring, и я считаю, что сервлет отправки отрицает такой подход.

Фрейм (app-ception) Я рассмотрел идею отображения приложения во фрейме внешнего приложения "UAT Viewer", которое будет иметь свою собственную безопасность, теоретически сегментируя проблемы Spring Security. Но я не знаю, будет ли это создавать разные куки для внешнего и внутреннего приложения (я редко рассматриваю фреймы по соображениям безопасности). В идеале я хотел бы запретить все кадрирование в заголовке x-frame-options, чтобы помочь предотвратить подделку кликов, но если такой подход возможен, я был бы рад, если бы мне пришлось только изменить политику фреймов на тот же источник.

Я думаю, что сначала попробую фреймовый подход и доложу.

Подумав об этом, внутреннее приложение, которое будет представлено во фрейме, все равно должно быть доступно внешнему миру, чтобы клиент мог его загрузить, поэтому такой подход не позволяет изолировать внутреннее приложение с минимальным воздействием на его код.

Answer 1

Решение заключается в добавлении зависимости в отдельный проект (с профилем "UAT" в Maven), который предоставляет фильтр и сервлет, которые могут прерывать и обрабатывать аутентификацию вне обычного потока весенней безопасности.

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

@Override
public void configure(WebSecurity web) throws Exception {

    // Disabling security for the login-aspect addon. Will emit 404 in
    // production operation where login-aspect.jar is no added.
    web.ignoring().antMatchers("/uat-login");
}

Таким образом, у меня может быть фильтр, который перенаправляет любой запрос к приложению сначала на внешний сервлет аутентификации, который сопоставляется с '/uat-login' и отображает запрос на аутентификацию.

Дополнительным преимуществом (IMO) является то, что если активируется функция выхода из приложения и удаляется cookie сеанса, то он также эффективно выходит из внешней защиты.

Возможно, это не оптимальный метод, но он работает. Предложения по улучшению, безусловно, приветствуются. Я думаю, что позже опубликую код, используемый для этого, в проекте Github.