JSF: Аутентификация и авторизация, лучший способ продвижения вперед
Я провел весь день в гугле и просматривал здесь различные вопросы, пытаясь найти лучшее решение для реализации аутентификации и авторизации. Я придумал часть решения сейчас, но надеюсь, что кто-то может заполнить пробелы. Я понимаю, что ниже много текста, но, пожалуйста, потерпите меня :O)
Исходная информация
Я унаследовал частично завершенное приложение CRM, которое в настоящее время использует JSF 2.0, JavaEE 6, JPA и базу данных PostgreSQL. К сожалению, ребята, которые изначально начали создавать это веб-приложение, в своей бесконечной мудрости решили, что лучше всего будет оставить аутентификацию/авторизацию на конец - теперь я должен это сделать.
Приложение по существу разделено на три уровня — представления, управляемые компоненты и DAO. Это означает, что управляемые компоненты являются особенно «толстыми», поскольку они содержат всю бизнес-логику, логику проверки и навигации.
Требования к аутентификации/авторизации
- Аутентификация на основе форм, проверка учетных данных, хранящихся в базе данных PostgreSQL.
- Единственной общедоступной страницей (для анонимных пользователей) будет страница входа.
- Мне нужно запретить доступ к определенным областям приложения в зависимости от роли пользователя. Например, только пользователи с ролью «Администратор» должны иметь доступ к странице создания/редактирования пользователя.
- Мне также нужно иметь возможность ограничить доступ к определенным областям страницы. Например, пользователь с ролью «Торговый представитель» должен иметь возможность просматривать сведения о клиентах, но кнопка «Сохранить/изменить» должна отображаться только в том случае, если у пользователя есть роль «Обслуживание клиентов».
Где я нахожусь
Первое, что я планирую сделать, это следовать этому примеру Аутентификации и авторизации пользователя с использованием JAAS и Servlet 3.0. Я считаю, что это выполнит мои первые 3 требования.
Чтобы показать/скрыть кнопки сохранения и т. д. на страницах, я могу использовать технику, описанную в этом SO-ответе. Это частично решит требование 4, однако я думаю, что мне все еще нужно защитить методы действий и/или сами управляемые компоненты.Например, я хотел бы иметь возможность добавить аннотацию или что-то еще к методу save() в клиентском компоненте, чтобы гарантировать, что его могут вызывать только пользователи с ролью «Обслуживание клиентов» — здесь я начинаю сталкиваться с проблемами. .
Я думаю, что одним из вариантов было бы сделать что-то похожее на то, что я предлагаю сделать в представлении, и использовать FaceContext для проверки того, находится ли текущий пользователь в роли. Мне это не нравится, так как это просто загромождает мой код и вместо этого я предпочел бы использовать аннотации. Однако, если бы я пошел по этому пути, как бы я вернул статус http 403?
Аннотации javax.annotation.security.* кажутся подходящими для декларативного определения доступа к областям приложения, однако, насколько я понимаю, их можно добавлять только в EJB. Это означало бы, что мне нужно было бы перенести всю мою бизнес-логику из управляемых компонентов, где она в настоящее время находится, в новые EJB. Я думаю, что это имело бы дополнительное преимущество, заключающееся в разделении бизнес-логики на собственный набор классов (делегатов, служб или того, что вы решите их назвать). Однако это будет довольно большой рефакторинг, которому не поможет отсутствие модульного тестирования или интеграционных тестов. Я не уверен, что ответственность за контроль доступа должна быть возложена и на этот новый уровень обслуживания - я думаю, что это должно быть на управляемых компонентах.
Другие альтернативы
Во время моего исследования я нашел много людей, упоминающих такие фреймворки, как Spring и Seam.У меня есть некоторый ограниченный опыт работы с Seam, я думаю, что это было бы хорошо для этого проекта, и, насколько я помню, я считаю, что он решает проблемы с авторизацией, которые у меня есть, но я думаю, что уже слишком поздно, чтобы представить его сейчас .
Я также видел упоминание Широ в разных местах. Глядя на 10-минутный туториал, он показался мне подходящим,особенно в сочетании с taglib Deluan Quintao, но мне не удалось найти никаких руководств или примеров того, как интегрировать его с веб-приложением JSF.
Другая альтернатива, с которой я сталкивался на удивление регулярно, — это реализация пользовательского решения — мне это кажется безумием!
Резюме
Подводя итог, мне бы очень хотелось узнать, правильно ли я иду по пути реализации аутентификации и авторизации, и как восполнить недостающую часть защиты отдельных методов и/или управляемые компоненты (или, по крайней мере, код, которому они делегируют) и/или как я могу вручную вернуть HTTP-статус 403.