Как я должен защитить свое веб-приложение записанная Калитка использования, Spring и JPA?
Так, у меня есть веб-приложение, которое использует Калитку 1,4 платформы, и это использует бобы Spring, API персистентности Java (JPA) и шаблон OpenSessionInView. Я надеюсь найти модель обеспечения безопасности, которая декларативна, но не требует ртов конфигурации XML - я предпочел бы аннотации.
Вот опции до сих пор:
Безопасность Spring (руководство) - выглядит завершенной, но каждое руководство, я нахожу, что комбинирует его с Калиткой все еще, называет ее безопасностью Acegi, которая заставляет меня думать, что это должно быть старо.
Wicket-Auth-Roles (ведут 1 и ведут 2) - Большинство руководств рекомендует смешать это с безопасностью Spring, и я люблю декларативный стиль @Authorize ("ROLE1", "ROLE2", и т.д.). Я обеспокоен необходимостью расширить AuthenticatedWebApplication, так как я уже расширяю org.apache.wicket.protocol.http. WebApplication и Spring уже проксируют это позади org.apache.wicket.spring. SpringWebApplicationFactory.
РОИТЕСЬ / WASP (руководство) - Это смотрит новейшее (хотя основной участник скончался несколько лет назад), но я ненавижу все JAAS-стилизованные текстовые файлы, которые объявляют полномочия для принципалов. Мне также не нравится идея сделать класс Действия для каждой вещи, которую пользователь мог бы хотеть сделать. Безопасные модели также не сразу очевидны для меня. Плюс, нет примера Authn.
Кроме того, похоже, что много людей рекомендует смешать первые и вторые опции. Я не могу сказать то, что лучшая практика вообще, все же.
2 ответа
Не знаю, видели ли вы это сообщение в блоге , поэтому я добавляю его сюда в качестве справки и просто процитирую конец:
Обновление 2009/03/12: тем, кто заинтересован в защите приложений Wicket , также следует знать, что существует альтернатива Wicket-Security, которая называется wicket-auth-roles. Эта ветка даст вам хороший обзор статуса двух фреймворков. Интеграция wicket-auth-roles с Spring Безопасность описана здесь .
Одной из интересных особенностей wicket-auth-roles является возможность настраивать авторизацию с помощью аннотаций Java . Мне он кажется более элегантным, чем централизованный файл конфигурации. Здесь есть пример .
Основываясь на информации выше и той, которую вы предоставили, и поскольку я тоже предпочитаю аннотации, я бы выбрал Wicket-Auth-Roles с Spring Security (то есть руководство 2 ). Расширение AuthenticatedWebApplication не должно быть проблемой, поскольку этот класс расширяет WebApplication . И извлечение объекта приложения из контекста Spring с помощью SpringWebApplicationFactory также должно работать.
И если ваши опасения действительно серьезны, это было бы довольно легко и быстро подтвердить с помощью тестовой IMO:)
Мы используем Wicket-security в течение многих лет, и мы использовали его вместе с файлами jaas и с аннотациями. Определение файлов jaas - довольно сложная задача, а их обслуживание практически невозможно ...
С помощью аннотаций нужно определять действия и принципы для каждой страницы. Это требует много времени, но позволяет пользователю динамически определять роли и полномочия. Также можно протестировать всех принципалов с помощью WicketTester.
Каждый из 3 пакетов имеет свои (отрицательные) преимущества, это дело вкуса, а также зависит от размера приложения.