<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 03/08/16 00:45, Bill Burke wrote:<br>
</div>
<blockquote
cite="mid:ea05ff64-0407-ed60-91b1-f17cee8066fb@redhat.com"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
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).<br>
<blockquote
cite="mid:ea05ff64-0407-ed60-91b1-f17cee8066fb@redhat.com"
type="cite">
<pre wrap="">
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.</pre>
</blockquote>
I think that some 3rd party federation SPI are able to store the
password credential with all the info, but some others are limited.
<br>
<br>
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.<br>
<br>
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?<br>
<br>
Previously the UserFederationProvider.validCredentials was supposed
to always receive password in plain-text. The stuff like
CredentialValidation.<span style="background-color:#e4e4ff;">validPassword
was supposed to be invoked just for validating against our JPA or
Mongo, but not against 3rd party UserFederationProviders.<br>
<br>
Marek<br>
</span>
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<blockquote
cite="mid:ea05ff64-0407-ed60-91b1-f17cee8066fb@redhat.com"
type="cite">
<pre wrap="">
Bill
_______________________________________________
keycloak-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>