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

Question

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

Я понимаю, что безопасность должна быть реализована контейнерным провайдером, и бобовый провайдер может просто использовать его в своем бине, мои простые аннотации (@javax.annotation.security.RolesAllowed, @PermitAll и т.д.) в соответствии с рекомендациями JSR.

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

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

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

Answer 1

Во всем этом довольно много сантехники. Более сложные части:

• Обработка аннотаций и соблюдение правил отсутствия наследования и переопределения (не относится к переопределению xml)
• Обеспечение того, чтобы аннотации не использовались неправильно или не применялись неправильно
• Уважение xml и переопределение данных аннотации
• Сопоставление "разрешенных ролей" с объявленными "ролями" (существует уровень косвенности)
• Добавление всех метаданных в виде правильно отформатированных строк разрешений поставщику JACC
• Обработка входа через правильно настроенный JAAS LoginModule
• Небольшой креативный код для интеграции JAAS с JACC (стандартного способа сделать это не существует)
• Отслеживание вашего предмета через doAs звонки или ThreadLocal
• Проксирование всех ваших объектов, чтобы вы могли выполнять проверку подлинности до того, как методы будут фактически вызваны
• Изменение контекста безопасности для метода, аннотированного @RunAs, и обеспечение роли RunAs объявленной
• Имея дело с EJBContext.getCallerPrincipal() (а Subject имеет много Principal объекты, поэтому вы должны выбрать один, чтобы вернуться и убедиться, что вы можете выбрать один и тот же)
• электропроводка EJBContext.isCallerInRole(String) провайдеру JACC
• Убедитесь, что вы используете правильные классы исключений, когда обрабатываете ошибку входа в систему, ошибку авторизации и другие различные условия

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

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

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

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

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

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

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

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