Re: [keycloak-dev] The ultimate fate of master realm
Hello Stian,
On Mon, 2018-11-05 at 20:13 +0100, Stian Thorgersen wrote:
It is very unlikely that we will remove the master realm in 5.x.
Glad to hear that, thx for the info
There are already a way to deal with global config which is in
standalone.xml. The limitation there currently is that changes require a server restart
and we don't have a schema so it's a simple key-value type config. Changes here
can be done through jboss-cli and with domain mode you can have these propagated to all
nodes in the cluster. At this point we won't consider adding another level of global
config like Apache Commons Configuration.
I'd also add my 2¢ to the list of limitations:
- it's impossible to modify configuration in runtime from either Keycloak itself or
providers (or is it? DMR maybe?)
- in standalone-ha mode, you'll still need to propagate the changes to the nodes
somehow.
I think for now I'll stick to using master realm attributes. And if Keycloak is about
to undergo such a drastic changes, I hope it will be announced in advance so I'll have
enough time to port my code.
Thanks for clarifications,
Dmitry
> On Mon, 5 Nov 2018 at 10:47, Dmitry Telegin <dt(a)acutus.pro> wrote:
> Hi,
>
> The idea of getting rid of master realm has been around for years [1] [2]. Just
wanted to know, what's the current stance on this? Can we tell for sure that there
still will be master realm in KC 5.0? Or can we tell the opposite?
>
> Some background: we're working on a Keycloak extension (provider) that needs to
operate a global (non-realm-based) writable config. So I'm choosing between the two
options:
> - store config keys as master realm attributes;
> - introduce full-fledged configuration system based on Apache Commons Configuration,
backed by its own DB table and Infinispan cache.
>
> The latter is obviously more complex, however more powerful. I've posted a
write-up on it about a year ago [3], but didn't get any feedback. I hope it could be
reevaluated today; for Keycloak proper, there are several use cases like auto-update
settings, admin email, periodic tasks etc.
>
> The former, on the contrary, is much easier to implement, however there is a risk of
having to rewrite everything from scratch should master realm bite the dust one day.
>
> Cheers,
> Dmitry Telegin
> CTO, Acutus s.r.o.
>
> [1] http://lists.jboss.org/pipermail/keycloak-dev/2015-December/006066.html
> [2] https://issues.jboss.org/browse/KEYCLOAK-3443
> [3] http://lists.jboss.org/pipermail/keycloak-dev/2017-December/010261.html
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>