EJB3 & Как субъект / принципал JAAS распространяется на уровень EJB из контейнера сервлета?

Question

Я пытаюсь понять, как принципал JAAS распространяется на уровень Business / EJB с веб-уровня.

Я читал, что если роли / область настроены в login-config & security-context из web.xml , тогда контейнер сервлета также прозрачно передаст аутентифицированного принципала на уровень EJB.

Два вопроса
1.) Первое и, что более важно, правда ли это? Без какого-либо вмешательства со стороны разработчика!
2.) А во-вторых, любая идея, как это работает под капотом.

Answer 1

1. да, это правда.В этом и заключается смысл ejb - брать «сложные» вещи из рук разработчика (например, безопасность, транзакции, надежность, многопоточность и т. д.)
2. это зависит от реализации.я знаю, что в jboss (по крайней мере, 4.x и ранее) при удаленных вызовах методов использовался собственный протокол сериализации, который имел дополнительную карту произвольной информации, которую можно было отправить вместе с запросом.в этом была информация об аутентификации, а также другие вещи для поддержки кластеризации.для локальных вызовов методов я считаю, что они используют такие вещи, как ThreadLocals.

Answer 2

Существуют различные «контекстные» фрагменты информации, которые распространяются в вызовах EJB, как только вы попадете внутрь слоя EJB и начнете выполнять вызовы EJB-EJB, в качестве примера можно привести транзакции. Некоторые контейнеры также позволяют вам создавать свои собственные объекты контекста.

Локальное хранилище потоков может использоваться в процессе, но обычно просто предполагается, что контейнер отвечает и может делать правильные вещи - фактическая методика зависит от конкретной реализации.

Answer 3

Principal распространяется на уровень EJB с веб-уровня, настроенного через login-config в файле web.xml, как вы и предполагали по большей части.

Способ его реализации зависит от реализации.Данные пользователя / группы также зависят от реализации и настраиваются как часть сервера приложений.

Однако, один из способов сделать это - реализация поставщика JASPIC, который является стандартным способом * 1007.* получение Principal.Использование этого позволяет вам иметь другой путь аутентификации по сравнению со стандартной регистрационной формой, базовой аутентификацией или аутентификацией сертификата, предоставляемой WEB-INF/web.xml, но это немного больше работы.

Пути аутентификации JASPIC допускают более сложные сценарии, такие какв качестве аутентификации на основе заголовка или двухфакторной или OpenID.Пользовательская база данных «обычно» не должна быть привязана к базе данных на сервере приложений.Я говорю «обычно», потому что WebSphere Application Server связывает аутентификацию с пользователем, настроенным на сервере.

Answer 4

По поводу вашего первого вопроса - да.
Относительно вашего второго вопроса - знакомы ли вы, например, с перехватчиками EJB3?
Контейнер создает прокси-объекты с «кодом перехвата» для bean-компонентов,
и, кроме того, контейнер может отслеживать другие аннотации для методов и класса bean-компонента, например,
, для обнаружения аннотации @PostConstruct.
Используя определение роли, он может проверить конфигурацию
(либо login-config.xml в более старых версиях jboss, либо standalone.xml в JBoss AS 7 в автономной конфигурации) и понять, каково определение для каждой роли,
JAAS используется для обеспечения уровня абстракции над аутентификацией и авторизацией.
Одной из концепций, лежащих в основе JAAS, является модуль входа в систему - он предоставляет вам код "для протокола", который заботится о фактической авторизации и аутентификации.
Например, я использую таким образом Krb5LoginModule для использования kerberos.