[keycloak-dev] broker import should be local only?
Marek Posolda
mposolda at redhat.com
Thu Dec 15 05:17:25 EST 2016
We have various methods on KeycloakSession (users(), userLocalStorage(),
...), so in the code we have a way to specify that some user should be
just local KC user. For example export/import is importing just to local
DB as users already exists in LDAP.
We don't have a way for people to configure (eg. admin configures "Don't
save broker-imported users into the LDAP" ). Not sure if we need that?
As Bill mentioned, nobody requested this yet?
But if really needed for a broker, they can override authenticator for
"First Broker Login" flow though. If we want to support OOTB, we can add
a flag to this authenticator whether to save broker-imported user just
to the "local" DB or whether use userStorage layer too. But not sure if
rather wait if it's needed by someone then introduce another flag? :)
Marek
On 15/12/16 10:38, Stian Thorgersen wrote:
> Someone might want to have all their users in the LDAP server.
> Including social registered, self registered and registered by admin
> in KC admin console.
>
> Do we have a way to control where new users are created?
>
> On 14 December 2016 at 17:47, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
> There is a difference here...linking vs. import. Linking is
> linking a brokered user to an existing account. Import is when
> the user doesn't exist. I guess nobody has had a problem with
> this so my concern doesn't matter.
>
>
>
> On 12/14/16 11:32 AM, Marek Posolda wrote:
>
> +1
>
> IMO it is perfectly valid to have same user linked to both
> LDAP (or other userStorage) and identity providers. I think
> that for https://issues.jboss.org/browse/KEYCLOAK-2943
> <https://issues.jboss.org/browse/KEYCLOAK-2943> we should just
> have a way to bypass calling
> IdentityProviderMapper.updateBrokeredUser to avoid updating
> read-only user. I think that all those JIRAS are very similar
> and should be addressed together:
> https://issues.jboss.org/browse/KEYCLOAK-2943
> <https://issues.jboss.org/browse/KEYCLOAK-2943>
> https://issues.jboss.org/browse/KEYCLOAK-2950
> <https://issues.jboss.org/browse/KEYCLOAK-2950>
> https://issues.jboss.org/browse/KEYCLOAK-3829
> <https://issues.jboss.org/browse/KEYCLOAK-3829>
>
> Marek
>
>
> On 14/12/16 15:51, Stian Thorgersen wrote:
>
> As the registration form and admin console results in
> creating new users in
> a user storage provider if it supports registration I
> don't see why it
> should be any different for brokered users. They are used
> "automatically
> registered" on first login.
>
> On 14 December 2016 at 15:28, Bill Burke
> <bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>
> I'm looking at the broker flow code and it seems that
> we import users
> into whatever storage provider supports adding users.
> Should this import
> be local only and bypass any User Storage Providers?
> This breaks
> backwards compatbility, but I'm not sure the old
> approach was the
> correct one.
>
> Thoughts?
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
>
>
>
More information about the keycloak-dev
mailing list