2016-05-23 4 views
0

Все методы авторизации Java EE, которые я видел до сих пор, предназначены только для уровня представления - в основном на основе JSF. Вы в основном ограничиваете доступ к определенным шаблонам URL или компонентам JSF.Служба на основе безопасности с Java EE

Однако, я бы предпочел, чтобы мой уровень безопасности был сервисом. Мои слои ищут что-то вроде этого:

  • View (XHTML + JSF Бэк Фасоль/RESTful веб-сервисы)
  • Услуги
  • Сущности и бизнес-логики
  • Daos

Поскольку услуги являются прокси для моей бизнес-логики и не содержат никакой логики, я бы хотел использовать их для контроля доступа. Таким образом, мне не нужно будет реализовывать безопасность для каждой технологии просмотра отдельно или следить за шаблонами URL (которые ужасно поддерживать).

Мое предпочтительное решение - это аннотации к классам или методам обслуживания. Если какой-либо код просмотра пытается получить к ним доступ без разрешения, он получает исключение (которое обрабатывается и отправляется в форму входа).

Есть ли что-нибудь вроде этого, я мог бы использовать?

ответ

4

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

Есть ли что-нибудь вроде этого, я мог бы использовать?

Да. То, что вы уже знакомы, называется безопасностью на уровне приложений, и это действительно часто. Но Java EE уже давно предоставляет встроенные декларативные механизмы в качестве альтернативы или дополнения; они могут работать на уровне веб-приложений или на уровне компонентов. Подробности здесь слишком обширны, чтобы описать здесь, но учебник по Java EE содержит три главы, охватывающие их. Вероятно, вы захотите начать с the overview.

На очень высоком уровне,

  • декларативные требования безопасности традиционно были выражены в дескрипторы развертывания. Информация зависит от типа защищаемого компонента или приложения.

  • С по меньшей мере Java EE 6 некоторые объявления безопасности также могут быть сделаны посредством аннотаций в источниках компонентов.

  • Основным встроенным механизмом аутентификации и авторизации пользователей является, соответственно, Java Authentication and Authorization Services (JAAS). Это на самом деле технология Java SE, поэтому вы можете использовать ее и для обычных приложений. Если вы когда-либо работали с подсистемой подключаемых модулей аутентификации Solaris/Linux (PAM), тогда JAAS будет чувствовать себя знакомой по концепции.

  • Некоторые контейнеры Java EE и некоторые прикладные структуры обеспечивают свои собственные механизмы безопасности; если ваши обстоятельства позволяют вам рассматривать такие вещи, тогда стоит посмотреть.

+0

'> Основной встроенный механизм аутентификации пользователя и авторизации - [...] (JAAS) .' Нет; аутентификация и авторизация предоставляются моделями безопасности отдельных спецификаций, преимущественно используемые среди которых (Servlet, EJB) не являются «построенными» поверх, ни мандата, ни даже не рекомендуют, чтобы их реализация основывалась на JAAS. Если это так, то это детализация реализации, о которой разработчику приложений Java EE не нужно заботиться. Если OP нуждается в дополнительных функциях, есть стандартные SPI (JASPIC, JACC) для Java EE, которые они могут использовать вместо этого. – Uux

Смежные вопросы