web-dev-qa-db-fra.com

Shiro vs. Spring Security

J'évalue actuellement les infrastructures de sécurité basées sur Java, je suis un utilisateur de Spring 3.0 et il semblait donc que SpringSecurity serait le bon choix, mais la sécurité de Spring semble souffrir d'une complexité excessive, il ne semble certainement pas en être ainsi. rendant la sécurité plus facile à mettre en œuvre, Shiro semble être beaucoup plus cohérent et plus facile à comprendre. Je cherche des listes de pour et de contre entre ces deux cadres.

javaspringspring-securityshiro
132
ams

Moi aussi je suis d'accord pour dire que Spring Security est trop compliqué (pour moi). Bien sûr, ils ont pris des mesures pour réduire la complexité, comme la création d'espaces de nom XML personnalisés pour réduire le nombre de configurations XML, mais pour moi, ils ne s'adressent pas my problème fondamental personnel avec Spring Security: ses noms et ses concepts sont souvent source de confusion pour moi. Il est difficile de simplement "l'obtenir".

À la seconde où vous commencez à utiliser Shiro, vous comprenez juste. Ce qui était difficile à comprendre dans le monde de la sécurité est encore plus facile à comprendre. Les choses qui sont insupportablement difficiles à utiliser dans le JDK (par exemple, Ciphers) sont simplifiées à un niveau qui n’est pas simplement supportable, mais qui est souvent un plaisir à utiliser.

Par exemple, comment hacher + salir un mot de passe et comment le coder en base64 en Java ou Spring Security?). Ils ne sont pas aussi simples et intuitifs que la solution de Shiro:

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

Pas besoin de codec commons ou quoi que ce soit d'autre. Juste le pot Shiro.

En ce qui concerne les environnements Spring, la plupart des développeurs Shiro utilisent Spring comme environnement d’application principal. Cela signifie que l'intégration de Shiro Spring est superbe et que tout fonctionne exceptionnellement bien. Vous pouvez être assuré que si vous écrivez une application Spring, vous bénéficierez d'une expérience de sécurité complète.

Par exemple, considérons l'exemple de configuration Spring XML dans une autre publication de ce fil de discussion. Voici comment vous feriez (essentiellement) la même chose dans Shiro:

<?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>

Bien que légèrement plus verbeux que l’autre exemple Spring, il est plus facile de lire OMI.

Vous constaterez également que les définitions de chaînes de filtres de Shiro sont probablement le moyen le plus simple de définir des chaînes de filtres générales et des règles de sécurité Web! Beaucoup plus agréable que de les définir dans web.xml.

Enfin, Shiro offre également une "connectabilité" extrême. Vous verrez que vous pouvez configurer et/ou remplacer à peu près n'importe quoi grâce à l'architecture POJO/injection-friendly de Shiro. Shiro utilise presque tous les paramètres par défaut pour conserver les paramètres par défaut et vous pouvez remplacer ou configurer uniquement ce dont vous avez besoin.

À la fin de la journée, je pense que choisir l’un ou l’autre de ces deux principes dépend davantage de votre modèle mental - lequel des deux est le plus logique et le plus intuitif pour vous? Pour certains, ce sera Shiro, pour d'autres, ce sera Spring Security. Shiro fonctionne très bien dans les environnements de printemps. Je vous conseillerais donc de choisir lequel de ces deux types de jeu vous plaît le plus et qui vous convient le mieux.

Pour plus d'informations sur l'intégration Spring de Shiro: http://shiro.Apache.org/spring.html

117
Les Hazlewood

Je n'ai pas d'expérience dans l'utilisation de Shiro et je suis en partie d'accord avec ce que vous avez dit à propos de Spring Security. Avant Spring Security 3.x, Spring Security (ou Acegi) était très difficile à mettre en place. Une configuration simple basée sur les rôles nécessitera au moins 140 lignes de configuration XML cryptique ... Je le sais car j'ai compté les lignes moi-même. C’est quelque chose que vous avez configuré une fois, et vous priez pour que cela fonctionne pour toujours sans que vous touchiez à nouveau la configuration, car vous pouvez vous assurer que vous avez oublié ce que toute la configuration signifie. :)

Avec Spring Security 3.x, il s’est énormément amélioré. Il introduit un espace de noms security qui réduit considérablement la configuration de 140 lignes à environ 30 lignes. Voici un exemple de Spring Security 3.x de l'un de mes projets: -

<?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>

La beauté de Spring Security 3.x réside dans le fait qu’il est extrêmement configurable, ce qui contribue à l’un des principaux inconvénients: trop compliqué à comprendre. La documentation n'est pas facile à lire non plus, car je ne connais que partiellement certains termes utilisés par Spring Security. Toutefois, les options sont disponibles si vous devez créer votre configuration personnalisée ou contrôler le degré de granularité de votre sécurité. Sinon, vous pouvez vous en tenir aux <30 lignes ci-dessus pour effectuer un contrôle de sécurité basé sur les rôles.

Ce que j'aime vraiment dans Spring Security, une fois qu'il est configuré, la sécurité est intégrée de manière transparente dans le projet. C'est comme si le code du projet lui-même ne connaissait pas l'existence de la sécurité ... et c'est bien, car cela me permet de détacher ou de mettre à niveau facilement le composant de sécurité à l'avenir (par exemple: changer l'autorisation de la base de données en LDAP/CAS auth).

32
limc

J'utilisais Spring Security (version 3.1) depuis quelques mois et j'étais assez content. Il est vraiment puissant et possède une fonctionnalité très agréable, surtout après avoir tout implémenté à la main comme je le faisais auparavant! C’était bien, comme je l'ai lu quelque part, une sorte de chose que vous avez configurée une fois vers le début du développement de l'application, puis priez pour qu'elle continue de fonctionner jusqu'à la fin, car si vous devez y remédier, avez probablement oublié la plupart des choses que vous avez dû paramétrer.

Mais alors un nouveau projet est arrivé, avec des exigences de sécurité plus complexes. En bref, nous avons dû implémenter une sorte d’authentification unique personnalisée entre deux applications Web associées.

Je savais exactement ce que je voulais réaliser en termes de logique HTTP, de cookies, d'identifiants de session et autres, et ce qui devait se passer dans quel ordre, mais j'ai passé la plus grande partie de la journée à lutter avec les API de sécurité Spring, mais je ne pouvais toujours pas comprendre. exactement quelle classe ou interface je dois implémenter ou remplacer, et comment les intégrer au contexte. L’ensemble de l’API était très complexe et parfois un peu ésotérique. Et bien que la doc soit assez bonne pour les cas d'utilisation générale et même pour une personnalisation, elle n'est pas assez profonde pour couvrir mes besoins.

Après avoir lu les réponses ici et à d’autres endroits sur le Web, j’ai eu l’impression que Shiro serait plus facile à comprendre et à personnaliser à mes besoins. Alors j'ai essayé.

Et je suis heureux de l'avoir fait, car après une journée de travail, j'ai réussi à en apprendre assez sur les API, non seulement pour configurer sans problème un système d'authentification et d'autorisation de base dans ma webapp Spring, mais aussi pour implémenter le comportement SSO personnalisé que j'avais auparavant. à la recherche de. Je n’ai eu à étendre que 2 ou 3 classes, et l’ensemble n’a pris que 25 lignes de configuration XML dans mon contexte de printemps.

En conclusion, en ce qui concerne la facilité d'utilisation et les aspects liés à la courbe d'apprentissage, Shiro est vraiment très sympathique et je pense que j'y reviendrai probablement à l'avenir, à moins que je ne rencontre certaines fonctionnalités manquantes ou un autre problème (que je n'ai pas encore rencontré.) jusque là).

TL; DR: Les deux sont puissants, mais Shiro est beaucoup plus facile à apprendre.

21
Pierre Henry