1:44 a.m.
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
5:49 a.m.
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
12:18 p.m.
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
1:26 a.m.
In case it could help , for our limited case, we would like the possibility to fetch
client configuration from ldap (and secret).
Historically, we manage application account (and roles) in ldap. Having keycloak able to
retrieve those from ldap would be a huge help.
Personnally, I'd like to use keycloak as an orchestrator (very good at that) between
different "store", without state.
Le Mardi, Juin 11, 2019 12:49 CEST, Stian Thorgersen <sthorger(a)redhat.com> a écrit:
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
2:16 a.m.
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
2:17 a.m.
Big question is do you want to store clients in LDAP only or multiple
places for a single realm?
On Wed, 12 Jun 2019, 07:26 cedric(a)couralet.eu, <cedric(a)couralet.eu> wrote:
In case it could help , for our limited case, we would like the
possibility to fetch client configuration from ldap (and secret).
Historically, we manage application account (and roles) in ldap. Having
keycloak able to retrieve those from ldap would be a huge help.
Personnally, I'd like to use keycloak as an orchestrator (very good at
that) between different "store", without state.
Le Mardi, Juin 11, 2019 12:49 CEST, Stian Thorgersen <sthorger(a)redhat.com>
a écrit:
> 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
7:09 a.m.
Not sure I understand your question, I imagine a functionality like for the users
("user federation"), sort of client federation which could use ldap (or other
thing). So, it could be multiple places with a "sync registration" feature or
not. I realize it is a great deal of change of course.
Le Mercredi, Juin 12, 2019 09:17 CEST, Stian Thorgersen <sthorger(a)redhat.com> a
écrit:
Big question is do you want to store clients in LDAP only or
multiple
places for a single realm?
On Wed, 12 Jun 2019, 07:26 cedric(a)couralet.eu, <cedric(a)couralet.eu> wrote:
> In case it could help , for our limited case, we would like the
> possibility to fetch client configuration from ldap (and secret).
> Historically, we manage application account (and roles) in ldap. Having
> keycloak able to retrieve those from ldap would be a huge help.
> Personnally, I'd like to use keycloak as an orchestrator (very good at
> that) between different "store", without state.
>
>
> Le Mardi, Juin 11, 2019 12:49 CEST, Stian Thorgersen <sthorger(a)redhat.com>
> a écrit:
>
> > 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
>
>
8:06 a.m.
So multiple sources for same realm. Not sure that is a common enough
use-case to add as it will of course be much simpler to have a single
client store for a realm.
On Wed, 12 Jun 2019 at 14:09, cedric(a)couralet.eu <cedric(a)couralet.eu> wrote:
Not sure I understand your question, I imagine a functionality like
for
the users ("user federation"), sort of client federation which could use
ldap (or other thing). So, it could be multiple places with a "sync
registration" feature or not. I realize it is a great deal of change of
course.
Le Mercredi, Juin 12, 2019 09:17 CEST, Stian Thorgersen <
sthorger(a)redhat.com> a écrit:
> Big question is do you want to store clients in LDAP only or multiple
> places for a single realm?
>
> On Wed, 12 Jun 2019, 07:26 cedric(a)couralet.eu, <cedric(a)couralet.eu>
wrote:
>
> > In case it could help , for our limited case, we would like the
> > possibility to fetch client configuration from ldap (and secret).
> > Historically, we manage application account (and roles) in ldap.
Having
> > keycloak able to retrieve those from ldap would be a huge help.
> > Personnally, I'd like to use keycloak as an orchestrator (very good at
> > that) between different "store", without state.
> >
> >
> > Le Mardi, Juin 11, 2019 12:49 CEST, Stian Thorgersen <
sthorger(a)redhat.com>
> > a écrit:
> >
> > > 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
> >
> >
4:01 p.m.
Yes Stian, we are planning to store clients in an LDAP storage. Initially storing only
those that are not bundled in with Keycloak (though I don’t see why we couldn’t also store
those in LDAP).
The main reasons for using LDAP for us are LDAP has advanced replication features and
functionality that are reliable and allow selective replication. We need an IAM and Client
store solution which is primarily online (and managed from the cloud) but can operate
normally while offline (on-premise, internet loss, synced). Some users will migrate from
location to location so we need “cross-realm” log-in. We don’t want to sync every user (or
client) to every location though so the filtered LDAP replication works wonderful. We can
sync all “migratory” users and then only those we expect at that physical location. We can
sync clients and users selectively based on any arbitrary attribute. Since LDAP is not
specifically a user credential store but rather a lightweight directory service we wish to
use it as such and store more than just users in it.
I have created LDAP schemas for the client related data and plan on finishing the minor
storage refactoring and LDAP Client Store implementation once I am back from vacation. I
plan on implementing the LDAP Client Store as an EAR that can be deployed rather than
baked in to Keycloak itself but it would be nice if it was eventually merged in if deemed
warranted.
Thanks,
Justin Gross
From: Stian Thorgersen
Sent: Tuesday, June 11, 2019 3:49 AM
To: Justin Gross
Cc: keycloak-dev(a)lists.jboss.org
Subject: Re: [keycloak-dev] Client Storage SPI and KEYCLOAK-6408
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
1771
days inactive
1784
days old
8 comments
4 participants
participants (4)
-
cedric＠couralet.eu -
Justin Gross -
Stian Thorgersen -
Łukasz Dywicki