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

[Stian Thorgersen]

Seems like we've got what we need then

On 15 December 2016 at 11:40, Marek Posolda <mposolda at redhat.com> wrote:

> 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> 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> 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 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-2950
>>>> 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> 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
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
>