Безопасность Java EE: JASPIC/JAAS или применить систему безопасности? (Glassfish 3)

В настоящее время я использую Oracle ADF (которая представляет собой сквозную инфраструктуру Java EE) для создания моих веб-приложений и GlassFish 3.1 в качестве сервера приложений.

Последний поддерживает JAAS (декларативный внутри своей консоли администратора). Итак, я создал область безопасности и сопоставил их с ролями, объявленными в файле конфигурации, и использовал JAAS для реализации функций авторизации и проверки подлинности. Все отлично, до сих пор! На прошлых неделях я изучал безопасность Java EE.

Я обнаружил, что JAAS достаточно хорош, если вы придерживаетесь "базовой" безопасности. Более того, кажется, что JAAS (как часть Java Security Framework) предназначался только для Java SE (но поскольку Java EE построен на Java SE, некоторые из его модулей повторно используются, например, LoginMethod и Callbacks).

Затем я нашел много сообщений о JASPIC, выяснив, что он может быть реализован только программным способом (не проблема) и он еще не полностью поддерживается поставщиками серверов приложений и попытался сделать сравнение между ними. Даже если выпуск JASPIC1.1 разрешил некоторые проблемы, например:

Контейнер, однако, не полностью запоминает аутентификацию. SAM по-прежнему вызывается по каждому запросу, и SAM все еще должен повторная аутентификация

(это звучит не так хорошо для меня).

Затем я перешел к поиску интеграции некоторых систем безопасности. Наиболее известными являются "Spring" и "Сиро" . Конечно, каждый из них имеет свои собственные характеристики (может быть, первый более подходит для конкретной ситуации, а второй в другой). Что более важно для меня, тем больше:

Аутентификация
Разрешение
Управление сеансом (и, возможно, шифрование)

Но везде я нашел противоречивые выводы. Результат: теперь я больше смущен, прежде чем искать.

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

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

Ответ 1

JASPIC - это единственная технология, которая является частью Java EE, которая очень хорошо сочетается с ней.

Тот факт, что модули аутентификации JASPIC автоматически не запоминают сеанс, также является преимуществом, так как он делает их пригодными для приложений без учета состояния (подумайте об API, таких как JAX-RS). Когда вы выполняете аутентификацию и хотите провести сеансы, просто поместите результат (имя пользователя и группы) в сеанс. Затем в начале каждого метода validateRequest выполните быструю проверку, если что-нибудь в сеансе, и если да, то снова дайте это контейнеру. Нет необходимости аутентифицироваться с нуля и, конечно же, не нужно помнить пароль!

Сиро и Spring Безопасность - это очень полнофункциональные фреймворки. Вы едва можете сравнить это с JASPIC, который очень низкий и базовый. Оба Spring и Shiro не идеально интегрируются с Java EE. Spring Безопасность часто считается более сложной, чем Сиро.

Надеюсь, что это поможет

Ответ 2

Профиль Servlet JASPIC требует, чтобы на каждом запросе вызывался модуль аутентификации сервера (для приложения); точно так, что SAM сможет управлять сеансами аутентификации (если это необходимо)

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

Также, как отметил Майк Браун, профиль также поддерживает режим без сохранения состояния для сеансов аутентификации и полностью интегрирован с системой авторизации контейнера; так что аутентификация JASPIC должна произойти, когда целевой запрос покрывается ограничением авторизации (например, будет определено в web.xml или с использованием аннотации ServletSecurity).

Определенные JASPIC обратные вызовы и контейнер, предоставленный обработчиком обратного вызова, позволяют переносимому SAM устанавливать основной вызов вызывающего абонента, проконсультироваться с реестром пользователей контейнера для проверки пароля и назначения групп и т.д.