I will share more details around Keycloak Next in a few weeks. Just need to
get time to write it up.
On Tue, 11 Jun 2019, 18:55 Łukasz Dywicki, <luke(a)code-house.org> wrote:
Hey Stian,
I track mailing lists from time to time but I see the term
"Keycloak.Next" first time.
Do you have a scope of changes you would like to introduce within next
major release? Perhaps there is an JIRA epic or something where I could
sign in to track progress and horizon of changes?
All best,
Łukasz Dywicki
--
Code-House
http://code-house.org
On 11.06.2019 12:49, Stian Thorgersen wrote:
> We are planning a bigger rework of the storage layer in the future as
part
> of Keycloak .Next.
>
> With that in mind you should rather follow the discussion around that as
it
> unfolds over the next few months.
>
> For the current implementation we can be open to smaller stuff, but not
big
> overhauls.
>
> Finishing the client storage API may be useful, but to be honest not many
> people have been interested here. I'd rather see a simpler client store
> where it's easier to replace with a custom store. I don't think there's
> need to federate multiple client stores for a single realm.
>
> For LDAP I'm not sure what you mean about separate core and user stuff.
It
> is only a user store, at least now. Are you perhaps thinking about
storing
> clients in LDAP?
>
> On Sat, 8 Jun 2019 at 08:46, Justin Gross <jgross.biz(a)gmail.com> wrote:
>
>> Good afternoon, good evening and good morning everyone! I am Justin and
>> I’d like to start contributing to Keycloak.
>>
>> Is there anyone on the list that is interested in the continuing
>> development of Client Storage SPI? (KEYCLOAK-6408 in JIRA)
>>
>> If you answered yes to the above, what storage systems/software are you
>> interested in using for client storage?
>>
>> Preparing to take on some of the things listed in KEYCLOAK-6408.
>>
>> I am in the middle of a lite refactoring of some useful things which are
>> currently specific to user storage federation such as
>> SynchronizationResult, ImportSynchronization, etc… so they can be used
by
>> the yet to be finished Client Storage API.
>>
>> I also plan to refactor some of the LDAP federation stuff so that the
user
>> specific stuff is separate from the core LDAP functionality itself.
>> Eventually I want to use LDAP to store client configuration and there’s
a
>> lot of useful LDAP functionality stashed away in the user federation
stuff.
>>
>>
>> Thank you,
>>
>> Justin Gross
>>
>> _______________________________________________
>> 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
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev