Общие сведения об аутентификации на сервере приложений Java

Question

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

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

---

У вас есть область безопасности, которая определяет, как пользователи проходят аутентификацию. Затем эта область подвергается действию вашего приложения, чтобы защитить его или ее часть. В AS7 это настроено в подсистеме < xmlns = "urn: jboss: domain: security: 1.0" >.

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

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

---

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

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

Answer 1

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

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

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

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

лексем аутентификации на основе

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

К слову, API LoginModule не является обязательным требованием, он может быть слишком сложным для некоторых протоколов. Например, реализация для поддержки OpenID with PicketLink использует только Servlet 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, который поддерживает authentication provider chaining (или Shiro).