1. Можно использовать декларативную безопасность в web контейнере так, как вы это описали в своем пункте 4 (то есть элемент <security-constraint>)
2. Можно продлить эту декларативную безопасность в EJB компоненты, описав каким ролям доступен вызов каких методов. 
3. Можно использовать программную безопасность в web контейнере используя методы
    getUserPrincipal()
    isUserInRole()
4. Можно использовать программную безопасность в EJB контейнере используя методы
    getCallerPrincipal()
    isCallerInRole()

(Первые два пункта предпочтительнее последних двух)

mbasil, ну EJB сразу откидываем, так как с EJB я практически не знаком. Будем говорить в контексте обычного веб-приложения.
Почему декларативная безопасность предпочтительнее программной? Все ли можно описать в декларативной, что в программной? Взять например вот это:
Как это описать в декларативном виде? Не терям ли мы гибкость и удобство?

Конечно основные преимущества декларативной авторизации мы получаем именно в EJB, так как там мы имеем дело с хорошо гранулированным контролем доступа на уровне методов.

В web контейнере речь идет о правах доступа к ресурсам, описываемым в web.xml. Это дает возможность управлять доступом к ресурсам WEB ПРИЛОЖЕНИЯ с использованием встроенных средств контейнера, причем после внесения изменений не всегда требуется даже повторно развертывать приложение. Иногда достаточно перезагрузить его.
Приведенный вами пример скорее подходит для standalone приложения. Кроме того включение менеджера безопасности, которое обязательно надо будет сделать, чтобы это работало (по непонятным для меня причинам) резко снижает производительность даже простого standalone приложения.

mbasil, ясно, спасибо. Буду при возможности дальше курить книгу, уверен что еще отпишу в этой теме.

Лично мне JAAS нравится именно своей гибкостью и тем, что я могу отнять у контенера работу по аутентификации и авторизации и сделать это так, как мне нравится, например с хранением полномочий в базе данных или на LDAP сервере. Вы можете сказать, но ведь например, Tomcat тоже позволяет получать полномочия из базы данных. Да, но делает это в жестких рамках и при преносе приложения на другой сервер я опять должен это переделывать (включая таблицы базы и т.п.). Кроме того, вы можете использовать JAAS, например для аутентификации с помощью JavaCard или с контролем отпечатков пальцев.
При использовании JAAS, принимая механизм аутентификации на себя, я результаты "подсовываю" контейнеру для выполнения декларативной авторизации и он это съедает. Очень удобно, на мой взгляд.

Что вы имеете ввиду под полномочиями? Роли как я понимаю? Так как потом использовать все эти роли? Везде чекать isUrerInRole? Как вы делаете?



Ну да, роли хранятся в базе. Как-то можно обойтись без этих таблиц при переносе приложения?



Да, это конечно круто, достаточно лишь реализовать соответствующий LoginModule



Вот тут что-то не понял. Разве в случае с JDBCRealm и DataSourceRealm это не так же?

1. Под полномочиями я понимаю то, что предполагает спецификация Java EE, а именно имена пользователей, пароли и роли. Но никто мне не мешает хранить в базе данных сертификаты и проверять их в своем  LoginModule, а затем связывать их с ролями.

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

3. JDBCRealm и DataSourceRealm это за рамками спецификации "Java™ Platform, Enterprise Edition (Java EE) Specification, v5", а значит другие сервера приложений не обязаны именно так работать с аутентификацией в базе данных. И скорее всего они потребуют других названий таблиц и т.п.

4. Сегодня JAAS стандарт Java так я и предпочитаю пользоваться стандартным механизмом, который работает на всех серверах приложений.

Добавлено через 5 минут и 17 секунд
Что касается - как проверять, вы же сами приводили пример

В Web контейнере это основной декларативный способ - контроль доступности навигационных путей (ресурсов) с помощью ролей. Чекать isUrerInRole это очень редко, только там, где по другому нельзя.

У меня тут еще вопрос вылез, например у нас есть некая страничка, которая доступна и пользователю и администратору, однако если это администратор, то на страничке должен появиться дополнительный функционал, например для редактирования какой-нибудь например новости. Как это реализовать? Каждый раз в коде проверять isUserInRole в том месте где надо вставить кнопку для редактирования? Так? Или же есть более грамотный способ?


Это сообщение отредактировал(а) garbuz - 25.4.2009, 10:48