2:11 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev