<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 8/19/16 2:37 AM, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAcrFJurnNYFB3Vi1dWmkVrWWWjtVVTMgp9C+VFtgxFFMQ@mail.gmail.com"
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 moz-do-not-send="true"
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
class=""><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
cite="mid:CAJgngAcrFJurnNYFB3Vi1dWmkVrWWWjtVVTMgp9C+VFtgxFFMQ@mail.gmail.com"
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 class="">> 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>
<br>
So, do you still think we should support import/offline mode given
all this?<br>
<br>
Bill<br>
</body>
</html>