Широ против SpringSecurity [закрыто]

132

В настоящее время я оцениваю фреймворки безопасности на основе Java, я являюсь пользователем Spring 3.0, поэтому мне показалось, что SpringSecurity будет правильным выбором, но безопасность Spring, похоже, страдает от чрезмерной сложности, это, конечно, не похоже, что это облегчает реализацию безопасности, Широ кажется более последовательным и понятным. Я ищу списки плюсов и минусов этих двух фреймворков.

военно-картографическая служба
источник

Ответы:

118

Я тоже согласен с тем, что 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

Les Hazlewood
источник
Я прочитал все это перед тем, как начать использовать сиро. Аннотации Shiro, похоже, страдают некоторыми проблемами весной. Информация о том, как их решить, очень сложна, и в stackoverflow есть различные сообщения (1 или 2 опубликованы мной), на которые большую часть времени не было ответов. Я серьезно думал, что мне нужно перейти на весеннюю охрану, несмотря на то, что там говорилось о сложностях, поэтому я уверен, что у меня будут люди, которые укажут мне правильное направление.
черный сенсей
@blacksensei вы решили упомянутые вами проблемы? Остаться с Широ или перейти на Spring Security?
Александр Сурафель
Привет, @AlexanderSuraphel, я не перешел на Spring для этого проекта. Его активно использует коллега. И я планирую протестировать его в проекте с весенней загрузкой. У меня это прекрасно работает. Все остальные проекты я перенесу. Вот так просто
черный сенсей
Хорошо, я решаю попробовать Широ в следующем проекте !!
Эрик Ван
32

У меня нет опыта использования Shiro, и я «частично» согласен с тем, что вы сказали о Spring Security. До Spring Security 3.x настройка Spring Security (или Acegi) была очень сложной. Простая конфигурация на основе ролей потребует не менее 140 строк загадочной конфигурации XML ... Я знаю это, потому что на самом деле сам считал строки. Это было что-то, что вы настраивали один раз, и вы молитесь, чтобы это работало вечно, не касаясь конфигурации снова, потому что вы можете быть уверены, что забыли, что означает вся конфигурация. :)

В Spring Security 3.x он значительно улучшился. Он вводит securityпространство имен, которое резко сокращает конфигурацию со 140 строк до ~ 30 строк. Вот пример Spring Security 3.x одного из моих проектов: -

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:security="http://www.springframework.org/schema/security" 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
                        http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security.xsd">

    <security:http auto-config="true">
        <security:form-login login-page="/index.do" authentication-failure-url="/index.do?login_error=1" default-target-url="/index.do"
            always-use-default-target="true" />
        <security:logout logout-success-url="/index.do" />
        <security:intercept-url pattern="/secure/**" access="ROLE_ADMIN,ROLE_USER" />
        <security:intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" />
    </security:http>

    <bean id="customAuthenticationProvider" class="my.project.CustomAuthenticationProviderImpl">
        ...
    </bean>

    <security:authentication-manager>
        <security:authentication-provider ref="customAuthenticationProvider" />
    </security:authentication-manager>

</beans>

Прелесть Spring Security 3.x в том, что она чрезвычайно настраиваема, что приводит к одному из основных недостатков: слишком сложен для понимания. Документацию тоже нелегко читать, потому что я лишь частично знаком с некоторыми используемыми терминами Spring Security. Однако есть варианты, если вам нужно создать свою индивидуальную конфигурацию или контролировать степень детализации вашей безопасности. Или же вы можете придерживаться приведенных выше <30 строк, чтобы выполнить проверку безопасности на основе ролей.

Что мне действительно нравится в Spring Security, так это то, что после ее настройки безопасность интегрируется в проект без проблем. Как будто фактический код проекта не знает о существовании защиты ... и это хорошо, потому что это позволяет мне легко отсоединять или обновлять компонент безопасности в будущем (например, изменить аутентификацию базы данных на LDAP / CAS авт).

LIMC
источник
Не могли бы вы сказать что-нибудь о том, когда лучше перейти от безопасности на основе контейнеров к таким альтернативам, как shiro или другим? См. Более сфокусированный вопрос здесь: stackoverflow.com/questions/7782720/…
Раджат Гупта
10
Я пробовал и сиро, и пружинную защиту, и лично считаю, что сиро довольно легко понять, а пружинная безопасность кажется сложной. Мне еще предстоит выяснить, как настроить разрешения, которые я могу назначать ролям / группам / пользователям в весенней безопасности (я думаю, что ACL может быть решением). С Сиро это было довольно легко. Я не эксперт по весенней безопасности или сиро, это просто мой личный опыт как пользователя обоих.
Sudhir N
@sudhir Вы сталкивались с какими-либо узкими местами в конфигурации Широ?
Александр Сурафель
Он работал для всех наших пользовательских случаев, я думаю, что его можно адаптировать для большинства ситуаций. Какой у вас вариант использования?
Sudhir N
21

Я использовал Spring Security (версия 3.1) несколько месяцев и был им вполне доволен. Это действительно мощно и имеет очень приятную функцию, особенно после того, как я реализовал все вручную, как я это делал раньше! Хотя, как я где-то читал, что-то вроде того, что вы настраиваете один раз в начале разработки приложения, а затем молитесь, чтобы оно продолжало работать до конца, потому что, если вам придется пойти и исправить, вы вероятно, вы забыли большую часть того, что вам нужно было параметрировать.

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

Я точно знал, чего хочу достичь с точки зрения логики HTTP, файлов cookie, идентификаторов сеансов и прочего, и что должно происходить в каком порядке, но большую часть дня я провел, борясь с API Spring Security, и все еще не мог понять точно определить, какой класс или интерфейс я должен реализовать или переопределить, и как подключить их к контексту. Весь API казался действительно сложным и временами немного эзотерическим. И хотя документ достаточно хорош для общих случаев использования и даже для некоторой настройки, он недостаточно углублен, чтобы удовлетворить мои потребности.

Прочитав ответы здесь и в некоторых других местах в Интернете, у меня сложилось впечатление, что Широ будет легче понять и настроить в соответствии с моими потребностями. Итак, я попробовал.

И я рад, что сделал это, потому что после дня работы над этим мне удалось узнать достаточно об API не только для того, чтобы без проблем настроить базовую систему аутентификации и авторизации в моем веб-приложении Spring, но и для реализации настраиваемого поведения SSO, которым я был находясь в поиске. Мне нужно было расширить только 2 или 3 класса, и все это заняло всего около 25 строк конфигурации XML в моем контексте Spring.

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

TL; DR: Оба они сильны, но Широ намного легче научиться.

Пьер Генри
источник
Пьер, спасибо за вклад. Мне тоже нужно ссо. Я не думаю, что вы могли бы показать несколько примеров того, какие классы вам нужно было открыть.
KingAndrew
@KingAndrew: в двух словах, я реализовал свои собственные AuthorizingRealm, AuthenticationToken и AuthenticationFilter. И все необходимые фильтры и сантехника. Но то, что я делаю, не является «нормальным» sso, оно основано на токене, который хранится в БД, который является общим для двух приложений. Поэтому я не использую отдельный сервер SSO.
Пьер Анри