We currently use a similar approach:
There is a legacy user store which is used by multiple existing
applications.
We currently integrate the users from that legacy user store with a custom
UserFederationProvider which is build in a
similar way to what Scott Rossillo proposed in his blog post.
Since there are currently more applications using the legacy user store
than Keycloak it needs to remain the leading system
which means that all user updates need to be performed in the legacy user
store and Keycloak is mostly used in read-only fashion.
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.
So it's not quite just "import and forget" but rather
"import-link-refresh-and-eventually-forget"...
Cheers,
Thomas
2016-08-23 16:32 GMT+02:00 Marek Posolda <mposolda(a)redhat.com>:
On 23/08/16 15:04, Bill Burke wrote:
On 8/23/16 3:39 AM, Marek Posolda wrote:
On 19/08/16 15:52, Bill Burke wrote:
On 8/19/16 2:37 AM, Stian Thorgersen wrote:
On 18 August 2016 at 20:30, Bill Burke < <bburke(a)redhat.com>
bburke(a)redhat.com> wrote:
>
> On 8/18/16 4:59 AM, Stian Thorgersen wrote:
> > Bill,
> >
> > Are you planing to have an option to allow import of users with the
> > new user federation SPI? I'm not convinced we should completely remove
> > this option.
> >
>
> The only callback that does not exist in the new SPI is
> validateAndProxy(). With the current federation SPI, the developer
> implements everything themselves for import. There are no
> synchronization APIs/SPIs either.
>
Sounds like we're removing built-in features around synchronization just
to make the user have to do everything themselves.
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.
> > Some use-cases I could imagine:
> >
> > * Allow users to authenticate even if LDAP server is down
> Our current LDAP provider will not work if LDAP is down, even with the
> import :)
>
Yes, I know. However, the fact that we don't currently support it doesn't
mean we shouldn't in the future.
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.
So, do you still think we should support import/offline mode given all
this?
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.
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.
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.
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.
As an example this blogpost from Scott Rossillo
https://tech.smartling.com/migrate-to-keycloak-with-zero-
downtime-8dcab9e7cb2c#.1e8sy1o8n, which AFAIK seemed to have some
positive feedback from more community users.
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.
Marek
So, #1, LDAP users are getting no real advantage to importing into our
database with tremendous overhead
#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).
I just think this whole import thing is a bad idea.
Bill
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev