EJB 3.1 - реализация javax.security.auth

Question

Как я понимаю, javax.security.auth - это API для аутентификации и авторизации.

Я понимаю, что безопасность должна быть реализована поставщиком контейнера, и поставщик bean-компонентов может просто использовать его в своем компоненте в моих простых аннотациях (, @PermitAll и т. Д.), Как рекомендовано JSR.

Мой вопрос: Это просто означает, что безопасность не может быть протестирована без развертывания в контейнере. Есть ли способ использовать внешнюю 3-ю реализацию javax.security, которая может каким-то образом быть введена в компонент из теста, из которого можно также распространять и тестировать безопасность?

Это почти аналогичный подход, в котором мы вводим реализацию JPA или внешний диспетчер транзакций из модульного теста в компонент для тестирования.

P.S: Я просто хочу проверить, возможно ли это, и если это возможно, это может открыть способы для какой-либо другой разработки. Я понимаю, что это тестирование можно легко выполнить, развернув компонент в встроенном контейнере, таком как OpenEJB или Arquillian.

Answer 1

Во всем этом есть много сантехники. Хитрее части:

• Обработка аннотаций и соблюдая без наследования и доминирующих правил (не относится к XML перекрытию)
• Обеспечения аннотаций не получают по назначению или неправильного применения
• Уважая XML и переопределение аннотации данные
• Mapping «роли позволили» с объявленными «ролями» (есть уровень косвенности)
• Добавление всех метаданных, как правильно отформатированные строки разрешения на поставщик JACC
• Handling Войти с помощью правильно настроенного JAAS LoginModule
• Некоторые творческие код для интеграции JAAS с JACC (нет стандартного способа сделать это)
• Отслеживание Subject через doAs вызовов или ThreadLocal
• что проксирующий все объекты, так что вы можете делать проверки AUTH прежде, чем методы на самом деле вызывается
• Изменение контекста безопасности для метода с аннотацией @RunAs и обеспечением роли RunAs является заявленной ролью
• Dealing с EJBContext.getCallerPrincipal() (а Subject имеет много Principal о bjects, так что вы должны выбрать один, чтобы вернуться и убедиться, что вы можете выбрать один и тот же один последовательно)
• Электропроводка EJBContext.isCallerInRole(String) поставщику JACC
• убедившись, что вы используете правильные классы исключений при обращении сбой входа в систему, выход из строя авторизации и различные другие условия

Так вот что делает контейнер. Работа JAAS и JACC действительно очень мала. Конечно, не так подробно, как минимум.

Ничего из этого действительно не может быть «введено», как вы могли надеяться. Безопасность - это практически совет.

На первый взгляд вещи, такие как защита на основе аннотаций, выглядят очень просто. Тем не менее, когда вы исследуете все комбинации, оговорки и условия, которые это действительно добавляет. Я помню все эти детали выше, потому что я их неправильно понял, когда мне сначала пришлось их реализовать. :) Слава богу за TCK.

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

Если у вас есть особый способ, которым вы хотите, чтобы ваше тестирование произошло, самым умным было бы просто связать себя с OpenEJB или Arquillian.

Все самые крутые функции в OpenEJB приходят от пользователей от боли и боли, и люди, описывающие нас, «мне больно, когда я это делаю». Мы любим это. Это отличный источник возможностей, отличный способ получить новых вкладчиков и отличный способ доказать идеи, которые могут быть полезны для внедрения в спецификацию (например, API Embedded EJBContainer в EJB 3.1).

Я не могу подчеркнуть, насколько важно участвовать в инновациях, а не пытаться обойти его. Если что-то не соответствует вашим потребностям, попробуйте лучше.

Это последнее заявление больше ориентировано на мир в целом :)