On 03/08/16 00:45, Bill Burke wrote:
Hey,

Ran into something implementing a user federation example.  My user 
federation example stores passwords in plain text.  So, I wrote a plain 
text password hasher. The first time the password is validated, the 
hashing iterations don't match from the returned 
UserCredentialValueModel.  The user fed provider always returns 0 
because its plain text.  The CredentialValidation class sees that the 
hash iterations dont' match with the default realm's hashing iterations, 
so the password is rehashed.  Rehashed with the default realm 
algorithm.  There is a bug here in that the algorithm is not set to the 
realm's hashing algorithm, so, once a user is validated once, they can 
never be validated again...at least in this scenario.
I assume it works this way, for case that the old passwords are imported from some legacy storage into Keycloak DB. Those passwords might be hashed with some weak algorithm or they might be just in plain-text. So after successful validation of plain-text password is the stored plain-text password dropped and new password credential is created and saved again into Keycloak DB with the official realm algorithm (pbkdf2 + 20000 iterations).

The bigger question is, how do we handle this scenario where the User 
Federation Provider does not store passwords in the same format as the 
realm's password policy? The workaround is to ignore password updates 
when updateCredentialsDirectly is called.  But this seems like a hack.  
A lot of documentation would need to be in place for this.
I think that some 3rd party federation SPI are able to store the password credential with all the info, but some others are limited.

For example if you want to update password to LDAP , you need to send it in plain-text. Not send hash + salt + requested hash algorithm. Same if you want to validate password against LDAP, you need to use plain-text. In other words, credential storage SPI must be able to use UserCredentialModel instead of UserCredentialValueModel.

Not sure if credential SPI storage should support both possibilities? Either possibility to store plain-text password or full UserCredentialValueModel or both? And have some switch what exactly it supports?

Previously the UserFederationProvider.validCredentials was supposed to always receive password in plain-text. The stuff like CredentialValidation.validPassword was supposed to be invoked just for validating against our JPA or Mongo, but not against 3rd party UserFederationProviders.

Marek
 

Bill

_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev