Ответ 1

Существует несколько вариантов. Что выбрать, полностью зависит от вас. Просто объективно взвесьте конкретные преимущества и недостатки, которые соответствуют вашей собственной ситуации.

1. Использовать Java EE при условии управляемая контейнером аутентификация

Просто объявите <security-constraint> в web.xml, который относится к области безопасности, которая настроена в servletcontainer. Вы можете указать для своего веб-шаблона шаблон URL, который должен быть проверен для входа и/или роли (ов), например. /secured/*, /app/*, /private/* и т.д.

Перед Java EE 8 вам, к сожалению, все равно нужно настроить реальность безопасности в определенном сервлетах контейнере. Он обычно описывается в документации, связанной с сервлетой. В случае Tomcat 8, Realm HOW-TO. Например, база данных, основанная на таблицах пользователей/ролей, описана в разделе "JDBCRealm".

Начиная с Java EE 8, наконец, будет стандартный API, основанный на JSR-375.

Преимущества:

• Относительно быстро и легко настроить и использовать.
• Так как Java EE 8, наконец, имеет надежный и гибкий стандартный API.

Недостатки:

• Перед Java EE 8 конфигурация области специфична для контейнера. В Java EE 8 новый JSR-375 Security Spec должен решить это с помощью JASPIC.
• Перед Java EE 8 нет мелкозернистого элемента управления.
• До Java EE 8 он очень спартански; нет "помни меня", плохой обработки ошибок, ограничений на основе разрешений.

См. также:

• Выполнение аутентификации пользователя в Java EE/JSF с использованием j_security_check - содержит примеры кода.
• Java EE kickoff application - пример веб-приложения (разработанный мной), который также демонстрирует аутентификацию Java EE 8 с помощью Soteria (JSR-375 RI).

2. Homegrow a фильтр сервлета

Это позволяет использовать намного более мелкозернистый контроль, но вам нужно будет написать весь код самостоятельно, и вы должны действительно знать/понимать, как вы должны применять такой фильтр, чтобы избежать потенциальных явлений безопасности. В стороне JSF вы можете, например, просто поместить зарегистрированного пользователя в качестве атрибута сеанса на sessionMap.put("user", user) и проверить фильтр, если session.getAttribute("user") не null.

Преимущества:

• Четкое управление.
• Полностью независимый контейнер.

Недостатки:

• Ослабление колеса; новые функции требуют большого количества кода.
• В качестве стартера вы никогда не будете уверены, что ваш код на 100% устойчив.

См. также:

• Есть ли какой-либо простой способ для предварительной обработки и перенаправления запросов GET? - содержит описание объяснения и пример запуска для аутентификации
• Перенаправление авторизации по истечении срока действия сеанса не работает при отправке формы JSF, страница остается прежней - содержит более расширенный пример запуска для аутентификации, который также охватывает запросы ajax
• JSF: как управляющий доступ и права в JSF? - содержит пример запуска для авторизации

3. Адаптировать стороннюю структуру

Например, Apache Shiro, Spring Безопасность и т.д. Это обычно предлагает гораздо более мелкие конфигурации, чем стандартная аутентификация, управляемая контейнером, и вам не нужно писать какой-либо код для этого самостоятельно, ожидайте от страницы входа и некоторой (XML) конфигурации, конечно.

Преимущества:

• Четкое управление.
• Полностью независимый контейнер.
• Отсутствие переосмысления колеса; минимум собственного кода.
• Тщательно разработанный и проверенный множеством пользователей, поэтому, скорее всего, на 100% надежный.

Недостатки:

• Некоторая кривая обучения.

См. также:

• JSF2 - учебник Shiro - обширный учебник по интеграции Shiro в JSF2 webapp