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

Stian Thorgersen sthorger at redhat.com
Thu Dec 15 05:21:20 EST 2016


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
>>>>
>>>
>>>
>>>
>>
>
>


More information about the keycloak-dev mailing list