j2ee webapp A с использованием средства проверки подлинности веб-приложения B

Question

Любой пользователь, который пытается получить доступ к некоторым защищенным ресурсам в моем веб-приложении A, должен быть аутентифицирован с помощью webapp B. B имеет доступ к паролю учетных данных пользователя и т. Д., Мне интересно правильный путь для этого.

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

B регистрирует пользователя в и перенаправляет браузер на защищенную страницу на сервера, вместе с идентификатором сессии некоторых Б и некоторые лексемы indicatng, что пользователь зарегистрирован в системе.

Фильтр улавливает редирект из B на A, извлекает информацию токена аутентификации из заголовка ответа B и регистрирует пользователя в сеансе A.

Все последующие запросы от браузера передают токен, который B установил. Фильтр видит этот токен и считает, что пользователь вошел в систему.

Это звучит здорово или я пропускаю большие вещи?

Также является ли сервлетфильтр лучшим способом для достижения этого потока? Как насчет декларативной безопасности в web.xml? Как я могу выполнить один и тот же поток с использованием декларативной безопасности?

Answer 1

Чтобы предлагаемая схема работала, вам необходимо настроить контейнер для совместного использования сеансов в веб-приложениях. Это не доступно во всех контейнерах, если я не ошибаюсь, и этапы настройки отличаются от одного контейнера к другому. При отсутствии совместного сеанса веб-приложение B просто не распознает сеанс, созданный приложением A. WebLogic Server разрешает совместное использование сеанса; другие могут с разным успехом.

Возможно, вы сможете достичь этой схемы (после сеансов обмена через приложения) с помощью декларативной безопасности в веб-приложении B - форма входа в систему B будет иметь логику для перенаправления пользователя в приложение A, где он будет аутентифицирован. Излишне говорить, что я не пробовал это. Одна вещь, которую следует учитывать при использовании общих сеансов, заключается в том, распространяются ли принципы или становятся доступными для второго приложения с первого.

Answer 2

Спасибо за ваш ответ, Vineet. Возможно, я не был чист, позвольте мне перефразировать его: A - это веб-приложение, которое не имеет доступа к имени пользователя. B - это веб-приложение, которое имеет доступ к имени пользователя. . Страница входа в систему работает на B, просто перенаправляется на Это.

Они оба живут в том же домене, но не могут обмениваться сеансами и т. Д., Для всех практических целей они являются полностью отдельными приложениями.

A хочет использовать доступ B к имени пользователя/паролю и создавать учетные данные для пользователя.

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

Я понимаю, что вход в систему с B будет создавать аутентифицированный сеанс в B и что этот сеанс не имеет ничего общего с A. Что A пытается сделать, так это: вместо прямого доступа к учетным данным пользователя он позволяет B сделайте это и, используя это ya или nea из B, создайте аутентифицированный сеанс. После всего, что такое аутентифицированный сеанс - просто сеанс с информацией пользователя в нем правильно?

Мне также интересно узнать о «утверждении личности» и о том, как это может быть связано с этим ...