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