Following on from this post:
you don’t always have users/passwords stored in LDAP. Admittedly it seems this is more legacy these days, but imagine you have a webapp which all your (1000+) users are registered with and you want to share those credentials. I was in EXACTLY this situation about 12 years ago, and we hit a snag – The password was hashed. Luckily, thanks to spring security, this was quickly resolved by simply configuring a passwordEncoder. NO code changes, nice! (At the time none of this was documented!)
Now move things forward. These days, passwords are not simply hashed, they are salted. This is primarily a reaction to an increase in compute speed making brute force/rainbow dictionary attacks a lot easier.
Ah ha you may think! Spring will handle it for us! Well yes and no..
Firstly; This is not simply a password encoder. Unfortunately you need access to the username and the encoder does not have this. However; there is something else – You need to create a “Salt Source”. Ideally you’d use the reflection one, and specify a userDetails property for the salt (e.g. username) BUT in this case the salt was assigned by the webapp… And is in the users table.
As I understand it, the correct/clean way to do this would therefore be to override the Userdetails object and add support for getting/setting the salt on the object. Then you can use the reflection salt source, and boom.
However; With Pentaho, thats not so easy.
Instead, you can create a saltSource, something like this:
package org.dan.salts;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.springframework.security.authentication.dao.SaltSource;
import org.springframework.security.core.userdetails.UserDetails;
public class DBSaltSource implements SaltSource {
private PreparedStatement pstmt;
private Connection con;
private String dbdriver;
private String url;
private String username;
private String password;
private static final Log logger = LogFactory.getLog(DBSaltSource.class);
DBSaltSource() throws Exception
{
}
@Override
public Object getSalt(UserDetails userDetails)
{
***SOME CODE TO GET THE SALT***
** Use the userDetails.getUsername() in your query **
** MAKE SURE TO USE A PREPARED STATEMENT OTHERWISE YOU'RE OPENING UP SQL INJECTION!***
* It's easy! *
return null;
}
/*
* Getters and setters for properties in spring security bean xml.
*
*/
public void setDbdriver(String dbdriver) {
this.dbdriver = dbdriver;
}
public String getDbdriver() {
return this.dbdriver;
}
ETC ETC . (For all 4 properties)
}
So; Now what?
Well build your class, dump it into a jar, and throw it into the BA server. At this point I’ll assume you’ve done all the JDBC configuration
Now, open up applicationContext-spring-security-jdbc.xml which you should already be familar with, and look at these changes:
<bean id="authenticationProvider" class="org.springframework.security.authentication.dao.DaoAuthenticationProvider"> <property name="userDetailsService"> <pen:bean class="org.springframework.security.core.userdetails.UserDetailsService"/> </property> <property name="passwordEncoder"> <ref bean="jdbcPasswordEncoder" /> </property> <property name="saltSource"> <bean class="org.dan.salts.DBSaltSource"> <!-- Not sure why, but the vars used below don't work here. Suspect because we're in the authenticationProvider scope? --> <property name="dbdriver" value="net.sourceforge.jtds.jdbc.Driver"/> <property name="url" value="jdbc:jtds:sqlserver://localserver:1433/adbsomewhere"/> <property name="username" value="dbuser"/> <property name="password" value="password"/> </bean> </property>
Note two things:
We link our class which we coded above, to the “saltSource” for the authentication provider.
To see how this works, look at the code here:
Make sure you look at the right version of the code. Check the libs in Pentaho server to be sure.
Anyway you’ll see thats how the salt thingumabob works. So now, we have our code, which gets a user specific salt and sends it to the password encoder.
If your lucky you can use a standard password encoder. If not, then you can customise one! In doing so, pay very careful attention to encodings (base64) but also the charset. So in my case, the password was base64 encoded, SHA-256 hashed, but the original string that was hashed had to be UTF16_LE . (This equates to Encoding.UNICODE in C#)
In fact – this is a key learning here – before you even go near any custom encoders, or spring, make absolutely sure you can write the code to match the passwords in the database FIRST. (You can do this in PDI, quick and easy).
One word of warning – All the encoder and saltSource stuff has changed in spring5, the passwordEncoder is now deprecated. It doesn’t look like the solution above will work in the same way so as always, when coming to upgrade time you’ll have to test, and re-write these snippets of code. (No sign that there’s any plan to upgrade spring at the moment however)
Finally, huge thanks and shout out to Alex Schurman for spending 5 minutes guiding me along the way to a solution!
Lets also thank the #Opensource gods. None of this could have been done with closed proprietary code.
Codeks Blog 