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