Utilizzo di JDBCRealm per autenticare l'utente con Shiro

Question

Sto tentando di autenticare un servlet in esecuzione in Tomcat 6 utilizzando Shiro.

Ho il seguente file shiro.ini:

[main] 
ps = org.apache.shiro.authc.credential.DefaultPasswordService 
pm = org.apache.shiro.authc.credential.PasswordMatcher 
pm.passwordService = $ps 

aa = org.apache.shiro.authc.credential.AllowAllCredentialsMatcher 
sm = org.apache.shiro.authc.credential.SimpleCredentialsMatcher 

jof = org.apache.shiro.jndi.JndiObjectFactory 
jof.resourceName = jdbc/UserDB 
jof.requiredType = javax.sql.DataSource 
jof.resourceRef = true 

realm = org.apache.shiro.realm.jdbc.JdbcRealm 
realm.permissionsLookupEnabled = true 
realm.credentialsMatcher = $pm 
; Note factories are automatically invoked via getInstance(), 
; see org.apache.shiro.authc.config.ReflectionBuilder::resolveReference 
realm.dataSource = $jof 

securityManager.realms = $realm 

[urls] 
/rest/** = authcBasic 
/prot/** = authcBasic 

e di seguito nel mio database:

mysql> select * from users; 
+----------+------------------+----------+----------------------------------------------+--------------------------+ 
| username | email   | verified | password          | password_salt   | 
+----------+------------------+----------+----------------------------------------------+--------------------------+ 
| admin | a.muys@********* |  1 | ojSiTecNwRF0MunGRvz3DRSgP7sMF9EAR77Ol/2IAY8= | eHp9XedrIUa5sECfOb+KOA== | 
+----------+------------------+----------+----------------------------------------------+--------------------------+ 
1 row in set (0.00 sec) 

Se uso il SimpleCredentialsManager è autentica bene contro una password in chiaro nella tabella utenti . Cercando di usare il PasswordMatcher è stato estremamente frustrante.

La password e password_salt sono state ottenute tramite l'utilità shiro-tools Hasher.

Quando si tenta di eseguire l'autenticazione contro una base HelloWorld servlet che uso per la prova (percorso = riposo/ciao, context =/WS), ottengo il seguente nei registri:

15:35:38.667 [http-8080-2] TRACE org.apache.shiro.util.ClassUtils - Unable to load clazz named [ojSiTecNwRF0MunGRvz3DRSgP7sMF9EAR77Ol/2IAY8=] from class loader [WebappClassLoader 
    context: /ws 
    delegate: false 
    repositories: 
    /WEB-INF/classes/ 
----------> Parent Classloader: 
org.apache.catalina.loader.StandardClassLoader@79ddd026 
] 

(log completi a https://gist.github.com/recurse/5915693)

Sembra che stia cercando di caricare la mia password con hash come nome di classe. È un bug o un errore di configurazione da parte mia? Se si tratta di un bug, come posso aggirarlo? Se si tratta di un errore di configurazione, cosa mi manca?

Answer 1

In primo luogo, grazie per aver fornito molte informazioni su questa domanda: è molto più semplice fornire una risposta.

Osservando l'elenco di righe del database di esempio, non sembra che si stia memorizzando l'output che si aspetta da PasswordService durante l'esecuzione di un confronto di password con hash. Per esempio:

$ java -jar ~/.m2/repository/org/apache/shiro/tools/shiro-tools-hasher/1.2.2/shiro-tools-hasher-1.2.2-cli.jar -p 
Password to hash: 
Password to hash (confirm): 
$shiro1$SHA-256$500000$uxaA2ngfdxdXpvSWzpuFdg==$hOJZc+3+bFYYRgVn5wkbQL+m/FseeqDtoM5mOiwAR3E= 

la stringa che inizia con $shiro1$ è quello che ci si salva alla colonna password nel database. Non è necessaria una colonna di sale separata in quanto tutte le informazioni richieste da Shiro sono nella stringa $shiro1$....

Il DefaultPasswordService utilizza gli stessi parametri di configurazione predefiniti (SHA-256, 500.000 iterazioni, ecc.) Quindi se si utilizza lo strumento CLI di Hasher come illustrato sopra (nessuna configurazione di algoritmo hash extra), non è necessario personalizzare ulteriormente il POJO DefaultPasswordService. Tuttavia, se si modificano i parametri di hashing sulla CLI, è necessario assicurarsi che gli stessi parametri siano configurati sul bean DefaultPasswordService (e/o sul suo HashingService interno).

Se si è ancora in fase di test e si può modificare lo schema del DB, si consiglia di farlo ora per disporre di un singolo campo password che memorizza la stringa $shiro1$.... Poi si utilizza il PasswordService come documentato qui sotto Uso:

http://shiro.apache.org/static/current/apidocs/org/apache/shiro/authc/credential/PasswordService.html