So in our application (REST)  we have the standard users with logging in via 
username/password. However, we also have a login as guest. However, guest users 
are still full users in our system. When a user signs in as guest for the first 
time a request is sent with just a FingerPrint, this is a HASH sent from the 
client to the REST api. To determine that this is the first time this 
fingerprint/deviceID has been sent I do a db lookup WHERE db.fingerPrint = 
loginRequest.fingerPrint. 

If it doesn’t return a record then that means it is a new guest and we create a 
User instance and store it in the db. We generate a username GuestNNN and 
generate a password for them, which we never send to them. If it does return, 
then we take the userName from the db and the passed in signature and create a 
SignatureAuthenticationToken, which just extends 
UsernamePasswordAuthenticationToken and the constructor we pass in username and 
fingerprint String. This works when we encrypt the fingerPrint with 
PasswordService and store it encrypted.

However, this does not work then on subsequent logins by that guest, because in 
order to get the userName I have to query the db using the same WHERE clause
WHERE db.fingerPrint = loginRequest.fingerPrint

It fails because the incoming login request has the fingerPrint unencrypted and 
the where clause will never match what is in the db, because the db has it 
stored encrypted. 

If I try to just store the fingerprint in the db unencrypted, then the login 
will fail because we are using PasswordMatcher with DefaultHashService which 
will always take the fingerprint and encrypt it and compare it to what is in 
the db, which is now unencrypted. So I am sort of damned if I do, damned if I 
don’t.

The login as guest request will always just have the fingerPrint, the client 
will never know or send us the userName because it doesn’t know it.

We can’t use rememberMe as unauthenticated user as guest because we need to 
make them an actual user with data stored in the database that on subsequent 
logins keeps their information etc.

Any ideas?

Thanks

Mark

Reply via email to