Attualmente sto valutando i framework di sicurezza basati su Java, sono un utente di Spring 3.0, quindi SpringSecurity sarebbe stata la scelta giusta, ma la sicurezza di Spring sembra soffrire di eccessiva complessità, certamente non sembra che stia rendendo la sicurezza più facile da implementare, Shiro sembra essere molto più coerente e più facile da capire. Sto cercando elenchi di pro e contro tra questi due quadri.
Risposte:
Anch'io sono d'accordo sul fatto che Spring Security sia troppo complicata (per me). Certo, hanno fatto cose per ridurre la complessità, come la creazione di spazi dei nomi XML personalizzati per ridurre la quantità di configurazione XML, ma per me questi non risolvono il mio problema personale fondamentale con Spring Security: i suoi nomi e concetti sono spesso confusi in generale per me. È difficile semplicemente "ottenerlo".
Nel momento in cui inizi a utilizzare Shiro, lo capisci e basta. Ciò che era difficile da capire nel mondo della sicurezza è molto più facile da capire. Le cose che sono insopportabilmente difficili da usare nel JDK (ad es. Ciphers) sono semplificate a un livello non solo sopportabile, ma spesso piacevole da usare.
Ad esempio, come si fa a hash + salt una password e base64 a codificarla in Java o Spring Security? Né sono semplici e intuitivi come la soluzione di Shiro:
ByteSource salt = new SecureRandomNumberGenerator().nextBytes();
new Sha512Hash(password, salt).toBase64();Non c'è bisogno di codec comuni o altro. Solo il barattolo Shiro.
Ora, per quanto riguarda gli ambienti Spring, la maggior parte degli sviluppatori Shiro usa Spring come ambiente applicativo principale. Ciò significa che l'integrazione di Shiro Spring è eccezionale e funziona tutto eccezionalmente bene. Puoi stare certo che se stai scrivendo un'app Spring, avrai un'esperienza di sicurezza completa.
Ad esempio, considera l'esempio di configurazione Spring XML in un altro post di questo thread. Ecco come faresti (essenzialmente) la stessa cosa in 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>Sebbene leggermente più dettagliato dell'altro esempio di primavera, è più facile leggere l'IMO.
Scoprirai anche che l'uso delle definizioni della catena di filtri di Shiro è probabilmente il modo più semplice per definire catene di filtri generali e regole di sicurezza basate sul Web di sempre! Molto più bello che definirli in web.xml.
Infine, Shiro offre anche estrema "innestabilità". Vedrai che puoi configurare e / o sostituire praticamente qualsiasi cosa grazie all'architettura POJO / iniezione-friendly di Shiro. Per impostazione predefinita, Shiro assume quasi tutte le impostazioni predefinite e puoi sostituire o configurare solo ciò di cui hai bisogno.
Alla fine della giornata, penso che scegliere uno di questi due sia qualcosa di più per il tuo modello mentale - quale dei due ha più senso ed è più intuitivo per te? Per alcuni sarà Shiro, per altri sarà Spring Security. Shiro funziona alla grande in ambienti primaverili, quindi direi di scegliere in base a quale dei due ti piace di più e ha più senso per te.
Per ulteriori informazioni sull'integrazione di Shiro in primavera: http://shiro.apache.org/spring.html
Non ho esperienza con Shiro e sono "parzialmente" d'accordo con quello che hai detto su Spring Security. Prima di Spring Security 3.x, Spring Security (o Acegi) era molto doloroso da configurare. Una semplice configurazione basata su ruoli richiederà almeno 140 righe di configurazione XML criptica ... Lo so perché ho contato le righe da solo. È stato qualcosa che hai impostato una volta e preghi che funzionerà per sempre senza che tu tocchi nuovamente la configurazione, perché puoi assicurarti di aver dimenticato cosa significa tutta la configurazione. :)
Con Spring Security 3.x, è notevolmente migliorato. Introduce lo securityspazio dei nomi che riduce drasticamente la configurazione da 140 righe a ~ 30 righe. Ecco un esempio di Spring Security 3.x di uno dei miei progetti: -
<?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>Il bello di Spring Security 3.x è che è estremamente configurabile, il che contribuisce a uno dei principali svantaggi: troppo complicato da capire. La documentazione non è facile da leggere neanche perché ho solo parzialmente familiarità con alcuni dei termini usati da Spring Security. Tuttavia, le opzioni sono disponibili se è necessario creare la configurazione personalizzata o controllare la granularità della sicurezza. Altrimenti, è possibile attenersi alle <30 righe precedenti per eseguire un controllo di sicurezza basato sul ruolo.
Quello che mi piace davvero di Spring Security è che una volta impostato, la sicurezza viene integrata perfettamente nel progetto. È come se il codice del progetto attuale non conoscesse l'esistenza della sicurezza ... e questo è un bene, perché mi consente di staccare o aggiornare facilmente il componente di sicurezza in futuro (es: cambiare l'autorizzazione del database in LDAP / CAS auth).
Ho usato Spring Security (versione 3.1) per alcuni mesi e ne sono rimasto abbastanza soddisfatto. È davvero potente e ha alcune funzionalità molto belle, soprattutto dopo aver implementato tutto a mano come facevo prima! È stato però, come ho letto da qualche parte, una sorta di qualcosa che hai impostato una volta vicino all'inizio dello sviluppo dell'app, e poi prega affinché continui a funzionare fino alla fine, perché se devi andare a sistemarlo dovrai probabilmente hai dimenticato la maggior parte delle cose che dovevi parametrizzare.
Ma poi è arrivato un nuovo progetto, con requisiti di sicurezza più complessi. In breve, abbiamo dovuto implementare una sorta di SSO personalizzato tra un paio di webapp correlate.
Sapevo esattamente cosa volevo ottenere in termini di logica HTTP, cookie, ID di sessione e cose e cosa dovrebbe accadere in quale ordine, ma ho trascorso la parte migliore di una giornata alle prese con le API di Spring Security e ancora non riuscivo a capire capire esattamente quale classe o interfaccia devo implementare o sovrascrivere e come inserirle nel contesto. L'intera API sembrava davvero complessa e un po 'esoterica a volte. E mentre il documento è abbastanza buono per i casi d'uso generali e anche per alcune personalizzazioni, non è andato abbastanza in profondità per coprire le mie esigenze.
Dopo aver letto le risposte qui e in alcuni altri posti sul web, ho avuto l'impressione che Shiro fosse più facile da capire e personalizzare in base alle mie esigenze. Quindi ho provato.
E sono contento di averlo fatto, perché dopo una giornata di lavoro sono riuscito a imparare abbastanza sulle API non solo per impostare un sistema di autenticazione e autorizzazione di base nella mia webapp Spring senza problemi, ma anche per implementare il comportamento SSO personalizzato che ero cercando. Ho dovuto estendere solo 2 o 3 classi e il tutto ha richiesto solo circa 25 righe di configurazione XML nel mio contesto primaverile.
Quindi, in conclusione, sulla facilità d'uso e sugli aspetti della curva di apprendimento, Shiro è davvero abbastanza simpatico, e penso che probabilmente lo seguirò in futuro, a meno che non incontri alcune funzionalità mancanti o altri problemi (che non ho finora).
TL; DR: Entrambi sono potenti, ma Shiro è molto più facile da imparare.