Return-Path: X-Original-To: apmail-shiro-user-archive@www.apache.org Delivered-To: apmail-shiro-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5199917F5A for ; Thu, 30 Oct 2014 18:46:41 +0000 (UTC) Received: (qmail 82887 invoked by uid 500); 30 Oct 2014 18:46:41 -0000 Delivered-To: apmail-shiro-user-archive@shiro.apache.org Received: (qmail 82855 invoked by uid 500); 30 Oct 2014 18:46:41 -0000 Mailing-List: contact user-help@shiro.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@shiro.apache.org Delivered-To: mailing list user@shiro.apache.org Received: (qmail 82845 invoked by uid 99); 30 Oct 2014 18:46:41 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Oct 2014 18:46:41 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of thekonradzuse@hotmail.com designates 65.54.190.214 as permitted sender) Received: from [65.54.190.214] (HELO BAY004-OMC4S12.hotmail.com) (65.54.190.214) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Oct 2014 18:46:13 +0000 Received: from BAY173-W3 ([65.54.190.201]) by BAY004-OMC4S12.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 30 Oct 2014 11:46:11 -0700 X-TMN: [kk38TknoQ3H0UZDnDKCe//71xu4bN3da] X-Originating-Email: [thekonradzuse@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_a8aeb0d3-2702-41da-afe4-332a49ed7263_" From: Konrad Zuse To: "user@shiro.apache.org" Subject: RE: Configuring Shiro Programatically Date: Thu, 30 Oct 2014 14:46:11 -0400 Importance: Normal In-Reply-To: References: ,,,,,,,,,, MIME-Version: 1.0 X-OriginalArrivalTime: 30 Oct 2014 18:46:11.0442 (UTC) FILETIME=[C66B0D20:01CFF471] X-Virus-Checked: Checked by ClamAV on apache.org --_a8aeb0d3-2702-41da-afe4-332a49ed7263_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Very detailed=2C but from what you said "steve" logs in=2C but Robert does = not. I believe Steve is the correct way the hashed passwords are supposed to wor= k. The salt and hash are usually together it seems=2C but I'm not sure if = Steve has a salt attached or not. At least this is how the command line hasher works http://shiro.apache.org/command-line-hasher.html It will then ask you to enter the password and then confirm it:Password to = hash:=0A= Password to hash (confirm):=0A= When this command executes=2C it will print out the securely-salted-iterate= d-and-hashed password. For example:$shiro1$SHA-256$500000$eWpVX2tGX7WCP2J+j= MCNqw=3D=3D$it/NRclMOHrfOvhAEFZ0mxIZRdbcfqIBdwdwdDXW2dM=3D=0A= Take this value and place it as the password in the user definition line (f= ollowed by any optional roles) as defined in the INI Users Configuration do= cumentation. For example:[users]=0A= ...=0A= user1 =3D $shiro1$SHA-256$500000$eWpVX2tGX7WCP2J+jMCNqw=3D=3D$it/NRclMOHrfO= vhAEFZ0mxIZRdbcfqIBdwdwdDXW2dM=3D=0A= You will also need to ensure that the implicit iniRealm uses a CredentialsM= atcher that knows how to perform secure hashed password comparisons. So con= figure this in the [main] section as well:[main]=0A= ...=0A= passwordMatcher =3D org.apache.shiro.authc.credential.PasswordMatcher=0A= iniRealm.credentialsMatcher =3D $passwordMatcher=0A= ... Granted I believe there are ways to set the salt as another DB item=2C or e= ven from another server I believe I read. I wish there was more I could do to help=2C I will have to try my code and = see how it works or not. My buddy seemed to have everythign working when I helped him=2C so i'm not = too sure. Date: Thu=2C 30 Oct 2014 14:32:56 -0400 Subject: Re: Configuring Shiro Programatically From: rmiddleton@synexxus.com To: user@shiro.apache.org The salt is stored in the database. The salt is retrieved from the databas= e. The salt is ignored when calculating the hash of the password. The chec= k always fails. Here's the sequence that happens(note that this starts at the Authenticatin= gRealm level):1. Starting in getAuthenticationInfo of AuthenticatingRealm= =2C an AuthenticationInfo is looked up. This goes to getCachedAuthenticati= onInfo - this is null the first time=2C so this goes to doGetAuthentication= Info2. doGetAuthentication info is abstract=2C so it is delegated to the Jd= bcRealmClass3. In doGetAuthenticationInfo of JdbcRealm=2C the salt is retri= eved from the database and set in the SimpleAuthenticationInfo object that = this method returns.4. The SimpleAuthenticationInfo is passed with the toke= n to assertCredentialsMatch5. assertCredentialsMatch asks the CredentialsMa= tcher if the token is equal to the AuthenticationInfo6. The CredentialsMatc= her in this case is a PasswordMatcher. The relevant method is doCredential= sMatch.7. The PasswordMatcher then asks the PasswordService(a DefaultPasswo= rdService object) if the passwords match. However=2C DefaultPasswordServic= e looks at the saved information=2C and attempts to figure out the correct = hash format. 8. The discovered format is null=2C because there's no data i= n the hashed password.9. The password is hashed=2C but the salt data that w= as retrieved from the database is not used. The hashed password is not equ= al to the stored password. Login fails. At some point between steps 6 and 7 there is a bug=2C in that the DefaultPa= sswordService knows nothing about the salt that is retrieved from the datab= ase. The PasswordMatcher can pass information on the salt to the DefaultPa= sswordService=2C but it does not. This is because the HashingPasswordServi= ce does not have the capability to take in the salt on the password. For clarity=2C here's the database dump. User 'steve' can log in=2C user '= robert' cannot. username|password|password_saltrobert|ff72007e587a7be71ffa92b598fef97ec0de1= a1354a5e241f60d1806c9cd0351|64df10ba steve|$shiro1$SHA-256$500000$ODjsYh0x1ASOx3gdXa3iGg=3D=3D$d0AnmvEpA1fVfBZrU= Ks4u+lkVwNr1o1eBdg+rAgqRHE=3D| Steve's password is in the Shiro1Crypt format=2C which tells shiro what for= mula to use=2C the iteration times=2C the salt=2C and the hash. User rober= t's format has the hashed password in one database column=2C and the salt i= n the other database column(it is using the defaults of SHA-256 and 500=2C0= 00 iterations). JdbcRealm explicitly allows this format for the salt/passw= ord. Of course=2C I could be fundamentally misunderstanding how these passwords = are supposed to be stored in the database. I can store passwords in the Sh= iro1Crypt if needed=2C I was just surprised that the first way of storing t= he passwords didn't work. -Robert Middleton On Thu=2C Oct 30=2C 2014 at 1:13 PM=2C Konrad Zuse wrote: =0A= =0A= =0A= Set the salt and stuff via java=2C and then retrieve with your shiro.ini in= fo. Date: Thu=2C 30 Oct 2014 13:06:13 -0400 Subject: Re: Configuring Shiro Programatically From: rmiddleton@synexxus.com To: user@shiro.apache.org What's the proper way to report a bug on this? There's the ASF Shiro JIRA= =2C but it seems that it's not possible to report a bug in JIRA without hav= ing the correct permissions. -Robert Middleton On Thu=2C Oct 30=2C 2014 at 11:29 AM=2C Robert Middleton wrote: The queries should all be done through the JdbcRealm class=2C that has the = standard JDBC queries. I have figured out the problem though. It turns out that shiro is ignoring= the salt when attempting to set the password up. Since I have two columns= =2C one for the hashed password and one for the salt=2C it's correctly retr= ieving them but is not setting the salt when asking for the password to be = checked. It works fine as long as the database column is in the $shiro1 fo= rmat. -Robert Middleton On Wed=2C Oct 29=2C 2014 at 6:07 PM=2C Konrad Zuse wrote: =0A= =0A= =0A= This is my code=2C granted I will say I have not personally tested it=2C bu= t I helped another buddy finish his project so I believe this should work c= ompletely. I haven't tested it yet only because I was siill setting up my DB and I am = finishing up other things now. I'm not 100% sure about the line "# privateSalt needs to be base64-encoded = in shiro.ini but not in the Java code" as I got this from another source=2C= but I'm not sure why one would be and one wouldn't=2C so hopefully someone= else can answer that. # Hash Service Original values of PasswordServicehashService =3D org.apache= .shiro.crypto.hash.DefaultHashServicehashService.hashIterations =3D 500=2C0= 00hashService.hashAlgorithmName =3D SHA-256hashService.generatePublicSalt = =3D true # privateSalt needs to be base64-encoded in shiro.ini but not in the Java c= ode#Salt is randomly generated with the Secure Generator saltGenerator =3D org.apache.shiro.crypto.SecureRandomNumberGeneratorhashSe= rvice.privateSalt =3D saltGenerator.nextBytes.toBase64 #PasswordMatcherpasswordMatcher =3D org.apache.shiro.authc.credential.Passw= ordMatcher #PasswordServicepasswordService =3D org.apache.shiro.authc.credential.Defau= ltPasswordServicepasswordService.hashService =3D $hashServicepasswordMatche= r.passwordService =3D $passwordService #DataSource which is our Databaseds =3D ds.serverName =3D ds.port =3D ds.d= atabaseName =3D ds.user =3D ds.password =3D jdbcRealm =3D org.apache.shir= o.realm.jdbc.JdbcRealm jdbcRealm.permissionsLookupEnabled =3D true jdbcReal= m.authenticationQuery =3D SELECT password FROM Company WHERE username =3D ?= jdbcRealm.userRolesQuery =3D SELECT roles FROM Company WHERE username =3D = ? jdbcRealm.permissionsQuery =3D SELECT permissions FROM Company WHERE role= _name =3D ? jdbcRealm.credentialsMatcher =3D $passwordMatcher jdbcRealm.dat= aSource=3D$ds securityManager.realms =3D $jdbcRealm I'm assuming all of your queries and such are done within your SQLiteConfig= config =3D new SQLiteConfig()=3B class? Is this your own class=2C or is t= his one of the predefined classes? From: thekonradzuse@hotmail.com To: user@shiro.apache.org Subject: RE: Configuring Shiro Programatically Date: Wed=2C 29 Oct 2014 17:54:38 -0400 =0A= =0A= =0A= Weird... It looks like there is an issue with the class loader=2C however = why does it say "Unable to load class" then "Unabl=3Be to load clazz....???= " Something is weird there. Date: Wed=2C 29 Oct 2014 17:40:39 -0400 Subject: Re: Configuring Shiro Programatically From: rmiddleton@synexxus.com To: user@shiro.apache.org Oh=2C that makes a bit more sense now. I've used the PasswordService and P= asswordManager now=2C but I'm still unable to authenticate. I turned up de= bugging some more=2C and now I get the following output:17:21:55.123 [SSHTh= read] TRACE org.apache.shiro.util.ClassUtils - Unable to load clazz named [= ff72007e587a7be71ffa92b598fef97ec0de1a1354a5e241f60d1806c9cd0351] from clas= s loader [sun.misc.Launcher$AppClassLoader@13cb1eb] 17:21:55.123 [SSHThread] TRACE org.apache.shiro.util.ClassUtils - Unable to= load class named [ff72007e587a7be71ffa92b598fef97ec0de1a1354a5e241f60d1806= c9cd0351] from the thread context ClassLoader. Trying the current ClassLoa= der... 17:21:55.124 [SSHThread] TRACE org.apache.shiro.util.ClassUtils - Unable to= load clazz named [ff72007e587a7be71ffa92b598fef97ec0de1a1354a5e241f60d1806= c9cd0351] from class loader [sun.misc.Launcher$AppClassLoader@13cb1eb] 17:21:55.124 [SSHThread] TRACE org.apache.shiro.util.ClassUtils - Unable to= load class named [ff72007e587a7be71ffa92b598fef97ec0de1a1354a5e241f60d1806= c9cd0351] from the current ClassLoader. Trying the system/application Clas= sLoader... 17:21:55.124 [SSHThread] TRACE org.apache.shiro.util.ClassUtils - Unable to= load clazz named [ff72007e587a7be71ffa92b598fef97ec0de1a1354a5e241f60d1806= c9cd0351] from class loader [sun.misc.Launcher$AppClassLoader@13cb1eb] The ff72... value is the hashed password=2C so shiro is reading from the da= tabase properly. However=2C the log messages indicate that it's trying to = load a class with that name?? My database should be setup properly=2C with= a table 'users' and columns 'password'=2C 'password_salt'=2C and 'username= '. =20 -Robert Middleton On Wed=2C Oct 29=2C 2014 at 2:35 PM=2C Konrad Zuse wrote: =0A= =0A= =0A= Sorry=2C ignore my last reply=2C was in the middle of typing it and was goi= n g to finish it later since I didn't have time and clicked send... sorry a= ll again >( You should=2C however=2C be using "passwordservice" and passwordmanager I don't have much time now=2C so I will reply again later with some code I = have using it. check out this post though from Lez=2C who is the creator (at least I belie= ve he is one of them=2C if not the only one). http://stackoverflow.com/questions/17048153/apache-shiro-using-hashing-cred= entials-can-not-make-login-successfully From: thekonradzuse@hotmail.com To: user@shiro.apache.org Subject: RE: Configuring Shiro Programatically Date: Wed=2C 29 Oct 2014 14:33:21 -0400 =0A= =0A= =0A= I don't think we used HashedCredentialsMatcher anymore=2C=20 From: alessio.stalla@manydesigns.com Date: Wed=2C 29 Oct 2014 15:26:12 +0100 Subject: Re: Configuring Shiro Programatically To: user@shiro.apache.org You're probably missing a LifecycleUtils.init(realm)=3B Log lines come from AuthenticatingRealm most probably because JdbcRealm inh= erits those methods from AuthenticatingRealm. Typically loggers are initial= ized with the class declaring them. On Wed=2C Oct 29=2C 2014 at 3:06 PM=2C Robert Middleton wrote: Hi=2C I have set up shiro programatically using the following code: SQLiteConfig config =3D new SQLiteConfig()=3B config.enforceForeignKeys( true )=3B HashedCredentialsMatcher cm =3D new HashedCredentialsMatcher( "SHA-256" )= =3B cm.setHashIterations( 500000 )=3B JdbcRealm realm =3D new JdbcRealm()=3B org.sqlite.SQLiteDataSource ds =3D new org.sqlite.SQLiteDataSource( config = )=3B ds.setUrl( "jdbc:sqlite:light.db" )=3B realm.setDataSource( ds )=3B realm.setCredentialsMatcher( cm )=3B realm.setSaltStyle( SaltStyle.COLUMN )=3B SecurityManager ss =3D new DefaultSecurityManager( realm )=3B SecurityUtils.setSecurityManager( ss )=3B However=2C when I try to authenticate a user=2C I can't log in. This worke= d find before when I used shiro.ini with no encryption on the passwords. = The following debug information is printed out: 18:18:28.835 [SSHThread] DEBUG org.apache.shiro.realm.AuthenticatingRealm -= Looked up AuthenticationInfo [robert] from doGetAuthenticationInfo 18:18:28.836 [SSHThread] DEBUG org.apache.shiro.realm.AuthenticatingRealm -= AuthenticationInfo caching is disabled for info [robert]. Submitted token:= [org.apache.shiro.authc.UsernamePasswordToken - robert=2C rememberMe=3Dfal= se]. 18:18:29.275 [SSHThread] DEBUG org.apache.shiro.authc.credential.SimpleCred= entialsMatcher - Performing credentials equality check for tokenCredentials= of type [org.apache.shiro.crypto.hash.SimpleHash and accountCredentials of= type [org.apache.shiro.crypto.hash.SimpleHash] 18:18:29.276 [SSHThread] DEBUG org.apache.shiro.authc.credential.SimpleCred= entialsMatcher - Both credentials arguments can be easily converted to byte= arrays. Performing array equals comparison 18:18:29.277 [SSHThread] ERROR com.synexxus.gateway.connectors.SSHConnector= - org.apache.shiro.authc.IncorrectCredentialsException: Submitted credenti= als for token [org.apache.shiro.authc.UsernamePasswordToken - robert=2C rem= emberMe=3Dfalse] did not match the expected credentials. Since I setup the realm for the SecurityManager to be a JdbcRealm=2C I woul= d expect that the log lines that come from org.apache.shiro.realm.Authentic= atingRealm would in fact come from org.apache.shiro.realm.jdbc.JdbcRealm. = Why isn't this the case? =0A= =0A= --=20 Alessio Stalla | Software Architect M: +39 340 7824743 | T: +39 010 566441 | F: +39 010 8900455 alessio.stalla@manydesigns.com | www.manydesigns.com MANYDESIGNS s.r.l. Via G. D'Annunzio=2C 2/51 | 16121 Genova (GE) | Italy =0A= = --_a8aeb0d3-2702-41da-afe4-332a49ed7263_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Very detailed=2C but from what y= ou said "steve" logs in=2C but Robert does not.


I believe Steve = is the correct way the hashed passwords are supposed to work.  =3BThe s= alt and hash are usually together it seems=2C but I'm not sure if Steve has= a salt attached or not.

At least this is how the command line hashe= r works

http://shiro.apache.org/command-line-hasher.html
=


It will then ask you to enter the p= assword and then confirm it:

Password to hash:=0A=
Password to hash (confirm):=0A=

When this command executes=2C= it will print out the securely-salted-iterated-and-hashed password. For ex= ample:

$shiro1$SHA-256$500000$eWpVX2tGX7WCP2J+jMCNqw=3D=3D$it/NRclMOHrfOvhA=
EFZ0mxIZRdbcfqIBdwdwdDXW2dM=3D=0A=

Take this value and place it = as the password in the user definition line (followed by any optional roles= ) as defined in the =3BINI Users Configuration =3Bdocumentation. F= or example:

[users]=0A=
...=0A=
user1 =3D $shiro1$SHA-256$500000$eWpVX2tGX7WCP2J+jMCNqw=3D=3D$it/NRclMOHrfO=
vhAEFZ0mxIZRdbcfqIBdwdwdDXW2dM=3D=0A=

You will also need to ensure = that the implicit =3BiniRealm =3Buses a =3BCredent= ialsMatcher =3Bthat knows how to perform secure hashed password co= mparisons. So configure this in the =3B[main] =3Bsection a= s well:

[main]=0A=
...=0A=
passwordMatcher =3D org.apache.shiro.authc.credential.PasswordMatcher=0A=
iniRealm.credentialsMatcher =3D $passwordMatcher=0A=
...

Granted I believe there are ways to set the salt a= s another DB item=2C or even from another server I believe I read.

I= wish there was more I could do to help=2C I will have to try my code and s= ee how it works or not.

My buddy seemed to have everythign working w= hen I helped him=2C so i'm not too sure.
Da= te: Thu=2C 30 Oct 2014 14:32:56 -0400
Subject: Re: Configuring Shiro Pro= gramatically
From: rmiddleton@synexxus.com
To: user@shiro.apache.org<= br>
The salt is stored in the database. =3B Th= e salt is retrieved from the database. =3B The salt is ignored when cal= culating the hash of the password. =3BThe check always fails.
=

Here's the sequence that happens(note that this starts = at the AuthenticatingRealm level):
1. Starting in getAuthenticati= onInfo of AuthenticatingRealm=2C an AuthenticationInfo is looked up. = =3B This goes to getCachedAuthenticationInfo - this is null the first time= =2C so this goes to doGetAuthenticationInfo
2. doGetAuthenticatio= n info is abstract=2C so it is delegated to the JdbcRealmClass
3.= In doGetAuthenticationInfo of JdbcRealm=2C the salt is retrieved from the = database and set in the SimpleAuthenticationInfo object that this method re= turns.
4. The SimpleAuthenticationInfo is passed with the token t= o assertCredentialsMatch
5. assertCredentialsMatch asks the Crede= ntialsMatcher if the token is equal to the AuthenticationInfo
6. = The CredentialsMatcher in this case is a PasswordMatcher. =3B The relev= ant method is doCredentialsMatch.
7. The PasswordMatcher then ask= s the PasswordService(a DefaultPasswordService object) if the passwords mat= ch. =3B However=2C DefaultPasswordService looks at the saved informatio= n=2C and attempts to figure out the correct hash format.  =3B
8. The discovered format is null=2C because there's no data in the hashed = password.
9. The password is hashed=2C but the salt data that was= retrieved from the database is not used. =3B The hashed password is no= t equal to the stored password. =3B Login fails.

At some point between steps 6 and 7 there is a bug=2C in that the Defaul= tPasswordService knows nothing about the salt that is retrieved from the da= tabase. =3B The PasswordMatcher can pass information on the salt to the= DefaultPasswordService=2C but it does not. =3B This is because the Has= hingPasswordService does not have the capability to take in the salt on the= password.

For clarity=2C here's the database dump= . =3B User 'steve' can log in=2C user 'robert' cannot.

username|password|password_salt
robert|ff72007e587a7be71= ffa92b598fef97ec0de1a1354a5e241f60d1806c9cd0351|64df10ba
steve|$shiro1$S= HA-256$500000$ODjsYh0x1ASOx3gdXa3iGg=3D=3D$d0AnmvEpA1fVfBZrUKs4u+lkVwNr1o1e= Bdg+rAgqRHE=3D|

Steve's password is in the Shi= ro1Crypt format=2C which tells shiro what formula to use=2C the iteration t= imes=2C the salt=2C and the hash. =3B User robert's format has the hash= ed password in one database column=2C and the salt in the other database co= lumn(it is using the defaults of SHA-256 and 500=2C000 iterations). =3B= JdbcRealm explicitly allows this format for the salt/password.
<= br>
Of course=2C I could be fundamentally misunderstanding how th= ese passwords are supposed to be stored in the database. =3B I can stor= e passwords in the Shiro1Crypt if needed=2C I was just surprised that the f= irst way of storing the passwords didn't work.

-Ro= bert Middleton

On Thu=2C Oct 30=2C 2014 at 1:13 PM=2C Konrad Zuse <=3Bthe= konradzuse@hotmail.com>=3B wrote:
=0A= =0A= =0A=
Set the salt and stuff via java=2C and then retrieve = with your shiro.ini info.

Date: Thu=2C 30 Oct 2014 13:06:13= -0400

Subject: Re: Configuring Shiro Programatic= ally
From: = rmiddleton@synexxus.com
To: user@shiro.apache.org

W= hat's the proper way to report a bug on this? =3B There's the ASF Shiro= JIRA=2C but it seems that it's not possible to report a bug in JIRA withou= t having the correct permissions.

-Robert Midd= leton

On Thu=2C Oct 30=2C 2014 at 11:29 AM=2C Robert Mid= dleton <=3Brmiddleton@synexxus.com>=3B wrote:
The queries should all be done through the JdbcRealm class=2C th= at has the standard JDBC queries.

I have figur= ed out the problem though. =3B It turns out that shiro is ignoring the = salt when attempting to set the password up. =3B Since I have two colum= ns=2C one for the hashed password and one for the salt=2C it's correctly re= trieving them but is not setting the salt when asking for the password to b= e checked. =3B It works fine as long as the database column is in the $= shiro1 format.

-Robe= rt Middleton

On Wed=2C Oct 29=2C= 2014 at 6:07 PM=2C Konrad Zuse <=3Bthekonradzuse@hotmail.com&g= t=3B wrote:
=0A= =0A= =0A=
This is my code=2C granted I will say I have not pers= onally tested it=2C but I helped another buddy finish his project so I beli= eve this should work completely.

I haven't tested it yet only becaus= e I was siill setting up my DB and I am finishing up other things now.
<= br>I'm not 100% sure about the line "# privateSalt needs to be base64-encod= ed in shiro.ini but not in the Java code" as I got this from another source= =2C but I'm not sure why one would be and one wouldn't=2C so hopefully some= one else can answer that.

# Hash Service Original values of Pas= swordService
hashService =3D org.apache.shiro.crypto.hash.Default= HashService
hashService.hashIterations =3D 500=2C000
ha= shService.hashAlgorithmName =3D SHA-256
hashService.generatePubli= cSalt =3D true

# privateSalt needs to be base64-en= coded in shiro.ini but not in the Java code
#Salt is randomly gen= erated with the Secure Generator

saltGenerator =3D org.ap= ache.shiro.crypto.SecureRandomNumberGenerator
hashService.private= Salt =3D saltGenerator.nextBytes.toBase64


#PasswordMatcher
passwordMatcher =3D org.apache.shiro.auth= c.credential.PasswordMatcher

#PasswordService
passwordService =3D org.apache.shiro.authc.credential.DefaultPassword= Service
passwordService.hashService =3D $hashService
pa= sswordMatcher.passwordService =3D $passwordService

#DataSource which is our Database
ds =3D =3B
ds.se= rverName =3D =3B
ds.port  =3B=3D =3B
ds.dat= abaseName =3D =3B
ds.user =3D =3B
ds.password = =3D =3B
 =3B
 =3BjdbcRealm =3D org.apache.s= hiro.realm.jdbc.JdbcRealm
 =3BjdbcRealm.permissionsLookupEnab= led =3D true
 =3BjdbcRealm.authenticationQuery =3D SELECT pas= sword FROM Company WHERE username =3D ?
 =3BjdbcRealm.userRol= esQuery =3D SELECT roles FROM Company WHERE username =3D ?
 = =3BjdbcRealm.permissionsQuery =3D SELECT permissions FROM Company WHERE rol= e_name =3D ?
 =3BjdbcRealm.credentialsMatcher =3D $passwordMa= tcher
 =3BjdbcRealm.dataSource=3D$ds

 =3BsecurityManager.realms =3D $jdbcRealm


I'm assuming all = of your queries and such are done within your =3BSQLiteConfig config =3D new SQLiteConfig()=3B class? =3B Is= this your own class=2C or is this one of the predefined classes?
From: thekonradzuse@hotmail.com
To: user@shiro.apache.org
Subject: = RE: Configuring Shiro Programatically
Date: Wed=2C 29 Oct 2014 17= :54:38 -0400


=0A= =0A= =0A=
Weird... =3B It looks like there is an issue with the = class loader=2C however why does it say "Unable to load class" then "Unabl= =3Be to load clazz....???"  =3BSomething is weird there.

Date: Wed=2C 29 Oct 2014 17:40:39 -0400
Subject: Re: Configuring Shiro= Programatically
From: rmiddleton@synexxus.com
To: user@shiro.apache.org

Oh=2C that makes a bit more sense now. =3B I've used the Pas= swordService and PasswordManager now=2C but I'm still unable to authenticat= e. =3B I turned up debugging some more=2C and now I get the following o= utput:
17:21:55.123 [SSHThread] TRACE org.apache.shiro.util.Class= Utils - Unable to load clazz named [ff72007e587a7be71ffa92b598fef97ec0de1a1= 354a5e241f60d1806c9cd0351] from class loader [sun.misc.Launcher$AppClassLoa= der@13cb1eb]
17:21:55.123 [SSHThread] TRACE org.apache.shiro.util.ClassU= tils - Unable to load class named [ff72007e587a7be71ffa92b598fef97ec0de1a13= 54a5e241f60d1806c9cd0351] from the thread context ClassLoader. Trying the = current ClassLoader...
17:21:55.124 [SSHThread] TRACE org.apache.shiro.u= til.ClassUtils - Unable to load clazz named [ff72007e587a7be71ffa92b598fef9= 7ec0de1a1354a5e241f60d1806c9cd0351] from class loader [sun.misc.Launcher$Ap= pClassLoader@13cb1eb]
17:21:55.124 [SSHThread] TRACE org.apache.shiro.ut= il.ClassUtils - Unable to load class named [ff72007e587a7be71ffa92b598fef97= ec0de1a1354a5e241f60d1806c9cd0351] from the current ClassLoader. Trying th= e system/application ClassLoader...
17:21:55.124 [SSHThread] TRACE org.a= pache.shiro.util.ClassUtils - Unable to load clazz named [ff72007e587a7be71= ffa92b598fef97ec0de1a1354a5e241f60d1806c9cd0351] from class loader [sun.mis= c.Launcher$AppClassLoader@13cb1eb]

The ff72... val= ue is the hashed password=2C so shiro is reading from the database properly= . =3B However=2C the log messages indicate that it's trying to load a c= lass with that name?? =3B My database should be setup properly=2C with = a table 'users' and columns 'password'=2C 'password_salt'=2C and 'username'= .  =3B

-Robert Middleton

On= Wed=2C Oct 29=2C 2014 at 2:35 PM=2C Konrad Zuse <=3Bthekonradzuse@= hotmail.com>=3B wrote:
=0A= =0A= =0A=
Sorry=2C ignore my last reply=2C was in the middle of= typing it and was goin g to finish it later since I didn't have time and c= licked send... sorry all again >=3B(


You should=2C however=2C = be using "passwordservice" and passwordmanager

I don't have much tim= e now=2C so I will reply again later with some code I have using it.

check out this post though from Lez=2C who is the creator (at least I = believe he is one of them=2C if not the only one).

http://stackoverflow.c= om/questions/17048153/apache-shiro-using-hashing-credentials-can-not-make-l= ogin-successfully

From: thekonradzuse@hotmail.com
To: user@s= hiro.apache.org
Subject: RE: Configuring Shiro Programatically
Da= te: Wed=2C 29 Oct 2014 14:33:21 -0400


=0A= =0A= =0A=
I don't think we used HashedCredentialsMatcher anymore=2C&= nbsp=3B

From: alessio.stalla@manydesigns.com
Date: Wed=2C 2= 9 Oct 2014 15:26:12 +0100
Subject: Re: Configuring Shiro Programatically=
To: user@shi= ro.apache.org

You're probably missing a Li= fecycleUtils.init(realm)=3B

Log lines come from Authenticating= Realm most probably because JdbcRealm inherits those methods from Authentic= atingRealm. Typically loggers are initialized with the class declaring them= .

On Wed=2C Oct 29=2C 2014 at 3:06 PM=2C Robert Midd= leton <=3Brmiddleton@synexxus.com>=3B wrote:

Hi=2C

I have set up shiro programatically usi= ng the following code:

SQLiteConfig config =3D new SQLiteConfig()=3B=
config.enforceForeignKeys( true )=3B
HashedCredentialsMatcher cm =3D= new HashedCredentialsMatcher( "SHA-256" )=3B
cm.setHashIterations( 5000= 00 )=3B
JdbcRealm realm =3D new JdbcRealm()=3B
org.sqlite.SQLiteDataS= ource ds =3D new org.sqlite.SQLiteDataSource( config )=3B
ds.setUrl( "jd= bc:sqlite:light.db" )=3B
realm.setDataSource( ds )=3B
realm.setCreden= tialsMatcher( cm )=3B
realm.setSaltStyle( SaltStyle.COLUMN )=3B
Secur= ityManager ss =3D new DefaultSecurityManager( realm )=3B
SecurityUtils.s= etSecurityManager( ss )=3B

However=2C when I try to authenticate a u= ser=2C I can't log in. This worked find before when I used shiro.ini with = no encryption on the passwords. The following debug information is printe= d out:

18:18:28.835 [SSHThread] DEBUG org.apache.shiro.realm.Authent= icatingRealm - Looked up AuthenticationInfo [robert] from doGetAuthenticati= onInfo
18:18:28.836 [SSHThread] DEBUG org.apache.shiro.realm.Authenticat= ingRealm - AuthenticationInfo caching is disabled for info [robert]. Submit= ted token: [org.apache.shiro.authc.UsernamePasswordToken - robert=2C rememb= erMe=3Dfalse].
18:18:29.275 [SSHThread] DEBUG org.apache.shiro.authc.cre= dential.SimpleCredentialsMatcher - Performing credentials equality check fo= r tokenCredentials of type [org.apache.shiro.crypto.hash.SimpleHash and acc= ountCredentials of type [org.apache.shiro.crypto.hash.SimpleHash]
18:18:= 29.276 [SSHThread] DEBUG org.apache.shiro.authc.credential.SimpleCredential= sMatcher - Both credentials arguments can be easily converted to byte array= s. Performing array equals comparison
18:18:29.277 [SSHThread] ERROR com= .synexxus.gateway.connectors.SSHConnector - org.apache.shiro.authc.Incorrec= tCredentialsException: Submitted credentials for token [org.apache.shiro.au= thc.UsernamePasswordToken - robert=2C rememberMe=3Dfalse] did not match the= expected credentials.

Since I setup the realm for the SecurityManag= er to be a JdbcRealm=2C I would expect that the log lines that come from or= g.apache.shiro.realm.AuthenticatingRealm would in fact come from org.apache= .shiro.realm.jdbc.JdbcRealm. Why isn't this the case?

=0A=
=0A=



--
Ale= ssio Stalla | Software Architect
M: +39 340 782= 4743 | T: +39 010 566441 | F: +39 010 8900455
alessio.stalla@manydesigns.com | www.manydesigns.com

MANY= DESIGNS s.r.l.
Via G. D'Annunzio=2C 2/51 | 16121 Genova (GE) | Italy

=

=0A= = --_a8aeb0d3-2702-41da-afe4-332a49ed7263_--