j2ee webapp A с помощью средства аутентификации веб-приложения B

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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