Авторизация с использованием фильтров в Java EE

Question

У меня есть база mongodb с пользователями и паролями. У меня есть файл JSP с формой для авторизации. Фильтр должен быть проверен - авторизован пользователь или нет. Сервлет должен авторизовать пользователя, если он не авторизован.

Пожалуйста, приведите простые примеры того, как это сделать.

• как проверить авторизованного пользователя или не?
• Пользователь не авторизован. Предположим, пользователь находится в базе данных. Как это
  санкционировать

извините за плохой английский.

Answer 1

Вот сценарий: -

1. Пользователь заходит на защищенную страницу.
2. Фильтр перехватывает запрос пользователя.
3. Фильтр получает User объект из сеанса.
4. Если объект User существует, разрешить пользователю доступ к защищенной странице.
5. Если объект User не существует, перенаправить пользователя на страницу входа.

Когда пользователь отправляет учетные данные со страницы входа в систему: -

1. Система аутентифицирует пользователя, используя предоставленные учетные данные для базы данных.
2. Если аутентификация прошла успешно, система сохраняет User объектв сеансе и отображает страницу приветствия.
3. Если аутентификация не прошла успешно, система возвращает пользователя на страницу входа.

Answer 2

Реализации Java EE обычно позволяют настроить login modules. Они содержат реальный код для аутентификации на множестве разных систем. К ним относятся локальный файл XML, база данных, LDAP, Kerberos и множество других.

Вам не нужно писать их самим, они уже предоставлены для вас.

Ваш код только запускает аутентификацию (или объявляет ресурсы для защиты, а Java EE запускает аутентификацию для вас) и ничего не знает о действительном механизме аутентификации. Фактическая аутентификация обычно настраивается вне вашего кода. Некоторые реализации Java EE позволяют вам указать это в вашем EAR (например, через файл -service.xml в Jboss AS).

Потенциальным недостатком является то, что эти модули специфичны для вашей реализации Java EE (например, JBoss AS, Glassfish и т. Д.). Если вы настраиваете его вне своего кода, кто-то должен будет повторить это снова для каждого отдельного сервера приложений Java EE, на котором вы хотите запустить свой код.

Кроме того, способы, которыми Java автоматически запускает для вас аутентификацию (декларативную безопасность), довольно грубые. Чаще всего его запуск выполняется программно, поэтому вы лучше контролируете, как работает ваше окно входа и когда именно оно происходит.

Смотрите следующее, чтобы узнать, как это сделать: http://it -result.me / servlet-3-programmatic-authentication-api /

В качестве альтернативы, существует также способ, которым объясняет limc. Благодаря такому подходу вы полностью игнорируете API-интерфейсы, предлагаемые Java EE, и просто создаете свой собственный код, который обычно запрашивает БД и сохраняет некоторый объект в сеансе HTTP. Недостатком здесь является то, что ваш контекст безопасности не распространяется автоматически, и вы должны вручную передать этот объект или предоставить код, который должен проверять аутентификацию с доступом к сеансу HTTP.

Особенно для бизнес-бинов доступ к сеансу HTTP - плохая практика.

Наконец, Seam 3 обещает создать портативное расширение CDI для обеспечения безопасности, которое может оказать большую помощь, если / когда оно будет доступно.