мне необходимо реализовать разграничение функционального доступа и доступа к данным.

использовать собираюсь JBoss AS, JBoss Seam (jsf), Hibernate, Oracle 8.1.7

1. как реализовывать функциональное разграничение доступа?
существующее решение: на страницу поставить constraint и с помощью jaas юзера проверять в базах данных
может существуют другие решения?

2. как реализовать разграничение доступа к данным?
имеется ввиду, чтобы пользователь А имел доступ к одним данным таблицы Т, а пользователь Б имел доступ к другим данным таблицы Т
существующее решение: сделать таблицу доступа:



а у данных:


и при доступе к данным запрос похитрее написать, чтобы возвращал только нужныеданные. Или же отделять лишние данные в бизнес-слое и отдавать в представление.
Но мне кажется этот путь неудобным, может быть есть попроще решения? Например какая нибудь библиотека для подобного доступа, или это может быть в хибернейте реализовано?
Или, использовать встроенную оракловскую систему прав (этот путь мне тоже кажется неудобным)?

буду признателен за любые советы

Synt, всё это можно сделать при помощи jaas, об этом подробнее на http://java.sun.com . И ещё здесь . Но есть более продвинутые и гибкие системы http://acegisecurity.org/ тоже основанные на jaas , но для работы требующие библиотеки spring. 

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

спасибо, похоже acegisecurity действительно то что нужно. Попробую его покопать;)

поиск попробовал, инфа есть, но очень мало. Кроме того сей вопрос все формулируют по разному. В книжках он тоже не описан, шаблонов таких я не нашел. По каким словам искать на sun.com? как называется эта проблема?

Synt, acegisecurity обсуждается на форуме spring http://forum.springframework.org/forumdisplay.php?f=33 . 

Так и ищи "jaas". 

А вообще почитай сначала что-нибудь об этом на русском. И не забывай про поиск .

читаю сейчас книжку жаасбук

как я понимаю, для 1 вопроса это описанный путь является наиболее оптимальным. Функционал Асеги секьюрити здесь повторяет обычный жаас (ну разве что не придется переписывать хмл файлы при изменении сервера приложений).

относительно ответа на вопрос 2:
Хранению прав в таблицах как я понял альтернативы нет.

Тогда вопрос - как лучше реализовать проверку прав
1. Хранимыми процедурами - тогда придется использовать права оракла, предачу принципала внутрь базы данных - сложно.
2. Собственноручно писать код для этой проверки.
3. Использовать контроль доступа к данным жаасовский или асеги. Этот вариант незначительно сложнее 2, но красивее. Однако об этом почему то написано очень мало,  наверно мало кто использует все эти Пермишшены. 
 Правильно ли я понимаю, для проверки прав, нужно унаследоваться от ProtectionDomain и  реализовать в implies  ProtectionDomain проверку соотетсвие полученного Пермишшена тому,которые есть  в таблице?

Synt, 
Можешь хранить в *.property файле, например (у acegi). А чем не устраивает хранение прав в бд?

Все твои потребности можно решить с помощью acegi, читай подробнее http://acegisecurity.org/docbook/acegi.pdf . На счёт второго вопроса, я бы сделал так. Так как acegi позволяет разделить права на выполнение разных методов кода, то можно сделать чтобы одни методы возвращали тебе одни данные, при условии, что юзер обладает требуемыми правами и не возвращали другие если таковых прав нет. Т.е. одни методы возвращают одни данные, другие методы другие и у этих методов разные требуемые права доступа. 

прочитал наконец jaasbook.com

Вообще механизм очень удобный - на объекты добавляю пермишшены.

Затемжу провожу "отсев" записей с пермишшенами, например так:




А потом методы сесионного бина, возвращающие данные вызывать с помощью Subject.doAsPrivileged().



мне кажется,  каждый метод оборачивать doAsPrivileged() - не слишком ли нудно? может быть как нибудь этого можно избежать? Будет ли AccessController.checkPermission(perm) работать правильно если вызывать getMyObjects() без doAsPrivileged()



и как хранить пермишшены в БД? Нужно их брать из базы при старте приложения, добавлять в PermissionService, такой путь работает? 
Тогда будет трудно поддерживать  соответсвие - удалил админ пермишшен - его нужно и из базы удалить, и из PermissionService.