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

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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >>> >> > >