Понимание аутентификации на сервере приложений Java - PullRequest
Новая
       57

Понимание аутентификации на сервере приложений Java

13 голосов
/ 29 марта 2012

В настоящее время я работаю над проектом, работающим на JBoss AS 7, который требует аутентификации из различных источников. Я пытаюсь понять различные компоненты, которые объединяются для обеспечения аутентификации.

У меня есть некоторые предположения / предположения о том, как все это сочетается, но я должен убедиться, что мое понимание верно. Ниже приведено описание процесса аутентификации для JBoss AS7.

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

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

Фактические имя пользователя и пароли передаются через механизм, определенный в файле web.xml (для сервлетов), определенный в элементе .

Предполагая, что описанный выше процесс является правильным (а может и не быть):

  • Подпадает ли весь этот процесс аутентификации под спецификацию, такую ​​как JAAS, или JAAS является лишь небольшой или необязательной частью этой процедуры?
  • Все ли типы (т.е. BASIC, DIGEST и FORM) работают со всеми видами модулей входа в систему? Эта страница , похоже, не предлагает, но я не видел четкой документации, соответствующей параметрам .
  • Поток имени пользователя и пароля от имени входа в систему к модулю входа кажется достаточно простым, но что происходит с такими системами, как OpenID или OAuth, где существуют промежуточные действия (например, перенаправление на внешние страницы входа)?
  • Как проекты, такие как Seam 3 Security , Apache Shiro и Spring Security вписываются в эту картину?

1 Ответ

11 голосов
/ 07 мая 2012

Спецификация безопасности JavaEE оставляет много места для разработчиков контейнеров, поэтому я сосредоточусь на реализации JBoss, чтобы ответить.

Реализация безопасности JBoss

JBoss использует аутентификацию JAAS для реализации безопасности JavaEE. Таким образом, он использует преимущества стабильного API и может использовать существующих LoginModule реализаций . Модули входа используются для аутентификации субъекта, а также для добавления ролей в Subject. JAAS предоставляет механизмы для авторизации, проверки разрешений, а JBoss использует его внутри.

JAAS LoginModule поддерживает не только аутентификацию на основе пароля, но и аутентификацию на основе токена.

Аутентификация на основе токена

Хорошим примером того, что можно сделать в JBoss благодаря JAAS, является поддержка HTTP-согласования для Kerberos SPNEGO : дополнительная auth-method с именем SPNEGO реализована благодаря Tomcat Authenticator и валидации токенов использует стандарт JavaSE Kerberos LoginModule .

Кстати, API LoginModule не является обязательным, он может быть слишком сложным для некоторых протоколов. Например, реализация для поддержки OpenID с PicketLink использует только API сервлета.

Сторонние библиотеки безопасности

Эти библиотеки часто предоставляют уровни безопасности для приложения, работающего с контекстом JavaEE или чистого Java, даже если оно не использует преимущества спецификаций JavaEE для аутентификации или авторизации на основе ролей.

Spring Security предоставляет разработчикам приложений другие абстракции, кроме безопасности JavaEE, для реализации аутентификации и авторизации, в основном благодаря ServletFilter, когда речь идет о веб-приложении. Для защиты его приложения доступна большая панель выбора: можно смешать несколько вариантов, таких как: использование JAAS, использование безопасности контейнера JavaEE или реализации, специфичные для Spring Security (в случае OpenID и OAuth). Также нет никакой зависимости от JavaEE, поэтому он может использоваться практически в любой ситуации при работе на JavaSE. Большинство архитекторов предпочитают создавать приложения безопасности на Spring Security, чтобы иметь возможность переключать конкретные реализации в будущем.

Apache Shiro действительно похож на Spring Security, но он моложе и, вероятно, проще в настройке.

Безопасность шва не зависит от безопасности JavaEE или JBoss, а только от API сервлетов и JSF. Это, очевидно, самый простой вариант для веб-приложения на основе JSF / Seam. За кулисами он использует PicketLink реализаций.

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

...