Как защитить свое веб-приложение, написанное с использованием Wicket, Spring и JPA?

Итак, у меня есть веб-приложение, использующее платформу Wicket 1.4, и оно использует компоненты Spring, Java Persistence API (JPA) и шаблон OpenSessionInView. Я надеюсь найти модель безопасности, которая является декларативной, но не требует большого количества XML-конфигурации — я бы предпочел аннотации.

Вот варианты на данный момент:

  1. Spring Security (руководство ) — выглядит завершенным, но каждое найденное мной руководство, объединяющее его с Wicket, по-прежнему называет его Acegi Security, что заставляет меня думать, что оно должно быть старым.

  2. Wicket-Auth-Roles (руководство 1 и guide 2) – в большинстве руководств рекомендуется смешивать это с Spring. Безопасность, и мне нравится декларативный стиль @Authorize("ROLE1","ROLE2" и т.д.). Меня беспокоит необходимость расширения AuthenticatedWebApplication, поскольку я уже расширяю org.apache.wicket.protocol.http.WebApplication, а Spring уже проксирует это за org.apache.wicket.spring.SpringWebApplicationFactory.

  3. SWARM / WASP (руководство) — это выглядит самым новым (хотя главный участник скончался много лет назад), но я ненавижу все текстовые файлы в стиле JAAS, в которых объявляются разрешения для принципалов. Мне также не нравится идея создания класса Action для каждой отдельной вещи, которую пользователь может захотеть сделать. Безопасные модели также не сразу очевидны для меня. Кроме того, нет примера Authn.

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


spring security jpa tomcat wicket
person Martin    schedule 23.02.2010    source источник

Ответы (2)


arrow_upward
8
arrow_downward

Я не знаю, видели ли вы это сообщение в блоге, поэтому я добавляю его сюда как ссылку и просто процитирую конец:

Обновление от 12 марта 2009 г. тем, кто заинтересован в защите приложений Wicket, также следует знать, что существует альтернатива Wicket-Security, которая называется wicket-auth-roles. Эта тема даст вам хороший обзор состояние двух фреймворков. Интеграция ролей калитки с Spring Security описана здесь.
Одной из привлекательных особенностей wicket-auth-roles является возможность настраивать авторизацию с помощью аннотаций Java. Я нахожу это более элегантным, чем централизованный файл конфигурации. Пример приведен здесь.

Основываясь на приведенной выше информации и той, которую вы предоставили, а также, поскольку я тоже предпочитаю аннотации, я бы выбрал Wicket-Auth-Roles с Spring Security (т.е. руководство 2). Расширение AuthenticatedWebApplication не должно быть проблемой, так как этот класс расширяет WebApplication. И вытаскивание вашего объекта приложения из контекста Spring с помощью SpringWebApplicationFactory также должно работать.

И если ваши опасения действительно велики, это было бы довольно легко и быстро подтвердить с помощью теста IMO :)

person Pascal Thivent    schedule 23.02.2010
comment
Я также должен добавить -- wicket-auth-roles, похоже, не обрабатывает разрешения, выходящие за рамки ролей. Например, если бы у меня была коллекция объектов, пользователь не мог бы иметь роль для каждого объекта. Опять же, SWARM, похоже, тоже не справляется с этим. Считаете ли вы, что какое-либо из этих решений лучше, учитывая, что у меня могут быть более сложные комбинации разрешений пользователя и объекта? - person Martin; 23.02.2010
comment
@Martin, я не уверен, что какое-либо из этих решений справится с этим (кажется довольно сложным), но это может выйти за рамки моих знаний. - person Pascal Thivent; 23.02.2010

arrow_upward
2
arrow_downward

Мы используем Wicket-security уже много лет, и мы использовали его вместе с файлами jaas и с аннотациями. Определение файлов jaas довольно хлопотно, а поддерживать их практически невозможно...

С аннотациями нужно определить действия и принципы для каждой страницы. Это отнимает много времени, однако позволяет пользователю динамически определять роли и права доступа. Также можно протестировать всех принципалов с помощью WicketTester.

Каждый из 3-х пакетов имеет свои (не)преимущества, это дело вкуса, а также зависит от размера приложения.

person Hielke Hoeve    schedule 28.04.2010