Когда переходить от безопасности, управляемой контейнером, к альтернативам, таким как Apache Shiro, Spring Безопасность?

Я пытаюсь защитить свое приложение, которое создается с помощью JSF2.0.

Я смущен, когда люди предпочитают использовать альтернативы безопасности, такие как Shiro, Spring Security или owasp esapi, выходящие за безопасность, управляемую контейнером. Увидев некоторые из связанных вопросов в Stack Overflow, я понял, что безопасность на основе контейнеров была более предпочтительной для разработчиков JSF в прошлом. Но я также настоятельно рекомендовал использовать Apache Shiro. Я новичок в вопросах безопасности и понятия не имею, какие могут быть соответствующие проблемы и как с ними бороться. Поэтому я ищу что-то, что обрабатывает большинство проблем безопасности с помощью настроек по умолчанию/самостоятельно.

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

В этом случае, как вы думаете, может быть хорошим вариантом для меня?

Я лично был убежден в выборе Сиро, поскольку он прост в использовании и заботится о большинстве вещей для новичков.

ОТВЕТЫ

Ответ 1

Я точно ничего не знаю об Apache Shiro, кроме следующих, но то, что вы процитировали, приходит практически дословно из их веб-страницы, которая содержит несколько неверных -значения, такие как "[JAAS], требовали статических определений, которые могли изменять только программисты", а "JAAS связан слишком сильно привязан к проблемам на уровне виртуального компьютера" и подразумевается, что JAAS не относится к пользователям и ролям, что просто ложный. Я бы хотел, чтобы многие убедились, чтобы уйти от безопасности, управляемой контейнером. Это часть спецификации сервлета, поэтому она должна поддерживаться любым контейнером; это хорошо понято; он поддерживается классами JDK без третьих сторон;... и это работает для меня; -)

Ответ 2

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

  • Обычно сервер приложений предоставляет некоторые службы поверх JAAS, такие как единый вход, встроенный в loginmodules и т.д., поэтому иногда, когда гранулярность разрешения не является требованием, вы должны обратиться за JAAS.

  • В прошлый раз, когда я проверил, Shiro также не поддерживал взаимную аутентификацию ssl (используя цифровые сертификаты), но вы, вероятно, не использовали бы это...

  • Если вы используете Shiro, ваше приложение, вероятно, будет более переносимым между контейнерами приложений/сервлетов (о, ирония!), поскольку конфигурация безопасности JavaEE имеет тенденцию быть специфичной для поставщиков для большинства нетривиальных настроек.

В целом, в соответствии с указанными вами требованиями:

  • Использование AppServer (GlassFish, JBoss): JAAS (ootb authc/authz, встроенные логин-модули)
  • Использование контейнера сервлетов (Jetty/Tomcat): Сиро (проще настроить и использовать)

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

Ответ 3

Я решил, что SpringSecurity (SS) станет нашей базой аутентификации и авторизации. Главным образом потому, что SS делает OpenID и OAuth. Мне придется настроить его, хотя для системы разрешений/группы/пользователя/сущности довольно немного. Я планирую сделать авторизацию на уровне "EntityManager/Entity", уровне обслуживания и уровнях Web/API. "Заблокируйте дверь, но у вас есть драгоценности в сейфе 3 тонны в задней комнате". Большая часть последней половины Shiro обрабатывает МНОГО лучше. Но я не стал так комфортно пытаться интегрировать openid4j/openauth4j в Сиро.

Было бы неплохо выбрать и выбрать функции обоих, без каких-либо помех или раздувания кода. Это лучший выбор.

PS, Spring приносит много других вещей на пластину, также как и интеграция с JSF, поэтому у него много апелляции.