Сиро против SpringSecurity

Ответ 1

Я тоже согласен с тем, что Spring Безопасность слишком сложна (для меня). Конечно, они сделали все, чтобы уменьшить сложность, например создание пользовательских пространств имен XML, чтобы уменьшить количество XML-конфигурации, но для меня они не затрагивают мою личную основную проблему с помощью Spring Безопасность: ее имена и понятия часто запутываются в общий для меня. Трудно просто "получить".

Во-вторых, вы начинаете использовать Сиро, но вы просто "получите". То, что было трудно понять в мире безопасности, гораздо легче понять. Вещи, которые невыносимо трудно использовать в JDK (например, Ciphers), упрощаются до уровня, который не только терпимо, но часто является радостью использования.

Например, как вы hash + salt пароль и base64 кодируете его в Java или Spring Security? Ни один из них не столь прост и интуитивен, как решение Сиро:

ByteSource salt = new SecureRandomNumberGenerator().nextBytes();
new Sha512Hash(password, salt).toBase64();

Нет необходимости в кодеках общего пользования или что-то еще. Просто майор Широ.

Теперь в отношении сред Spring большинство разработчиков Shiro используют Spring в качестве основной среды приложений. Это означает, что интеграция Siro 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, легче читать IMO.

Вы также найдете, что определение цепочек фильтров Shiro, вероятно, является самым простым способом определения общих цепей фильтров и правил безопасности на веб-сайтах! Гораздо приятнее, чем определять их в web.xml.

Наконец, Сиро предлагает экстремальную "возможность подключения". Вы увидите, что вы можете настроить и/или заменить практически все, что связано с архитектурой Shiro POJO и дружественной к инъекциям. Shiro по умолчанию почти все использует нормальные значения по умолчанию, и вы можете переопределить или настроить только то, что вам нужно.

В конце дня я думаю, что выбор одного из этих двух - это больше о вашей ментальной модели - какая из двух имеет больше смысла и более интуитивна для вас? Для некоторых это будет Сиро, для других это будет Spring Безопасность. Shiro отлично работает в средах Spring, поэтому я бы сказал, что выбирайте на основе того, какой из двух вам нравится больше, и имеет для вас наибольший смысл.

Подробнее об интеграции Shiro Spring: http://shiro.apache.org/spring.html

Ответ 2

У меня нет опыта использования Shiro, и я "частично" согласен с тем, что вы говорили о безопасности Spring. До Spring Безопасность 3.x, Spring Безопасность (или 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 Безопасность, когда она настроена, безопасность интегрирована в проект без проблем. Это как если бы код проекта не знал о существовании безопасности... и это хорошо, потому что это позволяет мне легко отсоединить или обновить компонент безопасности в будущем (например: изменить базу данных auth на LDAP/CAS авт).

Ответ 3

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

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

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

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

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

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

TL; DR: Оба мощные, но Сиро намного легче изучить.