Я тоже согласен с тем, что Spring Security кажется слишком сложным (для меня). Конечно, они сделали кое-что, чтобы уменьшить сложность, например, создали пользовательские пространства имен XML, чтобы уменьшить количество XML-конфигурации, но для меня это не решает мою личную фундаментальную проблему с Spring Security: его названия и концепции часто сбивают с толку в целом. меня. Трудно просто «понять».
Но как только вы начнете использовать Широ, вы просто «поняли». То, что было трудно понять в мире безопасности, понять гораздо легче. Вещи, которые невыносимо сложно использовать в JDK (например, шифры), упрощены до уровня, который не только терпим, но и часто приносит удовольствие.
Например, как вы хешируете + солируете пароль, а base64 кодируете его в Java или Spring Security? Ни одно из них не так просто и интуитивно понятно, как решение Широ:
ByteSource salt = new SecureRandomNumberGenerator().nextBytes();
new Sha512Hash(password, salt).toBase64();
Нет необходимости в общедоступном кодеке или чем-то еще. Просто банка Широ.
Что касается сред Spring, большинство разработчиков Shiro используют Spring в качестве основной среды приложений. Это означает, что интеграция Shiro с Spring великолепна, и все работает исключительно хорошо. Вы можете быть уверены, что если вы пишете приложение Spring, у вас будет всесторонняя безопасность.
Например, рассмотрим пример конфигурации Spring XML в другом посте в этой ветке. Вот как вы (по сути) сделали бы то же самое в Широ:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd>
<bean id="shiroFilter" class="org.apache.shiro.spring.web.ShiroFilterFactoryBean">
<property name="securityManager" ref="securityManager"/>
<property name="loginUrl" value="/login.jsp"/>
<property name="successUrl" value="/home.jsp"/>
<property name="unauthorizedUrl" value="/unauthorized.jsp"/>
<property name="filterChainDefinitions">
<value>
/secure/** = authc
/** = anon
</value>
</property>
</bean>
<bean id="securityManager" class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
<property name="realm" ref="myRealm"/>
</bean>
<bean id="myRealm" class="...">
...
</bean>
Хотя он немного более подробный, чем другой пример Spring, его легче читать.
Вы также обнаружите, что использование определений цепочек фильтров Широ, вероятно, является самым простым способом определения общих цепочек фильтров и правил безопасности в Интернете! Намного лучше, чем определять их в web.xml.
Наконец, Shiro также предлагает исключительную «подключаемость». Вы увидите, что вы можете настроить и / или заменить что угодно благодаря архитектуре Shiro, ориентированной на POJO / инъекции. Широ устанавливает по умолчанию почти все в разумные значения, и вы можете переопределить или настроить только то, что вам нужно.
В конце концов, я думаю, что выбор любого из этих двух больше связан с вашей ментальной моделью - какая из двух имеет больше смысла и является более интуитивной для вас? Для некоторых это будет Широ, для других - Spring Security. Широ отлично работает в весенних средах, поэтому я бы сказал, выбирайте, исходя из того, какой из двух вам нравится больше и имеет для вас наибольший смысл.
Подробнее об интеграции Shiro Spring: http://shiro.apache.org/spring.html
У меня нет опыта использования Shiro, и я «частично» согласен с тем, что вы сказали о Spring Security. До Spring Security 3.x настройка Spring Security (или Acegi) была очень сложной. Простая конфигурация на основе ролей потребует не менее 140 строк загадочной конфигурации XML ... Я знаю это, потому что на самом деле сам считал строки. Это было что-то, что вы настраивали один раз, и вы молитесь, чтобы это работало вечно, не касаясь конфигурации снова, потому что вы можете быть уверены, что забыли, что означает вся конфигурация. :)
В Spring Security 3.x он значительно улучшился. Он вводит
securityпространство имен, которое резко сокращает конфигурацию со 140 строк до ~ 30 строк. Вот пример Spring Security 3.x одного из моих проектов: -Прелесть Spring Security 3.x в том, что она чрезвычайно настраиваема, что приводит к одному из основных недостатков: слишком сложен для понимания. Документацию тоже нелегко читать, потому что я лишь частично знаком с некоторыми используемыми терминами Spring Security. Однако есть варианты, если вам нужно создать свою индивидуальную конфигурацию или контролировать степень детализации вашей безопасности. Или же вы можете придерживаться приведенных выше <30 строк, чтобы выполнить проверку безопасности на основе ролей.
Что мне действительно нравится в Spring Security, так это то, что после ее настройки безопасность интегрируется в проект без проблем. Как будто фактический код проекта не знает о существовании защиты ... и это хорошо, потому что это позволяет мне легко отсоединять или обновлять компонент безопасности в будущем (например, изменить аутентификацию базы данных на LDAP / CAS авт).
источник
Я использовал Spring Security (версия 3.1) несколько месяцев и был им вполне доволен. Это действительно мощно и имеет очень приятную функцию, особенно после того, как я реализовал все вручную, как я это делал раньше! Хотя, как я где-то читал, что-то вроде того, что вы настраиваете один раз в начале разработки приложения, а затем молитесь, чтобы оно продолжало работать до конца, потому что, если вам придется пойти и исправить, вы вероятно, вы забыли большую часть того, что вам нужно было параметрировать.
Но затем появился новый проект с более сложными требованиями к безопасности. Короче говоря, нам пришлось реализовать своего рода настраиваемую систему единого входа между парой связанных веб-приложений.
Я точно знал, чего хочу достичь с точки зрения логики HTTP, файлов cookie, идентификаторов сеансов и прочего, и что должно происходить в каком порядке, но большую часть дня я провел, борясь с API Spring Security, и все еще не мог понять точно определить, какой класс или интерфейс я должен реализовать или переопределить, и как подключить их к контексту. Весь API казался действительно сложным и временами немного эзотерическим. И хотя документ достаточно хорош для общих случаев использования и даже для некоторой настройки, он недостаточно углублен, чтобы удовлетворить мои потребности.
Прочитав ответы здесь и в некоторых других местах в Интернете, у меня сложилось впечатление, что Широ будет легче понять и настроить в соответствии с моими потребностями. Итак, я попробовал.
И я рад, что сделал это, потому что после дня работы над этим мне удалось узнать достаточно об API не только для того, чтобы без проблем настроить базовую систему аутентификации и авторизации в моем веб-приложении Spring, но и для реализации настраиваемого поведения SSO, которым я был находясь в поиске. Мне нужно было расширить только 2 или 3 класса, и все это заняло всего около 25 строк конфигурации XML в моем контексте Spring.
Итак, в качестве заключения, касательно простоты использования и аспектов кривой обучения, Широ действительно весьма симпатичен, и я думаю, что, вероятно, буду придерживаться его в будущем, если только я не столкнусь с некоторыми отсутствующими функциями или какой-либо другой проблемой (которой у меня не было). до сих пор).
TL; DR: Оба они сильны, но Широ намного легче научиться.
источник