Добавление пользовательской контекстной информации в вызовы методов EJB

Question

Я хочу передать информацию об аутентификации в EJB-сеансные компоненты без сохранения состояния при вызове их методов из веб-приложения Java (Wicket). Информация состоит из идентификатора пользователя и типа аутентификации (запомните cookie или пользователя / пароль) и хранится в сеансе http. Одно очевидное решение - добавить это как параметр ко всем методам EJB, но это громоздко, и я надеюсь, что существует другое решение.

Поиск JNDI-компонентов EJB выполняется через javax.naming.InitialContext # lookup (String) на веб-уровне.

Существует ли переносимый способ добавления аутентификационной информации в вызывающий контекст, чтобы она стала доступна бинам? Мне нужно, чтобы этот процесс был доступен для вызывающих абонентов как на уровне EJB (для конечной точки веб-службы), так и на веб-уровне.

Дополнительная информация

Я использую Java EE 6. CDI не используется, и я бы предпочел избежать его реализации.

Аутентификация обрабатывается веб-уровнем с компонентами без сохранения состояния, проверяющими запоминаемые cookie-файлы и комбинации пользователя и пароля. Когда посетитель впервые заходит на сайт, выполняется проверка подлинности с помощью файла cookie cookie. Когда в конечном счете требуется, пользователя просят войти с именем пользователя и паролем. Как упоминалось выше, статус аутентификации сохраняется в сеансе http. Я не использую модель безопасности Java EE, основанную на сферах, потому что я не мог понять, как этот поток аутентификации мог бы быть должным образом интегрирован.

Схема авторизации основана на динамических ролях, аналогично тому, как Facebook определяет авторизацию на основе связи между двумя пользователями и некоторыми предпочтениями. Некоторые действия также принимают во внимание тип аутентификации. Например, изменение настроек учетной записи требует пользователя / пароля, а cookie недостаточно. Из того, что я понял, стандартные группы и роли Java EE не подходят для этого требования.

Другие похожие вопросы, которые я нашел

EJB3 & Как субъект / принципал JAAS распространяется на уровень EJB из контейнера сервлета?

Управление принципом безопасности, передаваемым по вызову EJB

Связывание сущности пользователя и принципала GlassFish

Доступ к клиентскому принципалу в методе ejb

динамические роли на сервере Java EE

Надеюсь, мой вопрос достаточно ясен. Если потребуется дополнительная информация, я с удовольствием предоставлю ее.

редактировать

Исправлены ссылки. Добавить примечание о CDI.

Answer 1

Я думаю, вы должны рассмотреть:

1. Создание перехватчика для процесса авторизации. Это даст вам общее место для авторизации, несмотря на то, с какого уровня был сделан вызов. Вы можете проверить, разрешено ли вызывающей стороне вызывать метод или его сеанс все еще активен (то есть проверьте его в БД).

2. В перехватчике вы можете передать некоторые пользовательские данные, используя InvocationContext#getContextData().put("user-related-data-name", someObj). В вызывающем EJB вы можете получить эти данные, используя SessionContext#getContextData().

Пример передачи контекстных данных с использованием SessionContext можно найти здесь

Последняя (и самая интересная часть) будет о том, как получить учетные данные пользователя на уровне EJB. Если вы говорите о конечной точке WebServices, то я предполагаю, что вам нужно предоставить какой-то граничный класс или указать методы, которые будут принимать некий sessionId для каждого вызова.

Если речь идет о распространении HttpSession данных из сервлета в EJB ... Это может быть далеко, но я бы подумал об использовании CDI. Ваш сервлет может использовать бин @SessionScoped, содержащий учетные данные пользователя, и вы вводите тот же боб @SessionScoped в перехватчик.

Я не уверен, возможно ли это вообще (внедрение компонентов CDI в перехватчики или совместное использование @SessionScoped между слоями сервлетов и EJB).