В своем проекте использую WEB-клиента, написанного на Eclipse RAP и JBoss 4.2.1 в качестве сервера приложений.
На одном из этапов дозрели до того, что бы органичивать доступ 
Первое решение было очень просто: в клиентский WAR'ник добавили jboss-web.xml и пару строчек в web.xml, настроили JAAS на JBoss'е.
Доступ к EJB ни как не контролировался.
Пользователь, когда открывал приложение в браузере, видел форму для ввода имени/пароля. Все замечательно.

Теперь второй шаг: нужно ограничивать доступ к EJB. Думал, что все будет просто - добавил  к каждом SSEJB

А оказалось - полный облом :( Вылетает исключение


Особенность клентской части в том, что большинство запросов обрабатываются в фоне в отдельном потоке (кажется, это Job'ам в eclipse  зовут). Может быть, проблема в этом.
Как заставить RAP-приложение корретно логироваться в JAAS при работе? Почему сейчас не сработало?
Когда экспериментировал с простым JSP - все работало корректно. Залогировался в на WEB - EJB стали доступны.

Секьюрити в JBoss работает в рамках потоков, т.е. threadLocal.
У тебя основной поток, в котором обрабатывается запрос, стартует фоновые потоки, которые и не могут обратиться к EJB?
Если так, то нужно самому делать логин, т.е. в Java-коде, хотя ты ведь не имеешь доступа к паролю текущего пользователя...  Наверное, есть какие-то прозрачные способы "просачивания" внешней авторизации и в другие потоки, но я их не знаю. Можно посмотреть внутренности JBoss по работе с авторизацией и вручную выставить нужных принципалов в новых потоках. Когда-то давно бегло смотрел тот код, вроде вполне реализуемая вещь.

А зачем тебе вообще ограничивать доступ именно к EJB, если контроль доступа осуществляется на уровне веб-клиента? Пусть EJB реализует только локальный интерфейс и никто извне не сможет до них достучаться. Или права на EJB могут быть более строгими, чем в веб-клиенте?

Плюсы в контроле доступа на EJB не только в собственно контроле доступа. Но и возможноти получения информации из security contex'а. На пример, кто это тут безобразничает...
Кроме того, в RAP'е организовать контроль что кому можно делать - думаю ооччень не просто. По крайней мере, применительно к моему случаю будет сильно дороже.

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


Про RAP посоветовать ничего не могу, web-клиентов никогда не писал.

А в целом, на твоём месте полез бы в исходники JBoss, дабы посмотреть из каких своих структур он извлекает информацию о секьюрити, и написал бы код по установке требуемых данных в новых потоках. 
Либо ещё проще - можно делать java-кодом логин с указанием только имени пользователя, а пароль не устанавливать, и в некую threadLocal пихать флаг, говорящий о том, что пароль проверять не нужно. И перекрыть проверку пароля в собственном модуле UsersRolesLoginModule.

Согласен, не красиво, но работать будет.
Если кто-то подскажет правильный способ - буду благодарен.

Исходники я уже перерыл вдоль и поперек  или почти вдоль и чуть поперк  
Использование встроенных механизмов JBOSS'а  лучше тем, что мне не надо заморачиваться и передавать имя пользователя в EJB-часть в качестве аргументов. Надо лишь настроить JAAS. Плюс использование официальных возможностей дает некоторую гарантию, что это будет работать и в следующих версиях. Или, по крайней мере, будет написано как перейти.
Использование всяких хитрых трюков, основанных на конкретной реализации - плохой тон. Особенно, когда есть нормальные решения.