[keycloak-dev] broker import should be local only?

[Marek Posolda]

Yes, the LDAP provider has "Synchronize registrations" flag on it.

Custom userStorage implementation can decide as well what to do. It 
seems that if they don't implement UserRegistrationProvider interface 
(or return null from "addUser" like LDAP provider is doing), then user 
will be added to Keycloak DB only.

Marek

On 15/12/16 11:21, Stian Thorgersen wrote:
> I don't mean for a broker only, I mean for all new users". Can we say 
> all new users should be created locally and not in LDAP?
>
> On 15 December 2016 at 11:17, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     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>
>>
>>
>>
>>
>>
>
>