Безопасность 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 по-прежнему должен повторно пройти аутентификацию
(это звучит не так хорошо для меня).
Затем я перешел к поиску интеграции некоторой структуры безопасности. Самыми известными из них являются "Весна" и "Широ". Конечно, у каждого из них есть свои особенности (может быть, первое больше подходит для конкретной ситуации, а второе - в другой). Что для меня важнее, так это:
- Аутентификация
- авторизация
- Управление сессиями (и, возможно, шифрование)
Но везде я находил противоречивые выводы. Результат: я сейчас более запутан, чем перед поиском.
Я просто новичок в таких темах, как безопасность, и, кроме того, я разработчик (у меня есть что реализовать), поэтому трудно быть в курсе всех новых выпусков, и прогресс в области безопасности, кажется, продолжает идти каждый день,
Я хотел бы некоторые факты, основанные на личном опыте, если это возможно. Каждый намек или предложение приветствуется. Я хочу быть уверен, что уверен в себе, прежде чем предпринимать шаги по реализации.
2 ответа
JASPIC - это единственная технология, которая является частью Java EE и хорошо интегрируется с ней.
Тот факт, что модули аутентификации JASPIC не запоминают сеанс автоматически, также является преимуществом, поскольку делает их пригодными и для приложений без сохранения состояния (например, API-интерфейсы, такие как JAX-RS). Когда вы аутентифицируетесь и хотите получать сеансы, просто поместите результат (имя пользователя + группы) в сеанс. Затем в начале каждого метода validateRequest выполните быструю проверку, есть ли что-либо в сеансе, и если да, передайте это контейнеру снова. Не нужно проходить аутентификацию с нуля и, конечно же, не нужно запоминать пароль!
Shiro и Spring Security - это полнофункциональные фреймворки. Вы можете только сравнить это с JASPIC, который является очень низким уровнем и основным. Spring и Shiro не идеально интегрируются с Java EE. Spring Security часто называют более сложным, чем Shiro.
Надеюсь это поможет
Профиль сервлета JASPIC требует, чтобы сконфигурированный (для приложения) модуль (ы) проверки подлинности сервера (SAM) вызывался при каждом запросе; именно так, чтобы SAM мог управлять сеансами аутентификации (если это желательно)
Профиль также поддерживает случай, когда SAM настроен на выполнение аутентификации, но затем желает делегировать управление сеансом аутентификации в охватывающий контейнер, который активируется с помощью свойства обратного вызова registerSession.
Также, как отметил Майк Браун, профиль также поддерживает режим без сохранения состояния по отношению к сеансам аутентификации и полностью интегрирован с системой авторизации контейнера; такой, что аутентификация JASPIC должна происходить, когда целевой запрос покрывается ограничением авторизации (таким, как определено в web.xml или с использованием аннотации ServletSecurity).
Определяемые в JASPIC Callbacks и контейнер, предоставляемый обработчиком Callback, позволяют переносимому SAM устанавливать принципала вызывающего контейнера, просматривать реестр пользователей контейнера для проверки пароля и назначения группы и т. Д.