| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java EE (J2EE) и Spring > Authorization & Authentication |
| Автор: ShurikA 30.12.2008, 11:34 |
| Какие готовые решения существуют? Мне нужно такое которое будет опираться на дазу данных. Что можете посоветовать? |
| Автор: Asal 30.12.2008, 11:47 |
| SpringSecurity |
| Автор: Llucas 30.12.2008, 13:37 |
| SpringSecurity действительно очень удобный фреймворк. |
| Автор: garbuz 30.12.2008, 14:03 |
| тоже в скором времени надо будет курить данное направление, буду копать в сторону jaas. Советую почитать jaasbook.com |
| Автор: powerOn 30.12.2008, 14:23 |
| какой сервер? технология (spring, ejb)? |
| Автор: ShurikA 30.12.2008, 22:37 |
| powerOn, Мдя, деталей я никаких и не дал Планирую на: Tomcat и GlassFish. EJB3. Частично будет имплементированно на сервисах. |
| Автор: powerOn 30.12.2008, 23:46 |
| ShurikA, в Java EE5 Tutorial и документации к Glassfish достаточно хорошо описаны стандартные механизмы обеспечения безопасности. Попробуй сначала эту доку покапать. Если имеется ввиду что информация о пользователях и группах должна лежать в твоей БД, то это также возможно стандартными средствами, путем конфигурирования своего realm-а (как на Tomcat, так и на Glassfish). Если имеются ввиду веб-сервисы, то есть смысл посмотреть на Metro - там тоже по части безопасности много чего реализовано. Впрочем, если ты будешь использовать Glassfish, то Metro как раз и будет под рукой. |
| Автор: ShurikA 31.12.2008, 00:11 |
| powerOn, Спасибо. Имеет ли смысл копать в JAAS? Добавлено через 11 минут и 57 секунд И ещё вопрос: На сколько сложно подкручивать это дело под разные Applications Servers? На пример сильно ли большая разница между Tomcat и Glassfish? |
| Автор: mbasil 31.12.2008, 14:03 |
| Предполагаю, что чисто конфигурационная задачка на каждом сервере будет выполняться по своему, а это раздражает. Как-то "нацарапал" в качестве упражнения JAAS LoginModule для Tomcat с собственным механизмом аутентификации и авторизации в базе данных. Полагаю, что это предпочтительный вариант, так как при этом: - принимая на себя механизм аутентификации вы его пишите один раз для разных приложений. - при переходе на другой сервер изменения (предполагаю) должны быть минимальны, даже и в части настройки. - JAAS все таки стандартный механизм и поэтому разработчики серверов не должны так уж сильно привиредничать с разнообразием настроек. - вам удается заставить сервер принимать ваши решения в части аутентификации и авторизации. (Это важно для дальнейшего использования декларативной авторизации, например в EJB). - механизм вы можете легко заменить заменив базу данных на LDAP сервер. При таком подходе, предполагаю, мы получаем здоровый компромисс между написанием своего механизма и стандартным подходом. Здорово, что сервера приложений все больше и больше задач берут на себя, снимая их с разработчиков приложений. Однако тот факт, что настройки и описания не стандартизованы приводит к затрате массы усилий при переходе с сервера на сервер и получению массы ограничений. |
| Автор: powerOn 31.12.2008, 15:52 | ||
И часто вы сервера приложений меняете? Я вот в 4 проектах работал, где ни разу сервер не меняли. Как выбрали один раз, так продукт с ним и шел. |
| Автор: mbasil 2.1.2009, 14:44 |
| Не часто, естественно. Но все-же есть желание держать под контролем те аспекты, что выходят за рамки стандартов и трактуются каждым сервером по своему. |
| Автор: ShurikA 2.1.2009, 21:56 |
Дело даже не в том на сколько часто меняются сервера. А в том что желательно что бы аппликация поддерживалась несколькими серверами, для разных заказщиков. |
| Автор: sandello 4.1.2009, 14:03 | ||
Гм... ты используешь логику, которую нельзя реализоваться с помощью идущих в комплекте модулей? Или там в комплекте ничего нет? |