<div dir="ltr">We currently use a similar approach:<div><br></div><div>There is a legacy user store which is used by multiple existing applications.</div><div>We currently integrate the users from that legacy user store with a custom UserFederationProvider which is build in a </div><div>similar way to what Scott Rossillo proposed in his blog post.</div><div><br></div><div>Since there are currently more applications using the legacy user store than Keycloak it needs to remain the leading system</div><div>which means that all user updates need to be performed in the legacy user store and Keycloak is mostly used in read-only fashion.</div><div><br></div><div>Therefore we need to reload the user information in Keycloak on every login ... until Keycloak becomes the main user store for which we can then remove the federation link.</div><div><br></div><div>So it's not quite just "import and forget" but rather "import-link-refresh-and-eventually-forget"...</div><div><br></div><div>Cheers,</div><div>Thomas</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-08-23 16:32 GMT+02:00 Marek Posolda <span dir="ltr"><<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
<div>On 23/08/16 15:04, Bill Burke wrote:<br>
</div>
<blockquote type="cite">
<p><br>
</p>
<br>
<div>On 8/23/16 3:39 AM, Marek Posolda
wrote:<br>
</div>
<blockquote type="cite">
<div>On 19/08/16 15:52, Bill Burke
wrote:<br>
</div>
<blockquote type="cite">
<p><br>
</p>
<br>
<div>On 8/19/16 2:37 AM, Stian
Thorgersen wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 18 August 2016 at 20:30,
Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank"></a><a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
On 8/18/16 4:59 AM, Stian Thorgersen wrote:<br>
> Bill,<br>
><br>
> Are you planing to have an option to allow
import of users with the<br>
> new user federation SPI? I'm not convinced we
should completely remove<br>
> this option.<br>
><br>
<br>
</span>The only callback that does not exist in the
new SPI is<br>
validateAndProxy(). With the current federation
SPI, the developer<br>
implements everything themselves for import. There
are no<br>
synchronization APIs/SPIs either.<br>
</blockquote>
<div><br>
</div>
<div>Sounds like we're removing built-in features
around synchronization just to make the user have to
do everything themselves.</div>
</div>
</div>
</div>
</blockquote>
I think you misinterpreted me, The old User Federation SPI
forces the developer to write all the import code themselves.
The old User Federation SPI does not have any synchronization
callbacks, methods or interfaces other than
validateAndProxy(), the logic of which the user has to write
themselves too.<br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <span>> Some use-cases I could imagine:<br>
><br>
> * Allow users to authenticate even if LDAP
server is down<br>
</span>Our current LDAP provider will not work if
LDAP is down, even with the<br>
import :)<br>
</blockquote>
<div><br>
</div>
<div>Yes, I know. However, the fact that we don't
currently support it doesn't mean we shouldn't in
the future.</div>
</div>
</div>
</div>
</blockquote>
If the user can only be authenticated via LDAP, an offline
mode is not possible. In other words, if LDAP does not expose
the password of a user (so it can be imported), then offline
mode is not possible. It would only be possible if the user
has logged in at least once, then the validated password could
be imported.<br>
</blockquote>
<blockquote type="cite"> <br>
So, do you still think we should support import/offline mode
given all this?<br>
</blockquote>
From some recent discussions I saw, it seems that quite many
people are interested in the "import-and-forget" mode. So they
need to import user from their old legacy store (3rd party
storage or LDAP) but once user is fully in Keycloak DB, they
want to completely forget about the 3rd party storage and do all
operations around this user against Keycloak DB.<br>
<br>
The credentials/password validation seems to be the most
complicated part around this as you pointed, as the password
needs to be first successfully validated against 3rdparty
storage or LDAP . Then once password is successfully validated
and updated to Keycloak DB, user can be "forgotten" and unlinked
from the federationProvider. I hope the new SPI has a way to
deal with this usecase? Or at least have a hook, so the people
can easily unlink the user by themselves whenever they want.<br>
<br>
</blockquote>
As I said before, the current SPI does not have any support for
import. It also does not have any SPIs around synchronization or
any synchronization buttons in the admin console. It is up to the
developer to write the code to import the user. And our current
LDAP implmementation is not "import and forget", you already
mentioned password validation, but there is also validateAndProxy
which is called every time the user is accessed and which hits
LDAP every time. There's also no way to unlink the user. <br>
</blockquote></div></div>
Not right now, but it seems that many people consider the
"import-and-forget" as important usecase? You just want to import
the users from 3rd party storage or LDAP, but you need to do in
multiple steps and "wait" until password is successfully validated
for the first time.<br>
<br>
As an example this blogpost from Scott Rossillo
<a href="https://tech.smartling.com/migrate-to-keycloak-with-zero-downtime-8dcab9e7cb2c#.1e8sy1o8n" target="_blank">https://tech.smartling.com/<wbr>migrate-to-keycloak-with-zero-<wbr>downtime-8dcab9e7cb2c#.<wbr>1e8sy1o8n</a>,
which AFAIK seemed to have some positive feedback from more
community users.<br>
<br>
I don't know how deeply to go with directly supporting it at SPI
level. However IMO it will be good to have at least same level like
the current UserFederation SPI. So at least at some point (ie. after
successful password validation), the people can manually unlink the
3rd party provider from the user and migrate all the data to
Keycloak DB and then use it just from Keycloak DB.<span class="HOEnZb"><font color="#888888"><br>
<br>
Marek</font></span><span class=""><br>
<blockquote type="cite"> <br>
So, #1, LDAP users are getting no real advantage to importing into
our database with tremendous overhead<br>
#2, I do not think we have many people implementing their own
custom providers. Why? We've had few questions on something that
is really really hard to do (see the whole deployer discussion).<br>
<br>
I just think this whole import thing is a bad idea.<br>
<br>
Bill<br>
</blockquote>
<br>
</span></div>
<br>______________________________<wbr>_________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div>