Какие готовые решения существуют?
Мне нужно такое которое будет опираться на дазу данных.
Что можете посоветовать?

SpringSecurity

SpringSecurity действительно очень удобный фреймворк.

тоже в скором времени надо будет курить данное направление, буду копать в сторону jaas. Советую почитать jaasbook.com 

Это сообщение отредактировал(а) garbuz - 30.12.2008, 16:49

какой сервер? технология (spring, ejb)?

powerOn, 
Мдя, деталей я никаких и не дал 

Планирую на: Tomcat и GlassFish.
EJB3.
Частично будет имплементированно на сервисах.

ShurikA, в Java EE5 Tutorial и документации к Glassfish достаточно хорошо описаны стандартные механизмы обеспечения безопасности. Попробуй сначала эту доку покапать.


Если имеется ввиду что информация о пользователях и группах должна лежать в твоей БД, то это также возможно стандартными средствами, путем конфигурирования своего realm-а (как на Tomcat, так и на Glassfish).


Если имеются ввиду веб-сервисы, то есть смысл посмотреть на Metro - там тоже по части безопасности много чего реализовано. Впрочем, если ты будешь использовать Glassfish, то Metro как раз и будет под рукой.

powerOn, 
Спасибо.

Имеет ли смысл копать в JAAS?

Добавлено через 11 минут и 57 секунд
И ещё вопрос:
На сколько сложно подкручивать это дело под разные Applications Servers?
На пример сильно ли большая разница между Tomcat  и Glassfish?

Если только realm настроить, то это чисто конфигурационная задача. Если раньше это делал, то несложно.

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

Как-то "нацарапал" в качестве упражнения JAAS LoginModule для Tomcat  с собственным механизмом аутентификации и авторизации в базе данных.
Полагаю, что это предпочтительный вариант, так как при этом:
 - принимая на себя механизм аутентификации вы его пишите один раз для разных приложений.
 - при переходе на другой сервер изменения (предполагаю) должны быть минимальны, даже и в части настройки.
 - JAAS все таки стандартный механизм и поэтому разработчики серверов не должны так уж сильно привиредничать с разнообразием настроек.
 - вам удается заставить сервер принимать ваши решения в части аутентификации и авторизации. (Это важно для дальнейшего использования декларативной авторизации, например в EJB).
 - механизм вы можете легко заменить заменив базу данных на LDAP сервер.

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

И часто вы сервера приложений меняете? Я вот в 4 проектах работал, где ни разу сервер не меняли. Как выбрали один раз, так продукт с ним и шел.

Не часто, естественно. Но все-же есть желание держать под контролем те аспекты, что выходят за рамки стандартов и трактуются каждым сервером по своему.

Дело даже не в том на сколько часто меняются сервера. А в том что желательно что бы аппликация поддерживалась несколькими серверами, для разных заказщиков.

Гм... ты используешь логику, которую нельзя реализоваться с помощью идущих в комплекте модулей? Или там в комплекте ничего нет?