Shiro contre SpringSecurity [fermé]

J'évalue actuellement des cadres de sécurité basés sur Java, je suis un utilisateur de Spring 3.0, 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 que cela facilite la mise en œuvre de la sécurité, Shiro semble être beaucoup plus cohérent et plus facile à comprendre. Je recherche des listes de pour et contre entre ces deux cadres.

Je suis moi aussi d'accord pour dire que Spring Security me semble trop compliqué. Bien sûr, ils ont fait des choses pour réduire la complexité, comme la création d'espaces de noms XML personnalisés pour réduire la quantité de configuration XML, mais pour moi, cela ne résout pas mon problème fondamental personnel avec Spring Security: ses noms et ses concepts sont souvent déroutants en général pour moi. Il est difficile de simplement «comprendre».

À la seconde où vous commencez à utiliser Shiro, vous «comprenez». Ce qui était difficile à comprendre dans le monde de la sécurité est tout simplement beaucoup plus facile à comprendre. Les choses qui sont insupportablement difficiles à utiliser dans le JDK (par exemple les chiffrements) sont simplifiées à un niveau qui n'est pas seulement supportable, mais souvent agréable à utiliser.

Par exemple, comment hacher + saler un mot de passe et l'encoder en base64 dans Java ou Spring Security? Ni l'un ni l'autre ne sont aussi simples et intuitifs que la solution de Shiro:

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

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

À présent, 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 Spring de Shiro 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érez l'exemple de configuration Spring XML dans un autre article de ce fil de discussion. Voici comment vous feriez (essentiellement) la même chose à 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 qu'un peu plus verbeux que l'autre exemple de Spring, il est plus facile de lire IMO.

Vous constaterez également que l'utilisation des définitions de chaînes de filtres de Shiro est probablement le moyen le plus simple de définir des chaînes de filtres générales et des règles de sécurité basées sur le Web! Bien plus agréable que de les définir dans web.xml.

Enfin, Shiro offre également une `` connectivité '' 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 par défaut presque tout sur des valeurs par défaut saines et vous pouvez remplacer ou configurer uniquement ce dont vous avez besoin.

En fin de compte, je pense que choisir l'un ou l'autre de ces deux éléments concerne davantage votre modèle mental - lequel des deux a le plus de sens et est 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 printaniers, je dirais donc que vous choisissez en fonction de celui des deux qui vous plaît le plus et qui a le plus de sens pour vous.

Pour en savoir plus sur l'intégration Spring de Shiro: http://shiro.apache.org/spring.html

Je n'ai pas d'expérience avec Shiro, et je suis "partiellement" 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 prendra au moins 140 lignes de configuration XML cryptique ... Je le sais parce que j'ai en fait 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 ne touchiez à nouveau la configuration, car vous pouvez vous assurer que vous avez oublié ce que signifie toute la configuration. :)

Avec Spring Security 3.x, il s'est considérablement amélioré. Il introduit un securityespace de noms qui raccourcit considérablement la configuration de 140 lignes à ~ 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 est qu'il est extrêmement configurable, ce qui contribue à l'un des principaux inconvénients: trop compliqué à comprendre. La documentation n'est pas non plus facile à lire car je ne connais que partiellement certains des termes utilisés par Spring Security. Cependant, les options sont disponibles si vous avez besoin de créer votre configuration personnalisée ou de contrôler la 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 avec Spring Security, c'est qu'une fois qu'il est configuré, la sécurité est intégrée au projet de manière transparente. C'est comme si le code réel du projet 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 (ex: changer l'authentification de la base de données en LDAP / CAS auth).

J'utilisais Spring Security (version 3.1) depuis quelques mois et j'en étais plutôt satisfait. Il est vraiment puissant et possède des fonctionnalités très intéressantes, surtout après avoir tout implémenté à la main comme avant! C'était cependant, comme je l'ai lu quelque part, une sorte de quelque chose que vous avez configuré une fois vers le début du développement de l'application, puis priez pour que cela continue à fonctionner jusqu'à la fin, car si vous devez aller le réparer, vous avez probablement oublié la plupart des choses que vous deviez paramétrer.

Mais un nouveau projet est arrivé, avec des exigences de sécurité plus complexes. En bref, nous avons dû implémenter une sorte de SSO personnalisé entre quelques 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 d'autres choses, et ce qui devrait se passer dans quel ordre, mais j'ai passé la majeure partie de la journée à lutter avec les API Spring Security, et je ne pouvais toujours pas comprendre exactement quelle classe ou interface je devrais implémenter ou remplacer, et comment les brancher dans le contexte. L'ensemble de l'API semblait vraiment complexe et parfois un peu ésotérique. Et bien que la documentation soit assez bonne pour les cas d'utilisation généraux et même pour certaines personnalisations, elle n'est pas suffisamment approfondie 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 selon mes besoins. Alors je l'ai essayé.

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

Donc, en conclusion, sur la facilité d'utilisation et les aspects de la courbe d'apprentissage, Shiro est vraiment très sympathique, et je pense que j'irai probablement avec lui à l'avenir, à moins que je ne rencontre des fonctionnalités manquantes ou un autre problème (que je n'ai pas jusque là).

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