Где:
1. Usersdepartmentses отделы, на которые есть право доступа у пользователя
2. usersession сессионная временная таблица, куда я укладываю перед выборкой залогиненного пользователя
3. Agents - таблица, на которую мне надо ограничить права доступа.

и того у меня при отукрытии HibernateSession 
вызывается такое(псевдо код):


А потом просто делаю выборку:

Views построенные с использованием динамического аттрибута - хорошая идея. Я такую видел в работе, отлично работает.

Дополнительный критерий к вопросу выбора: будут ли запросы аггрегативного характера, охватывающие всю базу? Если да - то, выполнить такой запрос по нескольким схемам потребует специального подхода.

MisterCleric, впечатляет, но есть вопросы
1. Я так понимаю tenant - это user ? Если да, то содержится ли поле user в остальных сущностях ? Если да, то по связи или нет ?
2. Зачем временная таблица с именем залогиненного пользователя?
3. Что такое "отделы, на которые есть право доступа у пользователя" ?
4. Где и когда этот sql код исполнять ?

Привет. 
Давай попытаюсь ответить:

Это просто привел тебе пример моего кода. Я его не адаптировал под тебя.
Зачем этот твой tenant держать во всех сущностях? Ведь в итоге у теб все-равно будет дерево объектов. И понятно, что всегда можно по внешним ключам добраться до вершины пирамиды - tenant. Что легко можно скрыть в таких вот View.

Потому как каждый пользователь ложа в такую таблицу записи видит только свои. И мне, что понимать на уровне БД, какой пользователь выполняет запросы, достаточно написать так:

И сразу же встречный вопрос: как ты будешь понимать какому tenant принадлежит пользователь, который выполняет действие?

Это такое разграничение прав доступа к данным в моей архитектуре. Суть сводиться к чему: контора, использующая мое приложение, имеет множество отделов по всей стране. Так вот необходимо показывать сделки пользователям строго по их региональной принадлежности. Плюс "объем региональности" растет с приближением к уровню столицы.

Мой EntityManager имеет TransactionScope. 
Я оборачиваю весь цикл запроса от пользователя в транзакцию. Т.е. у меня это делает seam. И в фильтре перед вызовом бизнес логики у меня стоит вызов INSERT во временную таблицу. Поскольку все дальнейшие действия с БД выполняются в одной БД сессии, то и содержимое этой таблицы доступно везде и оно однозначно.

Удачки тебе

MisterCleric, спасибо.
В итоге я добавил во все сущности tenant_id, и при занесении записи в БД, я заношу id того тенанта к которому относится эта запись. Ну а дальше дело техники, создал хибер фильтр, в который в сессию ложу критерий tenant_id. 
Этот способ нормальный ? 

Да, поскольку его тоже приводят в пример по данной теме