Używanie JDBCRealm do uwierzytelniania użytkownika za pomocą Shiro

Question

Próbuję uwierzytelnić serwlet działający w Tomcat 6 przy użyciu Shiro.

Mam następujący plik 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 

i następujący w mojej bazy danych:

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) 

Jeśli używam SimpleCredentialsManager uwierzytelnia grzywny przeciwko zwykłego tekstu hasła w tabeli użytkowników . Próba użycia telefonu PasswordMatcher była wyjątkowo frustrująca.

Hasło i password_salt zostały uzyskane za pomocą narzędzia shiro-tools Hasher.

Kiedy próbuję uwierzytelnić podstawowego HelloWorld serwletu używam do testowania (path = reszta/hello, context =/WS), otrzymuję następujący w dziennikach:

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 
] 

(pełny raport na https://gist.github.com/recurse/5915693)

Wygląda na to, że próbuję załadować moje hashowane hasło jako nazwę klasy. Czy to błąd, czy błąd konfiguracji z mojej strony? Jeśli jest to błąd, jak mogę go obejść? Jeśli jest to błąd konfiguracji, czego mi brakuje?

Answer 1

Po pierwsze, dziękuję za dostarczenie dużej ilości informacji na to pytanie - to znacznie ułatwia udzielenie odpowiedzi.

Patrząc na przykładową listę wierszy w bazie danych, nie wydaje się, że przechowuje się dane wyjściowe oczekiwane przez usługę PasswordService podczas porównywania hashowanych haseł. Na przykład:

$ 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= 

ciąg znaków, który rozpoczyna się $shiro1$ jest czego można zapisać się do kolumny w bazie danych password. Nie ma potrzeby stosowania oddzielnej kolumny z solą, ponieważ wszystkie informacje, jakich potrzebuje Shiro, znajdują się w ciągu znaków $shiro1$....

Urządzenie DefaultPasswordService używa tych samych domyślnych parametrów konfiguracyjnych (SHA-256, 500 000 iteracji, itp.), Więc jeśli używasz narzędzia Hasher CLI, jak pokazano powyżej (bez dodatkowej konfiguracji algorytmu skrótu), nie musisz dostosuj POJO DefaultPasswordService dalej. Jeśli jednak zmienisz parametry mieszania w interfejsie CLI, musisz upewnić się, że te same parametry są skonfigurowane na fasoli DefaultPasswordService (i/lub jej wewnętrznej usłudze HashingService).

Jeśli nadal testujesz i możesz zmienić swój schemat bazy danych, polecam zrobić to teraz, aby mieć jedno pole hasła, które przechowuje ciąg znaków $shiro1$.... Następnie użyć PasswordService udokumentowane tutaj pod Wykorzystanie:

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